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.

JTAG error: Unable to access the DAP

Other Parts Discussed in Thread: TMS570LS3137, UNIFLASH

Dear Sir/Madam!

We experience strange problems with JTAG on TMS570LS3137. After executing our code that was supposed to initialize CAN interface, we were no longer able to use JTAG to work with the CPU. In CCS 5.3.0, we get the following error (we use XDS100v2 emulator):

CortexR4: Error connecting to the target: (Error -1206 @ 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 5.0.872.0)

When we run Target Configurations -> TMS570LS3137.ccxml -> Test Connection, no error is reported (see the log at the end of this message).

Do you have any idea what could have happened to the CPU? Can it be that JTAG security module (AJSM) got incidentally activated?

Additional information:

  • The problem is reproducible. We "damaged" two boards this way.
  • JTAG broke when our code was executed/debugged, not during FLASH programming. We successfully loaded the program (to one board with CSS, to the second board with UniFlash tool). Then we used CCS to step through the program, which was the  last thing done with the board.
  • The code was not compiled by CCS, we used the GCC compiler shipped with http://www.arccore.com/products/arctic-studio/.
  • We tried OpenOCD to communicate with the board - it get into an infinite loop somewhere in the ARM target handling code. No meaningful error was produced by OpenOCD.

Best regards,
-Michal Sojka

Test connection log: 

[Start]
 
Execute the command:
 
%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity
 
[Result]
 
 
-----[Print the board config pathname(s)]------------------------------------
 
C:\Users\Leos\AppData\Local\.TI\693494126\
    0\0\BrdDat\testBoard.dat
 
-----[Print the reset-command software log-file]-----------------------------
 
This utility has selected a 100- or 510-class product.
This utility will load the adapter 'jioserdesusb.dll'.
The library build date was 'Oct  3 2012'.
The library build time was '21:58:41'.
The library package version is '5.0.872.0'.
The library component version is '35.34.40.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '4' (0x00000004).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.
 
-----[Print the reset-command hardware log-file]-----------------------------
 
The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 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).
 
-----[The log-file for the JTAG TCLK output generated from the PLL]----------
 
There is no hardware for programming the JTAG TCLK frequency.
 
-----[Measure the source and frequency of the final JTAG TCLKR input]--------
 
There is no hardware for measuring the JTAG TCLK frequency.
 
-----[Perform the standard path-length test on the JTAG IR and DR]-----------
 
This path-length test uses blocks of 512 32-bit words.
 
The test for the JTAG IR instruction path-length succeeded.
The JTAG IR instruction path-length is 6 bits.
 
The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.
 
-----[Perform the Integrity scan-test on the JTAG IR]------------------------
 
This test will use blocks of 512 32-bit words.
This test will be applied just once.
 
Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.
 
The JTAG IR Integrity scan-test has succeeded.
 
-----[Perform the Integrity scan-test on the JTAG DR]------------------------
 
This test will use blocks of 512 32-bit words.
This test will be applied just once.
 
Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.
 
The JTAG DR Integrity scan-test has succeeded.
 
