I am researching a situation where G120 COM1 stops working. It happens both during normal operation and during the in-field update. When it happens, a re-initialization of the COM port is required, thus requiring a restart of whatever communications were occurring as well. The impact on the in-field update is the worst, since it causes the receiving device (USBizi/NetMF 4.1) to require a manual update. Using a USBizi/NetMF 4.1 system to manage an in-field update, this does not happen. I am wondering if there is an open issue or a work-around for this?
I do not think there is an open issue about serial ports. Have you tried to subscribe to the error events? That may hint of possible overflow error.
Have you tried a small application to show this behavior?
Gus, my thanks for your quick response. Yes, we monitor for errors, and no, we are not getting any.
Your question about trying a small application is a good one and I will follow up on it. However, I have some questions regarding what this small application should be doing, and how it can be monitored for problems that would cause the COM port to go away.
Should we look for problems using a small application that has a similar rate of communication but has less overhead, for example, no concurrent use of other external interfaces like the SD card and no concurrent updates of the LCD display, just sending messages with predetermined contents?
Should we monitor the communications with a different technique that would give us information we do not currently get from the COM port? Do we need a serial data analyzer, and what would we be looking for- errors specific to the COM port implementation like bad bit timing?
And, should we use oscilloscope to check pins for some sort of external noise? Any suggestion on which pins?
We are not currently planning on reverting to a previous version of NetMF, since that would not be a long-term solution.
Will it be possible soon to try a later version of NetMF for the G120?
I am also having an issue with Serial Ports on G120, more ore less in all NETMF firmware versions I can remeber.
Sometime I get an ArgumentException (no more info on that) when I call SerialPort.Write().
I then Close and Open the Port, and call Write again with the same Parameters and it works.
Since this worked for me so far I havn’t mentioned it.
The Problem occurs not too often, may be once an hour when port is in constant usage.
I also think that ports stop receiving if you send them too much data sometimes.
I also loose single characters whenn I send too much to the G120.
@ SecretSquirrel - are your Problem related to one of the above?
@ Reinhard, Can you give me the amount of data that causes a problem for you? That way, I can answer your question more accurately.
The internal receive buffer of the Serial port is 256 Bytes.
If I receive more than that in a continous stream I loose a Byte sometimes.
To get the port not receiving any data at all anymore, a lot of data over a longer period of time is needed, but I can’t say exactly how much.
We do not get ArgumentException when we call SerialPort.Write()- however it is good to know that can happen.
We have transmit and receive queues at the application level that would overflow if we tried to send 256 bytes at once.
Three additional questions arise, knowing you have experience with G120 COM ports:
-
Do you get an error event or an exception when you send too much data to the COM port and it stops working?
-
Do you get the receive event at times when there are no bytes to receive? This is something we have noticed- not fatal but it does increase overhead.
-
When you overflow a G120 COM port queue (assuming both RX and TX have 256 byte queues) and you miss a byte, do you receive an error event from the COM port?
to somewhat answer the “what should a repro app look like”, it’s intended to allow others to be able to repro the issue without having your specific hardware implementation. So they shouldn’t need an LCD, they shouldn’t need your sensor suite etc, but an app they can load on a G120 board and have something to feed or read from the serial port (on say a PC). If you can extract that from your current app, and the issue is still obvious, then it should be able to be reproed at GHI or by someone else in the community. Much easier then to start exploring whether a different producer/consumer pattern helps or hinders, or if there is some hardware or firmware level things that need attention
I see why the question was asked now.
Since we would have to create a simple app on generic hardware on both sender and receiver to reproduce the in-field update scenario, there will not be time in the current budget to do that.
We will move forward, armed with the knowledge that the G120 COM port fails without warning for at least one other user, and the issue is fixed by closing and re-opening the COM port.