For the device that supports a BSL, and the BSL is
set as enabled (default enabled), use the hardware invoke method to force the MCU to enter
BSL mode. The MCU then executes the BSL code in the ROM and does not execute the application
code. The device remains connected to the SEC_AP and CS_DAP cores in BSL mode.
Note: When the MCU enters BSL mode, users
cannot connect to the Arm® Cortex®-M33 core because the BSL is not debuggable by default.
But users can still send a DSSM command as the CS_DAP core is available for
connection.
In BSL mode, users can send a BSL command as
Section 8.2.2, or send a DSSM command asSection 8.2.3 to recover the device. This approach
help users unlock the device if a software issue causes the MCU to enter a locked state.
The following lists the recommended methods to force the MCU to enter BSL
mode:
- Connect the BSL invoke pin (the default is PA18)
to the VCC (with or without pullup resistor). Re-power the device.
- Connect the BSL invoke pin (the default is PA18)
to the VCC (with or without pullup resistor). Force NRST low for more than 1s to trigger a
POR.
Note: When the MCU enters BSL mode, the MCU enters STANDBY0 mode if the BSL
connection command is not sent to a UART, I2C or CAN interface within 10s.
The approach is not viable in the following situations:
- The NONMAIN configuration has CRC check
failure.
- The NONMAIN configuration disables the SWD interface or locks the debug
access.
- IWDT is enabled through the device supporting the
VBAT feature, requiring users to manually turn off the VBAT to disable the IWDT.
- The BSL hardware invoke method is disabled.