Error about load .out to 6678

Lee,

I don't have experience in c66xx platforms. But from the log the first error looks like you are accessing either wrong memory address which is not valid according to the device memory map, or the memory you are loading is not initialized. You can check the same doing the following.

1. Connect to C66xx_1and after GEL file executes successfully with DDR being initialized properly.

2. Check the .map file generated for your ,out file and see the different section addresses and verify its valid according to the device memory map.

3. In CCS, open the memory browser and access any of the sections address and see whether you are able to read/write there. (It should fail if any issue is there with memory initialization/mapping)

4. If the address specified in your map file is not valid according to the device memory map, then you've change the linker script(.cmd) accordingly. 

For the second problem of not getting connected to C66xx_0, I think the core C66xx_0 is not powered up properly. That should be performed by the GEL file logically or using a boot loader or your application code. So please double check whether you are using the right GEL file.

Hello Thomas and TI engineers,

Strangely enough, one of my customers is also having the second issue that Lee mentioned in his post: They designed a board based on the C6678 and the boards were manufactured with TMS320c6678 rev1 and TMS320c6678 rev2.

On the boards  with TMS320c6678 rev1 they are able to connect the CCS 5 debugger to the target without any issues but on the boards with the TMS320c6678 rev2 they get the following message: 

C66xx_0: GEL Output: Setup_Memory_Map...

C66xx_0: GEL Output: Setup_Memory_Map... Done.

C66xx_0: Error connecting to the target: (Error -1144 @ 0x0) Device core is hung. The debugger attempted to recover debug control, but was unsuccessful. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.0.872.0)

 We do not understand what is happening?  What could be the difference between TMS320c6678 rev1 and rev 2 that can cause this behavior? Could it be that a different GEL file is needed for TMS320c6678 rev2?

The PCBs are identical except for the DSP revision and the same target configuration is used. In both situation the “Test Connection” passed.

Please let me know if you can help.

Best regards

Seb

Seb,

Leave the GEL file. Can you try using CCS to connect to the core without GEL file? Can you verify whether this works in both the boards? Basically GEL file is executed after the connection is established on the core. So, as a first step connecting to the core should work. If this works, you can selectively comment out different functions in the GEL file and try to see whether any of the function is causing the trouble. 

Since you are saying that there is no difference in boards except for the silicon revision, I believe same GEL file should work without any issues. Alternatively you can check for the silicon errata to find out any difference in the two versions.

Hi Thomas,

Thank you for your response.

My customer tried exactly what you suggested:

He removed the GEL file from initialization and observed the same behavior. No improvement.

It’s like the TMS320c6678 rev 2 is not ready to work with the emulator. (After reset, the DSP does not start correctly or is busy doing something else)

However, the TMS320c6678 rev 1 works well in the same conditions (no GEL file).  

Any thing else we could check?

Thanks

Seb

Seb,

Have you check the errata for c6678 and observed any difference? Also can you update CCS version so that it will install the latest drivers for the platform?

Hello Thomas and TI Application engineers,

Yes, we have checked the errata for C6678 and followed the workaround provided in Advisory 24.

1. Domain Power Loss Mode is selected correctly(  Auto) like in Workaround 1
2. We have the latest CCS  Version: 5.3.0.00090 and did all updates

My customer received two brand new boards with C6678 ver2 on them and unfortunately we observed the same problem:

The CCS is unable to connect to the target. As mentioned before it seems like the DSP core doesn’t start correctly or is busy and can’t respond

to the CCS commands.

I have some questions about this:

1. Are there pins that we can probe to monitor the status of the DSP cores ?
2. Could we use other input pins other than the RESET pins to control the start of the DSP ?
3. Is it important in which boot configuration the DSP starts?

Hello Seb,

I'm not sure what version of CCS you are using but if you are not using the lastest version (currently 5.3, though 5.4 is coming in a few days), please update your version.

If you are still having problems, please run the JTAG diagnostic tool and report the results:

http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems#Code_Composer_Studio_v5

Thanks

ki

Hello Ki,

As stated in my last post, the CCS version they are using is 5.3.0.00090.

The issue is still present.

