This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3220MOD: CC3220MODS Firmware update

Part Number: CC3220MOD
Other Parts Discussed in Thread: UNIFLASH, CC3200

Currently there are three options for firmware update function of CC3220MODS

1. Use bootloader that CC3220 originally support

2. Self-developed secondary bootloader program. That is after CC3220 boots, run the secondary bootloader. Secondary bootloader can decide whether run application or run firmware update process.

3. External MCU directly operate the external flash of CC3220.

Question:

1. Is option 3 workable? Can the 4MB external flash memory be divided into two areas for saving a backup image? The external flash is connected to CC3220 and the external MCU at the same time. Will there be conflicts after power-on?

2.  It seems option 2 can be supported on CC3200, whether there is a demo on CC3220 for option 2? Are there regulations for the flash memory area and ram area for secondary bootloader and application storage? When doing firmware update, is it possible to flash the app.bin without packaging the application image by using uniflash?

Thanks.

  • Hi,

    Answers to your questions:

    1. If you talk about SPI flash insider module (sFlash) that this is not possible. You can program SPI flash from external programmer / MCU via pins FLASH_SPI_*. But all content of SPI flash is rewritten always.

    2. This option is achievable. But this option is not directly supported by TI. Similar option was used with CC3200 (1st generation) devices. You can look CC3200 SDK and OTA examples.

    > Are there regulations for the flash memory area and ram area for secondary bootloader and application storage?

    Direct access into SPI flash is not supported. That means you need to use sl_ filesystem API. In case of any device without internal XIP flash is entry point for code execution in RAM at address 0x20004000. Your own bootlaoder needs start there. Example how to load code into RAM and start execution you find here. Be aware that my bootloder was written for SF devices. That means you will need re-map entry point of you application into different place inside RAM.

    When doing firmware update, is it possible to flash the app.bin without packaging the application image by using uniflash?

    > Yes. You can use sl_ filesystem API at same way as is used with OTA updates at CC32xx SDK.

    Jan