CCS/CC2640R2F: error downloading program

Hi moshe,

When you do CCS debug initially it waits at main, then you need to press the run button which looks like a right arrow button. You can also do debug step.

-kel

Hi Kel...debugging is NOT my issue...downloading the application to the launchpad is the issue.

Hi,

When you press the CCS debug button, there should be a progress bar indicating downloading the firmware to CC2640R2F Launchpad. Do you see this?

Anyway to make sure that the XDS110 firmware is updated you can try to program the hex file using SmartRF Flash Programmer 2. It will prompt to update the XDS110 firmware. When the hex file is flashed to the CC2640R2F Launchpad, test if project zero is running

-kel

Hi Kel

Thanks for trying to help..but if you reread my original post you will notice that CCS DOES download to the launchpad & i AM able to debug & my program DOES run.

The problem is the SEQUENCE of events i have to go through to make it happen.

And yes the XDS110 WAS updated when i used Btool or SmartRF (i forget which and when...this problem has been ongoing for a while now).

cheers

moshe

edit----further to the above, i just 'updated' the firmware via smartRF (because it said to do so), i then went back to CCS & when i tried to download it popped up a message saying the firmware needed to be updated!!!
So clearly there is a difference in what SmartRF believes the firmware should be & what CCS does.
Regardless i updated it, again, from CCS and now i'm back to my original problem.

Hi Moshe,

Do you have all the appropriate jumpers placed on the LP? Are you seeing any issues if you control the CC2640R2F from SmartRF Studio? Are you consistently able to download FW through Flash Programmer 2 or Uniflash?

Regards,
Fredrik

Hi Fredrik

I have not tried to download via any other program except CCS (purely because i'm just trying to debug at this stage)...is it a useful exercise to try??
When i previously connected the smartRF to the LP it immediately said to upgrade the firmware (but doing that proved to be the wrong version for CCS).

Regarding the jumpers, i imagine they are all in the right place...its the out of the box position for all of them (ie they are ALL jumpered) & the power jumper is set for XDS power...should any of them be UN-jumpered??

cheers

moshe

edit------fredrik FYI

i just tried an experiment...using uniflash ver 4.5.2056 it said it needed to 'update' the xds110 firmware from ver 3.0.0.2 (done by ccs ver 9.1.0.00010)) to 2.3.0.14...which is really going backwards but never mind.
after that i could download my program (hex & out vers) withOUT any problems.
I also noticed that uniflash indicated an emulation of 8.0.27.9 whilst CCS indicated 8.2.0.00004.....(if thats of any use to you).
So is it possible there is an issue with firmware ver 3.0.0.2 & ccs ver 9.1.0??

Hi Moshe,

Thanks for the additional testing. It sounds like the jumpers are in the right place. Since you are consistently successful when using Uniflash, the HW should also be confirmed to be good.

I will notify our CCS support team to take a look at this case.

Bare with us and thank you for your patience. 

Regards,
Fredrik

Hi Fredrik

An update with uniflash...i just realised that the 'load' did not perform a "verify" - so i now clicked 'verify' and that came back with "a data verification error occurred, the file load failed".
And in the console window was "[ERROR] Cortex_M3_0: File Loader: Verification failed: Values at address 0x0001E000 do not match Please verify target memory and memory map."

Just a by the way - Previously on clicking 'load image' the console output was " [SUCCESS] Program Load completed successfully." (i didnt realise it didn't perform a verification after loading).

cheers

moshe

Moshe,

Error 260 is described in detail at the Debugging JTAG page: 

https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html 

Given the root cause is between the host and the Debug Probe, I can't help but wornder if other variables are being responsible for the instabilities in your scenario. Firmware could be one of them, although ideally the Control Panel and the xdsdfu utility could be used to try to see if any OS-level drivers are the ones causing the problem. The sections "Updating the XDS110 Firmware" and "troubleshooting" have details to help isolate the root cause.

http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds110.html 

Also, the connection issues could be happening due to incomplete firmware updates. The page above can help with this as well by running the updater from the command line. 

Specifically to Uniflash, what is exactly the version (or versions) you are using during this exercise? There was an issue with Flash verification that was fixed in Uniflash 4.4, but based on the assertive below it seems you are past that. 

moshe jacobson18 said:

i just tried an experiment...using uniflash ver 4.5.2056 it said it needed to 'update' the xds110 firmware from ver 3.0.0.2 (done by ccs ver 9.1.0.00010)) to 2.3.0.14...which is really going backwards but never mind.
after that i could download my program (hex & out vers) withOUT any problems.
I also noticed that uniflash indicated an emulation of 8.0.27.9 whilst CCS indicated 8.2.0.00004.....(if thats of any use to you).
So is it possible there is an issue with firmware ver 3.0.0.2 & ccs ver 9.1.0??

