gnupic: Re: [gnupic] pic18f24j10


Previous by date: 1 Jul 2007 17:37:30 +0100 Re: [gnupic] Scope, Robert Pearce
Next by date: 1 Jul 2007 17:37:30 +0100 Re: [gnupic] pic18f24j10, George M. Gallant Jr.
Previous in thread: 1 Jul 2007 17:37:30 +0100 Re: [gnupic] pic18f24j10, Xiaofan Chen
Next in thread: 1 Jul 2007 17:37:30 +0100 Re: [gnupic] pic18f24j10, George M. Gallant Jr.

Subject: Re: [gnupic] pic18f24j10
From: David ####@####.####
Date: 1 Jul 2007 17:37:30 +0100
Message-Id: <20070701113210.1e74c61f@DEEPTHOUGHT.BARNET.net>

On Sun, 1 Jul 2007 10:45:18 -0400
"Xiaofan Chen" ####@####.#### wrote:

> On 7/1/07, George M. Gallant Jr. ####@####.#### wrote:
> > Dave
> >
> > The actual hex image is much larger than 64k. It has multiple
> > records of setting the base address and then 64k of 0xFF.
> > ...
> > George
> >
> 
> Maybe it will be easy for David or others to help you if you can
> post your code.
If I'm understanding your problem correctly, I have no idea why it
would do that. Obviously the 0xFF's are nops, but if they're up at
invalid addresses, I can't see why. gputils has the 18f24j10 marked
with 16k program memory (up to address 0x3ff7, plus CONFIG and devid
sections) both for gpasm and the LKR files.

Do you see the same behavior if you cut it down to a smaller project?
Are you using gplink or absolute mode on gpasm? Some code and your
command line would definitely help.

David Barnett

Previous by date: 1 Jul 2007 17:37:30 +0100 Re: [gnupic] Scope, Robert Pearce
Next by date: 1 Jul 2007 17:37:30 +0100 Re: [gnupic] pic18f24j10, George M. Gallant Jr.
Previous in thread: 1 Jul 2007 17:37:30 +0100 Re: [gnupic] pic18f24j10, Xiaofan Chen
Next in thread: 1 Jul 2007 17:37:30 +0100 Re: [gnupic] pic18f24j10, George M. Gallant Jr.


Powered by ezmlm-browse 0.20.