ADSP-21571 SPI Slave Boot problem

Hi,

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?

Thanks!

Parents
  • 0
    •  Analog Employees 
    on Feb 8, 2019 6:39 AM over 1 year ago

    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

Reply
  • 0
    •  Analog Employees 
    on Feb 8, 2019 6:39 AM over 1 year ago

    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

Children
  • 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!

  • 0
    •  Analog Employees 
    on Oct 11, 2019 1:58 PM over 1 year ago in reply to 86675289@qq.com

    Hi,

    The default boot kernel(for ADSP-SC573 Ez-kit) is available along with CCES. Please find it in the below path. You can also modify it based on your custom design.
    C:\Analog Devices\CrossCore Embedded Studio 2.9.0\SHARC\ldr\ezkitSC573_initcode_core0

    Regards,
    Anand Selvaraj.