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.

CC2650: ROM Bootloader takes several resets to respond to sync bytes

Part Number: CC2650

Hello

Trying to initiate communication with the CC2650 ROM bootloader (from a MSP432P4111 host MCU) on our custom board is proving challenging. The two (0x55) sync bytes are not acknowledged until the device is reset several times (at least 5 or 6). We've checked the supplies and can't see a problem. Resetting the host MCU via the debugger has no effect.

Any thoughts are appreciated!

Regards

Meenal

  • Hi Meenal,

    In your case, is the device you try to communicate with a "clean" device or is there an existing image on it? If the later, what is the CCFG settings of the project loaded to the device? Have you tried to scope the lines to verify the integrity of the communication?

  • Hi M-W

    This was the first ever attempt to load an image on to the device. Thanks for the advice - we will check the UART comms lines.

    Kind regards,

    Meenal

  • Hi M-W

    We've checked the UART lines and they're clean. With the auto-bauding feature it's hard to understand why this issue might occur. Any other ideas?

  • Hi Meenal,

    It is possible that the baudrate detection could fail (no ACK) and in this case you would need to re-try the synchronization (you should not need to reset the device though). What is the baudrate used in your case? 

  • Hi M-W,

    We did try to sync multiple times. We found that it either syncs up the first time or it never does (until a reset).

    Baud rate is 115200. 

    Thanks,

    Meenal

  • Hi Meenal,

    I can't see any good reason for this behavior when it comes to the actual hardware IP. The only thing that comes to mind is the configuration of the serial interface which happens during boot up of the device. You can read more about this in the Technical Reference Manual at chapter 8.2.2 but in short, the bootloader will select between the UART 0or SSI0 interface depending on which port is getting "accessed" first by the external device.

    When the selection is done, the other interface (UART0 or SSI0) is disabled. This would mean that in case something is causing "communication" on the SSI0 TX pin before you do so on the UART0 pins, the device would lock to SSI0 mode and require a reset to perform the selection again. 

    I recommend you look into if you might be using the SSI0 interface pins in your design and if there is anything going on here during boot-up.