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.
Tool/software: Code Composer Studio
Hi,
I'm using two CC2650 Launchpad boards, rev 1.3, for FW development and am trying to put the out of the box demo firmware back in place using the cloud re-programming button on Resource Explorer webpage for the CC2650 Launchpad. The boards are fully functional and have been running custom code as well as various examples from the BLE v2.2.2 SDK (the SDK required for a legacy project) . The board I'm currently trying to revert is running the cc2650lp_simple_peripheral_rel sample project.
The problem I'm having is a variant of the issue with the space in path names that contain "Texas Instruments". I overcame the initial occurrences of this error using advice from other forum threads about this problem. The initial occurrence was resolved by enabling 3.5 names via fsutil and RegEdit. 3.5 names are confirmed as fully enabled, and that did resolve an issue I was having with getting TICloudAgent installed. TICloudAgent now runs when triggered by the webpage button but fails during its preparation for reprogramming. This happens repeatedly at the same point when executing 'ccs_base/hercules/flash/libraries/f021_R4_le.nfl' as shown below:
I have tried editing config.json to replace "...\\Texas Instruments\\TICLOU~1" with "...\\TEXAS~1\\TICLOU~1" but that did not fix the issue. After that the webpage button wants me to reinstall TICloudAgent, or states it can't detect hardware etc.. So I kill the JSON node that is still running, delete the TICloudAgent folders under my Users area and under AppData\Local\Texas Instruments and repeat the process, failing at the same point.
Questions:
1) Are there other config files that I need to edit to replace "Texas Instruments" with "TEXAS~1"?
2) Is the compiled hex file for the CC2650 Launchpad Out of the Box factory image v2.2.5.1 or newer available? If so I could just flash the board with Flash Programmer 2 and be done with this in 2 minutes? I can't find it anywhere, all searches and links lead back to the button shown in the picture above from ://dev.ti.com/tirex/explore/node?devtools=LAUNCHXL-CC2650
For what it's worth, even though The TI agent for Google Chrome is installed and tuned on I can't get any of TI's Cloud based resources to work. They either fail with this path issue or just say "No hardware connected". The hardware is connected, and is running TI example code as shown below:
Thanks for you help in advance,
GSarver
Hi Gerry,
Gerry Sarver said:The initial occurrence was resolved by enabling 3.5 names via fsutil and RegEdit. 3.5 names are confirmed as fully enabled, and that did resolve an issue I was having with getting TICloudAgent installed.
This is usually the solution to the error you are getting. I'm surprised you were able to get it to install but continue to get the error when trying to connect to the launchpad from the cloud.
If you got to dev.ti.com, is it able to detect your board?
Thanks
ki
Can you uninstall the TI Cloud Agent you installed (you can do this from Windows settings) and then make sure short file name generation is enabled and try re-installing?
Unfortunately, that sequence put me back to square one:
1) Used Windows App manager to uninstall cloud agent - success.
2) Rebooted the PC and verify 8dot3 settings:
3) Used dev.ti.com to trigger cloud agent re-install.
4) Although I was able to get the agent installed after much effort yesterday, this re-install failed:
I'm stumped. The Windows version is recent, 64bit Win 10 Pro, v20H2 OS build 19042.746 BTW.
I'm also stumped. I have reached out to the engineering team for further assistance. I'll keep you posted of any updates I get.
Thanks
ki
Thanks, hopefully they can resolve this. If I'm having this issue even after 8dot3 names are enabled others likely will also. It may be worth mentioning that our engineering team has seen a couple of issues pop-up after IT upgraded us to Win 10 v20H2.
If the Cloud tools issue can't be resolved, is it possible that TI can provide the CC2650 Launchpad Out of the Box factory hex file? That would solve my immediate need.
Regards,
Gerry
Gerry Sarver said:If the Cloud tools issue can't be resolved, is it possible that TI can provide the CC2650 Launchpad Out of the Box factory hex file? That would solve my immediate need.
I'll bring this to the attention of the device experts. They should be able to assist with this.
Hi Gerry,
I think the issue you are running into is still related to the 8.3 filename setting. If a folder was created before the 8.3 name generation was enabled, then the 8.3 name may not be available even after it is enabled. Could you give this a try:
Hopefully this resolves your issue.
Hi Andy,
That makes sense. Starting over with a new \AppData\Local\Texas Instruments folder with 8dot3 enabled did solve the issue with installing and running the cloud agent. Board reprogramming now kicks-off without issue. However, that led to what looked like perhaps stale items in \AppData\Local\Temp:
Looking in Temp I saw these:
So I deleted those folders and all other items back to a date before starting all this, uninstalled cloud agent for the heck of it, rebooted the PC, reinstalled the agent, and kicked-off reprogramming again:
The error was not resolved by cleaning out Temp, and the same error now occurs in the middle of each programming attempt. Cycling power to the board, restarting Chrome, etc., doesn't help:
I can confirm that the CC2650 Launchpad is indicating that firmware update has been kicked-off. The LED next to the XDS110 is flashing the typical alternating red/green pattern up until the point at which the error occurs. However, after reboot I see that the previous application is still in place. It appears whatever issue there is with the .data file cannot be overcome. Has that issue been reported? Where do we go from here?
Given that the original topic has been resolved I'll mark this issue as closed and ask a new question that is specific to the programming failure.
Thanks to both Ki and Andy for their help in resolving the original issue.
Gerry Sarver