FreeRTOS, Sleep and UARTs issue

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

cross mob
Anonymous
Not applicable

 Hi everybody.

   

I have a blocking issue with a FreeRTOS firmware running on PSoC5LP, where I have to put device in sleep mode (by mean of SleepTimer component) and get my UARTs work as expecrted once firmware wakes.

   

My Idle Task is:

   

void vApplicationIdleHook( void )

   

{

   

UART_Debug_Sleep();

   

UART_Gprs_Sleep();

   

UART_Gps_Sleep();

   

CyPmSaveClocks();

   

CyPmSleep(PM_SLEEP_TIME_NONE,PM_SLEEP_SRC_CTW);

   

CyPmRestoreClocks();

   

UART_Gps_Wakeup();

   

UART_Gprs_Wakeup();

   

UART_Debug_Wakeup();

   

}

   

But despite tasks run as expected, there is no UARTs activity once firmware awakes from sleep.

   

Any suggestions?

0 Likes
5 Replies
MuKa_284621
Level 3
Level 3

 Hello,

   

 

   

This thread is a bit old, but I was about to ask the exact same question (albeit not using the FreeRTOS).

   

 

   

I'm guessing that the Active template registers may not have the UDB bit set. However I'm stuck with that problem so it's a blind guess.

   

 

   

Any ideas?

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I had a similar issue on a PSoC4 a few days ago. The reason was that I sent the UART to _Sleep(), which issues a _Stop() before the transmission was completed. There are different signals on PSoC5 indicating the process of sending bytes:

   

-The FIFO must be empty and when a transmition has been in progress, it must be completed

   

 

   

Bob

0 Likes
MuKa_284621
Level 3
Level 3

 Hello,

   

 

   

In the end, I found out that the UART was functioning, but that it somehow triggered a weird behaviour on my acquisition program (maybe a burst of zeros?).

   

 

   

Then again, I wasn't using any flow control mechanism so I should've expected anything to happen.

   

 

   

Maybe if I added some delay, it wouldn't do that?

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Just adding delay does not demonstrate the source of the actual problem,

   

leaves one open to a non repeatable design. Further testing would be advisable

   

to make sure, if delay works, why it works.

   

 

   

Regards, Dana.

0 Likes
MuKa_284621
Level 3
Level 3

Yeah, I had better do a proper debug.

   

 

   

But I didn't have time (and guts) to develop the solution further.

   

 

   

Nevertheless, I found out somewhere (I think it was in one of these forums 😃 ) that it is recommended to disable the output pin dedicated to communication when returning from LP modes as behaviours are not predictable. To avoid stray bytes (like what I had) and whatnot.

   

 

   

Cheers,

0 Likes