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 |
|
standalone EEPROM write on MC9S12A256B / 1k79x ?
Started by ●December 4, 2003
Reply by ●December 4, 20032003-12-04
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 |
|
Reply by ●December 4, 20032003-12-04
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 |
|
Reply by ●December 9, 20032003-12-09
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 > > |
Reply by ●December 9, 20032003-12-09
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 > |
|
Reply by ●December 9, 20032003-12-09
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 > > > > > > |
Reply by ●December 9, 20032003-12-09
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 > > > > > > -------------------- |