[End]
 



  • Hello Mikal,

    Can you share more details on the code you are programming into the device? The best alternative would be to zip and attach the project to this thread, but in case this is not possible due to proprietary information, you can post a detailed description/psuedo code so we can see what steps are being taken in your code.

  • Hi Chuck,

    the code is open-source and is available from our repository. It is not easy to understand, though. The main application is tms570_hdk_can.   As I've written, we don't use CCS to compile it; we use the makesystem in the project and free toolchain shipped with Arctic Studio. The binary that caused the problem is 7418.com_simple_mpc5516it.elf.zip (don't look at the file name, the project was started by copying from another board).

    Thanks for your help and let us know if you need more information. We afraid to experiment with the hardware before we find out what was wrong. We have only few prototypes of our board.

    Best regards,
    -Michal

  • Hello Michal,

    Thanks for the additional information. I will have a look at the source to see if I can see anything that might be causing a problem. I don't have your tools installed so I will try and see if I can see anything through simple inspection to start.

    In the meantime, we have seen some success in recovering devices by asserting nPORRST just after the programming tool starts the connect sequence. This frees up the CPU from whatever is occupying it's cycles and allows the debugger/JTAG tool to take control of the core. This can be tricky as it is very timing dependent and could require multiple attempts with random timing.

    In other cases, I have seen it help if nRST is asserted after loading the code. This may clear out some random RAM content that is causing the program to run errantly into "no man's land." However, this method may also only offer limited success after many iterations.

  • Hello Mikal,

    One more question. Did you have any success running your application in the device prior to adding the DCAN code?

  • Chuck Davenport said:

    One more question. Did you have any success running your application in the device prior to adding the DCAN code?

    Yes, we successfully run a LED blinkin application. DCAN application also run before we added initialization of the second CAN interface.

    I'll try  playing with nPORRST later today or tomorrow.

    Thanks,
    -Michal

  • Michal,

    Can you try the following sequence?

    1] Start CCS and launch your target configuration.
    2] In the debug windows, right click on your emulator and select "Show all Cores"
    3] Expend Non-Debuggable Devices.
    4] Right click on emulator/IcePick and select connect target. (This should work)
    5] Right click on emulator/Dap and select connect target.
    5.1] If this is working, go to 6
    5.2] If this is not working, there is a lot of chance you have lock the part with AJSM.
    6] Open a memory windows at address 0xFFFF_FF00 (system module)
    7] write 0x00 at address 0xFFFF_FFFE This will generate a system reset.
    8] In the debug windows, right click on emulator/CortexR0 and select Connect Target.
    9] If this is ok, go to Tools->On-Chip Flash. Erase Option "Entire Flash" and click on "Erase Flash"
    10] Disconnect, reset and restart your debugger as usual. It should work now.

    11] At that point, the code in flash is forcing the device in some kind of lock mode. A deep debug is necessary.

  • Hello Michal,

    Have you had a chance to try the process Jean-Marc describes in his post? If so, does this provide any determination of the state of the device or does it allow you to connect and debug the device?

  • Dear Jean-Marc,

    I followed you sequence. Step 5 was successful. After step 6 console window showed:

    Dap: Trouble Reading Memory Block at 0xfffffd00 on Page 0 of Length 0x300: (Error -1170 @ 0xFFFFFD00) 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 5.0.872.0)

    Despite of that, I continued with step 7 and the result was similar:

    Dap: Trouble Writing Memory Block at 0xfffffffe on Page 0 of Length 0x1: (Error -1170 @ 0xFFFFFFFC) 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 5.0.872.0)

    Then, step 8 produced the well known an error box:

    Error connecting to the target:
    (Error -1206 @ 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 5.0.872.0)

    Do you have any other idea what we can try?

    (BTW we tried your procedure with working board and steps 6 and 7 didn't generate the errors and we could see the content of system module memory.)

    Best regards,
    -Michal

  • Michal,


    Can you try the following?

    After step 4 (Connect IcePick) and before step 5, click on Run->Reset->System Reset.
    Than continue with step 5 (Connect DAP)
    If DAP is able to connect, you can open a memory window and display the content of 0x0000_0000 (Flash) or 0x0800_0000 (RAM)
    It should be possible to modify the RAM content from the memory window.

    Please let me know the result of these tests.

  • I can read neither from Flash nor from RAM:

    Dap: Trouble Reading Memory Block at 0x0 on Page 0 of Length 0x320: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. 

    -Michal

  • Hi,

    is there anything else we can try or the CPUs are dead?

    Thank you,
    -Michal

  • Hi Jean-Marc Mifsud,

    I am Facing similar problem as discussed in this post for my LM4F232H5QD. I am using XDS100v2 JTAG Emulator for flashing the code on my custom board. Its working well with the LM4F232 Evaluation board. Even I tried with flashing the code using CCS Uniflash but it is the same. Following is the error I am getting when loading the program.

    ********************************************************************************************************************************

    CORTEX_M4_0: GEL Output:
    Memory Map Initialization Complete
    Texas Instruments XDS100v2 USB Emulator_0/CS_DAP_0 : Target must be connected before loading program.
    CORTEX_M4_0: GEL Output: Watchdog Timer Enabled
    CORTEX_M4_0: GEL Output: UARTs Enabled
    CORTEX_M4_0: Trouble Writing Memory Block at 0x400fd008 on Page 0 of Length 0x4: (Error -1204 @ 0x400FD008) 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 5.0.872.0)
    CORTEX_M4_0: Trouble Writing Memory Block at 0x400fd000 on Page 0 of Length 0x4: (Error -1203 @ 0x400FD008) 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 5.0.872.0)
    CORTEX_M4_0: Trouble Writing Memory Block at 0x400fd008 on Page 0 of Length 0x4: (Error -1203 @ 0x400FD008) 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 5.0.872.0)
    CORTEX_M4_0: Failed Software Reset
    CORTEX_M4_0: Trouble Writing Memory Block at 0x400fe0f0 on Page 0 of Length 0x4: (Error -1203 @ 0x400FE000) 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 5.0.872.0)
    CORTEX_M4_0: Trouble Writing Memory Block at 0x20000000 on Page 0 of Length 0x8c: (Error -1203 @ 0x20000000) 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 5.0.872.0)
    CORTEX_M4_0: Trouble Writing Memory Block at 0x20000400 on Page 0 of Length 0x560: (Error -1203 @ 0x20000400) 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 5.0.872.0)
    CORTEX_M4_0: Can't Run Target CPU: (Error -1203 @ 0x20000400) 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 5.0.872.0)
    CORTEX_M4_0: Flash Programmer: Error while writing to Flash memory
    CORTEX_M4_0: GEL: File: D:\TI workspace\blinky\Debug\blinky.out: Load failed.
    ***********************************************************************************************

    I am able to erase the flash but getting failure message for BlankCheck as mentioned below. Even I tried with the lower TCLK.

    ERROR >> CORTEX_M4_0: Flash Programmer: Error during Blank Check @ address 0x0001B800; expected 0xFFFFFFFF, actual 0xFFFFFFBF
    ERROR >> CORTEX_M4_0: Flash Programmer: Error performing Blank Check.

    As per the hardware is concern, my schematic is same as the Eval board schematic for clock, reset and JTAG.

    Please suggest me the solution for this problem

    Thank you very much in advance.

    Regards,

    - Anand

  • Given the length of time since the last activity on this thread, I assume the issue has been resolved and this thread will be closed. If any additional questions or related issues arrise, please let us know by opening a new thread.

    Anand,

    The LM4F232 is not supported through this forum since this forum is specific to the Hercules product line and your device uses a different Flash IP than the Hercules line of MCUs. If you are still experiencing issues, I would suggest you post your questions in the Tiva/Stellaris forum since they would be better suited to answer your question.

  • Hi,

    Has this issue been solved ? I have bought a launchpad to evaluate the product and I am having a similar issue:

    CortexR5: Error connecting to the target: (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.14.6)

    I have been browsing the forum for hours now and can't find a solution that works for me. The issue happened once I had loaded the code and I was stepping through it with the debugger.

    Jonathan
  • Hi,

    this has not been solved. Our conclusion is that the CPU is simply dead.
  • Hi Jonathan,

    Normally it would be best to start a new thread rather than add to an old existing thread since usually the older threads have been closed. In the mean time, the type of error you are describing is usually a result of no response from the MCU when it tries to connect. You may want to try having a look at the power connections, the crystal/OSCIN, and even the USB cable used for JTAG/Power. If, once you look at all of these parts of the board, you still are experiencing the same issue, please open a new thread and describe exactly what was going on when the issue occurred. i.e., code was executing or not, the device had connected previously and debug worked, this was the first attempt at debug, etc. If possible, zip up your project and post it as well.

  • Hi Mr Davenport,

    The USB cable and power connections look good. I have no way right now to check the crystal/OSCIN however. I have opened a thread to describe the issue.

    Thanks,

    Jonathan