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.
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
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.
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