The filesystem is basically the resources that gets downloaded to the external flash when we build our application.
These resources are WICED webserver components such as web pages, images, scripts, styles, WLAN firmware, Security certificates etc. For more information on the resources, you can refer to the 43xxx_WiFi/resources/README.txt in WICED STUDIO SDK. When we build our application, filesystem.bin is also build which contains all these resources, basically whatever is required by the app makefile in resources folder-->43xxx_Wi-Fi/resources.
The above points on the usage of serial flash are right. The filesystem, OTA application, factory reset application, Wifi firmware, APP0,APP1, APP2, by default all goes in external (serial) flash.
Regarding Q1, Which serial protocol are you planning to use?
Regarding Q2, You can provide the RESOURCES_LOCATION ?= RESOURCES_IN_DIRECT_RESOURCES in the platform makefile, in this case the resources like wifi firmware, clm_blob etc will be packaged as a part of APP_CODE region and will go in internal flash but if you require OTA factory reset, external flash will be necessary in that case. The factory reset application, APP1 and APP2 also goes in external flash.
Thanks AditiB_81 for your reply.
Further to your list of resources on the SPI flash "WLAN firmware" and "Security certificates" - is there a way to avoid using the SPI flash altogether (to enable USB flashing of the STM32F412).
I assume that certificates can be stored and used out of the DCT, what about the "WLAN firmware"? Can it be flashed to the internal flash instead the SPI flash?
And a spin-off question:
For testing purpose - What is the way to do full internal flash erase/full SPI flash erase in wiced build system?
The WLAN firmware and the Security certificates are flashed to the internal flash when the resources location is provided as RESOURCES_IN_DIRECT_RESOURCES in the platform makefile. So, you can change the download location to internal flash of the host from the external flash in this way.
For the SPI flash erase, you can follow this blog post-->
I followed your link to erase the sflash and right afterwards changed the platform's makefile to use RESOURCES_IN_DIRECT_RESOURCES (see screen cap)
However now, the application does not run.
I thought that maybe some other 'stuff' resides on the sflash and erasing it prevents the system from running correctly...
Does the bootloader uses the sflash? I see WICED_NO_WIFI macro in its *.mk file.
How does the bootloader "knows" the platform it runs on and the fact this platform do NOT use sflash ?
Any advice is appreciated.
1 of 1 people found this helpful
I see that the application isn't running when you change the resources location to IN_DIRECT RESOURCES. First of all, Is the application getting build successfully (any APP_CODE overflow error in the build logs)? Was that application working when the resources location was WICEDFS? You can also check whether normal applications such as snip.scan is going through with resources location to INDIRECT_RESOURCES? Also, where do you see the WICED_NO_WIFI macro, in the platform.mk file or the application's makefile?
Regarding your query of bootloader. The bootloader goes in the internal flash for platforms with both internal + external flash. You can refer to the WICED-OTA.pdf in WICED. Location: 43xxx_Wi-Fi\doc\WICED-OTA.pdf. You can refer to the standard_platform_targets.mk for the BOOTLOADER_TARGET that gets build and the $(PLATFORM) gets updated according to what make target we provide.
Also, you can ensure that SFLASH gets disabled by commenting out the lines under /* SPI flash is present */ in the platform.h file of your platform. For ex: for MurataType1LD i.e. a STM32F412 based WICED platform, you can go to the platform.h file of this platform and can disable these lines-->
/* SPI flash is present */
#define WICED_SPI_FLASH_CS ( WICED_GPIO_1 ) /* PA4 */
You can try these things out and let us know. Please feel free to ask any other such queries.