Slow communication speed between EVM C6748 and the host PC

Xinwang,

   That sounds way to slow for a DSP running at 300MHz. What type of communication are you using Emulation? I believe the C6748 EVM is shipped with an XDS100v1 Emulator on the board. You should be able to put a simple printf("hello world)" statement in the main loop and see it much faster than 10s of seconds.

   printf() in and of itself is pretty slow (takes lots of cycles), so it's not the best method to use, but it should still show up relatively quickly.

Hi Drew,

I was using XDS100V1.

Since I updated the driver files of emulator, I was thinking it might cause the problem. But when I recovered it to the old version, it still does the same thing. I also tried to use XDS510 and XDS560. These two simply just don't work.

It should be at least loading the code and communicating at the same speed as DSK C5510 does, right? Is there any way I can check the communication speed?

Thank you for your help.

XDS100v1 is a slower (older emulator). What didn't work about the XDS5x emulator files?

I haven't used the C5x DSK's but I'm fairly certain the load speed is more a factor of he JTAG clock than the internals of the devices, so I would expect the load speed to be similar across all devices, however take this for what it's worth due to my inexperience using the C5x DSK.

Also - what version of CCS are you using? If it's CCSv4 I can probably provide a .ccxml file for you as a reference for the XDS5x device. I would also see if there are some available on the manufacturers website.

Hi Drew,

I am using CCS3.3. If the speed of loading code is pretty much same, then I suppose it caused either by  hardware issues or some wrong setup somewhere. Are you familiar with finding hardware problems for XDS100 on the EVM base board? Any suggestion? Is there any setup needs to do in CCS for the emulator?

About using XDS510 and XDS560, that is just a foolish mistake. I thought they are just software versions, and tried to install them to work with the emulator on the base board which is XDS100.

Anyway, I will try to find the problem and let you know if I did. Thanks for your help.

Xinwang

Hello,

We have the same problem on a custom board, loading (by pressing Debug button) the Test_Ram application takes minutes from CCSv5 to the board via XDS100v2. Any idea why? Does it need new drivers? The logs can be seen below and look fine once the application started, but takes too long for such a simple application.

C674X_0: Output:  Target Connected.
C674X_0: Output:  ---------------------------------------------
C674X_0: Output:  Memory Map Cleared.
C674X_0: Output:  ---------------------------------------------
C674X_0: Output:  Memory Map Setup Complete.
C674X_0: Output:  ---------------------------------------------
C674X_0: Output:  KICK Unlocked.
C674X_0: Output:  ---------------------------------------------
C674X_0: Output:  PSC Enable Complete.
C674X_0: Output:  ---------------------------------------------
C674X_0: Output:  PLL0 init done for Core:300MHz, EMIFA:25MHz
C674X_0: Output:  mDDR initialization is in progress....
C674X_0: Output:  PLL1 init done for DDR:150MHz
C674X_0: Output:  Using mDDR settings
C674X_0: Output:  mDDR init for 150 MHz is done
C674X_0: Output:  ---------------------------------------------

[C674X_0] ------------------------------------------------------------
[C674X_0]                      OMAP-L138 RAM Test
[C674X_0] 
[C674X_0] Test Description
[C674X_0] ----------------
[C674X_0] this code verifies the mDDR address bus and writes/verifies 
[C674X_0] data patterns to the mDDR. 
[C674X_0] ------------------------------------------------------------
[C674X_0] 
[C674X_0] 
[C674X_0] Execute Test
[C674X_0] ------------
[C674X_0] 
[C674X_0] --- Test address and data bus ---
[C674X_0]  address/data bus test passed
[C674X_0] 
[C674X_0] --- Test data pattern ---
[C674X_0]  data pattern test passed
[C674X_0] 
[C674X_0] 
[C674X_0] 
[C674X_0] 
[C674X_0] 
[C674X_0] ********** OMAP-L138 TEST PASSED **********
[C674X_0]

[Start]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

[Result]


-----[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 'Dec 19 2011'.
The library build time was '21:32:12'.
The library package version is '5.0.569.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 now 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]

Best regards,

David.

Turns out it was a failing USB controller on the PC. Solved by installing a PCI card USB 2.0 controller.