CCS/LAUNCHXL-CC1310: Error connecting to the target: (Error -275 @ 0x0)

Michael Kusch said:

Part Number: LAUNCHXL-CC1310

Tool/software: Code Composer Studio

I just installed CCS9.10 and SmartRF Studio 7 in order to follow Simplelink Academy. I have 3 LaunchXL-CC13010 launchapds, one v1.3 and two 1.4.

I first used SmartRF Studio 7 to get each launchpad serial number, which prompted a firmware update for each device.

I then used CCS9.10 to download the Collector example into launchpad 1 (v1.3). It showed 2 consecutive popup windows asking to update the target firmware. I chose update on both which returned error. I was however able to download the collector example.

BUT: when trying to download the Sensor example to either launchpad 2 or 3 (v1.4) it shows the same 2 consecutive popup windows asking to update firmware. The first popup is for "Cortex_M3_0", which is blocked by the second popup for "IcePick_C". Both say "Emulation package 8.2.0.00004"

After clicking on Update for the IcePick_C I hear USB disconnecting and then reconnecting sounds, after which CCS console shows "Error -275 @ 0x0". Clicking on the first (now unblocked) popup shows an "Unable to connect to target" popup, and the same "Error -275 @ 0x0" on CCS console.

Further attempts at debugging have the same error "IcePick_C: Error connecting to the target: (Error -275 @ 0x0) The attempt to poll a target device exceeded its timeout limit. The utility or debugger has requested that a target device be repeatedly accessed for a specific data or status value. This has failed because the built-in limit for the maximum number of attempts when polling the JTAG scan-path has been exceeded. (Emulation package 8.2.0.00004) "

If I launch SmartRF 7, it again tells me "Firmware Update Required". If I update it, CCS then recognizes the launchpad and the cycle repeats.

If I reject the update in CCS, the error is the same.

So I'm stuck in an endless loop.

If I try the "Forced mass erase" option in SmartRF Flash Programmer 2 v1.8.1, as suggested in google search result, the software crashes each time.

Please help me.

This was on a PC running Windows 7 64bit

I just finished installing CCS 9.10 and Smart RF Studio 7 on my Notebook running Windows 7 64-bit. The problem is the exact same. Same error code, same  firmware update prompts.

When importing the Sensor (and Collector) project, I got this warning which I don't think is related, but I'm posting it just in case:

sensor_CC1310_LAUNCHXL_tirtos_ccs
No XDCtools, equivalent to the specified version '3.51.3.28_core', are available - defaulting to '3.55.2.22_core'.

Hi,

If I understood one of the issues correctly, the two tools (CCS and SmartRF Studio) are requiring to update the XDS110 firmware, right? If so, this is due to the fact SmartRF Studio and CCS are bundled with different versions of the emulation component - this usually happens during a timeframe where the SmartRF studio is not yet updated to the same version of the newest CCS. The definitive solution for this goes through an update to the SmartRF Studio to match the latest version of CCS. I would have to contact some folks at the SmartRF studio team to provide an estimate as to when this will happen. 

Also, if I understood correctly, another lingering issue is due to the fact that CCS is spawning two dialog boxes to update the firmware, one after the other, right? 

This is unfortunately a known issue with CCSv9.1.0 and is reported in the bug report CCBT-2457. A rough procedure to workaround this is:

• Click on the "Update" button only once. Wait until the firmware process finishes, then click on "Cancel" on the second dialog. This should restore the debug session.
• If the "Update" button is clicked twice, the second time will fail and CCS will return to the CCS Edit perspective.
• Remove and reinsert the board on the USB port to restore the normal functionality. At this point the firmware should be updated.
• Relaunch the Debug session.

Hopefully I understood the issues at hand, but please let me know if there are still lingering questions. 

I apologize for the inconvenience,

Rafael

Hello Rafael,

Thanks for trying to help.

Unfortunately, none of the different combinations of pressing Update and Cancel on the two dialog boxes, un- and replugging USB, restarting CCS and rebooting Windows results in a working launchpad, even if I rush to press the first update popup before the second one appears, which some times resulted in both updates succeeding in the Console window. I still can't get CCS to recognize any of the Launchpads afterwards to download the examples.

The only way CCS will again recognize the Launchpads is by re-updating the firmware with SmartRF Studio, but this is kinda pointless since the loop continues.

As I mentioned, this is happening on a fresh install in 2 different PC systems, (Windows 7 and 10) with both launchpads, which points to a bug in CCS.

This is especially frustrating since I asked for 3 days time at work to learn to use these modules, and I'm stuck in this bugged loop.

