Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
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
Sponsor
Ads
Discussion Groups
See Also
Discussion Groups | 68HC12 | Re: D64 COP: the saga continues
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
Re: D64 COP: the saga continues - WadeA & RebeccaM Smith - Mar 26 5:00:23 2008
--- In 6...@yahoogroups.com, Rob Milne wrote:
>
> If TwinPeeks torches the virtual vector table on reset I'd say it isn't
> worth much as a testing platform for a real world project. A COP reset
> should restart your program. Placing virtual reset vectors in RAM is a
> pretty bad idea when you consider the damage that writing to a stray
> pointer can do. If the virtual table is in flash a stray pointer write
> can't corrupt it and thus prevent COP from doing its job.
Well, actually, it works out GREAT in production for programs that we
load into flash without having to hook up a BDM, especially for techs
out in the field. Since the vectors are in RAM, we set them up as
part of our application startup and it works great. ... Until you try
to force an action like a HARDWARE reset which is not happening.
Since the memory doesn't get trashed unless the program is toast and
therefore not ready for deployment (I are the only one programming, so
I aint gonna mess with myself), we have had no problems and we are
very happy with the TwinPeeks setup.
If we could make the COP produce a HARDWARE reset, then the registers
at 10,11,12 could be set up, COP would be off (until our application
starts up) and life would be good....
> Petting the dog is a two step process. Consult the CRG portion of the
> D64 docs.
Yep, we been pettin' th' puppy for a while now, but the monior does
NOT (because that's supposedly after a HARDWARE reset when COP has
been reset to 0x00), and then there's the funnly little time out that
is happening when we don't have the LCD hooked up. Now if I could
catch WHERE the COP timeout is happening during the LCD start up code,
that would take care of that.
> Resets via software can be accomplished via a swi interrupt. Usually
> this interrupt is used by RTOS schedulers to leverage the register
> storage mechanism for context switching.
Actually, that is ONLY an interrupt and the register context is saved
on the stack like all the other interrupts. What I need is a HARDWARE
reset that will reset everything back to powerup conditions.
All we have for RESET on the Hardware is a button going to ground.
The EE REFUSES to hook a port to the reset button so that I can
command the bit to reset the processor. I'd call him names implying
fearfulness, but then I'd be in deep trouble and probably show my
ignernts in things EE-realted.
> -rob
>
> WadeA & RebeccaM Smith wrote:
> >
> >
> > It looks like I NEED a REAL hardware reset for the COP to go to.
> >
> > I added a standard 2x16 LCD. In the init code it checks the "busy
> > flag" (read Status is 0x80) and waits there until it goes away.
> > Everything works wonderfully UNTIL you do not plug in the LCD. Now
> > the processor goes off into la-la land.
> >
> > According to NoICE, the system jumps to COP vector, which is the same
> > address that is stored at 0xFFFE, which is 0xF000, which is the start
> > of the TwinPeeks monitor. Now that it is in the monitor, it stays
> > there forever resetting into whereever (one of the first things the
> > monitor does is to clear the soft reset vectors at 3f40-3fff so that
> > the next hit of the COP goes to whereever BGND takes it.
> >
> > I put in some code to check for waiting too long at the
> > waitForBusyFlagToQu it code. I also put in code to "petThePuppy" and
> > STILL it insists on COPping out.
> >
> > Suggestions?
> >
> > How do I get a real hardware reset to happen through software?
> >
> > wade
> >
>
------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>
> If TwinPeeks torches the virtual vector table on reset I'd say it isn't
> worth much as a testing platform for a real world project. A COP reset
> should restart your program. Placing virtual reset vectors in RAM is a
> pretty bad idea when you consider the damage that writing to a stray
> pointer can do. If the virtual table is in flash a stray pointer write
> can't corrupt it and thus prevent COP from doing its job.
Well, actually, it works out GREAT in production for programs that we
load into flash without having to hook up a BDM, especially for techs
out in the field. Since the vectors are in RAM, we set them up as
part of our application startup and it works great. ... Until you try
to force an action like a HARDWARE reset which is not happening.
Since the memory doesn't get trashed unless the program is toast and
therefore not ready for deployment (I are the only one programming, so
I aint gonna mess with myself), we have had no problems and we are
very happy with the TwinPeeks setup.
If we could make the COP produce a HARDWARE reset, then the registers
at 10,11,12 could be set up, COP would be off (until our application
starts up) and life would be good....
> Petting the dog is a two step process. Consult the CRG portion of the
> D64 docs.
Yep, we been pettin' th' puppy for a while now, but the monior does
NOT (because that's supposedly after a HARDWARE reset when COP has
been reset to 0x00), and then there's the funnly little time out that
is happening when we don't have the LCD hooked up. Now if I could
catch WHERE the COP timeout is happening during the LCD start up code,
that would take care of that.
> Resets via software can be accomplished via a swi interrupt. Usually
> this interrupt is used by RTOS schedulers to leverage the register
> storage mechanism for context switching.
Actually, that is ONLY an interrupt and the register context is saved
on the stack like all the other interrupts. What I need is a HARDWARE
reset that will reset everything back to powerup conditions.
All we have for RESET on the Hardware is a button going to ground.
The EE REFUSES to hook a port to the reset button so that I can
command the bit to reset the processor. I'd call him names implying
fearfulness, but then I'd be in deep trouble and probably show my
ignernts in things EE-realted.
> -rob
>
> WadeA & RebeccaM Smith wrote:
> >
> >
> > It looks like I NEED a REAL hardware reset for the COP to go to.
> >
> > I added a standard 2x16 LCD. In the init code it checks the "busy
> > flag" (read Status is 0x80) and waits there until it goes away.
> > Everything works wonderfully UNTIL you do not plug in the LCD. Now
> > the processor goes off into la-la land.
> >
> > According to NoICE, the system jumps to COP vector, which is the same
> > address that is stored at 0xFFFE, which is 0xF000, which is the start
> > of the TwinPeeks monitor. Now that it is in the monitor, it stays
> > there forever resetting into whereever (one of the first things the
> > monitor does is to clear the soft reset vectors at 3f40-3fff so that
> > the next hit of the COP goes to whereever BGND takes it.
> >
> > I put in some code to check for waiting too long at the
> > waitForBusyFlagToQu it code. I also put in code to "petThePuppy" and
> > STILL it insists on COPping out.
> >
> > Suggestions?
> >
> > How do I get a real hardware reset to happen through software?
> >
> > wade
> >
>
------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )