L138 emulator recommendation

Rahul,

I have looked at the XDS510 USB and XDS560 V2 traveler info at Spectrum Digital site and the wiki article. Very probably I am going to pick one among them. Thanks for your recommendation.

Paul

Rahul,

Have you ever tried using any of Spectrum Digital’s

1. XDS510USB
2. XDS510USB Plus
3. XDS560USB V2 STM

to debug power saving modes of OMAP L138? We actually want to see if errors happened when debugging power-saving modes are due to potential fallacies with our current Seed International XDS560 plus emulator.

When trying to put ARM core into wait-for-interrupt sleep mode we see the following error message

CCS error message said:

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 5.0.569.0) 

The problem has also been reported in Error -1029 @ 0x2B5F when changing ARM926 clock but haven’t got responded so far.

In addition, with the ARM core on we were able to put DSP core into sleep mode using the Seed International emulator,  and the current decrease is noticeable form the external power supply reader; however this is also quite unstable and the emulator’s connection to ARM core would frequently get disrupted, say 3 out of 5 times.

So I would like to know which emulator people at TI are using when debugging these power-saving modes? This is one of the very few outstanding problems of our project and we are in a certain urgency to get it solved ASAP.

Rahul,

Thanks for sharing the experience on XDS510USB Plus. I am going to have a try with them.

Rahul,

I am currently debugging DEEPSLEEP mode with SpectrumDigital’s XDS560V2 STM emulator. After having put the device into DEEPSLEEP mode, the connection between the compiler and the emulator got disrupted with the following message:

CCS debugging error message said:

ARM9_0: Can't Run Target CPU: (Error -1066 @ 0x3332) Unable to set requested breakpoint in memory. Verify that the breakpoint address is in writable memory. (Emulation package 5.0.681.0)

ARM9_0: Trouble Halting Target CPU: (Error -184 @ 0x2A4E) The controller has detected a failure in its connection to the target. This often implies one of the following errors: 1. The target cable is disconnected near-to the controller. 2. The target cable is disconnected far-from the controller. 3. The target system has lost its JTAG clock. 4. The target system has lost its power supply. (Emulation package 5.0.681.0)

ARM9_0: Error: Failed to get PRSC status

ARM9_0: Trouble Halting Target CPU: (Error -181 @ 0x277D) The controller has detected a dead JTAG clock. The user must turn-on or connect the JTAG clock for the target. (Emulation package 5.0.681.0)

ARM9_0: Error: Failed to get PRSC status

ARM9_0: Trouble Halting Target CPU: (Error -181 @ 0x277D) The controller has detected a dead JTAG clock. The user must turn-on or connect the JTAG clock for the target. (Emulation package 5.0.681.0)

ICEPICK_C: JTAG Communication Error

ARM9_0: Error: Failed to get PRSC status

ARM9_0: Trouble Halting Target CPU: (Error -181 @ 0x277D) The controller has detected a dead JTAG clock. The user must turn-on or connect the JTAG clock for the target. (Emulation package 5.0.681.0)

ICEPICK_C: 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

Rahul Prabhu said:

I have used XDS510USB Plus while debugging OMAPL137/C6747 part in power saving modes but don`t recollect having any reliability issue.

Did you meet the same problem? Or perhaps it is the expected behavior because DEEPSLEEP mode is supposed to gate all clocks which of course disrupts emulator connection, since emulator would need to see some response from or valid signal on the device to know whether the connection is successful. So perhaps the connection problem it is just what it should look like, an indication that the DEEPSLEEP mode did have worked?

Paul

Hello,

Here's an unverified suggestion:

The clock loss means perhaps the emulator return clock (JTAG RTCK signal from the CPU) loss; it is replicated from the emulator clock (JTAG TCK signal).

 You may try to configure the emulator from some "adaptive TCK" mode (RTCK needed to find the best JTAG clock frequency) to a "fixed frequency" or "counter" mode (which won't use RTCK). With some luck, entering the deep sleep mode will then be silent.

Jakez

Jakez,

I did have a test of the idea.

First, the default target configuration for Spectrum Digital XDS560 V2 uses "Adaptive with user specified limit", for which the connection got lost during DEEPSLEEP.

Second, if I choose "Adaptive without any limit at all", there would be a error message when connecting:

error message said:

Error connecting to the target:
(Error -507 @ 0x0)
The user selected asynchronous adaptve frequency failed the scan-path test.
The utility or debugger requested the JTAG controller and cable,
that generate the JTAG clock, to use a user selected feature or
algorithm.  The built-in scan-path reliability test has failed.
This indicates that the JTAG controller and its cable cannot reliably
communicate with the target system using that feature or algorithm.
(Emulation package 5.0.681.0)

Not sure if I am understanding on the RTCK mechanism you mentioned is correct. But at least for the two "adpative" modes on SD emulator the connection is either unsuccessful at the beginning or get lost during DEEPSLEEP.

It is nevertheless a minor problem since I could simply just reconnect. A caveat is that the initialization GEL should better be unloaded for reconnection, since usually initialization GEL script contian the "OnTargetConnect()" function which would be executed and reinitialize the chip to result in state change. Anyway it is a small problem and I already come to terms with it.

Paul