[WeAct STM32F411CEU6] Avoiding “Volume was not properly unmounted” warnings

[scruss]

I'm really enjoying using MicroPython on these boards - thanks, mcauser, for the very clear definitions/instructions!

One thing is not quite right: on resetting the board, the drive ejects without cleaning up writes. At best, I get Volume was not properly unmounted. Some data may be corrupt. Please run fsck. warnings when it remounts. At worst, the board reset itself mid-write and locked my computer (i7, Ubuntu 2020.04).

Is there a way to mark the flash storage equivalent to the Windows Quick removal policy? This might reduce the warnings a bit.

I see that CircuitPython (are we allowed to say that here?) tries to manage indexing under OS X only by creating empty .fseventsd/no_log, .metadata_never_index and .Trashes files, but managing removal policy seems more generally useful.

[tannewt]

Typically the MicroPython or CircuitPython device can't do anything to get the Host OS to flush filesystem changes. It's really up to the user on the host OS to "eject" or "safely remove" the device before resetting.

[scruss]

Hmm - that's annoying. Especially since the flash on one of my F411 boards is in such a mess that Linux doesn't even see it as a filesystem any more, and there's no way of doing the safe mode reset on it.

[dhylands]

You can do a mass erase followed by reflashing firmware to reset your filesystem. You can also manually use dfu-util to erase just the filesystem area.

Are you saying you didn't connect up LED and USRSW in your mpconfigboard.h file?

[dhylands]

Here's a script that uses dfu-util to erase the first sector of the filesystem (assuming your filesystem starts at 0x08004000) which is enough to get micropython to reinitialize the filesystem when it boots up.
https://github.com/dhylands/upy-example ... aord-fs.sh

For reference the contents of the script is:

Code: Select all

#!/bin/sh
#
# This script demonstates how to erase just the filesystem on a pyboard.
#
# It actually only erases the first sector of the filesystem, but this
# is enough to make micropython reinitialize things.

set -x

echo -e -n "\xff" > ff.bin
dfu-util -s 0x08004000:leave -a 0 -d 0483:df11 -D ff.bin

[dhylands]

Also for reference, here's how to perform a mass-erase:

Code: Select all

#!/bin/sh
#
# This script demonstates how to mass-erase the entire flash.

set -x

echo -e -n "\xff" > ff.bin
dfu-util -s :mass-erase:force -a 0 -d 0483:df11 -D ff.bin

In this case the file ff.bin isn't actually used, but dfu-util wants a file passed in before it will continue.

[scruss]

Thanks for the guidance.

Are you saying you didn't connect up LED and USRSW in your mpconfigboard.h file?

Uh … maybe? This board only has a single blue user LED, so the colour change to indicate status isn't going to happen.

I also have more than a suspicion that running a ws2812 strip off SPI1_MOSI that happens also to be the board's external flash DI line could have comprehensively hosed the flash in short order ...

[dhylands]

The code detects that you only have a single LED configured and instead of using colors, it will flash the LED 1, 2, or 3 times.

So you press and hold the USRSW while resetting, and while you're holding it will flash once, pause, flash twice, pause, and flash 3 times, pause and the repeat. You release the USRSW when you see the appropriate number of flashes.

1 flash = standard boot
2 flashes = safe boot
3 flashes = filesystem reset

[scruss]

Ah, thanks. I got it to rewrite the flash, and it starts, but the filesystem doesn't seem too happy. Like I said before, I may have accidentally destroyed the flash. Is there a flash checker script, or do I need to write/run my own?