Main Site Documentation

UART freeze on startup?



I’m developing a data logger using a FEZ Rhino which receives data from an external device on COM1, samples some analog inputs and then writes the data out on another COM port and logs the data to an SD card.

Everything works fine in debug and release versions when initiated from VS2010.

However if the USB cable to the PC is used simply to supply power then the app starts up but only logs around 9 records to the SD card, which at the 20Hz sampling means roughly 0.5s worth and then stops logging.

It appears as if the COM1 UART stops receiving data from the external device in this case.

I’m using the latest SDK 1.0.14 and have updated the FEZ Rhino firmware.



You can use debug.print to debug a bit more then use MFDeploy to view the messages.

If you use serial events then be careful on when you add the event. It has to be after you open the port


Okay thanks for the tip on using MFDeploy to view debug messages, I’ll use that to confirm what is happening in this situation.

I’m not using serial events in this project, simple loop based reads on the incoming UART.



Using MFDeploy I’ve been able to see that the reason for the apparent freeze when not launched via VS2010 is due to an out of memory exception after receiving loads of DataReceived events for a serial port that isn’t even physically connected, and again this only happens when the program isn’t launched via VS2010.

To recap the program sits in a loop reading from COM1 (not using serial events), reads a couple of analog inputs and then transmits a packet out 3 other COM ports and writes the packet to the SD card all at about 20Hz.

As a placeholder I have set up DataReceived event handlers for 2 of the COM ports, however nothing is currently physically connected to them yet.

_rockwellComPort = new SerialPort("COM1", 115200, System.IO.Ports.Parity.None, 8, StopBits.One);
_bluetoothComPort = new SerialPort("COM2", 115200, System.IO.Ports.Parity.None, 8, StopBits.One);
_pcComPort = new SerialPort("COM3", 115200, System.IO.Ports.Parity.None, 8, StopBits.One);
_telemetryComPort = new SerialPort("COM4", 115200, System.IO.Ports.Parity.None, 8, StopBits.One);

_bluetoothComPort.Handshake = Handshake.RequestToSend;

_bluetoothComPort.DataReceived += new SerialDataReceivedEventHandler(_bluetoothComPort_DataReceived);
_pcComPort.DataReceived += new SerialDataReceivedEventHandler(_pcComPort_DataReceived);


DataReceived event handlers are empty placeholders at the moment.

void _pcComPort_DataReceived(object sender, SerialDataReceivedEventArgs e)
	Debug.Print("PC Com Port DataReceived");

void _bluetoothComPort_DataReceived(object sender, SerialDataReceivedEventArgs e)
	Debug.Print("Bluetooth Com Port DataReceived");

When the FEZ Rhino is reset and only connected to MFDeploy to view the debug messages there are hundreds of calls to _pcComPort_DataReceived event handler, lots of garbage collections (not invoked directly by my code) and then an out of memory exception.

If the same program even in release mode is launched via VS2010 however there are no calls to the DataReceived event handler at all and the unit logs data without issue for hours.

So what could be causing the DataReceived events when not launched via VS2010 and it’s not clear what is actually causing the out of memory exception even in this case.

The BINARY_BLOB_HEAD type seems to grow and eventually lead to an out of memory exception.

I’m fairly certain I didn’t see this issue, although I didn’t do as much testing without using VS2010 to launch the app with an earlier SDK.

As mentioned earlier I’m using the latest SDK after having updated the firmware etc.



See my first reply


Thanks that did it!

To be honest I did see that comment of yours but discounted it since the only COM port currently receiving physical data doesn’t use serial events and the serial events I did set up were mearly placeholders for future features.

Also what confused me was the different behaviour I was seeing depending on whether the app was launched via VS2010 or not.

But internally what causes this sort of issue? How does registering an event handler on COM3 even if it isn’t open yet starts receiving events when reading from COM1?

Anyway thanks for the very prompt support.



I am glad you got it to work.

This is one of the things that needs to be enhanced on NETMF so hopefully in near future.

Let us know if you need more help :slight_smile:


The other positive side-effect is that before moving the serial event registration until after the Open method I was seeing a lot of packet corruption, the sender includes a CRC, when I was launching the app from VS2010. On the order of 30% of the packets were corrupt, now it’s down to typically 0.1%.

And in this case unlike the case with the app run without being launched from VS2010 the serial events weren’t being called erronously.

So it seems registering the serial events before the Open even on completely different COM ports has some really weird and nasty side-effects.


I think corruption is coincidently related to registering events