cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G473 system bootloader responds with 0xA5 continuously on SPI1

AShel.1
Associate III

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)

10 REPLIES 10
AShel.1
Associate III

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.

I2C4_Clk_PC6_WrongBehavior.PNG

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.

Bootloader_StateMachine_WrongBehavior.PNG

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,