Reply
Posts: 143
Registered: ‎10-03-2015

BLE113 UART Data Loss / Corruption

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)

Posts: 143
Registered: ‎10-03-2015

Re: BLE113 UART Data Loss / Corruption

I should also note the same behavior in the bled112 and 121lr.

I have the sleep oscillator on as well.
Posts: 143
Registered: ‎10-03-2015

Re: BLE113 UART Data Loss / Corruption

I think I found it. Looks like the only solution that will work for me is slowing down the baud rate to 9600.

 

http://community.silabs.com/t5/Bluetooth-Wi-Fi-Knowledge-Base/REFERENCE-Using-or-bypassing-flow-cont...

Posts: 1,788
Registered: ‎08-25-2015

Re: BLE113 UART Data Loss / Corruption

Hi,

 

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.

 

Regards,

Tiago

Highlighted
Posts: 143
Registered: ‎10-03-2015

Re: BLE113 UART Data Loss / Corruption

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. 

 

 

 

 

Posts: 1,788
Registered: ‎08-25-2015

Re: BLE113 UART Data Loss / Corruption

Hi,

 

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?

 

Regards,

Tiago

Posts: 143
Registered: ‎10-03-2015

Re: BLE113 UART Data Loss / Corruption

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>

 

Posts: 1,788
Registered: ‎08-25-2015

Re: BLE113 UART Data Loss / Corruption

Hi,

 

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

realterm.png

 

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.

 

Regards,

Tiago