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/TMDSEMU110-U: CCSv7 OMAP-L138_LCDK.gel script reports error writing to target with XDS110

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

Tool/software: Code Composer Studio

Configuration: CCSv7 / XDS110 / LCDKOMAPL138 / StarterWare uart example (or any other application)

Debug session fails with the following log, showing there is an issue accessing DDR memory. According to the XDS Features wiki

"If your XDS does not support adaptive clocking an adapter may be required to achieve the device's full JTAG operating rate. Running the XDS with a TCK rate that is less than 1/8th the ARM's functional clock rate is also an option if adaptive clocking is not supported by your XDS."

But the result is not better even with the lowest frequency (100kHz). See second log. 

1) Console output with default configuration (CCS Target configuration window)

==================================================================================
ARM9_0: Output:     Target Connected.
ARM9_0: Output:     ---------------------------------------------
ARM9_0: Output:     Memory Map Cleared.
ARM9_0: Output:     ---------------------------------------------
ARM9_0: Output:     Memory Map Setup Complete.
ARM9_0: Output:     ---------------------------------------------
ARM9_0: Output:     PSC Enable Complete.
ARM9_0: Output:     ---------------------------------------------
ARM9_0: GEL: Error while executing OnTargetConnect(): Target failed to write 0x01C11138
     at (*((unsigned int *) (0x01C11000+0x138))|=0x1) [OMAP-L138_LCDK.gel:16]
     at device_PLL0(0, 24, 1, 0, 1, 11, 5) [OMAP-L138_LCDK.gel:403]
     at Set_Core_300MHz() [OMAP-L138_LCDK.gel:468]
     at Core_300MHz_mDDR_150MHz() [OMAP-L138_LCDK.gel:245]
     at OnTargetConnect()
ARM9_0: File Loader: Verification failed: Values at address 0xC1080000 do not match Please verify target memory and memory map.
ARM9_0: GEL: File: C:\ti\OMAPL138_StarterWare_1_10_04_01\build\armv5\cgt_ccs\omapl138\lcdkOMAPL138\uart\Debug\uartEcho.out: a data verification error occurred, file load failed.
ARM9_0: Unable to terminate memory download: NULL buffer pointer at 0x320

==================================================================================

2) Console output with JTAG TCLK = 100kHz.

==================================================================================
ARM9_0: Output:     Target Connected.
ARM9_0: Output:     ---------------------------------------------
ARM9_0: Output:     Memory Map Cleared.
ARM9_0: Output:     ---------------------------------------------
ARM9_0: Output:     Memory Map Setup Complete.
ARM9_0: Output:     ---------------------------------------------
ARM9_0: Output:     PSC Enable Complete.
ARM9_0: Output:     ---------------------------------------------
ARM9_0: GEL: Error while executing OnTargetConnect(): Target failed to write 0x01C11138
     at (*((unsigned int *) (0x01C11000+0x138))|=0x1) [OMAP-L138_LCDK.gel:16]
     at device_PLL0(0, 24, 1, 0, 1, 11, 5) [OMAP-L138_LCDK.gel:403]
     at Set_Core_300MHz() [OMAP-L138_LCDK.gel:468]
     at Core_300MHz_mDDR_150MHz() [OMAP-L138_LCDK.gel:245]
     at OnTargetConnect()
ARM9_0: Error: (Error -1060 @ 0x2E18) Device is not responding to the request. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.628.3)
ARM9_0: Error: (Error -1029 @ 0x2B5F) Invalid data read from ICECrusher register. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.628.3)
ARM9_0: Unable to determine target status after 20 attempts
ARM9_0: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
==================================================================================

