• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 25721 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Error connecting to the target: (Error -1063 @ 0x0)

Mohammad Ali Koteich
Intellectual 365 points
Other Parts Discussed in Thread: OMAP-L138, OMAPL138

Hi there good folks.

I am trying to achieve a connection between a custom OMAP-L138 board and an XDS100v2 Rev B (spectrum digital) with CCS v5.2.0.00069 

I've set TCLK to adaptive, 1.0MHz. Whenever I try to connect by pressing the debug button, or by doing a manual connection to the ARM core through the target configuration panel, I get the following error:

"ARM9_0: Error connecting to the target: (Error -1063 @ 0x0) Device ID is not recognized or is not supported by driver. Confirm device and emulator configuration is correct, or update device driver. (Emulation package 5.0.681.0) "

So then I change the "Arm9 Core" setting from Auto-detect to Arm926 and try again, the message i get then is:

"ARM9_0: Error connecting to the target: (Error -2062 @ 0x32D0) Unable to halt device. 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.681.0)" 

No matter what value I try the message persists.. Even if I change the boot pin configuration... At the correct configuration (BOOT1, BOOT3, BOOT4 = High, rest low), the high level is around 2V.. I know that the boot configuration works because I can boot perfectly well from UART by using the AISgen and UART boot host utilities. But for some reason, the JTAG boot is not working, and I get the same message regardless of the boot pin config. I tried checking and unchecking the OMAP-L138 device in the target configuration. Didn't help.

I tested the JTAG connection through the target configuration interface, and here is the output:

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

-----[Print the board config pathname(s)]------------------------------------

C:\Users\koteich\AppData\Local\.TI\1552351012\
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 'Apr 2 2012'.
The library build time was '21:41:04'.
The library package version is '5.0.681.0'.
The library component version is '35.34.39.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]

//////////////////////////////////////////////////////////////////////////////////////////////////

Any help is appreciated!

Thanks for your time :)

