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.

CC2640 performs differently (worse) when powered up externally vs. when reset through the debug interface

Other Parts Discussed in Thread: CC2640

I'm working on a custom device using the CC2640 chip.  My firmware started out based on the SimpleBLEPeripheral project, but has been expanded significantly since then.  I have had several instances where I notice substantial performance degradations when I try to run the device on an external source (battery), so I am trying to figure out what the source of these differences is.  I'm using the XDS110 debugger.

The device works well when I:

  • Run the device in debug mode from CCS.
  • Flash the device using Flash Programmer 2.  
  • Connect and disconnect from the device with Flash Programmer 2 (so that it resets the board)
  • If I do any of these, and keep the board booted up, and remove the debug cable, it continues to perform well

However, then if I remove power and restore power, the device consistently performs differently.   

Performance issues include:

  • I have a line related to updating the advertising data within the main loop.  If I remove that line, it will work fine when run as above, but the program will not run at all if I power cycle it without the debugger.
  • I have a fixed-rate data transfer over a notification characteristic.  If I run it as above, the data transfer completes perfectly.  If I power cycle it without the debugger, it works fine until I try to transfer the data, then it transfers the first packet and then fails.

It's possible in each of these situations I've done something wrong, but then why would it run differently in the two boot-up conditions?  What is different between a simple power-up vs a board reset through the debugger that could cause this kind of issue?

Thanks,

--Allen 

  • Hello Allen,

    It's hard to say, but perhaps the debugger is compensating for a HW issue. Does your SW run OK on a TI Reference board (LaunchPad or SmartRF06, etc)? Can you post your schematic & layout for review?

    Best wishes
  • That's a good thought.  However I have replicated the problems on SensorTag boards.  I assume that would be sufficient to exclude a hardware issue?  

    If I sent you the hex file, could you try to replicate it?  If you could replicate it I would be much obliged if you would take a look at my code, but I would prefer not to post it publicly.  (I'd be happy to post the solution including code excerpts when we discover it, however.)

    Thanks,

    --Allen

  • Allen,

    If the issues are reproducible on SensorTag hardware then we will certainly look into it. Please identify the minimum steps for us to reproduce this on the SensorTag platform. Code snippets where changes are required should be sufficient as I understand that you want to protect your code.

    I would start with SimpleBLEPeripheral and provide the steps required for us to see the issue and we will attempt to recreate on SensorTag . also if you have any hardware information about your SensorTag device (board revision, debugger FW version, etc) please provide that.
  • Can you elaborate what you experience when you say performance is worse? What kind of battery do you use? Have you tested an external power supply? What is the peak current for your application?
  • @ CHS

    (1) I described two instances where the program did not run as intended.  These were the performance differences, so perhaps "worse" was a bad adjective to use, it either performs as intended or apparently crashes / doesn't run.

    (2) 2xAA, or coin cell, or external digital DC power supply, or Vdd from the XDS110.  All effects were the same.  Draw is under 10mA

    @ Sean2

    I'll try to get something for you to try out.  The fact is I found a workaround for the issues identified, but the fact that I've run into the same behavior multiple times does make me want to figure it out so I can have a real solution (and share it) for future experiences.

    --Allen