68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC

Hi all,

I am working with 9S12D64 with TwinPEEKS monitor at 0xF000. The
application resides at 0x8000:0xBFFF. At some point in the
application we want to go to the monitor to load a new version of the
program.
COP is running at 1 Sec.
How do I get a reset to happen (to turn off the COP) and then get to
the monitor at 0xF000?

I turn off all of the timer interrupts, serial interrupts and clear
the status registers for serial and timers. Then I wait for the COP
to give me a reset which gets me to the monitor... supposedly. What
happens is nothing until I press the reset button on the board.
The goal is to have the user choose the option and then it would jump
to the monitor with no further intervention.
Plug in the serial port,
push a front panel button,
get through the menus to the load request,
select load request,
see the monitor notice,
do the eeprom/flash clear,
and start loading S19 file.

Opening the box to press the reset button is not good.

I get to the "select the load request" and it goes off into la-la
land. If I hit the hardware reset button, I get the monitor notice.

With ICC, NoICE and ComPOD12 I am told that a reset has occurred, but
with NoICE running, I see the monitor notice. Without NoICE, the
serial output is .... nothing. Nothing in and nothing out.

So, how do I get the CPU to do a nice little hard reset and go into
the monitor like a nice little CPU and transmit the monitor notice to me?

Two days on this one idea with MANY variations and nothing good
happens. I need some help.

wade



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Hi,
My idea: place a small resistor (1K) between your reset circuit and
the reset pin of your micro.
Regards,
Ioan

WadeA & RebeccaM Smith wrote:
>
> Hi all,
>
> I am working with 9S12D64 with TwinPEEKS monitor at 0xF000. The
> application resides at 0x8000:0xBFFF. At some point in the
> application we want to go to the monitor to load a new version of the
> program.
> COP is running at 1 Sec.
> How do I get a reset to happen (to turn off the COP) and then get to
> the monitor at 0xF000?
>
> I turn off all of the timer interrupts, serial interrupts and clear
> the status registers for serial and timers. Then I wait for the COP
> to give me a reset which gets me to the monitor... supposedly. What
> happens is nothing until I press the reset button on the board.
> The goal is to have the user choose the option and then it would jump
> to the monitor with no further intervention.
> Plug in the serial port,
> push a front panel button,
> get through the menus to the load request,
> select load request,
> see the monitor notice,
> do the eeprom/flash clear,
> and start loading S19 file.
>
> Opening the box to press the reset button is not good.
>
> I get to the "select the load request" and it goes off into la-la
> land. If I hit the hardware reset button, I get the monitor notice.
>
> With ICC, NoICE and ComPOD12 I am told that a reset has occurred, but
> with NoICE running, I see the monitor notice. Without NoICE, the
> serial output is .... nothing. Nothing in and nothing out.
>
> So, how do I get the CPU to do a nice little hard reset and go into
> the monitor like a nice little CPU and transmit the monitor notice to me?
>
> Two days on this one idea with MANY variations and nothing good
> happens. I need some help.
>
> wade
>
>



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Is TwinPEEKs sort of consuming COP reset vector or does it just point COP
vector into user jump table? If second, then do you have COP entry in jump
table pointing to monitor?

Also, is TwinPEEKs configured to jump to user software by default,
autostart? If so then you should do something to prevent autostart on COP
reset, you want TwinPEEKs to run, right?

Edward

----- Original Message -----
From: "WadeA & RebeccaM Smith"
To: <6...@yahoogroups.com>
Sent: Friday, March 07, 2008 1:44 AM
Subject: [68HC12] D64 reset
> Hi all,
>
> I am working with 9S12D64 with TwinPEEKS monitor at 0xF000. The
> application resides at 0x8000:0xBFFF. At some point in the
> application we want to go to the monitor to load a new version of the
> program.
> COP is running at 1 Sec.
> How do I get a reset to happen (to turn off the COP) and then get to
> the monitor at 0xF000?
>
> I turn off all of the timer interrupts, serial interrupts and clear
> the status registers for serial and timers. Then I wait for the COP
> to give me a reset which gets me to the monitor... supposedly. What
> happens is nothing until I press the reset button on the board.
> The goal is to have the user choose the option and then it would jump
> to the monitor with no further intervention.
> Plug in the serial port,
> push a front panel button,
> get through the menus to the load request,
> select load request,
> see the monitor notice,
> do the eeprom/flash clear,
> and start loading S19 file.
>
> Opening the box to press the reset button is not good.
>
> I get to the "select the load request" and it goes off into la-la
> land. If I hit the hardware reset button, I get the monitor notice.
>
> With ICC, NoICE and ComPOD12 I am told that a reset has occurred, but
> with NoICE running, I see the monitor notice. Without NoICE, the
> serial output is .... nothing. Nothing in and nothing out.
>
> So, how do I get the CPU to do a nice little hard reset and go into
> the monitor like a nice little CPU and transmit the monitor notice to me?
>
> Two days on this one idea with MANY variations and nothing good
> happens. I need some help.
>
> wade



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

