The map of the external flash is dynamically changing based on what images are set to go to flash (out of the 8 binaries). What happens is, the files are simply stacked in the flash. Each files is aligned to a flash sector size though.
so if 2 files (e.g. factory reset 6k and DCT 6k) are meant to be in the flash, then starting from initial adddress of the WAF file system (which is set in the platform make files). Let's assume this address is 0x00000000 for now, FR will start at that address and go up to 8k (because the sector size is 4k). Next comes DCT at address 8K and goes up to 16K, and so on.
All of this you can find in tools/makefiles/wiced_apps.mk
Finally, WICED implements another read only file system is one of the 8 binaries. so consider using that filesystem as well before porting your own.
1 of 1 people found this helpful
The initial layout of external flash is defined in wiced_apps_lut.c. As Bassem said the compiler sets up the layout based on some make file scripts. If you use WAF to write to external flash then it does in fact dynamically change the sizes of apps based on what you write.
But - external flash is not touched by WAF at all unless several things happen. This includes setting some parameters in your make file (e.g. FR_APP, OTA_APP, etc.) AND adding "download_apps" to your build target. The download_apps part is what results in an actual pseudo file system on the external flash.
If you don't do both of those things then WAF doesn't use external flash and you have it all to yourself. I figured this out the hard way because I was trying to get WAF to use external flash for OTA upgrades and it wasn't getting set up until I did the above.
Also, I don't believe that WAF does anything behind the scenes to external flash. In other words, WAF isn't an operating system and unless you call a function that accesses external flash it won't be touched.