standalone EEPROM write on MC9S12A256B / 1k79x ?

Started by christian_theiss_2003 December 4, 2003
Hi all,

I have come across of some strange unexplained behaviour if I try to
write to the 4k EEPROM of my HCS12 derivative:

a) writing to the EEPROM with BDM attached works walking through my
application code which successfully writes to the EEPROM

b) writing to the EEPROM without BDM running the system standalone in
single-chip mode doesn't work and EEPROM writing is always rejected

----------------
Setup of EEPROM:
- INITEE is set to 0x400 OR'ed with default 0x01
- INITRM is let set at default reset value

additional setup possibly EEPROM relevant:
- PLL works with 24MHz
- external oscillator is 16MHz from which EEPROM clock is derived
-----------------------------

After resetting and stepping through the debugger:
--------------
register 0x10 is set to 0x09 for the RAM mapping?
register 0x12 is set to 0x01 for the EEPROM mapping?

As the border on which the EEPROM base should be set is said to be a
2k/4k border sticking to HCS12 EEPROM spec it also doesn't work with
INITEE set to 0x800 instead of 0x400!? What is the problem with this kind of standalone behaviour? Is the
EEPROM locked to be not able to write to it anymore and BDM does some
kind of backdoor unlocking mechanism? Has anyone made similar
experiences around HCS12 EEPROM writing stuff? Or is it simply
depending on my special derivative? Thanx for your help in advance,

Christian



Christian,

The HCS12 family includes a priority encoder to determine which memory
resource will be mapped to every address when several memory resources
overlap. The priority is set to:

SFR Registers (Highest priority)
Internal RAM
Internal EEPROM
Internal Flash
External memory (Lowest priority)

Thus when both the EEPROM and SFR registers are mapped to start at address
$0000 (default condition after Reset), the first 1K of the EEPROM (at
addresses $0000 - $03FF) is not usable and is covered by the SFR registers.
In order to use the whole EEPROM you need to first map it to another
address using the INITEE register.

For HCS12 derivatives with 4K EEPROM (like the MC9S12A256B that you are
using), the EEPROM may be mapped to any 4K address boundary and not 2K
address Boundary. Thus on the MC9S12A256B, the EEPROM can be mapped to
start at address $0000, $1000, $2000, ... $E000, $F000.

On other HCS12 parts that have 2K EEPROM or less, it is possible to map the
EEPROM to any 2K boundary using the INITEE register.

Hope this helps,
Doron
Nohau Corporation
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 08:10 04/12/2003 +0000, you wrote:
>Hi all,
>
>I have come across of some strange unexplained behaviour if I try to
>write to the 4k EEPROM of my HCS12 derivative:
>
>a) writing to the EEPROM with BDM attached works walking through my
>application code which successfully writes to the EEPROM
>
>b) writing to the EEPROM without BDM running the system standalone in
>single-chip mode doesn't work and EEPROM writing is always rejected
>
>----------------
>Setup of EEPROM:
>- INITEE is set to 0x400 OR'ed with default 0x01
>- INITRM is let set at default reset value
>
>additional setup possibly EEPROM relevant:
>- PLL works with 24MHz
>- external oscillator is 16MHz from which EEPROM clock is derived
>-----------------------------
>
>After resetting and stepping through the debugger:
>--------------
>register 0x10 is set to 0x09 for the RAM mapping?
>register 0x12 is set to 0x01 for the EEPROM mapping?
>
>As the border on which the EEPROM base should be set is said to be a
>2k/4k border sticking to HCS12 EEPROM spec it also doesn't work with
>INITEE set to 0x800 instead of 0x400!? >What is the problem with this kind of standalone behaviour? Is the
>EEPROM locked to be not able to write to it anymore and BDM does some
>kind of backdoor unlocking mechanism? Has anyone made similar
>experiences around HCS12 EEPROM writing stuff? Or is it simply
>depending on my special derivative? >Thanx for your help in advance,
>
>Christian





Christian,

You don't say where your program is running from. If your program
resides in EEPROM, you will not be able to program it because it
is not possible to read from EEPROM while it is being programmed.

However, it's possible that stepping through your program with the
BDM in trace mode might allow you to program it. I imagine that
the BDM keeps trace instructions temporally in RAM somewhere.

Mike --- In , christian_theiss_2003 you wrote:

>I have come across of some strange unexplained behaviour if I try to
>write to the 4k EEPROM of my HCS12 derivative:

>a) writing to the EEPROM with BDM attached works walking through my
>application code which successfully writes to the EEPROM