What is puzzling is that the customer boards (exact PCBs) populated with C6678 Rev 1 work perfectly (0 failure to connect) whereas the same boards populated
with C6678 Rev 2 don't not work ( 0 success). Clearly if it were a JTAG connectivity issue, statistically speaking, the probability of failing would be equivalent
from Rev 1 to Rev 2. Maybe the JTAG diagnostic tool will catch something we missed. Were is that test located on the link you send me? Do you mean
the JTAG scan chain integrity test?

 If I summarize:

1. Boards (PCBs) are identical
2. CCS 5.3 is used in both cases
3. The HW debugger is the same
4. The only delta is the DSP that changed from Rev 1->Rev 2.

So some change took place in Silicon Rev 2 that is causing the core to hang (in a setup that works with Rev 1). We just need to understand exactly what.

Thanks
Seb

Electrons4me said:

. Maybe the JTAG diagnostic tool will catch something we missed. Were is that test located on the link you send me?

Yes. Here is the link again which tells you how to run the test in CCS:

http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems#Code_Composer_Studio_v5

Please post the full results here.

Electrons4me said:

So some change took place in Silicon Rev 2 that is causing the core to hang (in a setup that works with Rev 1). We just need to understand exactly what.

yes that is the big question. The first step is to get the results of the JTAG connectivity test. It should provide a few clues on what the issue could be.

Thanks

ki

Hi Ki,

Attached is the result of the JTAG connectivity test.

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

/home/hardware/.TI/1416048871/0/0/BrdDat/
    testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 560/2xx-class product.
This utility will load the program 'sd560v2e.out'.
Loaded FPGA Image: /home/hardware/development/tools/ti/ccsv5/ccs_base/common/uscif/./././././dtc_top.jbc
The library build date was 'Apr 16 2013'.
The library build time was '22:54:39'.
The library package version is '5.1.92.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 '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
The cable+pod has a version number of '8' (0x00000008).
The cable+pod has a capability number of '7423' (0x00001cff).
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 Nano-TBC VHDL.
The link is a 560-class second-generation-560 cable.
The software is configured for Nano-TBC VHDL features.
The controller will be software reset via its registers.
The controller has a logic ONE on its EMU[0] input pin.
The controller has a logic ONE on its EMU[1] input pin.
The controller will use falling-edge timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '2' (0x0002).
The utility logic has not previously detected a power-loss.
The utility logic is not currently detecting a power-loss.
Loaded FPGA Image: /home/hardware/development/tools/ti/ccsv5/ccs_base/common/uscif/./././././dtc_top.jbc

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

  Test  Size   Coord      MHz    Flag  Result       Description
  ~~~~  ~~~~  ~~~~~~~  ~~~~~~~~  ~~~~  ~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~
    1   none  - 01 00  500.0kHz   -    similar      isit internal clock
    2   none  - 01 09  570.3kHz   -    similar      isit internal clock
    3    512  - 01 00  500.0kHz   O    good value   measure path length
    4    128  - 01 00  500.0kHz   O    good value   auto step initial
    5    128  - 01 0D  601.6kHz   O    good value   auto step delta
    6    128  - 01 1C  718.8kHz   O    good value   auto step delta
    7    128  - 01 2E  859.4kHz   O    good value   auto step delta
    8    128  + 00 02  1.031MHz   O    good value   auto step delta
    9    128  + 00 0F  1.234MHz   O    good value   auto step delta
   10    128  + 00 1F  1.484MHz   O    good value   auto step delta
   11    128  + 00 32  1.781MHz   O    good value   auto step delta
   12    128  + 01 04  2.125MHz   O    good value   auto step delta
   13    128  + 01 11  2.531MHz   O    good value   auto step delta
   14    128  + 01 21  3.031MHz   O    good value   auto step delta
   15    128  + 01 34  3.625MHz   O    good value   auto step delta
   16    128  + 02 05  4.312MHz   O    good value   auto step delta
   17    128  + 02 13  5.188MHz   O    good value   auto step delta
   18    128  + 02 23  6.188MHz   O    good value   auto step delta
   19    128  + 02 37  7.438MHz   O    good value   auto step delta
   20    128  + 03 07  8.875MHz   O    good value   auto step delta
   21    128  + 03 15  10.62MHz   O    good value   auto step delta
   22    128  + 03 1E  11.75MHz  {O}   good value   auto step delta
   23    512  + 02 3E  7.875MHz   O    good value   auto power initial
   24    512  + 03 0E  9.750MHz   O    good value   auto power delta
   25    512  + 03 16  10.75MHz   O    good value   auto power delta
   26    512  + 03 1A  11.25MHz   O    good value   auto power delta
   27    512  + 03 1C  11.50MHz   O    good value   auto power delta
   28    512  + 03 1D  11.62MHz   O    good value   auto power delta
   29    512  + 03 1D  11.62MHz   O    good value   auto power delta
   30    512  + 03 13  10.38MHz  {O}   good value   auto margin initial

