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

    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,

    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!

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

Children
No Data