gnupic: Thread: Re: [gnupic] pic18f24j10

On 7/1/07, Michael Ballbach ####@####.#### wrote:
>
> 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:
>

The patch seems to work. Without the patch, the test code in relocation
mode produced big hex files. With the patch, the following test code
produce the same hex file as the corresponding code in absolute mode.

XFCHEN@APSGSGPXFCHEN ~/mcu
$ cat main1.asm
        LIST P=18F24J10                 ;directive to define processor
#include        <p18f24j10.inc>
        CONFIG  WDTEN = OFF             ;To use ICD2 as a debugger disable WDT
        CONFIG  STVREN = ON             ;Reset on stack
overflow/underflow enabled
        CONFIG  XINST = OFF             ;Legacy mode
        CONFIG  CP0 = OFF               ;Program memory is not code-protected
        CONFIG  FOSC = HSPLL            ;HS oscillator. PLL enabled
        CONFIG  FOSC2 = ON              ;Clock selected by FOSC as system clock
        CONFIG  FCMEN = OFF             ;Fail-Safe Clock Monitor disabled
        CONFIG  IESO = OFF              ;Two-Speed Start-up disabled
        CONFIG  WDTPS = 32768           ;1:32768

;Reset vector

RESET_VECTOR    CODE    0x0000

Main:   nop
        bra     Main
        end

XFCHEN@APSGSGPXFCHEN ~/mcu
$ gpasm -i -c main1.asm

XFCHEN@APSGSGPXFCHEN ~/mcu
$ gplink -o main1 main1.o
message: using default linker script
"C:/msys/1.0/local/share/gputils/lkr/\18f24j10.lkr"

XFCHEN@APSGSGPXFCHEN ~/mcu
$ cat main1.hex
:020000040000FA
:040000000000FED727
:063FF800A0F405FFFFF13B
:00000001FF

XFCHEN@APSGSGPXFCHEN ~/mcu
$ diff main.hex main1.hex


Regards,
Xiaofan

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

On Sun, Jul 01, 2007 at 07:30:14PM -0400, Xiaofan Chen wrote:
> I have not tried your patch yet but I noticed an interesting thing. If
> the code is using absolute mode, gputils does not produce big hex
> file.

I imagine this is because the defaults were being added as part of
writing out the object file, and not as part of the assembly process.

-- 
Michael Ballbach, N0ZTQ
####@####.#### -- PGP KeyID: 0xA05D5555
http://www.rten.net/

On Sun, Jul 01, 2007 at 08:08:43PM -0400, Xiaofan Chen wrote:
> The patch seems to work. Without the patch, the test code in
> relocation mode produced big hex files. With the patch, the following
> test code produce the same hex file as the corresponding code in
> absolute mode.

Thanks for checking!

-- 
Michael Ballbach, N0ZTQ
####@####.#### -- PGP KeyID: 0xA05D5555
http://www.rten.net/

On Sun, Jul 01, 2007 at 08:49:20PM -0400, George M. Gallant Jr. wrote:
> Thanks! Much nicer.

No problem, thanks for verifying.

-- 
Michael Ballbach, N0ZTQ
####@####.#### -- PGP KeyID: 0xA05D5555
http://www.rten.net/

Hallo Michael,

Michael Ballbach wrote: (among others)

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

And this is not even the complete list! I scanned the device (.dev) 
files of MPLAB 7.61 and found the following list of 18FxxJxx PICS with 
'non-expected' config address values.

   18F24J10     3FF8-3FFF
   18F25J10     7FF8-7FFF
   18F44J10     3FF8-3FFF
   18F45J10     7FF8-7FFF
   18F63J11     1FF8-1FFF
   18F63J90     1FF8-1FFF
   18F64J11     3FF8-3FFF
   18F64J90     3FF8-3FFF
   18F65J10     7FF8-7FFF
   18F65J11     7FF8-7FFF
   18F65J15     BFF8-BFFF
   18F65J50     7FF8-7FFF
   18F65J90     7FF8-7FFF
   18F66J10     FFF8-FFFF
   18F66J11     FFF8-FFFF
   18F66J15    17FF8-17FFF
   18F66J16    17FF8-17FFF
   18F66J50     FFF8-FFFF
   18F66J55    17FF8-17FFF
   18F66J60    0FFF8-0FFFF
   18F66J65    17FF8-17FFF
   18F67J10    1FFF8-1FFFF
   18F67J11    1FFF8-1FFFF
   18F67J50    1FFF8-1FFFF
   18F67J60    1FFF8-1FFFF
   18F83J11     1FF8-1FFF
   18F83J90     1FF8-1FFF
   18F84J11     3FF8-3FFF
   18F84J90     3FF8-3FFF
   18F85J10     7FF8-7FFF
   18F85J11     7FF8-7FFF
   18F85J15     BFF8-BFFF
   18F85J50     7FF8-7FFF
   18F85J90     7FF8-7FFF
   18F86J10     FFF8-FFFF
   18F86J11     FFF8-FFFF
   18F86J15    17FF8-17FFF
   18F86J16    17FF8-17FFF
   18F86J50     FFF8-FFFF
   18F86J55    17FF8-17FFF
   18F86J60    0FFF8-0FFFF
   18F86J65    17FF8-17FFF
   18F87J10    1FFF8-1FFFF
   18F87J11    1FFF8-1FFFF
   18F87J50    1FFF8-1FFFF
   18F87J60    1FFF8-1FFFF
   18F96J60    0FFF8-0FFFF
   18F96J65    17FF8-17FFF
   18F97J60    1FFF8-1FFFF

