Hi, its me again…
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:
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.
@ 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.
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.
@ 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…
@ 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…
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 ?
why?
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.
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.
