gnupic: Re: [gnupic] pic18f24j10
Subject:
Re: [gnupic] pic18f24j10
From:
"George M. Gallant Jr." ####@####.####
Date:
2 Jul 2007 01:44:28 +0100
Message-Id: <1183337360.11653.28.camel@scuba.home.net>
Dave,
Thanks! Much nicer. I think this fault correction means a new release
of gputils.
George
On Sun, 2007-07-01 at 19:02 -0400, Michael Ballbach wrote:
> 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.
>
--
George M. Gallant, Jr.
(508) 202-2933
