STM32L452 Bootloader (UART) not working via STM32 Programmer CLI

jvieira88 · ‎2024-09-03

Hi,

I'm using a STM32L452 and launching the bootloader in System Memory by setting the Boot0 pin to high and resetting. This launches the bootloader successfully.

I'm using UART1 on PA9 and PA10.

However, when trying to write the flash using the STM32_Programmer_CLI.exe it shows a NACK and the program exits. Here's the command I'm using, see log attached:

"C:\ProgramFiles\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe" -c port=COM11 -w="C:\FW.hex"

Command line output is as follows:

      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.15.0
      -------------------------------------------------------------------

Warning: Wrong connect parameter: -w=C:\FW.hex
Serial Port COM11 is successfully opened.
Port configuration: parity = even, baudrate = 115200, data-bit = 8,
                     stop-bit = 1.0, flow-control = off
Activating device: OK
Board       : --
Chip ID: 0x462
BootLoader protocol version: 3.1

Response received from device: NACK
Device name : STM32L45x/L46x
Flash size  : 512 KBytes (default)
Device type : MCU
Revision ID : --
Device CPU  : Cortex-M4

However, when using STM32CubeProgrammer and selecting UART and the correct COM port, the hex file is successfully written to flash. Here's the verbose 1 output when using STM32CubeProgrammer (full log verbose 3 attached when flashing the MCU as log2.log):

  14:21:51 : Disconnected from device.
  14:21:52 : UR connection mode is defined with the HWrst reset mode
  14:21:52 : RTS low
  14:21:52 : DTR low
  14:21:52 : Serial Port COM11 is successfully opened.
  14:21:52 : Port configuration: parity = even, baudrate = 115200, data-bit = 8,                     stop-bit = 1.0, flow-control = off
  14:21:54 : Activating device: OK
  14:21:54 : Board       : --
  14:21:54 : Chip ID: 0x462 
  14:21:54 : BootLoader protocol version: 3.1
  14:21:54 : Response received from device: NACK
  14:21:57 : UPLOADING OPTION BYTES DATA ...
  14:21:57 :   Bank          : 0x00
  14:21:57 :   Address       : 0x1fff7800
  14:21:57 :   Size          : 36 Bytes
  14:21:57 : UPLOADING ...
  14:21:57 :   Size          : 1024 Bytes
  14:21:57 :   Address       : 0x8000000
  14:21:57 : Read progress:
  14:21:58 : Data read successfully
  14:21:58 : Time elapsed during the read operation is: 00:00:01.426

It seems that the option bytes are written and this might be what's missing. Looking at application note AN2606 I didn't find anything relevant.

There's also a somehow similar case in the forum but the solution is not applicable: https://community.st.com/t5/stm32-mcus-embedded-software/stm32-programmer-cli-bootloader-procedure/td-p/182037

Reading the option bytes via CLI (using option "-ob displ"), this is what I get:

      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.15.0
      -------------------------------------------------------------------

Serial Port COM11 is successfully opened.
Port configuration: parity = even, baudrate = 115200, data-bit = 8,
                     stop-bit = 1.0, flow-control = off
Activating device: OK
Board       : --
Chip ID: 0x462
BootLoader protocol version: 3.1

Response received from device: NACK
Device name : STM32L45x/L46x
Flash size  : 512 KBytes (default)
Device type : MCU
Revision ID : --
Device CPU  : Cortex-M4

UPLOADING OPTION BYTES DATA ...

  Bank          : 0x00
  Address       : 0x1fff7800
  Size          : 36 Bytes

██████████████████████████████████████████████████ 100%


OPTION BYTES BANK: 0

   Read Out Protection:

     RDP          : 0xAA (Level 0, no protection)

   BOR Level:

     BOR_LEV      : 0x0 (BOR Level 0, reset level threshold is around 1.7 V)

   User Configuration:

     IWDG_STOP    : 0x1 (IWDG counter active in stop mode)
     IWDG_STDBY   : 0x1 (IWDG counter active in standby mode)
     WWDG_SW      : 0x1 (Software window watchdog)
     IWDG_SW      : 0x1 (Software independent watchdog)
     nRST_STOP    : 0x1 (No reset generated)
     nRST_STDBY   : 0x1 (No reset generated)
     nRST_SHDW    : 0x1 (No reset generated when entering the Shutdown mode)
     nBOOT1       : 0x1 (Boot from system memory when BOOT0=1)
     SRAM2_PE     : 0x1 (SRAM2 parity check disable)
     SRAM2_RST    : 0x1 (SRAM2 is not erased when a system reset occurs)
     nSWBOOT0     : 0x1 (BOOT0 taken from PH3/BOOT0 pin)
     nBOOT0       : 0x1 (BOOT0 = 0, boot from system memory when nSWBOOT0=1 and main flash is empty,otherwise, boot from main flash memory)

   PCROP Protection:

     PCROP1_STRT  : 0xFFFF  (0x807FFF8)
     PCROP1_END   : 0x0  (0x8000000)
     PCROP_RDP    : 0x1 (PCROP zone is erased when RDP is decreased)

   Write Protection:

     WRP1A_STRT   : 0xFF  (0x807F800)
     WRP1A_END    : 0x0  (0x8000000)
     WRP1B_STRT   : 0xFF  (0x807F800)
     WRP1B_END    : 0x0  (0x8000000)