>b) writing to the EEPROM without BDM running the system standalone in
>single-chip mode doesn't work and EEPROM writing is always rejected



Hi Mike,

thanx for your reply! Yes, I think BDM makes it possible write the
lower 1k @0x400 and if I try to read it standalone this first 1k
EEPROM memory area is hidden then... I will try
- 0x1000 for INITEE or
- write to EEPROM @ offset 0x1000
to get again my data structured EEPROM data entities Thanx for your help

Christian --- In , "Mike Elphick" <mike.elphick@d...>
wrote:
> Christian,
>
> You don't say where your program is running from. If your program
> resides in EEPROM, you will not be able to program it because it
> is not possible to read from EEPROM while it is being programmed.
>
> However, it's possible that stepping through your program with the
> BDM in trace mode might allow you to program it. I imagine that
> the BDM keeps trace instructions temporally in RAM somewhere.
>
> Mike > --- In , christian_theiss_2003 you wrote:
>
> >I have come across of some strange unexplained behaviour if I try
to
> >write to the 4k EEPROM of my HCS12 derivative:
>
> >a) writing to the EEPROM with BDM attached works walking through
my
> >application code which successfully writes to the EEPROM
>
> >b) writing to the EEPROM without BDM running the system standalone
in
> >single-chip mode doesn't work and EEPROM writing is always rejected >
>




Hi Doron,

thanx for your detailed explanation of the EEPROM mapping topic! I
will try to remap at the 4k boundary 0x1000 or write my data
structure to an 0x1000 offset...
maybe in standalone is was prohibited to write to SFR system register
area in the lower 1k where I tried to write my data in standalone
without help of BDM debug tool Thanx for this important 4k-border mapping hint

Christian

--- In , Doron Fael <doronf@n...> wrote:
> Christian,
>
> The HCS12 family includes a priority encoder to determine which
memory
> resource will be mapped to every address when several memory
resources
> overlap. The priority is set to:
>
> SFR Registers (Highest priority)
> Internal RAM
> Internal EEPROM
> Internal Flash
> External memory (Lowest priority)
>
> Thus when both the EEPROM and SFR registers are mapped to start at
address
> $0000 (default condition after Reset), the first 1K of the EEPROM
(at
> addresses $0000 - $03FF) is not usable and is covered by the SFR
registers.
> In order to use the whole EEPROM you need to first map it to
another
> address using the INITEE register.
>
> For HCS12 derivatives with 4K EEPROM (like the MC9S12A256B that you
are
> using), the EEPROM may be mapped to any 4K address boundary and not
2K
> address Boundary. Thus on the MC9S12A256B, the EEPROM can be mapped
to
> start at address $0000, $1000, $2000, ... $E000, $F000.
>
> On other HCS12 parts that have 2K EEPROM or less, it is possible to
map the
> EEPROM to any 2K boundary using the INITEE register.
>
> Hope this helps,
> Doron
> Nohau Corporation
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> At 08:10 04/12/2003 +0000, you wrote:
> >Hi all,
> >
> >I have come across of some strange unexplained behaviour if I try
to
> >write to the 4k EEPROM of my HCS12 derivative:
> >
> >a) writing to the EEPROM with BDM attached works walking through my
> >application code which successfully writes to the EEPROM
> >
> >b) writing to the EEPROM without BDM running the system standalone
in
> >single-chip mode doesn't work and EEPROM writing is always rejected
> >
> >----------------
> >Setup of EEPROM:
> >- INITEE is set to 0x400 OR'ed with default 0x01
> >- INITRM is let set at default reset value
> >
> >additional setup possibly EEPROM relevant:
> >- PLL works with 24MHz
> >- external oscillator is 16MHz from which EEPROM clock is derived
> >-----------------------------
> >
> >After resetting and stepping through the debugger:
> >--------------
> >register 0x10 is set to 0x09 for the RAM mapping?
> >register 0x12 is set to 0x01 for the EEPROM mapping?
> >
> >As the border on which the EEPROM base should be set is said to be
a
> >2k/4k border sticking to HCS12 EEPROM spec it also doesn't work
with
> >INITEE set to 0x800 instead of 0x400!?
> >
> >
> >What is the problem with this kind of standalone behaviour? Is the
> >EEPROM locked to be not able to write to it anymore and BDM does
some
> >kind of backdoor unlocking mechanism? Has anyone made similar
> >experiences around HCS12 EEPROM writing stuff? Or is it simply
> >depending on my special derivative?
> >
> >
> >Thanx for your help in advance,
> >
> >Christian >





