ADSP-21571 SPI Slave Boot problem

Hi Anderson,

I understand that SPI slave boot is not working for ADSP-21571. Is this correct? Can you please check the below and see if this could be of help.

Can you please let me know how are you loading the .ldr file and sending it from the Host processor?
Note that the SPI slave boot types do not need bit reversing necessarily. For SPI slave boots to non-PROM devices, the same default exists (bit-reversed); however, the host can simply be configured to transmit LSB first. Are you doing so?

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 together with a simple LED blink code to confirm basic boot-loading.

Also, ensure that you have selected the correct parameters while generating the .LDR file. Selecting an inappropriate parameter may cause the boot to fail. Please choose the loader option (Boot mode (-b)) as ‘SPI slave’ for booting from the external host processor.

Meanwhile I would suggest you to try booting a simple LED blink application and check if that boots correctly. BTW, is it possible for you to hook up the SPI signals from the host and check if the data is sent out correctly?

Regards,
Lalitha S

Hello Lalitha,

Sorry for my late reply - I have been working on other projects for a while.

You are correct; I can not get SPI Slave Boot to work for the ADSP-21571.

Regard the SPI bit order; if I understand you correctly the DSP is expecting LSB first, right?
That is what I'm no trying without any success (I have actually tried both bit orders without any success).

To eliminate any problems I might have with the elfloader utility or my program I am now transmitting only three simple block headers:

