EXPKITOMAPL138_ARM.gel script from CCS 5.5 reports errors writing to target

I also tried with CCSv6 beta 3, and got the same error.

From looking at the previously attached debug server logging, prior to the point at which the GEL script reported a target write failure there are some errors of the form "Internal error: Access to unknown or invalid register was requested....".

Not sure if these errors cause the GEL script failure, but there does appear to be one bug on how failures to find a register ID are handled.

Error from the first connection attempt:

0x000009EC 134187 3 ARM9_0 TA C: GetRegisterId( ETM_TRACE_ENABLE_CTL2, 36FAB948 )
0x000009EC 134187 3 SETUP I: SELECT Registers.dbid AS dbid, Register_Cache.Name AS Name, Registers.Name AS Alias, Register_Cache.Address AS Offset, Register_Cache.Page AS Page, Registers.Width AS Width, Register_Cache.Module AS Module, Registers.Description AS Description FROM Register_Cache, Registers WHERE Register_Cache.Register=Registers.dbid AND Register_Cache.Name=@Name AND Register_Cache.Processor=@ProcessorID
0x000009EC 134187 3 ARM9_0 TA R: GetRegisterId( ETM_TRACE_ENABLE_CTL2, *36FAB948 = 0x6E750000 ) = -1
0x000009EC 134187 3 ARM9_0 TA C: RegisterWrite( 0x6E750000, 0x00000000 )
0x000009EC 134187 3 ARM9_0 GTI C: GTI_WRITEREG( 0x36F455B0, 0x6E750000, *0x30CFCBE0 = 0x00000000 )
0x000009EC 134187 3 ARM9_0 GTI R: GTI_WRITEREG( 0x36F455B0, 0x6E750000, *0x30CFCBE0 = 0x00000000 ) = 0xFFFFFFFF
0x000009EC 134187 3 ARM9_0 GTI C: GTI_GETERRSTR_EX3( 0x36F455B0, *0x30CFC560 = 0x00000000, *0x30CFC540 = 0x00000000, *0x30CFC55C = 0x00000000, *0x30CFC538 = 0x00000000, *0x30CFC558 = 0x00000000, *0x30CFC554 = 0x00000000, *0x30CFC54C = 0x00000000, "", 0x00000040, "", 0x00000400 )
0x000009EC 134187 3 ARM9_0 GTI R: GTI_GETERRSTR_EX3( 0x36F455B0, *0x30CFC560 = 0x00000006, *0x30CFC540 = 0xFFFFF812, *0x30CFC55C = 0x00000004, *0x30CFC538 = 0x00000002, *0x30CFC558 = 0x00000000, *0x30CFC554 = 0x00000008, *0x30CFC54C = 0x00000000, "", 0x00000040, "(Error -2030 @ 0x6E750000)
Internal error: Access to unknown or invalid register was requested. Restart the application. If error persists, please report the error.
(Emulation package 5.1.402.0)
", 0x00000400 ) = 0x00000001
0x000009EC 134187 3 ARM9_0 GTI C: GTI_GETERRSTR_EX3( 0x36F455B0, *0x30CFC498 = 0x00000000, *0x30CFC478 = 0x00000000, *0x30CFC494 = 0x00000000, *0x30CFC470 = 0x00000000, *0x30CFC490 = 0x00000000, *0x30CFC48C = 0x00000000, *0x30CFC484 = 0x00000000, "", 0x00000040, "", 0x00000400 )
0x000009EC 134187 3 ARM9_0 GTI R: GTI_GETERRSTR_EX3( 0x36F455B0, *0x30CFC498 = 0x00000000, *0x30CFC478 = 0x00000000, *0x30CFC494 = 0x00000000, *0x30CFC470 = 0x00000002, *0x30CFC490 = 0x00000000, *0x30CFC48C = 0x00000008, *0x30CFC484 = 0x00000000, "", 0x00000040, "", 0x00000400 ) = 0x00000000

Error from the second connection attempt:

0x000009EC 704328 3 ARM9_0 TA C: GetRegisterId( ETM_TRACE_ENABLE_CTL2, 36F71E38 )
0x000009EC 704328 3 SETUP I: SELECT Registers.dbid AS dbid, Register_Cache.Name AS Name, Registers.Name AS Alias, Register_Cache.Address AS Offset, Register_Cache.Page AS Page, Registers.Width AS Width, Register_Cache.Module AS Module, Registers.Description AS Description FROM Register_Cache, Registers WHERE Register_Cache.Register=Registers.dbid AND Register_Cache.Name=@Name AND Register_Cache.Processor=@ProcessorID
0x000009EC 704328 3 ARM9_0 TA R: GetRegisterId( ETM_TRACE_ENABLE_CTL2, *36F71E38 = 0x000C0006 ) = -1
0x000009EC 704328 3 ARM9_0 TA C: RegisterWrite( 0x000C0006, 0x00000000 )
0x000009EC 704328 3 ARM9_0 GTI C: GTI_WRITEREG( 0x348E55B0, 0x000C0006, *0x30CFCBE0 = 0x00000000 )
0x000009EC 704328 3 ARM9_0 GTI R: GTI_WRITEREG( 0x348E55B0, 0x000C0006, *0x30CFCBE0 = 0x00000000 ) = 0xFFFFFFFF
0x000009EC 704328 3 ARM9_0 GTI C: GTI_GETERRSTR_EX3( 0x348E55B0, *0x30CFC560 = 0x00000000, *0x30CFC540 = 0x00000000, *0x30CFC55C = 0x00000000, *0x30CFC538 = 0x00000000, *0x30CFC558 = 0x00000000, *0x30CFC554 = 0x00000000, *0x30CFC54C = 0x00000000, "", 0x00000040, "", 0x00000400 )
0x000009EC 704328 3 ARM9_0 GTI R: GTI_GETERRSTR_EX3( 0x348E55B0, *0x30CFC560 = 0x00000006, *0x30CFC540 = 0xFFFFF812, *0x30CFC55C = 0x00000004, *0x30CFC538 = 0x00000002, *0x30CFC558 = 0x00000000, *0x30CFC554 = 0x00000008, *0x30CFC54C = 0x00000000, "", 0x00000040, "(Error -2030 @ 0xC0006)
Internal error: Access to unknown or invalid register was requested. Restart the application. If error persists, please report the error.
(Emulation package 5.1.402.0)
", 0x00000400 ) = 0x00000001
0x000009EC 704328 3 ARM9_0 GTI C: GTI_GETERRSTR_EX3( 0x348E55B0, *0x30CFC498 = 0x00000000, *0x30CFC478 = 0x00000000, *0x30CFC494 = 0x00000000, *0x30CFC470 = 0x00000000, *0x30CFC490 = 0x00000000, *0x30CFC48C = 0x00000000, *0x30CFC484 = 0x00000000, "", 0x00000040, "", 0x00000400 )
0x000009EC 704328 3 ARM9_0 GTI R: GTI_GETERRSTR_EX3( 0x348E55B0, *0x30CFC498 = 0x00000000, *0x30CFC478 = 0x00000000, *0x30CFC494 = 0x00000000, *0x30CFC470 = 0x00000002, *0x30CFC490 = 0x00000000, *0x30CFC48C = 0x00000008, *0x30CFC484 = 0x00000000, "", 0x00000040, "", 0x00000400 ) = 0x00000000
0x000009EC 704328 3 ARM9_0 TA R: RegisterWrite( 0x000C0006, 0x00000000 ) = -1

1) A call to GetRegisterId( ETM_TRACE_ENABLE_CTL2) returns a failure status of -1, as the register can't be found on the ARM9 core.

2) Since the GetRegisterId call has failed, the returned register address is undefined - on the first attempt it is 0x6E750000 and on the second attempt 0x000C0006

