> 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:
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
Reply by Doron Fael●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
>
>
Reply by E E●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
Reply by Doron Fael●August 4, 20052005-08-04
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
>
>
Reply by E E●August 4, 20052005-08-04
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.
Dave, my apologies. I neglected to copy that line
over. "lds #$0BFF" is placed right after "clr
COPCTL".
I also tried Jefferson's suggestion of resetting COP
(with the $55, $AA sequence into COPRST) prior to
clearing COPCTL and even added resetting COP at the
right times in the program, to no avail.
It seems that unless I'm using BDM, reading from (byte
erasable) EEPROM changes something so that the program
doesn't run.
Incidently, COPCTL is defined as $0016 and COPRST is
$0017.
Am I missing something?
--- "Dr. David A. Perreault" <dap@dap@...> wrote:
> If this is all you have, where did you setup
the
> stack pointer?
>
> Dave
> drranu wrote:
>
> > Dave, actually I have a simpler case. I set the
> reset vector to point
> > to $8000. From here, the code shuts off the COP
> watchdog and then
> > jumps to $0FFA in EEPROM which just jumps to $8100
> which then runs
> > sime very simple code to continuously output an
> 'e' on the SPI port
> > (which goes to a RS-232 level converter for a
> serial port). Again,
> > unless the BDM is on, it won't work. Here's the
> code:
> >
> > org $8000
> > clr COPCTL
> > jmp $0FFA
> >
> > org $8100
> > clr SC0CR1
> > movw #$000C,SC0CR1
> > ldaa SC0SR1
> > ldab #$65
> > LOOP:
> > jsr PUT_CHAR
> > bra LOOP
> >
> > PUT_CHAR:
> > brclr SC0SR1,#$80,PUT_CHAR
> > stab SC0DRL
> > rts
> >
> > Okay, now at $0FFA there is just
> > ldy #$8100
> > jmp 0,Y
> >
> > And that's all. It will not run on power on or
> external reset without
> > the BDM connected and on (controlled from a host
> proc). Thanks for
> > any help. All of my programs to date (3 years
> worth) have run fine
> > until I started accessing the EEPROM. Thanks for
> any help. I really
> > appreciate your time.
> >
> > --- In 68HC12@68HC..., Dave Perreault
> <dap@p...> wrote:
> > > Both the RAM and the EEPROM should be visible at
> startup of the B32
> > part.
> > >
> > > What does your copy code look like and what are
> you using to
> > generate it?
> > >
> > > Dave
> > >
> > >
> > > Dave Perreault wrote:
> > >
> > > > I would guess that the additional copy code
> generates enough delay
> > that
> > > > you are not getting to your code which
> disables the COP. In BDM
> > mode the
> > > > COP starts up disabled.
> > > >
> > > > Dave
> > > >
> > > >
> > > > drranu wrote:
> > > >
> > > > > Hey. Is there an initialization sequence
> necessary to be able to
> > read
> > > > > EEPROM (byte-erasable) on reset? Here's my
> situation:
> > > > >
> > > > > MC68HC912B32 microcontroller.
> > > > >
> > > > > 1. The first line of my program clears
> COPCTL.
> > > > > 2. The next several lines copy bytes from
> EEPROM (starting at
> > $0D00)
> > > > > into RAM (starting at $0800).
> > > > > 3. The program is located in flash EEPROM
> at $8000
> > > > > 4. The reset vector at $FFFE is pointed to
> $8000.
> > > > > 5. On power-on the program does not work.
> > > > > 6. Through the BDM when I specify that the
> program starting at
> > $8000
> > > > > should run, it does so fine.
> > > > > 7. However when not in BDM, on power on or
> external reset, the
> > > > > program does not run.
> > > > > 8. If I remove the lines that copy data
> from EEPROM (byte-erasable)
> > > > > to RAM and reflash the EEPROM, the program
> runs fine on power on and
> > > > > when reset externally with and without the
> BDM.
> > > > >
> > > > > Thus, it seems that I am missing some kind
> of init routine to make
> > > > > $0D00-$0FFF readable. Any ideas?
> > > > >
> >
> >
> >
> >
> >
> > SPONSORED LINKS
> > Pic microcontrollers
> >
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Pic+microcontrollers&w2=Intel+microprocessors&w385+microprocessor&c=3&sx&.sig=trd8G9Fjoj7JJ3faqzNL9w> >
> > Intel microprocessors
> >
> <http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Pic+microcontrollers&w2=Intel+microprocessors&w385+microprocessor&c=3&sx&.sig=K9F-qweX-SR3HNRrl-g3yw> >
> > 8085 microprocessor
> >
> <http://groups.yahoo.com/gads?t=ms&k85+microprocessor&w1=Pic+microcontrollers&w2=Intel+microprocessors&w385+microprocessor&c=3&sx&.sig=Gy6INN6xGz43y8XfYFnyxw> >
> >
> >
> >
> >
>
> > >.
> >
> >
> >
>
>
> [Non-text portions of this message have been
> removed]
__________________________________
Reply by E E●August 3, 20052005-08-03
Jeffereson, thanks for your reply. On your suggestion
I tried doing that as well as properly resetting the
COP in the program at the right intervals to no avail.
Hmm...
--- Jefferson Smith <imajeffs@imaj...> wrote:
> --- In 68HC12@68HC..., "drranu"
> <drranu@y...> wrote:
> > Hey Dave, thanks a lot for the reply. The very
> first thing the code
> > does is shut down COP though. And when I remove
> the copy routine from
> > the code, it works fine outside of BDM.
> >
>
> I had this problem. I found the solution is to reset
> the COP just
> before disabling it (mine is MC68HC912BC32, but
> probably the same with
> COP).
> --jeffs
>
Reply by Dr. David A. Perreault●August 3, 20052005-08-03
If this is all you have, where did you setup the stack pointer?
Dave
drranu wrote:
> Dave, actually I have a simpler case. I set the
reset vector to point
> to $8000. From here, the code shuts off the COP watchdog and then
> jumps to $0FFA in EEPROM which just jumps to $8100 which then runs
> sime very simple code to continuously output an 'e' on the SPI
port
> (which goes to a RS-232 level converter for a serial port). Again,
> unless the BDM is on, it won't work. Here's the code:
>
> org $8000
> clr COPCTL
> jmp $0FFA
>
> org $8100
> clr SC0CR1
> movw #$000C,SC0CR1
> ldaa SC0SR1
> ldab #$65
> LOOP:
> jsr PUT_CHAR
> bra LOOP
>
> PUT_CHAR:
> brclr SC0SR1,#$80,PUT_CHAR
> stab SC0DRL
> rts
>
> Okay, now at $0FFA there is just
> ldy #$8100
> jmp 0,Y
>
> And that's all. It will not run on power on or external reset
without
> the BDM connected and on (controlled from a host proc). Thanks for
> any help. All of my programs to date (3 years worth) have run fine
> until I started accessing the EEPROM. Thanks for any help. I really
> appreciate your time.
>
> --- In 68HC12@68HC..., Dave Perreault <dap@p...> wrote:
> > Both the RAM and the EEPROM should be visible at startup of the B32
> part.
> >
> > What does your copy code look like and what are you using to
> generate it?
> >
> > Dave
> >
> >
> > Dave Perreault wrote:
> >
> > > I would guess that the additional copy code generates enough
delay
> that
> > > you are not getting to your code which disables the COP. In
BDM
> mode the
> > > COP starts up disabled.
> > >
> > > Dave
> > >
> > >
> > > drranu wrote:
> > >
> > > > Hey. Is there an initialization sequence necessary to be
able to
> read
> > > > EEPROM (byte-erasable) on reset? Here's my
situation:
> > > >
> > > > MC68HC912B32 microcontroller.
> > > >
> > > > 1. The first line of my program clears COPCTL.
> > > > 2. The next several lines copy bytes from EEPROM (starting
at
> $0D00)
> > > > into RAM (starting at $0800).
> > > > 3. The program is located in flash EEPROM at $8000
> > > > 4. The reset vector at $FFFE is pointed to $8000.
> > > > 5. On power-on the program does not work.
> > > > 6. Through the BDM when I specify that the program starting
at
> $8000
> > > > should run, it does so fine.
> > > > 7. However when not in BDM, on power on or external reset,
the
> > > > program does not run.
> > > > 8. If I remove the lines that copy data from EEPROM
(byte-erasable)
> > > > to RAM and reflash the EEPROM, the program runs fine on
power on and
> > > > when reset externally with and without the BDM.
> > > >
> > > > Thus, it seems that I am missing some kind of init routine
to make
> > > > $0D00-$0FFF readable. Any ideas?
> > >
> SPONSORED LINKS
> Pic microcontrollers
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Pic+microcontrollers&w2=Intel+microprocessors&w385+microprocessor&c=3&sx&.sig=trd8G9Fjoj7JJ3faqzNL9w>
> Intel microprocessors
>
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Pic+microcontrollers&w2=Intel+microprocessors&w385+microprocessor&c=3&sx&.sig=K9F-qweX-SR3HNRrl-g3yw>
> 8085 microprocessor
>
<http://groups.yahoo.com/gads?t=ms&k85+microprocessor&w1=Pic+microcontrollers&w2=Intel+microprocessors&w385+microprocessor&c=3&sx&.sig=Gy6INN6xGz43y8XfYFnyxw
>
>
> >.
>
>
Reply by drranu●August 2, 20052005-08-02
Dave, actually I have a simpler case. I set the reset vector to point
to $8000. From here, the code shuts off the COP watchdog and then
jumps to $0FFA in EEPROM which just jumps to $8100 which then runs
sime very simple code to continuously output an 'e' on the SPI port
(which goes to a RS-232 level converter for a serial port). Again,
unless the BDM is on, it won't work. Here's the code:
Okay, now at $0FFA there is just
ldy #$8100
jmp 0,Y
And that's all. It will not run on power on or external reset without
the BDM connected and on (controlled from a host proc). Thanks for
any help. All of my programs to date (3 years worth) have run fine
until I started accessing the EEPROM. Thanks for any help. I really
appreciate your time.
--- In 68HC12@68HC..., Dave Perreault <dap@p...> wrote: > Both the RAM and the EEPROM should be visible at
startup of the B32 part. >
> What does your copy code look like and what are you using to generate it? >
> Dave
> Dave Perreault wrote:
>
> > I would guess that the additional copy code generates enough delay that > > you are not getting to your code which
disables the COP. In BDM mode the > > COP starts up disabled.
> >
> > Dave
> >
> >
> > drranu wrote:
> >
> > > Hey. Is there an initialization sequence necessary to be able
to read > > > EEPROM (byte-erasable) on reset?
Here's my situation:
> > >
> > > MC68HC912B32 microcontroller.
> > >
> > > 1. The first line of my program clears COPCTL.
> > > 2. The next several lines copy bytes from EEPROM (starting at $0D00) > > > into RAM (starting at $0800).
> > > 3. The program is located in flash EEPROM at $8000
> > > 4. The reset vector at $FFFE is pointed to $8000.
> > > 5. On power-on the program does not work.
> > > 6. Through the BDM when I specify that the program starting at $8000 > > > should run, it does so fine.
> > > 7. However when not in BDM, on power on or external reset, the
> > > program does not run.
> > > 8. If I remove the lines that copy data from EEPROM
(byte-erasable)
> > > to RAM and reflash the EEPROM, the program runs fine on power on
and
> > > when reset externally with and without the BDM.
> > >
> > > Thus, it seems that I am missing some kind of init routine to
make
> > > $0D00-$0FFF readable. Any ideas?
> > >
Reply by Jefferson Smith●August 2, 20052005-08-02
--- In 68HC12@68HC..., "drranu" <drranu@y...> wrote: > Hey Dave, thanks a lot for the reply. The very
first thing the code
> does is shut down COP though. And when I remove the copy routine from
> the code, it works fine outside of BDM.
>
I had this problem. I found the solution is to reset the COP just
before disabling it (mine is MC68HC912BC32, but probably the same with
COP).
--jeffs