TwinPEEKS reset vectors jump to a RAM vector location. The vector
table is a series of JMP ???? instructions. So COP jumps to 0x3FFA
which has 0x06 0xF0 0x00 (JMP $F000) Normally, COP jumps to a single
"RTI" instruction.

Yes, TwinPEEKS defaults to user software, but we've added code to
check a location in EEPROM. $FF means go to monitor (no program
loaded) otherwise jump to 0x8000.

My code for "Select Load request" does the following:

pet the puppy (reset COP timeout with 9x55, 0xAA)
clear serial interrpts
clear serial status/data registers
clear timer interrupts (T0TIE = 0;)
clear timer status register(dummy = T0TFLG;)
set COP RAM vector to 0xF000
erase EEPROM BootUpSw to 0xFF
delay 1.6 seconds
and if that delay doesn't do it "JMP 61440"

Once the CPU goes into la-la land, if I press the reset button, it
goes straight to TwinPEEKS. But before I press the reset button, it
just stays hung up and not responding to serial ports and not
transmitting either. (TwinPEEKS BAUD rate is 19200 and that is was we
keep it at too.)

So how do I make it really reset?

wade

--- In 6...@yahoogroups.com, "Edward Karpicz" wrote:
>
> Is TwinPEEKs sort of consuming COP reset vector or does it just
point COP
> vector into user jump table? If second, then do you have COP entry
in jump
> table pointing to monitor?
>
> Also, is TwinPEEKs configured to jump to user software by default,
> autostart? If so then you should do something to prevent autostart
on COP
> reset, you want TwinPEEKs to run, right?
>
> Edward
>
> ----- Original Message -----
> From: "WadeA & RebeccaM Smith"
> To: <6...@yahoogroups.com>
> Sent: Friday, March 07, 2008 1:44 AM
> Subject: [68HC12] D64 reset



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Wade wrote:

> TwinPEEKS reset vectors jump to a RAM vector location. The vector
> table is a series of JMP ???? instructions. So COP jumps to 0x3FFA
> which has 0x06 0xF0 0x00 (JMP $F000) Normally, COP jumps to a single
> "RTI" instruction.
>

There are three reset vectors, main, COP and CME. I'm talking about real
reset vectors at $FFxx. I think that main vector points into TwinPEEKs code
were some initializations like stack pointer, INITRM etc are done, then
TwinPEEKs checks if some pins are shorted, and if they are then it jumps to
users software. There must be such a feature, I remember something like that
in card.912DG128A. Looks like you aren't using autostart?

Anyway, you say that RAM vectors (jump table) are at 0x3Fxx. But out of
reset D64 has its RAM at 0-0xFFF, not at 0x3000-0x3FFF. So if COP and CME
reset vectors really do point to 0x3Fxx, then you have no way to using COP
and CME resets properly, because D64 INITRM is reset to 0 on reset.
COP vector should point either to 0x0FFA, or into TwinPEEKs COP reset
handler, where TwinPEEKs inits INITRM and jumps to 0x3FFA. If COP vector
points to 0x3FFA, then its a TwinPEEKs's bug.

If COP vector points to 0x0FFA, then you init 0x3FFA with 0x6,0xF0,0x0 as
before, because INITRM is setup to make RAM mapped to 3F00.
When CPU resets it will see these 3 bytes at 0x0FFA and jump to TwinPEEKs.
Hope it's clear.
> Yes, TwinPEEKS defaults to user software, but we've added code to
> check a location in EEPROM. $FF means go to monitor (no program
> loaded) otherwise jump to 0x8000.
>
> My code for "Select Load request" does the following:
>
> pet the puppy (reset COP timeout with 9x55, 0xAA)
> clear serial interrpts
> clear serial status/data registers
> clear timer interrupts (T0TIE = 0;)

Hm, weird register name. Is it from something like 3 timers equipped S12E?

> clear timer status register(dummy = T0TFLG;)
> set COP RAM vector to 0xF000
> erase EEPROM BootUpSw to 0xFF
> delay 1.6 seconds

Alternatively to long delay you can write something not equal to 0x55 and
0xAA to ARMCOP. COP should reset immediately.

BTW is COP really enabled? Please make sure that COPCTL register wasn't
written more than once, one time to disable COP, another time to enable COP.
In normal single chip mode COPCTL is write once register. Since it's write
once only in normal mode, BDM debugger isn't your friend verifying if COP is
really enabled. You should send contents of COPCTL over SCI or show it on
some pins.

