• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 54 subscribers
  • Views 1336 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS 4.2.0.10018 Memory Map Problem

Michael Williamson
Expert 1995 points
Other Parts Discussed in Thread: OMAP-L138

Hi,

I am using an OMAP-L138 and upgraded CCS to version 4.2.0.10018 and can no longer debug my application.

I am connecting to the TMS320C64XX core, loading a gel file (that worked with 4.1.x).  When I try to load my DSP application I get an error:

C674X_0: File Loader: Data verification failed at address 0xC63D6800 Please verify target memory and memory map.
Error found during data verification.
Ensure the linker command file matches the memory map.

All of my memory windows will no longer work (I get XXXX's, saying the memory map is not valid).  I have tried restarting the app, reloading the Gel, reloading the memory map.  Everything claims to be OK, but the access windows and the load capability is now broken.

However, if I view the Memory Map, on the Gel File Tool Tab, it shows that all of the regions that should be available (including the DDR from 0xC0000000 to 0xDFFFFFFF).

I am at a dead stop.  I am not doing anything different than with 4.1.X.  Can someone please advise?

-Mike

 

  • 0
    TI__Guru**** 162895 points

    Mike,

    What emulator are you using?

    I could try to reproduce here on both 4.1.3 and 4.2.0.

    Regards,

    John

     

  • 0 in reply to JohnS
    Expert 1995 points

    Spectrum Digital USB 510 emulator.

     

  • 0 in reply to Michael Williamson
    TI__Guru**** 162895 points

    Ok I will grab one of those and a Logic L138 board.

    Can you send me a private message with the .out you are loading (it will need to be zipped up)?  If you click on my user name it let you send me a message.

    One thing to note is that the Spectrum Drivers need to be updated between 4.1.x and 4.2.x.  The updated driver package should show up when check for updates.  After updating the spectrum drivers you will need to unplug the usb cable to make sure the firmware on the pod gets updated.

    Regards,

    John

     

  • 0 in reply to JohnS
    Expert 1995 points

    Hey John,

    I can't seem to find the link for attaching a file off of the User Page.  I can start a conversation, but it pretty much looks like forum editor....

    Not sure how to get the .out file to you....

    Is there a way to verify that the drivers are loaded (other than the red-light on the emulator pops up)?  Can I use the SDConfig tool to verify the firmware?

    -Mike

     

  • 0 in reply to Michael Williamson
    TI__Guru**** 162895 points

    Mike,

    Test 1: CCSv4.1.3, SD 510USB+ (my non+ bit the dust), Logic L138 EVM, GEL files from Logic

    Connect to ARM

    Connect to DSP

    Loaded your program fine

    Test 2: CCSv4.2.0, SD 510USB+ (my non+ bit the dust), Logic L138 EVM, GEL files from Logic

    Unplug/replug emulator

    Power cycle board

    Connect to ARM

    Connect to DSP

    Loaded your program fine

    Test 3: CCSv4.2.0, SD 510USB+ (my non+ bit the dust), Logic L138 EVM, ARM GEL file from Logic and your DSP GEL file

    Power cycle board

    Connect to ARM

    Connect to DSP

    Loaded your program fine

    Test 4: CCSv4.2.0, SD 510USB+ (my non+ bit the dust), Logic L138 EVM, No ARM GEL file and your DSP GEL file

    Power cycle board

    Connect to ARM

    Connect to DSP

    Get the same data verification error as you!!!

     

    Is your GEL file for the ARM initializing the DDR?  When I connect the ARM a bunch of stuff is happening in GEL.  I see it initializing the DDR and enabling the DSP.  Also if I don't power cycle my EVM I find it does not get through the initialization.  Attached is my GEL file for the ARM.4137.OMAPL138_ARM.gel

     

     

    ARM9_0: Output: Memory Map Cleared.

    ARM9_0: Output: ---------------------------------------------

    ARM9_0: Output: Memory Map Setup Complete.

    ARM9_0: Output: ---------------------------------------------

    ARM9_0: Output: Enabling Full EVM PSCs...

    ARM9_0: Output: PSC Enable Complete.

    ARM9_0: Output: ---------------------------------------------

    ARM9_0: Output: PLL0 init done for Core:300MHz, EMIF:25MHz

    ARM9_0: Output: mDDR initialization is in progress....

    ARM9_0: Output: PLL1 init done for DDR:132MHz

    ARM9_0: Output: mDDR init for 132 MHz is done

    ARM9_0: Output: ---------------------------------------------

    ARM9_0: Output: DSP Wake Complete.

    ARM9_0: Output: ---------------------------------------------

     

     

  • 0 in reply to JohnS
    Expert 1995 points

    I'm a little confused.  I don't want to connect to the ARM at all, just the DSP.  The ARM is running linux.  Do I have to attach to the ARM, and then release the process to keep linux running?

     Most of the time I am trying to debug an application loaded by the ARM via DSPLINK.

    We have two main use cases:

    1.

    - Boot linux (on ARM)

    - Have ARM progam DSP (via DSPLINK) with a dummy program with a simple spin loop.  We do this primarily to release the DSP from reset.

    - Connect with emulator.

    - Load and debug program (overwriting dummy application loaded by DSP link)

    2.

    -Boot linux (on ARM)

    - Have ARM load target DSP application (via DSPLINK)

    - DSP application sits in spin loop

    - Connect with emulator and break in

    - Load symbols of program to debug and debug program

    These paths were working with 4.1.2, and I never loaded an ARM gel or connected to the ARM to accomplish this.  Am I not understanding something here?

  • 0 in reply to Michael Williamson
    TI__Guru**** 162895 points

    Mike,

    The ARM has to initialize the DDR and setup the DSP.  The GEL can do that or your application can do it.

    If you were not using a GEL in 4.1.2 and were having Linux do it on boot then I don't see how upgrading CCS would change the behavior.  By the time you connect CCS to the DSP it is either setup or it is not.  Unless somehow connecting the emulator is now reseting something on the ARM.

    If you really need to go back to 4.1.2 it is available here: http://processors.wiki.ti.com/index.php/Download_CCS

    However I don't think that is the problem.  On Monday I can ask someone with Linux experience to take a look but unfortunately I don't have any experience with using Linux on ARM myself.

    John

  • 0 in reply to JohnS
    Expert 1995 points

    Right.  I am using the ARM (running on it's own) to initialize the mDDR, the pinmux, powering up all the peripherals, etc., while loading/starting/running linux.  You can also reproduce this problem by breaking into u-Boot as well (UBL actually sets up the mDDR), and not necessarily loading linux.

    When I connect with CCS, the RAM is all setup and running.  I know this because I can launch my app using DSPLINK (and not connect at all with the emulator) and it runs fine, as well as the linux OS.

    The fundamental problem is 4.2.x isn't even trying to access memory because it claims it's not setup in the memory map.  But I can sit there and observe that the memory should be set up for the DSP.  I am suspicious that, for some reason, the debugger is looking at the ARM memory map (which isn't loaded) instead of the DSP memory map (which is loaded).  When it connects, it knows where the DSP PC is (in a spin loop in mDDR), but refuses to load symbols, etc., because of this problem.  If I knew java, I could probably hunt the problem down.

    I will try to experiment with making an ARM gel that doesn't whack the memory controller (just sets an ARM memory map, and nothing more) and see if I can work around the problem.  But I shouldn't need to to that, I don't think.

    While it *might* not be a 4.2 thing, the issue I have is that all of this worked like a champ with version 4.1.x, multiple times, over several days with several power cycles / reboots, etc.  Same executables.  Same OS (linux).  Same gel file.  Same basic procedure to attach.

    Do you know if I can install 4.1.2 side by side with 4.2.x?  Or do I have to uninstall everything and re-install?  CCS 3.3 allows my to run side by side with 3.1 (as well as 4.x).  An uninstall/reinstall cycle takes about 1.5 hours by the time it's all done.  Do I need to back up the upgrade emulator drivers too?

    -Mike

  • 0 in reply to Michael Williamson
    TI__Guru**** 162895 points

    Mike,

    You can install 4.1.2 beside 4.2.0.  I have an install of pretty much every flavor on the same machine.

    You could disable the memory map in both the DSP and ARM gel files.  The memory map just controls debugger accesses if the map is off then the debugger can do any access.

    John

  • 0 in reply to JohnS
    Expert 1995 points

    Thanks for the info.

    While connected to the DSP, I did try to disable the memory map (which basically opened all the memory from 0x00000000 to 0xFFFFFFFF), and it still didn't work.  That's why I suspect the debugger might be looking at the wrong processor (the ARM, or the PRU) for memory map information.  I'll experiment more when I get back to the office on Monday.

    -Mike

     

  • 0 in reply to Michael Williamson
    Expert 1995 points

    Well,

     

    I installed 4.1.X in a separate directory.  It worked fine.

    I then went back and tested 4.2.X.  It now works fine.

    I did have to disconnect and reconnect the emulator (the installations somehow altered the driver).  I'm wondering if that was all I needed to do the first time.

    Not sure what the real solution was, but 4.2 is now working.

     

  • 0 in reply to Michael Williamson
    TI__Guru**** 162895 points

    Good to hear it is working. Often when Spectrum releases new drivers you have to unplug the usb cable and plug it back in to get it to update the firmware.  

    I wonder if it is using the firmware from the 4.1.2 install now?  I will check with Spectrum and see if there is a way to read out which firmware is loaded.  It also could just be Gremlins.

    John

  • 0 in reply to JohnS
    TI__Guru**** 162895 points

    I checked with Spectrum and there isn't a way to check the firmware version on the pod.  

    I would assume that the the problem was that the firmware on the pod needed to be upgraded when you did your first update to 4.2, but that it didn't occur as that only happens when you unplug and replug the USB cable and then start CCS.

     

    John