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.

CC2650EM-4XD-RD: XBAL object failed - Forced Mass Erase Doesnt Work

Part Number: CC2650EM-4XD-RD
Other Parts Discussed in Thread: CC2650

Hello, 

I have about 30 custom boards that use the CC26504XS chip. I have previously programmed these boards using Flash Programmer 2 through 2-pin JTAG with either a SmartRF06 or LaunchPad board. No issues. However, now I keep getting "XBAL object failed" on a majority of the boards when programming. The ccfg file for the project was never changed so I'm not sure why it is saying that the board is locked. I've tried using Forced Mass Erase but it will either 1) have "XBAL object Failed" occur or 2) "Erases"(says erase was successful...) and then still can't program afterwards ("XBAL object failed" still). I have uninstalled and reinstalled Flash Programmer 2 and have also tried a different computer but the issue still occurs. Any help is appreciated as this is hindering my research. 

Environment:

  • BLESDK 2.2.0
  • CCS 7.4.0
  • tirtos 2.20.01.08
  • xdc 3.32.00.06
  • Flash Programmer 1.8.0

Thanks,

Johnny

  • Hi Johnny,

    Can you control your boards from SmartRF Studio? Can you try using the latest version of Flash Programmer 2? How many times have you reprogrammed the boards?

    Regards,
    Fredrik
  • Hi Fredrik,

    I will try with SmartRF Studio and get back to you. I believe 1.8.0 is the latest version for Flash Programmer 2 (http://www.ti.com/tool/FLASH-PROGRAMMER). And I have reprogrammed the boards about 5-10 times, some up to 15. 

    - Johnny

  • Hi Fredrik, 

    I want to give you an update. I was eventually able to program the custom boards using Flash Programmer 2. However, the boards' current consumption is much greater than expected and also not the behavior the boards were exhibiting couple months back (when it was working properly). Using an oscilloscope and op amp to perform current measurements, it was found that there is a spike every 8ms during advertising when advertising events should be every second. I could connect to the custom boards over BLE using a central device however the connection would periodically disconnect as well. The same exact code running on a TI CC2650EM-7ID exhibits the behavior I expect with advertising packets every second. This can be seen in the two graphs I've attached. Also the spikes for the custom board are also much greater than the evaluation module; EM-7ID has expected 8.5 mA adv spikes whereas custom board 14-17 mA. Both EM and custom board were powered by a DC power supply set to 3V for these tests. 

    Do you know why the code isn't executing properly on the custom boards that use a CC2650 4x4 chip? I have not modified the ccfg files and the custom boards use external oscillators for the LF (32.768 kHz) and HF (24 MHz) clocks just like the CC2650EM-7ID (checked registers and clocks are set properly). I am using the following lines of code to measure the clocks and will get back to you with an update. Any other suggestions are appreciated.

    IOCPortConfigureSet(IOID_7, IOC_PORT_AON_CLK32K, IOC_STD_OUTPUT);

    AONIOC32kHzOutputEnable();

    Thanks, 

    Johnny 

    Fig. 1: Current consumption for CC2650EM-7ID during advertising

    Fig. 2: Current consumption for custom board that uses CC2650_4x4 during advertising

  • Hi Johnny, 

    It is not possible to say what is causing the problems you see. Could the ICs potentially have suffered any ESD damage? What is the static power consumption in various modes of operation?

    Regards,
    Fredrik

  • Hi Johnny,

    I am marking this thread as resolved.

    Regards,
    Fredrik

  • Hey Fredrik, 

    Sorry for the delay, I've been busy with testing and trying to diagnose the issue. I repeated measurements to analyze the VDDR voltage of the custom boards and small spikes on the sawtooth curve can be seen (Figure below).  So the boards maybe have ESD damage (although I use gloves regularly) but I am still able to program them. Also, I commented out the SimpleBLEPeripheral task in main.c so that the board would enter deep sleep upon powering on; the frequent current spikes were still seen however. 

    1. Could this be due to pin leakage or an MCU setting as the spikes don't correspond to VDDR recharge looking at the figure? For reference, the MCU GPIO pins are initialized properly and are held to the correct voltage as defined in the board file.   

    2. Is there a way to verify programs are correctly flashed to the MCU? Maybe by reading the flash memory using Flash Programmer 2 and comparing it to the hex image?

    Regards,

    Johnny

  • I managed to figure out the answer to Question 2 using the readback function in Flash Programmer 2. All pages were successfully verified; however, the same high frequency spike behavior still occurred. I also want to know if soldering jumper wires to the PCB (to power and ground terminals of battery clamp) may be the reason for the MCU not functioning properly? (i.e. from the heat of the soldering iron)

  • - Have you tried the empty example from the SDK since this is the most basic example

    - Would you be able to do the same measurement on a launchpad as a reference? This to check that you don't have a measurement setup issue. 

    - Do you have a more zoomed in version of the plot showing one period of the VDDR voltage?  

  • 1. I tried the empty example (using Resource Explorer in CCS) for CC2650DK_4XS using TI-RTOS v.2.21.00.06 and the current spikes were still seen. 

    2. Yes, I also did the measurements using: a) CC2650DK_7ID + SmartRF06 board and b) previously fabricated test PCB with the CC2650 4XS that was used to verify the RF front end. Evaluation modules for the motordriver and accelerometer were used for this test PCB. (the custom PCBs in question consist of the consolidated circuit on a flexible PCB). Normal current consumption was observed for both (a) and (b); ie no frequent spiking.

    3. See below details of the VDDR voltage for the custom PCBs running SimpleBLEPeripheral. 

    Thanks,

    Johnny

  • I was reading through this thread again and I get the impression that the board has had normal functionality and that the board at one point has started to behave differently. 

    Does that mean all your boards have the same issue? Do you know when the good to bad happened? 

  • Any feedback?

  • Hi TER,

    Yes, all the custom boards are affected which makes me think its a software issue or the MCUs have been corrupted. I noticed this issue about 3 months back. 

    Thanks,

    Johnny

  • I doubt that you managed to damage all your boards in the same way at the same time. On the other side it looks like you have always had some issues with these boards.

    Have we done a review of your schematic to rule out any obvious mistakes? 

  • Yes, I doubt that as well which is why I think it could be some type of software or configuration issue with the MCU? However, the empty project still has this odd behavior as well. Is there a way to send you the schematic directly? I'm trying through the message board but looks like we may have to "Connect" (from your profile) first before I can send you a private message. 

  • I have now accepted your friend request so you should now be able to share the files in a privat message.

  • Case has been taken offline, closing he ticket here.