CC2650 LaunchPad - can't build Project Zero and/or program the board

Also tried using CCS Cloud - this time the project builds successfully and I get to a screen saying:
GEL Expression: GEL_Go(Main)
with a progress bar which never ends (tens of minutes).

The green and red 'debug' LEDs are both on with about 1/2 sec brief flicker, LaunchPad unresponsive. No Bluetooth RF detected.

I tried to recover by going to this page:
dev.ti.com/.../index.html
I selected "Download prebuilt Project Zero App+Stack combined image to the CC2650 Launchpad". I got a couple of windows telling me all was going well, and a success message at the end. The green & red debug LEDs flickered while code was being downloaded. After the success message the green debug LED was on continuously. No Bluetooth activity.

This board was working fine with iOS SensorTag app (V 4.9 build 188) before attempting to build and load Project Zero myself.

I downloaded and installed Flash Programmer 2 and then the project 0 hex file given in an E2E forum post (from CC2650LaunchPad_BLE_All_v0_90.zip). Using Flash Programmer 2 I was able to load the project zero .hex file onto the LaunchPad and it works again.

So it's not a hardware problem: neither the CCS Desktop nor the CCS Cloud tools will build/install a good Project Zero image, having taken great care to follow all the instructions in detail.

The PC is an HP Envy quad core running Win 10.
Code Composer Studio - Version: 6.1.3.00034
SmartRF Flash Programmer 2 1.7.4 build 10

Try to download and install SimpleLink Academy 1.08 from software-dl.ti.com/.../overview.html . Then, use ProjectZero in it for your test. By the way, TI recommends to use TI ARM compiler v5.2.6 to build those BLE examples.

Thank you, YiKai. I'll do the download you suggested and let you know how it goes. 

I started using the SensorTag before switching to the LaunchPad and when I tried to build the SensorTag app it told me I needed to upgrade the compiler to match the one used for the stack or libraries - I don't remember which.

You probably guessed I'm new to this TI experience and there's a lot I haven't found out yet.

It doesn't matter you are a newbie or experienced Develper. According to my experiences, it's quite frustrating to use CCS sometimes and that's why I help people here. Anyway, good luck to you.

I have the same problem (in a different environment, Linux etc.)  I reported it in the forums  here with no answer yet.

I too tried CCS Cloud and CCS Desktop, with no luck.

One point  is that CCS Cloud SHOULD be more robust to operator errors: you don't make many choices, e.g. you don't get to choose the compiler version.  You also download the example via CCS Clound, it should not make a difference whether you went through the Academy download?

Another point is that evidence is building that there is a problem somewhere, between you and I and the two different tool chains, that is four  more or less independent instances of the problem.

