gnupic: Re: [gnupic] gpdasm 0.13.6 alpha question


Previous by date: 12 Mar 2009 04:10:25 -0000 Re: [gnupic] gpdasm 0.13.6 alpha question, Robert Pearce
Next by date: 12 Mar 2009 04:10:25 -0000 Re: [gnupic] gpdasm 0.13.6 alpha question, Rob Pearce
Previous in thread: 12 Mar 2009 04:10:25 -0000 Re: [gnupic] gpdasm 0.13.6 alpha question, Robert Pearce
Next in thread: 12 Mar 2009 04:10:25 -0000 Re: [gnupic] gpdasm 0.13.6 alpha question, Rob Pearce

Subject: Re: [gnupic] gpdasm 0.13.6 alpha question
From: Peter Keller ####@####.####
Date: 12 Mar 2009 04:10:25 -0000
Message-Id: <20090312040707.GA1540@cs.wisc.edu>

Hello,

On Wed, Mar 11, 2009 at 09:41:10PM +0000, Robert Pearce wrote:
> On Wed, 11 Mar 2009, Peter Keller ####@####.#### wrote :
> >
> >Then the configuration bits get printed out, but the data sheet says it is
> >supposed to be at 300000h-3FFFFFh
> >
> >60000000:  0804  sublw  0x4
> >60000002:  1e38  comf   0x38, 0x1, 0
> 
> That definitely looks wrong - the upper 8 bits of the address seem to 
> have been shifted left by nine!

I just noticed something else too, suppose the addresses were right, and it
looked like this:

300000:  0804  sublw  0x4
300002:  1e38  comf   0x38, 0x1, 0

I would read that (from left to right) as being:

300000: 08
300001: 04
300002: 1e
300003: 38

But, as far as I can determine, there seems to be an endian swap, and it
really should look like this:

300000:  0408
300002:  381e

leading to:

300000: 04
300001: 08
300002: 38
300003: 1e

Both gpdasm and gpvo do this, and sadly, pk2cmd does this also when I
ask it for the configuration bits. I must say, this screwed me up for a
good long time since I thought the processor was in a certain mode when
it wasn't! Are the other sections printed out like this too?

How would one make gdasm and gpvo smarter to actually print out the
configuration bits is a much more human readable manner?

> (The data sheet doesn't quote that address because it's not real, merely 
> conventional. Unlike the configuration data, the EEPROM can't be 
> programmed using the tblwt scheme for main programming. Hence the 
> 0xF00000 address offset used in the HEX file is only a convention for 
> tools, not something imposed by the silicon.)

Could I get a bit more clarification on where the EEPROM addresses are on
PICs in general? It seems a hard thing to pin down.

> Given what you've posted, it appears gpdasm may be misinterpreting the 
> "type 04" blocks - the lines of the HEX file that begin ":02000004"

I see. Think this may get fixed before the new release?

Also, is there a better place to report this stuff, like in the wiki or
something? Do I need an account? I'm interested in hacking on gputils
(as my time permits) since I'm using it for several projects of mine.

Thank you.

-pete

Previous by date: 12 Mar 2009 04:10:25 -0000 Re: [gnupic] gpdasm 0.13.6 alpha question, Robert Pearce
Next by date: 12 Mar 2009 04:10:25 -0000 Re: [gnupic] gpdasm 0.13.6 alpha question, Rob Pearce
Previous in thread: 12 Mar 2009 04:10:25 -0000 Re: [gnupic] gpdasm 0.13.6 alpha question, Robert Pearce
Next in thread: 12 Mar 2009 04:10:25 -0000 Re: [gnupic] gpdasm 0.13.6 alpha question, Rob Pearce


Powered by ezmlm-browse 0.20.