Trap on Unimplemented ISR

Started by Andy Sifferman August 22, 2003

Hello everyone -

I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled by the
Metrowerks True-Time debugger. I have been developing code for a few
months now.

Most of the time everything works fine. But every now and then (between
several minutes to a few hours), the processor simply halts. In every case
the True-Time debugger indicates that the processor has halted on the BGND
instruction in the Unimplemented ISR trap.

I modified the isr_vectors.c file to produce a unique (but identical)
routine for each of the 64 vectors. This allowed me to identify that the
trap occurs on Unimplemented ISR 63, whose vector is mapped to address 0xFF80.

The MC9S12DT128B Device User Guide indicates that the vector at address
0xFF80 is "Reserved." It is not assigned to any documented
function. Therefore, I would expect that this vector would never be seen.

I have only seen this behavior with the BDM-Multilink connected to my
target. I don't know if it will happen when the target is running
standalone. The problem occurs so infrequently that I really can't just
sit around and wait for it to happen.

Of course with an in-circuit emulator, I could set up a trace to see the
executed instructions leading up to the interrupt. But alas, all I have is
the humble BDM-Multilink.

Anyone have any ideas about why this might be happening, or how I might
debug it?

Thanks.

Andy






Hi Andy.

Can you make sure that when the debugger halts, the I bit is set?
I mean that the debugger will halt on any BGND instruction execution. A
jump to this address would do the same thing. But only an interrupt will set I.

I can imaging that the PC has "quitted" the program and incremented till
reaching address FF80 and halted the debugger this way.

Typically, the debugger is able to read the program call chain on the
device stack and display it in the Procedure window: If an interrupt
occurs, you should be able to find latest procedure called. Best regards,
Gilles At 11:10 PM 8/22/2003, you wrote:

>Hello everyone -
>
>I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled by the
>Metrowerks True-Time debugger. I have been developing code for a few
>months now.
>
>Most of the time everything works fine. But every now and then (between
>several minutes to a few hours), the processor simply halts. In every case
>the True-Time debugger indicates that the processor has halted on the BGND
>instruction in the Unimplemented ISR trap.
>
>I modified the isr_vectors.c file to produce a unique (but identical)
>routine for each of the 64 vectors. This allowed me to identify that the
>trap occurs on Unimplemented ISR 63, whose vector is mapped to address 0xFF80.
>
>The MC9S12DT128B Device User Guide indicates that the vector at address
>0xFF80 is "Reserved." It is not assigned to any documented
>function. Therefore, I would expect that this vector would never be seen.
>
>I have only seen this behavior with the BDM-Multilink connected to my
>target. I don't know if it will happen when the target is running
>standalone. The problem occurs so infrequently that I really can't just
>sit around and wait for it to happen.
>
>Of course with an in-circuit emulator, I could set up a trace to see the
>executed instructions leading up to the interrupt. But alas, all I have is
>the humble BDM-Multilink.
>
>Anyone have any ideas about why this might be happening, or how I might
>debug it?
>
>Thanks.
>
>Andy >
>
>-------------------- >
>">http://docs.yahoo.com/info/terms/






Gilles -

Good idea. The next time this happens, I will check the I bit and
the
stack, which might yield further clues as to what is happening.

But I don't think a runaway processor would halt if it tried to
execute the contents of 0xFF80 - this location would contain the
address of the Unimplemented ISR service routine, and not the BGND
instruction itself. The service routine for Unimplemented ISR 63
occurs in memory AFTER all of the other Unimplemented ISR routines
(all of which contain simply a single BGND instruction) - this is the
last BGND instruction, not the first. Therefore, it seems unlikely
to
me that the processor was executing runaway code and "happened" upon
the BGND instruction. Though it is plausible that there might be a
jump to that location.

Thanks for the reply.

Andy

