gnupic: Re: [gnupic] gpdasm 0.13.6 alpha question
Subject:
Re: [gnupic] gpdasm 0.13.6 alpha question
From:
Robert Pearce ####@####.####
Date:
11 Mar 2009 21:44:01 -0000
Message-Id: <DrRe05R2$CuJFwsK@daniel.huneausware.local>
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!
>
>Then the EEPROM gets printed out. This contains the valid data, but I have
>an org 0xF00000 at the start of the 'de' directives. Why does it end up at
>e0000000?
>
>e0000000: 6c42 negf 0x42, 0
Again, the upper 8 bits are shifted left by nine....
>If I use gpvo to look at the object file which contains the EEPROM data,
>I get this:
>
<snip correct looking stuff>
>
>So the assembly process seems to have done the right thing wrt the object
>file. (As far as I know the EEPROM starts at 0xf00000, but the data sheet
>doesn't mention an address, and I got that info from the internet).
(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.)
>
>Here is the entire test.hex file that gpasm produced, maybe it is somehow
>wrong?
>
No, it looks correct to me.
Here's a block starting at 0x00000000 :
>:020000040000FA
>:0400000015EF00F008
>:06002A0021EC00F02FECB8
>:1000300000F03BEC00F035EC00F03BEC00F017EF8B
>:1000400000F0626F0F01806A0F0E0F01C16E070E84
>:100050000F01B46E000E0F01926E62511200626FBA
>:10006000010E0F01806E62511200626F000E0F01CF
>:10007000806E625112000001A00E616FFF0E606F72
>:0E008000602F40EF00F0612F3EEF00F0120005
Now there's a block at 0x00300000 :
>:020000040030CA
>:0E0000000408381EFF0080FF0FC00FE00F4005
And finally some data at 0x00F00000 :
>:0200000400F00A
>:10000000426C696E6B696E67204C45442056657280
>:1000100073696F6E20302E30200042792070736932
>:100020006C6F72644063732E776973632E656475B9
>:100030002E20436F707972696768742032303039CE
>:100040002E20425344204C6963656E73652E000078
>:00000001FF
>
>Any help would be appreciated. Even if it is a bug in one of the tools, I'll
>take a crack at fixing it if someone points me in a direction.
Given what you've posted, it appears gpdasm may be misinterpreting the
"type 04" blocks - the lines of the HEX file that begin ":02000004"
--
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. |
