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.

CC2630: CC2630 With a Custom Board

Part Number: CC2630
Other Parts Discussed in Thread: Z-STACK

Hello,

we have successfully connected a CC2630 to a custom board. Using the IAR EWARM we can:

* erase the memory;

* flash the Z-Stack sample applications;

* use the debugger (behaviour NOT consistent); and

* join a coordinator and exchange messages (retrieve active endpoints, simple descriptor, node descriptor).

Unfortunately every time we change the code we have to completely erase the flash and download the ZStackCore and the application (e.g. SampleSwitch) to the device. Otherwise the device gets stuck in the ICall_createRemoteTasks() call. Powering on/off the device does not help.

We haven't made any significant changes to the sample source code, which is actually written for the SmartRF06 development board (we changed the target to 'TexasInstruments CC2630F128'). The board we are using does not have the switches, LEDs, LCD, etc.

We are programming and debugging the device using an XDS100-V3 debug probe. 

Any ideas why we have difficulties re-programming and debugging the device?

Thanks in advance

Todor

  • Hi Todor,

    Does this happens in TI evaluation boards? or only in your custom board?

  • Hi Luis,

    sorry for the late reply. We don't have any evaluation boards. Sometimes the programming and debugging goes completely smoothly and sometimes the board has to be programmed several times. Once the application is started, the communication with the other ZigBee devices works as expected. The debugger can be also attached to the running target.

    Erasing the CC2630 with the Flash Programmer from TI works without any problems. Also reading the ROM works without problems. Could it be that we are using a wrong debug probe configuration under IAR EWARM? I also have the feeling that debugging is somewhat slower. We've previously used TI evaluation boards with a different ZigBee IC and downloading/debugging was faster, as far as I can remember. Back then we used 8051 instead of ARM.

    Thanks,

    Todor

  • Hi Todor,

    I do not think that the issue is a configuration on the debugger, since it would not work randomly (it would or it wouldn't work at all). My little experience on the CC2630 is that some times you have to load both, the stack library project and the application, in order to make it work.
    To discard any issue with the project and its configuration, I would suggest that if you could get a TI evaluation board to test your project in there and validate that this still happens, otherwise the custom board may have some connectivity issue for debugging.

    Hope this helps!
  • Hi Luis,

    I found this on the TI wiki:

    http://processors.wiki.ti.com/index.php/VMware_with_CCS#Linux_and_Mac_OSX_as_a_guest_OS

    It seems that the debug probe is very slow under OS X and Linux. I am using Parallels Desktop under OS X.

    Thanks for the help,

    Todor