Hi,
I am using the ROM_PageErase() and ROM_ProgramFlash() functions from the CC2538 ROM Utility Function Library to perform on-the-air firmware update. For normal flash pages, this works fine, but for the lock bit / CCA page, ROM_PageErase() returns -1, which is probably caused by an abort (i.e. FLASH_CTRL_FCTL.ABORT = 1). This function seems to set FLASH_CTRL_FCTL.UPPER_PAGE_ACCESS to 1 as expected, so this issue should not be a normal lock blocking of the CCA page.
Note that the original firmware calling the ROM functions to perform the firmware update has its debug lock bit asserted (i.e. CCA.LOCK_DEBUG_N = 0). Hence, I suspect a silicon bug in the flash controller considering CCA.LOCK_DEBUG_N both as the debug lock bit and as the lock bit for page 255 (i.e. lock bit / CCA page). If this is the case, a CC2538 with debug locked (which is very important for confidentiality of firmware + data in flash) has no way of writing to its CCA page, so this page is wasted both because the firmware cannot write application configuration information to the free words of this page, and because a trampoline solution has to be implemented with a temporary vector table for on-the-air firmware update.
If the debug lock bit is not the cause of this issue, the only other explanation that I see right now is that the address to write to FLASH_CTRL_FADDR for the lock bit / CCA page should be page-relative rather than flash-relative because FLASH_CTRL_FCTL.UPPER_PAGE_ACCESS = 1, in which case there is a bug in the ROM flash functions. I am wondering this because of the following sentence in section '8.5 Flash Page Erase' in the CC2538 User's Guide: 'If an information page is to be erased, the offset address from the information page base address must be written.'. The lock bit / CCA page is a flash page (not an 'info page'), so this sentence should normally not apply for it, but maybe it is not correctly formulated.
I very urgently need an answer to this. I will perform further tests on Monday morning to pinpoint the cause of this issue, but if TI employees could confirm or refute my hypotheses above in the meantime, that would be great.
Thanks in advance.
Best regards,
Benoît