----------------------------
--- In , Gilles Blanquin <gblanquin@m...> wrote:
> Hi Andy.
>
> Can you make sure that when the debugger halts, the I bit is set?
> I mean that the debugger will halt on any BGND instruction
execution. A
> jump to this address would do the same thing. But only an interrupt
will set I.
>
> I can imaging that the PC has "quitted" the program and incremented
till
> reaching address FF80 and halted the debugger this way.
>
> Typically, the debugger is able to read the program call chain on
the
> device stack and display it in the Procedure window: If an
interrupt
> occurs, you should be able to find latest procedure called. > Best regards,
> Gilles > At 11:10 PM 8/22/2003, you wrote:
>
> >Hello everyone -
> >
> >I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled
by the
> >Metrowerks True-Time debugger. I have been developing code for a
few
> >months now.
> >
> >Most of the time everything works fine. But every now and then
(between
> >several minutes to a few hours), the processor simply halts. In
every case
> >the True-Time debugger indicates that the processor has halted on
the BGND
> >instruction in the Unimplemented ISR trap.
> >
> >I modified the isr_vectors.c file to produce a unique (but
identical)
> >routine for each of the 64 vectors. This allowed me to identify
that the
> >trap occurs on Unimplemented ISR 63, whose vector is mapped to
address 0xFF80.
> >
> >The MC9S12DT128B Device User Guide indicates that the vector at
address
> >0xFF80 is "Reserved." It is not assigned to any documented
> >function. Therefore, I would expect that this vector would never
be seen.
> >
> >I have only seen this behavior with the BDM-Multilink connected to
my
> >target. I don't know if it will happen when the target is running
> >standalone. The problem occurs so infrequently that I really
can't
just
> >sit around and wait for it to happen.
> >
> >Of course with an in-circuit emulator, I could set up a trace to
see the
> >executed instructions leading up to the interrupt. But alas, all
I
have is
> >the humble BDM-Multilink.
> >
> >Anyone have any ideas about why this might be happening, or how I
might
> >debug it?
> >
> >Thanks.
> >
> >Andy
> >
> >
> >
> >
> >--------------------
> >
> >
> >
>




Hi Andy!

Oops! Sorry for this hilarious suggestion. I might have been seriously
tired that day. For sure, above 0xFF7F, there might be only vectors, no
BNGD and no trap ISRs.

An emulator would be nice to debug this. Also if you could port/test your
code on an MC9S12 "E" part (or any device featuring the DBG module),

http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=MC9S12E128&n
odeIdt3ZGpnLn8636K100

it features the DBG12 module i.e advanced triggers + "change-of-flow" trace
buffer.

http://e-www.motorola.com/files/microcontrollers/doc/ref_manual/S12DBGV1.pdf

Best regards,
Gilles

At 07:18 PM 9/4/2003, you wrote:

>Gilles -
>
>Good idea. The next time this happens, I will check the I bit and
>the
>stack, which might yield further clues as to what is happening.
>
>But I don't think a runaway processor would halt if it tried to
>execute the contents of 0xFF80 - this location would contain the
>address of the Unimplemented ISR service routine, and not the BGND
>instruction itself. The service routine for Unimplemented ISR 63
>occurs in memory AFTER all of the other Unimplemented ISR routines
>(all of which contain simply a single BGND instruction) - this is the
>last BGND instruction, not the first. Therefore, it seems unlikely
>to
>me that the processor was executing runaway code and "happened" upon
>the BGND instruction. Though it is plausible that there might be a
>jump to that location.
>
>Thanks for the reply.
>
>Andy
>
>----------------------------
>--- In , Gilles Blanquin <gblanquin@m...> wrote:
> > Hi Andy.
> >
> > Can you make sure that when the debugger halts, the I bit is set?
> > I mean that the debugger will halt on any BGND instruction
>execution. A
> > jump to this address would do the same thing. But only an interrupt
>will set I.
> >
> > I can imaging that the PC has "quitted" the program and incremented
>till
> > reaching address FF80 and halted the debugger this way.
> >
> > Typically, the debugger is able to read the program call chain on
>the
> > device stack and display it in the Procedure window: If an
>interrupt
> > occurs, you should be able to find latest procedure called.
> >
> >
> > Best regards,
> > Gilles
> >
> >
> > At 11:10 PM 8/22/2003, you wrote:
> >
> > >Hello everyone -
> > >
> > >I am using the MC9S12DG128B with the P&E BDM-Multilink, controlled
>by the
> > >Metrowerks True-Time debugger. I have been developing code for a
>few
> > >months now.
> > >
> > >Most of the time everything works fine. But every now and then
>(between
> > >several minutes to a few hours), the processor simply halts. In
>every case
> > >the True-Time debugger indicates that the processor has halted on
>the BGND
> > >instruction in the Unimplemented ISR trap.
> > >
> > >I modified the isr_vectors.c file to produce a unique (but
>identical)
> > >routine for each of the 64 vectors. This allowed me to identify
>that the
> > >trap occurs on Unimplemented ISR 63, whose vector is mapped to
>address 0xFF80.
> > >
> > >The MC9S12DT128B Device User Guide indicates that the vector at
>address
> > >0xFF80 is "Reserved." It is not assigned to any documented
> > >function. Therefore, I would expect that this vector would never
>be seen.
> > >
> > >I have only seen this behavior with the BDM-Multilink connected to
>my
> > >target. I don't know if it will happen when the target is running
> > >standalone. The problem occurs so infrequently that I really
>can't
>just
> > >sit around and wait for it to happen.
> > >
> > >Of course with an in-circuit emulator, I could set up a trace to
>see the
> > >executed instructions leading up to the interrupt. But alas, all
>I
>have is
> > >the humble BDM-Multilink.
> > >
> > >Anyone have any ideas about why this might be happening, or how I
>might
> > >debug it?
> > >
> > >Thanks.
> > >
> > >Andy
> > >
> > >
> > >
> > >
> > >--------------------
> > >
> > >
> > >
> > >
>-------------------- >
>">http://docs.yahoo.com/info/terms/





