OMAPl138 does not work with XDS100v2

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) [OMAPL138_ARM.gel:16]
at device_PLL0(0, 24, 1, 0, 1, 11, 5) [OMAPL138_ARM.gel:400]
at Set_Core_300MHz() [OMAPL138_ARM.gel:459]
at Core_300MHz_mDDR_150MHz() [OMAPL138_ARM.gel:247]
at OnTargetConnect()

Hi,

Which CCS version are you using (You said CCSv6.x) ?
Could you please try it on CCSv6.1 and CCSv5.5.

I use already 6.1. 6.x was a typo. And my first try was with 5.5 . No difference.

For the refference im using a XDS from OlIMEX , if not clear : look at log.loetlabor.org/.../LoetLab_TI_XDS100v2_20082015.jpg

And i have the TMDXLCDK138 , the obsolet Version of the LCDK's the new one is the TMDSLCKDK138.

Greetings!

Dear TI,

i do have the same problem with the same hardware. I am using the TMDXLCDK138 with an OLIMEX XDS100v2 and CCS 6.1.0.00104 with a full license. All hardware is new and unsed. The XDS100v2 has been updated, flashed but nothing changed.

I tried the "specific" clock setting with 1MHz as well as the "adaptive" configuration. In order to ease the process for you, i am giving you the complete LOGs as well as the ccBoard0.dat files attached. They are named as follows:

Log files:

• log_specific_connectionTest.txt (connection test log with specific 1 MHz clock)
• log_specific_connectionARM9.txt (target connection log to ARM9 core with specific 1MHz clock)
• log_adaptive_connectionTest.txt (connection test log with adaptive 1MHz clock)

ccBoard0.dat files:

• ccBoard0_specific.dat (ccBoard0.dat for specific 1MHz clock frequency configuration)
• ccBoard0_adaptive.dat (ccBoard0.dat for adaptive 1MHz clock frequency configuration)

I hope by giving you all the information i have we can fix this issue soon. I am looking forward to hear from you.

Regards

M. Klum

Technical University Berlin

[Start: Texas Instruments XDS100v2 USB Debug Probe_0]

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:\DOCUME~1\MICHAE~1\LOCALS~1\APPLIC~1\TEXASI~1\
    CCS\ti\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 'Feb 18 2015'.
The library build time was '23:56:50'.
The library package version is '5.1.641.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: Texas Instruments XDS100v2 USB Debug Probe_0]

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

[Start: Texas Instruments XDS100v2 USB Debug Probe_0]

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:\DOCUME~1\MICHAE~1\LOCALS~1\APPLIC~1\TEXASI~1\
    CCS\ti\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 'Feb 18 2015'.
The library build time was '23:56:50'.
The library package version is '5.1.641.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 JTAG IR instruction path-length was not recorded.

-----[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

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-154' (0xffffff66).
The title is 'SC_ERR_FTDI_WRITE'.

The explanation is:
One of the FTDI driver functions used to
write data returned bad status or an error.

[End: Texas Instruments XDS100v2 USB Debug Probe_0]

Ephraim, Michael,

I don't have a LCDK board (only the older HawkBoard), but a colleague tested it and was able to successfully connect to his OMAPL138LCDK Rev A6 with a Spectrum Digital XDS100v2 (we don't have a v2 from Olimex), CCSv6.1.0.00104 and TI Emulators component 6.0.14.0.

He tested the configurations using both the LCDKOMAPL138 connection supplied with CCS (which uses the OMAP-L138_LCDK.gel file) and a custom configuration using the original gel file provided by LogicPD.

Attached follows the files he used.

Just for grins I also tested on my old HawkBoard and everything worked just fine, provided I disabled the device from booting from its built-in flash. Perhaps your board already booted from flash and it is influencing the normal operation of the GEL? If so, you can interrupt the GEL execution, issue either a HW or a System Reset and retry running the board initialization from the "Scripts" menu.

I also tested my board with my Olimex XDS100v3, and one additional detail about this particular debugger is the placement of the cable and its pin converter (something I mention on this thread). I am not 100% sure if that is the case, but it may be worth a try.

