C# read .hex file incorrectly on Chinese PDA

[cgladd87]

I'm using a stream reader to read a hex file on the pda from a C#
program that I am converting from VB.net. The problem is that on some
of the lines, the hex is changed from its actual values. The same file
reads in fine in the VB.net program and I have checked to the bytes in
the file and am sure that they are correct. The first line of the hex
file reads in correctly but all subsequent lines have a 2 subtracted
from one of the hex numbers and 2 added to the last hex number. It is
always the same position and even though I'm just reading this in as
as string, I'm relatively sure something intelligent is happening
because if needed the subtraction will borrow from the number in front
of it, changing two of the hex numbers. This only happens with my
Chinese PDA and only when I'm using the C# version of the program. I'm
using a Chinese Dell Axim 51 for this project. I don't know what could
be changing the file or why but I need to accurately read in the hex
number as they are the program for our micro. I've tried different
encodings for the stream as well as a BinaryReader and end up with the
same result. My code is as follows:

FileStream inFile = new
FileStream(Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase)
+ "\\Firmware\\" + filename, FileMode.Open, FileAccess.Read,
FileShare.None);
StreamReader sr = new StreamReader(inFile,Encoding.ASCII,
false);

line_input = sr.ReadLine();

while (line_input != null)
{
(DO WORK ON THE STRING)
Application.DoEvents();
line_input = sr.ReadLine();
}
sr.Close();

Thanks,
Chris

 

[cgladd87]

An example of what is happening is as follows:

Here are the first four lines of my .hex file.

:040000000C94D60086
:040040000C94570CB9
:040048000C943609D5
:040078000C9471056E

They are being read in like this:

:040000000C94D60086
:040040000C94550CBB
:040048000C943409D7
:040078000C946F0570

As you can see the first one is correct but the other three are
changed with the fifth digit in from the right having two subtracted
from it and the end digit having two added to it.

 

[Guest]

You're certain it's on the read, and not during processing that it gets
altered? How are you "verifying" the output (i.e. what's in your "DO WORK
ON THE STRING" code)?


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com

 

[cgladd87]

Yes I'm sure it's on the read. I'm checking the line right after it is
read in, before the processing of the string has occurred. The work
done on the string doesn't alter it at and basically converts the hex
to bytes two hex numbers at a time. I'm definately sure that the
problem is on the read though.

 

[Dick Grier]

Hi,

Shouldn't you use a BinaryReader instead of a StreamReader?

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[cgladd87]

I've tried that. The file is encoded in Ascii and using a Binary
Reader, I just get the ascii values for the incorrect letters and
numbers in the hex file. The problem is still there using the
BinaryReader. However as I mentioned before, this only happens in C#.

 

[Dick Grier]

Hi,

Strange.

Well, if it happens only when using C#, then code the fragement that "works
correctly" in VB as a separate dll and call that from your code. There
isn't any real additional overhead if you do so. Then, report the problem
to Microsoft -- the appropriate folks probably won't see it here.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[cgladd87]

Made a DLL and the .hex file reads in fine. I was trying to avoid this
as a solution because it seems more of a band-aid than an actual
solution but if it works, it works.

Thanks for you help,
Chris