Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I have already added a UART to the bootloader, which I am modifying. The SDK is great because this was rather easy to do!
However, we need to load the WiFi firmware into the external flash manually via a UART in the bootloader instead of using the FTDI. This is for a board used for production testing of modules and we do have the ability to bootload the ST processor, but not the external flash. Furthermore, we are out of internal memory to store the WiFi firmware image internally.
To clarify a bit more these boards contain the host processor and external flash only. They are a socket that our module is placed in to be tested. We upgrade them at our CM by having the production software bootload them via the ST's internal bootloader (UART). We would like this capability for the external flash as well.
My thoughts are modify the bootloader programmed via the ST's internal bootloader to accept UART commands that program the external flash. Specifically, my question is what address in external flash is the mfg-test.bin located? I realize this lies in the WICED file system so this may be rather tricky. We don't necessarily care about the factory reset aspect of the SDK.
The importance of this is if there are updates to the SDK and the mfg-test.bin gets updated we can get it in the ext flash.
Used ThreadX instead of the FreeRtos with lwip. This allows me to put the WiFi firmware in internal flash. Would still like to know how to accomplish the above question since customers may find this functionality useful.
External flash is used as file system and it holds DCT backup image, applications and OTA firmware image, etc.
After boot-up, which application would be loaded from external flash to internal flash is determined by checking the DCT entry.
Are you running out of memory to store the BCM4343W binary into the host memory? If you are trying to include this image into the bootloader, it would not fit because the boot loader section is reserved with less memory (15K) to just to boot and start the application. If bootloader section needs to be incremented, the BTLDR_CODE entry in ".../WICED/platform/MCU/<HostPlatformFamily>/<HostPlatform>/memory_with_bootloader.ld" could be updated and following sections will be pushed out as well.
I guess at this point it would be useful to have a means other than JTAG to program the WiFi bin into external flash. Our customers would find this very useful. Basically bootload a program to accept UART commands to program external flash.
Right now you load a program to accept JTAG commands to program the external flash. We would like to do the same but with UART instead.
If you already have the data received from serial communication port, the wiced_framework_app_xxx() APIs could be utilized to write data to serial flash. Please take a look at .../include/wiced_framework.h file. This APIs actually make a call to platform specific APIs to access the serial flash and the definitions could be found in .../WICED/platform/MCU/wiced_apps_common.h.
The .../apps/snip/tftp snip application utilizes serial flash writes by "wiced_result_t wiced_framework_app_write_chunk(...)" API call.
Similar access to serial flash is already being used by the OTA upgrade and the OTA server implementation could be found in ..//libraries/daemons/ota_server/wiced_ota_server.c with "wiced_framework_app_write_chunk(...)" API call. This implementation uses the same Wiced Application Framework to access the serial flash read write. The OTA server implementation also incorporates the web services and it is more comprehensive.