3) The undefined register address from the failed GetRegisterId call is then used in a call to GTI_WRITEREG. In these two attempts the undefined register address which is passed to GTI_WRITEREG results in GTI_WRITEREG reporting an error the register is unknown.

Shouldn't CCS detect when GetRegisterId fails to find a named register, rather than continue and attempt to access an undefined register on the target?

[I haven't checked to see which driver / DLL is causing this behavior]

Hi Chester,

Chester Gillon said:

The onboard XDS100v1 is being used. Note that in the target configuration, a XDS100v2 was selected, since in CCS 5.5 where there is no driver support for a OMAP L138 with a XDS100v1.

Note that the XDS100v1 does not support ARM. People who have tried to use the onboard XDS100v1 with the ARM9 of the L138 have run into various known issues. We don't really have a good workaround for it other than recommending using an external emulator that supports ARM9 (like XDS100v2)

ki

Ki-Soo Lee said:

Note that the XDS100v1 does not support ARM. People who have tried to use the onboard XDS100v1 with the ARM9 of the L138 have run into various known issues

An XDS100v2 should do the job.

On a side note, I do find it a bit confusing why the board manufacturers would have on-board emulation that only supports one of the two cores on the device. Doesn't make sense to me unless they simply reused everything for the C6748 board and kept the XDS100v1 for cost reasons...

Ki-Soo Lee said:

Note that the XDS100v1 does not support ARM. People who have tried to use the onboard XDS100v1 with the ARM9 of the L138 have run into various known issues. We don't really have a good workaround for it other than recommending using an external emulator that supports ARM9 (like XDS100v2)

ARM9_0: Output:  Memory Map Cleared.
ARM9_0: Output:  ---------------------------------------------
ARM9_0: Output:  Memory Map Setup Complete.
ARM9_0: Output:  ---------------------------------------------
ARM9_0: Output:  Enabling Experimenter PSCs...
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) [EXPKITOMAPL138_ARM.gel:25]  at device_PLL0(0, 24, 1, 0, 1, 11, 5) [EXPKITOMAPL138_ARM.gel:405]  at Set_Core_300MHz() [EXPKITOMAPL138_ARM.gel:464]  at Core_300MHz_mDDR_150MHz() [EXPKITOMAPL138_ARM.gel:252]  at OnTargetConnect() .
ARM9_0: Trouble Writing Memory Block at 0xc3000000 on Page 0 of Length 0x7ff0: (Error -2030 @ 0xC0006) Internal error: Access to unknown or invalid register was requested. Restart the application. If error persists, please report the error. (Emulation package 5.1.402.0)
ARM9_0: GEL: File: C:\Documents and Settings\Mr_Halfword\workspace_v5_5_omap_L138\hello_EXPKITOMAPL138_ARM9\Debug\hello_EXPKITOMAPL138_ARM9.out: Load failed.
ARM9_0: Unable to terminate memory download: NULL buffer pointer at 0x320
ARM9_0: Error: (Error -1033 @ 0x3FF) Instruction bus is 'not ready'. Choose 'Abort' to try to abort the pending transaction. Choose 'Force' to try to force the bus ready state. (Emulation package 5.1.402.0)

