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.

CC2340R5: ROM Bootloader Default

Part Number: CC2340R5

Hi , members

SDK Version : 7_10_00_35

CCS Version : 12.2.0.00009 

I used the Uart method of the ROM Bootloader to update the Application, but the problem I am currently encountering is that assuming that the RX and TX of my Uart are set in the DIO12 and DIO13 groups respectively today, if the update fails and the CCFG area has been Erase, then The RX and TX of Uart will jump back to the default group of DIO20 and DIO22, but my CC2340 only has 24 Pins, so there will be no DIO20 and DIO22. This situation will cause it to be updated later if it is updated. Unable to update, how do I change the default Uart to DIO12 and DIO13?

  • Hi Ryan,

    Thank you for reaching out.

    The default configuration of the UART bootloader  on CC2340R5 RGE should be configuration 0, i.e. DIO20 for Rx and DIO6 for Tx. These two pins should be available on the RGE package:

    Configuration 2 (using DIO20 and DIO22) cannot be used on your case. Side note, this same configuration is the default configuration for CC2340R5 RKP package.

    In case an incorrect CCFG section is detected at boot time (i.e. blank CCFG, or invalid CRCs), the device will boot in bootloader mode using the default configuration.

    I hope this will help,

    Best regards,

  • OK , thanks

    But Can I change defult configuration? For example, change the default RX and TX to 12 and 13

  • Hi,

    The default configuration is set in ROM, so I am afraid you cannot change it.

    Best regards,

  • OK,
    Or can I check Write/Erase Protection, CCFG Sector in .Syscfg?
    Currently, I have it checked by default, but it will still be erased.
    Or do I need to turn on "Main Sector" and "Write/Retain Main Sector" to truly enable the Protection function?

  • Hi Ryan,

    On the CC23xx devices, the CCFG section is not part if the "Main Sector". This means you cannot protect it the way you have described.

    One option I can think about is to implement a Flash bootloader (invoked instead of the ROM bootloader) so you can disable the possibility to overwrite the CCFG.

    I have reached out to some experts internally (awaiting their feedback) to see which other options can be considered.

    Best regards,

  • OK,
    So I want to know why the Write/Erase Protection CCFG Sector option has been checked in Syscfg, but it is still erased during the ROM Bootloader process. Or is it that the Write/Erase Protection CCFG Sector function is not perfect?

  • Hi Ryan,

    I got the following feedback from the experts.

    The ROM bootloader is designed in a way that requires the CCFG to be erased first in order to download an application to the flash.

    They have also confirmed you should implement a Flash bootloader if you want to enforce a different way of working. 

    So I want to know why the Write/Erase Protection CCFG Sector option has been checked in Syscfg, but it is still erased during the ROM Bootloader process. Or is it that the Write/Erase Protection CCFG Sector function is not perfect?

    Two reasons here:

    • First reason: the ROM bootloader MUST erase the CCFG first in order to load the image
    • Second reason: the CCFG is not part of the sectors that can be protected. Note: the CCFG is always protected during the execution of the application.

    I hope this will help,

    Best regards,

  • OK , thanks

    So this means that if I want to use the ROM Bootloader, I must clear CCFG first, and I cannot Protect CCFG.

  • Hi Ryan,

    So this means that if I want to use the ROM Bootloader, I must clear CCFG first, and I cannot Protect CCFG.

    This is correct understanding.

    Please note that, if you leverage the serial bootloader host example provided here (https://github.com/TexasInstruments/ble_examples/tree/simplelink_low_power_f3_sdk-7.40/tools/TI_CC2340_Linux_SBL), the CCFG and the application are loaded as two separate files.
    This means you can set your serial bootloader host with a "hard coded" CCFG. This way, you reduces the risk of having a change introduced in the CCFG.

    I hope this will help,

    Best regards,