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
Discussion Groups | 68HC12 | Re: Re: D64 COP: the saga continues
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
Re: Re: D64 COP: the saga continues - Edward Karpicz - Mar 28 3:18:50 2008
WadeA & RebeccaM Smith wrote:
>
> 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.
What does that routine do? Does it loop forever until you hotconnect with
debugger that is able to connect without reset into special mode? Does NoICE
supports that or does it indeed resets CPU into special chip mode?
>
> 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
Again. It doesn't help. BGND after COP reset is just a multicycle NOP, it
doesn't move you into active BDM mode.
> NoICE informs me that "reset has occured and all your breakpoints have
> been removed" (What breakpoints? I haven't set any breakpoints in
Reset removes all breakpoints (initializes breakpoints hardware like
everything else).
> flash! Can I?), I was HOPING that I could get to the BDM, but all I
Yes, hardware breakpoints can be set everywhere in RAM, flash and EEPROM.
> get is a few more "reset has..."
Yes, reset inits your onchip breakpoints hardware and after COP target runs
at full speed without any stops. BGND instructions are treates as multicycle
NOPs (about 60 bus cycles).
> 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.
Right. BDM doesn't help to debug over resets. S12C and all S12X do have
trace hardware, that should help at least logging execution over reset. But
I don't know how this works and what software tools to use. Once I tried
manually tracing forced COP reset on S12XD. It didn't work or I did it
wrong.
>
> 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...)
>
case 6. But COP reset from special single chip into normal single chip
disables active BDM and BGND instruction, your code runs at full speed
without any breakpoints. Do you somehow conditionally avoid calling initLCD
and initing COP to YES?
> What do you think could be the cause of my strange happenings.
Seems like to long loop inside initLCD, probably waiting while LCD is busy?
I don't know, I didn't see your code.
> (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?
>
Outputing some milestones over SCI, o-scope, good eye looking over and over
again at your code.
Don't forget that normally debuggers are using special single chip mode and
that most likely after COP reset you get back into normal single chip mode.
You can analyse MODE register (IIRC) to conditionally stop or continue. Hope
this helps.
Regards
Edward
>> > 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 )
>
> 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.
What does that routine do? Does it loop forever until you hotconnect with
debugger that is able to connect without reset into special mode? Does NoICE
supports that or does it indeed resets CPU into special chip mode?
>
> 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
Again. It doesn't help. BGND after COP reset is just a multicycle NOP, it
doesn't move you into active BDM mode.
> NoICE informs me that "reset has occured and all your breakpoints have
> been removed" (What breakpoints? I haven't set any breakpoints in
Reset removes all breakpoints (initializes breakpoints hardware like
everything else).
> flash! Can I?), I was HOPING that I could get to the BDM, but all I
Yes, hardware breakpoints can be set everywhere in RAM, flash and EEPROM.
> get is a few more "reset has..."
Yes, reset inits your onchip breakpoints hardware and after COP target runs
at full speed without any stops. BGND instructions are treates as multicycle
NOPs (about 60 bus cycles).
> 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.
Right. BDM doesn't help to debug over resets. S12C and all S12X do have
trace hardware, that should help at least logging execution over reset. But
I don't know how this works and what software tools to use. Once I tried
manually tracing forced COP reset on S12XD. It didn't work or I did it
wrong.
>
> 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...)
>
case 6. But COP reset from special single chip into normal single chip
disables active BDM and BGND instruction, your code runs at full speed
without any breakpoints. Do you somehow conditionally avoid calling initLCD
and initing COP to YES?
> What do you think could be the cause of my strange happenings.
Seems like to long loop inside initLCD, probably waiting while LCD is busy?
I don't know, I didn't see your code.
> (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?
>
Outputing some milestones over SCI, o-scope, good eye looking over and over
again at your code.
Don't forget that normally debuggers are using special single chip mode and
that most likely after COP reset you get back into normal single chip mode.
You can analyse MODE register (IIRC) to conditionally stop or continue. Hope
this helps.
Regards
Edward
>> > 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 )