Notice that all these have also 8 bytes of config mem, in stead of the 
14 bytes with the 'regular' 18F PICs.

Regards, Rob.

-- 
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

On Mon, Jul 02, 2007 at 09:08:45AM +0200, Rob Hamerling wrote:
> And this is not even the complete list! I scanned the device (.dev)
> files of MPLAB 7.61 and found the following list of 18FxxJxx PICS with
> 'non-expected' config address values.

Interesting! Our configuration table was extracted from an older version
of MPASM. I have extracted data from this 7.61, but some of the address
fields ended up empty from the script that extracts the data from the
executable, which led me to believe that some format might have changed
and the data was invalid. I still haven't verified it. Hopefully I can
do so soon and we will have an updated database.

>   18F24J10     3FF8-3FFF
>   18F25J10     7FF8-7FFF
>   18F44J10     3FF8-3FFF
>   18F45J10     7FF8-7FFF
>   18F63J11     1FF8-1FFF
>   18F63J90     1FF8-1FFF
>   18F64J11     3FF8-3FFF
>   18F64J90     3FF8-3FFF
>   18F65J10     7FF8-7FFF
>   18F65J11     7FF8-7FFF
>   18F65J15     BFF8-BFFF
>   18F65J50     7FF8-7FFF
>   18F65J90     7FF8-7FFF
>   18F66J10     FFF8-FFFF
>   18F66J11     FFF8-FFFF
>   18F66J15    17FF8-17FFF
>   18F66J16    17FF8-17FFF
>   18F66J50     FFF8-FFFF
>   18F66J55    17FF8-17FFF
>   18F66J60    0FFF8-0FFFF
>   18F66J65    17FF8-17FFF
>   18F67J10    1FFF8-1FFFF
>   18F67J11    1FFF8-1FFFF
>   18F67J50    1FFF8-1FFFF
>   18F67J60    1FFF8-1FFFF
>   18F83J11     1FF8-1FFF
>   18F83J90     1FF8-1FFF
>   18F84J11     3FF8-3FFF
>   18F84J90     3FF8-3FFF
>   18F85J10     7FF8-7FFF
>   18F85J11     7FF8-7FFF
>   18F85J15     BFF8-BFFF
>   18F85J50     7FF8-7FFF
>   18F85J90     7FF8-7FFF
>   18F86J10     FFF8-FFFF
>   18F86J11     FFF8-FFFF
>   18F86J15    17FF8-17FFF
>   18F86J16    17FF8-17FFF
>   18F86J50     FFF8-FFFF
>   18F86J55    17FF8-17FFF
>   18F86J60    0FFF8-0FFFF
>   18F86J65    17FF8-17FFF
>   18F87J10    1FFF8-1FFFF
>   18F87J11    1FFF8-1FFFF
>   18F87J50    1FFF8-1FFFF
>   18F87J60    1FFF8-1FFFF
>   18F96J60    0FFF8-0FFFF
>   18F96J65    17FF8-17FFF
>   18F97J60    1FFF8-1FFFF
> 
> Notice that all these have also 8 bytes of config mem, in stead of the
> 14 bytes with the 'regular' 18F PICs.

It's interesting. I don't know anything about the J parts, guess I
should read up a little.

-- 
Michael Ballbach, N0ZTQ
####@####.#### -- PGP KeyID: 0xA05D5555
http://www.rten.net/

Hallo Michael,

Michael Ballbach wrote:
> On Mon, Jul 02, 2007 at 09:08:45AM +0200, Rob Hamerling wrote:
>> And this is not even the complete list! I scanned the device (.dev)
>> files of MPLAB 7.61 and found the following list of 18FxxJxx PICS with
>> 'non-expected' config address values.
> 
> Interesting! Our configuration table was extracted from an older version
> of MPASM. I have extracted data from this 7.61, but some of the address
> fields ended up empty from the script that extracts the data from the
> executable, which led me to believe that some format might have changed
> and the data was invalid. I still haven't verified it. Hopefully I can
> do so soon and we will have an updated database.

I have of a script (in Rexx language) to check the configuration files 
of my Wisp628 support program Xwisp2. And I use some variants of this 
script for different purposes for example to build lists of specific 
(sub)families.  I have to update my scripts from time to time because of 
changes (and errors) in the MPLAB files. So your experience doesn't 
really surprise me. ;-)

I just started to read about this 18FxxJxx chips and I found an 
interesting paragraph in datasheet DS39682C:

  Unlike most PIC18 microcontrollers, devices of the
  PIC18F45J10 family do not use persistent memory
  registers to store configuration information. The config-
  uration bytes are implemented as volatile memory
  which means that configuration data must be
  programmed each time the device is powered up.

I suppose the meaning of 'configuration bits' has changed a little....

Regards, Rob

-- 
Rob Hamerling, Vianen, NL (http://www.robh.nl/)