• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 102 subscribers
  • Views 1485 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

ARM and DSP loading

Steve Sanders
Expert 1490 points

I'm using CCS to talk to an OMAPL137 EVM from Spectrum Digital.  I’m looking at the on-board 64MB as four “banks” at 0xc000 000, 0xc100 0000,  0xc200 0000, and 0xc300 0000.

I can load the DSP to either 0xc000 0000 or 0xc300 0000 easily. When I load the ARM to the “other” bank, it fails with something like:

ARM9_0: File Loader: Verification failed: Values at address 0x00000000C3000000 do not match Please verify target memory and memory map.

And then when I “move” the DSP image to 0xc300 0000, it loads fine and the ARM fails loading to 0xc000 0000.


Is there something easy I'm missing???

Thanks.

Steve

  • 0
    TI__Mastermind 43660 points
    Steve,

    We will look into this and get back.

    Regards,
    Senthil
  • 0 in reply to Senthilkumar Srinivasan
    Expert 1490 points
    l can use the memory browser to peek/poke memory UNTIL I right-click the ARM and connect. At that point I read 0s and can't write anything.
  • 0 in reply to Steve Sanders
    Expert 1490 points
    If I start the memory browser while the DSP is selected, I can read/write memory no problem. If I start it while the ARM is selected, I can't. This is before AND after I connect the ARM.
  • 0
    TI__Guru** 116100 points

    Dear Steve,
    OMAPL137 is DSP master device, i.e firstly DSP will come out of reset and still ARM is in reset state.
    You need to wakeup the ARM by DSP core (by using user boot loader; UBL).

    In emulation boot mode, both cores is in wake up state and initialization has to be done through gel file for both cores.

    So, always, do connect the DSP core first and then ARM (in all boot modes) in CCS target configuration.
    Then try to access the memory, please let me know if any.

    ARM gel file doesn't have any initialization part but DSP gel file.
    C:\ti\ccsv6\ccs_base\emulation\boards\evmomapl137\gel\evmomapl137_dsp.gel
    C:\ti\ccsv6\ccs_base\emulation\boards\evmomapl137\gel\evmomapl137_arm.gel

    I hope this helps.

  • 0
    TI__Mastermind 43955 points

    Hi Steve,

    In addition to Titus's Suggestion, the following are points to look at.

    1. As a first step, after launching the *.cxml file, do you able to do "connect target" on DSP and then the "connect target" on ARM and able to see the gel file running successfully displaying the messages on the CCS console? For Spectrum digital OMAPL137 board, use the gel file attached below. Open up the *.cxml file --> advanced --> select DSP_0 --> < locate to the path of dskda830_dsp.gel> and again, open up the *.cxml file --> advanced --> select ARM_0 --> < locate to the path of dskda830_arm.gel>

    2. Check whether the Gel output messages are OK. If throws error, locate the portion in the gel file and have a look at. If not able to find, post the screenshot of your gel output messages.

    Steve said:
    I can load the DSP to either 0xc000 0000 or 0xc300 0000 easily. When I load the ARM to the “other” bank, it fails with something like:

    Are you trying to load the DSP programs on ARM?? I mean to ask for what family ( ARM / C6000 ) your program has been created? You cannot load DSP programs into ARM. I hope you knew it. Create ARM programs and load it on ARM core and check it.

    Else, I have attached two binaries ( One for ARM : GPIO_multi_led_interrupt_armL137 and another one for DSP : GPIO_multi_led_interrupt_dspL137) you can load them directly on your SDI board and check it.

    Gel files:

    ARM: 8306.dskda830_arm.gel

    DSP: 1362.dskda830_dsp.gel

    ARM Binary: GPIO_multi_led_interrupt_armL137.out

    DSP Binary:

    GPIO_multi_led_interrupt_dspL137.out

    All the best. Try it and let me know how it goes for you.

  • 0 in reply to Shankari G
    Expert 1490 points
    The ARM's MMU was getting turned ON somehow... That's what was causing the memory access problems.

    What causes the MMU to get turned on? I keep turning it off, but it keeps wanting to turn back on...

    tnx

    Steve
  • 0 in reply to Steve Sanders
    TI__Mastermind 43955 points
    Hi Steve,

    Did you try out the binaries I have posted?

    Could you please share the results of steps 1 and 2 posted in the previous post?