Reply by varneybob ●January 6, 20032003-01-06
I HAVE SOLVED THE BUG! Man that was a doosey. On my next project I'll
make sure I get an ICE however, as it would be better to have the
option to use it then to not even have the option.

Anyway, the bug was that the addresses in my Interrupt Vector Table
(except for the Startup address) were all pointing into a paged area
of Flash. Most of my code executed out of a single page of Flash, so
early in development my PPAGE register was always set right when
interrupts occurred, however as soon as the code grew to 2 pages,
then I started experiencing the bug. Periodically, I'd be in
the "wrong" page for where the ISR was stored, and blam, the code
would be off in the weeds.

Once I saw that my IVT was wrong it was a simple matter to ensure
that all my ISRs were stored in non-paged Flash. --- In , Doron Fael <doronf@n...> wrote:
> Bob,
>
> Full featured emulator can work both "stand alone", or plugged into
a
> target board.
>
> Unlike BDMs, the full emulator has its own emulation RAM and HC12
CPU, and
> it thus can function in stand alone configuration.
>
> When plugged into a target, it replaces the HC12 CPU on the target.
It has
> special QFP solder-down adapter that is soldered down to the CPU
footprint
> on the target. For targets with mechanical constraints high speed
> flex-cable is also available, allowing minimum clearance and
escaping from
> the target at any of 4 directions.
>
> The trace and triggers which I mentioned in a previous email are
the
> biggest but not the only advantage of a full featured emulator in
compare
> with a BDM emulator.
>
> A full featured emulator also has the following main advantages
over a BDM:
> 1. The emulation RAM allows loading the code simply into RAM
instead of
> having to program the internal HC12 flash every time the code is
> recompiled. Programming the internal flash is also allowed, but is
usually
> used only in late stages of the design.
> 2. An unlimited number of software and hardware breakpoints is
available,
> in compare with 2 only on a BDM when executing from Flash.
> 3. Debugging and testing of going through Reset (external and
internal),
> STOP and WAIT power down modes, Limp-Home Self-Clock mode are
possible and
> extensively supported, as oppose to BDMs that either entirely not
> supporting operation through these modes, or are allowing execution
through
> only few of these modes, and in a limited way.
> 4. Speed changes, including frequent ones is supported (to allow
operation
> with PLL and clock manipulation for power consumption purposes for
> example), unlike BDMs that don't allow this or are very limited.
> 5. A shadow memory which is entirely non-intrusive allows observing
changes
> to memory while running, as oppose to BDM which allows this only
intrusively.
>
> Hope this helps,
>
> Doron
> Nohau Corporation
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> At 12:16 PM 1/6/2003 +0000, you wrote:
> >Doron,
> >
> >Do the Nohau emulators need a board to plug into? Or do the Nohau
> >emulators come with an "eval board" of sorts? I do not have
> >socketed MCU, so I would need an emulator that was standalone.
> >
> >Thanks.
> >
> >--- In , Doron Fael <doronf@n...> wrote:
> > > Bob,
> > >
> > > This is the sort of problems that are very easy to find and
> >resolve using a
> > > full-featured emulator.
> > > In such full featured emulator, you simply set a trace trigger
on
> >a random
> > > value write to the PPAGE register, and once the trigger occur,
> >look in the
> > > trace to see what code was executed and lead to the PPAGE
> >overwrite.
> > >
> > > Nohau and a few other vendors carry such full-featured emulator
> >systems for
> > > the HC12 and HCS12 (STAR12). Enable Engineering (joe@e...) is a
> > > Nohau rep. company, and will also rent these full-featured
> >emulators.
> > >
> > > Doron
> > > Nohau Corporation
> > > HC12 In-Circuit Emulators
> > > www.nohau.com/emul12pc.html
> > >
> > > >Okay, I have roughly 4000 lines of C++ code developed in
> >Metrowerks
> > > >CodeWarrior for the STAR12. The code seems to work fine for the
> >most
> > > >part as long as my serial port debug messages are active. My
> >serial
> > > >debug messages are polled out and not interrupt driven. As
soon
> >as
> > > >I recompile the source with the debug messages removed the code
> > > >eventually has a symptom where the PPAGE register changes to
what
> > > >seems to be a pseudo-random value and then my code crashes. I
am
> > > >running a banked Flash application, so having the PPAGE
register
> > > >switch to a non-sensical value is disastrous.
> > > >
> > > >Can anyone provide any help, suggestions, or links to errata
that
> > > >would explain why my code would work with debug stmts in, and
> >crash
> > > >when the only thing changed is taking the debug statements out?
> > > >
> > > >Also, when I switch my serial port debug messages to 8-bit port
> > > >write values that a logic analyzer can pick up, I crash as
well.
> > > >Obviously the time it takes for serial messages to go out over
the
> > > >RS-232 is much much longer than the 3 bus cycles it takes to
write
> > > >to a port. This points somewhat to timing, but I'm not sure
where
> > > >to look, or what debug tactic to try next. I'm starting to
wonder
> > > >if I've uncovered an MCU hardware bug.
> > > >
> > > >All help would be appreciated.
> > > >




