Maybe this hasn't been clarified. Reseting the COP is done by writing
0x55
then 0xAA to the ARMCOP register, then write 0x00 to the COPCTL register.
So the sequence is:
movb 0x55,ARMCOP
movb 0xAA, ARMCOP
clr COPCTL
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 09:58 04/08/2005 -0700, you wrote:
>Okay, so here's my assessment of the
problem:
>
>With the idea that Jefferson had about needing to
>reset the COP timer right before shutting it off (clr
>COPCTL), I thought that perhaps by reading byte
>erasable EEPROM (BE-EEPROM), COP is turned on, despite
>having turned it off. And since COPCTL is a
>write-once register, if it comes back on, I can't turn
>it off again.
>
>So, during my initial access to BE-EEPROM, I reset the
>COP timer several times then following the last read,
>I turn off the COP timer. This way, it doesn't time
>out and since I'm done reading the BE-EEPROM, COPCTL
>isn't automatically modified.
>
>It sounds crazy this whole thing, but several simple
>programs on three different board designs with
>different B32s verify that reading of the BE-EEPROM
>will turn on COP, no matter its previous state. Thus,
>turning it off AFTER reading BE-EEPROM keeps COP off.
>Right now, my program does not run on power-on reset,
>but will after an external reset, with or without BDM.
> I can handle that, but that's goofy. The same
>program without the reading of BE-EEPROM works on
>power-on reset however.
>
>It appears to be a bug in the processor. If Freescale
>wants code that demonstrates this, I'll be happy to
>share it.
>
>Thanks goes to Jefferson whose suggestion generated my solution.
>
>__________________________________________________
>
>
>
>Yahoo! Groups Links
>
>
EEPROM not readable on reset? (MC68HC912B32)
Started by ●August 2, 2005
Reply by ●August 4, 20052005-08-04
Reply by ●August 4, 20052005-08-04
Hi Doron, my documentation states that to *reset* the
COP requires moving those bytes in the order you
specify to ARMCOP (or in my case COPRST). But, to
*turn off* (disable) the COP requires "clr COPCTL" and
COPCTL is a write-once register. Again, I'm using the
MC68HC912B32.
The first two lines of your code reset the COP whilst
the last one disables it.
--- Doron Fael <doronf@doro...> wrote:
> Maybe this hasn't been clarified. Reseting the COP
> is done by writing 0x55
> then 0xAA to the ARMCOP register, then write 0x00 to
> the COPCTL register.
>
> So the sequence is:
>
> movb 0x55,ARMCOP
> movb 0xAA, ARMCOP
> clr COPCTL
>
> Hope this helps,
> Doron
> Nohau
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> At 09:58 04/08/2005 -0700, you wrote:
> >Okay, so here's my assessment of the problem:
> >
> >With the idea that Jefferson had about needing to
> >reset the COP timer right before shutting it off
> (clr
> >COPCTL), I thought that perhaps by reading byte
> >erasable EEPROM (BE-EEPROM), COP is turned on,
> despite
> >having turned it off. And since COPCTL is a
> >write-once register, if it comes back on, I can't
> turn
> >it off again.
> >
> >So, during my initial access to BE-EEPROM, I reset
> the
> >COP timer several times then following the last
> read,
> >I turn off the COP timer. This way, it doesn't
> time
> >out and since I'm done reading the BE-EEPROM,
> COPCTL
> >isn't automatically modified.
> >
> >It sounds crazy this whole thing, but several
> simple
> >programs on three different board designs with
> >different B32s verify that reading of the BE-EEPROM
> >will turn on COP, no matter its previous state.
> Thus,
> >turning it off AFTER reading BE-EEPROM keeps COP
> off.
> >Right now, my program does not run on power-on
> reset,
> >but will after an external reset, with or without
> BDM.
> > I can handle that, but that's goofy. The same
> >program without the reading of BE-EEPROM works on
> >power-on reset however.
> >
> >It appears to be a bug in the processor. If
> Freescale
> >wants code that demonstrates this, I'll be happy to
> >share it.
> >
> >Thanks goes to Jefferson whose suggestion generated
> my solution.
> >
> >__________________________________________________
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> > [Non-text portions of this message have been
> removed]
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
COP requires moving those bytes in the order you
specify to ARMCOP (or in my case COPRST). But, to
*turn off* (disable) the COP requires "clr COPCTL" and
COPCTL is a write-once register. Again, I'm using the
MC68HC912B32.
The first two lines of your code reset the COP whilst
the last one disables it.
--- Doron Fael <doronf@doro...> wrote:
> Maybe this hasn't been clarified. Reseting the COP
> is done by writing 0x55
> then 0xAA to the ARMCOP register, then write 0x00 to
> the COPCTL register.
>
> So the sequence is:
>
> movb 0x55,ARMCOP
> movb 0xAA, ARMCOP
> clr COPCTL
>
> Hope this helps,
> Doron
> Nohau
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> At 09:58 04/08/2005 -0700, you wrote:
> >Okay, so here's my assessment of the problem:
> >
> >With the idea that Jefferson had about needing to
> >reset the COP timer right before shutting it off
> (clr
> >COPCTL), I thought that perhaps by reading byte
> >erasable EEPROM (BE-EEPROM), COP is turned on,
> despite
> >having turned it off. And since COPCTL is a
> >write-once register, if it comes back on, I can't
> turn
> >it off again.
> >
> >So, during my initial access to BE-EEPROM, I reset
> the
> >COP timer several times then following the last
> read,
> >I turn off the COP timer. This way, it doesn't
> time
> >out and since I'm done reading the BE-EEPROM,
> COPCTL
> >isn't automatically modified.
> >
> >It sounds crazy this whole thing, but several
> simple
> >programs on three different board designs with
> >different B32s verify that reading of the BE-EEPROM
> >will turn on COP, no matter its previous state.
> Thus,
> >turning it off AFTER reading BE-EEPROM keeps COP
> off.
> >Right now, my program does not run on power-on
> reset,
> >but will after an external reset, with or without
> BDM.
> > I can handle that, but that's goofy. The same
> >program without the reading of BE-EEPROM works on
> >power-on reset however.
> >
> >It appears to be a bug in the processor. If
> Freescale
> >wants code that demonstrates this, I'll be happy to
> >share it.
> >
> >Thanks goes to Jefferson whose suggestion generated
> my solution.
> >
> >__________________________________________________
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> > [Non-text portions of this message have been
> removed]
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
Reply by ●August 4, 20052005-08-04
Yes, That the way you want to handle the COP: First Reset it, then disable
it.
This is due to a specific issue in the HC912B32 silicon.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 11:21 04/08/2005 -0700, you wrote:
>Hi Doron, my documentation states that to *reset* the
>COP requires moving those bytes in the order you
>specify to ARMCOP (or in my case COPRST). But, to
>*turn off* (disable) the COP requires "clr COPCTL" and
>COPCTL is a write-once register. Again, I'm using the
>MC68HC912B32.
>
>The first two lines of your code reset the COP whilst
>the last one disables it.
>
>--- Doron Fael <doronf@doro...> wrote:
>
> > Maybe this hasn't been clarified. Reseting the COP
> > is done by writing 0x55
> > then 0xAA to the ARMCOP register, then write 0x00 to
> > the COPCTL register.
> >
> > So the sequence is:
> >
> > movb 0x55,ARMCOP
> > movb 0xAA, ARMCOP
> > clr COPCTL
> >
> > Hope this helps,
> > Doron
> > Nohau
> > HC12 In-Circuit Emulators
> > www.nohau.com/emul12pc.html
> >
> > At 09:58 04/08/2005 -0700, you wrote:
> > >Okay, so here's my assessment of the problem:
> > >
> > >With the idea that Jefferson had about needing to
> > >reset the COP timer right before shutting it off
> > (clr
> > >COPCTL), I thought that perhaps by reading byte
> > >erasable EEPROM (BE-EEPROM), COP is turned on,
> > despite
> > >having turned it off. And since COPCTL is a
> > >write-once register, if it comes back on, I can't
> > turn
> > >it off again.
> > >
> > >So, during my initial access to BE-EEPROM, I reset
> > the
> > >COP timer several times then following the last
> > read,
> > >I turn off the COP timer. This way, it doesn't
> > time
> > >out and since I'm done reading the BE-EEPROM,
> > COPCTL
> > >isn't automatically modified.
> > >
> > >It sounds crazy this whole thing, but several
> > simple
> > >programs on three different board designs with
> > >different B32s verify that reading of the BE-EEPROM
> > >will turn on COP, no matter its previous state.
> > Thus,
> > >turning it off AFTER reading BE-EEPROM keeps COP
> > off.
> > >Right now, my program does not run on power-on
> > reset,
> > >but will after an external reset, with or without
> > BDM.
> > > I can handle that, but that's goofy. The same
> > >program without the reading of BE-EEPROM works on
> > >power-on reset however.
> > >
> > >It appears to be a bug in the processor. If
> > Freescale
> > >wants code that demonstrates this, I'll be happy to
> > >share it.
> > >
> > >Thanks goes to Jefferson whose suggestion generated
> > my solution.
> > >
> > >__________________________________________________
> > >
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been
> > removed]
> >
> >
>
>____________________________________________________
>Start your day with Yahoo! - make it your home page
>http://www.yahoo.com/r/hs >Yahoo! Groups Links >
>
This is due to a specific issue in the HC912B32 silicon.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 11:21 04/08/2005 -0700, you wrote:
>Hi Doron, my documentation states that to *reset* the
>COP requires moving those bytes in the order you
>specify to ARMCOP (or in my case COPRST). But, to
>*turn off* (disable) the COP requires "clr COPCTL" and
>COPCTL is a write-once register. Again, I'm using the
>MC68HC912B32.
>
>The first two lines of your code reset the COP whilst
>the last one disables it.
>
>--- Doron Fael <doronf@doro...> wrote:
>
> > Maybe this hasn't been clarified. Reseting the COP
> > is done by writing 0x55
> > then 0xAA to the ARMCOP register, then write 0x00 to
> > the COPCTL register.
> >
> > So the sequence is:
> >
> > movb 0x55,ARMCOP
> > movb 0xAA, ARMCOP
> > clr COPCTL
> >
> > Hope this helps,
> > Doron
> > Nohau
> > HC12 In-Circuit Emulators
> > www.nohau.com/emul12pc.html
> >
> > At 09:58 04/08/2005 -0700, you wrote:
> > >Okay, so here's my assessment of the problem:
> > >
> > >With the idea that Jefferson had about needing to
> > >reset the COP timer right before shutting it off
> > (clr
> > >COPCTL), I thought that perhaps by reading byte
> > >erasable EEPROM (BE-EEPROM), COP is turned on,
> > despite
> > >having turned it off. And since COPCTL is a
> > >write-once register, if it comes back on, I can't
> > turn
> > >it off again.
> > >
> > >So, during my initial access to BE-EEPROM, I reset
> > the
> > >COP timer several times then following the last
> > read,
> > >I turn off the COP timer. This way, it doesn't
> > time
> > >out and since I'm done reading the BE-EEPROM,
> > COPCTL
> > >isn't automatically modified.
> > >
> > >It sounds crazy this whole thing, but several
> > simple
> > >programs on three different board designs with
> > >different B32s verify that reading of the BE-EEPROM
> > >will turn on COP, no matter its previous state.
> > Thus,
> > >turning it off AFTER reading BE-EEPROM keeps COP
> > off.
> > >Right now, my program does not run on power-on
> > reset,
> > >but will after an external reset, with or without
> > BDM.
> > > I can handle that, but that's goofy. The same
> > >program without the reading of BE-EEPROM works on
> > >power-on reset however.
> > >
> > >It appears to be a bug in the processor. If
> > Freescale
> > >wants code that demonstrates this, I'll be happy to
> > >share it.
> > >
> > >Thanks goes to Jefferson whose suggestion generated
> > my solution.
> > >
> > >__________________________________________________
> > >
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been
> > removed]
> >
> >
>
>____________________________________________________
>Start your day with Yahoo! - make it your home page
>http://www.yahoo.com/r/hs >Yahoo! Groups Links >
>
Reply by ●August 5, 20052005-08-05
--- In 68HC12@68HC..., E E <drranu@y...> wrote:
> So, during my initial access to BE-EEPROM, I reset the
> COP timer several times then following the last read,
> I turn off the COP timer. This way, it doesn't time
> out and since I'm done reading the BE-EEPROM, COPCTL
> isn't automatically modified.
Strange though, I've never seen it work that way in my EE bootup code.
Maybe my BC32 is different? I have one where the ROM vector 0xfffe
jumps to EE, which does this:
0D00 CF0C00 LDS #$0C00 > set Stack Pointer
0D03 790016 CLR $0016 > Disable COP
0D06 18032C78000A MOVW #$2C78,$000A > Enable expanded mode
0D0C 18032C78000A MOVW #$2C78,$000A >
0D12 1C00D70C BSET $00D7,#$0C > Configure MX1 RAM expansion
0D16 1D00D60C BCLR $00D6,#$0C >
0D1A 180B020013 MOVB #$02,$0013 > Disable internal Flash
0D1F CE0019 LDX #$0019 > Delay to power up MX1
0D22 CC682A LDD #$682A >
0D25 0434FD DBNE D,$0D25 >
0D28 0435F7 DBNE X,$0D22 >
0D2B FEFFFE LDX $FFFE > Reset vector from RAM
0D2E 2702 BEQ $0D32 >
0D30 0500 JMP 0,X > Jump if vector not null
0D32 CE1000 LDX #$1000 > no vector; clear program space
0D35 87 CLRA >
0D36 C7 CLRB >
0D37 6C31 STD 2,X+ >
0D39 0475FB TBNE X,$0D37 >
I use it to load programs to the external RAM at 0x8000..0xffff which
is battery backed up, then this executes it on powerup. I used this
over a year ago. I wonder why I didn't even have to reset the COP
timer before `CLR $0016` --jeffs
> So, during my initial access to BE-EEPROM, I reset the
> COP timer several times then following the last read,
> I turn off the COP timer. This way, it doesn't time
> out and since I'm done reading the BE-EEPROM, COPCTL
> isn't automatically modified.
Strange though, I've never seen it work that way in my EE bootup code.
Maybe my BC32 is different? I have one where the ROM vector 0xfffe
jumps to EE, which does this:
0D00 CF0C00 LDS #$0C00 > set Stack Pointer
0D03 790016 CLR $0016 > Disable COP
0D06 18032C78000A MOVW #$2C78,$000A > Enable expanded mode
0D0C 18032C78000A MOVW #$2C78,$000A >
0D12 1C00D70C BSET $00D7,#$0C > Configure MX1 RAM expansion
0D16 1D00D60C BCLR $00D6,#$0C >
0D1A 180B020013 MOVB #$02,$0013 > Disable internal Flash
0D1F CE0019 LDX #$0019 > Delay to power up MX1
0D22 CC682A LDD #$682A >
0D25 0434FD DBNE D,$0D25 >
0D28 0435F7 DBNE X,$0D22 >
0D2B FEFFFE LDX $FFFE > Reset vector from RAM
0D2E 2702 BEQ $0D32 >
0D30 0500 JMP 0,X > Jump if vector not null
0D32 CE1000 LDX #$1000 > no vector; clear program space
0D35 87 CLRA >
0D36 C7 CLRB >
0D37 6C31 STD 2,X+ >
0D39 0475FB TBNE X,$0D37 >
I use it to load programs to the external RAM at 0x8000..0xffff which
is battery backed up, then this executes it on powerup. I used this
over a year ago. I wonder why I didn't even have to reset the COP
timer before `CLR $0016` --jeffs