I'd appreciate if you would replicate this problem by installing a fresh copy of CCS 9.10 and SmartRF Studio 7 on a Windows 64bit system and try it yourself.

Hi,

I captured the short clip below that illustrates this process, but the duplicate update box did not happen for me this time (it has happened for me other times)

Can you see if the process above helps you with this scenario?

Hope this helps,

Rafael 

desouza said:

Hi,

I captured the short clip below that illustrates this process, but the duplicate update box did not happen for me this time (it has happened for me other times)

Can you see if the process above helps you with this scenario?

Hope this helps,

Rafael 

1) Nothing appears under 1310 in the Target Configurations window if I have no project loaded. What you must be seeing is something you yourself have created before, it doesn't show up on a fresh install of CCS.

2) I erased all projects from Project Explorer and then reimported the collector_CC1310_LAUNCHXL_tirtos_ccs. When doing so I get the same Operation Summary Message as before:

No XDCtools, equivalent to the specified version '3.51.3.28_core', are available - defaulting to '3.55.2.22_core'.

My guess is that here lies the problem.

3) I used that projects CC1310F128.ccxml file to continue your video and it prompted only the Cortex firmware update, as in your video.

4) In your video, you didn't try to debug a project, so you didn't run into the IcePick_C: Error connecting to the target: (Error -275 @ 0x0) afterwards, which is the actual step preventing me from loading the collector project into the launchpad.

5) I installed UniFlash, but run into the exact same problems as with CCS: Two pupup windows, failed IcePick_C update, and unable to connect to IcePick_C ever since. The only way to reconnect to the launchpad is to run SmartRF Studio 7 and re-update the firmware.

Hi,

1) Yes, you are correct in your assumption: in a fresh install of the OS (or if it is the first installation of CCS on the host), the target configuration view showed in the video should not have a pre-existing target configuration file. However, if you import a project the target configuration view would have a similar configuration file, as you could attest. 

2) This is a project/build configuration error and should not influence the abilty to connect to the target via its JTAG debug probe, unless the example project is completely faulty and causing the device to be inaccessible after it is loaded to the target. I don't expect this to be the case.  

3) Thanks; that was my intention with my video - to verify if the firmware process in CCS could be followed without errors. This seems to be the case here, right? 

4) As I mentioned in 2) above, the fact you are loading a project or not shouldn't influence the connection phase. To cover any possible issues, I send below a new video where I import the collector project and, with the firmware previously loaded by SmartRF Studio, I go through the process of building the project and loading the code to the target, even running into the firmware update duplicate dialog boxes I mentioned before. Please check if this new procedure is closer to what you are doing. 

By the way, are you completely shutting down SmartRF before connecting to CCS, as shown in my previous video? In the past this utility and CCS did not work well when they were opened simultaneously.  

If the procedure above does not work, one last idea is to perform a Mass Erase on the device so any prior demo code or failed attempts to flash the device can be overcome. To do this, you need to create a standalone target configuration file (like the one I used in my prior video) and manually launching the debugger. 

- Go to menu File → New → Target Configuration File
- Give a meaningful name. Make sure the checkbox Use shared location is checked. Click Finish
- In the Connection drop down, select Texas Instruments XDS110 USB Debug Probe
- In the box beside Board or Device, type CC1310. Check the box of the device CC1310F128. Click on the Save button. 
- Go to menu Run → Debug. 
- After the debugger finishes launching, on the upper left view named Debug click on the entry Texas Instruments XDS110 USB Debug Probe_0/Cortex_M3_0 to select it and then go to menu Scripts → CC13x0_CC26x0 → MassErase
- After the Mass Erase procedure ends, the device should be empty.
- To go back to the prior screen with the project, go to menu Run → Terminate.

Hope this helps,

Rafael

desouza said:

Hi,

1) Yes, you are correct in your assumption: in a fresh install of the OS (or if it is the first installation of CCS on the host), the target configuration view showed in the video should not have a pre-existing target configuration file. However, if you import a project the target configuration view would have a similar configuration file, as you could attest. 

2) This is a project/build configuration error and should not influence the abilty to connect to the target via its JTAG debug probe, unless the example project is completely faulty and causing the device to be inaccessible after it is loaded to the target. I don't expect this to be the case.  

3) Thanks; that was my intention with my video - to verify if the firmware process in CCS could be followed without errors. This seems to be the case here, right? 

4) As I mentioned in 2) above, the fact you are loading a project or not shouldn't influence the connection phase. To cover any possible issues, I send below a new video where I import the collector project and, with the firmware previously loaded by SmartRF Studio, I go through the process of building the project and loading the code to the target, even running into the firmware update duplicate dialog boxes I mentioned before. Please check if this new procedure is closer to what you are doing. 