The downgrade of the firmware only happens across major releases (2.x.x.x and 3.x.x.x) - otherwise, the prior versions leave it untouched. 

In your particular case, does the prior version of the firmware consistently allow you to connect and download the code to the target? Do you see any other issues with the prior firmware version, such as program loading issues?

If you can consistently load code to the target with the older firmware but not with the new one, please check the reference below - although the issue reported there only happens at a later stage during the connection process, it may help you eliminate variables during the process of debugging this. 

https://e2e.ti.com/support/tools/ccs/f/81/t/821584 

Hope this helps,

Rafael 

Hi Rafael

Unfortunately after a lot of reading it didn't.

However, an interesting thing was the following....i ran the xdsdfu utility as "xdsdfu -e" and it reported NO xds110, i then disconnected it & reconnected and it reported the FOUND xds110

Running this command a few times consistently returned the correct results.

I then tried to download & debug from CCS & it came back with the result:

Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
Cortex_M3_0: Failed Board Reset: (Error -260 @ 0x0) An attempt to connect to the XDS110 failed.

I then ran "xdsdfu -e" again & sure enough it reported NO xds110!!

If at this point i disconnect the USB cable & reconnect the USB & click RETRY, CCS now DOES find the XDS110 (because it has reset itself??) and loading proceeds normally.

To me it appears that CCS somehow causes the XDS110 to shut down after performing the memory map inialization!!

Is that possible at all, and if it is, what can i do about it??
(recall this is consistent with both my launchpads - both purchased at same time about 3 months ago)

 Thanks

moshe

moshe,

Please apologize; I missed your last reply. Are you still having this intermittent malfunction? 

I have been trying to reproduce a similar issue here but unfortunately to date I am able to have the XDS110 released from control all the time during the switches across multiple tools. However, I don't use SmartRF very often, therefore it may be a variable impacting this. 

At this point I can't necessarily find out why the XDS110 port seems locked by a process - that is certainly what it seems to be happening in your case, where a disconnect/reconnect releases the port. I could never find a very reliable way to map a port to a process on Windows, thus leaving only the Task Manager and monitoring possibly lingering known processes such as uniflash.exe, ccstudio.exe, SmartRF Studio 7 (startup_window.exe), etc. 

Regards,

Rafael

Hi Rafael

Since my last update, CCS has performed an update or two.

The current state of affairs is....click debug, it performs the compile& link, about to commence the download, pops up the message "no XDS", disconnect & reconnect, click "retry", download proceeds without any problems, and is then ready & waiting at main().

The above is consistent EVERY time....i have resigned myself to this is how it has to be done.

cheers
Moshe

Hi Rafael

Further to my previous post....for some reason logged as "moshe jacobson 1 - prodigy" (an unintended feature?)

i have noticed today that after i launch CCS, i can download & debug WITHOUT any issues of ccs not finding the XDS.

However, my problems resume as soon as i disconnect & reconnect the launchpad, as thereafter, EVERYTIME i download it does not see the XDS UNTIL i disconnect & reconnect.

My current setup is:
CCS Launcher 9.0.0.20190123
CC13xx/CC26xx Device Support 3.11.1.77
installed org.eclipse.rtsc.xdctools: 3.51.3.28

cheers
moshe

moshe,

I have been trying to reproduce a similar scenario as yours to no avail. What is the exact Windows 10 version you are using? Also, are there any specific Antivirus or other security-related process running at the same time? Is this running in a native host or via a virtualization engine (Vmware, docker, etc.)?

My suspicion is that one of the CCS threads related to the Debug Server are hijacking the XDS110 Debug Probe after terminating the debug session. 

I am not sure what this may reveal, but would you mind sending the Debug Server logs for the successful and the subsequent failed debug launch attempt? 

Check the page at: https://software-dl.ti.com/ccs/esd/documents/ccs_diagnostic-logs.html 

Regards,

Rafael

Hi Rafael

running win10 pro ver 1903 o/s build 18362.356 64bit
HP Probook 470 G1 intel i5-4200M @ 2.5GHz  x64
anti-virus: windows defender, antimalwarebyte (but the problem happens regardless if its running or not)
native host.

I enabled the debugging logs & attach 2 files.
Note, in the below, when i write 'load' or 'reload' this is the action that happens after clicking the debug icon.

debug-connection-0.....this shows a load that went thru without any problems (because i had restarted ccs), i ran the program for a few secs, then stopped debugging, disconnected the usb, reconnected usb, then tried to reload & the reload stopped at the error message of 'no xds'.
so i cancelled the operation & after it returned to the editing view i stopped the logging.
i then restarted the logging with the new file name...

