gnupic: Thread: Re: [gnupic] Re: [orders] Re: [gnupic] gpasm hex files, compatibility with odyssey

Now that you mention it reading a blank chip and writing it back is  
not a good test. I will have to dig in to the Odyssey source to see  
what's really going on.

It appears that no one else uses this programmer software- can anyone  
suggest a better one. We only use Linux / Unix in the labs and I  
would prefer one that is configurable and uses the parallel port.


On May 29, 2007, at 2:22 PM, Robert Pearce wrote:

> On Tue, 29 May 2007, Tim Allen ####@####.#### wrote :
>
> First I will echo what David said - trying to re-program the chip  
> with what you've just read out of it does not actually test the  
> ability to write, especially when the data is all blank!
>
> Other than that:
>> HelloWorld.hex (the output from gpasm)...
>>
>> :020000040000FA
> Note    ^^^^^^
>> :100000000F28FF308C0000008C0B032808008E00A6
>> :10001000FF308D0001208D0B0A280E0808000030EB
>> :0E00200065006600FF30860007208609142860
>> :00000001FF
>>
>
> I checked your gpasm output against the file you saved from  
> odyssey. They use the same endianism (there are three possible  
> representations of the PIC's 14-bit word out there), but I note  
> odyssey did not include that first line I've marked above. That's  
> an Intel HEX extension for >16bit addressing, so it's rarely needed  
> on PICs (never on 14-bit ones). It's possible odyssey doesn't like  
> it, so it would be worth deleting it as a quick test.
>
> That said, if an incompatibility of HEX file format produces the  
> error message "Couldn't write to program memory" then the author of  
> that application should be severely reprimanded!
> -- 
> Rob Pearce                       http://www.bdt-home.demon.co.uk
>
> The contents of this | Windows NT crashed.
> message are purely   | I am the Blue Screen of Death.
> my opinion. Don't    | No one hears your screams.
> believe a word.      |
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

I've used Odyssey for 16F628 projects with microEngineering Labs' EPIC 
programmer, but I haven't done any PIC work in quite a while.  I had a few 
pains getting it running, but that was mainly because the author didn't 
have any 16F628 hardware and so hadn't tested its support in Odyssey; I 
had to help debug it.  After we got those issues ironed out I liked using 
Odyssey.

Several of the others had good ideas:  run dos2unix to ensure Unix-style 
newlines, convert the file to 8-bit intel hex format (srec_cat is a 
convenient utility for converting among numerous types), and check the 
config word of your 'F84 part to see whether code protect is turned on. 
The 16F628 part is supposed to read out 0's when protected; I don't know 
whether the 16F84 is similar.

good luck!

Greg



On Tue, 29 May 2007, Tim Allen wrote:

> Now that you mention it reading a blank chip and writing it back is not a 
> good test. I will have to dig in to the Odyssey source to see what's really 
> going on.
>
> It appears that no one else uses this programmer software- can anyone suggest 
> a better one. We only use Linux / Unix in the labs and I would prefer one 
> that is configurable and uses the parallel port.
>
>
> On May 29, 2007, at 2:22 PM, Robert Pearce wrote:
>
>> On Tue, 29 May 2007, Tim Allen ####@####.#### wrote :
>> 
>> First I will echo what David said - trying to re-program the chip with what 
>> you've just read out of it does not actually test the ability to write, 
>> especially when the data is all blank!
>> 
>> Other than that:
>>> HelloWorld.hex (the output from gpasm)...
>>> 
>>> :020000040000FA
>> Note    ^^^^^^
>>> :100000000F28FF308C0000008C0B032808008E00A6
>>> :10001000FF308D0001208D0B0A280E0808000030EB
>>> :0E00200065006600FF30860007208609142860
>>> :00000001FF
>>> 
>> 
>> I checked your gpasm output against the file you saved from odyssey. They 
>> use the same endianism (there are three possible representations of the 
>> PIC's 14-bit word out there), but I note odyssey did not include that first 
>> line I've marked above. That's an Intel HEX extension for >16bit 
>> addressing, so it's rarely needed on PICs (never on 14-bit ones). It's 
>> possible odyssey doesn't like it, so it would be worth deleting it as a 
>> quick test.
>> 
>> That said, if an incompatibility of HEX file format produces the error 
>> message "Couldn't write to program memory" then the author of that 
>> application should be severely reprimanded!
>> -- 
>> Rob Pearce                       http://www.bdt-home.demon.co.uk
>> 
>> The contents of this | Windows NT crashed.
>> message are purely   | I am the Blue Screen of Death.
>> my opinion. Don't    | No one hears your screams.
>> believe a word.      |
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ####@####.####
>> For additional commands, e-mail: ####@####.####
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>

On Tue, 29 May 2007, Tim Allen ####@####.#### wrote :
>Now that you mention it reading a blank chip and writing it back is not 
>a good test. I will have to dig in to the Odyssey source to see what's 
>really going on.

Another thought occurred to me just after posting...

The PIC ICSP protocol is master-slave, and has the rather unfortunate 
characteristic that if you implement only the minimum it is possible to 
have no device present and still pass that test!

If you have access to a 'scope it would be well worth looking at the 
voltages on your PIC pins during a programming attempt. You need Vss at 
+5V and Vpp at +12V (ideally more like +14V if you ever want to use a 
ROM device). You also need to see clock and data signals (toggling from 
0V to 5V) on RB6 and RB7.
-- 
Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of this | Windows NT crashed.
message are purely   | I am the Blue Screen of Death.
my opinion. Don't    | No one hears your screams.
believe a word.      |

Tim Allen writes ("Re: [gnupic] Re: [orders] Re: [gnupic] gpasm hex files, compatibility with odyssey"):
> It appears that no one else uses this programmer software- can anyone  
> suggest a better one. We only use Linux / Unix in the labs and I  
> would prefer one that is configurable and uses the parallel port.

I use odyssey to program 16F458s (with hex files produced by gpasm and
gplink).  I did find that .hex files aren't as straightforward and
unambiguous as might be hoped.

I don't know what's wrong with your setup but if you want to test
whether the problem is (a) odyssey can't write to your chip somehow or
(b) the hex file format is not right, here's a suggestion: edit your
tim.hex file to have some different data in it (and you might want to
shorten it too).  You'll have to adjust the checksum(s) according to
the intel hex file spec (which I don't seem to have a reference to
right now).

Ian.