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
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 27 21:39:28 2008
--- In 6...@yahoogroups.com, "Edward Karpicz" wrote:
>
> WadeA & RebeccaM Smith wrote:
>
> >> RSBCK? It makes sense only for BDM debug sessions. I completely lost
> > track
> >> of what you are doing and asking for.
> >
> > I just keep trying to find out exactly where/why the COP starts doing
> > its thing, so I run NoICE trying to find that.
> > From datasheet:
> RSBCK - COP and RTI stop in Active BDM mode Bit
>
> BDM is Active when NoICE go/halt button is depressed (of corse
provided BDM
> is properly connected and BDM comms aren't lost) :-).
>
> RSBCK won't point you to the place where COP timeouts. RSBCK=1 just
stops
> COP and RTI while target is halted by BDM debugger. So that you
don't get
> annoyed always single stepping into RTI handler or reset if halted
for too
> long. To find where COP timeouts you should let you code to run for
a while.
> Step over few lines, function calls, loops. Succeded = COP didn't
timeout,
> reset - let's get deeper into details. Alternatively you may print some
> milestone messages, been here, done that. Did you try this, didn't
it help?
>
> Also keep in mind that some uninitialized pointer may lead to
accidental
> write to ARMCOP and COP reset.
I assign EVERY vector to a routine to keep track of EVERY interrupt
that I dont actully use. There seems to be no help there.
I put BGND in for some of the interrupts so that I can get to the BDM
when COP (or some of the other top interrupts) occur. However, when
NoICE informs me that "reset has occured and all your breakpoints have
been removed" (What breakpoints? I haven't set any breakpoints in
flash! Can I?), I was HOPING that I could get to the BDM, but all I
get is a few more "reset has..."
And whatever resets are happening, I cant seem to get them to SHUT UP
long enough for me to figure out what happened and they will NOT let
the BDM take over.
case = LCD + initLCD + COP = result
--------------------------------------------
1 = NO LCD + no initLCD + COP no/yes = OK
2 = YES LCD + no initLCD + COP no/yes = OK
3 = YES LCD + YES initLCD + COP no/yes = OK
4 = NO LCD + YES initLCD + COP no = OK
5 = NO LCD + YES initLCD + COP YES = la-la land,
6 = NO LCD + YES initLCD + COP YES + NoICE = reset, reset, reset ...
----------------------------------------------
So, if an actual Hardware reset occurs and COPCTL gets set back to
zero (the powerup default), then case 6 shouldn't happen (reset, reset...)
What do you think could be the cause of my strange happenings.
(My mental state nor my ignernts is to be mentioned, please)
> > Without NoICE all I see is perminant la-la land. With NoICE I see
> > reset... reset... reset.... I was hoping that RSBCK would help me
>
> You can't debug over reset. NoICE just warns you you're lost.
Yep. I noticed that. Any suggestions?
> > isolate where COP takes over so I can put in more puppyPetting().
> >
> > Friday I'll have the board on an o'scope with Mr EE and we'll try to
> > get COP to not kill us when the LCD is not hooked up.
> >
> > A real HARDWARE reset to start life over would be so nice, if I could
> > get one...
> > COP is real hardware reset.
> S12X parts do have "illegal address reset". It resets every time you
> read/write unimplemented locations. You may like it more than COP.
But I
> wonder if you will be happy chasing bugs leading to such reset?
>
> Regards
> Edward
>
------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
>
> WadeA & RebeccaM Smith wrote:
>
> >> RSBCK? It makes sense only for BDM debug sessions. I completely lost
> > track
> >> of what you are doing and asking for.
> >
> > I just keep trying to find out exactly where/why the COP starts doing
> > its thing, so I run NoICE trying to find that.
> > From datasheet:
> RSBCK - COP and RTI stop in Active BDM mode Bit
>
> BDM is Active when NoICE go/halt button is depressed (of corse
provided BDM
> is properly connected and BDM comms aren't lost) :-).
>
> RSBCK won't point you to the place where COP timeouts. RSBCK=1 just
stops
> COP and RTI while target is halted by BDM debugger. So that you
don't get
> annoyed always single stepping into RTI handler or reset if halted
for too
> long. To find where COP timeouts you should let you code to run for
a while.
> Step over few lines, function calls, loops. Succeded = COP didn't
timeout,
> reset - let's get deeper into details. Alternatively you may print some
> milestone messages, been here, done that. Did you try this, didn't
it help?
>
> Also keep in mind that some uninitialized pointer may lead to
accidental
> write to ARMCOP and COP reset.
I assign EVERY vector to a routine to keep track of EVERY interrupt
that I dont actully use. There seems to be no help there.
I put BGND in for some of the interrupts so that I can get to the BDM
when COP (or some of the other top interrupts) occur. However, when
NoICE informs me that "reset has occured and all your breakpoints have
been removed" (What breakpoints? I haven't set any breakpoints in
flash! Can I?), I was HOPING that I could get to the BDM, but all I
get is a few more "reset has..."
And whatever resets are happening, I cant seem to get them to SHUT UP
long enough for me to figure out what happened and they will NOT let
the BDM take over.
case = LCD + initLCD + COP = result
--------------------------------------------
1 = NO LCD + no initLCD + COP no/yes = OK
2 = YES LCD + no initLCD + COP no/yes = OK
3 = YES LCD + YES initLCD + COP no/yes = OK
4 = NO LCD + YES initLCD + COP no = OK
5 = NO LCD + YES initLCD + COP YES = la-la land,
6 = NO LCD + YES initLCD + COP YES + NoICE = reset, reset, reset ...
----------------------------------------------
So, if an actual Hardware reset occurs and COPCTL gets set back to
zero (the powerup default), then case 6 shouldn't happen (reset, reset...)
What do you think could be the cause of my strange happenings.
(My mental state nor my ignernts is to be mentioned, please)
> > Without NoICE all I see is perminant la-la land. With NoICE I see
> > reset... reset... reset.... I was hoping that RSBCK would help me
>
> You can't debug over reset. NoICE just warns you you're lost.
Yep. I noticed that. Any suggestions?
> > isolate where COP takes over so I can put in more puppyPetting().
> >
> > Friday I'll have the board on an o'scope with Mr EE and we'll try to
> > get COP to not kill us when the LCD is not hooked up.
> >
> > A real HARDWARE reset to start life over would be so nice, if I could
> > get one...
> > COP is real hardware reset.
> S12X parts do have "illegal address reset". It resets every time you
> read/write unimplemented locations. You may like it more than COP.
But I
> wonder if you will be happy chasing bugs leading to such reset?
>
> Regards
> Edward
>
------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )