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.

File Loader: Verification failed: Values at address 0x00000000C3000000

Other Parts Discussed in Thread: OMAP-L137

ARM9_0: File Loader: Verification failed: Values at address 0x00000000C3000000 do not match Please verify target memory and memory map.
ARM9_0: GEL: File: C:\Users\Jaime\Dropbox\Modem Cetrulo\evmomapl137typical\Debug\evmomapl137typical.out: a data verification error occurred, file load failed.
ARM9_0: Unable to terminate memory download: NULL buffer pointer at 0x322


I get the above error when I try to create a SYS\BIOS example. This is without any modifications. I can run rCSL arm and dsp examples, RTSC DSP Examples.


If I select OMAPL137.cmd in the build settings then I get an error that the memory map overlaps,

  • Hoffiz,

    Prior to loading the .out file (or after, for confirmation), try looking at the SDRAM at 0xc0000000 and 0xc3000000 using the CCS Memory Browser to see if you can read and write memory there. My first guess is that you do not have the EMIF configured correctly prior to loading the code. This configuration is usually done in a GEL file, so it is also unusual to see the "ARM9_0: GEL:" heading for the second line - I would not expect this to be running from a GEL file at this point. That may mean you have something complex that you are doing, either behind the scenes or intentionally.

    It is often a mistake for me to try to guess from implied information about what you are doing. It would be helpful for you to explicitly tell us

    - processor being used
    - CCS version
    - custom board or EVM/LCDK, etc.
    - what steps you have taken prior to this point

    To be clear, you are trying to build a SYS/BIOS example program on the ARM9? Most people use Linux, but I personally prefer the simplicity and much lower overhead of SYS/BIOS. I am curious about the application for this.

    When you select OMAPL137.cmd, what exactly does that mean? Where did you select it, in which setting? There should be more information with the "memory map overlaps" message, such as which areas of memory overlap. It may help to explain a lot more. We will need more information.

    Regards,
    RandyP
  • Hi Hoffiz,
    In addition to Randy suggestions,


    If I select OMAPL137.cmd in the build settings then I get an error that the memory map overlaps,

    In SYS/BIOS examples, you no need to add any *.cmd (linker command) file since memory mapping is done through platform *.cfg file.


    ARM9_0: File Loader: Verification failed: Values at address 0x00000000C3000000 do not match Please verify target memory and memory map.
    ARM9_0: GEL: File: C:\Users\Jaime\Dropbox\Modem Cetrulo\evmomapl137typical\Debug\evmomapl137typical.out: a data verification error occurred, file load failed.
    ARM9_0: Unable to terminate memory download: NULL buffer pointer at 0x322

    What is your emulator ?
    XDS100v2 ?
    You are getting an error when you load this binary "evmomapl137typical.out" ? not for any other binary?
    How did you build this binary "evmomapl137typical.out" ? with *.cmd also ?
  • OMAP-L137
    CCS 6
    Spectrum Digital EVM

    Hi Randy and Titus,

    I think your first guess is right. I have not tried to poke the memory address but to get around it this is what I do: launch the target configuration file, connect the DSP, at which point I can see the GEL running and after further inspection of the dsp gel, I can see it does initializes the EMIF. Then I can connect to the ARM, at which point it will warm that address 0xFFFF0000 has nothing and I can manually load/run my arm out file.

    I thought this was a little strange since I have used both the DSP and ARM side but this is the first time I compile an ARM project with SYS/BIOS. Previous interaction where the rCSL examples. This will happen even with the hello example for the ARM with SYS/BIOS. I'm not sure if that is expected or a little more documentation could help but is not that big of a deal, just kind of annoying.

    For ease of use what will you recommend? Creating a Gel file that includes the part of the DSP that turns on the EMIF and other peripherals, or continue with my approach of connecting the DSP, then loading my program?

  • Hi Titus,

    XDS100v3 Texas Instruments.


    I added the cmd file as a debug step and quickly realize that it was the wrong step. For the question of this thread I still get the error even if I don't add the cmd. Which I now know is not the correct approach. SYS/BIOS will create its own linker.cmd. This will happen with any of the SYS/BIOS ARM examples for the EVMOMAPL137. All of the other things I have tried, almost all rCSL ARM examples, work fine.


    Although the rCSL point to the same gel file, none of them example use SDRAM.


    Jaime

  • Hi Hoffiz,
    Able to solve this issue ?
    Can you provide the *.out to me to check it at my end (for reproducing) ?
    It will be good if you provide with project source file, you can remove your confidential code and just put some prints then attach here.
  • Hi Titus,

    Yes I was able to workaround this issue. Like I mention above, when running simple ARM side SYS/BIOS examples, I will first connect to the DSP, this will run the DSP Gel and turn ON (or enable the ARM, that is actually how it prints on the console), then connect to my ARM and finally run the .out file.

    and


    build, and when I try to launch a debug session I get

    with this on the console

    ARM9_0: File Loader: Verification failed: Values at address 0x00000000C3000000 do not match Please verify target memory and memory map.
    ARM9_0: GEL: File: C:\Users\Jaime\Dropbox\Modem Cetrulo\armminimalexample\Debug\armminimalexample.out: a data verification error occurred, file load failed.
    ARM9_0: Unable to terminate memory download: NULL buffer pointer at 0x320


    armminimalexample.zip

    I think you will only be missing the gel file to have an exact replica of the project, well also my evm ;). This happens when I power cycle the evm. I think I can get around it if the DSP is left running already.
     

  • Jaime,

    Thank for taking the time to go through this. It will help other people, too.

    Personally, I never use the Debug icon 'bug' to start a debug session because it starts 3 things happening that all could lead to problems of their own: launch target configuration, connect to target, and finally [try to] load the .out file.

    This is the common way that people use CCS for most of our MCU products, and the process is worked out to go smoothly. But with our multi-core and complex ARM or DSP devices, my preference is to do all of the steps separately. I will manually launch the target configuration (usually from the down-arrow on the right of the 'bug' icon), select the core I need to work with, connect to that core (Target Connect), and then do whatever I need to do. On many of our ARM+DSP devices where I am programming on the DSP, I have to bring up the ARM first and tell it to enable the DSP.

    I think the OMAPL137 can be configured by boot pins for either the ARM or the DSP to be the boot master. Whichever one is the boot master will have to enable the other core after loading its code.

    If you power up, launch the target configuration, connect to the DSP, run its GEL to initialize everything and enable the ARM, then you should be ready to work with the ARM and not have to go through any of that again, unless of course a Reset is required. If no reset is required, then you should be able to connect to the ARM and load programs to be debugged, change the program and let it automatically reload, and not have to go back to the DSP until the next reset. You might need to verify that any GEL setup for the ARM (if there is one) does not automatically do a reset with a reload of a new .out file. This is most likely not happening or it would mess with you as it is today, anyway, but just a thought that came to mind.

    Good luck with your debugging, and come back to a new thread if you have any new issues.

    Regards,
    RandyP
  • Thanks a lot Randy, this should be a wiki itself. It does explain and clarifies exactly what I'm seeing.

    I really appreciate the last suggestion:

    If no reset is required, then you should be able to connect to the ARM and load programs to be debugged, change the program and let it automatically reload, and not have to go back to the DSP until the next reset.

    I've kept with the flow and keep doing all 3 steps. I will try this more efficient approach.