On CCS Desktop, I tried using the debugger and after only stepping over/into a few functions, it 'gets lost' for example the debugger shows returning to a statement AHEAD of the calling statement.  To me, that hints at a problem in the compiler so I am considering changing the optimization level (on CCS Desktop.)  It could be that CCS Cloud IS using a later compiler version (when it shouldn't) and that v5.26 IS required in CCS Desktop.  I need to make sure that is what I used (although 5.2.7 is all that I see available when choosing from the CCS 'Install New Software' menu item.)

Like you, in CCS Cloud I was able to build and execute successfully SOME project, in my case BigTime, so the problem is not in the path to the target, but confined to BLE related example projects?

When I use ARM Compiler v5.2.7 on CCS Desktop, Project Zero behaves a little better (compared to v16.06.. which the project seems to have defaulted to) but gets lost stepping into BIOS_start(). I set a breakpoint on exception_handler() and it stops there, but I don't yet know how to display the call stack. And I need to read the Dev Guide about deciphering exceptions.

Note the numbering of compiler versions changed recently see elsewhere in this forum.

The upper left pane of the CCS Debug perpsective IS the call stack . (I was confused because it only has two lines (main and the call to BIOS_start). So I am guessing that the call to BIOS_start throws the exception and that either the BLE stack was not loaded, or the hook to it (a location in the app that it jumps through?) was not created properly.

Do you download project_zero_stack_cc2650 to your CC2650 before you download and debug project_zero application?

Yes, I did 'download' the stack image first (if you mean, click on the 'Debug' icon.) That blinks the LEDS on the Launchpad and enters the debugger normally. Then I stop the debugger, select the BLE app image, and click on 'Debug' icon. Again, LEDs blink and you get other feedback that the software is compiled and downloaded to the board. Then you get a dialog saying "gel_go(main)" (indicating a non-recoverable error?) and the debugger is not functioning. All this, 5 minutes ago.

That is using CCS Cloud on Ubuntu 16.04, following TI Cloud Agent install instructions on a clean dev machine and a newly purchased, clean, out-of-the-box Launchpad (no jumpers changed.) I suppose the example code (in the cloud) could be corrupted. I would retry importing the example project, but ProjectZero also has failed for me using CCS Desktop, and for other people (the original post.)

YiKai

Sorry for the delay in getting back to you - I was on vacation. I downloaded and installed SimpleLink Academy 1.08 from software-dl.ti.com/.../overview.html , a you suggested. Then, I used the ProjectZero image in it. To program the LaunchPad I installed TI's SmartRF Flash Programmer 2. Using this ProjectZero image and programming software I was able to restore the LaunchPad board to its original working state, so whatever was wrong with it, it wasn't a hardware failure.

The next thing I need to do is get ProjectZero source code that I can install and use to build a working ProjectZero on the LaunchPad. Once I can do this I want to be able to change the code so that I can use two pins on the CC2650 as analog inputs and two pins for digital (on/off).

There are many layers of code involved here, and I don't know the start-up sequence or how to get the analog input/pin on-off status read on a regular basis.

Where do you suggest I look to get started on this?

 

Today I tried Lab 1 from the SimpleLink Academy. It built with no errors, but would not run on the LaunchPad under Debug: the LED was not flashing. I tried plugging/unplugging the USB cable but it did not change.

So I started Flash Programmer and tried to reflash Project Zero, as before, to return to a known working condition. This ran for 10 minutes (I timed it) and did not finish, then I got this error message:

After this, I have been unable to reprogram the LaunchPad at all using either the on-line reprogramming buttons, the FlashRF, or CodeComposer.

This is very similar to the error I had before. It looks like something in the programming is changing something in the chips which is needed to (re-)program them.

Ideas?

YiKai

Thanks for your help. It fixed the problem, but I see no 'Verify Answer' button to click ...

Here's what I had to do - it may help someone else avoid problems.

I went to C:\ti\ccs_base\common\uscif\xds110 and found xdsdfu.exe  

I also found a ReadMe.txt file.  DO NOT OPEN THIS USING (Windows) NOTEPAD - the critical formatting will be messed up and you will not read the correct command sequence. Use WordPad or similar. Follow the instructions very carefully.

To enter the necessary commands using Windows I had to open a CMD window, and type in:

C:

cd \ti\ccs_base\common\uscif\xds110

xdsdfu -m

xdsdfu -f firmware.bin -r

I got this response:

USB Device Firmware Upgrade Utility
Copyright (c) 2008-2015 Texas Instruments Incorporated. All rights reserved.

Scanning USB buses for supported XDS110 devices...

<<<< Device 0 >>>>

VID: 0x0451 PID: 0xbef3
Device Name: XDS110 with CMSIS-DAP
Version: 2.3.0.2
Manufacturer: Texas Instruments
Serial Num: L1000648
Mode: Runtime

Switching device into DFU mode.

After this, I unplugged and replugged the USB cable. Then I ran SmartRF Flash programmer 2 using the file CC2650LaunchPad_BLE_All_v0_90.hex that I downloaded earlier. After SmartRF signalled success, I unplugged/plugged the USB cable again and the LaunchPad started BLE broadcasting. I was then able to connect to it using BLE. I have yet to try accessing it from CodeComposer. 

It's good to know that, once again, this was not a hardware failure but a software screwup. 

Can anyone tell me why I have less than a 50% success rate in sending code (that has built without reported errors) from the CodeComposer IDE to the LaunchPad? The same is true for the SensorTag platform.

This is not my code, or even TI code I modified - it is TI code, unmodified, straight from the TI download sites.

The frequent failure modes are not identical, but they have a common thread: the project builds and enters the downloading-to-the-target phase. Typically the first couple of steps will happen OK as reported in the CodeComposer window, and then progress will stop.  Once this has happened the ID of the target is corrupted somehow and heroic measures (see above!) are needed to get it back again.

I have waited a timed 20 minutes - it definitely stops, it's not just taking a long time. Sometimes Windows says the CodeComposer is unresponsive and it grays out (I'm using Win 10). 

A bad USB cable or USB port sometimes causes those trouble so you can try to replace an USB cable or use another USB port.

Thanks again YiKai for a prompt response.

There are three different computers - two laptops, and one desktop. The laptops are made by Asus and HP. The desktop is a Dell. The Asus is running Win 8; the other two are running Win10. We have tried several different USB ports on each machine, and several USB cables. This does not seem to make any difference. Some of the ports are USB 3 - again, that does not seem to matter. We mostly use the USB cables that came packaged with the SensorTag and LaunchPad.

Two different people here are working on this, and we are both getting these 'reliability' problems.

We have also used both Cloud and Desktop versions of CCS on these computers. Currently we are using the desktop version of CCS.

We don't get the same problems repeatably. In other words, I can't say "Do this, then that, and you'll see the problem." I can say that we get a lot of failures, and that the majority of the failures are hanging up when the dev board is being programmed. The progress bar, or progress pop-up, stops reporting any changes and you can wait for over 15 min We can have something work perfectly, and then try what we believe is the exact same thing a few minutes later and have it fail.

Finally, reading other posts from other people, we are not the only ones seeing these issues.

CCS is clearly a multi-threaded solution, and the progress window transiently reports threads blocked by other threads, waiting, and releasing to run again. I'm wondering if there is a possible deadlock condition between the various threads, perhaps only showing up in later versions of Windows (8 and 10).

What CCS version do you use? If you download Hex file using Flash Programmer 2, do you see similar problem?

YiKai

Again, thanks for a prompt response.

We're using Code Composer Studio 6.1.3 - do you need the more detailed information?

The similar issues with Flash Programmer 2 (1.7.4) are that when you plug in the USB you will see a red 'rotating circle' at the top left, which never goes away or stops, or you will see three devices in the left pane, all of which are 'XDS110 Class ... Unknown' so you can't connect or do any programming

Sometimes unplugging/replugging the USB will fix this.

It seems more reliable if you start Flash Programmer first, then plug in the USB, but this is not a 100% fix.

Here's the xdsdfu report:

C:\ti\ccs_base\common\uscif\xds110>xdsdfu -e

USB Device Firmware Upgrade Utility

Copyright (c) 2008-2015 Texas Instruments Incorporated.  All rights reserved.

Scanning USB buses for supported XDS110 devices...

<<<< Device 0 >>>>

VID: 0x0451    PID: 0xbef3

Device Name:   XDS110 with CMSIS-DAP

Version:       2.3.0.1

Manufacturer:  Texas Instruments

Serial Num:    L1000648

Mode:          Runtime

Found 1 device.

C:\ti\ccs_base\common\uscif\xds110>

This is with a single LaunchPad plugged in. We do not have more than one device plugged in at one time.

Hope this helps

Every thing looks OK to me and it doesn't make sense that you have such high failure rate when using LaunchPad. If you keep seeing this, I would suggest you to ask for replacement from www.ti.com/.../faq-returns-and-refunds.page