May somebody confirm that XDS110 woks fine with OMAPL138?

  • Josh,

    I just gave XDS110 and my OMAPL138 LCDK a try and I was able to load and run simple programs on both the ARM9 and DSP.

    I did see that same first error you saw:
    ARM9_0: GEL: Error while executing OnTargetConnect(): Target failed to write 0x01C11138
    at (*((unsigned int *) (0x01C11000+0x138))|=0x1) [OMAP-L138_LCDK.gel:16]
    at device_PLL0(0, 24, 1, 0, 1, 11, 5) [OMAP-L138_LCDK.gel:403]
    at Set_Core_300MHz() [OMAP-L138_LCDK.gel:468]
    at Core_300MHz_mDDR_150MHz() [OMAP-L138_LCDK.gel:245]
    at OnTargetConnect()

    I did not get the other errors though. I will see if I can find the starterware examples and give them a try as well.

    Regards,
    John
  • I can get the same errors as you if I use the StarterWare examples. These ones load to DDR which makes sense as that first error we see is for setrrupt on the DDR. I will try some other debug probes and see if the issue is related to the probe.
  • If I use an XDS100v2 then the DDR initialization completes successfully and I am able to load the program into DDR. I will need to check with an XDS110 expert to see if this is a limitation with adaptive clocking.



    ARM9_0: Output: Target Connected.
    ARM9_0: Output: ---------------------------------------------
    ARM9_0: Output: Memory Map Cleared.
    ARM9_0: Output: ---------------------------------------------
    ARM9_0: Output: Memory Map Setup Complete.
    ARM9_0: Output: ---------------------------------------------
    ARM9_0: Output: PSC Enable Complete.
    ARM9_0: Output: ---------------------------------------------
    ARM9_0: Output: PLL0 init done for Core:300MHz, EMIFA:25MHz
    ARM9_0: Output: DDR initialization is in progress....
    ARM9_0: Output: PLL1 init done for DDR:150MHz
    ARM9_0: Output: Using DDR2 settings
    ARM9_0: Output: DDR2 init for 150 MHz is done
    ARM9_0: Output: ---------------------------------------------
    ARM9_0: Output: DSP Wake Complete.
    ARM9_0: Output: ---------------------------------------------
  • Thanks JohnS,
    Formerly I used XDS200 with another OMAPL138LCDK and everything worked fine. This time, I was about to purchase XDS100v2 when I was told by TI support that XDS110 is about to replace XDS100 serie (v1,v2,v3)...
    I may confirm that when I build a "Hello World" example that loads the program in shared RAM it works despite the error log like your first try.
  • In general the XDS110 is a replacement for the XDS100. However with some of our older ARM926 devices that use adaptive clocking like OMAPL138 that could be a problem. XDS200 and XDS560v2 support adaptive clocking. I think the XDS100v2 does as well at a really low frequency. I will try to confirm this today.
  • I just got confirmation that this probe is not going to work well for devices like OMAPL138 that have an ARM926 core with adaptive clocking. I will make sure that our web pages get updated to reflect this.

    Regards,
    John
  • OK, Thanks again.
    Now I have a useless probe in hands and will purchase XDS200. Could customer service take back my XDS110?
    Regards,
    J.W.
  • Josh,

    We should be able to figure something out. I will send you a friend request and we can talk offline.

    John
  • Great, thanks in advance.
  • Josh,

    One additional detail if you would like to keep using your XDS110 while your XDS200 is on the mail. The XDS110 loses the ability to properly talk to the device when the register PLLCMD is set to re-lock the PLL - this happens at line 716 of the  OMAP-L138_LCDK.gel.

    In this case, converting the GEL routines to C (easy as GEL is, in fact, C) and including them in your project can help you get past this issue, as the XDS110 does not need to go through the clock transition caused by the PLL (and therefore does not lose sync/ability to read/write to the target). 

    Just for your reference (and for others interested in this discussion) I send attached a small project that runs on my LCDK and performs the entire GEL initialization in two files: init.c and init.h

    Regards,

    Rafael

    OMAPL138_Test.zip

  • Raphael,
    Your sample project seems to work fine... However, I would suggest you try a StarterWare or any other sample project that loads program into DDR memory. You will probably reproduce the issue we are talking about. As a matter of fact, when I modify your OMAPL138.cmd by replacing SHRAM with DDR2 I can get the following:
    -----------------------------------------------------------------------------------
    ARM9_0: File Loader: Verification failed: Values at address 0xC0000000 do not match Please verify target memory and memory map.
    ARM9_0: GEL: File: C:\WORK\0016-agx\OMAPL138_Test\OMAPL138_Test\Debug\OMAPL138_Test.out: a data verification error occurred, file load failed.
    ARM9_0: Unable to terminate memory download: NULL buffer pointer at 0x320
    -----------------------------------------------------------------------------------
    Nonetheless, as you mentioned for my reference, now I may know more about the purpose of the gel script.
    Thanks.

    J.W.
  • Josh,

    I understand that and should have been clearer. The project I sent you performs the initialization of the hardware as the CCS debugger would have done via the GEL file, which involves configuring the PLL, DDR, etc.

    Therefore, after loading this code and running it until it finishes the initialization, you should have a completely configured HW and peripherals (DDR, PLLs, etc.) ready to load any executable that makes use of the DDR memory - including the Starterware projects. That is true as long as you don't reset the device before (or after) loading your code, since the HW initialization would have to be re-done.

    This exercise illustrates what you would do for your production code at a later stage in development - after all, with a standalone product you would not have the whole debug infrastructure to "start up the processor" and therefore the initialization file provided in the project I sent will still be useful.

    I hope I haven't complicated matters too much, but feel free to ask further questions.

    Regards,
    Rafael
  • OK Rafael,

    I did not catch the idea. That is interesting. With your sample project I may perform HW initialization, then switch to another project, and debug it (with XDS110) without a GEL ("initialization script" field in "Target Configuration" window) .

    Formerly, I used AIS bootloader for standalone SW and did not look at what the GEL was doing in debug environment. Now it is clear.

    Regards.
    J.W.