cancel
Showing results for 
Search instead for 
Did you mean: 

No ACK received form SPI Bootloader

cblackburn
Associate II

NB: To view the kvdat files I have attached as part of this post use the KingstVIS Logic Analyser software. Freely availible from https://www.qdkingst.com/en/download . You will also need to decompress them using XZ and Tar

Hi All,

I'm trying to get a bootloader working over SPI to program an STM32WB55. I've been making some good progress with getting the bootloader up and running and I've been able to do some proofs of concepts to make sure that it's working. I have attached Logic Analyser traces of the "Good" behaviour as SPI Bootloader Good.kvdat . This probes the device and reads/writes some locations in SRAM without issue. So, I know I have the fundamental protocol working.

However, when I try to erase the flash the device never returns an ACK to me. It also never returns a NACK, it just sits there sending me 0xA5 for infinity. I have attached this as SPI Bootloader Bad.kvdat . I know the trace I have attached only shows a second or so but I've tried it with multiple minutes and it still doesn't do it. I've worked through the flowchart in AN4286 but I can't see where I'm going wrong, the traces look good to me. I'm just trying a bulk flash erase here to start with. I'll try erasing individual pages once I get this working.

Can anyone point me in the right direction?

Thanks

Chris

2 REPLIES 2
cblackburn
Associate II

Hi All,

An update..... I found one of my problems. I wasn't following the initialisation procedure of the bootloader and I was going straight to sending commands. Once I followed the proper procedure it seemed to take the erase command. Well, it seemed to erase the memory at least.

However.... it still isn't giving me an ACK or NACK once the erasure is complete. There is an obvious point for 20-30ms where it sends 0x00 rather than the 0xA5 sync pattern which I assume is it doing the erase. Then the sync's come back but no (N)ACK. Again, this is waiting for a long time to make sure it's not me waiting long enough. I also tried putting a wait statement in between sending the erase command and starting to poll for the ack, this didn't make any difference.

I've attached a new trace showing the current output. Any ideas welcome as to what I might be still doing wrong.

Thanks

Chris

Hi All,

Another update for anyone googling in the future and coming across this. I've done a lot of digging and there are some restrictions that you have to follow in order to get the bootloader working properly over SPI. Some or all of these may be because I'm working with the P-NUCLEO example board for the STM32WB55 rather than a raw device. So, YMMV. But this is how I got it to work

  • Erasing the whole flash using the special 0xFFFF command just doesn't work at all. Nothing I've tried gets this to work. You have to erase using the page command
  • When erasing sets of pages using the erase command you can only erase chunks of 16 pages at a time. Anything more than this will cause the bootloader to lock up.
  • Even though the STM32WB55 I have has 1MB of flash (double checked in STM25CubeProgrammer) I can only erase 768KB of flash. Attempting to erase anything above this limit will cause the bootloader to crash.
  • When you write to the flash using the write command 0x31 all writes *must* be 64 bit aligned. I.e. those writes must start at an address which is evenly divisible by 8 without a remainder and must be an exact multiple of 8 bytes long. If you try and perform a write with a length not divisible by 8 (say, 12 for example) then the last remaining bytes will be filled with "undefined behaviour". In my experience the data pointer seems to loop around and write the first 4 bytes into the 4 bytes after the end of the write. The bootloader will silently ACK the write not indicating that there is a problem but you will have corruption. This is against the documentation which states that the writes must be 16 bit aligned.

If I encounter anything else I'll write it down in this post for posterity. Hopefully it will save someone some time.

Regards

Chris