Boot from SPI Master

Hi,

I've just spent several hours with trying to find out, what is wrong with my hard and software!
Here is my experience, which might be helpful for anybody, who is going to design a system that boots a DA1458x from a master MCU via SPI:
Our device contains a STM32Fxxx MCU, and an ALPS UGMZ2AA module (AFAIK DA14580 inside) and SPI flash memory, both sharing the same SPI peripheral of the main MCU. The flash memory, as well as the UGMZ shall be both accessable as SPI slaves during normal operation, therefore it's not possible to connect the UGMZ as master to the flash menory.
I have written some code for loading the image data from the flash memory into the MCU and then transfering them to the Bluetooth module, according to boot protocol from document "AN-B-001 - Booting from serial interfaces v2.0". While debugging the program, I was happy to see the UGMZ responding with ACK (0x02) for the preamble and image length data.
But the SPI data look like this:

Byte MOSI MISO
# (P0_5) (P0_6)
0 0x70 0x00 (Preamble)
1 0x50 0xDC
2 0x00 0xD4
3 0x00 0x02 (MOSI: Prg.size LSB, MISO: ACK, as expected)
4 0x1A 0xC0 (MOSI: Prg.size MSB)
5 0xD1 0xC6 (MOSI: CRC)
6 0x00 0x02 (MOSI: Mode Byte = 8-bit mode, MISO: ACK for length, as expected)
7 0x00 0xC0 (MOSI: empty)
8 0 x00 0 xff(莫西人:第一个数据字节,味噌:Problem -> ACK expected!)

Problem is byte #8, which should be ACK, according to AN-B-001

So I tried to find out what could be wrong here, also searched this forum and found several other posts about that issue, e.g.https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl...
既然话题总是对话框的答案was about likely SPI transfer problems and that the DA1458x's SPI in slave mode might be somewhat critical ("The spi sampler when in slave mode its very sensitive to spikes and reflections"), and since AN-B-001 is meanwhile quite old, without further updates released, I didn't assume that the documentation could be wrong. So I assumed the problem is related to my hard- or software. But even with a second test hardwarre, completely different from our device production sample (another MCU board, connected to ALPS development board, tried SPI connection for both variants according to Step 1 and Step 2, the result was always the same and I had no idea what's wrong.
On our device, SPI trace length between MCU and slaves is just a few millimeters, so I could not really imagine a problem of reflections there, nor could I see anything suspicious on the oscilloscope.
In desperation, I've tried to transmit just a little "test-image" of 4 bytes, by simply ignoring the missing ACK at byte #8 :

Byte MOSI MISO
0 0x70 0x00 (Preamble)
1 0x50 0xDC
2 0x00 0xD4
3 0x01 0x02 (MOSI: Prg.size LSB, one 32-bit word = 4 bytes, MISO: ACK, as expected)
4 0x00 0xC0 (MOSI: Prg.size MSB)
5 0xFF 0xFF (MOSI: CRC)
6 0x00 0x02 (MOSI: Mode Byte = 8-bit mode, MISO: ACK for length, as expected)
7 0x00 0xC0 (MOSI: empty)
8 0 x00 0 xff(莫西人:第一个数据字节,味噌:ACK expected, FF = garbage, ignored)
9 0x00 0xFF (MOSI: data byte)
10 0x00 0xFF (MOSI: data byte)
11 0x00 0xFF (MOSI: last data byte)
12 0x00 0xAA (MOSI: empty, MISO: :) )
13 0x00 0x02 (MOSI: empty, MISO: :) wow! Surprise - obviously that worked!)

My Conclusion: Seems that DA14580's bootloader does not fully comply to the document AN-B-001.
Question: did anybody ever see an ACK from the bootloader at byte #8?
@Dialog: if I'm right and the doc (AN-B-001) is wrong, please release a corrected version! It is rather frustrating to spend hours and hours to search for bugs that do not exist, due to misleading documentation!

Further I found out:
I never saw any "NACK" (0x20) - if you send garbage, e.g. if the given length of the image is beyond the DA1458x's memory size, you'll get garbage back (= anything, but "ACK), so do not really expect "NACK" (0x20) for errors.
Nice:
It seems to be allowed to deselect the SPI slave (CS high) between any two data bytes and resume SPI transmission later by setting CS low again. This is very helpful for our application, because the flash and the Bluetooth module share the same SPI pins on the MCU. So I guess I can fetch the image in small packets from flash and send them to the module, rather than having to load and transmit the whole image as a single, large block. I did not find anything about that in the documents, so I tried out by setting CS high after each byte, which seems to work. But I did not yet finally test it with real image data though....