# missing bytes (serial / RS232)

**URL:** <https://forums.digi.com/t/missing-bytes-serial-rs232/3592>\
**Category:** NET+OS\
**Tags:** serial-interface\
**Created:** [September 4, 2007, 1:09pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592 "2007-09-04T13:09:37Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![compie](https://avatars.discourse-cdn.com/v4/letter/c/4af34b/32.png) [@compie](https://forums.digi.com/u/compie)\
**Post date:** [September 4, 2007, 1:09pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/1 "2007-09-04T13:09:37Z")

</div>

I have connected a Digi Connect ME to an Elmo Whistle motion controller via RS232.

Sometimes I’m missing a number of bytes (For example: I should receive 5 bytes but I’m only receiving one).

I have also connected a PC with HyperTerminal to the Tx pin of the Elmo Whistle and the PC does receive all bytes! So I’m 100% sure that the problem is on the Digi side.

I have checked the structure filled by tcgetcounters() but there are no overruns or errors.

What should I do to solve this problem?

Notes:  
I’m using a low baudrate (19200), 8N1, no flow control.  
I’m missing bytes only occasionally, most of the time I receive all bytes.  
I have tried blocking and non-blocking I/O, but this doesn’t matter.

#define BSP\_SERIAL\_PORT\_API BSP\_SERIAL\_API\_TERMIOS  
#define BSP\_SERIAL\_PORT\_1 BSP\_SERIAL\_UART\_DRIVER

---

<div class="post-metadata">

**Author:** ![compie](https://avatars.discourse-cdn.com/v4/letter/c/4af34b/32.png) [@compie](https://forums.digi.com/u/compie)\
**Post date:** [September 5, 2007, 7:00am UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/2 "2007-09-05T07:00:08Z")

</div>

Update: I’ve discovered this:

I keep polling read() to receive bytes for three seconds long. It keeps returning -1 and getErrno() == EWOULDBLOCK. If a that point I write one more byte to the serial port then read() is working again! It returns the ‘missing’ bytes.

That’s really strange, because I polled read() for 3 seconds and it keeps saying there are no bytes in the buffer, while there ARE bytes in the buffer.

So my code looks like this:

- keep polling read() for three seconds long
- no bytes are received  
tcgetcounters() -\> rbytes = 213, tbytes = 86  
tcgetbuffers() -\> rxbuf = 0, txbuf = 0
- write(1 byte)  
tcgetcounters() -\> rbytes = 217, tbytes = 87  
tcgetbuffers() -\> rxbuf = 4, txbuf = 0
- read() returns the missing bytes!

I think we need a fix/patch from Digi for this problem.

---

<div class="post-metadata">

**Author:** ![charliek](https://avatars.discourse-cdn.com/v4/letter/c/94ad74/32.png) [@charliek](https://forums.digi.com/u/charliek)\
**Post date:** [August 7, 2009, 3:28pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/3 "2009-08-07T15:28:03Z")

</div>

Hello all, I thought I might make a few comments. It looks like there’s at least 5 different serial problems all attached to the same thread.

Compie’s issue is tied to a NET+OS 7.1 serial driver issue where 1 - 3 bytes could get stuck in the FIFO because of character gap timings. The best fix is to move up to 7.2, the second best is to play with your character gap timings (i.e. directly mess with the registers) after you’ve setup the serial port.

nfgaida issue is with his code, it’s just bad (sorry). I’d use the attached code as a good reference point on how to use the serial port with select (and a TCP socket connection).

Joris’s first issue is that by default we enable software flow control. This causes 0x11’s and 0x13’s to be stripped from the data stream (and the data in between). Disable software flow control if you don’t plan on using it (again the attached example demonstrates how to use it).

Joris’s second issue is very likely bad coding or a transceiver that’s been put to sleep (see this article if you’re using the Digi Connect ME on the old dev board: [http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=751](http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=751)), data doesn’t just get ‘shifted’ by a couple of bits as it comes out the serial port.

sofjk’s issue is actually pretty interesting. Over run errors are described as:

Indicates that a receive overrun error condition has  
been found. An overrun condition indicates that the  
FIFO was full while data needed to be written by the  
receiver. When the FIFO is full, any new receive data  
will be discarded; the contents of the FIFO before the  
overrun condition remains the same.

Which means the serial driver wasn’t able to service the FIFO quickly enough. If the driver you’re using supports DMA (O\_DMA when opening the port) I would recommend using it to pull the data off the FIFO quicker. But this is also dependant on the module and NET+OS version you’re using (for example: I would only use DMA with the Connect ME in NET+OS 7.4)

---

<div class="post-metadata">

**Author:** ![nfgaida](https://avatars.discourse-cdn.com/v4/letter/n/a9adbd/32.png) [@nfgaida](https://forums.digi.com/u/nfgaida)\
**Post date:** [December 3, 2008, 5:37pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/4 "2008-12-03T17:37:14Z")

</div>

Have any of the patches released by Digi addressed this?

---

<div class="post-metadata">

**Author:** ![kubiajir](https://avatars.discourse-cdn.com/v4/letter/k/e19b73/32.png) [@kubiajir](https://forums.digi.com/u/kubiajir)\
**Post date:** [December 3, 2008, 8:33pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/5 "2008-12-03T20:33:09Z")

</div>

Try to use function: select() for reading. It is better than pooling and it also works better.

Jirka

---

<div class="post-metadata">

**Author:** ![nfgaida](https://avatars.discourse-cdn.com/v4/letter/n/a9adbd/32.png) [@nfgaida](https://forums.digi.com/u/nfgaida)\
**Post date:** [December 3, 2008, 8:37pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/6 "2008-12-03T20:37:22Z")

</div>

Select seems to be for sockets. Are sockets usable with serial UART communication?

---

<div class="post-metadata">

**Author:** ![sparkys\_dad](https://avatars.discourse-cdn.com/v4/letter/s/a6a055/32.png) [@sparkys\_dad](https://forums.digi.com/u/sparkys_dad)\
**Post date:** [December 3, 2008, 8:39pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/7 "2008-12-03T20:39:46Z")

</div>

As of NET+OS V6.3, the select() API supported BOTH sockets and serial ports. So yes select() is support on a serial port.

---

<div class="post-metadata">

**Author:** ![kubiajir](https://avatars.discourse-cdn.com/v4/letter/k/e19b73/32.png) [@kubiajir](https://forums.digi.com/u/kubiajir)\
**Post date:** [December 4, 2008, 10:52am UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/8 "2008-12-04T10:52:02Z")

</div>

Yes it is possible to use for UART.

Here is some exaple:

int fd;  
fd\_set read\_set;  
int ccode;  
struct serial\_buffer\_t serial\_buf;  
struct timeval wait;

wait.tv\_sec = 1;  
wait.tv\_usec = 0;

init\_RS()  
{…}

Read\_data(){  
FD\_ZERO (&read\_set);  
FD\_SET (fd, &read\_set);  
ccode = select (FD\_SETSIZE, &read\_set, (fd\_set \*) 0, (fd\_set \*) 0, &wait);

if ( ccode == 0) // timeout  
{}   
if (!FD\_ISSET(fd, &read\_set)) // some other error  
{}

tcgetbuffers(fd, &serial\_buf); //get num of recieved data  
read(fd,buf,serial\_buf.rxbuf);  
…  
}

Jirka

---

<div class="post-metadata">

**Author:** ![nfgaida](https://avatars.discourse-cdn.com/v4/letter/n/a9adbd/32.png) [@nfgaida](https://forums.digi.com/u/nfgaida)\
**Post date:** [December 3, 2008, 8:41pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/9 "2008-12-03T20:41:28Z")

</div>

Huh. Thanks. Wouldn’t have gotten that from the API doc page on select.

---

<div class="post-metadata">

**Author:** ![sparkys\_dad](https://avatars.discourse-cdn.com/v4/letter/s/a6a055/32.png) [@sparkys\_dad](https://forums.digi.com/u/sparkys_dad)\
**Post date:** [December 3, 2008, 8:46pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/10 "2008-12-03T20:46:16Z")

</div>

That piece of missing documentation is addressed in NET+OS V7.4. Digi was made aware of it after V7.3 shipped. It is included in the description of select() under internetworking\sockets\functions\select

---

<div class="post-metadata">

**Author:** ![nfgaida](https://avatars.discourse-cdn.com/v4/letter/n/a9adbd/32.png) [@nfgaida](https://forums.digi.com/u/nfgaida)\
**Post date:** [December 3, 2008, 8:47pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/11 "2008-12-03T20:47:52Z")

</div>

Where can I get NET+OS v7.4? I don’t see it on digi’s website. (at least not in the options for what version of net+os I have)

---

<div class="post-metadata">

**Author:** ![sparkys\_dad](https://avatars.discourse-cdn.com/v4/letter/s/a6a055/32.png) [@sparkys\_dad](https://forums.digi.com/u/sparkys_dad)\
**Post date:** [December 3, 2008, 9:03pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/12 "2008-12-03T21:03:52Z")

</div>

Please find the URL to the API reference guide for V7.4. As far as access to the kit, you’d have to talk with your distributor or Digi sales type.

[http://ftp1.digi.com/support/patches/CurrentApiReference.zip](http://ftp1.digi.com/support/patches/CurrentApiReference.zip)

---

<div class="post-metadata">

**Author:** ![nfgaida](https://avatars.discourse-cdn.com/v4/letter/n/a9adbd/32.png) [@nfgaida](https://forums.digi.com/u/nfgaida)\
**Post date:** [December 3, 2008, 9:11pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/13 "2008-12-03T21:11:17Z")

</div>

Is the “kit” in this case referring to the Digi ESP/eclipse environment, or the actual software + hardware?

I’d only be interested in getting the latest 7.4 software

(it would be awesome if they either upgraded eclipse or made it easy to use the digi esp environment in the latest version of eclipse).

Also, are the changes between 7.3 and 7.4 documented somewhere? The API doc doesn’t seem to have that information.

Thanks

---

<div class="post-metadata">

**Author:** ![sparkys\_dad](https://avatars.discourse-cdn.com/v4/letter/s/a6a055/32.png) [@sparkys\_dad](https://forums.digi.com/u/sparkys_dad)\
**Post date:** [December 3, 2008, 9:47pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/14 "2008-12-03T21:47:28Z")

</div>

If you are covered by a support contract then Digi sends you an upgrade to the software. You mention eclipse so I’ll assume you are running the GNU version. So I believe the upgrade includes NET+OS + ESP. Now what version of ESP and with what version of eclipse ESP inter-relates, I do not know.

If you are not covered by a support contract then you would need to contact your digi sales type or distributor to purchase an upgrade.

If you are covered by the support contract that comes with a jumpstart kit, then there is some limited window in which you can get an upgrade as described above.

I hope that helps.

---

<div class="post-metadata">

**Author:** ![nfgaida](https://avatars.discourse-cdn.com/v4/letter/n/a9adbd/32.png) [@nfgaida](https://forums.digi.com/u/nfgaida)\
**Post date:** [December 18, 2008, 5:48pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/15 "2008-12-18T17:48:25Z")

</div>

Roughly following your example, I have the same problem I had without using select. Basically, I’m waiting for 208 bytes.

After first power-on, I send my data out, and wait for the response. I read() the number of bytes that tcgetbuffers says is there. However, that number of bytes is less than I’m expecting. The most recent example was 36bytes. I send again, and this time, I have 172bytes bytes waiting (36+172 = 208). All sends after this had 208 bytes. Then, if I turn off the other end and do a send/receive one more time, there are 208 bytes waiting for me again (obviously they were sitting there from the previous send). After that all send/receive attempts end up with no bytes received.

Thoughts?

---

<div class="post-metadata">

**Author:** ![kubiajir](https://avatars.discourse-cdn.com/v4/letter/k/e19b73/32.png) [@kubiajir](https://forums.digi.com/u/kubiajir)\
**Post date:** [December 23, 2008, 6:44pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/16 "2008-12-23T18:44:34Z")

</div>

Can you publish your receive procedure?

---

<div class="post-metadata">

**Author:** ![Joris](https://avatars.discourse-cdn.com/v4/letter/j/f17d59/32.png) [@Joris](https://forums.digi.com/u/Joris)\
**Post date:** [January 6, 2009, 3:34pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/17 "2009-01-06T15:34:03Z")

</div>

For some reason, Digi has enabled some settings by default. Look if the missing data is one of the control bits and are therefore not received or transmitted.  
Mostly the values of 0x11, 0x12, 0x13 will be missing.

---

<div class="post-metadata">

**Author:** ![nfgaida](https://avatars.discourse-cdn.com/v4/letter/n/a9adbd/32.png) [@nfgaida](https://forums.digi.com/u/nfgaida)\
**Post date:** [January 6, 2009, 7:31pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/18 "2009-01-06T19:31:09Z")

</div>

I’ve attached the basic routine I am using for the receive thread.

Advance thanks for looking.

---

<div class="post-metadata">

**Author:** ![kubiajir](https://avatars.discourse-cdn.com/v4/letter/k/e19b73/32.png) [@kubiajir](https://forums.digi.com/u/kubiajir)\
**Post date:** [January 14, 2009, 9:35am UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/19 "2009-01-14T09:35:16Z")

</div>

Hi,  
I quickly looked to you code. I found one possible problem:

In this part of code:

nBytes\_Received = read( (int)fd, pRecvBuffer, serial\_buf.rxbuf );

if( nBytes\_Received == -1 ){  
everything in this part o code is bad  
}

See documentation - Read function.  
When the read() returns error you have to check for errno but not to start select() again.

I will take look at you code at night …

Jirka

---

<div class="post-metadata">

**Author:** ![nfgaida](https://avatars.discourse-cdn.com/v4/letter/n/a9adbd/32.png) [@nfgaida](https://forums.digi.com/u/nfgaida)\
**Post date:** [January 6, 2009, 7:31pm UTC](https://forums.digi.com/t/missing-bytes-serial-rs232/3592/20 "2009-01-06T19:31:58Z")

</div>

Those don’t seem to be the missing characters. In fact, there aren’t any characters that seem to go “missing”, just that the serial buffer lies about how many bytes are waiting.

[Next page](https://forums.digi.com/t/missing-bytes-serial-rs232/3592.md?page=2)
