CC2340R5: CC2340 ROM Bootloader Erase range

Hi,

From 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:

Then the BLDR_CMD_DOWNLOAD and BLDR_CMD_SEND_DATA may be used to update the relevant flash sectors.

Since BLDR_CMD_CHIP_ERASE always erases CCFG, this sector should be updated after each BLDR_CMD_CHIP_ERASE, making sure to specify which flash sectors should be protected in the next chip erase. Generally the CCFG is always paired with a firmware image, so this should not be considered an extra cost.

Ryan Li said:

It may be possible to export important parameters through UniFlash first, but this is very troublesome. If the company's products have tens of thousands of units that need to be updated today, it is impossible for each unit to use UniFlash to export important parameters first, which will be very inefficient.

Note that UniFlash may use SACI, in which case, refer to TRM section "8.2.4.2 Reprogramming of Previously Programmed Device".

Thanks,
Toby

(1)Are there any practical examples of operation?

(2)Do you mean to set which Flash blocks are not allowed to be erased from Syscfg->Device Configuration->Flash Protection Settings?

If so, assuming I want 0x3E800 to 0x7FFFF not to be erased by the ROM Bootloader, how should I set it?

(3)After the update is completed, CCFG will have a new Value. Do I still need BLDR_CMD_DOWNLOAD and BLDR_CMD_SEND_DATA to update CCFG?

Hi Ryan,

Thanks for investigating it further.

I'll look more into this and provide an update within 3 business days.

Thanks,
Toby

Ryan Li said:

(1)Are there any practical examples of operation?

It would look something like:

1. CC2340R5 blank device
2. Design FW which includes certain flash sections that have info which should not be write/erased, call it FLASH_SECT_PROT
3. CC2340R5 loaded with FW and CCFG which specifies FLASH_SECT_PROT
4. Modify executable FW from 2.
5. Enter ROM SBL
6. Send BLDR_CMD_CHIP_ERASE (now CCFG and non-protected flash sectors are erased)
7. Send BLDR_CMD_DOWNLOAD_CRC to specify where the FW load should start, and how large the FW is (note this MUST NOT touch the FLASH_SECT_PROT), along with the expected CRC of it
8. Send BLDR_CMD_SEND_DATA with the actual bytes of the FW image
9. Prepare the CCFG which has the same write/erase bits as used in 3
10. Send the BLDR_CMD_DOWNLOAD_CRC command passing as input the startAddress=(0x4E020000), length=(2048), CRC=(calc_crc(ccfg_contents))
11. Send BLDR_CMD_SEND_DATA to send the bytes for CCFG
12. Once these steps are successful, then a Reset will allow the device to execute the new FW (from 4) while maintaining the unchanged data originally loaded at 2

Ryan Li said:

(2)Do you mean to set which Flash blocks are not allowed to be erased from Syscfg->Device Configuration->Flash Protection Settings?

If so, assuming I want 0x3E800 to 0x7FFFF not to be erased by the ROM Bootloader, how should I set it?

Correct.

To write/erase protect the range 0x3E800 to 0x7FFFF, first determine the Flash Sectors which intersect it. In this case, it would be sectors 125 - 256.

