- 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
02-10-2017 05:54 PM
With BGScript I get RX data loss at baud rates higher than 9600. I am disabling watermarks in the RX event handler. I am just passing data back to the TX buffer and I see bytes dropped and in more rare cases corrupted bytes. (issue is on the RX side as I test data on the TX side and did not see an issue)
It's not a flow problem (I have flow enabled) because I have the issue just transferring a few bytes at a time. Its seemingly random. At 9600 baud I have no problems.
I seem to recall an issue like this some time ago, but I could not find it in the forum. Any ideas? I have the latest FW 1.5.
call system_endpoint_set_watermarks(device_endpoint, 0, $ff)
call system_endpoint_rx(device_endpoint, size)(ret_result, in_len, rx_buffer(rx_idx:in_len))
call system_endpoint_tx(device_endpoint, in_len, rx_buffer(0:in_len))
call system_endpoint_set_watermarks(device_endpoint, 1, $ff)
02-11-2017 01:55 PM
I think I found it. Looks like the only solution that will work for me is slowing down the baud rate to 9600.
02-11-2017 10:57 PM
I can't understand if you're exchanging data back and forth with a host device or you've just shunt TX and RX together, can you clarify? If it's with a host can you hook up a logic analyzer to see the signals? I know that Freescale MCUs had an issue with their flow-control which caused data corruption.
02-12-2017 10:22 PM
I tested the issue on different BLEXXX modules, but for simplicity let's just focus on the BLED112...
FW Version 1.5.0-137
I am using a BLED112 with a custom BGScript. The script simply echos back any data that it receives over the UART endpoint. I am sending the data to the BLED112 from a PC terminal emulator over its virtual COM port.
I can observe that at baud rates higher than 9600 I get data loss. For testing I am sending 8 bytes at a time from the PC's terminal emulator to the virtual com port of the dongle about every 500ms. The 8 bytes are echoed back by the BGScript. The data loss is generally the 2nd byte in the 8 byte packet and this happens on ~1% of the packets.
The data loss is in the RX buffer of the BLED112 because I tested sending the same data directly from the BLED112's TX buffer every 500ms and saw no loss.
Setting different watermarks did not have effect.
02-13-2017 12:18 AM
I'm not sure if there is flow-control on the USB implementation for BLED112. As I asked earlier, can you please show a logic trace of the UART and flow-control signals? I have not heard a single customer complaining about lost bytes (the flow-control is in the BLE1xx hardware so it's pretty reliable) except for 2 or so customers who were using Freescale MCUs where it turned out that the problem was in the MCUs flow-control implementation.
Can you share your BGScript so I can try this on a BLE1xx modules? Do you have some script on the PC side to send and receive back and compare the data which would could share as well?
02-13-2017 07:13 AM
Logic trace will be challenging on the BLED112. I'll have to break that dongle open to get to the IO lines.
I have no doubt the UART is bulletproof and I accept there could be some other explanation. I would be more likely to suspect the BGScript implementation. Clearly the default dongle with the BGAPI installed has no such issue. My BGScript code simply consists of the following event handler so it should be fairly easy to see if you can reproduce this, no?
event system_endpoint_watermark_rx(endpoint, size) # disable RX watermark temporarily call system_endpoint_set_watermarks(device_endpoint, 0, $ff) call system_endpoint_rx(device_endpoint, size)(ret_result, in_len, rx_buffer(0:in_len)) call system_endpoint_tx(device_endpoint, in_len, rx_buffer(0:in_len)) call system_endpoint_set_watermarks(device_endpoint, 1, $ff) end
Attached is a trace of the serial port of the PC while sending 7 bytes every ~500ms. The "<" indicates data from the PC to the BLED112 and the ">" is the response back. You will see near the end a missing byte in the response back from the BLED112. This is typical.
Again, the reason I say the missing byte never made it to the RX buffer in BGScript is that if I setup a soft timer that sends the same 7 bytes out at similar intervals I see no data loss.
Like the BLED112 I can reproduce this same behavior with a BLE121LR using a Silabs CP2104 UART to USB chip. I can trace the USB packets to and from the CP2104 so I am pretty confident the data is getting to the modules. I'll try and get a logic trace on this BLE121LR device since the pins are a little more accessible.
7 byte transmissions are not going to trigger flow control anyway are they? In any case here is my hardware xml:
<hardware> <sleeposc enable="true" ppm="30" /> <sleep enable="false"/> <slow_clock enable="false" /> <usb enable="false" endpoint="none" /> <usart flow="true" endpoint="none" baud="115200" alternate="1" channel="1" mode="uart"/> <script enable="true" /> </hardware>
02-14-2017 01:52 AM
I thought I had reproduced this problem but it turns out that it was related to the terminal emulator I was using (termite). I tried now with RealTerm and TeraTerm and both show no issues at all.
I've tested with your code 'as-is' and also with a more conservative approach with uses the tx watermarks to make sure there is enough buffer space before sending the data. Here's the script for that:
dim result dim in(100) # endpoint data in dim in_len event system_boot(major, minor, patch, build, ll_version, protocol_version, hw) call system_endpoint_set_watermarks(5, 1, 0) # enable RX watermarks, disable TX watermarks end event system_endpoint_watermark_rx(endpoint, size) # disable RX watermark call system_endpoint_set_watermarks(endpoint, 0, $ff) in_len = size # read uart RX data to buffer call system_endpoint_rx(endpoint, in_len)(result, in_len, in(0:in_len)) # enable TX watermarks call system_endpoint_set_watermarks(endpoint, $ff, in_len) end event system_endpoint_watermark_rx(endpoint, size) # send data call system_endpoint_tx(5, in_len, in(0:in_len)) # enable rx watermarks and disable tx watermarks call system_endpoint_set_watermarks(5, 1, 0) end
And here's how it looks in RealTerm when I send a bunch of "0123456789" (x30... altogether).
So my earlier suggestion still stand, please hook up a logic analyzer to the BLE1xx UART lines (RX, TX, CTS, RTS) because that's the best way to see if the USB<->UART bridges are violating the flow-control signals, I suspect they are.