Searching \ for '[PIC] PIC16F628A 0x7F ram mapping' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/microchip/devices.htm?key=16F
Search entire site for: 'PIC16F628A 0x7F ram mapping'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC16F628A 0x7F ram mapping'
2009\05\01@102325 by PPA

flavicon
face

Hi all,
Anybody knows why PIC16F628A MPLINK script has a special section mapping of
one byte for ram address 0x7F?
I've scanned the datasheet and nothing about this strange thing. PIC16F628
does not have this one byte section.


-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/-PIC--PIC16F628A-0x7F-ram-mapping-tp23333893p23333893.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\05\01@102832 by PPA

flavicon
face

Hi all,
Somebody knows why PIC16F628A MPLINK script has a special section mapping of
one byte for ram address 0x7F?
I've scanned the datasheet and nothing about this strange thing. PIC16F628
does not have this one byte section.


-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/-PIC--PIC16F628A-0x7F-ram-mapping-tp23333893p23333893.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\05\01@103728 by Dario Greggio

face picon face
PPA ha scritto:

> Anybody knows why PIC16F628A MPLINK script has a special section mapping of
> one byte for ram address 0x7F?
> I've scanned the datasheet and nothing about this strange thing. PIC16F628
> does not have this one byte section.


wow :) tons of years using them, and now my certainties go berserk in
one moment!! :))

seriously, I don't know...

2009\05\01@110958 by PPA

flavicon
face

Ha ha! I knew that it would be a good riddle!
Come on list gurus! Scratch your head!


Dario Greggio (in giro) wrote:
{Quote hidden}

> --

2009\05\01@111628 by olin piclist

face picon face
PPA wrote:
> Somebody knows why PIC16F628A MPLINK script has a special section
> mapping of one byte for ram address 0x7F?

Probably, since someone had to write the file.  Why do you ask?

> I've scanned the datasheet and nothing about this strange thing.
> PIC16F628 does not have this one byte section.

I just took a look and it doesn't make sense to me either.  It looks like
something accidentally left in from another version.  Note that memory
region for 1FFh is called TESTREG and is not in the sharebank of the other
three aliases for that address.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\01@114503 by PPA

flavicon
face

Hi all,
The OP was incomplete (sorry Olin) and requires some additional
explanations:
The mapping concerns all 0x?7F and 0x?FF addresses; included the last 0x3FF
that seems in fact to be isolated from the other addresses and named
"testreg".
So I suppose there is a special behavior on this 0x3FF address that some MC
software uses? Or what else?


PPA wrote:
>
> Hi all,
> Somebody knows why PIC16F628A MPLINK script has a special section mapping
> of one byte for ram address 0x7F?
> I've scanned the datasheet and nothing about this strange thing. PIC16F628
> does not have this one byte section.
>
>


-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/-PIC--PIC16F628A-0x7F-ram-mapping-tp23333893p23335131.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\05\01@120119 by PPA

flavicon
face

Hi Olin,

Our posts has just crossed...


Olin Lathrop wrote:
>
> PPA wrote:
>> Somebody knows why PIC16F628A MPLINK script has a special section
>> mapping of one byte for ram address 0x7F?
>
> Probably, since someone had to write the file.  Why do you ask?
>

Nothing illogical can get through your logical spirit Mr Spok...
Good question... First because I want to know how things work and why they
are as they are...
In fact a compiler that I use allocates variables at compile time and
outputs absolute data sections for mplink; it has put an array of 5 bytes at
0x7B and MPLINK does not aggree because there is a section crossing, even if
sections are in the same bank and of the same type. So I'm searching if
there is a special thing to know about this special mapping.



-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/-PIC--PIC16F628A-0x7F-ram-mapping-tp23333893p23335432.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\05\01@121515 by Alan B. Pearce

face picon face
>So I suppose there is a special behavior on this 0x3FF
>address that some MC software uses? Or what else?

I have a feeling that the ICD uses this in debug mode, and as such, it is a
reserved location. It looks like they have reserved it in the linker map so
that they don't use a special linker map for debug.

2009\05\01@130701 by Jan-Erik Soderholm

face picon face
Alan B. Pearce wrote:
>> So I suppose there is a special behavior on this 0x3FF
>> address that some MC software uses? Or what else?
>
> I have a feeling that the ICD uses this in debug mode, and as such, it is a
> reserved location. It looks like they have reserved it in the linker map so
> that they don't use a special linker map for debug.
>

Then why doesn't the 16F648A.LKR linker script have the
same allocations ? If it was me, I'd simply adjust the 628A
LKR to match the 648A LKR (apart from the second program
memory page, of course).

Jan-Erik.

2009\05\01@132225 by Bob Ammerman

picon face
IIRC 0x7F is reserved for ICD on some chips. Don't know about the 628A,
though.

-- Bob Ammerman
RAm Systems

2009\05\01@140831 by Jan-Erik Soderholm

face picon face
Bob Ammerman wrote:
> IIRC 0x7F is reserved for ICD on some chips. Don't know about the 628A,
> though.

Then I would expect the same in the 648A LKR...

And, b.t.w, the "i" LKR does have special allocations
for the debugger (both 628ai and 648ai).

Jan-Erik.

>
> -- Bob Ammerman
> RAm Systems
>

2009\05\02@081256 by PPA

flavicon
face


Jan-Erik Soderholm wrote:
>
> Bob Ammerman wrote:
>> IIRC 0x7F is reserved for ICD on some chips. Don't know about the 628A,
>> though.
>
> Then I would expect the same in the 648A LKR...
>
> And, b.t.w, the "i" LKR does have special allocations
> for the debugger (both 628ai and 648ai).
>
> Jan-Erik.
>

BTW too: '627A has also a special mapping at the same address as '628A.
I don't know what are MC (or all?) ICDs using requirements so the following
questions may seem a little bit simplistic:
A quick grep shows that almost all *i and *g scripts had a special mapping
with a section named "dbgnobnk" for a single byte at 0x?70 / 0x?F0 (first
byte of unbanked area).
So why there's a different mapping on '628A (0x?7F / 0x?FF)?
How does the ICD know what is the address to be used?
What mechanism prevent the use of these one byte sections by the linker when
you want to use an ICD?
As Olin suggests, can we assume that these mappings was left by the MC guys
by mistake and should be seen as a bug?


-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/-PIC--PIC16F628A-0x7F-ram-mapping-tp23333893p23345617.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...