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: Question about CC2340 ROM Bootloader Erase command (SPI)

Part Number: CC2340R5
Other Parts Discussed in Thread: UNIFLASH, , SYSCONFIG

Tool/software:

Hi TI Support Team,

I am working on protecting important data in flash when using BLDR_CMD_CHIP_ERASE

I enabled the flash protection and do a test.

My Flash Protection Settings are shown in the image below:

Test Scenario:

  1. I enabled flash protection in my application and booted into the ROM bootloader.
  2. A host sent the BLDR_CMD_CHIP_ERASE command to the device and downloaded only the CCFG.

According to the Technical Reference Manual (TRM) section "8.5.3.5 BLDR_CMD_CHIP_ERASE", it seems possible to specify certain flash sectors to retain from a bootloader erase:

This command is used to perform a chip erase of the device. All main flash bank sectors not protected by FCFG and CCFG protect bits are erased. The CCFG is erased once the bank erase has completed. This command first invalidates the CCFG and then begin erasing all unprotected sectors in the main flash bank. Once the flash sectors have been erased, the command finally erases the contents of the CCFG.

Based on my flash protection settings, my application should not have been erased.

However, after running the test, I found that my application was erased.

Could you provide guidance on implementing proper write protection when using BLDR_CMD_CHIP_ERASE?

Thank you for your support.

  • Hi Weiting,

    Please see this similar E2E post.  How are you checking if the area was retained?  You should make sure that the BLDR host does not overwrite whatever area you want to protect (using BLDR_CMD_DOWNLOAD_CRC, BLDR_CMD_SEND_DATA, etc).  To check if the retained feature works:

    1. Performa a complete chip erase (CHIP_ERASE or otherwise).
    2. Flash your CCFG again and check with Uniflash that the area was updated correctly, and save expected flash memory for later comparison.
    3. Perform the BLDR_CMD_CHIP_ERASE only, with no other BLDR commands afterwards.
    4. Reset and check (e.g. with Uniflash) if the expected flash area was retained.

    Regards,
    Ryan

  • Hi Ryan,

    I followed the steps you provide.

            1.Performa a complete chip erase (CHIP_ERASE or otherwise).

            2.Flash your CCFG again and check with Uniflash that the area was updated correctly, and save expected flash memory for later comparison.

    This is the CCFG read from CC2340.

            3.Perform the BLDR_CMD_CHIP_ERASE only, with no other BLDR commands afterwards.

            4.Reset and check (e.g. with Uniflash) if the expected flash area was retained.

    My host executed only the BLDR_CMD_PING and BLDR_CMD_CHIP_ERASE commands.

    Afterward, Uniflash displayed the following error when attempting to read the memory.

    Console log as follows:
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: Debugging is not allowed. If this is not expected, check your CCFG.
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: If you are experiencing issues with loading your application, do the following (this will erase the chip):
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: - Code Composer Studio:
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: - End the current debug session (if any is active).
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: - View -> Target Configurations -> Right click on .ccxml file for your project -> Launch Selected Configuration.
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: - Right click on the 'Debug Probe/Cortex_M0P' and select 'Show all cores'.
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: - Select the 'Debug Probe/CS_DAP0' item after expanding the 'Non Debuggable Devices' item.
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: - Scripts -> CC23xx -> ChipErase to start Chip erase.
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: - You should now be able to load your application to the target.
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: Debugging is not allowed. If this not expected, check your CCFG.
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: Flash loading is currently not supported if debugging is not allowed.
    [2025/2/27 下午2:23:53] [ERROR] Cortex_M0P: Halting at entry of application is not allowed. Are you sure debugging is allowed?
    [2025/2/27 下午2:23:53] [INFO] Cortex_M0P: Running the application, without halting at the entry of the application.
    [2025/2/27 下午2:23:53] [ERROR] Cortex_M0P: Error connecting to the target: (Error -1274 @ 0x0) Error encountered during connect sequence. The specific reason is unknown but may be the result of trying to access a Core or logic that is inaccessible due to a lack of Power, Clocks, or Authentication (i.e. Security is preventing). If blocked by security, and if supported, access may be allowed after following the Authentication process. (Emulation package 20.0.0.3178)
  • Are any Uniflash commands capable of succeeding in this state?  For example, can you recover from this condition when using the Chip Erase feature in Uniflash?  Also, what is returned when you use "Read Device Info" inside the "Settings & Utilities" window?  

    Please provide your Uniflash and SimpleLink SDK version used to build the CCFG image.  Is there a particular SDK example you are using as reference?  Are you using TI_CC2340_Linux_SBL as your host SBL tool?

    Regards,
    Ryan

  • Hi Ryan,

    Can you recover from this condition when using the Chip Erase feature in Uniflash?

    No.
    I found that it always displayed this error when I performed Chip Erase and tried to read the memory in Uniflash.
    Even if I flashed a test code(just print a UART log) before erasing it.

    Also, what is returned when you use "Read Device Info" inside the "Settings & Utilities" window?  

    Please provide your Uniflash and SimpleLink SDK version used to build the CCFG image.


    simplelink_lowpower_f3_sdk_8_10_02_02

    Are you using TI_CC2340_Linux_SBL as your host SBL tool?

    Yes.
    I only executed
    ping() and chipErase().

  • So have you thus been completely disabled from accessing the device through JTAG or the serial bootloader now?

    The setting you are attempting to modify in SysConfig directly affects the CC2340R5 WEPRA/B registers, see section 7.2.4 Flash of the TRM for more details

    "Read-only sectors cannot be erased or programmed, which protects the contents of those blocks from being modified."

    Regards,
    Ryan

  • So have you thus been completely disabled from accessing the device through JTAG or the serial bootloader now?


    I can successfully flash the device using Uniflash or the serial bootloader.

    However, after performing a Chip Erase, I am unable to read the memory in Uniflash regardless of the flash write protection settings.

  • Also from 8.5.3.5 BLDR_CMD_CHIP_ERASE: "The write/erase flash protections applied in the CCFG (see Table 9-3) won’t affect the ROM bootloader. If write/erase flash protection is required, consider implementing a 'User-Defined' Bootloader (see User-Defined Bootloader Guidelines )"

    Thus the Flash Protection Settings primarily affect the SACI.

    Regards,
    Ryan