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: AM335x JTAG debug question

Tool/software: Code Composer Studio

Hi,

I'm debugging a very ugly crash on a am335x custom board that completely freeze the board.

I attached an XDS100v2 JTAG debugger to see what appened at register level to know if this problem is HW or SW.

When system crash JTAG lost control of  cortexa8 and give the following errors:

CS_DAP_DebugSS: Error: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 6.0.628.3)
CortxA8: Error: (Error -1170 @ 0x0) Unable to access the DAP. 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)
CortxA8: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. 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)

....

CortxA8: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. 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)
CortxA8: Error: (Error -1170 @ 0x0) Unable to access the DAP. 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)
CortxA8: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. 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)
CortxA8: Unable to determine target status after 20 attempts
CortxA8: 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

I can't reconnect to the Probe0/CortexA8 but I can connect directly to the Probe0/CS_DAP_DebugSS and I able to watch entire memory DDR and memory mapped registers.

I'm interested to see the values of the SPSRs register but I don't understand if these registers are memory mapped.

Is possible to watch these registers using DAP?

Are there any other register that could help me to see what's happening?

Regards,

Matteo

  • Matteo,

    Unfortunately these fatal crashes are difficult to debug.

    You are on the right track by accessing the DAP and checking the device's memory, but unfortunately the core registers are not memory mapped and therefore you will not be able to access any xPSR registers (CPSR or SPSR) rom the DAP.

    One detail you can try is to enable HW breakpoints at exceptions. You can try to connect to the Cortex A8 core at power up (before the crash occurs), then go to menu Tools → ARM Advanced Features and scroll to the bottom to enable the trap breakpoints.

    After enabling all this (or perhaps only the ones you are suspicious), you put the core to run and follow the steps to make the system crash again - if the crash is not too severe and the core does not reset, it should halt at the corresponding exception, thus allowing you to investigate even further what may have happened. 

    If the issue is happening during power transition modes that cause the device to reset, all breakpoints are cleared and you will not be able to halt at the exceptions. You can, however, trap the core at reset by enabling the Halt on Reset feature. With the device connected, go to the Debug view and select the option below:

    I have never tried this, but another route is to enable trace via ETB before the scenarios above and check the immediate execution history of the core. To enable Trace, go to menu Tools --> Hardware Trace Analyzer and select PC Trace (if you are running for the first time, it will require some time to initialize the Trace Use Cases). The default settings are OK for this:

    One thing I am not entirely sure is if the ETB Trace information is preserved during exceptions or Resets, but it may be worth trying. 

    I will try to think about any additional tips that may help you to track this problem and report back. 

    Hope this helps,

    Rafael

  • Hi, Rafael...

    thank you very much for your helpful post.

    At first, I use the "Arm Advanced Feauture" and in the "Non-Secure" section I try to set "Break on Undefined Instruction" and "Break on Data Abort".
    I expected that kernel runs and break only for a not recognized instruction or for a virtual memory fault but, after that I enable these breaks, kernel stop immidiatly and continue to stopping like as these exception are used in the normal kernel activity.
    Is it right or there are something that I wrong?

    At second, using tracer, It seems that last instruction to be executed is always:
    l *0xc03d03ee
    0xc03d03ee is at arch/arm/xenomai/switch.S:184.
    179 clear_exclusive_monitor
    180 switch_tls r1, r4, r5, r3, r7
    181 #ifdef USE_DOMAINS
    182 mcr p15, 0, r6, c3, c0, 0 @ Set domain register
    183 #endif
    184 fpu_switch r4
    185 ARM( add r4, r2, #TI_CPU_SAVE )
    186 ARM( ldmia r4, {r4 - sl, fp, sp, pc} ) @ Load all regs saved previously
    187 THUMB( add ip, r2, #TI_CPU_SAVE )
    188 THUMB( ldmia ip!, {r4 - sl, fp} ) @ Load all regs saved previously

    For the moment I don't uderstand if the instruction in line 184 could be couse the block...
    There is any other tool in CCS that I use to better investigate?

    Thanks,
    Matteo
  • Hi Matteo,

    Please apologize for the delay; I lost track of this thread.

    Your questions are very related to the device and kernel, therefore I will ask for help from the Sitara experts (I work with Code Composer Studio).

    Matteo Facchinetti1 said:
    after that I enable these breaks, kernel stop immidiatly and continue to stopping like as these exception are used in the normal kernel activity.
    Is it right or there are something that I wrong?

    I don't know how the kernel operates, but there is a possibility that certain exceptions are used in a regular basis. I would need the help of a Linux expert to comment. 

    Matteo Facchinetti1 said:

    179 clear_exclusive_monitor
    180 switch_tls r1, r4, r5, r3, r7
    181 #ifdef USE_DOMAINS
    182 mcr p15, 0, r6, c3, c0, 0 @ Set domain register
    183 #endif
    184 fpu_switch r4
    185 ARM( add r4, r2, #TI_CPU_SAVE )
    186 ARM( ldmia r4, {r4 - sl, fp, sp, pc} ) @ Load all regs saved previously
    187 THUMB( add ip, r2, #TI_CPU_SAVE )
    188 THUMB( ldmia ip!, {r4 - sl, fp} ) @ Load all regs saved previously

    For the moment I don't uderstand if the instruction in line 184 could be couse the block...
    There is any other tool in CCS that I use to better investigate?

    From a CCS perspective you are using the available tools at your disposal. I am not very familiar with the instruction highlighted, but perhaps a device expert may know better. 

    Regards,

    Rafael