AnsweredAssumed Answered

SPI loader/boot kernel bug?

Question asked by rolf on Jul 6, 2009
Latest reply on Jul 14, 2009 by CraigG

I discovered the following contradiction when loading a generated loader file onto my SHARC DSP 21161N via SPI, using the latest SPI boot kernel ([VisualDSP_path]\211xx\ldr\161_spi\161_spi.asm), which I have adapted for SDRAM-customized purposes.

The elfloader is called as follows:

[VisualDSP_path]\elfloader.exe -proc ADSP-21161 -bSPI -fBINARY -HostWidth 32 -ExternalMemoryWidth 32 -NoBitReverse -l ..\bin\dac1_spi_ldr_kernel\161_spi.dxe -t65530 -o .\ReleaseLoader\dac1_conv_dsp.ldr -NoInitialWord -v  .\ReleaseLoader\dac1_conv_dsp.dxe -MM


My generated .LDR file contains several initialization sections with loader tag 0x15 (INIT_PM32_EXT) and I suspect the count variable of its header are either wrong or misinterpreted by the default boot kernel (161_spi.asm).

Consider this excerpt of my generated .LDR file:



0x00000002     // count

0x08006804     // address (ext. memory)

0x00000015     // tag (INIT_PM32_EXT)

0x00000000     // data0

0x00000003     // data1

0x00000000     // data2

0x00002000     // count

0x08006806     // address

0x00000019     // tag (ZERO_PM32_EXT)



I found that the reason this .LDR would not correctly load was the following:

since the default boot kernel only awaits 2 words to be written to address 0x08006804, it misinterprets data2 as being the count variable for the next header, and all other following data is misalligned due to "nonsense" header information.



I suspect a bug in the SPI loader generator. Respectively incorrect use of the count variable in 0x15 init sections (maybe others as well?) within the current SPI boot kernel. Either one or the other should be corrected in order to avert erronious SPI loading for future users. Hasn't this occured to anyone else before?



My current workaround is to run a (python-)script which removes the needless data words within 0x15 init sections of the .LDR. To do this you must parse all init/zero headers to find the 0x15 sections. Since I need to extract the header information for my SPI host CPU in order to respect EE-177 (SW Solution), parsing is necessary anyways in my case. The DSP now loads fine.