- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Labels:
-
PSoC 5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,