Skip to main content
Graduate
December 30, 2024
Solved

STM32G030C8T6 devices don't run after flashing them for the first time

  • December 30, 2024
  • 2 replies
  • 977 views

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?

    This topic has been closed for replies.
    Best answer by waclawek.jan

    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

     

    2 replies

    Super User
    December 30, 2024

    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

     

    GastonAuthor
    Graduate
    December 30, 2024

    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.

    Super User
    December 30, 2024

    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