debug-connection-1....with this file i resumed from above & attempted to reload the program, it stopped at the error 'no xds', i then disconnected the usb, reconnected it and clicked retry. It then loaded the program without a problem & sat waiting at main. I closed the debug session without actually running the program and after the screen returned to the edit screen i retried to reload the program. Again it stopped at the error 'no xds' so i repeated the process of disconnecting & reconnecting the usb & clicking retry. Whereupon it loaded and sat waiting at main.
With this file i looked in it at various stages....so...the line numbers reflect the file as it was when i looked at it, but may not be entirely accurate as windows may not have flushed all contents to disc at that point in time.
line 9564 -> stopped at error 'no xds'
line 44069 -> waiting at main()
line 54421 -> end of debug session, edit screen active.
line 62015 -> stopped at error 'no xds'
line 64150 -> clicked retry
line 95396 -> waiting at main()
line 97112 -> end of debug session, back at edit screen active, stopped debug logging.

cheers
moshe

the following link has both files...www.dropbox.com/.../AAC5h-Evdh4932EvCTkn6if2a

and the actual files i've tried to add below....

debug-connection-0 & below it is the next file.
debug-connection-0.log

debug-connection-1
debug-connection1.log

moshe,

Thanks for sending the logs. I looked at line 128033 of the debug-connection-0 and it seems the target itself is throwing an error to the debugger. That may be the point where the second connection error happens. In this particular case, I suspect the interface between the target and the debug probe is unstable. 

If you haven't done so, I would ask you to reduce tthe TCLK speed according to the post I have sent before and copy below: 

https://e2e.ti.com/support/tools/ccs/f/81/t/821584 

This may certainly help stabilize part of the connection and program loading process. Just be sure you are modifying the correct .ccxml file - Simplelink projects usually carry their own .ccxml and it is easy to get confused (I have done thsi multiple times). 

The debug-connection-1 fails right from the start with a libusb read error - that seems to indicate the previous theory of a hijacked port. Unfortunately the debug server log does not dive into the device driver to extract exactly what may be going on - it only reports the error condition reported by it. We don't have logs that go down on the driver itself, unfortunately. 

I will try to track down other folks that may help but that will not happen until the middle of next week (Monday is a holiday in Canada, where some of them are located). 

Regards,

Rafael

Hi Rafael

I had reduced the TCLK down to 2.5MHz a while back.

I also performed an update to ver 9.2

On restart, i changed the speed back to 8MHz..it worked no problem. So as a test, I changed the speed down to 2.5MHz, it ALSO worked with no problems.
I then disconnected the USB & reconnected it and thereafter i was back to square one.....ie it gives the error, so disconnect & reconnect and it downloads to the launchpad until the next time whereupon i disconnect & reconnect.
But again, if i restart CCS then i have no problem downloading UNTIL i disconnect the usb.

The error has now changed slightly......ccs gives the following message on loading the launchpad:

Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
Cortex_M3_0: Failed Board Reset: (Error -260 @ 0x0) An attempt to connect to the XDS110 failed. The cause may be one or more of: no XDS110 is connected, invalid firmware update, invalid XDS110 serial number, or faulty USB cable. The firmware and serial number may be updated using the xdsdfu utility found in the .../ccs_base/common/uscif/xds110 directory of your installation. View the ReadMe.txt file there for instructions. (Emulation package 8.3.0.00003)
Cortex_M3_0: GEL: Error while executing StartUp( 9, 2, 0, 1751 ): Reset failed: retcode=-1
at GEL_AdvancedReset("Board Reset") [cc26x0.gel:29]
at StartUp(9, 2, 0, 1751)
IcePick_C: Error connecting to the target: (Error -260 @ 0x0) An attempt to connect to the XDS110 failed. The cause may be one or more of: no XDS110 is connected, invalid firmware update, invalid XDS110 serial number, or faulty USB cable. The firmware and serial number may be updated using the xdsdfu utility found in the .../ccs_base/common/uscif/xds110 directory of your installation. View the ReadMe.txt file there for instructions. (Emulation package 8.3.0.00003)

cheers

moshe

moshe,

Unfortunately the developers are baffled as well. It is very difficult to track which process holds which resource on a host, thus making the issue quite elusive.

At this point I can't really promise further action other than monitor e2e or see if we get the same issue in one of our hosts here. Sorry.

Regards,

Rafael

Hi Rafael

Thanks for trying nonetheless....its just very odd i appear to be the only one with the problem....which i suppose would indicate an environment issue.
Oh i'll just carry on as i am :)

cheers

moshe