gnupic: Thread: Gpasm / Mpasm hex file compatibility


[<<] [<] Page 1 of 1 [>] [>>]
Subject: Gpasm / Mpasm hex file compatibility
From: Pete Harlow ####@####.####
Date: 1 Mar 2004 20:02:21 -0000
Message-Id: <40438EAE.6070103@nerim.net>

I've just assembled up a new version of some code for a client and sent 
the hex file to him. The gpasm hex file worked fine with picp and my 
Picstart Plus here to produce a working chip.
However my client has used his Picstart with Mplab and this complains 
that the hex file has a bad checksum.

Are the checksum formats different?

Regards,
-- 
Pete  Harlow  I.Eng  MIIE          Open Systems  Design  Consultant
Internet   Systems   -   Payment   Systems   -   Security   Systems
Web: http://www.catnip.co.uk/consultants/

Subject: Re: Gpasm / Mpasm hex file compatibility
From: Scott Dattalo ####@####.####
Date: 1 Mar 2004 20:34:22 -0000
Message-Id: <Pine.LNX.4.44.0403011159220.19163-100000@ruckus.brouhaha.com>

On Mon, 1 Mar 2004, Pete Harlow wrote:

> I've just assembled up a new version of some code for a client and sent 
> the hex file to him. The gpasm hex file worked fine with picp and my 
> Picstart Plus here to produce a working chip.
> However my client has used his Picstart with Mplab and this complains 
> that the hex file has a bad checksum.
> 
> Are the checksum formats different?

The problem is most probably an end-of-line issue. Try converting your 
.hex files to "dos" before sending them to your client. e.g.:

$ unix2dos hexfile.hex

Another thing I found is that some mail readers like to reformat files 
when they're saved. So the other thing I do is package the .hex file into 
a .zip file too.

Scott

Subject: Re: Gpasm / Mpasm hex file compatibility
From: Pete Harlow ####@####.####
Date: 2 Mar 2004 10:41:03 -0000
Message-Id: <40446809.1080800@thales-transportservices.com>

Scott,

Thanks for your post. I've managed to load MPlab under Crossover Office, 
and I get the same error on the hex file. Running unix2dos on the hex 
file fixes it, but I've not a Picstart here to test with...

I'll let you know what happens at the other end!

You are absolutely right about zipping files - my client uses Compuserve 
and has been having difficulty even saving the hex file attachment as a 
separate file. Zipping seems to get round this. Add to this the problem 
of no serial port and having to use an adaptor... I thought these modern 
boxes were meant to be easy to use :-j

Regards,

Pete.

Scott Dattalo wrote:
> On Mon, 1 Mar 2004, Pete Harlow wrote:
> 
> 
>>I've just assembled up a new version of some code for a client and sent 
>>the hex file to him. The gpasm hex file worked fine with picp and my 
>>Picstart Plus here to produce a working chip.
>>However my client has used his Picstart with Mplab and this complains 
>>that the hex file has a bad checksum.
>>
>>Are the checksum formats different?
> 
> 
> The problem is most probably an end-of-line issue. Try converting your 
> .hex files to "dos" before sending them to your client. e.g.:
> 
> $ unix2dos hexfile.hex
> 
> Another thing I found is that some mail readers like to reformat files 
> when they're saved. So the other thing I do is package the .hex file into 
> a .zip file too.
> 
> Scott
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

-- 
Pete Harlow                                     Thales e-Transactions
Tel  +33 1 69 88 59 41
Fax  +33 1 69 88 54 05
####@####.####


This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. 
If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, 
copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, 
and may be unlawful. 
If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete 
this message. Thales, its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete 
transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.