RTOS/CC2650: Unknown CPU status

Kamen Ivanov

Part Number: CC2650

Tool/software: TI-RTOS

Hello,

I am having a custom board with CC2650 that seems to work fine. I am working to run another one, identical board, that was just assembled. I am downloading identical code to the both, the old board works fine, while the new one executes code well till BIOS_start(); - once starting Bios, the debugger reports "Unknown CPU status", perhaps the board halts.

What could the possible reason be? Is there a chance the MCU got damaged during soldering, or it might be another problem with external connections? The CC2650 voltages all seem fine...

over 8 years ago

0 Richard W. over 8 years ago

TI__Genius 14860 points

Hi,

looks like the chip has crashed. Are you sure that all crystals on the board are working properly? The only reason that I could imagine would be a hardware issue.

0 Kamen Ivanov over 8 years ago in reply to Richard W.

Intellectual 690 points

I just replaced the MCU with a new one and got exactly the same result, which indicates the MCU was healthy and problem is in peripherals... I will check the oscillators right away

0 Kamen Ivanov over 8 years ago in reply to Richard W.

Intellectual 690 points

There is one more observation: the code before BIOS_start(); is executed well when the board is connected to debugger. One not connected to debugger, however, it doesn't start. This should suggest problems with the RESET circuit, but both the resistor (100k) and the capacitor (100 nF) look normal, well soldered, and identical to the board that works fine...

0 Richard W. over 8 years ago in reply to Kamen Ivanov

TI__Genius 14860 points

Hi,

the CC13x0 starts with internal RC oscillators only and the LF clock derived from the HF RC OSC. Once you get to Power_init(), the power driver will activate external crystals and periodically checks whether they are working or not. This happens depending on the clock configuration in the CCFG. That means, you should at least get to Power_init() (or Board_initGeneral()) in your application even though your external crystals are not working.

You can force the chip to use the RCOSC HF as a source for the LF clock signal by setting the following your ccfg.c:

#define SET_CCFG_MODE_CONF_SCLK_LF_OPTION            0x0        // LF clock derived from High Frequency XOSC

Then you at least whether the LF crystal is working.

Second you can try an example that does not use any RF operation. Then the chip should keep running from the internal HF RCOSC and not switch to an external crystal.

0 Kamen Ivanov over 8 years ago in reply to Richard W.

Intellectual 690 points

Dear Richard,

Thanks for effort to help. For now I soldered on another pcb only the parts that related to start the MCU - however, I am getting the same result - the board can't start when standalone, and can run when connected on the debugger and debugger resets it. Once the MCU start it is possible to see relatively normal signal from the LF oscillator. For now I am not sure if the external HF oscillator works well. What is the best way to check if it is functional? Can I export signal from it (e.g. divided) to toggle a GIPIO pin?

Thanks

0 Richard W. over 8 years ago in reply to Kamen Ivanov

TI__Genius 14860 points

Hi,
could you post the relevant part of the schematic?

0 Kamen Ivanov over 8 years ago in reply to Richard W.

Intellectual 690 points

Dear Richard,

Thanks for the help that proved to be very useful so far. My latest efforts show that probable problems are related to not able to run the both oscillators properly. Although not recommended, with extreme care I tried to measure the signal from oscillators directly on XTAL pins, and I also have fed the 32kHz signal to a GPIO. I have finally tried several boards, only one of them seemingly working, and observed the following phenomena:

- In one of the non-working boards there was 32kHz signal while the 24Mhz one was missing. After attempts to revive all the boards (re-soldering the CC2650, re-soldering the crystals, etc.) I was not able to observe the LF signal at the XTAL pins anymore, while the HF oscillator worked in most of the boards. In that, the strange thing is that I still observed 32kHz signal at the GPIO although I didn't intentionally enable the internal RC oscillator nor defined USE_RCOSC. When setting the CC2650 to use the internal RC LF oscillator, most of the boards started normally. I am yet to investigate what caused the mess with the LF oscillator setting in my previous code.

