gnupic: Thread: Re: [gnupic] Warning [220] : Address exceeds maximum range for this processor

On Tue, 06 Nov 2007 21:28:54 -0300
"Nestor A. Marchesini" ####@####.#### wrote:

> Again with the 18f4550, this time trying to define data in memory
> eeprom data.
> In my opinion gpasm should not generate this warning:
> 
> gpasm-0.13.4 beta               prog1.asm   11-6-2007
> 21:05:20 PAGE 75
> F00000           04012         ORG  H'F00000'
> Warning [220] : Address exceeds maximum range for this processor.
You're correct. This issue was actually reported by Thomas Welsch right
after the release of 0.13.5. We added bounds checking to gpasm
(formerly it wasn't available in absolute mode) and completely forgot
about EEPROM data regions. If you'd like, you can see the earlier
discussion starting 27 Oct 2007 with the subject line:
"[gnupic] org	H'2100', EEPROM and "Warnung:Address exceeds maximum range for this processor."

It seemed like a really tough problem, but I just realized that gplink
has been handling this situation just fine for relocatable code, and I
might be able to come up with a good solution by looking at what
information it uses.

Even though it doesn't keep gpasm from functioning properly, I know it's
an irritating issue and I'll try to get it patched up quickly. Thanks
everyone for being patient (or at least everyone who still uses
absolute mode).

David Barnett

On Tue, 6 Nov 2007 21:06:48 -0500
David ####@####.#### wrote:

> On Tue, 06 Nov 2007 21:28:54 -0300
> "Nestor A. Marchesini" ####@####.#### wrote:
> 
> > Again with the 18f4550, this time trying to define data in memory
> > eeprom data.
> > In my opinion gpasm should not generate this warning:
> > 
> > gpasm-0.13.4 beta               prog1.asm   11-6-2007
> > 21:05:20 PAGE 75
> > F00000           04012         ORG  H'F00000'
> > Warning [220] : Address exceeds maximum range for this processor.
> ...
> It seemed like a really tough problem, but I just realized that gplink
> has been handling this situation just fine for relocatable code
> ...
Actually I found out that statement was completely false. If I remember
correctly, MPLINK doesn't actually emit that warning for relocatable
code, so neither does gplink. Can anyone confirm that MPASM/MPLINK
don't emit this warning for relocatable code? It would also be good to
know whether they give any kind of warning for exceeding the EEPROM
range in either relocatable or absolute mode.

I guess we'll just have to solve it from scratch...

David Barnett

El 06/11/07 23:06, David escribió:
> On Tue, 06 Nov 2007 21:28:54 -0300
> "Nestor A. Marchesini" ####@####.#### wrote:
>
>> Again with the 18f4550, this time trying to define data in memory
>> eeprom data.
>> In my opinion gpasm should not generate this warning:
>>
>> gpasm-0.13.4 beta               prog1.asm   11-6-2007
>> 21:05:20 PAGE 75
>> F00000           04012         ORG  H'F00000'
>> Warning [220] : Address exceeds maximum range for this processor.
> You're correct. This issue was actually reported by Thomas Welsch right
> after the release of 0.13.5. We added bounds checking to gpasm
> (formerly it wasn't available in absolute mode) and completely forgot
> about EEPROM data regions. If you'd like, you can see the earlier
> discussion starting 27 Oct 2007 with the subject line:
> "[gnupic] org	H'2100', EEPROM and "Warnung:Address exceeds maximum range for this processor."
>
> It seemed like a really tough problem, but I just realized that gplink
> has been handling this situation just fine for relocatable code, and I
> might be able to come up with a good solution by looking at what
> information it uses.
>
> Even though it doesn't keep gpasm from functioning properly, I know it's
> an irritating issue and I'll try to get it patched up quickly. Thanks
> everyone for being patient (or at least everyone who still uses
> absolute mode).
>
> David Barnett

Ok...time to time, only that he was informing those warnings in obsolute 
mode. :-)
I remedied with:

  ERRORLEVEL   0, -220

Only for large projects use gplink...but if it is true, gplink gives better
file listing much more informative.

Regards
Néstor A. Marchesini
Chajari-Entre Rios-Argentina

El 06/11/07 23:48, David escribió:
> On Tue, 6 Nov 2007 21:06:48 -0500
> David ####@####.#### wrote:
>
>> On Tue, 06 Nov 2007 21:28:54 -0300
>> "Nestor A. Marchesini" ####@####.#### wrote:
>>
>>> Again with the 18f4550, this time trying to define data in memory
>>> eeprom data.
>>> In my opinion gpasm should not generate this warning:
>>>
>>> gpasm-0.13.4 beta               prog1.asm   11-6-2007
>>> 21:05:20 PAGE 75
>>> F00000           04012         ORG  H'F00000'
>>> Warning [220] : Address exceeds maximum range for this processor.
>> ...
>> It seemed like a really tough problem, but I just realized that gplink
>> has been handling this situation just fine for relocatable code
>> ...
> Actually I found out that statement was completely false. If I remember
> correctly, MPLINK doesn't actually emit that warning for relocatable
> code, so neither does gplink. Can anyone confirm that MPASM/MPLINK
> don't emit this warning for relocatable code? It would also be good to
> know whether they give any kind of warning for exceeding the EEPROM
> range in either relocatable or absolute mode.
>
> I guess we'll just have to solve it from scratch...
>
> David Barnett
Assembled with MPASM 5.13 of MPLAB 7.62.

MPASM 5.13                         SALIDA.ASM   11-7-2007  
1:20:00         PAGE 77
F00000                03998     ORG H'F00000'
F00000 6854 7369 6920 03999     DE  "This is  a  test"
       2073 6120 2020
       6574 7473
                      04000    END
No warning in the file listing (absolute mode).

Regards
Néstor A. Marchesini
Chajari-Entre Rios-Argentina

I've finally implemented a solution for this problem (SVN r503).

I'm pleased with the solution I found because it will scale well if we
later determine that we need 3 or more separate ranges on some device.

Thomas Welsch and Nestor, could you update to r503 and make sure it
solves your problems? Don't forget to delete any "ERRORLEVEL -220"
directives while testing.

David Barnett

El 08/11/07 22:00, David escribió:
> I've finally implemented a solution for this problem (SVN r503).
>
> I'm pleased with the solution I found because it will scale well if we
> later determine that we need 3 or more separate ranges on some device.
>
> Thomas Welsch and Nestor, could you update to r503 and make sure it
> solves your problems? Don't forget to delete any "ERRORLEVEL -220"
> directives while testing.
>
> David Barnett

[nestor@deselectronica gputils]$ svn up 
https://gputils.svn.sourceforge.net/svnroot/gputils/trunk/gputils 
gputils-0.13.5-svn
Omitiendo 
'https://gputils.svn.sourceforge.net/svnroot/gputils/trunk/gputils'
U    gputils-0.13.5-svn/ChangeLog
U    gputils-0.13.5-svn/gpasm/gpasm.h
U    gputils-0.13.5-svn/gpasm/directive.c
U    gputils-0.13.5-svn/gpasm/processor.c
U    gputils-0.13.5-svn/libgputils/gpprocessor.c
U    gputils-0.13.5-svn/libgputils/gpprocessor.h
Actualizado a la revisión 503.

gpasm-0.13.4 beta               prog1.asm   11-9-2007  03:25:10          
PAGE 75
F00000           04007         ORG  H'F00000'
F00000 6854 7369 04008         DE   "This is  a  test"
F00004 6920 2073
F00008 6120 2020
F0000C 6574 7473

Now it works perfectly! many thanks David for worry in solving problems 
reported. :-)

