STM32F401 - problems with SPI bootloader.

[pasha_anik]

Posted on September 18, 2014 at 18:35

Hello!

Please, help me! 

I want to use SPI-bootloader in STM32F401 to update firmware in this controller.

But controller returns wrong answers.

For my experiments I use demoboard NUCLEO F401RE and application note AN4286 and AN2606.

I use SPI2 with configuration:

Slave mode, Full Duplex, 8-bit MSB, speed 1MHz, Polarity: CPOL Low, CPHA Low, NSS=0. Boot0=1, boot1=0.

After reset I send synchronization Byte 0x5A, but controller doesn't return 0xA5, it return  0x08 to me. I send 0x5A three times and then controller return 0xA5.

After that I send 0x00 and wait for ACK(0x79) or NACK(0x1F), but I have 0x83. Than I send 0x83 to controller many times and after that controller return 0x79.

Is it right?

After synchronization I try to send command (0x5A+0x00+0xFF) and I wait for ACK or NACK, but controller return 0x3C.

Help me, please!

P.S. I try to use UART1 bootloader - it works fine!

#stm32f401-spi

[rowandevries]

Posted on January 29, 2015 at 12:16

Hello,

I just started looking into the SPI bootloader and table 69 of AN2606 suggest the real maximum speed SPI speed is only 100 KHz. You could try and see if this low speed does work

[Christian Frick]

Posted on December 09, 2016 at 12:10

Hi anik.pasha

I'm currently dealing with a similar problem. See 

https://community.st.com/0D50X00009XkYagSAF

 

How did you solve your problem?

Thanks a lot

Christian

[ST Renegade]

Posted on December 09, 2016 at 21:17

The SPI bootloader is kinda tricky and the application note can be a bit misleading. You need to follow the flow chart at the beginning of the SPI bootloader AP note.

After you send a command, you need to ACK the command. So you need to follow the flowchart Figure 2. Get Ack Procedure (master side) where you can see you need to poll the 'slave' for an acknowledge.

After that the read procedure should follow. For reading you should always start with 0x00 dummy. After you receive the data, you should also receive an ACK. This ends the data and you can start over...

So in general it should be:

Sync + Command + CmdChecksum -> poll for ACK -> 0x00 dummy, read bytes until end + read ACK. Bare in mind, once you do something wrong and you end up somewhere in the middle of reading/writing or so, because you thought you have implemented the communication properly and want to start a new command, you will see strange things on the bus, but that's only because the protocol continues with sending data or sending ACK or so... so it appears the bootloader is not working, but it's just not handled properly and this is very confusing.

A scope is a great help in this case. Send a command a see, what is happening on the line and make sure your implementation is really doing all the steps including ACK's.

Hope this helps! Have a nice day,

Renegade

[Christian Frick]

Posted on December 12, 2016 at 15:02

Hi Renegade

Thanks a lot for your response. It helped and I got it to work.

Can you please update the AN? Figure 3 is indeed pretty much misleading and I wasted ways too much time on it! Reading the AN let me understand that we don't have to send a whole command incl. checksum but only ONE byte.

Please change 'Synchronization byte' to 'Synchronization command' in figure 1, insert '0x00 0xFF' between 0x5A and 0x00 in figure 3 and add the information close to figure 3 that it might take several tries until ACK resp. NACK is answered.

Thanks a lot

Christian