-Koteich

  • 0
    TI__Guru**** 168297 points

    Koteich,

    I can connect just fine with my OMAPL138 development board here, therefore I suspect of one thing: are you running something on the device (xloader, u-boot, linux).

    The reason of my question is that in certain occasions I can't connect to the device if something is already running there. Therefore, can you try to setup the "pure" emulation bootmode (BOOT[1] and BOOT[4] high, if I am not mistaken), which will prevent to run anything before connect.

    You can also try to inspect the status of the internal cores before connecting:

    - launch the debug session manually via the Debug Configurations or the Target Configurations view

    - After launching, right-click on the Debug view and select Show all cores

    - Connect to the ICEPICK_C

    - Then go to menu View --> Other and type Target Status at the search top bar

    This view will show the status of the cores of your OMAPL138 as reported by the ICEPICK. From there you can check what is out of reset, with/without power, etc.

    The concept is the same as shown in the short clip Using ICEPICK of the Quick Tips page below.

    http://processors.wiki.ti.com/index.php/Quick_Tips

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    TI__Guru**** 168297 points

    The procedure for the Target Status I mentioned above is also very well explained at the forum thread below:

    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/71334.aspx

    Regards,

    Rafael

  • 0 in reply to desouza
    Intellectual 365 points

    Rafael,

    Thanks for your reply! :)

    Ok, so let's see. I am not running anything on the cores. (I've booted the UARTecho example from starterware via UART a couple of times... but it disappears after reboot, so I'm sure nothing is running on the ARM).. There is no OS on the board yet.. it's completely bare.

    BTW, I'm not using the EVM.. I'm using a custom board I developed myself. So there is a chance that this is due to a HW failure.. I'm just not able to find it.

    As for the ICEPick, here's a screenshot from the target status view:

    .

    I have a red LED that blinks whenever RESETOUT from the OMAP-L138 is active. When I connect to ICEPICK the led starts flashing constantly.. Is this normal?

    Wwhen I try to connect to the cores through a regular connection, the led is on for a few seconds, then I get the error messages I described in my first post followed by the led flashing, when I press on cancel in error message, the led shuts off.

    I've ensured that TRST is pulled low through a 4.7k pulldown to ground.

    The boot pin configuration is also designed by following TI's guidelines in the bootloader application report.

    So hmm.. what can the problem be?.. Would it behave in such a manner if some of the BGA balls didn't get soldered properly during the assembly?

    BTW, I have another ft232 chip on the board which I use to connect to the UART interface.. might this be causing issues with the ft232 on the xds100v2?

    Regards

    -Koteich



  • 0 in reply to Mohammad Ali Koteich
    Intellectual 365 points

    Ok, I solved the problem. It was a hardware connection issue.. a wrong connection in the layout forced the circuitry to reset.

    I can connect fine now. :)

    I also ran the Gel file from here: http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files
    and it worked, it printed out the status etc..

    However, when I run the EchoUart example from Starterware through JTAG, nothing happens on my board.. but when I boot through UART it works.. I can step through the code during debugging.. but if I press resume, the program runs, but nothing happens in the terminal.. Why is this? Does the JTAG disable the UART interface or something?.. Plus, when I step through the code, it gets stuck on the first transmit and keeps repeating it everytime I press step over.. The registers also remain unchanged and stay at 0x00000000... I'm confused, am I missing some setting?

  • 0 in reply to Mohammad Ali Koteich
    TI__Guru**** 168297 points

    Koteich,

    Thank you for reporting your board is working!

    Regarding the Starterware example, I had some trouble making some of its UART examples work in my BeagleBone (didn't test on the OMAPL yet, though). Therefore you may have more luck by consulting with the experts in the device forum.

    Of course, this takes into consideration your custom boards has a similar UART connectivity as a development board (where the Starterware examples were tested).

    Regards,

    Rafael

  • 0 in reply to desouza
    Intellectual 365 points

    Yeah, the UART example doesn't work like it's supposed to (interrupts don't work at all) on my board.. but I'm able to force it to transmit. I just thought it's weird that the same code behaves differently depending on wether it's booted from JTAG or through UART boot. If I boot through uart through the uart boot utility, the code runs fine and transmits like I instruct it to.. if I load the same code through JTAG, it doesn't transmit.. Do you know if JTAG booting alters the behavior of the SoC's functionality? Or do you think this is strictly an issue with the software and how it was written?

    Also, do you know if there are any programs to run through UART that can test if all the peripherals are working?..

    I just need a simple test utility that will ensure that the peripherals on my board is working... All the starterware stuff are written for specific platforms. Editing, compiling and running the projects is a painful process and defeats the entire point of "a quick way to start".. There should be some generic examples that highlights platform specific sections in order to enable easier and faster editing..

    Regards

    -Koteich

  • 0 in reply to Mohammad Ali Koteich
    TI__Guru**** 168297 points

    Koteich,

    The UART Example worked fine in my OMAPL138 board (the baseboard of a LogicPD experimenter board Rev 3), therefore it may be difficult to pinpoint an exact reason of this behaviour (I am using OMAPL138 Starterware 1.10.03.03 on CCSv5.2.0.00069 and a BH510L emulator).

    At first glance the differences between running from JTAG and running straight from a bootloader are probably given by the hardware initialization routine. When loading the code using an emulator, the debugger executes hardware initialization routines from a GEL script file; when performing the bootloader, the initialization is done by the code itself.

    Regarding your last question, unfortunately I am not aware of such testing procedures apart from what is provided with Starterware.

    Regards,

    Rafael

  • 0 in reply to desouza
    Intellectual 365 points

    Thanks for the help Rafael,

    I haven't been using a GEL file to configure the SoC, so that's probably the reason. I only loaded an EVM GEL file and ran the script once to see if the connection worked, but other than that I've never used it.. Anyway, I'll finish up what I'm working on right now (booting from SD) then I'll come back to this and see if I can figure something out.

    Thanks again :)

    -Koteich