I managed easily to compile and download micropython on the STM32F407 Discovery! Thank you very much for the very good description on that. It's working perfect.
One thing: If I open the drive provided by micropython as PYBFLASH then it shows only a capacity of 95k. I would expect much more because the image I downloaded had only ~270k and the bord has 1M. I need more than the 95k.
Any ideas what happens to the rest of flash memory?
Thanks, Thomas
STM32F407 Discovery size of flash drive
Re: STM32F407 Discovery size of flash drive
The flash on the 405/407 is comprised of 4x16K, 1x64K and the remainder 128K pages.
The way flash works is that when you erase a page, the entire page turns to 1 bits. You can then write 0's in using much smaller writes. The net effect is that when the filesystem needs to modify the contents of an already written page, it needs to read the flash page into RAM, erase the flash page, and then write the new contents.
The pyboard has 192K of RAM. We reserve 64K for this purpose, which limits the size of flash block we can use to 64K. The very first page of flash contains the interrupt vectors, so we can't really use that as part of the file system. That leaves 3x16K + 1x64K = 48K + 64K = 112K for the internal file system. If we wanted to use the 128K pages, we would need to reserve an additional 64K of the 128K of RAM which is available.
The way flash works is that when you erase a page, the entire page turns to 1 bits. You can then write 0's in using much smaller writes. The net effect is that when the filesystem needs to modify the contents of an already written page, it needs to read the flash page into RAM, erase the flash page, and then write the new contents.
The pyboard has 192K of RAM. We reserve 64K for this purpose, which limits the size of flash block we can use to 64K. The very first page of flash contains the interrupt vectors, so we can't really use that as part of the file system. That leaves 3x16K + 1x64K = 48K + 64K = 112K for the internal file system. If we wanted to use the 128K pages, we would need to reserve an additional 64K of the 128K of RAM which is available.
Re: STM32F407 Discovery size of flash drive
Well the recent work towards bytecode that can be loaded from files or linked with the firmware image may become helpful.
it would be thinkable that libraries get linked to the firmware, using that extra flash memory. in such a scenario, that flash does not need to be a writable filesystem.
an other option would be a simple erase-all/write-once file system, where you could download any file into that space (appending). you just could not change it unless you erase the entire filesystem. this would still be useful for libraries or static data for an application (images, js libs a webserver serves, ...)
is there already an API to get access to that flash from python?
it would be thinkable that libraries get linked to the firmware, using that extra flash memory. in such a scenario, that flash does not need to be a writable filesystem.
an other option would be a simple erase-all/write-once file system, where you could download any file into that space (appending). you just could not change it unless you erase the entire filesystem. this would still be useful for libraries or static data for an application (images, js libs a webserver serves, ...)
is there already an API to get access to that flash from python?
Re: STM32F407 Discovery size of flash drive
I'm not aware of any python accessible classes, but it seems like it would be pretty straight forward to create one.
The critical information is in stmhal/flash.c
You'd probably want to expose the flash_info_table, and the handful of flash functions.
The python functions should probably prevent pages in the firmware from being erased/written. Basically everything upto _edata is part of the firmware and shouldn't be touched. Although that also depends on where storage.c decided to put the in-flash file system.
And any code which wants to write to flash should coordinate with the storage_irq_handler(), since you don't want to try writing to flash while its writing to flash or vice-versa.
The critical information is in stmhal/flash.c
You'd probably want to expose the flash_info_table, and the handful of flash functions.
The python functions should probably prevent pages in the firmware from being erased/written. Basically everything upto _edata is part of the firmware and shouldn't be touched. Although that also depends on where storage.c decided to put the in-flash file system.
And any code which wants to write to flash should coordinate with the storage_irq_handler(), since you don't want to try writing to flash while its writing to flash or vice-versa.