The first internal/external clock test resuts are:
The expect frequency was 500000Hz.
The actual frequency was 499872Hz.
The delta frequency was 128Hz.

The second internal/external clock test resuts are:
The expect frequency was 570312Hz.
The actual frequency was 569976Hz.
The delta frequency was 336Hz.

In the scan-path tests:
The test length was 16384 bits.
The JTAG IR length was 6 bits.
The JTAG DR length was 1 bits.

The IR/DR scan-path tests used 30 frequencies.
The IR/DR scan-path tests used 500.0kHz as the initial frequency.
The IR/DR scan-path tests used 11.75MHz as the highest frequency.
The IR/DR scan-path tests used 10.38MHz as the final frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

The frequency of the JTAG TCLKR input is measured as 10.37MHz.

The frequency of the JTAG TCLKR input and TCLKO output signals are similar.
The target system likely uses the TCLKO output from the emulator PLL.

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

I could not see anything wrong in the test results (but I'm no expert either). However we are able to get CCS to connect to the core now (no HW changes, just a slightly different sequence than workaround No 2 per c6678 errata doc).

Somehow I knew that the issue revolved around Advisory 24 (Errata) and indeed my customer found a sequence that allows connection of CCS to the target. However two issues remain:

1. The workaround No 1 and No 2, found in the errata document, seem to be a subset of the solutions. 
2. My customer's workaround is different from No1 and No2 above but is also a subset since it works on 50% of their boards. It would be good if TI could offer 
   a solution that covers 100% of the cases. (Note that  workaround No 1 and No 2 do not work at all on my customer's boards).

Since our solution only offers 50% success rate (but the sample population is statistically low, i.e. 4 boards) I'm hesitant to post it. I could send it to you offline for review and if a satisfactory tweak is found to make it work at a higher success rate it could then be posted. If you prefer me to post it anyway, I'll be happy to. 

Please advise
Thanks and cheers

Seb 

Electrons4me said:

Attached is the result of the JTAG connectivity test.

Fullscreen 1460.testjtagCWP2.txt Download

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

/home/hardware/.TI/1416048871/0/0/BrdDat/
    testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 560/2xx-class product.
This utility will load the program 'sd560v2e.out'.
Loaded FPGA Image: /home/hardware/development/tools/ti/ccsv5/ccs_base/common/uscif/./././././dtc_top.jbc
The library build date was 'Apr 16 2013'.
The library build time was '22:54:39'.
The library package version is '5.1.92.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 '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
The cable+pod has a version number of '8' (0x00000008).
The cable+pod has a capability number of '7423' (0x00001cff).
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 Nano-TBC VHDL.
The link is a 560-class second-generation-560 cable.
The software is configured for Nano-TBC VHDL features.
The controller will be software reset via its registers.
The controller has a logic ONE on its EMU[0] input pin.
The controller has a logic ONE on its EMU[1] input pin.
The controller will use falling-edge timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '2' (0x0002).
The utility logic has not previously detected a power-loss.
The utility logic is not currently detecting a power-loss.
Loaded FPGA Image: /home/hardware/development/tools/ti/ccsv5/ccs_base/common/uscif/./././././dtc_top.jbc

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

  Test  Size   Coord      MHz    Flag  Result       Description
  ~~~~  ~~~~  ~~~~~~~  ~~~~~~~~  ~~~~  ~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~
    1   none  - 01 00  500.0kHz   -    similar      isit internal clock
    2   none  - 01 09  570.3kHz   -    similar      isit internal clock
    3    512  - 01 00  500.0kHz   O    good value   measure path length
    4    128  - 01 00  500.0kHz   O    good value   auto step initial
    5    128  - 01 0D  601.6kHz   O    good value   auto step delta
    6    128  - 01 1C  718.8kHz   O    good value   auto step delta
    7    128  - 01 2E  859.4kHz   O    good value   auto step delta
    8    128  + 00 02  1.031MHz   O    good value   auto step delta
    9    128  + 00 0F  1.234MHz   O    good value   auto step delta
   10    128  + 00 1F  1.484MHz   O    good value   auto step delta
   11    128  + 00 32  1.781MHz   O    good value   auto step delta
   12    128  + 01 04  2.125MHz   O    good value   auto step delta
   13    128  + 01 11  2.531MHz   O    good value   auto step delta
   14    128  + 01 21  3.031MHz   O    good value   auto step delta
   15    128  + 01 34  3.625MHz   O    good value   auto step delta
   16    128  + 02 05  4.312MHz   O    good value   auto step delta
   17    128  + 02 13  5.188MHz   O    good value   auto step delta
   18    128  + 02 23  6.188MHz   O    good value   auto step delta
   19    128  + 02 37  7.438MHz   O    good value   auto step delta
   20    128  + 03 07  8.875MHz   O    good value   auto step delta
   21    128  + 03 15  10.62MHz   O    good value   auto step delta
   22    128  + 03 1E  11.75MHz  {O}   good value   auto step delta
   23    512  + 02 3E  7.875MHz   O    good value   auto power initial
   24    512  + 03 0E  9.750MHz   O    good value   auto power delta
   25    512  + 03 16  10.75MHz   O    good value   auto power delta
   26    512  + 03 1A  11.25MHz   O    good value   auto power delta
   27    512  + 03 1C  11.50MHz   O    good value   auto power delta
   28    512  + 03 1D  11.62MHz   O    good value   auto power delta
   29    512  + 03 1D  11.62MHz   O    good value   auto power delta
   30    512  + 03 13  10.38MHz  {O}   good value   auto margin initial

The first internal/external clock test resuts are:
The expect frequency was 500000Hz.
The actual frequency was 499872Hz.
The delta frequency was 128Hz.

The second internal/external clock test resuts are:
The expect frequency was 570312Hz.
The actual frequency was 569976Hz.
The delta frequency was 336Hz.

In the scan-path tests:
The test length was 16384 bits.
The JTAG IR length was 6 bits.
The JTAG DR length was 1 bits.

The IR/DR scan-path tests used 30 frequencies.
The IR/DR scan-path tests used 500.0kHz as the initial frequency.
The IR/DR scan-path tests used 11.75MHz as the highest frequency.
The IR/DR scan-path tests used 10.38MHz as the final frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

The frequency of the JTAG TCLKR input is measured as 10.37MHz.

The frequency of the JTAG TCLKR input and TCLKO output signals are similar.
The target system likely uses the TCLKO output from the emulator PLL.

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

I could not see anything wrong in the test results (but I'm no expert either).

You are correct, it does look good.

Electrons4me said:

Somehow I knew that the issue revolved around Advisory 24 (Errata) and indeed my customer found a sequence that allows connection of CCS to the target.

I am not aware of this errata. It probably comes from the device team. Could you point me to it?

Thanks
ki

Hi Ki,

Notice from page 8 of the errata sheet (see link below for the errata sheet) Advisory 24 only applies to C6678 rev 2.0! Also it has to do with CCS connection to targets that fails after systems reset issued by CCS; so immediately knew that Advisory 24 was related to my customer's issue.

http://www.ti.com/lit/er/sprz334e/sprz334e.pdf

Thanks
Seb 

Thanks Seb. This issue is a bit beyond me. Either the CCS emulation experts or the device experts would be best to follow up with. Let's start with the emulation experts. Please start a private conversation with me so we can get the ball rolling.

Thanks

ki

Hi Ki,

I'm  not sure how to start a private conversation... I don't see a button on E2E that says "private chat/conversation".

Tx

Seb

Seb,

Without more tests, It is hard to make judgement for what might be wrong with your customer's case. My guess is, most possibly it is a configuration/boot related issue.

I'd suggest following test to bypass any booting process, by using so-called WIR mode (Wait-In-Reset mode). The simple way to enable this is:

1. Power-off the board, and using wire to connect EMU1 pin to HIGH, and EMU0 pin to LOW (two of the emulation header signal pins).

2. Power-on the board.

3. Start CCS, and try to connect to the Core0/1, etc.

If you can connect to the core0 successfully (the target should be halt at the beginning of the ROM code), then, try to run/step the code (booting code in ROM), to see which part of the code causing the failures.

Regards!

Wen