Regards
Néstor a. Marchsini
Chajari-Entre Rios-Argentina

Hello David,

your efforts  were successful.

Thanks,
  Thomas Welsch

Am Freitag, 9. November 2007 schrieb David:
> I've finally implemented a solution for this problem (SVN r503).
>
> I'm pleased with the solution I found because it will scale well if we
> later determine that we need 3 or more separate ranges on some device.
>
> Thomas Welsch and Nestor, could you update to r503 and make sure it
> solves your problems? Don't forget to delete any "ERRORLEVEL -220"
> directives while testing.
>
> David Barnett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

On Friday 09 November 2007, David wrote:
> I've finally implemented a solution for this problem (SVN r503).
> 
> I'm pleased with the solution I found because it will scale well if we
> later determine that we need 3 or more separate ranges on some device.
> 
> Thomas Welsch and Nestor, could you update to r503 and make sure it
> solves your problems? Don't forget to delete any "ERRORLEVEL -220"
> directives while testing.

Hi,

I can confirm also that the warning about the adress range of DE 
instructions in absolute mode is gone now.
But I am afraid I get something similar in relocatable mode:

gplink: lst.c:171: write_src: Assertion `data & 0x80000000' failed.


The code leading to that failure is:

---------------------
eedata			UDATA
ee_address	DE	0x01
---------------------

but when I change it to

---------------------
eeprom		ORG	0x2100
;eedata			UDATA
ee_address	DE	0x01
---------------------

instead, it compiles and links just fine. (I compile for a 16F628).

Is this realy related or do I make a mistake here?

Thanks for your efforts and best regards,
Holger.

-- 
Holger Oehm ####@####.####
KeyID: B50E51A9, 1024bit at http://www.holger-oehm.de/public-key.asc
Fingerprint: E92A 5C2C 497A 44ED 23C0  DB66 1DD9 3EF7 B50E 51A9

On Fri, 11 Jan 2008 01:17:24 +0100
Holger Oehm ####@####.#### wrote:

> Hi,
> 
> I can confirm also that the warning about the adress range of DE 
> instructions in absolute mode is gone now.
> But I am afraid I get something similar in relocatable mode:
> 
> gplink: lst.c:171: write_src: Assertion `data & 0x80000000' failed.
> ...
> eedata		UDATA
> ee_address	DE	0x01
> ...
> Is this realy related or do I make a mistake here?
I strongly doubt that it's related because the original problem has to
do with data hard-coded into gpasm specifically for absolute mode and
your problem is triggered in gplink.