OK, now the problem seems to have morphed into something repeatable.
I wrote some test code to solve another problem, that repeatedly calls
one routine to read data from a proprietary input port, and transmit
that data to a serial output port for viewing with Hyperterminal.
This code appears to work fine. But, the debugger does the following.
(Note: I am using MC9S12DG128B, P&E BDM Multilink, and Metrowerks
True-Time debugger.)

1. I click Start in the True-Time debugger, which starts up my code at
the Reset vector, using the BDM-Multilink. The target program starts
to run correctly, and I start seeing data appearing on Hyperterminal.

2. After a second or so, the debugger appears to halt on the BGND
instruction in the service routine for Unimplemented ISR 63, whose
vector is mapped to address 0xFF80. However, the program continues to
run properly on the target. Only the debugger has stopped. The Halt
button on the debugger toolbar is grayed-out and not available.

3. If I click on the Start button in the toolbar, nothing appears to
happen. The program continues to run on the target.

4. If I scroll through memory within the debugger while the program is
running and the debugger is in this halted state, it all reads FF.
All of the HC12 registers read FF, too, as does the CCR.

5. If I click on the Reset Target button on the toolbar, the program
in the target halts, and the debugger returns to its normal state. I
can then see the actual memory in the target, and the actual state of
the registers.

Any clues, I'd appreciate your ideas.

Thanks everyone.

Andy

------------------------------
--- In , "Sifferman" <asifferm@a...> wrote:
>
> Gilles -
>
> Good idea. The next time this happens, I will check the I bit and
> the
> stack, which might yield further clues as to what is happening.
>
> But I don't think a runaway processor would halt if it tried to
> execute the contents of 0xFF80 - this location would contain the
> address of the Unimplemented ISR service routine, and not the BGND
> instruction itself. The service routine for Unimplemented ISR 63
> occurs in memory AFTER all of the other Unimplemented ISR routines
> (all of which contain simply a single BGND instruction) - this is
the
> last BGND instruction, not the first. Therefore, it seems unlikely
> to
> me that the processor was executing runaway code and "happened" upon
> the BGND instruction. Though it is plausible that there might be a
> jump to that location.
>
> Thanks for the reply.
>
> Andy
>
> ----------------------------
> --- In , Gilles Blanquin <gblanquin@m...>
wrote:
> > Hi Andy.
> >
> > Can you make sure that when the debugger halts, the I bit is set?
> > I mean that the debugger will halt on any BGND instruction
> execution. A
> > jump to this address would do the same thing. But only an
interrupt
> will set I.
> >
> > I can imaging that the PC has "quitted" the program and
incremented
> till
> > reaching address FF80 and halted the debugger this way.
> >
> > Typically, the debugger is able to read the program call chain on
> the
> > device stack and display it in the Procedure window: If an
> interrupt
> > occurs, you should be able to find latest procedure called.
> >
> >
> > Best regards,
> > Gilles
> >
> >
> > At 11:10 PM 8/22/2003, you wrote:
> >
> > >Hello everyone -
> > >
> > >I am using the MC9S12DG128B with the P&E BDM-Multilink,
controlled
> by the
> > >Metrowerks True-Time debugger. I have been developing code for a
> few
> > >months now.
> > >
> > >Most of the time everything works fine. But every now and then
> (between
> > >several minutes to a few hours), the processor simply halts. In
> every case
> > >the True-Time debugger indicates that the processor has halted on
> the BGND
> > >instruction in the Unimplemented ISR trap.
> > >
> > >I modified the isr_vectors.c file to produce a unique (but
> identical)
> > >routine for each of the 64 vectors. This allowed me to identify
> that the
> > >trap occurs on Unimplemented ISR 63, whose vector is mapped to
> address 0xFF80.
> > >
> > >The MC9S12DT128B Device User Guide indicates that the vector at
> address
> > >0xFF80 is "Reserved." It is not assigned to any documented
> > >function. Therefore, I would expect that this vector would never
> be seen.
> > >
> > >I have only seen this behavior with the BDM-Multilink connected
to
> my
> > >target. I don't know if it will happen when the target is
running
> > >standalone. The problem occurs so infrequently that I really
> can't
> just
> > >sit around and wait for it to happen.
> > >
> > >Of course with an in-circuit emulator, I could set up a trace to
> see the
> > >executed instructions leading up to the interrupt. But alas, all
> I
> have is
> > >the humble BDM-Multilink.
> > >
> > >Anyone have any ideas about why this might be happening, or how I
> might
> > >debug it?
> > >
> > >Thanks.
> > >
> > >Andy
> > >
> > >
> > >
> > >
> > >--------------------
> > >
> > >
> > >
> > >





