Serial Communication Error

Hi, its me again… :smiley:
Just for those who think i am to stupid to handle this device, i am porting a big project from 4.0 to 4.3 and there are many errors, which have to be fixed…
This time my error is the following thing:
After i initialize the SerialPort from System.IO.Ports.SerialPort and the first byte is transferred, the device instantly crashes and i get the following error message:

(during 1/2 second):


(after the 1/2 second):


After, i guess, 10 seconds the device automatically restarts…

Those are not any error messages that I recognize, and particularly the first block looks like it might come from the user code and not the underlying netmf code.

The main thing that needs to happen is to start eliminating things that aren’t causing the problem, and to collect more diagnostics:

Are there other threads running at the same time? Can you stop them to try to eliminate the chance that something is happening elsewhere to crash you program?
Is that really all the output? Are you running debug? Is that all that the debug stream outputs?
I presume that you are still talking about the G-400 from your other post, correct? (Just so we know your hardware and firmware setup).
Can you break (stop) the program at the point of ‘ERROR’ and capture thread lists, call stacks and the like?

My strategy at this point would be to start commenting out/removing stuff to pare the problem space down. Without your actual code, or more diagnostics to work with, I doubt the community can offer much more at the moment.

yes the g400 - sorry

i’ll collect everything i can…

@ mcalsyn -
Oh i think we misunderstood each other…
The error isn’t a NETMF exception, it seems more native and it gets ONLY displayed on the g400D built in screen.
It seems like the framework is crashing not the program itself…

Well, that explains why I haven’t seen that message before, but I think most of my recommendations still make sense. You’re going to have to start a process of elimination and diagnostic telemetry - less code, and more examination of diagnostics to narrow down the source.

In particular, does the debug output stream tell you anything more (the output you see in Visual Studio, or in MFDeploy after a ‘Connect’)?

So - pare down; review or add diagnostics; rinse; repeat.

EDIT: and any mention of a failure of ‘new’ probably signals an out-of-memory issue or RLP code that is corrupting memory. Does your program include any native code? Is memory exhausted?

No external native code but i think i know the source of the problem.
I did some debugging while i’m receiving serial data…
the data gets stored in an array list, because of the easy “appendability”…

var serialData = new ArrayList();
while (SerialPort.BytesToRead > 0)
     serialData.Add((byte) SerialPort.ReadByte());
byte[] convertedBuffer = (byte[]) serialData.ToArray(typeof(byte));

The bug occurs exactly when the program tries to convert…
that also would explain why it says new

I know you said you are converting old code, so I probably don’t have to point out that that is a pretty inefficient code, space-wise. I also realize that I don’t know your requirements, so this is real Monday morning quarterbacking on my part.

I think a fixed array buffer for the input would be much more efficient, even if you need to allocate a second buffer and use .CopyTo() to hand off the data (though handing off a reference to the input buffer itself would be even more efficient).

The idea is that you can’t let the ArrayList expand indefinitely anyway (and it seems in this case, it got too big to reallocate as an array), so you need to set an upper bound, and you might as well use an array to avoid the overhead of ArrayList.

The fewer uses of new and .ToXXX() and the fewer mem-to-mem copies, the more time and space efficient the code is. That ‘easy append’ is really costing you here.

EDIT: More info here : [url][/url] particularly section 2 describing the ArrayList base cost and growth algorithm. There may also be a ‘boxing’ cost of four additional bytes per character, and an inconviently timed ‘grow’ might have your ArrayList costing twice it’s actual content count.

1 Like

While it is inefficient code, it doesn’t change the fact that there’s a real live bug that’s been exposed here. Whether his code is wrong or not, it shouldn’t result in a crash of the framework; worst case, it should run slowly if it’s simply inefficient, or it should result in an exception (that he could handle) if it’s simply wrong.

1 Like

@ mcalsyn -
Yes you are right, but the crash sould not occur, because on the “ancestor” board, everything worked fine :-[
Meanwhile i didn’t have much time to work on the project, i will continue tomorrow…

So now i changed the code as you said. I used a byte array which’s size is allocated…

void _serialPort_DataReceived(object sender, SerialDataReceivedEventArgs e)
            byte[] data = new byte[SerialPort.BytesToRead];
            SerialPort.Read(data, 0, data.Length);
            var convertedData = ShortenBuffer(BitConverter.ToString(data));
            if (convertedData != null) Interpret(convertedData);

so … the same problem, as expected

@ quickshat -

what version SDK are you using? is it latest version

@ Dat -
No i don’t use the newest…
my coworker refused to use it because it isn’t marked as stable…
But i tested it on 4.3.8 and the error occurred too

Btw… i removed the Bitconverter and just put in a simple string, just to test it --> it worked,
so i took the Encoding but then i got an System.Exception with no more information…

Thats the problem, the exception is thrown without any information… just System.Exception…
BUT… i used a external bitconverter and the convertion works now… but my output is completely wrong…

¡¦£  ¥£¥

instead of

Step into: Stepping over non-user code ‘TwoSpeak.Program.’
#### Exception System.Exception - CLR_E_WRONG_TYPE (3) ####
#### System.Text.UTF8Encoding::GetChars [IP: 0000] ####
#### TwoSpeak.IO.Bluetooth::_serialPort_DataReceived [IP: 003c] ####
#### System.IO.Ports.SerialPort::DataEventHandler [IP: 0012] ####
A first chance exception of type ‘System.Exception’ occurred in mscorlib.dll
An unhandled exception of type ‘System.Exception’ occurred in mscorlib.dll

Thats the output… the same with Encoding.UTF8.GetChars()…CLR_E_WRONG_TYPE ?

Try with the following extension :

 bytes, int offset, int count = -1)
            if (count == -1) count = bytes.Length - offset;
            int bytesUsed, charsUsed;
            bool completed;
            var chars = new char[count];
            Encoding.UTF8.GetDecoder().Convert(bytes, offset, count, chars, 0, count, true, out bytesUsed, out charsUsed, out completed);
            return new string(chars);

It should avoid “non-standard” chars that can be present in your byte array.

@ andre.m - yeah! ;D

I’ll try your extension now … thank you

@ Bec a Fuel -
returns null :’(

How do you initialize your SerialPort ?

I think andre.m is on the right track - it looks like a framing or rate error. You are expecting simple ascii and are receiving jibberish. Sorting that out first will probably help matters greatly.

Building on what andre.m said : are the baud rates the same? stop bits? parity?

There’s no point in sorting out conversion if the byte stream is bad data.

The baudrate is definitely the same , parity is and stop bits too.
The communication worked fine before the switch of firmware