L4 integration: Modification to flash and storage. #1922
Conversation
|
Just a thought: The L4 seems to have the advantage of small, continous flash blocks. It might be possible to implement a "secure" write that prevents the internal filesystem to become corrupt in case of power failures while flash is written (using bank swapping for example). This is something that occurs often especially if the system is usb powered and thus can be powered/plugged off anytime. I have no spefific knowledge about the various flash filesystems but maybe its worth investigating this further. Would be a real benefit for this platform. |
|
A year ago i evaluated spiffs (https://github.com/pellepl/spiffs) for the use in an embedded system. The code looked quit good, ram usage is low and the license allows to do anything with the code. Probably there are other FS and I would be happy to hear about them. |
|
Yes something like that. He describes the powerloss scenario and the page swapping, so that seems convincing. It might not work in 100% in all cases but better than pure Ram buffering. On the other hand, the lack of proper directory support might not be compatible with uPy? Anyway, it's an issue that must be desided by the uPy maintainers. I just thought it's worth mentioning it here as corrupted filesystems are reported frequently on the forum as well. Btw great to see support for the L4! Its a nice addition to the uPy universe. |
|
The filesystem corruption reported in the forum (and in my own experience) has been down to the lack of multi-master compatibility in the USB mass storage spec. I can't recall anyone experiencing issues with USB MSC disabled. |
|
I'm not convinced if the root cause is due to incompatibility of multi master MSC. As far as I know the Pyboard doesn't write to the file system by its own. At startup, it parses the code in flash, but the VM then runs entirely in ram (skipping frozen bytecode for know), You can then write files from your python code of course and that can interfere with the PC, but thats not what i have experienced. So normally, the only one that does dirty things with the pyboard flash file system is the PC... On my OSX machine it writes hidden .trash folders etc on it. if the pyboard resets or is powered off while the PC writes staff on it, it messes up the file system. If MSC is disabled it helps, but the underlying root cause might be that the bank being written was erased and not yet completly written, hence leaving the fs corrupted. This can in principle also happen without MSC (maybe a uPy test script that writes to flash file system can force such a scenario)? A RAM bufferd flash write is something to be avoided IMO. |
|
Merged in 067fb2d with cosmetic changes (eg whitespace, some name changes). |
…o uint32_t so it matches the sample rate type parsed from the WAV header format, fix micropython#1922
This is another PR in a series (#1888, #1890, #1903, #1904, #1916, #1917, #1918, #1919, #1920, #1921 ) of PR to support the STM32L4 series in micropython. (see http://forum.micropython.org/viewtopic.php?f=12&t=1332&sid=64e2f63af49643c3edee159171f4a365)
The old way to describe a flash had no meaning with the flash on the 2tm32l476xg which has 512 Sectors of 2048 Bytes. In the old structure this would have introduced a
flash_info_tablewith 512 entries, which I thought is not good. To guarantee the correct function of the reengineeredflash_get_sector_infofunction I wrote a little unit test. This can be obtained from my repo in thestm32l476discovery_integrationbranch in stmhal/tests.This PR is independent of earlier PR.