Chester Gillon said:

With the Spectrum Digital XDS100v2 I am still getting the same error when trying to run the EXPKITOMAPL138_ARM.gel script

Chester Gillon said:

With the Spectrum Digital XDS100v2 I am still getting the same error when trying to run the EXPKITOMAPL138_ARM.gel script

When the "JTAG TCLK Frequency" was changed to "Adaptive with user specified limit" and a limit of 1MHz, both CCS 5.5 and CCS 6 beta 3 were able to successfully run the EXPKITOMAPL138_ARM.gel and download a SYS/BIOS program in DDR memory.

The point which the EXPKITOMAPL138_ARM.gel failed when using a "Fixed default 1.0MHz frequency" was when the GEL script was configuring the PLL0 - and so guess the act of changing the internal PLL0 was triggering a JTAG failure due to not using adaptive clocking.

Ki-Soo Lee said:

Note that the XDS100v1 does not support ARM. People who have tried to use the onboard XDS100v1 with the ARM9 of the L138 have run into various known issues. We don't really have a good workaround for it other than recommending using an external emulator that supports ARM9 (like XDS100v2)

a) The device has an ARM core which required adaptive clocking.

b) The selected emulator supports adaptive clocking

Ki-Soo Lee said:

There was a request for this in the past and I'm pretty sure a bug was filed for this. Looks like it still has yet to be implemented. Time for a repush on this issue..

