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.

XDS100 v1 FTDI error in VM machine

Hello,

There's a problem a bit more complicated to solve, but hope someone might have an idea:

I have a Buildbot server that calls an automatic build script by a service running on a VMWare Windows 7 slave to build the project using CCSv5.1.1 which after upgrade (from CCSv5.1.0) stopped working, I'm using the C6748.GEL provided by LogicPD and created a .ccxml connection for XDS100v1. I've tried reinstalling CCSv5.1.1, also the USB drivers for VM Windows, but I have the same problem:

Loading Firmware: c:/ti/ccsv5/ccs_base/scripting/examples/loadti/loadti.bat -a -c TMS320C6748.ccxml -x ../log.xml Debug/UnitTesting.out
Configuring Debug Server for specified target... Done TARGET: Texas Instruments XDS100v1 USB Emulator_0 
Connecting to target... Error code #4001, could not connect to target! Aborting! 
SEVERE: ICEPICK_C: Error connecting to the target: (Error -151 @ 0x0) One of the FTDI driver functions used during the connect returned bad status or an error. The cause may one or more of: invalid emulator serial number, blank emulator EEPROM, missing FTDI drivers, faulty USB cable. Use the xds100serial command-line utility in the 'common/uscif' folder to verify the emulator can be located. (Emulation package 5.0.569.0) 
SEVERE: emulation failure occurred SEVERE: Error connecting to the target: emulation failure occurred 

Funny thing it works if I start it from console manually within the VM, also xds100 test reports all tests passed.

Any idea why is not working at all? Should I revert back to CCSv5.1.0 which worked but occasionally failed? Is it related to some Windows rights for services?

Thank you in advance for any suggestions,

David.

  • David,

    Your last remark caught my attention: since CCSv5.1.0 worked occasionally, I wonder if there was always some sort of timing issue during connection that was more evidenced with the new version.

    This would explain why the manual connection works but the automated one does not - the successive sequence of commands in the script may not be waiting long enough for the DSP to come up after executing all GEL files.

    A way to workaround this would be to include some delays between the connect (leaving plenty of time for the GEL to run) and the attempt to load the code.

    If you are already doing this, would you mind sending an small example that shows this behaviour?

    Regards,

    Rafael

  • Hi Rafael,

    Should this delay be added in the GEL file? My script just calls loadti.bat which doesn't have anything related to delaying between connect and running of GEL.

    To me it seems that it can't even connect to the emulator to download the code. Running from console manually also occasionally failed, so I changed my script for retrying and after a few more  attempts it succeeds. 

    Best regards,

    David.