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 | Reset event debug
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
Reset event debug - Longworth, Kevin - May 23 10:52:00 2005
Does anyone have some tips on how to debug a reset using Isystems BDM ?
I get a reset which causes the FFFE vector and jumps to the startup
code. But I have no idea why. The breakpoints in the ISR are not being
hit, and COP is disabled. I don't know if the CRG is generating an
interrupt or what. How can this be determined, how can I debug this?
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Reset event debug - Doron Fael - May 23 11:24:00 2005
Kevin,
Our (Nohau) full-emulator supports debugging through all Reset sequences.
The entire history that leads into the Reset, through the Reset, and out of
the Reset is also shown in the trace, so there is a good chance the answer
why you get a Reset will be just there in front of you, in the trace
display. You can see more Reset debugging details in the following article:
http://www.nohau.com/products/hcs12_emulator_features.pdf
The Nohau full-emulator can be rented on a monthly basis if you cannot
afford or don't wish to buy one.
To the best of my knowledge the iSystem HCS12 full-emulator and BDM don't
support debugging through Resets.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 10:52 23/05/2005 -0400, you wrote: >Does anyone have some tips on how to debug a reset using Isystems BDM ?
>I get a reset which causes the FFFE vector and jumps to the startup
>code. But I have no idea why. The breakpoints in the ISR are not being
>hit, and COP is disabled. I don't know if the CRG is generating an
>interrupt or what. How can this be determined, how can I debug this? [Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Our (Nohau) full-emulator supports debugging through all Reset sequences.
The entire history that leads into the Reset, through the Reset, and out of
the Reset is also shown in the trace, so there is a good chance the answer
why you get a Reset will be just there in front of you, in the trace
display. You can see more Reset debugging details in the following article:
http://www.nohau.com/products/hcs12_emulator_features.pdf
The Nohau full-emulator can be rented on a monthly basis if you cannot
afford or don't wish to buy one.
To the best of my knowledge the iSystem HCS12 full-emulator and BDM don't
support debugging through Resets.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 10:52 23/05/2005 -0400, you wrote: >Does anyone have some tips on how to debug a reset using Isystems BDM ?
>I get a reset which causes the FFFE vector and jumps to the startup
>code. But I have no idea why. The breakpoints in the ISR are not being
>hit, and COP is disabled. I don't know if the CRG is generating an
>interrupt or what. How can this be determined, how can I debug this? [Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Reset event debug - Longworth, Kevin - May 23 11:24:00 2005
I think I found a way, I am using a redirected interrupt table in ram
(because the bootloader I have to use does), so I filled that part of
RAM with 0, a BGND instruction which halts the BDM when it's hit. I
found out the ECT ch 5 interrupt was being hit, which was defined to
jump to unkown interrupt. Now I have to figure out why that's happening.
It seem like even if not using a ram int table, it would be fairly
simple to set up and thus be able to determine what interrupt is
occurring with the BGND instruction.
_kevin
_____
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Longworth, Kevin
Sent: Monday, May 23, 2005 10:53 AM
To: 68HC12@68HC...
Subject: [68HC12] Reset event debug Does anyone have some tips on how to debug a reset using Isystems BDM ?
I get a reset which causes the FFFE vector and jumps to the startup
code. But I have no idea why. The breakpoints in the ISR are not being
hit, and COP is disabled. I don't know if the CRG is generating an
interrupt or what. How can this be determined, how can I debug this?
[Non-text portions of this message have been removed]
_____
> .
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
(because the bootloader I have to use does), so I filled that part of
RAM with 0, a BGND instruction which halts the BDM when it's hit. I
found out the ECT ch 5 interrupt was being hit, which was defined to
jump to unkown interrupt. Now I have to figure out why that's happening.
It seem like even if not using a ram int table, it would be fairly
simple to set up and thus be able to determine what interrupt is
occurring with the BGND instruction.
_kevin
_____
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Longworth, Kevin
Sent: Monday, May 23, 2005 10:53 AM
To: 68HC12@68HC...
Subject: [68HC12] Reset event debug Does anyone have some tips on how to debug a reset using Isystems BDM ?
I get a reset which causes the FFFE vector and jumps to the startup
code. But I have no idea why. The breakpoints in the ISR are not being
hit, and COP is disabled. I don't know if the CRG is generating an
interrupt or what. How can this be determined, how can I debug this?
[Non-text portions of this message have been removed]
_____
> .
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Reset event debug - Steve Russell - May 23 15:17:00 2005
I recommend making each unused reset, trap, and interrupt vector go to its
own, unique loop.
That makes the occurrence of unexpected interrupt obvious, and doesn't lose
any information. It also generally produces acceptable results in the
final application. (The COP watchdog goes off after a while and resets the
system.)
Among the interrupts or traps that can occur, but may be surprising, are
unimplemented instruction trap and SWI.
In the past, some Motorola parts have been known to cause interrupts to
"reserved" vector locations due to errors in the silicon.
As far as I know, Freescale hasn't done this yet, but the protection is
simple - fill in all the vector locations.
Steve Russell
Nohau Emulators
At 08:24 AM 5/23/2005, you wrote:
>I think I found a way, I am using a redirected interrupt table in ram
>(because the bootloader I have to use does), so I filled that part of
>RAM with 0, a BGND instruction which halts the BDM when it's hit. I
>found out the ECT ch 5 interrupt was being hit, which was defined to
>jump to unkown interrupt. Now I have to figure out why that's happening.
>It seem like even if not using a ram int table, it would be fairly
>simple to set up and thus be able to determine what interrupt is
>occurring with the BGND instruction. >
>_kevin >
> _____
>
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Longworth, Kevin
>Sent: Monday, May 23, 2005 10:53 AM
>To: 68HC12@68HC...
>Subject: [68HC12] Reset event debug >Does anyone have some tips on how to debug a reset using Isystems BDM ?
>I get a reset which causes the FFFE vector and jumps to the startup
>code. But I have no idea why. The breakpoints in the ISR are not being
>hit, and COP is disabled. I don't know if the CRG is generating an
>interrupt or what. How can this be determined, how can I debug this? >
>[Non-text portions of this message have been removed] >
>
> _____
>
>> . >
>[Non-text portions of this message have been removed] >
>
>Yahoo! Groups Links
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
own, unique loop.
That makes the occurrence of unexpected interrupt obvious, and doesn't lose
any information. It also generally produces acceptable results in the
final application. (The COP watchdog goes off after a while and resets the
system.)
Among the interrupts or traps that can occur, but may be surprising, are
unimplemented instruction trap and SWI.
In the past, some Motorola parts have been known to cause interrupts to
"reserved" vector locations due to errors in the silicon.
As far as I know, Freescale hasn't done this yet, but the protection is
simple - fill in all the vector locations.
Steve Russell
Nohau Emulators
At 08:24 AM 5/23/2005, you wrote:
>I think I found a way, I am using a redirected interrupt table in ram
>(because the bootloader I have to use does), so I filled that part of
>RAM with 0, a BGND instruction which halts the BDM when it's hit. I
>found out the ECT ch 5 interrupt was being hit, which was defined to
>jump to unkown interrupt. Now I have to figure out why that's happening.
>It seem like even if not using a ram int table, it would be fairly
>simple to set up and thus be able to determine what interrupt is
>occurring with the BGND instruction. >
>_kevin >
> _____
>
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Longworth, Kevin
>Sent: Monday, May 23, 2005 10:53 AM
>To: 68HC12@68HC...
>Subject: [68HC12] Reset event debug >Does anyone have some tips on how to debug a reset using Isystems BDM ?
>I get a reset which causes the FFFE vector and jumps to the startup
>code. But I have no idea why. The breakpoints in the ISR are not being
>hit, and COP is disabled. I don't know if the CRG is generating an
>interrupt or what. How can this be determined, how can I debug this? >
>[Non-text portions of this message have been removed] >
>
> _____
>
>> . >
>[Non-text portions of this message have been removed] >
>
>Yahoo! Groups Links
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )