SWCU195A December 2024 – May 2025 CC2744R7-Q1 , CC2745P10-Q1 , CC2745R10-Q1 , CC2745R7-Q1 , CC2755R10
The CCFG.permissions record contains fields that control which types of flash programming operations are allowed:
| CCFG.permissions | Description |
|---|---|
| .allowChipErase | Determines whether the Chip Erase command is allowed. Normally allowed, as otherwise the device cannot be reprogrammed through SACI or ROM serial bootloader |
| .allowMainAppErase | Determines whether the Main App Erase command is allowed. This command does not erase the entire chip. Instead, it will only erase the main flash sectors where the customer application resides. Note: The HSM FW region of the main flash will never be erased by this command. |
| .allowFlashProgram | Determines whether flash programming commands are allowed. Reset to allowed after a chip erase. Normally not allowed to avoid changes to flash through the flash programming interface after initial programming. |
| .allowFlashVerify | Determines whether flash verify commands are allowed. These commands only check integrity against a provided CRC32 value, never return any flash contents. Flash verify commands are always allowed after a chip erase and until the first reset after the CCFG sector has been programmed Normally allowed for checking integrity or identifying the flash image. |
On a blank device or a device otherwise without a valid CCFG, including after a chip erase command, these all default to allowed.
The CCFG.flashprot.writeEraseProt sub-record controls with finer granularity (down to sector or groups of 8 sector level) whether flash programming is allowed through SACI. The same mechanism controls whether the application is allowed to program these sectors. If flash programming operations are done on a blank device or a device otherwise without a valid CCFG, including after a chip erase command, these all default to unrestricted.
The CCFG.flashprot.chipEraseRetain sub-record controls with finer granularity (down to sector or groups of 8 sector level) whether a chip erase affects a sector or not. The mechanism is intended to allow flash sectors devoted to logging or runtime state/configuration to survive the chip erase during a FW update. This retention mechanism is not intended to be bulletproof: a sequence of (chip erase → reset → chip erase) erases both CCFG and non-retained MAIN sectors the first time around and CCFG and all MAIN sectors the second time around.