This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DSP executable load using UART for DSPLINK driver on OMAP3530 platform

Other Parts Discussed in Thread: OMAP3530

1. We are using Threadx OS for our Omap3530 Eval board from LogicPD. We have compiled DSP Link driver for GPP side on Threadx.

2. We have compiled DSP Link driver and sample application for DSP side on DSP/BIOS.

3. We have directly loaded DSP executable (in COFF format) to DDR through UART using kermit protocol and tried to start the DSP. There is no response from DSP. Handshaking between these two processors have failed.

4. We have also converted the COFF format executable to binary format  and ascii-hex  format using hex6x.exe and tried the same procedure. There is no response from DSP.

If we want to download the DSP executable directly into DDR then which format DSP executable should be converted so that the DSP shall respond for ARM's request?

Please provide your suggestions and your early response is very much appreciated.

  • The DSP will need the executable in a raw image format, the DSP is not aware of COFF or ascii-hex formatting, it can only work in raw binary images. Typically you would load a COFF formatted image to the DSP memory space by unpacking it into a raw image, that is removing the headers in the COFF file and placing the sections where they need to be in memory based on the headers.

  • Hi Bernie,

    Thanks for your response. Can you please let me know how to remove the header from the COFF file? Is any utility available for this? Can I load this raw image through UART using kermit protocol? 

  • Sakkarai Rasu said:
    Can you please let me know how to remove the header from the COFF file?

    For details on the COFF format see this document, if you were to create your own loader which would remove the section headers you could do so based on the format described there. I am not sure where this is managed in a typical Linux/BIOS system, I suspect it is at the BIOS/Link layer but I am not sure, in any case it would happen for a normal Linux system when you open your codec engine server.

    Sakkarai Rasu said:
    Is any utility available for this?

    The hex6x utility is doing this to some extent, only the output is in hex meant for being fed into a flash writing utility and not a binary, I believe the -b option with the hex6x utility will give you such a image but it is undocumented.

    Sakkarai Rasu said:
    Can I load this raw image through UART using kermit protocol? 

    If you had a raw image I suppose you could, however this is not typical, like suggested above you would normally have Codec Engine manage the loading of your DSP image, however I am not sure how reasonable this is to do in a non Linux/WinCE OS environment.