Trouble reading from the RV50 serial port


My problem could be related to this one : [url]], but the provided answers to this post didn’t help me to fix mine.

I run an application on an RV50 that’s supposed to read data from the serial port. But the data frames that I read are wrong and don’t match with the frames I send (To be precise, it works sometimes but like 80% of the time datas are wrong and I need a 100% reliability system).

Here are pieces of my code :

In the first place, I reserve the serial port :

-- Check if the serial port has been reserved for AAF --------------------------
-- if not, reserve it ----------------------------------------------------------
function reserve_serial_port (string)

	LOG = LOG .. "inside reserve_serial_port, string: " ..'\10'
	local serial_available = devicetree.get(string)
	LOG = LOG .. "inside reserve_serial_port, result to devicetree.get: " .. serial_available..'\10'
	print("inside reserve_serial_port, result to devicetree.get: ", serial_available)
	if serial_available ~= 1 then
		local result = devicetree.set(string, 1)
		LOG = LOG .. "Reserving Serial Port for AAF. Result: " .. result..'\10'
		print ("Reserving Serial Port for AAF. Result: ", result)
	LOG = LOG .. "Serial Port Reserved" .. '\10'
	print("Serial Port Reserved")

Then I configure the serial port :

-- open and configure UART				----------------------------------------
function open_UART (string)

	print ("Inside open_UART, string: ", string)
	LOG = LOG .. "Inside open_UART, string: " .. string..'\10'
	local portname
	local i = 0

	if string == "main"
		portname = "/dev/ttyS0"
	elseif string == "aux"
		portname = "/dev/ttyS2"

	print("Portname called within open_UART: ", portname)

--  Serial configuration : 19200 bauds, 8 datas bits, No parity, No flowcontrol, 2 stop bits
	local serial_config =
		flowcontrol = 'none',
	local serialdev =, serial_config)
	return serialdev


And to finish, I read from the serial port :

function receivefromuart(uarthandle)

	print("Inside synchronize")
	local err
	local Pointeur_Write_Buffer
	while true do  --  permanently read on the UART
	uarthandle:settimeout (1)
	local read1_buffer, err = uarthandle:read("*a") --lecture des caractères arrivant sur l'UART

	if read1_buffer ~= nil then 
			synch_buffer = synch_buffer .. read1_buffer
			print("_________________ received data is: __________________")		
			Pointeur_Write_Buffer  = string.len(synch_buffer)
			print ("Longeur Buffer :",Pointeur_Write_Buffer)
				if Pointeur_Write_Buffer <= 24 then
				LOG = LOG .. "Longeur Buffer :" .. Pointeur_Write_Buffer .. '\10'
					synch_buffer = ""

Let me know I you need more details about the code.

I run this code on many LS300 and I never had problems. I tried on 2 different RV50 for the same result, but every time what is read is not what is sent…

I tried to upgrade the RV50 firmware ( ->, but same issue for both.
I also tried to change the flowcontrol setting and I have only one application on the RV50.

My settings in the Acemanager :

Hi Dylan,

Could you be more specific on how the read data are wrong? (i.e. corrupted bytes, or misaligned frames?)
I saw no obvious prb with your code.

Sometimes bytes are missing, sometimes I just have zeros where usually datas are…
I guess it’s not helpful…

I could eventually screenshot some good/bad frames to let you see if you don’t have any ideas but I don’t think it will help.

If bytes were corrupted I would think of a hardware issue (bad cable for instance).
For misalignment issue, it could be caused by the timeout, the way you read your data. In general I do not recommend using “*a” pattern + timeout. for normal reading on the serial port. It is usually better to read the number of bytes you actually need.
A typical algorithm:

  1. Phase one: read each byte one by one (serial:receive(1)), until a synchronization pattern is found
  2. Phase two: read a frame with the exact byte count. Some time the frame is variable size, in that case I read the minimum number, parse it and infer the rest of the frame size (for instance if the frame size is in the packet header)

Another note: I have found that closing/reopening the serial port while reading does cause some weird data to be read, so make sure you do not close/open the serial port during the receive operation.