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.

OMAP-L138: Issue with DSP library functions while running program from NAND flash

Part Number: OMAP-L138
Other Parts Discussed in Thread: OMAPL138,

Hi

I am working on LCDK OMAP L138 evaluation board.

I made one dsp application in which i am doing fft calculation  using DSPF_sp_cfftr2_dit(f32FftIn,w,N) library function and toggle one led and load the program using jtag in debug mode, and its working fine as expected .

Now i want to download the same dsp application (dsp.out) in nand using uart bootme utility by following the below steps

a) Generate boot.ais from boot.out file using aisgen (boot loader prj from OMAPL138_StarterWare_1_10_04_01 and AISgen_d800k008.exe )

b) Generate dsp1.bin from dsp_prog.out using out2rprc.exe and download these files using sfh_OMAP-L138.exe

      out2rprc.exe dsp_prog.out dsp1.bin

      sfh_OMAP-L138.exe -flash boot.ais dsp1.bin -targetType OMAPL138_LCDK -flashType NAND -p COM5

Application gets downloaded successfully in nand and on serial port it shows dsp application running, but the led is not toggling, seems program is not working

But when i commented the fft functions on the dsp program and download the same dsp application on nand then led is toggling, seems program is working

Our observation is that when we use dsp library function then it get stuck where we called the library function

Note: I am using TI DSP library functions i.e. dsplib_c674x_3_4_0_0 whose kernel is in L2RAM.

Please tell us the reason why it get stuck when we call dsp library function and how can we solve this.

Following are the screenshot of programming details when we downloaded program with FFT function.

Regards,

Satheesh

  • Hi,

    I've notified the Starterware team. They will post their feedback directly here.

    Best Regards,
    Yordan
  • Hi yordan,

    We are running out of time.Please help us in a timely manner.Our own target hardware will come in two days, we have to load our Program in Nand flash for detailed testing.

    Regards,

    Satheesh

  • There are few reasons that this may be occurring. DO you have any memory map overlap between the bootloader.out and your application?
    If there is some over lap then it can cause undesirable behavior like this. One way to debug this issue is to flash the application to NAND and then run the boot.out over an emulator to see exactly where the error occurs.

    When you load the boot.out over emulator the secondary bootloader, you can trace the application boot. You can also set a While loop at the start of your application that blocks on a volatile variable and then connect to see the root cause for this failure. We have archived common Bootloader debugging techniques here:

    processors.wiki.ti.com/.../Processor_SDK_RTOS_Boot

    One other techniques to isolate the issue would be to place the sections in DDR that way there is no conflict with secondary bootloader. If that works then look closely at section in Shared RAM And L2 RAM to make sure there is no conflicts.

    Hope this helps root cause the issue. Let us know if you need any further guidance.

    Regards,
    Rahul
  • Dear Rahul,

    Boot loader is using L3RAM (or shared RAM) and DSP is using SDRAM and L2RAM so there is a no question of memory overlap between our application and Boot loader.out.The main problem is when we put DSP lib in L2RAM then this issue is coming.

    I have a one more observation

    If I use one simple program without FFT and put  all code and data in L2RAM then also this program is not working.So our observation is  above mentioned programing technique is only works when we put all Code in SDRAM.

    Kindly let us know how to program OMAPl138 using above mentioned programing technique with a application program with all code and data in L2RAM  ?

    And also tell us how to solve the DSPLIB issue which I mentioned initially

    Regards,

    Satheesh

  • Which memory range are you using for L2RAM? The bootloader that executes on the ARM side cannot access the 0x00800000 range. Any writes to that range from the ARM side will not work. It can access the 0x11800000 range though.