But aren't you trying to initialize uninitialized data (UDATA)? It's
been a while since I've worked on PIC's, but I would think you'd want
either "ee_address res 1" or maybe to put it in an IDATA section...?

David Barnett

On Friday 11 January 2008, David wrote:
> On Fri, 11 Jan 2008 01:17:24 +0100
> Holger Oehm ####@####.#### wrote:
> 
> > Hi,
> > 
> > I can confirm also that the warning about the adress range of DE 
> > instructions in absolute mode is gone now.
> > But I am afraid I get something similar in relocatable mode:
> > 
> > gplink: lst.c:171: write_src: Assertion `data & 0x80000000' failed.
> > ...
> > eedata		UDATA
> > ee_address	DE	0x01
> > ...
> > Is this realy related or do I make a mistake here?
> I strongly doubt that it's related because the original problem has to
> do with data hard-coded into gpasm specifically for absolute mode and
> your problem is triggered in gplink.

I see. It was just that I had the same warning (when i used the ORG
directive) and the warning went away when I installed the latest 
version from svn.

> But aren't you trying to initialize uninitialized data (UDATA)? It's
> been a while since I've worked on PIC's, but I would think you'd want
> either "ee_address res 1" or maybe to put it in an IDATA section...?

Ah. Didnt think about that, I just replaced the ORG with UDATA. But
I think it should certainly be initialized data then (I want the
default value to be present in the eeprom after burning the pic).

I changed my code to
...
DEEPROM			IDATA
ee_address	DE	0x01
...

but id didnt do what i wanted. The address was assinged correctly but
not the value (it was still unitialized).

But my next try:
...
DEEPROM			CODE
ee_address	DE	0x01
...
works just fine. (I didnt understand the documentation of IDATA anyway,
shoud it burn the value or not?) Sorry for the confusion on my side 
and thank you for your quick answer! 

Best Regards,
Holger.