Yep there was a bug filed for this: SDSCM00039843. Should have been fixed for CCSv5.1. But looks like it is not working (at least in recent v5 builds)! I'll reopen this one.

Thanks

ki

Ki-Soo Lee said:

Yep there was a bug filed for this: SDSCM00039843. Should have been fixed for CCSv5.1. But looks like it is not working (at least in recent v5 builds)! I'll reopen this one.

I filed a new bug as SDSCM00049602. I was able to determine that 39843 was working until CCSv5.3.0. It stopped working for CCSv5.4.0 and greater.

Yes, this is correct, the default was set automatically in CCSv5.1 but broke in CCSv5.4.  

The work around is still to go to the advanced page, connection properties, in the target configuration editor, and manually change the TCLK frequency to adaptive.

The new fix will be available in CCSv6.0.

wallace said:

It looks like the bug came back again in CCSv7 ( 7.2.0.00013). My configuration,

board : LCDKOMAPL138
probe : XDS110 usb debug probe
project : uart (StarterWare example)

I got similar error when trying to debug the starterware example or my own project. The problem is, there is no way to apply the workaround in CCSv7 since the only options available are: "Fixed default 2.5MHz frequency" and "Fixed with user specified value".

Based upon my previous test where the GEL file failed when initialising the PLL even when a fixed JTAG frequency of 1MHz failed not sure if you will be able to get the XDS110 to work, or if you will have to change to a debug probe such as a XDS100v2 which supports adaptive clocking.

wallace said:

But XDS110 does not work better at 100.0 kHz, which is the lowest frequency available in CCS.

I haven't yet tried connecting a XDS110 to an OMAPL138, with with CCS 7.2 did confirm that:

a) With Blackhawk USM560-M, 20 pin JTAG cable connected to a OMAPL138 with a fixed JTAG TCLK of 1MHz the connection was reliable. Whereas with a fixed JTAG TCLK of 1.5MHz the connection became un-reliable in that the EVMOMAPL138_ARM.gel GEL script failed with:

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) [EVMOMAPL138_ARM.gel:25]
	 at device_PLL0(0, 24, 1, 0, 1, 11, 5) [EVMOMAPL138_ARM.gel:405]
	 at Set_Core_300MHz() [EVMOMAPL138_ARM.gel:464]
	 at Core_300MHz_mDDR_150MHz() [EVMOMAPL138_ARM.gel:252]
	 at OnTargetConnect()

b) When the fixed XDS110 JTAG TCLK frequency was reduced set in the CCS Target Configuration to 100KHz the actual TCLK frequency measured by a LSA was 100 KHz.

i.e. agree that lowering the XDS110 JTAG TCLK should work.

With JTAG TCLK set at 100.0 kHz I got the below log. Now I hope somebody will confirm that XDS110 works with LCDKOMAPL138, In which case there will really be an issue on my side. 

--------------------------------------------------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------------------

Notice that when I click  "Test Connection" in Target configuration, the test seems to succeed but It also outputs the following log, which is not reassuring:

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the XDS110 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for XDS110 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

---------------------------------------------------------------------------------------------

Thanks.