cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7 SPI bootloader anomalies ?

ECA
Associate

Hello,

I’m experiencing some difficulties trying to communicate with the embedded bootloader in SPI configuration.

I have two separate Nucleo boards:

-         NUCLEO-H753ZI

-         NUCLEO-H743ZI2

One of them is the master, the over is the slave (order doesn’t matter).

Application Note AN2606 specifies the pinout configuration as follow (p38/426 - Figure 4):0693W00000JP29VQAT.pngWith this configuration, there is no way to get any form of communication from the slave bootloader. I must connect both NSS together and configure it as hardware NSS output signal in master software. It looks like this:

0693W00000JP2AEQA1.pngWith this configuration, slave bootloader is active on SPI interface (data on MISO).

Below is the two boards connection schematic, note that:

-         SPI3 is used both by Master and Slave, Master’s SPI GPIO configuration has been accordingly updated to match default bootloader pinout to avoid any confusion or connection error.

-         SPI clock’s prescaler is set to 256 to get as low frequency as possible. Other parameters are set as specified in Application Note AN2606 (p263/426 – Table 103)

-         Power is transferred from Master to Slave (Slave JP2 set to EXT)

-         Master control Slave’s NRST and BT0 through GPIOs

-         Master’s USART3 is configured to send datas through USB Virtual COM Port (print Master’s status & data)

0693W00000JP2AYQA1.png 

First, I send the RESET and BOOT0 GPIOs accordingly to start the Slave’s bootloader.

Now I send the first three get commands from Application Note 4286 (p8/48):

-         Get (version & supported commands)

-         Get Version (bootloader version)

-         Get ID (chip ID)

The results are a bit odd:

-         Get:

o  The number of bytes to follow returned by bootloader is 0x0D (13), which mean I’m expecting 14 data bytes.

o  Next byte received is 0x11, which mean bootloader version is 1.1, but Application Note 2606 (p34/426 – Table3) says that SPI bootloader protocol version is 1.2

o  Next 11 bytes are commands ID, as expected: 00 01 02 11 21 31 44 63 73 82 92 (in hex)

o  Last 2 bytes are not known commands: A5 A5 (in hex). This value is more likely to be the bootloader dummy byte, as specified in Application Note 2606 (p7/48)

-         Get Version:

o  Returns 0x11 (same as above)

-         Get ID:

o  Returns 0x0450 (1104)

Next, I send the Erase memory command then send data through Write memory command to Slave’s Flash at 0x08000000 address. Data are binary from another sample program which toggle the board’s LEDs from timer or user button B1. The Go command is finally sent, and the program is running fine on Slave board.

I want to visualize the Erase effect, so I call the Read memory command before and after the Erase command. Address is 0x08000000 and size is 256 (0xFF because of minus 1).

I first see the 256 first bytes of my sample program, and after the erase they are all 0xFF.

Then, I loop over all the above commands, each time restarting the Slave’s bootloader to see if the communication is nice and stable. It works well for a long time but at some point, an error occurs while waiting for the Slave’s bootloader ACK or NACK; which is I don’t receive any of these. I reset the Master and try again but the error is still present. I plugged the Saleae on MISO/MOSI/CLK/NSS to check the communication, and surprisingly I see that MISO stops talking for a long period of time before starting again. When this kind of error occurs, the error is at the exact same byte for each following test. Here is a shot of the phenomenon, during Read Memory command:

0693W00000JP2BMQA1.png0693W00000JP2BlQAL.pngHere is a shot of the same function in case it works well:

0693W00000JP2C0QAL.png 0693W00000JP2CKQA1.png 

I did other tests but didn’t saved the Saleae capture. Once, I saw the MISO stalls right after the two bytes FF 00 have been sent.

Finally, I try to check if my sample program is correctly written by comparing the bytes sent and the bytes read. After the Write memory loop, I create a Read memory loop and compare the bytes, starting from address 0x08000000 and reading 256bytes each time.

First three times goes well, but as I go to address 0x08000300, I receive a NACK byte after the address as been sent to bootloader. This happens everytime.

I manually set the first address to be checked as 0x08000300, and expect to immediately receive NACK, but this time, the Read memory command goes well for this address, until the address 0x08000B00 and another NACK.

Issues summary:

-         NSS connection must be connected between Master & Slave ?

-         Bootloader protocol version is 1.1 and not 1.2 ?

-         Get command returns two dummy bytes ?

-         MISO stalls ?

-         Read memory NACK ?

Regards

0 REPLIES 0