Reply by Doron Fael ●January 6, 20032003-01-06
Bob,

Full featured emulator can work both "stand alone", or plugged into a
target board.

Unlike BDMs, the full emulator has its own emulation RAM and HC12 CPU, and
it thus can function in stand alone configuration.

When plugged into a target, it replaces the HC12 CPU on the target. It has
special QFP solder-down adapter that is soldered down to the CPU footprint
on the target. For targets with mechanical constraints high speed
flex-cable is also available, allowing minimum clearance and escaping from
the target at any of 4 directions.

The trace and triggers which I mentioned in a previous email are the
biggest but not the only advantage of a full featured emulator in compare
with a BDM emulator.

A full featured emulator also has the following main advantages over a BDM:
1. The emulation RAM allows loading the code simply into RAM instead of
having to program the internal HC12 flash every time the code is
recompiled. Programming the internal flash is also allowed, but is usually
used only in late stages of the design.
2. An unlimited number of software and hardware breakpoints is available,
in compare with 2 only on a BDM when executing from Flash.
3. Debugging and testing of going through Reset (external and internal),
STOP and WAIT power down modes, Limp-Home Self-Clock mode are possible and
extensively supported, as oppose to BDMs that either entirely not
supporting operation through these modes, or are allowing execution through
only few of these modes, and in a limited way.
4. Speed changes, including frequent ones is supported (to allow operation
with PLL and clock manipulation for power consumption purposes for
example), unlike BDMs that don't allow this or are very limited.
5. A shadow memory which is entirely non-intrusive allows observing changes
to memory while running, as oppose to BDM which allows this only intrusively.

Hope this helps,

Doron
Nohau Corporation
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 12:16 PM 1/6/2003 +0000, you wrote:
>Doron,
>
>Do the Nohau emulators need a board to plug into? Or do the Nohau
>emulators come with an "eval board" of sorts? I do not have
>socketed MCU, so I would need an emulator that was standalone.
>
>Thanks.
>
>--- In , Doron Fael <doronf@n...> wrote:
> > Bob,
> >
> > This is the sort of problems that are very easy to find and
>resolve using a
> > full-featured emulator.
> > In such full featured emulator, you simply set a trace trigger on
>a random
> > value write to the PPAGE register, and once the trigger occur,
>look in the
> > trace to see what code was executed and lead to the PPAGE
>overwrite.
> >
> > Nohau and a few other vendors carry such full-featured emulator
>systems for
> > the HC12 and HCS12 (STAR12). Enable Engineering (joe@e...) is a
> > Nohau rep. company, and will also rent these full-featured
>emulators.
> >
> > Doron
> > Nohau Corporation
> > HC12 In-Circuit Emulators
> > www.nohau.com/emul12pc.html
> >
> > >Okay, I have roughly 4000 lines of C++ code developed in
>Metrowerks
> > >CodeWarrior for the STAR12. The code seems to work fine for the
>most
> > >part as long as my serial port debug messages are active. My
>serial
> > >debug messages are polled out and not interrupt driven. As soon
>as
> > >I recompile the source with the debug messages removed the code
> > >eventually has a symptom where the PPAGE register changes to what
> > >seems to be a pseudo-random value and then my code crashes. I am
> > >running a banked Flash application, so having the PPAGE register
> > >switch to a non-sensical value is disastrous.
> > >
> > >Can anyone provide any help, suggestions, or links to errata that
> > >would explain why my code would work with debug stmts in, and
>crash
> > >when the only thing changed is taking the debug statements out?
> > >
> > >Also, when I switch my serial port debug messages to 8-bit port
> > >write values that a logic analyzer can pick up, I crash as well.
> > >Obviously the time it takes for serial messages to go out over the
> > >RS-232 is much much longer than the 3 bus cycles it takes to write
> > >to a port. This points somewhat to timing, but I'm not sure where
> > >to look, or what debug tactic to try next. I'm starting to wonder
> > >if I've uncovered an MCU hardware bug.
> > >
> > >All help would be appreciated.
> > >


Reply by varneybob ●January 6, 20032003-01-06
Doron,

Do the Nohau emulators need a board to plug into? Or do the Nohau
emulators come with an "eval board" of sorts? I do not have
socketed MCU, so I would need an emulator that was standalone.

Thanks.

