26.5.6 Security Bit and Chip Erase Hard Lock Bit

The security bit allows the entire chip to be locked from external access for code security. The security bit can be written by a dedicated command, Set Security Bit (SSB). Once set, the only way to clear the security bit is through a debugger Chip Erase command. After issuing the SSB command, the STATUS.PROGE error bit can be checked.

In order to increase the security level it is recommended to enable the internal BODVDD when the security bit is set.

The CEHL bit allows to permanently disable the debugger chip erase feature. It can be written by a dedicated command, Set Chip Erase Hard Lock (SCEHL). CEHL can only be set after the Security Bit has been set. This is a permanent fuse, meaning that once it is set, it is set forever and cannot be reset anymore, therefore removing any possibility to perform a chip erase, reprogram or debug the chip.

The four possible combinations of both bits and their implications are described as follows:

Security Bit = 0 and CEHL = 0:

  • Full debugger access is allowed
  • If a boot section has been defined in the user row BOOTPROT bit field, then this section is write and erase protected (from the debugger and from the application code running on the target). Note that changes to BOOTPROT are only taken into account after the next reset. Consequently, if a boot code was previously programmed and secured with a BOOTPROT value, then in order to reprogram it and secure it again, the user shall:
    • Disable the boot section protection(BOOTPROT = 0xF) and reset the potentially related region lock bit(s)
    • Reset the chip for the new BOOTPROT value to be taken into account
    • Reprogram the boot section, protect it again by setting BOOTPROT to the appropriate value depending on the boot code size
    • Reset again
  • The application code (outside of the boot section) can be reprogrammed
  • A debugger chip erase is possible. It will erase the main array (even the potentially protected boot section), the Data Flash, the volatile memory, and the Security Bit.
    Note: The user row containing BOOTPROT is not reset by a debugger chip erase.

Security Bit = 0 and CEHL = 1: this combination is not possible, CEHL cannot be set when Security Bit=0. (This will result in STATUS.PROGE being set)

Security Bit = 1 and CEHL = 0:

  • Once Security Bit is set, the only way to clear it is through a debugger chip erase
  • The debug access and actions are restricted in this mode (For more information, refer to the DSU Intellectual Property Protection chapter and table 13-6):
    • The debugger chip erase is possible
    • The debugger is not allowed to read and dump the code and data contained in the Flash memory
    • Programming (write/erase) of the Flash (boot code, application code, Data Flash section, auxiliary rows (in particular BOOTPROT in the user row)) is not allowed. It will only be possible after a debugger chip erase, when Security Bit is back to 0.
  • The boot and application codes running on the target have full read/write/erase access to the main array, Data Flash section and user and auxiliary rows, except if a boot section is defined with BOOTPROT, in which case, the boot section becomes write/erase protected from the boot code itself and from the application code.

Security Bit = 1 and CEHL = 1:

  • Once CEHL is set, it is not possible to reset it. This is a permanent fuse. The part is locked forever and there is no way to come back.
  • The same as above still applies, except that chip erase functionality is disabled forever
  • CEHL status is visible in DSU STATUS2:CEHL

Defining a protected boot section, setting the Security Bit and the CEHL bit allows for a global secure boot solution with an immutable boot loader section. The boot loader may for example embed public keys or certificates for supporting secure boot loading algorithms or secure update of the main application code.