gnupic: Thread: Re: [gnupic] pic18f24j10

On 6/30/07, George M. Gallant Jr. ####@####.#### wrote:
> I would like to use gputils with the pic18f24j10 chip. gpasm balks
> at the unsupported processor. Tried p18f2410 and gpasm dosn't like
> all of my MPLAB style CONFIG directives. It finds the p18f24j10.inc
> file.
>
> Program assembles, links, and runs when built with mplab.
>

Get the latest CVS version and build it. The latest CVS version does
support the MPLAB style CONFIG directive and support 18F24J10.

I just tested using a template file from MPLAB and it works fine.

Regards,
Xiaofan

Xiaofan,

Thanks. As a side note, I think the cvs instructions on sourceforge are
incorrect.


George

On Sat, 2007-06-30 at 19:51 -0400, Xiaofan Chen wrote:
> On 6/30/07, George M. Gallant Jr. ####@####.#### wrote:
> > I would like to use gputils with the pic18f24j10 chip. gpasm balks
> > at the unsupported processor. Tried p18f2410 and gpasm dosn't like
> > all of my MPLAB style CONFIG directives. It finds the p18f24j10.inc
> > file.
> >
> > Program assembles, links, and runs when built with mplab.
> >
> 
> Get the latest CVS version and build it. The latest CVS version does
> support the MPLAB style CONFIG directive and support 18F24J10.
> 
> I just tested using a template file from MPLAB and it works fine.
> 
> Regards,
> Xiaofan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
-- 
George M. Gallant, Jr.
(508) 202-2933

The resultant hex and cod files are huge. The linker appears to
be generating a 64Kbyte image when actual image size should be
less than 3Kbytes.


On Sat, 2007-06-30 at 19:51 -0400, Xiaofan Chen wrote:
> On 6/30/07, George M. Gallant Jr. ####@####.#### wrote:
> > I would like to use gputils with the pic18f24j10 chip. gpasm balks
> > at the unsupported processor. Tried p18f2410 and gpasm dosn't like
> > all of my MPLAB style CONFIG directives. It finds the p18f24j10.inc
> > file.
> >
> > Program assembles, links, and runs when built with mplab.
> >
> 
> Get the latest CVS version and build it. The latest CVS version does
> support the MPLAB style CONFIG directive and support 18F24J10.
> 
> I just tested using a template file from MPLAB and it works fine.
> 
> Regards,
> Xiaofan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
-- 
George M. Gallant, Jr.
(508) 202-2933

On Sat, 30 Jun 2007 22:03:27 -0400
"George M. Gallant Jr." ####@####.#### wrote:

> The resultant hex and cod files are huge. The linker appears to
> be generating a 64Kbyte image when actual image size should be
> less than 3Kbytes.
How are you seeing the size and how do you know what size the image
should be? The actual file size of the HEX file will be much bigger
than the actual data to program because it's ASCII encoded, not raw
bytes, and the HEX format includes addresses, headers, and footers as
well as some other configuration data. The COD file has lots of other
data, too.

There will be a few bytes way up in high addresses for the CONFIG word.
If that's not the issue, you can look in the LST file or use gpdasm or
gpvo to determine what's actually going into memory.

Without any of that information, we have no idea why the files are
bigger than you're expecting.

David Barnett
> 
> On Sat, 2007-06-30 at 19:51 -0400, Xiaofan Chen wrote:
> > On 6/30/07, George M. Gallant Jr. ####@####.#### wrote:
> > > I would like to use gputils with the pic18f24j10 chip. gpasm balks
> > > at the unsupported processor. Tried p18f2410 and gpasm dosn't like
> > > all of my MPLAB style CONFIG directives. It finds the
> > > p18f24j10.inc file.
> > >
> > > Program assembles, links, and runs when built with mplab.
> > >
> > 
> > Get the latest CVS version and build it. The latest CVS version does
> > support the MPLAB style CONFIG directive and support 18F24J10.
> > 
> > I just tested using a template file from MPLAB and it works fine.
> > 
> > Regards,
> > Xiaofan