The option bytes seem to be as expected.

Am I missing something or does anyone know what's happening?

Regards,

Joao

jvieira88 · ‎2024-09-05

OK, so I think I found a workaround, even though I believe there is a bug in the CLI program for this MCU (STM32L452).

I managed to get it working by introducing a read operation before starting to write the firmware file to flash. The GUI version of the tool does a read of 0 bytes at 0x08000000 but with the CLI this doesn't seem to be possible so I'm doing a 1 byte read, this is discarded but seems to do the trick.

Example of complete command:

"C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe" -c port=COM11 -r 0x08000000 1 "test.bin" -w "C:\FW.hex" -v -s 0x08000000

Brief explanation of parameters used:

- c: Connect to COM port.

- r: Read 1 byte at 0x08000000, as explained above.

- w: Write the hex file content to flash memory.

-v: Verify

- s: Start running the application program.

Can someone from ST confirm if this bug is known? Is there a better workaround?

Regards,

Joao

View solution in original post

jvieira88 · ‎2024-09-05

So I started monitoring the data exchange over serial between the board and the CubeProgrammer (GUI and CLI). I also had a look at the bootloader command set (application note AN3155 Rev 18) to make some sense about what's the difference between these two tools. I've also updated to STM32CubeProgrammer v2.17.0 (latest) but still no success.

I'll focus on the main differences that I found:

On the CLI side, there's not even an attempt to write any data (cmd 0x31).

On the GUI side, there's a periodic Read Chip ID exchange (cmd 0x02, presumably to check that the board is still present). There's also an operation that reads 1024 bytes starting at 0x08000000, presumably to populate the GUI after the connecting is established. There are also some read operations of size 0 bytes starting at 0x08000000. I don't think that these things are relevant for this problem anyways. However, before starting the write operation, an Extended Erase command is sent (cmd 0x44), but the data followed doesn't seem to make much sense to me:

002380: 2024-09-05 11:12:19.9858618 +0.0018714

 44 BB                                             D»
002394: 2024-09-05 11:12:20.0000851 +0.0000259

 00 1F 00 00 00 01 00 02 00 03 00 04 00 05 00 06   ................
 00 07 00 08 00 09 00 0A 00 0B 00 0C 00 0D 00 0E   ................
 00 0F 00 10 00 11 00 12 00 13 00 14 00 15 00 16   ................
 00 17 00 18 00 19 00 1A 00 1B 00 1C 00 1D 00 1E   ................
 00                                                ...

For reference, this is what the application note mentions:

After sending this extended erase command, the CubeProgrammer GUI starts the write operations (cmd 0x31) until completion.

Can anyone confirm if this is a bug on the CLI program? Why the need for the extended erase command? And if the extended erase command is needed, what is the data that should follow and which option to use in the CLI?

Regards,

Joao

jvieira88 · ‎2024-09-05

OK, so I think I found a workaround, even though I believe there is a bug in the CLI program for this MCU (STM32L452).

I managed to get it working by introducing a read operation before starting to write the firmware file to flash. The GUI version of the tool does a read of 0 bytes at 0x08000000 but with the CLI this doesn't seem to be possible so I'm doing a 1 byte read, this is discarded but seems to do the trick.

Example of complete command:

"C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe" -c port=COM11 -r 0x08000000 1 "test.bin" -w "C:\FW.hex" -v -s 0x08000000

Brief explanation of parameters used:

- c: Connect to COM port.

- r: Read 1 byte at 0x08000000, as explained above.

- w: Write the hex file content to flash memory.

-v: Verify

- s: Start running the application program.

Can someone from ST confirm if this bug is known? Is there a better workaround?

Regards,

Joao