I am using the Pearl Gecko uC and am streaming out 366 byte packets at 10Hz.
Within each packet, there are 2 constant start bytes and 2 CRC bytes at the end.
I have noticed however that after allowing the device to run for around 20 seconds, the data received gets shifted out of phase. As such, although in my code, I am requesting to send my start bytes, these bytes are never received on the client-side.
I have tried increasing my USART buffer size which offers some improvement but at the expense of more memory space. What else could cause this issue? Any ideas are welcome!
Did you ever check the output bytes of Pearl Gecko with a uart terminal ?
My wild guess is that the issue may has some relation with the firmware, since that enlarge the buffer size can improve the reliability.
@yucheng Thank you for your input!
Yes, I have tried connecting the Pearl Gecko to uart terminals like Tera Term and RealTerm in order to view the hex outputs from my device. I agree in that there may be something on the setup side in firmware that isn't optimized which is causing this issue. I have noticed that I set up a demo application that solely streams constant data packets, I don't appear to have this issue. However, when I add code for ADC sampling and SPI communication, this issue appears.
In debugging a little further, I can see that the read and write indices in the circularBuffer used for my TX buffer are out of sync when this issue occurs. For some reason, the read index drifts ahead of the actual write index. For example:
I have attached a copy of my usart setup code below. I don't really understand what would cause this issue though as the read index should only increment when it transmits a byte, unless I am getting unexpected TX interrupts somewhere...
Shouldn't the TXBL interrupt be cleared in the ISR?
Further, I'm no fan of pendingBytes. Incrementing/decrementing such a variable is not an atomic action on an ARM. I would drop it and use ((wrI - rdI)% BUFFERSIZE) instead. This way the producing side only updates wrI and the consuming side only updates rdI.
@vanmierlo your tip regarding the pendingBytes seems to have done the trick!