Part Number: CC2642R-Q1
Hello everyone,
I’d like to get expert feedback on whether the following runtime flash-copy approach is **safe and reliable** on the **CC26x2** device family under normal operating conditions (assuming no unexpected reset or power loss).
---
### **Goal**
We aim to copy an updated **BIM image** and **CCFG** region, as well as an updated **certificate block**, from a temporary staging area in flash (`0x34000`) to their final destinations (`0x54000–0x57FFF`), triggered by a **CAN message** during runtime.
---
### **System Context**
- Device: **TI CC26x2** (running TI-RTOS)
- Flash operations performed using TI **Flash API (driverlib)**
- The staging area (`0x34000–0x35FFF`) is written earlier by **OTA update** as a ready-to-run binary image.
- The structure is as follows:
- `0x34000` → Certificate page
- `0x35000` → New BIM + CCFG image
- Final destinations:
- `0x54000` → Certificate (final copy)
- `0x56000` → BIM + CCFG (final copy)
- Write protection is **not** enabled for BIM/CCFG regions during this procedure.
---
### **Code Overview**
This function is triggered at runtime by a CAN message.
It runs successfully so far without errors or unexpected behavior.
```c
uint8_t res = copyBimToFinal(true);
__attribute__((section(".ti_ram_code")))
bool copyBimToFinal(bool isTaskRunning)
{
uint8_t* src = (uint8_t*)0x34000;
uint8_t* dst = (uint8_t*)0x54000;
uint32_t i;
uint32_t dataBuf[32]; // 128-byte buffer
UInt key = Hwi_disable();
if (isTaskRunning)
Task_disable();
// 1. Erase destination pages (including CCFG)
if (FlashSectorErase(0x54000) != FAPI_STATUS_SUCCESS)
return false;
if (FlashSectorErase(0x56000) != FAPI_STATUS_SUCCESS)
return false;
// 2. Copy in 128-byte chunks
for (i = 0; i < 0x4000; i += sizeof(dataBuf))
{
uint32_t j;
for (j = 0; j < sizeof(dataBuf); j++)
{
((uint8_t*)dataBuf)[j] = src[i + j];
}
if (FlashProgram((uint8_t*)dataBuf, (uint32_t)(dst + i), sizeof(dataBuf)) != FAPI_STATUS_SUCCESS)
return false;
}
for (i = 0; i < 100000; i++) {} // Small delay
if (isTaskRunning)
Task_enable();
Hwi_restore(key);
return true;
}
```
The function is placed into RAM using:
```ld
.ti_ram_code : {
*(.ti_ram_code)
} > SRAM
```
---
### **Design Rationale**
Because flash operations on CC26x2 block CPU access to flash memory during erase and program operations, this function is explicitly moved to **RAM** to avoid instruction fetch conflicts.
Additionally:
- **Hwi_disable()** and **Task_disable()** prevent flash access or preemption from other parts of the system during programming.
- All operations are done sequentially (erase → program) in small chunks to minimize memory use.
---
### **Question**
Under these conditions (normal operation, no power failure scenarios), is this approach considered **safe and compliant** with TI’s flash programming requirements?
Specifically:
1. Are there any **hidden risks** with executing this code from RAM during runtime while other tasks are temporarily disabled?
2. Does TI recommend any **additional synchronization** or precautions when performing flash operations from RAM in a multitasking RTOS environment?
3. Is this the **preferred approach** to update BIM and CCFG regions dynamically (without rebooting into a dedicated bootloader context)?
At present, this implementation works perfectly in practice — no crashes, verification failures, or flash corruption observed — but I would like to confirm its correctness and potential limitations from an architectural standpoint.
---
Thank you for any insights, documentation references, or examples you can provide.
Best regards,
**Yusuf Ünlü**
