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.