Main Site Documentation

ChipworkX COM3 Serial Overruns


I am trying to use COM3 to communicate with a GSM modem. I have tried 115200 and 57600 bps but I keep getting overruns on the communications even just with the simple AT commands. I haven’t even got to the stage of doing a PPP connection with a flow of data.

I found a few posting here about lack of RTS/CTS support on COM3. Not so great considering the lines are shown on the brochure and dev board.

I am monitoring RTS and CTS with a scope and they are both at a LOW level which would make them active.

I have noticed that setting ReadTimeout to zero gives me less overruns. With it set to 10ms I get lots of them. What is the purpose of ReadTimeout?

Is all a bit strange as the same code was used with a Sytech Nova board and it ran without any overruns.

Any clues to setting issues with the ChipworkX that I might have missed?

If I can sort this out, I will have successfully ported the code over to the ChipworkX as all the I2C analog stuff is working. I have even managed to sort out the touch and have a nice stable touch input now with my custom LCD.


Any tight loops in your code with no sleep?


The only thing I have added since I ran this on the old module is the touch driver. This just checks the PENIRQ input and then sleeps for 50ms.

No other code changes.

Oh wait. The ADC handler now has devices on the PCB. Before they were not fitted. It was trying to read them but failing with an exception. Now it is reading them.

Let me go check the timing. Would be strange though as this is the same code I ran on the 200MHz Nova board without any serial data overruns. I can try to disable it again and see.

I assume that the serial port drivers are actually interrupt driven in the background are they not?


You should not have any loops with no sleep in them; otherwise, the system become unstable.


Yeah. All loops have sleep in them. The ADC has one at the end, between and wherever there is a loop of some kind.

I’ll need to look through the code and find out why it fails with the ADC thread running. I disabled it and now the overruns are no longer happening. Mmmmm.


Just can’t get COM3 to work at 38400 or 57600. It seems to be stable at 19200 so far this evening.

Luckily this is SMS based only, with GPRS only ever been used to do a system update. At that time I can shutdown the Analog thread and increase the baudrate for the duration of the download. A bit messy but seems to be the only workable solution.

I did spot another thread elsewhere that talked about overruns and the lack of RTS and CTS support.


I have had the same issue -

Following much diagnostics - and discussions with other members (also Gus via phone) the conclusion is that I was tying the processor up. Basically if you have a high enough CPU load the software routines to empty the ~100byte buffer that sits in between the character buffer and the FIFOs does not get called soon enough.

At the moment I am not aware of a means to force the routine to run at a set interval beyond letting the dispatcher handle it via Thread.Sleep() calls as mentioned above.

After modifying my program to reference static buffers and reducing the UART baud rates to near minimum (9600) where I can, I still get the occasional underrun requiring re-request for data.

Frustrating to say the least as the system masquerades as an OS with a thread dispatcher but isn’t aggressive enough in prioritise the key system threads over the managed code. I have also tried lowering the priority of any instantiated threads to ThreadPriority.BelowNormal and so on with no apparent effect.

As I understand it in order of data flow:

A) Serial Character Buffer (Hardware Interrupt)
B) ~100byte buffer (Software Interrupt?)
C) Large FIFO buffer (Event triggered on DataReceived)

The issue seems to be at the B to C stage.


I am curious to see if 4.2 would make this better. But there is no 4.2 on chipworkx sadly.

I think some tweaks and possible RLP will make it work though.


It’s kind of strange as I get this overrun on short data. I sent a request to the modem and it replies with up to 20 characters. At least one character is lost on reception.