Very broken WOFS on STM32F1

[ttmrichter]

I have several STM32F1 boards: one (STM32F103ZET6) is filled to the brim with peripherals, two are "minimum core" systems (STM32F103ZET6 and STM32F103RCT6).  In all of them I have a basic problem: if I turn WOFS on I get a hard fault at startup.  If I turn WOFS off I have a functioning system (without the ability to write files to flash, obviously).  I've traced the problem down to one point, but past this I'm stuck.  I'm hoping I can get someone with more knowledge of the internals to point me to a fix.

The issue is that the romfs_open_file() function (src/romfs.c line 74) contains within it a while(1){...} loop that never exits.  There are two exit tests: one for the WOFS_END_MARKER_CHAR value (which returns FS_FILE_NOT_FOUND) and one for finding the file (which returns FS_FILE_OK).  These are the only two ways to exit the loop.  Neither of them ever gets hit.  The conditions for neither are ever met.  The loop just goes on and on until it causes a double fault (likely by trampling over random memory; I haven't yet characterized the full fault).

At this point I'm stuck.  I can't see anywhere in the source where WOFS_END_MARKER_CHAR is actually set in the flash that is actually executed.  (It's set in wofs_format(), in romfs_init() iff ELUA_CPU_LINUX is defined, which it obviously isn't in this case.  Further wofs_format() is not called anywhere except from the shell which never executes because the system explodes on contact long before the shell runs.)

I'd appreciate some pointers from anybody on how I can proceed here.

[BogdanM]

Hi,

WOFS_END_MARKER_CHAR is 0xFF, which is the value you get in flash after it is erased. When you program your boards, try to erase the whole flash, not only the flash used by your firmware. This should help with your problem.

Best,
Bogdan

[michael.brunt]

Hello,

I can confirm the WOFS also fails on the STM3210e-EVAL Revision D

In my case the system would start fine but crash after some amount of file system access. For example ls would sometimes list all the files but would often crash the system. I am 98% sure I tried clearing the entire flash but it was a few months back so I cant say for sure.

On Wed, Nov 18, 2015 at 5:13 AM, BogdanM [via eLua Development] <[hidden email]> wrote:

Hi,

WOFS_END_MARKER_CHAR is 0xFF, which is the value you get in flash after it is erased. When you program your boards, try to erase the whole flash, not only the flash used by your firmware. This should help with your problem.

Best,
Bogdan

---

If you reply to this email, your message will be added to the discussion below:

http://elua-development.2368040.n2.nabble.com/Very-broken-WOFS-on-STM32F1-tp7578555p7578556.html

To start a new topic under eLua Development, email [hidden email]
To unsubscribe from eLua Development, click here.
NAML

[ttmrichter]

That worked, yes, but ... this does not strike me as a very robust way of handling the matter.  Will patches to this with a more robust system be accepted?

[BogdanM]

They definitely will, yes. WOFS in particular is very poorly tested, so apologies for the weird behaviour and feel free to improve it ad infinitum :)