1. First Block (hdrSign = 0xAC, targetAddr = 0x1c0000

2. Fill Block ( hdrSign = 0xAC, targetAddr = 0x1c0000, byteCount = 4, argument = 0xcafebabe)

3. Final Block (hdrSign = 0xAC, targetAddr = 0, byteCnt = 0, argument = 0)

I figure I should see 0xcafebabe showing up at address 0x1c0000 when using the CrossCore Memory Browser.
Unfortunately data at address 0x1c0000 is not affected.

Is this expected?

I have attached an image of what the SPI signals look like. From top to bottom the signals are SPI2_SS, SPI2_CLK, SPI2_MOSI. Just ignore the fourth signal at the bottom.

Regarding my software; as you also suggested, I have a tiny program that just toggles a GPIO pin. It works just fine when I'm running it from CrossCore.

Thank you!

Hello Lalitha,

Here's some further info on how I generate the loader stream.
I'm calling the elfloader from command line using the following flags:

elfloader -b SPISLAVE -bcode 3 -f INCLUDE -proc ADSP-21571 -verbose -Width 8 \
-core1="Core1.dxe" \
-core2="Core2.dxe" \
-NoFinalTag="Core1.dxe" \
-o ../Output.ldr

The elfloader outputs the following message(s):

*********************************************************************
ADSP-21571 INPUT FILE(S) FOR BUILD
CORE1 Core1.dxe
CORE2 Core2.dxe
*********************************************************************
Process file: Core1.dxe
Process section: dxe_block0_data_prio0_bw
Section start address: 0x2403F0 [0x2403F0]
Section byte count: 0x68
Process section: dxe_block0_data_prio1_bw
Section start address: 0x240468 [0x240468]
Section byte count: 0xD84
Process section: dxe_block0_data_prio2_bw
Section start address: 0x241240 [0x241240]
Section byte count: 0x8C
Process section: dxe_block0_data_prio3_bw
Section start address: 0x2412D4 [0x2412D4]
Section byte count: 0x18
Process section: dxe_iv_code
Section start address: 0x90000 [0x28240000]
Section byte count: 0x300
Process section: dxe_block0_data_prio1
Section start address: 0x90117 [0x2824045C]
Section byte count: 0xA (0x8)
Process section: dxe_block0_data_prio2
Section start address: 0x9047C [0x282411F0]
Section byte count: 0x64 (0x50)
Process section: dxe_block0_data_prio3
Section start address: 0x904B3 [0x282412CC]
Section byte count: 0xA (0x8)
Process section: dxe_block3_sw_code_prio0
Section start address: 0x1C0000 [0x28380000]
Section byte count: 0x3BE
Process section: dxe_block3_nw_code_prio0
Section start address: 0xE00A0 [0x283803C0]
Section byte count: 0x6
Process section: dxe_block3_sw_code_prio1
Section start address: 0x1C01E4 [0x283803C8]
Section byte count: 0x1196
Process section: dxe_block3_sw_code_prio2
Section start address: 0x1C0AB0 [0x28381560]
Section byte count: 0xD16
Process section: dxe_block3_sw_code_prio3
Section start address: 0x1C113E [0x2838227C]
Section byte count: 0x148

Process file: Core2.dxe
Process section: dxe_block0_data_prio0_bw
Section start address: 0x2403F0 [0x2403F0]
Section byte count: 0x68
Process section: dxe_block0_data_prio1_bw
Section start address: 0x240468 [0x240468]
Section byte count: 0xD84
Process section: dxe_block0_data_prio2_bw
Section start address: 0x241240 [0x241240]
Section byte count: 0x8C
Process section: dxe_block0_data_prio3_bw
Section start address: 0x2412D4 [0x2412D4]
Section byte count: 0x18
Process section: dxe_iv_code
Section start address: 0x90000 [0x28A40000]
Section byte count: 0x300
Process section: dxe_block0_data_prio1
Section start address: 0x90117 [0x28A4045C]
Section byte count: 0xA (0x8)
Process section: dxe_block0_data_prio2
Section start address: 0x9047C [0x28A411F0]
Section byte count: 0x64 (0x50)
Process section: dxe_block0_data_prio3
Section start address: 0x904B3 [0x28A412CC]
Section byte count: 0xA (0x8)
Process section: dxe_block3_sw_code_prio0
Section start address: 0x1C0000 [0x28B80000]
Section byte count: 0x3BE
Process section: dxe_block3_nw_code_prio0
Section start address: 0xE00A0 [0x28B803C0]
Section byte count: 0x6
Process section: dxe_block3_sw_code_prio1
Section start address: 0x1C01E4 [0x28B803C8]
Section byte count: 0x1196
Process section: dxe_block3_sw_code_prio2
Section start address: 0x1C0AB0 [0x28B81560]
Section byte count: 0xCE2
Process section: dxe_block3_sw_code_prio3
Section start address: 0x1C1122 [0x28B82244]
Section byte count: 0x148

*** Summary of -NoFinalTag usage

-NoFinalTag Core1.dxe was successful

----------

As you can see I generate an "INCLUDE" file. When looking at the generated data some values puzzle me.
Below you can see the initial 32 generated bytes. I marked the values I don't really understand with a '*'.

0x03,
0x50,
0xAD,
0xAC,
0xB0,
0x0A,
0x1C,
0x00,
0x00,
0x00,
0x00,
0x00,
0xDC,
0x28,
0x00,
0x00,
0x03,
0x00,
0x38,
0xAC,
0xF0, *
0x03, *
0x24, *
0x28, *
0x68,
0x00,
0x00,
0x00,
0x00,
0x00,
0x00,
0x00,
...
...

Section 'dxe_block0_data_prio0_bw' (see elfloader output above) is destined for address 0x2403f0.
But somehow it's translated to address 0x282403f0 (see marked bytes above).
Could you please explain why this happens?

Several other address are also translated (0x90000 ---> 0x28240000, 0x1c0000 ---> 0x28380000 etc) but these translations are indicated by the elfloader output.
Still, I do not understand why this translation of addresses take place.

Thank you!

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 <--- bcode
50
66
ac <--- core1
04 \
00  \ 0x90004
09  / 
00 /
00
00
00
00
94
00
00
00
03 <--- 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!

Hi Andersson,

I'm in the same situation as you are.  I'm trying to set up an ADSP-21571 to boot as SPI slave.  For the addresses of 0x2824xxxx I thinks its OK.  If you look at the ADSP-21571 data sheet there's a memory map diagram on p. 8.  The memory range 0x2428xxxx is the core1 multi-memory space.  Using the offset 0x28xxxxxx something can write directly to a core's L1 memory.  There's a note about it here: ez.analog.com/.../faq-what-is-multiprocessor-offset-in-adspsc58x-adsp-215xx-processors

Hi,

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.

Thanks,

Matt

Hi,

Another question - 

What is the purpose of the switch to the elfloader command for SPI Master and SPI Slave? - the resulting ldr file appears to be the same using either setting.

Thanks,
Matt

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!

Hi,
Interesting - I'd like to know that too.
Thanks