Dave

The actual hex image is much larger than 64k. It has multiple 
records of setting the base address and then 64k of 0xFF.

The size of the hex file with gputils:  8614212 bytes
                              mpasm:       7948

The address portion of the hex record indicates 49 banks of 64k.

The 18f24j10 has 16K.

George

On Sat, 2007-06-30 at 21:25 -0500, David wrote:
> On Sat, 30 Jun 2007 22:03:27 -0400
> "George M. Gallant Jr." ####@####.#### wrote:
> 
> > The resultant hex and cod files are huge. The linker appears to
> > be generating a 64Kbyte image when actual image size should be
> > less than 3Kbytes.
> How are you seeing the size and how do you know what size the image
> should be? The actual file size of the HEX file will be much bigger
> than the actual data to program because it's ASCII encoded, not raw
> bytes, and the HEX format includes addresses, headers, and footers as
> well as some other configuration data. The COD file has lots of other
> data, too.
> 
> There will be a few bytes way up in high addresses for the CONFIG word.
> If that's not the issue, you can look in the LST file or use gpdasm or
> gpvo to determine what's actually going into memory.
> 
> Without any of that information, we have no idea why the files are
> bigger than you're expecting.
> 
> David Barnett
> > 
> > On Sat, 2007-06-30 at 19:51 -0400, Xiaofan Chen wrote:
> > > On 6/30/07, George M. Gallant Jr. ####@####.#### wrote:
> > > > I would like to use gputils with the pic18f24j10 chip. gpasm balks
> > > > at the unsupported processor. Tried p18f2410 and gpasm dosn't like
> > > > all of my MPLAB style CONFIG directives. It finds the
> > > > p18f24j10.inc file.
> > > >
> > > > Program assembles, links, and runs when built with mplab.
> > > >
> > > 
> > > Get the latest CVS version and build it. The latest CVS version does
> > > support the MPLAB style CONFIG directive and support 18F24J10.
> > > 
> > > I just tested using a template file from MPLAB and it works fine.
> > > 
> > > Regards,
> > > Xiaofan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
-- 
George M. Gallant, Jr.
(508) 202-2933

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.
>
> The size of the hex file with gputils:  8614212 bytes
>                              mpasm:       7948
>
> The address portion of the hex record indicates 49 banks of 64k.
>
> The 18f24j10 has 16K.
>
> George
>

Maybe it will be easy for David or others to help you if you can
post your code. I only tested the simple template code and it
is working fine.

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

Dave,

Further test reveals a huge .o file. Attached are a test case
file exhibiting the problem.

George

On Sun, 2007-07-01 at 11:32 -0500, David wrote:
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
-- 
George M. Gallant, Jr.
(508) 202-2933

		include	<p18f24j10.inc>
	
		CONFIG	WDTEN = OFF		;To use ICD2 as a debugger disable Watch Dog Timer
		CONFIG	STVREN = ON		;Reset on stack overflow/underflow enabled
		CONFIG	XINST = OFF		;Instruction set extension and Indexed Addressing mode disabled (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 is enabled when OSCCON<1:0> = 00
		CONFIG	FCMEN = OFF		;Fail-Safe Clock Monitor disabled
		CONFIG	IESO = OFF		;Two-Speed Start-up disabled
		CONFIG	WDTPS = 32768		;1:32768

		code
main:		nop
		bra	main
	
		end

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/

On 7/1/07, 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:
>

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.

XFCHEN@APSGSGPXFCHEN ~/mcu
$ cat main.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              ;
        CONFIG  FCMEN = OFF             ;Fail-Safe Clock Monitor disabled
        CONFIG  IESO = OFF              ;Two-Speed Start-up disabled
        CONFIG  WDTPS = 32768           ;1:32768

        ORG     0x0000

Main:   nop
        bra     Main
        end

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

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

Regards,
Xiaofan