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.

CC3220: CC3220+CC2642

Part Number: CC3220
Other Parts Discussed in Thread: CC2642R,

Hi Team,

I have a few questions in order to continue my design based CC3220+CC2642:

 

1.      Do I need external flash for the CC3220 in all 3 flavors?

2.      What is the trade offs in the power consumption if I use an external flash and not the internal one?

3.      How do I do SW update for the CC3220? only external flash or can I use the BT CC2642R to update the WiFi chip?

4.      In case there is an external memory connected to the CC3220 and I would like to save the sensor data collected on the CC2642R in that memory, is there a limitation for such a connectivity (to open the channel through the WiFi chip)?

Thanks,

Shlomi

  • Hi Shlomi,

    1. Yes, all CC3220 variants require the external serial flash. This storage is required to support the file system used by the Network Processor, the initial boot image, OTA updates, etc.

    2. The external flash is mandatory so it should be accounted for in terms of power estimates. The external serial flash is accessed through the network processor, which means there will be a slight power increase due to the fact that the network processor will be on during flash accesses.

    3. The CC3220 boots from the external serial flash (at least initially or after OTA update on the SF). To perform a software update, you will write a new image to the mcuimg.bin (or mcuflashimg.bin) file in the file system. The content for the new software can be delivered to the device however you like, whether that is through a physical connection (UART) or wireless connection (Wi-Fi or BLE). For full details on the software update process, take a look at our OTA Update Application Report. This document covers the process from the perspective of updating the software over the Wi-Fi interface, however, a lot of the process (and a lot of the OTA library) is still applicable for other designs. In particular, you can reuse the design of the update archive and the file write/commit process for creating a robust software update solution.

    4. Are you referring to creating a design where both ICs share the external serial flash? For simplicity, I would recommend passing the data from the CC2640R2 to the CC3220 device to have the CC3220 store it on the file system when needed.

    Best,
    Ben M
  • Hi Ben,

     

    Thanks for your detailed reply.

     

    The architecture is such the CC2642 is the master and the CC3220 is the slave

    so if I were to connect the flash only to the CC3220 does this still makes sense?

    The master (CC2642) going through the slave (CC3220) to get its image?

    When I am storing data its ok - the question is for burning the image and booting

    Also I understand that there are tools for setting the IOs for both devices

    Please send the link and let me know if you know in advance of any constraints considering the architecture.

    Thanks,

    Shlomi

     

    CC2642+CC3220.docx

     

  • Hi Shlomi,

    What do you mean CC2642R2 getting its image through the slave? Are you referring to an off-chip OAD for the CC2642 device that uses the CC3220's file system?

    There definitely will be some overhead when storing data through the CC3220. You will want to include a pin that is a hibernate or LPDS wake source on the CC3220 in the interface between the two devices. Then I imagine you'll need to build into your protocol a way to specify for the CC3220 that certain operations only require turning on the device to access the file system (to make sure additional power isn't wasted due to a Fast or Auto connect policy when Wi-Fi isn't needed). In general, I think it will really depend on the use-case.

    Best,
    Ben M
  • Hi Ben,

    I plan to connect CC2642R to CC3220R via UART.

    CC3220R will have external serial FLASH.

    Second UART of CC2642R will be connected for external HOST for development purpose and for production line:

     

    HOST <---> [[UART_X] CC2642R [UART_Y]] <---> [[UART_A] CC3220R [FLASH]]

     

    CC2642R is a "Master" that controls all system logics.  CC3220R is "Slave"

    that mainly responsible for Wi-Fi communication.

    In addition I want to utilize serial flash of CC3220R as general purpose storage

     

    Now I am working on system design of software update process and have a several questions.

     

    Use case A:   Update SW of CC2642R and CC3220R from HOST

    Use case B:    Update SW of CC2642R and CC3220R OTA BLE (images are

    received by CC2642R)

    Use case C:    Update SW of CC2642R and CC3220R OTA Wi-Fi (images are

    received by CC3220R)

     

    Q1. Please explain about ROM of CC2642R and CC3220R.

    Q1.1. How ROM is created? Is it binary image that provided by TI or it is created during project building?

    Q1.2  Is ROM can be updated OTA or by UART?

    Q1.3  What is ROM size of CC3220R? It's written in spec that ROM contains "external serial flash bootloader and peripheral drivers". Is Wi-Fi stack also located in ROM?

    Q1.4  What is the ROM content of CC2642R besides BLE stack and bootloader?

    Is TI RTOS located in ROM?

     

    Q2. Software update of CC3220R

    Q2.1. I understand that CC3220R software is always located in serial flash and loaded to RAM after reset. New image is also programmed to flash.

               How bootloader distinguish between "old" and "new" images?

    Q2.2 I plan to get new image by CC2642R (in use cases A and B) or by CC3220R (use case C), program to flash and activate SW update. Is it correct and what should be a trigger to start update?

    Q2.3 What is the flow of SW update operations (find image, load, erase etc....)?

     

    Q3. Software update of CC2642R

    Q3.1 Is it possible to load new image of CC2642R to serial flash of CC3220R and activate bootloader from UART_Y? (CC3220R will read image from flash and send it via UART_A) Q3.1.a  Is such programming can be triggered by "backdoor" GPIO that will be controlled by  CC3220R?

     

    Q4. CC3220R serial flash

    Q4.1 Is part of CC3220R serial flash memory can be used as general purpose storage? Is CC3220R have file system and API for this purpose?

     

    Thanks,

    Shlomi

     

     

  • Hi Shlomi,

    I can answer for the Wi-Fi (CC3220) side of things. See my responses inline below:

    Q1. Please explain about ROM of CC2642R and CC3220R.

    Q1.1. How ROM is created? Is it binary image that provided by TI or it is created during project building?

    ROM by definition is created during manufacturing. The ROM of the CC3220 is most important for having the bootloader as well as the network processor (NWP) stock firmware, which handles all of the Wi-Fi networking from the TCP/IP stack down to the MAC+PHY. The firmware that runs on the NWP side of the CC3220 can be updated through servicepacks provided in the SDK, which contain patches to the ROM firmware. 

    Q1.2  Is ROM can be updated OTA or by UART?

    No, the ROM cannot be updated, but the servicepacks allow selective patches to the NWP firmware. These servicepacks can be updated either through OTA or UART.

    Q1.3  What is ROM size of CC3220R? It's written in spec that ROM contains "external serial flash bootloader and peripheral drivers". Is Wi-Fi stack also located in ROM?

    The ROM size of the CC3220 is not public. The Wi-Fi stack is part of ROM, although it can and has been patched and enhanced using the servicepacks. One implication of this is that you cannot run your own Wi-Fi stack directly on the NWP, since the servicepacks can only be created by TI.

     

    Q2. Software update of CC3220R

    Q2.1. I understand that CC3220R software is always located in serial flash and loaded to RAM after reset. New image is also programmed to flash.

               How bootloader distinguish between "old" and "new" images?

    As part of the OTA process the application writes a bundle of files with the "pending commit" flag set. This bundle includes the main MCU image .bin, and thus when you reset the device the bootloader will see the new MCU image immediately, albeit with the "pending commit" flag set. The key thing is that while the "old" image is not visible in the filesystem as long as the new "pending commit" image is present, it is not overwritten until the new image is committed to the filesystem. See the OTA SimpleLink Academy module for more information.

    Q2.2 I plan to get new image by CC2642R (in use cases A and B) or by CC3220R (use case C), program to flash and activate SW update. Is it correct and what should be a trigger to start update?

    The trigger will depend on how you plan to interact with your product. If your user will interact with the device over the cloud, then waiting for some packet or message from the cloud to trigger the OTA will make sense.

    Q2.3 What is the flow of SW update operations (find image, load, erase etc....)?

    For the CC3220 side of things, we have the cloud_ota example that interacts with the OTA library to perform an OTA update. You should use that example as a reference for the right steps you need to do for OTA. 

    Q4. CC3220R serial flash

    Q4.1 Is part of CC3220R serial flash memory can be used as general purpose storage? Is CC3220R have file system and API for this purpose?

    Yes, the CC3220R external flash can be used as general purpose storage. See the Secure Filesystem SimpleLink Academy module for information on how to use the CC3220 external flash. 

    Regards,
    Michael