RM48 USB Stick Dev Kit flash issue running on Win7/Vmplayer/Ubuntu

Don,

What is the output of your 'test connection' screen?

We can start by seeing if this matches the target.

Hi Anthony,

The following Test Connection output was from:
CCS 5.4 (Ubuntu)
RM48USB dev kit
Building Hercules example SCI_UART_9600_RM48

*Note: when running CCS 5.4 (Windows) and building the same example, loading from Windows 7 works (same PC that is running the VMPlayer Ubuntu 12.04) . Also, if I load from Windows the example, when running from VmPlayer Ubuntu, I can see the device connect and get the serial output on /dev/ttyUSB0. But loading from Ubuntu CCS 5.4 always fails.

Test Output:

[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/dcarlson/.TI/1524211065/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 'libjioserdesusb.so'.
The library build date was 'Apr 2 2013'.
The library build time was '01:37:27'.
The library package version is '5.1.73.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]

When loading from CCS:

Popup - "SCI_UART_9600_RM48.out: Load failed."

Console Output:

CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0Dap: Error: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 5.1.73.0)
CortexR4: Trouble Writing Memory Block at 0x8000000 on Page 0 of Length 0xa0: (Error -1141 @ 0x1FE) 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 5.1.73.0)
IcePick: Trouble Halting Target CPU: (Error -150 @ 0xFFFFFF6A) One of the FTDI driver functions used during configuration returned a invalid status or an error. (Emulation package 5.1.73.0)
CortexR4: Breakpoint Manager: Retrying with a AET breakpoint
CortexR4: Trouble Setting Breakpoint with the Action "Remain Halted" at 0x8000080: (Error -1169 @ 0x8000080) Unable to flush instruction cache. 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.1.73.0)
CortexR4: Can't Run Target CPU: (Error -1141 @ 0x1FE) 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 5.1.73.0)
CortexR4: Flash operation timed out waiting for the algorithm to complete. Operation cancelled.
CortexR4: GEL: File: /home/dcarlson/workspace_v5_4/SCI_UART_9600_RM48/Debug/SCI_UART_9600_RM48.out: Load failed.

Don ...

Don,

The scan chain test results look ok.

Would you please send the .ccxml file that you're using so we can check it for the errors mentioned above?

Anthony,

Attached is RM48L950.ccxml, this should be the one that was in the SCI_UART_9600_RM8 example, athough I did change the target from RM48L950 to the RM48L952 since the RM48USB dev kit has the L952.

Don ...

0412.RM48L950.zip

Don,

That looks ok, but then there are lots of references in it and problem could be in one of them.

I've got access to a Ubuntu 12.04 machine (native not vmware) and am installing CCSv5.4 on that to give it a try.

If that works I'll try under VMWARE Player and the newer ubuntu.

By the way though - there are a lot of posts complaining that the XDS100v2 is very slow when running through VMWARE.   I talked to a colleague and he says pretty much whatever emulator you use you get sort of the 'next emulator down' performance when you run through VMWARE because of overhead translating USB or something to that effect.   So you might wind up not too happy w. the solution.   But we can see how that goes.

Fresh install of CCSv54 worked on the ubuntu 12.04 machine running ubuntu natively.

I was able to connect to the target as well as erase the flash.   So it might be related to VMWARE.

I did use 'sudo' to install CCSv54 - don't know how critical this is but wonder if you did the same?

Also, once you have the .ccxml are you doing the launch all in one step, or are you trying to connect first without jumping straight into flash programming  (if you do a "Debug As" on a project it tends to jump straight to programming, whereas if you open the window with the 'target configurations' and just launch a target config, it usually launches but leaves the device disconnected.   then you can try simply connecting as a first step.   if you wanted to try something else you could do this to see if you can at least connect  (which might then mean the errors are to do w. the next step of flash programming) or if you cannot connect at all.  

Anthony,

Thanks for the information. Yes, I was using the "Debug As". I will try the other method you mention above.

Let me know if you are able to get it working with VMWARE, curious if it is just the PC I am running on. 

By the way, someone else here is running Ubuntu on a MacPro using Paralles and no issues.

Don ...

Don,

I tried out CCS through VMWARE player 6.0.0 on my home laptop w. an RM42 Launchpad and it worked.  It was slow however, and I don't think you would be happy with this combination of hardware.   Normally the XDS100v2 isn't fast but it's been improved so that it's not painfully slow.   When it's run under VMWARE I'd say it's back to painfully slow.   Takes seconds to just update a small memory or disassembly window.

This isn't the exact same hardware or PC that you've got I'm sure.  My home laptop is an HP I7 about 1 yr old running win 8.1 pro.   VMWARE is 6.0.0.   Ubuntu was 13.10.

I did install CCS with 'sudo' privilege and again I don't know if this might be part of the recipe;  but if you didn't do it that way you might try.  

Hi Anthony,

Thanks for the feedback. 

I though I would try on a different box. This time I was using the following:

Dell XPS 9100 i7 9GB RAM
Windows 7 Professional SP1
VMWare Player v6.0.1 build-1379776
Ubuntu v13.10 32-bit
Dev Kit: TMDSRM48USB
Prior to installing CCS, ran the depends_0.2.tar.gz to make sure all required libraries were installed.
Code Composer v5.4, installed using sudo privilege

I have attached all of the information I collected. I ran the xds100serial to verify that the emulator could be found:
Scanning for XDS100 emulators...
VID/PID Type Serial # Description
0403/a6d0 XDS100v1/v2 TIWU1MCM Texas Instruments Inc.XDS100 Ver 2.

I also verified the device serial port was working on /dev/ttyUSB0

I then ran CCS and enabled the CCS debug logging:

 TI_DS_ENABLE_LOGGING=1
 TI_DS_LOGGING_OUTPUT=/home/dcarlson/tmp/debug.log

In the attached zip file, you will find the target ccxml file and the debug information collected. Still cannot seem to get this working.

Understood that the XDS100v2 runs slow under VMWare, but that is the current development environment my client is using for proto-typing. If possible, I would still like to get it going. Hopefully the debug output is useful?

Thanks,
Don ...

0741.rm48_debug.zip 

Don,

Sorry for this late answer.

I've re-created your environment, Ubuntu 32bit 13.04 running in VMplayer 6.0.1

I'm able to connect and debug using XDS100V2, but flash programming is failing as it is in your environment.

The XDS100V2 is doing bit banging to generate the JTAG protocol. This is extremely slow in the VM environment.
I was in the past able to run a WIN7 in a virtual machine, and flash programming was slow but working.

Apparently Ubuntu is adding additional delay and I was unable to make it work.

If you have to stay in a Virtual Machine, I will suggest to use an XDS200 from Spectrum Digital.
I did test it in this VM/Ubuntu setup and it is working perfectly. I even don't see real slow down because of the Virtual machine.

This is the only option I can see so far to solve your problem.

Please let me know.