Bizarre VB/MSCOMM data corruption

[vinemicros]

Hi all,

We've written a very simple Firmware update routine for a product of ours, that sends data down the RS232 line at 57600 baud (8 bits, no parity, 1 stop bit). It uses MSCOMM, which seems to work fine with us, after we'd figured out it's peculiarities.

HOWEVER, 2 customers have reported precisely the same problem when doing a firmware update on our unit using this program. The upload stops at a certain point which tells us there's been data corruption. Note that it's not data loss (missing bytes), as we'd know this from the program error message we get.

Even wierder is that both of these customers are based in Japan. One unit with the firmware update problem was sent to our distributor in the US (we're in the UK), who updated it with no problems (same software, same RS232 lead).

The error message confirms that data is definitely being sent and received, but for some reason at some point during one or more of the 32-byte blocks being sent there's corruption occuring. If a byte was missing, or ignored due to major corruption, a different error message would be given to us.

Does anyone know of such a problem with either VB or MSCOMM?

We've tried re-writing the VB program do use different methods of using MSCOMM, with no luck. The customers have tried differnt types of PCs and OS's (Eg. 95/98/XP), with no difference - same error.

Anyone have a clue what's going on?

Richard

 

[AndyWatt]

It wouldn't be something as obvious as the different character sets would it?

Can you add a logging facility to your app so you can see what is being received?

Andy
"Logic is invincible because in order to combat logic it is necessary to use logic." -- Pierre Boutroux
"A computer program does what you tell it to do, not what you want it to do." -- Greer's Third Law

 

[vinemicros]

Hi Andy

Why would a different character set cause this problem? We're sending binary data in 32 byte packets, and then getting a single byte back as an 'acknowledge'.

We've added as much logging as we can, and all we can tell (without having the person's whole setup here) is that at some point during the first 495 32-byte packets there's at least 1 byte we send with an error in it.

(After these 495 packets, there's a checksum, at which point it fails.)

Richard