SPI bootloader fails to accept every other command.

[THamb]

I am trying to use the SPI bootloader on a Nucleo F446ZE board and have problems when issuing commands. The symptom is that every other command is not acknowledge and every other works fine. Trying for instance the GET_VERSION command gives the following:

MOSI MISO

0x5A 0xA5

0x01 0xA5

0xFE 0xA5

The second time around it all works fine

MOSI MISO

0x5A 0x79 ---- Start of frame

0x01 0x79 ---- Command

0xFE 0x79 ---- ~Command

0x00 0x79 ---- Ack frame

0x00 0x79

0x79 0x79

0x00 0x79 ---- Dummy read

0x00 0x11 ---- Version

0x00 0x79 ---- Ack frame

0x00 0x79

0x79 0x79

It seems very strange that the command ends fine with a 0x79 but when sending the next 0x5A this returns A5 and no 0x79. I have the same problem with GET and ERASE as well.

By the way: the version returned is 0x11.

[THamb]

It seems as Figure 4. "SPI command frame" in AN4286 is not accurate. The system seems to work fine when ignoring what is returned by the bootloader in the third byte of the command frame. The specification indicates that the bootloader should return 0x79 in this byte, but this does not always happen. The command is accepted and treated correctly anyway.

[TDK]

I’ve used the SPI bootloader commands on the STM32F4 series extensively and never experienced an issue. Maybe your master is sending an extra byte or something? Can you do a scope trace to verify the signal?

[THamb]

Here are the signals from the communication. To the right is a table with the MOSI and MISO sequence. I agree that it seems something is out of sync. T

[TDK]

A more useful trace would be to capture a correctly ACK'd command and the subsequent NACK'd command and see if anything is inserted between the two or if the commands differ in any way.

[THamb]

Here is the sequence with a working command. I cannot manage to get two commands in a row that succeed. I modified the code so that if the bootloader does not respond 0x79 on the third byte in the command I resend the command. The command then work according to the specification, with all responses correct. However sending the command again results in this exact same sequence with a failing response on the third byte. My feeling is that the statemachine in the bootloader somehow comes out of sync with my commands, but cannot figure out why or where.

[TDK]

Okay, you've shown a command that works and one that fails. What happened in between to make it get into a bad state? Use your 10s of logic analyzer buffer and capture everything from start to finish. I can't debug what you aren't showing.

[THamb]

There is absolutely nothing going on. At least nothing that shows up on the logic analyzer. I have run commands back to back (see image and table with communication data), and get the same behavior every time. I have also tried do the ack procedure within the same chip select with no difference, and I have tried adding extra reads in different places but that really trashes the communication.

[TDK]

0xA5 isn't a NACK. The response to 0x5A, 0x01, 0xFE should be ignored. You search for an ACK/NACK afterwards. In fact, the slave is sending an ACK, but you're interpreting it incorrectly. The slave/master finally sync back up when you send a 0x79, which is how the ACK/NACK terminates.