STM32L496 SPI Bootloader fails to synchronize

[chaup]

I have been working on a project that intends to utilize the SPI ST bootloader to load code to a board. Using a Nucleo-H723ZG and Nucleo-G0B1RE dev boards, I made a driver to interface with the ST bootloader over SPI and was successfully able to get it to work. The actual project is intended to work with STML47s and STML49s, so the next step was getting a Nucleo-L476RG and after a little tweaking, I was able to get the driver working with this dev board. Finally, I'm now trying to get the driver to work with a Nucleo-L496ZG and for the life of me I can't get it to work. I'm pretty confident in the driver that I have made as it works with both the L476 and G0B1 Nucleo boards and the specific error I'm running into doesn't feel like an issue with my code.

The specifics of what I'm seeing on the L496 is that the SPI protocol will never complete the synchronization sequence. No matter what I do, the L496 always sends 0xA5. I've tried increasing the amount of time that I wait for the 0x79 ACK byte, I've tried both SPI1 and SPI2 on the L496, verified that the SPI pins work with a simple test program, double checked the L476 and G0B1 work as a sanity check, changed the speed that the SPI is running at, and verified the bootloader is working by using the STM32CubeProgrammer to flash a program through the USB bootloader protocol all to no avail. I'm hoping its just that I've been working on this too long and its something obvious I'm missing, but am at the point where I'm skeptical the Bootloader SPI protocol works on the L496 series at all. 

The H7 I have configured to use SPI1 at 1.25MHz using PB4 as the MISO, PB5 as the MOSI, and PB3 as the SCK.

The L496 I have currently connected to SPI2 through MOSI on PB15, MISO on PB14, SCK on PB13, and NSS disconnected (though I have tried with it grounded). As previously mentioned, I also tried SPI1 with MOSI on PA7, MISO on PA6, and SCK on PA5.

[TDK]

It would be best to control the NSS line to allow for master and slave to sync up.

Probably something that could be resolved by putting a logic analyzer on the lines to see what is happening.

Is this what you're doing to read ACK? Show some code.

[chaup]

Here are a couple of pics from a logic analyzer: 

I tried hooking up the NSS line but found the logic analyzer was getting a bit of noise on the line, causing de-sync. Not sure if this is an issue with my setup, so I'll try again tomorrow. Regardless, correct me if I'm wrong, but the NSS line should be optional. Won't the SPI transaction sync on the rising edge of the first clock pulse?

As fir a code snippet, a lot of it is wrapped in classes, but it looks like this:

[chaup]

Got the logic analyzer working with the NSS line and did 2 further tests. The first was just dropping the NSS at the start of the init:

The second was per transaction attempt: 

Neither seems to have changed anything.

[TDK]

Not real sure, looks like you're doing the right things.

You're getting 0xA5, so the SPI slave is active and transmitting. Slave is acting as if it doesn't see the 0x5A.

If another peripheral is active, it might be jumping there instead. Seems unlikely.

Perhaps MOSI isn't hooked up as expected. You could try initialized PB15 as an output and toggling and verify on the scope that it changes. Seems unlikely too. PB15 is hooked up by default and doesn't have any relevant solder bridges.

That's all I got. I don't have an STM32L4 to test. Good luck.

[chaup · Accepted solution]

After some more testing, I believe that the issue is that the L496 dev board is connecting to another peripheral. I found that I can always connect to the USB protocol, but I could occasionally connect to the UART one. After some more playing around, figured out that the window to connect to the UART protocol was immediately after startup of the dev board. Trying the same thing with the SPI protocol and I found that I was finally able to connect to it if it was immediately on startup. My assumption is that for some reason the USB protocol is always being initialized on startup for some reason. Thankfully, I can work around it at least.