With this, I am not 100% sure if the problem resides on the JTAG debugger or the board itself.

Hope this helps,

Rafael

OMAPL138.rar

Dear Rafael,

Thank you a lot for your extensive answer.

I tried to update my TI Emulators to 6.0.14.0, unfortunately this somehow breaks dbgjtag.exe reproducibly. The only thing that helped was reinstalling CCS and not updating it. I tried it none the less again (even though I did it several times by now) with the same result. Dbgjtag.exe in file version 35.35.0.0 just does not work and throws a “not a valid Win32 application”. However, I didn’t want to reinstall CCS again and thus just replace the .exe by file version 35.34.40.0 – luckily for me, we use CCS a lot around here at the TU Berlin.

I tried your target configurations. They differ only slightly from mine, only the Arm9 Core is set to “Auto-detect” instead of 926 and the Target Timeouts are set to “Very Fast” instead of “Very Slow”. The problem is, since Adaptive JTAG TCLK Frequency is used, even the Connection Test fails with error. Thus any further testing is rendered impossible. I cannot use the GEL files in this setting. As usual, the following error log is written:

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
This error is generated by TI's USCIF driver or utilities.

The value is '-154' (0xffffff66).
The title is 'SC_ERR_FTDI_WRITE'.

The explanation is:
One of the FTDI driver functions used to
write data returned bad status or an error.

Error connecting to the target:
(Error -150 @ 0x0)
One of the FTDI driver functions used during
configuration returned a invalid status or an error.
(Emulation package 6.0.14.0)

However, I did try the fixed configuration again completely. Then I ran the scripts by hand. Then I issued a system reset and ran the scripts by hand again. But every time I get the exact same error. Below the complete console log:

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: Trouble Writing Memory Block at 0x1c11138 on Page 0 of Length 0x4: (Error -2030 @ 0x756F7247) Internal error: Access to unknown or invalid register was requested. Restart the application. If error persists, please report the error. (Emulation package 6.0.14.0) 
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: 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: Trouble Writing Memory Block at 0x1c11138 on Page 0 of Length 0x4: (Error -2030 @ 0x756F7247) Internal error: Access to unknown or invalid register was requested. Restart the application. If error persists, please report the error. (Emulation package 6.0.14.0) 
Core_300MHz_mDDR_150MHz() cannot be evaluated.
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()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: Trouble Writing Memory Block at 0x1c11138 on Page 0 of Length 0x4: (Error -1060 @ 0x2BCA) 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.14.0) 
Core_300MHz_mDDR_150MHz() cannot be evaluated.
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()

Regarding the pin converter, I don’t see how I could change anything about the connection. It seems fool-proof and there is no way to switch or reverse anything or to use other interfaces – there are simply none than those in use which could be used.

I hope you still have an idea – I am running out of options here. For me it seems like the OMAPlcdk needs adaptive clocking but the OLIMEX XDS100v2 can’t handle it. And if I use specific clocking, everything is ok until I try to set the Core/RAM Frequencies.

Thank you for your help!

Best Regards

Michael Klum

Michael,

Michael Klum said:

Dbgjtag.exe in file version 35.35.0.0 just does not work and throws a “not a valid Win32 application”

That is very odd. Despite I am using a 64-bit OS, I can see the executable is a 32-bit application.

Your reply gave me another idea. I have the impression that your Windows install may not have some of Microsoft's runtime Redistributable Packages installed, as hinted by this thread at Microsoft's forum. By following the suggestions in this other thread I found out that dbgjtag.exe requires the Microsoft redistributables 2013:

This package should have been installed with the component installer, but perhaps that did not happen. You can try to install the missing redistributables package that can be obtained at this link.

Michael Klum said:

The problem is, since Adaptive JTAG TCLK Frequency is used, even the Connection Test fails with error.

Ok, back to the problem at hand. As you also suspect, probably the JTAG debugger you have does not work with adaptive clocking - something that Olimex may confirm.

Michael Klum said:

