• Resolved

CC2650: Dual-chip MSP432+CC2640/CC2650 best practices

Part Number: CC2650

There are several messages on these forums about the relative lack of flash space (128 KB) on CC2640, CC2650 and related parts. TI's recommended "workaround" seems to be a second MSP432 microcontroller next to the CC2640 chip, running the main application code, while only strictly BLE-related things run on CC2640.

I have extensive experience with Nordic nRF51822 and nRF52832, but not with other BLE solutions. The Nordic parts, especially nRF52832, have enough flash that it is not necessary to have two chips, although Nordic does have a solution for that (softdevice serialization).

I'm wondering if there are any detailed application notes, reference designs or tips about the dual-chip solution. Some questions that immediately come to mind:

Is it reasonable to run the MSP432 from the 48 MHz RC oscillator, to save a crystal? I'm assuming CC2640 needs a high-frequency crystal in any case for RF. Or would you normally have a second high-frequency crystal for the MSP432? Or have a clock output from CC2640, if that's possible?

Nordic-based designs usually have a 32.768 kHz crystal for more precise timing between BLE events, which can reduce power consumption. I assume that's also appropriate on the CC2640 side. But in the dual-chip solution, which chip manages the sleep and timers in between BLE events, for example to wake up between advertising events? Would it be reasonable to have a 32.768 kHz crystal on the CC2640 side, but rely on the VLO low-power low-frequency internal oscillator on the MSP432 side, which may not have a need for very accurate timing during sleep?

In a dual-chip design, would you normally treat the CC2640 as a "dumb" BLE chip (like the erstwhile nRF8001) and not run anything or have any peripherals connected to it at all? And so forgo the advantages of the ultralow-power sensor controller, for example?

  • Hi Guan,

    We do have SW references for running the CC2640 as a network processor and the MSP432 as an application processor. There are no specific HW reference for connecting these, but I will address your questions later.

    First I would say that in most cases available flash for your application is not a problem with the CC2640. We have further improved the amount of available flash by putting more BLE Stack SW in ROM on the CC2640R2F. On this device, a typical Peripheral application will have more than 80 kB free  flash. I would highly recommend you to evaluate the CC2640R2F before looking into a two-chip solution.

    Guan Yang74
    Is it reasonable to run the MSP432 from the 48 MHz RC oscillator, to save a crystal? I'm assuming CC2640 needs a high-frequency crystal in any case for RF. Or would you normally have a second high-frequency crystal for the MSP432? Or have a clock output from CC2640, if that's possible?

    Yes, the CC2640 requires a 24 MHz crystal for the RF. Whether to use a crystal or RC oscillator for the MSP432 would depend on the clock accuracy requirement for the application (PWM for example). There is no built-in support in the CC2640 to output a high frequency clock signal, although the timers could be used up to a few MHz.

    Guan Yang74
    Nordic-based designs usually have a 32.768 kHz crystal for more precise timing between BLE events, which can reduce power consumption. I assume that's also appropriate on the CC2640 side. But in the dual-chip solution, which chip manages the sleep and timers in between BLE events, for example to wake up between advertising events? Would it be reasonable to have a 32.768 kHz crystal on the CC2640 side, but rely on the VLO low-power low-frequency internal oscillator on the MSP432 side, which may not have a need for very accurate timing during sleep?

    The CC2640 would have to handle the BLE interval timing itself. This can be done by using the 32k crystal oscillator or the internal 32k RC oscillator (the former is more accurate and will give lowest power consumption). The CC2640 also accepts externally generated 32k clock signals, and it can output the 32k clock. As such it does not really matter where the clock is generated.

    Guan Yang74
    In a dual-chip design, would you normally treat the CC2640 as a "dumb" BLE chip (like the erstwhile nRF8001) and not run anything or have any peripherals connected to it at all? And so forgo the advantages of the ultralow-power sensor controller, for example?

    It depends. In our two-chip example the CC2640 is a network processor running the whole BLE stack, but nothing else. It does not have to be like that though, you can run application SW on the CC2640 also, but then you would have to implement the protocol to exchange data from the external processor yourself using one of our example projects as starting point. 

    Regards,
    Fredrik

    --
    PS. Thank you for clicking  Verify Answer below if this answered your question!

  • In reply to Fredrik K:

    Thank you for your answers, this all makes sense.

    One followup: TI's HomeKit solution requires an MSP432 and will not fit in CC2640, correct?
  • In reply to Guan Yang74:

    Hi Guan,

    That is correct. Our current HomeKit offering is based on a two-chip solution with MSP432 and CC2640.

    Regards,
    Fredrik

    --
    PS. Thank you for clicking  Verify Answer below if this answered your question!