Reply by Jefferson Smith 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



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.

__________________________________________________




Reply by E E August 3, 20052005-08-03
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:

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?
> > >



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