- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
09-06-2017 08:09 PM
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!
Solved! Go to Solution.
09-07-2017 03:39 AM
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.
09-07-2017 12:11 PM
@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:
- Main loop: call usartPutData() and put 4 bytes for transmission
- usartPutData(): 4 bytes added to tx buffer at write indices 276-279
- USARTn_TX_IRQHandler(): tx buffer starts sending 4 bytes from tx buffer values starting from read index 278 -> results in first two transmission bytes being lost
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...
09-11-2017 05:24 AM - edited 09-11-2017 05:26 AM
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.