I am evaluating using SPI and ST's internal System Bootloader for a 2 processor application.
To that end, I am attempting to attempt to read in the bootloader via SPI on an STLink V3.
I am successfully able to do so for a NUCLEO-L496ZG, but fails for a NUCLEO-U575ZI-Q.
This is what the traces look like on the Oscilloscope. Yellow is the MISO line.
What it isn't:
- It is not an issue with going into boot mode. I pull Boot0 pin via jumper and press the reset button to put it in boot mode. I am able to verify that it is in boot mode, as I check whether STLink V3 can connect via I2C. It can. I also reset in between connection attempts, as I am aware the bootloader turns off other peripherals when a connection is established.
- It is not an issue with the hardware/pins. I used the same Nucleoboard with the same pins in the U575 SPI Slave example. I configured another U575 to be the master. I even modified the Slave example to configure those pins (PA5, PA6, PA7) to be in pulldown mode, like AN2606 claims the bootloader configures the pins in. The example works fine, messages are received successfully on both sides, and I have seen strong healthy traces on the MISO line, unlike when the STLinkV3 talks to the internal bootloader (pictured above).
- It is not an issue with the connection setup. As I mentioned earlier, I tested with a Nucleo-L496ZG on the same pins and it works fine. In both cases, I connect PA4 to GND.
I am left with one possible conclusion: That there is an error in the SPI configuration in ST's system bootloader. Can anyone verify if they have successfully tried using the System bootloader on an STM32U575 in SPI mode?
Thanks
The trace shows two bytes, not enough for a sync frame. Can you show the full sequence? Would be better if you controlled NSS as well, showing the full 4-byte sequence.
Edit: Eh, I guess it should transmit 0xA5 on the first byte regardless.