This is achieved with writeEraseProt.mainSectors32_255 = 0x0FFFF800 (bits 11 - 27 set, according to TRM this will protect sectors 120-255, or address range of 0x3C000 - 0x80000. This is because each bit protect 8 consecutive sectors (bit 11 protects sectors 120 - 127, bit 27 protects sectors 248 - 255 --> bits 11-27 protect sectors 120 - 255). In SysConfig, this would refer to "Main Sectors 32-255".

Ryan Li said:

(3)After the update is completed, CCFG will have a new Value. Do I still need BLDR_CMD_DOWNLOAD and BLDR_CMD_SEND_DATA to update CCFG?

Yes, since CCFG is always erased, it must be loaded again by the ROM SBL (with appropriate protect bits set).

I set it up as you said, but when I updated it using the ROM Bootloader, no data was retained.
This means that all my data after the 120th Sector have been erased after updating.

I changed it to 0xF0000FFF and did a test and found that it did achieve the protection effect. However, this also caused a problem, that is, CC2340 cannot Erase and Write this block during execution. What I want is that CC2340 is executing. Will write data into Flash, but when updating using ROM Bootloader, the data stored in CC2340 during execution cannot be erased.

This means that after setting the protected Sector in Syscfg at the beginning, I cannot Erase/Write, not even NVS_write()/NVS_erase().

Or it should actually be set to "Erase/Retain, Main Sectors 32-255" ? , Because I looked at its description, it uses SC_FLASH_ERASE_CHIP to Erase

But I can't find any relevant information about SC_FLASH_ERASE_CHIP in the TRM file.

Ryan Li said:

I changed it to 0xF0000FFF and did a test and found that it did achieve the protection effect.

Yes, you are correct here -- I mistyped. A "0" bit enables the write/erase protect.

Ryan Li said:

However, this also caused a problem, that is, CC2340 cannot Erase and Write this block during execution. What I want is that CC2340 is executing. Will write data into Flash, but when updating using ROM Bootloader, the data stored in CC2340 during execution cannot be erased.

Yes, this is the intended effect. 

Ryan Li said:

Otherwise, what should I do if there are important parameters in the Flash of CC2340 that disappear due to the update of the ROM Bootloader?

Based on this statement, I had assumed this section was read only. If write is needed, then this method would not work.

Ryan Li said:

Or it should actually be set to "Erase/Retain, Main Sectors 32-255" ? , Because I looked at its description, it uses SC_FLASH_ERASE_CHIP to Erase

But I can't find any relevant information about SC_FLASH_ERASE_CHIP in the TRM file.

I think they short-handed the "SC" part... in full it should be "SACI Command" (Secure-AP Command Interface).
This refers to SACI commands supported (in TRM, section "8.3 Device Management Command Interface ").

For the SACI_CMD_FLASH_ ERASE_CHIP, yes, the "Erase/Retain, Main Sectors 32-255" can be used. This will take effect if the SACI_CMD_FLASH_ ERASE_CHIP command also passes the optional parameter "retainSelMainSectors".

thank you for your reply

This means that the data written by CC2340 during execution can be retained, and by using SACI_CMD_FLASH_ ERASE_CHIP, can the Sector range of written data be protected? If so, after the Syscfg setting is completed, enter the ROM Bootloader mode and execute the SACI_CMD_FLASH_ ERASE_CHIP command on the CC2340?

Yes, if SACI is used, this should work (retain flash sectors while allowing application to modify contents).

In this case it is not ROM Bootloader, but SACI (similar to ROM Bootloader with respect to loading/erasing flash contents, but different in that it uses SWD pins vs serial UART/SPI pins).

So is the operation process of SACI the same as that of ROM Bootloader? First, set the Trigger Pin in Syscfg, then Reset to let CC2340 enter ROM Bootloader mode, and then set SACI_CMD_FLASH_ ERASE_CHIP to Erase CC2340.

I hope there are detailed steps, thank you

In the TRM, please see section "8.3 Device Management Command Interface".

I have checked TRM 8.3, SACI seems to be unable to download update files, so it cannot meet my expected goals.

The section "8.2.4.2 Reprogramming of Previously Programmed Device" shows sequence of using SACI to update the firmware.

Does that meet your expected goals?

SACI seems to be the burning mode I am currently using, through SWCLK, SWDIO, Vcc, GND, Reset
And I hope to be able to update through the Uart pin like the ROM Bootloader, because the product will only have Uart to communicate in the future.

I tried a method, setting the Protection Sector range in Syscfg, and then using NVS_unlock() in Code to unprotect Flash at the necessary time, so that CC2340 can write data to Flash during execution, but the current test Seems unsuccessful, is this a possible approach?

If there is no way, I hope my suggestions can be conveyed to the development departmen

I'll look into this and get back to you within 3 business days.

OK，thanks

Ryan Li said:

I tried a method, setting the Protection Sector range in Syscfg, and then using NVS_unlock() in Code to unprotect Flash at the necessary time, so that CC2340 can write data to Flash during execution, but the current test Seems unsuccessful, is this a possible approach?

NVS_unlock (and NVS_lock) implement an mutex for flash writes, so this does not protect it from chip erase.

Ryan Li said:

And I hope to be able to update through the Uart pin like the ROM Bootloader, because the product will only have Uart to communicate in the future

If only UART is available in final product, then you are right, SACI cannot be used. Also, the ROM bootloader cannot be used, since any flash protection would also prevent future flash writes (e.g. application data).

There is another option to create a custom bootloader, some guidelines for this are detailed in TRM section "8.4.3 User-Defined Bootloader Guidelines".

With this, on device startup the custom bootloader may be entered, and this bootloader could use the Flash APIs to leave alone certain sectors if it wants to perform an erase (e.g. NVSLPF3_erase --> doErase).

For the CC2340R5, neither SACI nor ROM bootloader support sector erase, but only write/erase protection as previously described.

(1)thanks , I understood

(2)In addition to the description in TRM section "8.4.3 User-Defined Bootloader Guidelines", is there any example project for user-defined bootloader?

Hi Ryan,

Are you aware of the mcuboot project?  This is used alongside OAD projects and could be a starting point for your custom bootloader development.

Regards,
Ryan

(1)I have tried to use this project before, but I have been unable to successfully jump to the Application address. Can you provide guidance on how to make the process successfully jump to the Application address and operate normally?

(2)Can mcuboot only be developed with OAD projects? Because I only want to use UART for updates, I don’t need to use wireless methods. If I use basic_ble, can this project be developed with mcuboot?

As far as I'm aware, TI does not make its ROM serial bootloader source solution publicly available.  Although your end goal is not to utilize OAD, the best development path using available TI resources would be to evaluate the basic_ble_oad_onchip project.  That way you can further utilize the CCS Debugger (a BLE5-Stack Debugging Guide is also available) to understand how the mcuboot project starts on device power-up and then jumps into the basic_ble application.  Afterwards, you can remove the OAD portions from the BLE project and add UART functionality to mcuboot.  As an open source project, you may also be able to find additional mcuboot UART-enabled resources from an online search which could possibly be ported to the CC2340R5 device.

Regards,
Ryan

Will TI consider adding a Command to the CC2340 ROM bootloader in the future that allows users to determine the Erase range?