bi-directional TCP to serial bridge passage

During an investigation to implement the Digi ConnectME module inside devices which will be extend with Ethernet activities we encounter some problems with the serial port.
We are using a ConnectME module attached to the JTAG debug development kit which runs Net+OS 7.0.

Context description:
The application executes a bi-directional TCP to serial bridge passage where blocks of serial data will be transmitted over a TCP port and also in contrary direction.
During transfers the read object (running in a thread) reads raw data from the rs232 port “/com0” and passes the received data into a buffer. During tests a device (connect to the serial port) will transmit a line of multiple characters to the ConnectME module after receiving a character.

Problem description:
After sending a single character, the device has transmitted all the characters to the ConnectME module, however not all the transmitted characters can be received by the read object. After receiving multiple data blocks, the last data block transmitted by the device will not be rejected by the read object. Watching the rx_buf, this buffer length is equal to 0 whereas not all of the transmitted data is rejected. By monitoring the rs232 link all characters are send to the ConnectME module.
By sending a new character to the external device, the last data block of the previous transfer is received with the data blocks of the current transfer.
So far we can see it, something overrides the buffer flags or miss some synchronization between the serial driver and our source.

Source application:
for( ;; )
{
tcgetcounters(rs232_handler, &port_counters);
if((port_counters.nframe > 0) || (port_counters.noflow > 0) ||
(port_counters.norun > 0))
exit(1);
else {
tcgetbuffers(rs232_handler, &port_buffers);
if(port_buffers.rxbuf > 0)
{
return_value = read(rs232_handler, &character, 1);
if(return_value > 0)
{
return_value = send(file_descriptor_client_connection,
&character, 1, 0);
if(return_value <= 0) create_tcp_handler();
else character = 0x00;
}
}
}

tx_thread_relinquish();

}

Serial monitor logs:

ConnectME module writes character ‘a’ 0x41(hex) to the external device. The device answers with a number of 7 characters ‘0’ 0x30(hex) followed by the characters ”ACK”.
159 0.00000751 IRP_MJ_WRITE SUCCESS Length 1: 34
160 0.28121659 IRP_MJ_READ TIMEOUT Length 3: 30 30 30
161 0.00000000 IRP_MJ_READ Length 80

Writing the character ‘a’ again after 20 seconds. The previous log changes into:
159 0.00000751 IRP_MJ_WRITE SUCCESS Length 1: 34
160 0.28121659 IRP_MJ_READ TIMEOUT Length 3: 30 30 30
161 20.82727978 IRP_MJ_READ TIMEOUT Length 1: 30
162 0.00000782 IRP_MJ_WRITE SUCCESS Length 1: 34
163 0.29683995 IRP_MJ_READ TIMEOUT Length 6: 30 30 30 41 43 4B
164 0.00000000 IRP_MJ_READ Length 80

Can anyone help us by solving this problem or supply more information about the synchronization between application code and serial driver, we will appreciate.

Pleasant greetings,

ing. M.L. Scheuter
Software Engineer
Research & Development

If you are using a fast baud rate e.g. above 115k2 baud then you should check the state of the serial driver you are using in bsp.h . I was having similar problems and I found that the defines…

BSP_SERIAL_PORT_API was set to BSP_SERIAL_API_LEGACY
BSP_SERIAL_FAST_INTERRUPT was set to FALSE

which means that if you are using slow baud rates its OK but as soon as you try to push the comms then bytes are lost.

Set them to
BSP_SERIAL_PORT_API BSP_SERIAL_API_TERMIOS
BSP_SERIAL_FAST_INTERRUPT TRUE

and see how that goes.

This is actually a known issue. Soon there will be a patch on the support site with a serial driver patch that corrects this issue. If you need the patch sooner please contact a Digi Support Engineer through the Web Portal (http://www.digi.com/support/eservice/login.jsp).

Please note the patch is for NS7520 based modules such as the Connect ME, Connect EM, etc.

Charlie,

Is there an ETA on this patch? What specifically does this patch fix?

Thanks,
Brian

Engineering is still looking to give its blessing on this patch (hence why it is not posted). The patch is actually our NDS (plug and play firmware) serial driver ported to NET+OS.