Hi Doron, Mike & all

I am still not able to write something to the EEPROM if I setup:
INITEE = 0x00;
INITRM = 0x09;

My system hangs if I try to write an EEPROM entity if this entity is
different from what I will newly write to! And I can't debug this
because writing this former value WITH BDM this error isn't present
at all...???

Do you know something else what could help to solve this...?
Please note that I have located my EEPROM structure at offset 0x400
not to overlap with SFR registers but this makes no difference:
a) with BDM running works
b) without BDM hangs... Thanx in advance

Christian --- In , "christian_theiss_2003"
<Christian.Theiss@b...> wrote:
> Hi Doron,
>
> thanx for your detailed explanation of the EEPROM mapping topic! I
> will try to remap at the 4k boundary 0x1000 or write my data
> structure to an 0x1000 offset...
> maybe in standalone is was prohibited to write to SFR system
register
> area in the lower 1k where I tried to write my data in standalone
> without help of BDM debug tool > Thanx for this important 4k-border mapping hint
>
> Christian
>
> --- In , Doron Fael <doronf@n...> wrote:
> > Christian,
> >
> > The HCS12 family includes a priority encoder to determine which
> memory
> > resource will be mapped to every address when several memory
> resources
> > overlap. The priority is set to:
> >
> > SFR Registers (Highest priority)
> > Internal RAM
> > Internal EEPROM
> > Internal Flash
> > External memory (Lowest priority)
> >
> > Thus when both the EEPROM and SFR registers are mapped to start
at
> address
> > $0000 (default condition after Reset), the first 1K of the EEPROM
> (at
> > addresses $0000 - $03FF) is not usable and is covered by the SFR
> registers.
> > In order to use the whole EEPROM you need to first map it to
> another
> > address using the INITEE register.
> >
> > For HCS12 derivatives with 4K EEPROM (like the MC9S12A256B that
you
> are
> > using), the EEPROM may be mapped to any 4K address boundary and
not
> 2K
> > address Boundary. Thus on the MC9S12A256B, the EEPROM can be
mapped
> to
> > start at address $0000, $1000, $2000, ... $E000, $F000.
> >
> > On other HCS12 parts that have 2K EEPROM or less, it is possible
to
> map the
> > EEPROM to any 2K boundary using the INITEE register.
> >
> > Hope this helps,
> > Doron
> > Nohau Corporation
> > HC12 In-Circuit Emulators
> > www.nohau.com/emul12pc.html
> >
> > At 08:10 04/12/2003 +0000, you wrote:
> > >Hi all,
> > >
> > >I have come across of some strange unexplained behaviour if I
try
> to
> > >write to the 4k EEPROM of my HCS12 derivative:
> > >
> > >a) writing to the EEPROM with BDM attached works walking through
my
> > >application code which successfully writes to the EEPROM
> > >
> > >b) writing to the EEPROM without BDM running the system
standalone
> in
> > >single-chip mode doesn't work and EEPROM writing is always
rejected
> > >
> > >----------------
> > >Setup of EEPROM:
> > >- INITEE is set to 0x400 OR'ed with default 0x01
> > >- INITRM is let set at default reset value
> > >
> > >additional setup possibly EEPROM relevant:
> > >- PLL works with 24MHz
> > >- external oscillator is 16MHz from which EEPROM clock is derived
> > >-----------------------------
> > >
> > >After resetting and stepping through the debugger:
> > >--------------
> > >register 0x10 is set to 0x09 for the RAM mapping?
> > >register 0x12 is set to 0x01 for the EEPROM mapping?
> > >
> > >As the border on which the EEPROM base should be set is said to
be
> a
> > >2k/4k border sticking to HCS12 EEPROM spec it also doesn't work
> with
> > >INITEE set to 0x800 instead of 0x400!?
> > >
> > >
> > >What is the problem with this kind of standalone behaviour? Is
the
> > >EEPROM locked to be not able to write to it anymore and BDM does
> some
> > >kind of backdoor unlocking mechanism? Has anyone made similar
> > >experiences around HCS12 EEPROM writing stuff? Or is it simply
> > >depending on my special derivative?
> > >
> > >
> > >Thanx for your help in advance,
> > >
> > >Christian
> >
> >
> >




Hi Christian,

What value have you got for the ECLKDIV register? This depends
on your crystal frequency and whether you have implemented the PLL.

For example, I think your ECLKDIV should be about $4b for an eclock
of 24MHz.

Another point is that, unlike RAM, you have to erase EEPROM
to $ff before you can write to it.