So here is one last question before closing this topic: as I can only find information how to feed the external LF oscillator signal to GPIO, is it possible, under any circumstances, to feed the internal LF oscillator oscillator to a GPIO pin in similar way, i.e. with an instruction like

IOCPortConfigureSet(IOID_3, IOC_PORT_AON_CLK32K, IOC_STD_OUTPUT);
AONIOC32kHzOutputEnable(); ?

Thanks for the great help so far, it was very useful.

0 Richard W. over 8 years ago in reply to Kamen Ivanov

TI__Genius 14860 points

Hi,

the AON_CLK32K is generated from any LF clock source. This is the official TI-RTOS way of routing it to a pin:

    #include <ti/devices/cc26x0/driverlib/aon_ioc.h>
    #include <ti/drivers/pin/PINCC26XX.h>

    PINCC26XX_setMux(pinHandle, Board_LED1, PINCC26XX_MUX_AON_CLK32K);
    AONIOC32kHzOutputEnable();

You can measure the HF OSC signal indirectly by setting up a PWM:

#include <ti/devices/cc26x0/driverlib/timer.h>
    #include <ti/drivers/power/PowerCC26XX.h>

    // Route the HF clock to a pin via a timer.
    
    /* Switches the peripheral power domain on */
    Power_setDependency(PowerCC26XX_PERIPH_GPT0);
    /* Prevents the controller from going to standby */
    Power_setConstraint(PowerCC26XX_SB_DISALLOW);
    // Route the timer pwm output to a physical pin
    // EVENT0: GPT0 A
    // EVENT1: GPT0 B
    // EVENT2: GPT1 A ...
    PINCC26XX_setMux(pinHandle, Board_LED1, IOC_PORT_MCU_PORT_EVENT0);
    // Set up timer A as PWM
    TimerConfigure(GPT0_BASE, TIMER_CFG_SPLIT_PAIR | TIMER_CFG_A_PWM);
    // Count until 1 before reset
    TimerLoadSet(GPT0_BASE, TIMER_A, 1);
    // Set the duty cycle to 50% (0)
    TimerMatchSet(GPT0_BASE, TIMER_A, 0);
    // Enable the timer
    TimerEnable(GPT0_BASE, TIMER_A);

If you are running a TI-RTOS application, you will only see a clock signal at any pin, if you forbid standby:

    /* Prevents the controller from going to standby */
    Power_setConstraint(PowerCC26XX_SB_DISALLOW);

When the chip goes into standby, IOs are frozen. That might explain why you see the clock signal disappearing (?).

0 Kamen Ivanov over 8 years ago in reply to Richard W.

Intellectual 690 points

Dear Richard,
Thanks for the continuous support to clear the matters above - all the information and advices you provided were very helpful to resolving my issues. They will perhaps help many other users too.
Kamen

0 Richard W. over 8 years ago in reply to Kamen Ivanov

TI__Genius 14860 points

Cool. Could you resolve your issue? Was it one of the crystals?

0 Kamen Ivanov over 8 years ago in reply to Richard W.

Intellectual 690 points

Indeed, in most PCBs it was the external LF oscillator didn't start. Since I am a bit in hurry to deliver the project at present I am using the internal 32kHz oscillator; I am interested to play more with the external one, though, so I will spend time on that later to see what was the actual problem of the external oscillator.
By the way, in terms of power consumption, does the consumption increase in any way when using the internal LF RC oscillator compared to using the external one and if so what would be the reason (I have read this is the case with Nordic MCUs - nrf52832, so that's the reason to ask the same question for the CC2650)?

0 Richard W. over 8 years ago in reply to Kamen Ivanov

TI__Genius 14860 points

Power consumption is equal, but the internal RCOSC requires frequent calibration. This happens automatically in background and if you perform an RF operation from time to time, then you won't see any effect. However, if your application is in standby most of the time, then the calibration process might be considerable because the device needs to wake-up, start the HF crystal, run the calibration and go back to standby. You find more information in this app note section 4.1. Please also beware the CC2650 errata.

Bluetooth®︎

Bluetooth forum

RTOS/CC2650: Unknown CPU status