Error while trying to connect to ICEv2 board from CCS

I've moved your thread to the CCS forum.

It did take the gel file but I get that error every time I try to connect to the board. Any suggestions to solve that ?

How to stop the program from running? I have already tried resetting, flashing using sd card, none of that works.

Hi,

I think I missed something: in your original post you say the error happens when you try to flash the SPI, but in your second reply you say this happens every time you try to connect. which case is happening?

If the first scenario, then it seems to be an application problem and you would get better help in the Sitara device forum.

If you can't connect at all, the thread below has some tips and links to the board documentation that may be helpful to prevent the board from booting and enabling a successful connection.

e2e.ti.com/.../356832

Also, check if the Test Connection button on the target configuration shows any errors. I don't think it will, given the nature of the error you showed, but it does not hurt trying.

Hope this helps,
Rafael

I am sorry for the confusion. Here is the how it goes :

I launch the Target configuration and when I test connection it says succeeded. Here is the 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\ashaikh\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 'Aug 20 2013'.
The library build time was '22:56:19'.
The library package version is '5.1.232.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]

Then I try to connect the target and it gives me the error.  

It was working before. After one SPI flash it stopped working. 

Any suggestions ?

Thank you

Hi,

The JTAG HW connection is fine, as the Test connection results indicate. So, it seems the SPI code flashed is not allowing the device to be halted by JTAG - not an uncommon scenario, especially if the code is constantly resetting the device or powered down the JTAG circuitry.

In this case, I would first try to change the bootmode of the ICE board and see if you are able to prevent the SPI code from starting - this would indicate the device is still working ok.

After regaining control you could potentially re-flash the SPI code (I am not sure exactly what is the flash procedure on the ICE board) but insert a forever loop at the beginning of the code, so you would still be able to connect to CCS and perform step-by-step debugging.

Something similar to what is described in the link below:
processors.wiki.ti.com/.../Debugging_Boot_Issues

Additional helper techniques can be seen in the short clips below:
https://youtu.be/g2aaJV_DcZY
https://youtu.be/-yGmq_VKvTQ

Hope this helps,
Rafael

desouza said:

So, it seems the SPI code flashed is not allowing the device to be halted by JTAG - not an uncommon scenario, especially if the code is constantly resetting the device or powered down the JTAG circuitry.

I haven't got the am335x_sysbios_ind_sdk_1.1.0.6\sdk\tools\gel\ICE\TMDXICE3359_v2_1A.gel installed to check it, but is the problem that the TMDXICE3359_v2_1A.gel doesn't have the modifications which were made to some CCS GEL files such as ccsv6\ccs_base\emulation\boards\ice_am3359\gel\TMDXICE3359.gel which asserted a System Reset before initialization, and disabled the MMU before loading code, which allows the GEL file to take control of the target regardless of what the running software was doing?

Chester,

In the newest release of the device support package for Sitara I included these directives to the latest GEL files to improve the rate of success of the connection and debugging baremetal code. However, the older version included with the IDK works when the SPI has valid code or the device is not allowed to boot from it.

Even with the newer GEL, the connection is also heavily dependent on how early the SPI code is disrupting the device - that is why I provided the suggestion to change the boot mode to allow re-flashing the SPI with valid code.

Regards,
Rafael

Thank you desouza, I will try this out today and see if it works.

Hi Rafael,

If I change the boot mode, I am able to load binary files in the nor flash and the sd card. But as soon as I set the boot mode for SPI it doesnt do anything. I dont know how to go into the SPI mode using CCS, it errors out when I try that.

Any suggestions ?

Adnan,

Thanks for reporting back your findings. I will ask someone from the Sitara team that has this specific board to provide some comments regarding what is required to properly boot the device via SPI - as you reported, I know the bootmode can't be switched from inside CCS.

In the meantime, I would try the following test:
- change the boot mode that allows you to connect to CCS
- connect to the device
- load the binaries you need
- go to the Debug view, select the CortxA8 core and disconnect the core (hit Ctrl+Alt+D) - do not terminate the debug session!
- change the boot mode to SPI and hit a reset button on the board (do not turn the board off or the JTAG connection may be lost)
- immediately try to connect to the core again (hit Ctrl+Alt+C) from the debug view.

Perhaps you will be lucky to connect to the core before the faulty routine kicks in and thus allow you to debug what may be going on.

All this could also be done if your code is modified as I mentioned before (with the forever loop included in the bootstrap routine of your code).

Regards,
Rafael

Adnan Shaikh said:

But as soon as I set the boot mode for SPI it doesnt do anything.

Analyzing Boot Issues with CCS and JTAG has a am335x-boot.dss script which can be run from CCS to collect information to help diagnose boot issues. e.g. the script dumps the ROM tracing vectors which record the status of the boot.

Try running the script after the device has failed to boot from SPI to see if the ROM tracing vectors identify the problem.

Thank you for your Suggestion Chester, I tried using the script from the script console but I get this error :

Error connecting to the target:
(Error -2062 @ 0x1FE)
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).

The same error when I try to connect to the board.

Edited : The text file is empty on the desktop. 

Thank you for your suggestion and help Rafael, I will try your steps right away.
Thank you for your patience.

Regards