I'm trying to boot an ADSP-21571 using SPI Slave mode, but I just can't get it to work.I'm pretty sure I have configured my SPI Master correctly (msb-first, pos. clk polarity). At the moment I'm running at a very low rate (1MHz).
When analyzing the Boot Stream (as generated by the elfloader tool), I can not quite understand the value of Target Address field in the Block Headers.From what I understand, for a Normal Block, the Target Address should always be the byte address of where the payload should be loaded.However, all Target Address fields have $28 in the most-significant byte. The other 24 bits seem to represent the correct address, but multiplied with a factor 2,4, 12 etc compared to the address found in the generated map-file.
Could someone please shed some light on this?
By the way, are there any examples on how to boot an ADSP-.21571 in SPI Slave mode available?
Hello Lalitha,I've done some further tests.After transmitting the first block (16 bytes) and two additional data bytes Core1 gets stuck in a loop. See attached picture.Any idea what's going? Is this an indication of that my block is invalid in some way?Thanks!
An update on my issue:
I finally sorted out SPI bit-order issue. I guess it's MSB first after all.
Using CCES emulator I can see the data sent from host showing up at the SPI2 RFIFO register. However, core1 still end up at that infinte loop at 0xb0253e.I'm transmitting the following sequence (hex) to the DSP:
03 <--- bcode5066ac <--- core104 \00 \ 0x9000409 / 00 /000000009400000003 <--- when this byte is received by core1, it ends up in an infinte loop (i guess something's wrong with the first block)..........If someone (perhaps ADI?) has a minimal loader stream available (for ADSP-21571 in SPI Slave boot mode) that they do know work, I would very much like to try that with my system.It could basically be just a 'nop' and a 'jump'.Thanks!
This happens in my experience as well. That last 0x03 in your listing should be the beginning of the next block - bits 0-7 of the block code (BCODE) - according to the hardware manual. If I send anything more than just the first block - an Ignore type with the 'first' bit set - The processor faults (~SYS_FAULT drives low).
ADI - What is happening here? I too would like to see a ldr file that is tested and known good. Can you please explain further - "Please ensure that the correct boot kernel is used before generating the loader (.LDR) file. If you are using a modified boot kernel, try using the default boot kernel supplied with CCES"
Isn't the boot kernel internal to the ADSP-21571? My understanding is that the boot process can be adjusted using OTP commands, but I have no use for that.
Hi Matt,I'm so glad I'm not alone in experiencing this. It was almost starting to feel like I was holding a monologue here...
I just checked my SYS_FAULT pin and it asserts for me too after the first block header has been received.As I, at this point, haven't even started to transmit actual code/instructions, I guess any problems with my program can be ruled out at this point.ADI: Again, I cannot emphasize enough how helpful it would be with a known good (a preferable minimal) loader steam.Thanks!