STM32G473 system bootloader responds with 0xA5 continuously on SPI1

[AShel.1]

Hello,

I've two STM32G473 controllers connected on SPI3 and SPI5 of main controller (STM32H753).

1. STM32G473 - Boot, Chip Select and Reset pins are controlled through the I/O pins of STM32H753, SPI5 of H753 is used to interface G473 on SPI1(as per note AN2606). This controllers works ok and I'm able to update the firmware of it through host H753.

2. STM32G473 - Boot, Chip Select and Power(VDD) is controlled through I/O pin on H753. SPI3 of H753 is used to interface G473 on SPI1(as per AN2606). This controller always sends 0xA5 on the MISO line. 

Things I've tried,

1. Verified the option bytes of both controllers and they are identical

2. Tried to send sync byte multiple times and receive the ACK

what could be the reason that it is not sending the ACK byte(0x79)

[TDK]

So the difference between the two is that SPI5 is used on one and SPI3 on the other? Has to be misconfigured or not connected how you think it is then. The STM32G473 doesn't know where the signal is coming from.

Hard to tell what's going on in your scope plots. Perhaps show transactions with only 4 bytes, per the sync frame requirement.

Note that the ACK procedure requires you to send a dummy byte. If you only send 0xA5, it'll only come back with 0x5A.

 

[AShel.1]

Hello,

As per the AN4286, master needs to send 0x5A sync byte to initiate the communication and in response slave sends 0xA5 then master needs to keep sending dummy byte 0x00 and read the byte on MISO line this loop will be until slave responds with 0x79 ACK byte. I’m following same sequence for both controllers. In the scope capture named STM32G473_Working.png you can see the 0x79 is received at the end and in STM32G473_NotWorking.png it only sends 0xA5.

 

Thanks,

 

[TDK]

In the "working" example, you don't just send 0x5A. The byte circled in green is clearly different.

Regardless, if you only send 0xA5, which is what you say you are doing, the slave will only respond with 0x5A, which is what you say you are seeing. That is the expected behavior.

In your "not working" picture, it looks like the red trace is always 0 so it's only sending 0x00, but you're saying it's sending 0x5A, so maybe I'm missing something.

[AShel.1]

In the working example capture the 0x5A is not seen but I'm sending it, its the same for both controller, here I send 0x5A from H753 on MOSI and Slave sub controller sends 0xA5 on MISO. this sequence is same for both controller and observed same frame on DSO for both controllers.

Yellow-ChipSelect, Blue -Clock, Red-MOSI(0x5A), GREEN-MISO(0xA5)

then H753 sends 0x00 as dummy byte and reads MISO line.

on one slave I read 0xA5 for 17 or 18 attempt and then gets 0x79 ACK byte, this ACK is transferred on MOSI as per the diagram mentioned in AN4286

MOSI - 0x00(Dummy), MISO-0xA5 then 0x79

for second controller:  H753 sends 0x00 as dummy byte and reads MISO line, I keep sending the dummy byte as 0x00 and read MISO line, here the data on MISO line is 0xA5, I tried to run the loop for 100, 1000 times but always the data on MISO is 0xA5.

MOSI-0x00(dummy), MISO-0xA5

I see one similar thread but this person got ACK byte after 40th Attempt,

https://community.st.com/t5/stm32-mcus-embedded-software/spi-bootloader-synchronization-issue/td-p/122797

I'm following this sequence from AN4286 Bootloader SPI synchronization frame sequence,

[TDK]

Follow the flowchart in AN4286 to get an ACK. Note that this doesn't say to send 0x00 forever. It's a 3 byte sequence and you read the second byte to determine ACK/NACK.

 

Send 0x00 dummy 0x79

Receive dummy DATA dummy

Is DATA = 0x79? Then ACK. If 0x1F then NACK. If else, then it's not in the SPI bootloader at all.

 

Also consider using a CS pin for byte synchronization, although it's not technically required.

[AShel.1]

I followed the sequence mentioned in Figure 2 of AN4286 also, please note that this sequence is working for one slave. 

on this comment:

Is DATA = 0x79? Then ACK. If 0x1F then NACK. If else, then it's not in the SPI bootloader at all.

-- if its not in Bootloader then how come I see 0xA5 on MISO which is mentioned in figure 3 of AN4286. 

Many of the people reported they have not received the ACK byte always as third byte as mentioned in AN4286. 

 

[TDK]

> if its not in Bootloader then how come I see 0xA5 on MISO which is mentioned in figure 3 of AN4286. 

You are not following the 3-byte ACK/NACK scheme described in AN4286. Attaching meaning to whatever you're reading out is misguided. My statements don't apply to your transaction because you're not following the scheme.

Follow AN4286 exactly.

> Many of the people reported they have not received the ACK byte always as third byte as mentioned in AN4286. 

Let's stick to the problem at hand. Other people have different setups and different code. It may or may not be relevant here.

[AShel.1]

I've followed exactly the same sequence as mentioned in AN4286 which is working fine on one controller (STM32g473) and not on the other (STM32G473) and I'm looking here if I get some help to trace out the root cause.

Can ST add some troubleshooting notes in the ANxxxx documents which will help developers to resolve some basic issues.

[Jacob WOODRUFF]

Hi All,

This question has been routed to our online support center for direct support from our team. 

Regards,

Jake

ST Support

[AShel.1]

Hello,

we could rectify the problem, the bootloader sequence is not working properly.

we've used PC6 as an analog input in our custom board (while bootloader is running this pin is not connected to any analog signal, the level remains 0V) - in bootloader this is clock pin for I2C4.

as per bootloader sequence mentioned in 42.2 section in AN2606, the system bootloader will enter into I2C loop and disable all other interrupts only if the I2C address is detected else it should check for SPI sync signal.

as we're not sending and data, clock signals on I2C4 then it should move to SPI and listen to sync byte which we're continuously sending. also what surprises is it remains in I2C loop and still responds with 0xA5 on SPI which was confusing to me. after isolating the PC6 pin we could program the MCU on SPI interface.

this may be a defect in bootloader sequence.

thanks,