gnupic: gpdasm 0.13.6 alpha question
Subject:
gpdasm 0.13.6 alpha question
From:
Peter Keller ####@####.####
Date:
11 Mar 2009 18:04:04 -0000
Message-Id: <20090302063558.GA21049@cs.wisc.edu>
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
