gpdasm 0.13.6 alpha question

[Peter Keller]

Hello,

I have a small assembly program for the pic18f4550 that I'm assembling
with gputils. The assembly seems to work fine and I can burn it to the
pic with pk2cmd And things appear to work.

However, when disassembling the program using gpdasm I get funky addresses
for the configuration bits and the EEPROM.

Here is an example:

000000:  ef15  goto 0x2a
000002:  f000
00002a:  ec21  call 0x42, 0
00002c:  f000
00002e:  ec2f  call 0x5e, 0
000030:  f000
000032:  ec3b  call 0x76, 0
000034 - 00008c: all the correct instructions

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
60000004:  00ff  reset
60000006:  ff80  dw 0xff80  ;unknown opcode
60000008:  c00f  movff  0xf, 0xf
6000000a:  e00f
6000000c:  400f  rrncf  0xf, 0, 0

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
# all correct data in here
e000004e:  0000  nop

If I use gpvo to look at the object file which contains the EEPROM data,
I get this:

Section Header
Name                    .org_780000
Address                 0xf00000
Size of Section         80
Number of Relocations   0
Number of Line Numbers  40
Flags                   0x1020
  Executable code.
  Absolute.

Data
f00000:  6c42  negf     0x42, 0
f00002:  6e69  movwf    0x69, 0
f00004:  696b  setf     0x6b, 0x1
f00006:  676e  tstfsz   0x6e, 0x1
f00008:  4c20  dcfsnz   0x20, 0, 0
# the rest of the data is correct

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).

Here is the entire test.hex file that gpasm produced, maybe it is somehow
wrong?

:020000040000FA
:0400000015EF00F008
:06002A0021EC00F02FECB8
:1000300000F03BEC00F035EC00F03BEC00F017EF8B
:1000400000F0626F0F01806A0F0E0F01C16E070E84
:100050000F01B46E000E0F01926E62511200626FBA
:10006000010E0F01806E62511200626F000E0F01CF
:10007000806E625112000001A00E616FFF0E606F72
:0E008000602F40EF00F0612F3EEF00F0120005
:020000040030CA
:0E0000000408381EFF0080FF0FC00FE00F4005
: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. I'm just
not sure what is *supposed* to happen since I've only started recently
understanding the hex format.

Thank you.

-pete



---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...