In specific 1.0MHz mode, the connection test works fine. But the error I (we) get when executing the GEL file seems to be known. According to Titus it can be removed by using the adaptive clocking

One additional idea that occurred to me: usually you can workaround the adaptive clocking by severely reducing a fixed clock speed. Can you try using the configuration below? Keep in mind this will be very impractical from a debug standpoint.

If none of this works, as I mentioned before I strongly suggest contacting Olimex and see if they can test this JTAG debugger themselves. If your debugger is similar to the one Ephraim is using, Olimex does not seem to carry it on their product line anymore.

Hope this helps,

Rafael

Dear Rafael,

thank you again for your answer. This time I worked on another machine where I don't have these update issues. But I will try to fix it on the other machine.

I tried the settings you have given me, as well as a 100kHz "Fixed with user specified slower value". In both settings the connection test works fine (just like in every other "fixed" setting i assume) but i cannot communicate with the ARM9 at all.

The log of the connection test:

[Start: Texas Instruments XDS100v2 USB Debug Probe_0]

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\Micha\AppData\Local\TEXASI~1\CCS\
    CCS6\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 'Jul 23 2015'.
The library build time was '19:45:35'.
The library package version is '6.0.14.0'.
The library component version is '35.35.0.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 64 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 64 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 64 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: Texas Instruments XDS100v2 USB Debug Probe_0]

The log of the ARM9 connect:

ARM9_0: Error connecting to the target: (Error -150 @ 0x2A3C) One of the FTDI driver functions used during configuration returned a invalid status or an error. (Emulation package 6.0.14.0) 

Error connecting to the target:
(Error -150 @ 0x2A3C)
One of the FTDI driver functions used during
configuration returned a invalid status or an error.
(Emulation package 6.0.14.0)

I think we hit bedrock on this one, or do you have other options? I will, however, try to get in contact with OLIMEX. But you are right, I did not find this specific board on their homepage as well.

Thank you none the less for your help!

Regards

Michael Klum

I hereby want to provide a minor update.

I am now in contact with the OLIMEX support and gave them the link to this forum post as well. They too assume a software problem in the XDS100v2 which may be fixed by updating the CPLD. It is the known, old problem. But then they said there is a "CPLD" folder in the XDS100v2 design files (to be found here) which contains updated software and I should reprogram the CPLD.

I however already updated the CPLD using the CPLDPROG utility with the included XSVF file provided here. I now wonder if the software is equivalent to the CPLD folder in the design files? Could you please clearify this for me? Just to keep it complete, here the log in -v 1 mode of the CPLD program sequence.

xds100v2_cpldprog.exe -v 1 xds100v2_cpld.xsvf

XSVF Player v5.01, Xilinx, Inc.
Found 2 USB 2.x devices
Opened Texas Instruments Inc.XDS100 Ver 2.0 B, at Location 4386
Verbose level = 1
XSVF file = xds100v2_cpld.xsvf
SUCCESS - Completed XSVF execution.
Execution Time = 14.810 seconds

In addition, OLIMEX clearified that they indeed never sold the device and that they were "ordered by Texas Instruments and [...] were manufactured under the strict supervision of Texas Instruments." In addition they assured me that they "have followed the general electronics practices and the unit was tested both hardware-wise and software-wise before leaving the factory". If anything, they assume a purely sofware related issue.

I hope you could answer my question regarding the CPLD code and maybe help with another idea to tackle the issue?

Best Regards

Michae Klum

Technical University Berlin

You are welcome.

A final note on the issue: OLIMEX wrote that they “ensured that future revisions of the adapter would have pin 9 connected”. In addition, they added a note in their XDS100v2 FAQ regarding this issue. For the sake of completeness, I give you a link below.

I can't get the adaptive clock working. Does the unit really support adaptive clocking?

Best Regards
Michael Klum
Technical University Berlin

Michael,

Thanks a lot for providing the feedback. I double-checked the XDS100v2 reference design and saw the RTCK signal connected, thus it seems restricted to Olimex.

Regards,

Rafael