gnupic: Re: [gnupic] pic18f24j10
Subject:
Re: [gnupic] pic18f24j10
From:
Michael Ballbach ####@####.####
Date:
2 Jul 2007 00:04:11 +0100
Message-Id: <20070701230259.GA4326@wayreth.rten.net>
On Sun, Jul 01, 2007 at 01:11:43PM -0400, George M. Gallant Jr. wrote:
> Further test reveals a huge .o file. Attached are a test case file
> exhibiting the problem.
This is due to code in coff.c which tries to pad out the config section
with defaults. Your device's config address space is not between
0x300000 and 0x30000d, which is what this code expects. Your config
bytes appear to be after 0x3ff8. The result is that the code tries to
pack all the bytes between 0x3ff8 to 0x30000d with 0xff's.
I suggest this patch which will use the configuration database when
available to calculate the last valid configuration address. Please let
us know how it works for you:
diff -d -u -r1.28 coff.c
--- coff.c 19 Dec 2005 20:59:47 -0000 1.28
+++ coff.c 1 Jul 2007 22:53:34 -0000
@@ -24,6 +24,7 @@
#include "libgputils.h"
#include "gpasm.h"
#include "gperror.h"
+#include "gpcfg.h"
#include "coff.h"
extern int _16bit_core;
@@ -130,7 +131,7 @@
gp_section_type *config_section = NULL;
int i;
int start;
- int stop;
+ int stop = 0;
int word;
gp_boolean found_break;
@@ -145,9 +146,24 @@
assert(config_section != NULL);
if(_16bit_core) {
- config_section->size = 0;
+ const struct gp_cfg_device *p_dev;
+
+ p_dev = gp_cfg_find_pic_multi(sizeof(state.processor_info->names) /
+ sizeof(*state.processor_info->names),
+ state.processor_info->names);
start = config_section->address >> 1;
stop = CONFIG7H >> 1;
+ config_section->size = 0;
+
+ if(p_dev) {
+ stop = 0;
+ for(i=0; i<p_dev->addr_count; i++) {
+ if(p_dev->config_addrs[i].addr / 2 > stop) {
+ stop = p_dev->config_addrs[i].addr / 2;
+ }
+ }
+ }
+
for (i = start; i <= stop; i++) {
word = i_memory_get(state.c_memory, i);
if (word & MEM_USED_MASK) {
I checked the configuration data, and these PICs:
PIC PIC18F24J10 starts at 0x3ff8
PIC PIC18F25J10 starts at 0x7ff8
PIC PIC18F44J10 starts at 0x3ff8
PIC PIC18F45J10 starts at 0x7ff8
PIC PIC18F64J15 starts at 0x5ff8
PIC PIC18F65J10 starts at 0x7ff8
PIC PIC18F65J15 starts at 0xbff8
PIC PIC18F66J10 starts at 0xfff8
PIC PIC18F66J15 starts at 0x17ff8
PIC PIC18F66J60 starts at 0xfff8
PIC PIC18F66J65 starts at 0x17ff8
PIC PIC18F67J10 starts at 0x1fff8
PIC PIC18F67J60 starts at 0x1fff8
PIC PIC18F84J15 starts at 0x5ff8
PIC PIC18F85J10 starts at 0x7ff8
PIC PIC18F85J15 starts at 0xbff8
PIC PIC18F86J10 starts at 0xfff8
PIC PIC18F86J15 starts at 0x17ff8
PIC PIC18F86J60 starts at 0xfff8
PIC PIC18F86J65 starts at 0x17ff8
PIC PIC18F87J10 starts at 0x1fff8
PIC PIC18F87J60 starts at 0x1fff8
PIC PIC18F96J60 starts at 0xfff8
PIC PIC18F96J65 starts at 0x17ff8
PIC PIC18F97J60 starts at 0x1fff8
Have 'non-expected' configuration address values. Any users of these
should have experienced the same problems, and I'd be curious as to
whether the patch works for users of these chips. Users of these chips
would have had the same problems with old _CONFIG directives as well.
--
Michael Ballbach, N0ZTQ
####@####.#### -- PGP KeyID: 0xA05D5555
http://www.rten.net/
[Content type application/pgp-signature not shown. Download]