None of this explains why your system hangs. If you want to
send me your code _off list_ I will try and help you.

Mike
----- Original Message -----
From: christian_theiss_2003
To:
Sent: Tuesday, December 09, 2003 2:50 PM
Subject: [68HC12] Re: standalone EEPROM write on MC9S12A256B / 1k79x ? Hi Doron, Mike & all

I am still not able to write something to the EEPROM if I setup:
INITEE = 0x00;
INITRM = 0x09;

My system hangs if I try to write an EEPROM entity if this entity is
different from what I will newly write to! And I can't debug this
because writing this former value WITH BDM this error isn't present
at all...???

Do you know something else what could help to solve this...?
Please note that I have located my EEPROM structure at offset 0x400
not to overlap with SFR registers but this makes no difference:
a) with BDM running works
b) without BDM hangs... Thanx in advance

Christian --- In , "christian_theiss_2003"
<Christian.Theiss@b...> wrote:
> Hi Doron,
>
> thanx for your detailed explanation of the EEPROM mapping topic! I
> will try to remap at the 4k boundary 0x1000 or write my data
> structure to an 0x1000 offset...
> maybe in standalone is was prohibited to write to SFR system
register
> area in the lower 1k where I tried to write my data in standalone
> without help of BDM debug tool > Thanx for this important 4k-border mapping hint
>
> Christian
>
> --- In , Doron Fael <doronf@n...> wrote:
> > Christian,
> >
> > The HCS12 family includes a priority encoder to determine which
> memory
> > resource will be mapped to every address when several memory
> resources
> > overlap. The priority is set to:
> >
> > SFR Registers (Highest priority)
> > Internal RAM
> > Internal EEPROM
> > Internal Flash
> > External memory (Lowest priority)
> >
> > Thus when both the EEPROM and SFR registers are mapped to start
at
> address
> > $0000 (default condition after Reset), the first 1K of the EEPROM
> (at
> > addresses $0000 - $03FF) is not usable and is covered by the SFR
> registers.
> > In order to use the whole EEPROM you need to first map it to
> another
> > address using the INITEE register.
> >
> > For HCS12 derivatives with 4K EEPROM (like the MC9S12A256B that
you
> are
> > using), the EEPROM may be mapped to any 4K address boundary and
not
> 2K
> > address Boundary. Thus on the MC9S12A256B, the EEPROM can be
mapped
> to
> > start at address $0000, $1000, $2000, ... $E000, $F000.
> >
> > On other HCS12 parts that have 2K EEPROM or less, it is possible
to
> map the
> > EEPROM to any 2K boundary using the INITEE register.
> >
> > Hope this helps,
> > Doron
> > Nohau Corporation
> > HC12 In-Circuit Emulators
> > www.nohau.com/emul12pc.html
> >
> > At 08:10 04/12/2003 +0000, you wrote:
> > >Hi all,
> > >
> > >I have come across of some strange unexplained behaviour if I
try
> to
> > >write to the 4k EEPROM of my HCS12 derivative:
> > >
> > >a) writing to the EEPROM with BDM attached works walking through
my
> > >application code which successfully writes to the EEPROM
> > >
> > >b) writing to the EEPROM without BDM running the system
standalone
> in
> > >single-chip mode doesn't work and EEPROM writing is always
rejected
> > >
> > >----------------
> > >Setup of EEPROM:
> > >- INITEE is set to 0x400 OR'ed with default 0x01
> > >- INITRM is let set at default reset value
> > >
> > >additional setup possibly EEPROM relevant:
> > >- PLL works with 24MHz
> > >- external oscillator is 16MHz from which EEPROM clock is derived
> > >-----------------------------
> > >
> > >After resetting and stepping through the debugger:
> > >--------------
> > >register 0x10 is set to 0x09 for the RAM mapping?
> > >register 0x12 is set to 0x01 for the EEPROM mapping?
> > >
> > >As the border on which the EEPROM base should be set is said to
be
> a
> > >2k/4k border sticking to HCS12 EEPROM spec it also doesn't work
> with
> > >INITEE set to 0x800 instead of 0x400!?
> > >
> > >
> > >What is the problem with this kind of standalone behaviour? Is
the
> > >EEPROM locked to be not able to write to it anymore and BDM does
> some
> > >kind of backdoor unlocking mechanism? Has anyone made similar
> > >experiences around HCS12 EEPROM writing stuff? Or is it simply
> > >depending on my special derivative?
> > >
> > >
> > >Thanx for your help in advance,
> > >
> > >Christian
> >
> >
> >

--------------------