Hi Andy.

Thanks for isolating this problem. All points after "point 2" are "normal",
resulting from a loss of communication.
This is a "hardware" problem. It seems to be something bound to bus speed
change via onchip PLL, implying also a BDM communication speed change and
loss of communication/synchronization between the chip and the Multilink.

If your application changes (even only once) the bus speed via PLL:
-make sure a PLL Loop Filter is installed.
-check the "set CLKSW bit in BDM control register (MC9S12 only)" checkbox
in the "Communication Device Specification" dialog (menu: "ICD-12" then
"Connect...").

If you open a "Command" component, speed variation detections by the cable
should be reported there.

Andy, you can send me your program/project directly. Please specify also
the MC9S12DG128B silicon mask, the Multilink cable revision, and also your
Metrowerks CodeWarrior version. Typing "ver" in the "Command" window gives
directly a list of DLL versions. Any other info like schematics is also
welcome.

Thanks for all your help.

Regards,
Gilles At 11:39 PM 10/6/2003, you wrote:

>OK, now the problem seems to have morphed into something repeatable.
>I wrote some test code to solve another problem, that repeatedly calls
>one routine to read data from a proprietary input port, and transmit
>that data to a serial output port for viewing with Hyperterminal.
>This code appears to work fine. But, the debugger does the following.
>(Note: I am using MC9S12DG128B, P&E BDM Multilink, and Metrowerks
>True-Time debugger.)
>
>1. I click Start in the True-Time debugger, which starts up my code at
>the Reset vector, using the BDM-Multilink. The target program starts
>to run correctly, and I start seeing data appearing on Hyperterminal.
>
>2. After a second or so, the debugger appears to halt on the BGND
>instruction in the service routine for Unimplemented ISR 63, whose
>vector is mapped to address 0xFF80. However, the program continues to
>run properly on the target. Only the debugger has stopped. The Halt
>button on the debugger toolbar is grayed-out and not available.
>
>3. If I click on the Start button in the toolbar, nothing appears to
>happen. The program continues to run on the target.
>
>4. If I scroll through memory within the debugger while the program is
>running and the debugger is in this halted state, it all reads FF.
>All of the HC12 registers read FF, too, as does the CCR.
>
>5. If I click on the Reset Target button on the toolbar, the program
>in the target halts, and the debugger returns to its normal state. I
>can then see the actual memory in the target, and the actual state of
>the registers.
>
>Any clues, I'd appreciate your ideas.
>
>Thanks everyone.
>
>Andy
>
>------------------------------
>--- In , "Sifferman" <asifferm@a...> wrote:
> >
> > Gilles -
> >
> > Good idea. The next time this happens, I will check the I bit and
> > the
> > stack, which might yield further clues as to what is happening.
> >
> > But I don't think a runaway processor would halt if it tried to
> > execute the contents of 0xFF80 - this location would contain the
> > address of the Unimplemented ISR service routine, and not the BGND
> > instruction itself. The service routine for Unimplemented ISR 63
> > occurs in memory AFTER all of the other Unimplemented ISR routines
> > (all of which contain simply a single BGND instruction) - this is
>the
> > last BGND instruction, not the first. Therefore, it seems unlikely
> > to
> > me that the processor was executing runaway code and "happened" upon
> > the BGND instruction. Though it is plausible that there might be a
> > jump to that location.
> >
> > Thanks for the reply.
> >
> > Andy
> >
> > ----------------------------
> > --- In , Gilles Blanquin <gblanquin@m...>
>wrote:
> > > Hi Andy.
> > >
> > > Can you make sure that when the debugger halts, the I bit is set?
> > > I mean that the debugger will halt on any BGND instruction
> > execution. A
> > > jump to this address would do the same thing. But only an
>interrupt
> > will set I.
> > >
> > > I can imaging that the PC has "quitted" the program and
>incremented
> > till
> > > reaching address FF80 and halted the debugger this way.
> > >
> > > Typically, the debugger is able to read the program call chain on
> > the
> > > device stack and display it in the Procedure window: If an
> > interrupt
> > > occurs, you should be able to find latest procedure called.
> > >
> > >
> > > Best regards,
> > > Gilles
> > >
> > >
> > > At 11:10 PM 8/22/2003, you wrote:
> > >
> > > >Hello everyone -
> > > >
> > > >I am using the MC9S12DG128B with the P&E BDM-Multilink,
>controlled
> > by the
> > > >Metrowerks True-Time debugger. I have been developing code for a
> > few
> > > >months now.
> > > >
> > > >Most of the time everything works fine. But every now and then
> > (between
> > > >several minutes to a few hours), the processor simply halts. In
> > every case
> > > >the True-Time debugger indicates that the processor has halted on
> > the BGND
> > > >instruction in the Unimplemented ISR trap.
> > > >
> > > >I modified the isr_vectors.c file to produce a unique (but
> > identical)
> > > >routine for each of the 64 vectors. This allowed me to identify
> > that the
> > > >trap occurs on Unimplemented ISR 63, whose vector is mapped to
> > address 0xFF80.
> > > >
> > > >The MC9S12DT128B Device User Guide indicates that the vector at
> > address
> > > >0xFF80 is "Reserved." It is not assigned to any documented
> > > >function. Therefore, I would expect that this vector would never
> > be seen.
> > > >
> > > >I have only seen this behavior with the BDM-Multilink connected
>to
> > my
> > > >target. I don't know if it will happen when the target is
>running
> > > >standalone. The problem occurs so infrequently that I really
> > can't
> > just
> > > >sit around and wait for it to happen.
> > > >
> > > >Of course with an in-circuit emulator, I could set up a trace to
> > see the
> > > >executed instructions leading up to the interrupt. But alas, all
> > I
> > have is
> > > >the humble BDM-Multilink.
> > > >
> > > >Anyone have any ideas about why this might be happening, or how I
> > might
> > > >debug it?
> > > >
> > > >Thanks.
> > > >
> > > >Andy
> > > >
> > > >
> > > >
> > > >
> > > >--------------------
> > > >
> > > >
> > > >
> > > >
>-------------------- >
>">http://docs.yahoo.com/info/terms/