> and if that delay doesn't do it "JMP 61440"

Jump can work too, if you know TwinPEEKs doesn't do something fancy with
stack pointer and INITRM. I would loop here forever.

>
> Once the CPU goes into la-la land, if I press the reset button, it
> goes straight to TwinPEEKS. But before I press the reset button, it
> just stays hung up and not responding to serial ports and not
> transmitting either. (TwinPEEKS BAUD rate is 19200 and that is was we
> keep it at too.)
>
> So how do I make it really reset?

I'm not sure yet.

Edward

>
> wade
>
> --- In 6...@yahoogroups.com, "Edward Karpicz" wrote:
>>
>> Is TwinPEEKs sort of consuming COP reset vector or does it just
> point COP
>> vector into user jump table? If second, then do you have COP entry
> in jump
>> table pointing to monitor?
>>
>> Also, is TwinPEEKs configured to jump to user software by default,
>> autostart? If so then you should do something to prevent autostart
> on COP
>> reset, you want TwinPEEKs to run, right?
>>
>> Edward
>>
>> ----- Original Message -----
>> From: "WadeA & RebeccaM Smith"
>> To: <6...@yahoogroups.com>
>> Sent: Friday, March 07, 2008 1:44 AM
>> Subject: [68HC12] D64 reset



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "Edward Karpicz" wrote:
>
> Wade wrote:
>
> > TwinPEEKS reset vectors jump to a RAM vector location. The vector
> > table is a series of JMP ???? instructions. So COP jumps to 0x3FFA
> > which has 0x06 0xF0 0x00 (JMP $F000) Normally, COP jumps to a single
> > "RTI" instruction.
> > There are three reset vectors, main, COP and CME. I'm talking about
real
> reset vectors at $FFxx. I think that main vector points into
TwinPEEKs code
> were some initializations like stack pointer, INITRM etc are done, then
> TwinPEEKs checks if some pins are shorted, and if they are then it
jumps to
> users software. There must be such a feature, I remember something
like that
> in card.912DG128A. Looks like you aren't using autostart?
>
> Anyway, you say that RAM vectors (jump table) are at 0x3Fxx. But out of
> reset D64 has its RAM at 0-0xFFF, not at 0x3000-0x3FFF. So if COP
and CME
> reset vectors really do point to 0x3Fxx, then you have no way to
using COP
> and CME resets properly, because D64 INITRM is reset to 0 on reset.
> COP vector should point either to 0x0FFA, or into TwinPEEKs COP reset
> handler, where TwinPEEKs inits INITRM and jumps to 0x3FFA. If COP
vector
> points to 0x3FFA, then its a TwinPEEKs's bug.
>
> If COP vector points to 0x0FFA, then you init 0x3FFA with
0x6,0xF0,0x0 as
> before, because INITRM is setup to make RAM mapped to 3F00.
> When CPU resets it will see these 3 bytes at 0x0FFA and jump to
TwinPEEKs.
> Hope it's clear.

first 3 instructions in TwinPEEKS is to set IOReg=0x00 EEPROM=0x01 amd
RAM=$30 (0x3000:0x3FFF)
Then RAM is cleared for the RAM vectors

Autostart is there but modified for our personal preferences.

>From tp2_main.lst:
FFFA : 3F FA <--- COP JMP $F000
FFFC : 3F FD
FFFE : F0 00

>
> > Yes, TwinPEEKS defaults to user software, but we've added code to
> > check a location in EEPROM. $FF means go to monitor (no program
> > loaded) otherwise jump to 0x8000.
> >
> > My code for "Select Load request" does the following:
> >
> > pet the puppy (reset COP timeout with 9x55, 0xAA)
> > clear serial interrpts
> > clear serial status/data registers
> > clear timer interrupts (T0TIE = 0;)
>
> Hm, weird register name. Is it from something like 3 timers equipped
S12E?

I am guessing that they set the names such that they can add a second
timer set and not change the name of the ones at the current location.
The name comes from ICC12v7, so blame Richard (of course, he will
blame Freescale documentation). I imagine that T1 module would be
named T1TIE for Timer 1 Timer Interrupt Enable Register.

> > clear timer status register(dummy = T0TFLG;)
> > set COP RAM vector to 0xF000
> > erase EEPROM BootUpSw to 0xFF
> > delay 1.6 seconds
>
> Alternatively to long delay you can write something not equal to
0x55 and
> 0xAA to ARMCOP. COP should reset immediately.

GREAT! I'll try that on Monday (overtime scheduling problems keep me
from playing with it until then).

