2024-12-30 03:34 AM
I have some STM32G030C8T6 custom boards with the same problem. After flashing them for the first time through SWD using STLINK probe the devices are stopped. STM32CubeIDE debug session is aborted and I cannot launch any debug session anymore.
The workaround is simple. Just switch off and on the power supply and everything is fixed! I have no more problems and I can flash the MCU as expected. Why? How can avoid this behavior when flashing the MCU for the first time?
Solved! Go to Solution.
2024-12-30 07:26 AM - edited 2024-12-30 07:28 AM
Unless you simultaneously lock the device (setting RDP level higher than 0), this is due to the remap of memory at 0x0000'0000 when an unprogrammed device is reset (upon first powerup).
One way to cope with it is to perform an OBL_LAUNCH after programming, if your programming setup is capable of this. If not, the power cycle is a sure bet.
JW
2024-12-30 07:26 AM - edited 2024-12-30 07:28 AM
Unless you simultaneously lock the device (setting RDP level higher than 0), this is due to the remap of memory at 0x0000'0000 when an unprogrammed device is reset (upon first powerup).
One way to cope with it is to perform an OBL_LAUNCH after programming, if your programming setup is capable of this. If not, the power cycle is a sure bet.
JW
2024-12-30 08:13 AM
Thank you. Now I understand the behavior. For me it is okay and not a problem because this is what I wanted. At the end I need to implement a mechanism for booting through USART on an unprogrammed device (using the ST Embedded Boot). Then program the device with a custom application.
2024-12-30 09:09 AM
I'm not familiar with programming using the bootloader (UART or any other protocol) so I'm not sure how to avoid the above problem. IIRC the bootloader allows to run the programmed code, but I don't know if it also maps back the user FLASH to 0x0000'0000 at that moment, and if not, your code should account for the remap.
JW