Wakeup from DeepSleep by Uart interruption

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

cross mob
VaPI_2771761
Level 1
Level 1
First like received

Hello, I need some help to construct my programme for a wakeup from deepsleep by uart interruption.

I have a GPS module whose send me NMEA frame.

My BLE module CYBLE-022001-00 is in Deepsleep State and I wait a new frame send by GPS for wakeup the BLE module.

My problem is when the BLE module wakeup, it doesn't receive the first byte because of Wakeup time.

Exemple :

I receive this : ±153935.000,A,5038.1687,N,00304.9711,E,0.39,250.86,020518,,,A*7A

Also the GPS module send $GNRMC,153935.000,A,5038.1687,N,00304.9711,E,0.39,250.86,020518,,,A*7A

The beginning "$GNRMC," is not catching by the BLE module.

My configuration:

GPS Baudrate : 9600Hz

PSOC Clock IMO : 6Mhz

pastedImage_1.png

I have two interrupt : one for wakeup and one for new byte

pastedImage_2.png

When I want to sleep :

GPS_UART_ClearRxInterruptSource(GPS_UART_INTR_RX_NOT_EMPTY);

GPS_RX_ClearInterrupt();

GPS_WAKEUP_ClearPending();

GPS_WAKEUP_Enable();

GPS_UART_Sleep();

GPS_RX_Sleep();

CySysPmDeepSleep();

GPS_RX_Wakeup();

GPS_UART_Wakeup();

I want to know if there is a solution for catch all byte and if the wakeup time to deepsleep from active state can be better ?

Thank you,

0 Likes
1 Solution
Anonymous
Not applicable

Hmmm; If you know that the wakeup bit is going to be lost, and you know it is always going to be a 0, then you could artificially reintroduce the bit back in once the unit wakes up and starts receiving the rest of the GPS frame. This would, however, require some processing of the data coming in to make sure it lines up.

This will work only as long as the beginning byte/bits of the GPS frame are constant however.

View solution in original post

0 Likes
5 Replies
Anonymous
Not applicable

Because the CPU is handling the UART receive (based on you having code for the UART handler), then it comes down to the buffer size of the UART and how long you take to service the data.

1. Try increasing the UART buffer size to be able to receive more bytes. Otherwise, it comes down to latency and how long the CPU takes to get to the UART interrupt and to handle the interrupt.

2. Try timing your ISR and see how long it is taking to execute; If it is too long, then the UART will overwrite the previous bytes and you will miss some.

3. Try just buffering/handling incoming bytes by only in the ISR, then processing them in the main loop.

4. Also, not sure how your code behaves in other locations, but the line: if(indexRxBuffer >=LEN_RxBuffer) GPS_ClearRxBUFFER(); will end up clearing the buffer if you receive too much data for your buffer.

This means that not clearing out the buffer when you finish processing a message, will cause the next message to overflow the buffer. Secondly, if you get an interrupt for a byte/message while you are clearing out the buffer, it may clear out the recevied byte as well (interrupt race condition), you might want to check/keep that in mind. A circular buffer for receiving bytes from the UART, and then clearing it out when you use it for processing works pretty well for saving as much data as you can while not losing data bytes except for the oldest bytes.

5. Depending on the priorities of your interrupts, the wakeup may or may not fire before the UART interrupt, and changing the priority/order may remove the first byte being dropped.

0 Likes
Anonymous
Not applicable

If you use the UART component, then you can set the RX buffer like in the image below:UART_RX_BUFFER_SIZE.PNG

0 Likes
VaPI_2771761
Level 1
Level 1
First like received

Hi,

Thank you for your response.

I have tried to increase my buffer size but without change... I'm sure that my interrupt handler is enough short for catching all byte receive.

I'm agree that process buffer value in interruption is not a good idea, I have changed that but without sucess.
I have tried to change the priorities without sucess...

Cypress support explain me that there are two constrains for wakeup from DeepSleep with Uart interruption (Datasheet SCB Serial Communication Block p171) :

The SCB block provides feature to skip start and synchronize on the 1st data bit. Usage of this feature implies two constrains:

▪ The 1st data bit of wakeup transfer has to be ‘1’ to synchronize the UART receiver.

▪ The wakeup time TDEEPSLEEP of the device must be less than one UART bit duration. Typical TDEEPSLEEP is equal to 25 μs (check selected device datasheet to get actual number of TDEEPSLEEP). This reduces the UART baud rate approximately to 40 kbps.

In my case, the first data bit isn't '1' because of GPS frame... So my first byte is corrupted and the solution will be another wakeup source and so, a new hardware for me...
If someone has another idea about synchronising the uart interruption wakeup, I'll take it

0 Likes
Anonymous
Not applicable

Hmmm; If you know that the wakeup bit is going to be lost, and you know it is always going to be a 0, then you could artificially reintroduce the bit back in once the unit wakes up and starts receiving the rest of the GPS frame. This would, however, require some processing of the data coming in to make sure it lines up.

This will work only as long as the beginning byte/bits of the GPS frame are constant however.

0 Likes

Hello epratt,

Thank you for the solution, it's the solution that works best.
I rebuilt my GPS packet with good data because, like you say, the beginning byte are constant