FreeRTOS/Deep Sleep problems

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
EdHa_4455331
Level 5
Level 5
25 replies posted 25 sign-ins 10 replies posted

I have been slogging through getting my FreeRTOS system to go into and come out of deep sleep. Of course, the system works perfectly when connected to the debugger (which makes the system only go into sleep instead of deep sleep). But things go wonky when the debugger is not connected. Since I can't use the debugger to the debug the problem, I've had to resort to using LEDs on my board to give me some clues as to where the system is going off the rails. 

TurnOnYellowLed();

// Go into low-power deep sleep state. The only thing that can wake us
// back up is an expander interrupt.
Cy_SysPm_CpuEnterDeepSleep( CY_SYSPM_WAIT_FOR_INTERRUPT );

vTaskDelay(3000);
TurnOffYellowLed();

Pushing the on/off button creates an "expander interrupt" that wakes up the system. Now (extra weirdness) the system seems to wake up correctly the very first time it goes to deep sleep after a cold start and the yellow LED stays on for about 3s after the wake-up interrupt. But on subsequent trips through this code, the vTaskDelay does not work and the yellow LED turns off immediately after the interrupt starts the system (and a see lots of other timing-related misbehavior in the code that follows).

I have experimented with setting configUSE_TICKLESS_IDLE to 1 because it seemed like it could be related to the problem, that that didn't fix anything.

Anybody have any ideas as to what I am doing wrong here?

Thanks,

Ed H.

0 Likes
1 Solution
EdHa_4455331
Level 5
Level 5
25 replies posted 25 sign-ins 10 replies posted

Thank you so much for taking the time to do that. I am basically doing what you are doing to wake up my system. But my overall interrupt structure is more complex. The on-button input in multiplexed through an expander IC with many other push button and sensor inputs, and they all then share one common interrupt out of that IC. Because an interrupt from source B could hit while an interrupt service from source A is in progress, the "while awake" interrupt handler has to be level sensitive so that no interrupts are missed.

EdHa_4455331_0-1641849834435.png

Things are further complicated by the fact that the push buttons have to be de-bounced and a distinction has to be made between a "long press" and a "short press" on some of the push buttons. So the overall interrupt processing is a little messy. It has all been working fine for almost 9 months (when only sleep and not deep sleep) was used. It only got wonky when I started using deep sleep.

That said, I wouldn't be surprised if some how the interaction between the two versions of the interrupt is screwing something up some where in my software. But at the moment I haven't seen anything that seems like it could cause the FreeRTOS timers to go off the rails. But now that you have demonstrated that the basic deep-sleep wakeup seems to work fine with FreeRTOS, I will discount a  problematic deep-sleep/FreeRTOS interaction as the source of the issue.

Thanks,

Ed H.

View solution in original post

0 Likes
2 Replies
lock attach
Attachments are accessible only for community members.
AlenAn14
Moderator
Moderator
Moderator
500 replies posted 100 solutions authored 250 replies posted

Hi @EdHa_4455331 ,

I tested out your approach on my 062-BLE-Pioneer kit and found the same to be working satisfactorily with Free RTOS. I am attaching my project here for your reference.

Can you please let me know if you are doing anything different from what I have done here?

Regards
Alen

0 Likes
EdHa_4455331
Level 5
Level 5
25 replies posted 25 sign-ins 10 replies posted

Thank you so much for taking the time to do that. I am basically doing what you are doing to wake up my system. But my overall interrupt structure is more complex. The on-button input in multiplexed through an expander IC with many other push button and sensor inputs, and they all then share one common interrupt out of that IC. Because an interrupt from source B could hit while an interrupt service from source A is in progress, the "while awake" interrupt handler has to be level sensitive so that no interrupts are missed.

EdHa_4455331_0-1641849834435.png

Things are further complicated by the fact that the push buttons have to be de-bounced and a distinction has to be made between a "long press" and a "short press" on some of the push buttons. So the overall interrupt processing is a little messy. It has all been working fine for almost 9 months (when only sleep and not deep sleep) was used. It only got wonky when I started using deep sleep.

That said, I wouldn't be surprised if some how the interaction between the two versions of the interrupt is screwing something up some where in my software. But at the moment I haven't seen anything that seems like it could cause the FreeRTOS timers to go off the rails. But now that you have demonstrated that the basic deep-sleep wakeup seems to work fine with FreeRTOS, I will discount a  problematic deep-sleep/FreeRTOS interaction as the source of the issue.

Thanks,

Ed H.

0 Likes