By the way, are you completely shutting down SmartRF before connecting to CCS, as shown in my previous video? In the past this utility and CCS did not work well when they were opened simultaneously.  

If the procedure above does not work, one last idea is to perform a Mass Erase on the device so any prior demo code or failed attempts to flash the device can be overcome. To do this, you need to create a standalone target configuration file (like the one I used in my prior video) and manually launching the debugger. 

- Go to menu File → New → Target Configuration File
- Give a meaningful name. Make sure the checkbox Use shared location is checked. Click Finish
- In the Connection drop down, select Texas Instruments XDS110 USB Debug Probe
- In the box beside Board or Device, type CC1310. Check the box of the device CC1310F128. Click on the Save button. 
- Go to menu Run → Debug. 
- After the debugger finishes launching, on the upper left view named Debug click on the entry Texas Instruments XDS110 USB Debug Probe_0/Cortex_M3_0 to select it and then go to menu Scripts → CC13x0_CC26x0 → MassErase
- After the Mass Erase procedure ends, the device should be empty.
- To go back to the prior screen with the project, go to menu Run → Terminate.

Hope this helps,

Rafael

A few things have happened since my last post:

CCS 9.10 on both my Windows 7 PC and my Windows 10 Notebook updated a CC13x0 component to version Version 3.11.01.77, which oddly enought is dated 2019-03-21. I've been checking for updates on CCS 9.10 on both computers ever since I installed it and this update didn't appear before.

By following its readme file, which indicated to uncheck al "custom configuration" tics in the whole ccxml tree to be able to mass erase devices that cound't be mass erased (one of the things I had failed to achieve), I ended up with a bricked launchpad. It now shows up only as "Tiva Device Firmware Update" in usb connected devices, and it is not recognized by either CCS, SmartRF RF Studio, Flash Programmer 2 nor Uniflash.

While trying to solve this new issue (which I couldn't), I stumbled upon the XDS Emulation Software Package, and found out the current version is from June 26th, so I went for the previous 8.1.0.00005 version dated March 21 thinking maybe it's a bug in the last version.

I'm not absolutely sure if it is related, but after installing this version of XDS Emulation Software, I'm able to flash the sensor and collector examples with CCS 9.10 into my 2 remaining CC1310 launchpads (v1.3 and v1.4) by cancelling the IcePick_C update and allowing the Cortex update. However it still breaks any further communication with the module, as in trying to flash the example again.

To clarify, since downgrading the XDS Emulation Software Package, I'm able to flash a project example into a CC1310 launchpad, but after that it behaves just as before, with the same IcePick_C communication error and I need to update the firmware with SmartRF Studio 7 if I want to flash another project.

This is getting ridiculous,

Since I couldn't move further with my CC1310 launchpads, I'm using my brand new CC1352R1 Launchpads and following their Simplelink Academy.

I'm running into the same problems. At first I didn't update the firmware with SmartRF Studio 7 as I didn't want to run into the same problems again.

When trying to debug the cli_ftd example, it too showed two "Update required" popups, the Ice one blocking the Corterx one. I updated the Ice, waited for it to finish successfully, then tried to update the Cortex. No success. No further communication (it can't load the example into the target).

Updated the firmware using SmartRF Studio 7 and gave it another try. Same thing.

Updated the firmware again using SmartRF Studio 7, canceled the ICE update, allowed the Cortex Upgrade. Got an "Unable to connect to target" popup after the Cortex firmware updated sucessfully. Unpulgged and replugged. Gave it another try at debugging. Same result as before, it fails to load the example into the target.

The only difference with the CC1310 launchpads is it reports Errors -2064@0x0 and -1170@0x0.

This is on my windows 7 PC; haven't tried it on the Notebook yet.

Hi,

At this point I would remove CCSv9.1 from the picture - it contains the latest firmware but it is causing more trouble with the firmware dance with the SmartRF and its older firmware. 

If you instead install CCSv9.0.1, it comes with a prior version of the firmware (as part of its internal component named TI Emulators) and you will not have the constant firmware updates between the two tools. This version is also fully compatible with both boards you have. 

In order to guarantee that you have a clean install of CCSv9.0.1, please remove the existing CCSv9.1.0 install from your setup (simply select the install directory and do a Shift+Del) and use a different workspace directory. 

That should settle on a common firmware version of the XDS110 Debug Probe of your Launchpads and help you move forward with what matters - the actual development. 

I apologize for the trouble, 

Rafael