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.

Can an AIS (application image script) load data into L2 RAM within the DSP Megamodule?

Other Parts Discussed in Thread: OMAP-L138

I'm trying to boot both the ARM and the DSP in the OMAP-L138 from a SPI flash device on SPI1.

The program data for the ARM all resides in external mDDR. The program data for the DSP all resides in the L2 RAM internal to the DSP Megamodule.

I'm using the AISgen tool to generate a single binary image for the SPI flash from the ARM and DSP output files (the ARM's is an ELF and the DSP's is a COFF). But, when I load that binary image into SPI flash and try to boot, the ARM starts executing code and the DSP doesn't.

I have the AISgen tool set to configure the PLLs and clocks, the DDR controller, and place the DSP in SynReset state. I have code running on the ARM that sets the DSP's boot address and then wakes up the DSP (by transitioning it to the Enable state).

After the ARM boots from the SPI flash, I connect the debugger (without executing any GEL scripts or code) and I can see that the code that was supposed to be loaded into L2 RAM by the AIS isn't there.

I've verified that the AISgen output does indeed contain segment load commands for the DSP's program data in L2 RAM. I did this by having it generate a .h file instead of a binary file and deciphering the contents using information in Application Report SPRAB41C - Using the OMAP-L1x8 Bootloader. All looks to be in order there. It executes commands to configure the PLLs and Clocks, to configure the DDR controller, and to configure the PSC controller (to place the DSP in SynReset state). It then follows those with segment load commands to load all of the ARM segments in DDR and then segment load commands to place all of the DSP segments in L2.

Anyone have any idea why this isn't working? Could it be that the AIS can't load segments into L2 RAM?! It seems like as long as the DSP Megamodule is being clocked (which it is by being placed in SynReset state), that this should work.

Thanks,
Arthur

  • Arthur James said:
    I have the AISgen tool set to configure the PLLs and clocks, the DDR controller, and place the DSP in SynReset state. I have code running on the ARM that sets the DSP's boot address and then wakes up the DSP (by transitioning it to the Enable state).

    Arthur,

    I would suggest you look at the code available with this wiki page that shows doing the DSP startup on an OMAP-L138 ARM boot device:

    http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138

    In particular, from the wiki page:

    "If any sections of the DSP memory map are located in DSP L2 RAM (0x11800000), be aware of two things:

    • 1: Make sure all L2 RAM addresses in the DSP linker command file are referenced in the 0x118xxxxx range and not 0x008xxxxx, as the ARM cannot write to the 0x008xxxxx address range
    • 2: Use the "Configure PSC" function of AISGen to enable the DSP LPSC (PSC0,#15). If the DSP megamodule is in reset, the L2 RAM will not be accessible so the section loads will fail. The AISGen CFG file included with this project enables PSC0,#15 by default."

    So, you need to put the DSP into the ENABLE state - if the module is in reset (even with clock enabled) the memories are in reset.  Putting the DSP LPSC domain into the enable state does not start the DSP - there is still a local reset bit that must be toggled to kick off the DSP execution.  Anyway, the example code from the wiki page shows all of this and also shows the use of the AISGen to combine the DSP and ARM image into a single boot image as you are doing.

    Regards, Daniel

  • Daniel,

    That was it. I changed the AIS to put the DSP in the Enable state instead of the SynReset state and now it loads code into L2 RAM and boots right up.

    As you surmised, I chose the SynReset state because I was afraid that the DSP would start executing before its code was loaded. I didn't realize that the local reset would be asserted and prevent the DSP from executing when putting it in the ENABLE state.

    Thanks!
    Arthur