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: Support compared to CC3200

Part Number: CC3220

Hi all,

I'm starting the design of a new Iot device and my intention was to use the CC3200. I found that TI reccomend to use the new CC3220 (I need module version), with the new features etc. My question: is the CC3220 fully supported by software, driver libs, rtos etc???

Two years ago I started to use the CC1310 for a project, and I had got a lot of problems cause many functions like LBT, watchdog, PWM weren't supported by software, they became available only on the latest version of TI RTOS, about 2 years later the chip production. I don't want repeat the same thing with the new design, so can I invest

(as better choice) on the new CC3220 or is better stay on the CC3200 (oldest but probably more software supported)?

Thanks

Riccardo

  • Hi Riccardo,

    I can give you information form my point of view as developer which worked with CC3200 and also CC3220.

    I think decision depends on how big project you want to do. Many things is not possible with old generation. Almost all limitations from previous generation was solved in CC3220. CC3200 have few bad "features" which is not possible solve. In this time make sense use CC3200 for small projects which will not be expected growing in the future.

    - CC3220 is currently fully supported by software, TI-RTOS, etc.
    - Inside CC3220 is less examples than in CC3200 SDK (this will be fixed in next SDK releases)
    - Energia development IDE is not supported by CC3220 yet
    - Code for embedded programming is not available yet (Uniflash need to be used)
    - But for example PDF documentation for CC3220 is much better than CC3200 documentation

    Conclusion: Decision is on you. From my point view not make sense use CC3200 for any new application.

    Jan
  • Hi Jan,

    thanks for your reply. My requirements aren't so important, but they are mandatory for the nature of the project, I list them:

    1) Support for TI RTOS.
    2) Management by TI RTOS about power states, LPDS to reduce power.
    3) Management about access point DTIM / skip beacons features to reduce power (data buffering by access point).
    4) PWM support.
    5) OTA
    6) SSL / HTTPS
    7) Serial bootloader (I'll interface it by an external BLE module that I'll use a backdoor / console port to configuration / low level firmaware programmation.

    All these features are supported by CC3200 from what I could see from the technical documents, is the same situation about CC3220?

    Energia is not mandatory for me 'cause a dedicated platform will be developed.
    What do you mean by embedded programming? Actually is not possible to flash the device using com port / bootloader feature with SOP2 input, or is only a API problem and so I need to use only Uniflash ? This could be a problem 'cause I want use my external BLE module to flash the device if needed, developing a custom flash application running on BLE, and bridging using BLE UART solution.

    Thanks again

    Riccardo
  • Hi,

    Please see my answers:

    1. CC3220 is supported by TI-RTOS. Also CC3220 have on advantage in compaction with CC3200 ( www.ti.com/.../simplelink-mcu-platform.page )
    2. I am not able confirm that power modes are supported by TI-RTOS drives, but I suppose yes.
    3. No problem. CC3220 have even slightly lower power consumption. Power policies of NWP (network processors) was improved.
    4. No problem. But I am not sure if PWM example is available in SDK.
    5. OTA for CC3220 is slightly different than CC3200, but I think is better.
    6. CC3220 supports more secure sockets. CC3200 have slightly obsolete ciphers suite. In the future can be problem connect CC3200 to some secured servers.
    7. Here can be small problem. Documentation how program CC3220 serial flash using bootlaoder from external device is not available yet. But documentation is promised from TI side. I don't know time schedule. For this moment you need use for flashing Uniflash software. But CC3220MOD have available SPI pins from sFlash on package. But I think it could be possible rewrite sFlash directly from your BLE module firmware (without bootloader in CC3220).

    Extra point 8. CC3220MOD versions are not yet at market. Preproduction samples are available. Release is planed very soon.

    Jan
  • Hi Jan,

    thanks for clarification. About CC3200MOD, I can use the launchpad with chip version and after migrate to the MOD version I hope....
    About serial bootloader, SPI from BLE could be a solution, but I hope TI will explain us how interface on the serial com port, my mission is to use BLE module as simple UART bridge without developing more code

    Thanks
    Riccardo
  • Hi,

    Last comment, for CC3200 exist this - processors.wiki.ti.com/.../CC31xx_&_CC32xx_Embedded_Programming_Tool. For CC3220 is expected similar package.

    Jan

  • Thanks Jan,

    only another question : difference between using S and SF version? The internal Flash of SF version replace external ROM? Which are the advantages ?

    I see a difference of price about the launchpads (this is not a problem, it's only to understand if taking the SF version could be a real improve or not), which is your experience with ?

    Thanks!

    Rick
  • Hi Rick,

    No. Flash memory inside SF version is for executing code in application processor. External serial flash is still mandatory for NWP, filesystem, etc.

    In the SF version is code executed from internal 1MB flash (like is common at other MCU) and not from RAM as in CC3200 or CC3220R/S.

    Jan
  • Hi Jan,

    but all right  but I loose the reason to have different versions....I mean, the one with internal flash should be the best choice (all run without external flash chips), or the S version could be more performant cause the code runs into ram?

    At programming level are the same things(ota, bootloader etc )?

    P.s sorry for the questions but I'm trying to make the right choose :)

  • Hi Rick,

    As to be honest, I didn't think about different performance between RAM and Flash execution. Because application processor (Cortex-M4) is running only at 80MHz. I think XIP flash is able feed CPU at this speed without read wait cycles. Tricks like flash accelerators are required for cores at higher execution clocks. But at flash code execution is slightly higher power consumption. With comparison at radio TX it is not important.

    I think reason for more variant is that internal flash is not cheap. For smaller application can be execution from RAM sufficient.

    Yes, other behaviour is same. Only SF version allow you to create bigger application.

    Jan
  • Hi Jan,

    today is a little difficulty understand very well the final code size, however, choosing the S version with a program code bigger then ram size, what happen? Swap on external flash?
    The problem should be that the code steels ram space, limiting for example tcp buffers etc? Is this correct or I'm wrong? Which version are you using and which are your impressions?

    Thanks again

    Rick
  • Hi Rick,

    We use CC3220SF, because our application have big requirements of memory. We started development with previous generation (CC3200), but we found that we will not be able add all required features due to limited resources. Transition from CC3200 to CC3220 was not cruel for us, because we had many experiences with CC3200. For someone without experiences with CC3200 can be start with CC3220 little bit harder due to low number examples in CC3220 SDK.

    When your code not fit into RAM, you cannot execute this code. There is nothing like swap file. Only option can be dynamically loaded part of code, but this is very advanced technique and not easy to use.

    S - you have 256kB RAM: you need fit into RAM your code, variables, buffers, stack heap, etc.
    SF - you have 256kB RAM and 1MB flash: your code is inside flash and you have all RAM for your variables, buffers, stack, heap, etc.

    Jan
  • Hi Jan,

    for more easy develop I'll take the launchpad with SF version. Thank you again for the replies and knowledge sharing!!!

    Have a good day

    Rick