CC1352P: Code only runs with Debugger

One typical issue in cases like this is that the 32 kHz xtal is not starting. If you set the chip to use the internal 32 kHz RCOSC, does is then work? 

What SDK version is you using and what is the example you have used as a staring point? I assume you are using our drivers even if you do not use an RTOS.

I am using SimpleLink CC13x2 26x2 SDK (5.20.0.52).

I believe my colleague created a non-RTOS project using the CCS wizard to use as a development base and we are using the available drivers. When I get this issue fixed, I'll be switching to the TI-RTOS to get the BLE wireless link going.

No. Using the proj.syscfg facility, the LF Clock Source was LF XOSC. I changed it to LF RCOSC. No improvement on any of my four custom boards. Note that on one sacrificial board, we stripped off all unnecessary components (keeping the uC, uC support parts and 2 LEDs) and the problem still persists.

Could the GEL file be doing something during Debug, that the normal power on startup is not?

Latest observations.

We had a Launchpad Evaluation Board that worked fine and a Custom Board that failed. We swapped the microcontrollers (requires much skill). The problem followed the microcontroller. We now have an Evaluation Board that fails and a Custom Board that works.

Conclusion: There is a fault in the batch of microcontrollers that we ordered for this project. One was marked as follows:

      CC1352

      P1F3

      TI 261 E       <261> varied with part

      AKFJ  G4.     <AKFJ> varied with part

Request: Can someone at TI provide some new samples (qty 6) of the very latest vintage for us to install/evaluate?

Any response, comments?

Have you tested all the samples you have to verify that the chip is the problem? 

It sounds very unlikely that you have received samples from TI that does not work at all, as all our devices go through production test.

Could it be that your samples has been damages by ESD?

Siri

We purchased about 25 through Mouser (sealed bag) and used 8 of them. All 8 exhibited the power up problem. Our surface mount rework area is ESD compliant. It's possible we are not following the spec sheet heat cycle exactly, but the uC's are not destroyed (i.e. loaded code runs in debug mode). Also, the 'Evaluation Board' chip worked after a de-soldering and re-soldering operation. We are creating a test jig with a ZIF socket to check the remaining uC's. Will advise you of results.

Just to clarify, your statement 'samples from TI that does not work at all' is misleading. Code runs fine under Debugger. Code does not run with normal power up with no Debugger.

Most forum threads revolve around the LaunchPad hardware. Has anybody at TI received reports of similar failures when using custom hardware?

The fact that the code runs fine using the debugger, and not in stand-alone does indicate there is a HW issue on your boards related to the 32 kHz xtal (if there is a crystal) or the configuration of it, or that you are not using power modes properly.

I have never come around a problem where there is a chip issue that causes this , not saying that it is not possible, so I think it is hard to guide you as to what could be wrong.

Could you please take and test your board with on of the default examples in the SDK instead of using your own code?

Use the latest SDK (7.10) and run the gpistandby example:

gpiostandby (ti.com)

Do not do other changes on the code other than what is necessary to adapt to your HW:

Custom Hardware — SimpleLink CC13XX/CC26XX SDK Proprietary RF User's Guide 6.10.01 documentation

Can you confirm that you get this to work on a custom board with the "good" device taken from the LP, but not on the a custom board with a "bad" device received from Mouser?

Siri

Imported, built and loaded gpiostandby into 'dead' LaunchPad. Code worked and apparently fixed the power up issue. My LED blink code worked both with and without the Debugger.

I loaded modified gpiostandby (remapped LED to my target pins) into my 1 good and 3 failed Custom boards. They all worked and apparently fixed my failed boards. My LED blink code worked both with and without the Debugger on all my boards.

Loading the gpiostandby code seems to have fixed the issue. My code uses SDK V5.20.0.52. The gpiostandby code used SDK V7.10.1.24. Perhaps the SDK version is the cause of my power up issue.

Note: The fix is not complete. I modified ProjectZero to fit onto my Custom Board and it does not work without the debugger. But is also does not 'kill' the board since I can load my LED blink code and it continues to work.

I will investigate further and report findings. Thanks for your suggestions. I'm making progress.

When you say you adapted ProjectZero to run on my hardware and then you tried to update the SDK, do you mean that you tried updating your existing example to run on a new SDK?

If so, this is not the recommended way of doing this.

Please start by importing ProjectZero from SDK 7.10 into a new workspace. Use CCS-12.2.0.

Build the project before you change anything at all, to make sure that e everything is properly installed (correct sysConfig version etc.) and builds without errors.

When this is up and running, start modifying the sysConfig file to adapt to your custom HW.

If you follow this procedure, it is also much easier for us to be able to help you, as we can then later reproduce what you have done, step by step, to see if we can reproduce any issues you are experiencing.

Siri

Siri,

Your first statement is correct. I re-modified the ProjectZero sysConfig file per your procedure as best as I could remember. I basically just remapped some IO pins and the UART to match my hardware. My hardware is pretty close to the Eval Board. I have an extra UART, I2C device, and a SPI FRAM chip (all of which are safely connected to 'unused ProjectZero pins). The code builds, loads, and runs. But... the code just ends up in an Error Handler (see below). This is new. I don't remember seeing this before. I do appreciate your time and help with this.

Debugger execution paused indicates code in infinite loop.

void Error_raiseX(Error_Block *eb, int prefix, const char * id, intptr_t a0, intptr_t a1)
{
    Error_Block defErr;

     ....

  
    if (Error_policy_D == Error_SPIN) {
        for(;;) {
        }
    }
    else if (((eb == &defErr) && (Error_policy_D == Error_UNWIND)) || (Error_policy_D == Error_TERMINATE)) {
        System_abort("ti_sysbios_runtime_Error_raise: terminating execution\n");
    }
}

My latest observation:

I built and loaded ProjectZero code via JTAG Debugger onto the LaunchXL CC1352P-4 Evaluation Board, and started App. I was able to see and connect to Eval Board using SimpleLink Starter. I terminated the Debugger, removed and reinserted the Serial Cable (power cycle). The ProjectZero App no longer worked and did NOT show up in the SimpleLink Starter device scan list. What is going on here? This seems to be evidence of my original complaint using all TI equipment and software. Could you please confirm my observation?

Hi James,

I can confirm I see what you observe with project_zero, but this is expected behaviour.

Indeed, according to the project's readme: https://dev.ti.com/tirex/explore/node?node=A__ANwcbe4yYQk37n9EhfqTNQ__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK_BLE5STACK_MODULE__BSEc4rl__LATEST&placeholder=true

unless you define the EXCLUDE_OAD symbol in the project, the application will not start without BIM on subsequent power cycles.

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/971291/cc2652rb-project_zero-not-initializing-after-power-cycle

Regards,

Arthur

Arthur,

Thanks for your response (the most valuable one so far). I added EXCLUDE_OAD to Compiler Include Options and Linker Command File Preprocessing. It seems that is not sufficient, the ProjectZero still fails clean power-up. Your second link describes a massive code hack. Please tell me I don't need to do this! These flags usually control conditional Compile operations. What is the point of a conditional Compiler flag if it doesn't handle ALL of the conditional compilation? A general exasperation, I am not begrudging you or your advice.

James

Hi James,

Unfortunately, as said in the other thread, project_zero is a bit special in that regard

If you want to get started with BLE development, or at least validate the functionality, I would suggest you to start with either the simple_peripheral/central sets of projects.

Note that the OAD version of those projects will exhibit the same behavior as the project_zero project, that is, you need to have BIM flashed on the device.

Regards,

Arthur