--- In , Gilles Blanquin <gblanquin@m...> wrote:

Hi Giles,

> If your application changes (even only once) the bus speed via PLL:
> -make sure a PLL Loop Filter is installed.

What is?

Hardware? Sodtware? Regards,

Theo




Theo,

The PLL Loop Filter is the name of a network of 2 capacitors and one
resistors that should be connected to the Xfc pin of your HC12 / HCS12, if
you want to activate and use the internal HC12 PLL.

In order to calculate the values of the capacitors and resistor for the
HCS12 parts, you can download and use the following program from the Nohau
web-site:
http://www.nohau.com/s12calc/pll_302.html

Hope this helps,
Doron
Nohau Corporation
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 19:49 10/10/2003 +0000, you wrote:
>--- In , Gilles Blanquin <gblanquin@m...> wrote:
>
>Hi Giles,
>
> > If your application changes (even only once) the bus speed via PLL:
> > -make sure a PLL Loop Filter is installed.
>
>What is?
>
>Hardware? Sodtware? >Regards,
>
>Theo





--- In , Doron Fael <doronf@n...> wrote:

Hi Doron,

Thanks for that, hadn't come accross the name.
Steep learning curve from 6800 to HC12:-)

Regards,

Theo

> The PLL Loop Filter is the name of a network of 2 capacitors and one
> resistors that should be connected to the Xfc pin of your HC12 / HCS12, if
> you want to activate and use the internal HC12 PLL.
>
> In order to calculate the values of the capacitors and resistor for the
> HCS12 parts, you can download and use the following program from the Nohau
> web-site:
> http://www.nohau.com/s12calc/pll_302.html
>
> Hope this helps,
> Doron
> Nohau Corporation
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> At 19:49 10/10/2003 +0000, you wrote:
> >--- In , Gilles Blanquin <gblanquin@m...> wrote:
> >
> >Hi Giles,
> >
> > > If your application changes (even only once) the bus speed via PLL:
> > > -make sure a PLL Loop Filter is installed.
> >
> >What is?
> >
> >Hardware? Sodtware?
> >
> >
> >Regards,
> >
> >Theo >