CC1314R10: How did I get deep sleep?

Gullik Webjorn

Part Number: CC1314R10
Other Parts Discussed in Thread: SYSCONFIG

I am debugging a project unde CCS 12.8.1. I notice that my board suddenly stops and becomes unresponsive. If I stop it using the debugger || symbol, if is in the

PRCMDeepSleep(void)
{
// Enable deep-sleep.
HWREG(NVIC_SYS_CTRL) |= NVIC_SYS_CTRL_SLEEPDEEP;

// Wait for an interrupt.
CPUwfi();

// Disable deep-sleep so that a future sleep will work correctly.
HWREG(NVIC_SYS_CTRL) &= ~(NVIC_SYS_CTRL_SLEEPDEEP);

}

procedure. I can continue from that point, leading to the suspicion that I have somehow enabled the deep sleep function. Where is that located and how do I turn it off?

I have not enabled this function actively, the code location indicates interrupts are not coming through, and have several interrupts that I believe are running (or should be)

Regards,

Gullik

PS. I started asking this question in the e2e subgigahertz forum, but end up here in TI.COM. Why??

28 days ago

0 Arthur R☑️ 28 days ago

TI__Mastermind 25896 points

HI Gullik,

You can disable DeepSleep/Standby by switch the Power driver policy function to doWFI in SysConfig:

Regards,

Arthur

0 Gullik Webjorn 28 days ago in reply to Arthur R☑️

Intellectual 570 points

Thanks Arthur,

I have misunderstood the problem. It seems the code IS running, at least the interrupts, but the main loop does not.

I am getting timer callbacks, so I guess I am to blame for screwing something up in the source.

I noticed that the radio callback actually works, since it toggles a led , but so brief it is hard to see.

I also placed a breakpoint in the timer routine, and I hit that. Removing that breakpoint and proceeding, all is dead.

So, I guess I have to do some elaborate stack tracing to find out what triggers this. It is not an infinite loop, and the SP stays in the middle

of the stack.

Do you know if there is some writeup / docs on the "nortos environment"?

Regards,

Gulik

+1 Arthur R☑️ 26 days ago in reply to Gullik Webjorn

TI__Mastermind 25896 points

Hi Gullik,

We have some more information on NoRTOS here: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_8_31_00_11/docs/drivers/doxygen/html/index.html#nortos

Please be careful when placing breakpoints when receiving packets, as it will most likely cause the rfcore to overflow, since the application processor cannot unpile the data queues.

Regards,

Arthur

0 Gullik Webjorn 21 days ago in reply to Arthur R☑️

Intellectual 570 points

Thank you Arthur,

All is well, I had a bug where I might call the radio subsystem while it was processing a previous command.

This is all sorted out now, and the application runs well.

Thanks for the pointer to the nortos doc, I had not found that before, but it does make a lot of sense to "emulate" an OS,

so that all drivers can be "unchanged" when going between the two environments.

Best Regards,

Gullik

Sub-1 GHz

Sub-1 GHz forum

CC1314R10: How did I get deep sleep?