> BTW is COP really enabled? Please make sure that COPCTL register wasn't
> written more than once, one time to disable COP, another time to
enable COP.
> In normal single chip mode COPCTL is write once register. Since it's
write
> once only in normal mode, BDM debugger isn't your friend verifying
if COP is
> really enabled. You should send contents of COPCTL over SCI or show
it on
> some pins.

COPCTL written to only once at the start of our user program. It is
set to the max value to get 1 second (but on the Oscope we have seen
480ms trigger it, so we may not have the timing set just right to get
the full 1 Second).

Before I put in the EEPROM autostart inhibit byte, I had a jump to the
monitor (just after autostart) working, but within a second the COP
would kick me back to the autostart and right back to the application.
I tried turning off COPCTL, but since that can only be written once,
it ignored me and went through a reset anyway.

Oh yes, COP is ON -- and causing a headache.
> > and if that delay doesn't do it "JMP 61440"
>
> Jump can work too, if you know TwinPEEKs doesn't do something fancy
with
> stack pointer and INITRM. I would loop here forever.
>
> >
> > Once the CPU goes into la-la land, if I press the reset button, it
> > goes straight to TwinPEEKS. But before I press the reset button, it
> > just stays hung up and not responding to serial ports and not
> > transmitting either. (TwinPEEKS BAUD rate is 19200 and that is was we
> > keep it at too.)
> >
> > So how do I make it really reset?
>
> I'm not sure yet.
>
> Edward

Thanks for the ARMCOP (0x003F) suggestion. That's more than I've come
up with.

wade



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

See below.

Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Dept (417)836-5131
SPRINGFIELD, MO 65897 USA

How much wood would a woodchuck chuck if a woodchuck could chuck wood?
How much ground would a groundhog hog if a groundhog could hog ground?
How much pig would a whistlepig whistle if a whistlepig could whistle
pig? :-\ :-/ :-)

> -----Original Message-----
> From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com]
> On Behalf Of WadeA & RebeccaM Smith
> Sent: Friday, March 07, 2008 11:20 AM
> To: 6...@yahoogroups.com
> Subject: [68HC12] Re: D64 reset
>
> --- In 6...@yahoogroups.com, "Edward Karpicz" wrote:
> >
> > Wade wrote:
> >
> > > TwinPEEKS reset vectors jump to a RAM vector location. The vector
> > > table is a series of JMP ???? instructions. So COP jumps
> to 0x3FFA
> > > which has 0x06 0xF0 0x00 (JMP $F000) Normally, COP jumps
> to a single
> > > "RTI" instruction.
> > >
> >
> > There are three reset vectors, main, COP and CME. I'm talking about
> real
> > reset vectors at $FFxx. I think that main vector points into
> TwinPEEKs code
> > were some initializations like stack pointer, INITRM etc
> are done, then
> > TwinPEEKs checks if some pins are shorted, and if they are then it
> jumps to
> > users software. There must be such a feature, I remember something
> like that
> > in card.912DG128A. Looks like you aren't using autostart?
> >
> > Anyway, you say that RAM vectors (jump table) are at
> 0x3Fxx. But out of
> > reset D64 has its RAM at 0-0xFFF, not at 0x3000-0x3FFF. So if COP
> and CME
> > reset vectors really do point to 0x3Fxx, then you have no way to
> using COP
> > and CME resets properly, because D64 INITRM is reset to 0 on reset.
> > COP vector should point either to 0x0FFA, or into TwinPEEKs
> COP reset
> > handler, where TwinPEEKs inits INITRM and jumps to 0x3FFA. If COP
> vector
> > points to 0x3FFA, then its a TwinPEEKs's bug.
> >
> > If COP vector points to 0x0FFA, then you init 0x3FFA with
> 0x6,0xF0,0x0 as
> > before, because INITRM is setup to make RAM mapped to 3F00.
> > When CPU resets it will see these 3 bytes at 0x0FFA and jump to
> TwinPEEKs.
> > Hope it's clear.
>
> first 3 instructions in TwinPEEKS is to set IOReg=0x00 EEPROM=0x01 amd
> RAM=$30 (0x3000:0x3FFF)
> Then RAM is cleared for the RAM vectors
>
> Autostart is there but modified for our personal preferences.
>
> From tp2_main.lst:
> FFFA : 3F FA <--- COP JMP $F000
> FFFC : 3F FD
> FFFE : F0 00
>


But with the discussion above about reset clearing INITRM, shouldn't
your vector table look like:

FFFA : 0F FA <--- COP JMP $F000
FFFC : 0F FD
FFFE : F0 00

So maybe TwinPEEKs has a bug in this respect. Since it appears that the
vector table needs to change, I'd probably go for:

FFFA : F0 00 ;Cut out the RAM middle man.
FFFC : F0 00 ;Ditto
FFFE : F0 00

HTH

Emmett
>
> wade
>



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )