STM32H7 returns extra byte in Get (device side). What is the extra byte?

Tomasz Zeman · ‎2018-08-19

When querying STM32H7 system bootloader with GET (0x00) command, it responds with:

31-00-01-02-11-21-31-44-63-73-82-92-FF-79

in e.g. STM32F4 series the response was:

31-00-01-02-11-21-31-44-63-73-82-92-79

The AN3155 document does not mention the extra byte or H7 protocol. I am using Rev 7 of AN3155.

What is the FF before the ACK (0x79)? Where can I get the recent protocol document for H7 series?

Khouloud GARSI · ‎2018-09-03

Dear Tomasz,

This command could not be used by the developer (He doesn't need it). However, it's not the root cause of the behavior you're encountering (As you explained, flash Loader Demo program does not allow to update the STM32H753).

Actually, the "Flash Loader Demo" tool was not updated to support STM32H7 MCU. Thus, I advise you to use the "STM32CubeProgrammer" instead. It's a tool for programming the STM32 MCUs that provides an easy-to-use environment for reading, writing and verifying device memory through both the debug (JTAG and SWD) and the bootloader (UART and USB) interfaces.

Regarding application note AN3155, it's now under development to support the STM32H7 devices. We will release it once ready.

Khouloud.

View solution in original post

Khouloud GARSI · ‎2018-08-28

Dear @Tomasz Zeman ,

It's expected to have this extra byte using the STM32H7 devices. However, this is only used for internal validation.

Khouloud.

Tomasz Zeman · ‎2018-08-30

What internal validation is that? Shouldn't this be a command that the bootloader understands?

Khouloud GARSI · ‎2018-08-31

Correct, it's a bootloader command used for internal validation.

Khouloud.

Tomasz Zeman · ‎2018-09-03

Is there any definition for it? What developer can use it for?

Khouloud, I appreciate your time, but you did not answer the core of my question. I do not really care for 0xFF in function list returned by the STM system bootloader.

Saying that I would like to say that the Flash Loader Demo program does not allow to update the STM32H753, most probably because of the 0xFF returned by the bootloader. There are number of other products that terminate or stop working because of the 0xFF.

I do still use the UART1 for board driver-less recovery. Probably could move to USB, if I find descriptors that do not require additional drivers. I take advantage of the FTDI drivers included in Windows at this moment.

I would like to know why AN3155 does not mention the H7 processor. Where is the document that is formalizing this? Will it be published soon?

Khouloud GARSI · ‎2018-09-03

Dear Tomasz,

This command could not be used by the developer (He doesn't need it). However, it's not the root cause of the behavior you're encountering (As you explained, flash Loader Demo program does not allow to update the STM32H753).

Actually, the "Flash Loader Demo" tool was not updated to support STM32H7 MCU. Thus, I advise you to use the "STM32CubeProgrammer" instead. It's a tool for programming the STM32 MCUs that provides an easy-to-use environment for reading, writing and verifying device memory through both the debug (JTAG and SWD) and the bootloader (UART and USB) interfaces.

Regarding application note AN3155, it's now under development to support the STM32H7 devices. We will release it once ready.

Khouloud.

mongisvi · ‎2019-08-02

Dear colleagues,

This topic seems extended in diferent forums and few solutions has been aported. I think I can contribute to solve the issue. I have been doing some testing with the NUCLE-H743ZI (STM32 H7) and the USART1 bootloader. My goal was to update the firmware of the STM32 using UART port. Finnally I manage to do it, but the procedure is a little bit tricky. Moreover, it seems that having the latest versions of software is important:

SOFTWARE USED:

STM32 Cube Programmer 2.1.0

PINOUT

USART1 (PA10, PA9)
FTDI 232 cable was connected to this pins (a COM port is created in the computer)

CONFIGURATION

BOOT0 = High state

Procedure:

0) Connect PA10/PA9 and GND to FTDI cable.

1) Set BOOT0 to High state.

2) Reset STM32.

3) Open STM32 Cube Programmer 2.1.0 (configure as UART connection with FTDI RS232; 115200, EVEN parity)

4) Press connect, you will get the following error (I am using REV Y of the STM32):

11:39:20 : Activating device: OK

11:39:20 : Response received from device: NACK

11:39:20 : Error: GETID command not acknowledged!

11:39:20 : Reemission of GetID command

11:39:20 : Response received from device: NACK

11:39:20 : Error: GETID command not acknowledged!

11:39:20 : Reemission of GetID command

11:39:20 : Response received from device: NACK

11:39:20 : Error: GETID command not acknowledged!

11:39:20 : Chip ID: 0x0

11:39:20 : Response received from device: NACK

11:39:20 : Error: GET command not acknowledged!

11:39:20 : Reemission of Get command

11:39:20 : Error: Read Serial Response timed out.

11:39:20 : BootLoader protocol version: 0.1

11:39:21 : Warning: Device is under Read Out Protection

11:39:21 : Response received from device: NACK

11:39:21 : Error: GETID command not acknowledged!

11:39:21 : Reemission of GetID command

11:39:21 : Response received from device: NACK

11:39:21 : Error: GETID command not acknowledged!

11:39:21 : Reemission of GetID command

11:39:21 : Response received from device: NACK

11:39:21 : Error: GETID command not acknowledged!

5) Close the STM32 Cube Programmer 2.1.0 without doing anything to the STM32 eval (no reset, no FTDI change, nothing...)

6) Open the STM32 Cube Programmer 2.1.0 again and press connect (with same configuration on the UART port)

7) Now the STM32 is recognized and it is possible to erase, read and programm it.

I think there is a bug dureing the connection on the STM32 Cube Programmer that forces to re-init the aplication. IMPORTANT: It seems that flashloader is not compatible with STM32 H7 chips.

Hope that helps.

Victor