--- In , Doron Fael <doronf@n...> wrote:
> Bob,
>
> This is the sort of problems that are very easy to find and
resolve using a
> full-featured emulator.
> In such full featured emulator, you simply set a trace trigger on
a random
> value write to the PPAGE register, and once the trigger occur,
look in the
> trace to see what code was executed and lead to the PPAGE
overwrite.
>
> Nohau and a few other vendors carry such full-featured emulator
systems for
> the HC12 and HCS12 (STAR12). Enable Engineering (joe@e...) is a
> Nohau rep. company, and will also rent these full-featured
emulators.
>
> Doron
> Nohau Corporation
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> >Okay, I have roughly 4000 lines of C++ code developed in
Metrowerks
> >CodeWarrior for the STAR12. The code seems to work fine for the
most
> >part as long as my serial port debug messages are active. My
serial
> >debug messages are polled out and not interrupt driven. As soon
as
> >I recompile the source with the debug messages removed the code
> >eventually has a symptom where the PPAGE register changes to what
> >seems to be a pseudo-random value and then my code crashes. I am
> >running a banked Flash application, so having the PPAGE register
> >switch to a non-sensical value is disastrous.
> >
> >Can anyone provide any help, suggestions, or links to errata that
> >would explain why my code would work with debug stmts in, and
crash
> >when the only thing changed is taking the debug statements out?
> >
> >Also, when I switch my serial port debug messages to 8-bit port
> >write values that a logic analyzer can pick up, I crash as well.
> >Obviously the time it takes for serial messages to go out over the
> >RS-232 is much much longer than the 3 bus cycles it takes to write
> >to a port. This points somewhat to timing, but I'm not sure where
> >to look, or what debug tactic to try next. I'm starting to wonder
> >if I've uncovered an MCU hardware bug.
> >
> >All help would be appreciated.
> >
> >
> >
> >
> >--------------------
> >
> >
> >
> >">http://docs.yahoo.com/info/terms/
>





Reply by Doron Fael ●January 5, 20032003-01-05
Bob,

This is the sort of problems that are very easy to find and resolve using a
full-featured emulator.
In such full featured emulator, you simply set a trace trigger on a random
value write to the PPAGE register, and once the trigger occur, look in the
trace to see what code was executed and lead to the PPAGE overwrite.

Nohau and a few other vendors carry such full-featured emulator systems for
the HC12 and HCS12 (STAR12). Enable Engineering () is a
Nohau rep. company, and will also rent these full-featured emulators.

Doron
Nohau Corporation
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

>Okay, I have roughly 4000 lines of C++ code developed in Metrowerks
>CodeWarrior for the STAR12. The code seems to work fine for the most
>part as long as my serial port debug messages are active. My serial
>debug messages are polled out and not interrupt driven. As soon as
>I recompile the source with the debug messages removed the code
>eventually has a symptom where the PPAGE register changes to what
>seems to be a pseudo-random value and then my code crashes. I am
>running a banked Flash application, so having the PPAGE register
>switch to a non-sensical value is disastrous.
>
>Can anyone provide any help, suggestions, or links to errata that
>would explain why my code would work with debug stmts in, and crash
>when the only thing changed is taking the debug statements out?
>
>Also, when I switch my serial port debug messages to 8-bit port
>write values that a logic analyzer can pick up, I crash as well.
>Obviously the time it takes for serial messages to go out over the
>RS-232 is much much longer than the 3 bus cycles it takes to write
>to a port. This points somewhat to timing, but I'm not sure where
>to look, or what debug tactic to try next. I'm starting to wonder
>if I've uncovered an MCU hardware bug.
>
>All help would be appreciated. >
>
>-------------------- >
>">http://docs.yahoo.com/info/terms/


Reply by varneybob ●January 3, 20032003-01-03
Okay, I have roughly 4000 lines of C++ code developed in Metrowerks
CodeWarrior for the STAR12. The code seems to work fine for the most
part as long as my serial port debug messages are active. My serial
debug messages are polled out and not interrupt driven. As soon as
I recompile the source with the debug messages removed the code
eventually has a symptom where the PPAGE register changes to what
seems to be a pseudo-random value and then my code crashes. I am
running a banked Flash application, so having the PPAGE register
switch to a non-sensical value is disastrous.

Can anyone provide any help, suggestions, or links to errata that
would explain why my code would work with debug stmts in, and crash
when the only thing changed is taking the debug statements out?

Also, when I switch my serial port debug messages to 8-bit port
write values that a logic analyzer can pick up, I crash as well.
Obviously the time it takes for serial messages to go out over the
RS-232 is much much longer than the 3 bus cycles it takes to write
to a port. This points somewhat to timing, but I'm not sure where
to look, or what debug tactic to try next. I'm starting to wonder
if I've uncovered an MCU hardware bug.

All help would be appreciated.