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 | Why does enabling Real Time Interrupt on S12XD hork the system?
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
Why does enabling Real Time Interrupt on S12XD hork the system? - davidarmstrong72 - Dec 22 13:05:13 2008
I've been working on assembly code for S12XDP512. (Technological Arts
board.) This has the serial monitor programmed into the Flash on the
board.
For ease of use, my program keeps the use of the default vector table
at page $FF in the serial monitor, but has vectors in the
pseudo-vector interrupt table at page $F7.
I have user input/output via SCI0 and a terminal interface. (I can
select when assembling the code whether or not SCI0 uses an
interrupt/buffer scheme, or just polled to handle I/O.)
I have also set up the Real Time Interrupt to trigger every 100 ms.
So, if I set up SCI0 to run in polled mode, and set up RTI without
enabling it, everything works fine. As soon as RTI is enabled though,
(writing $80 to $38 = CRGINT), things go haywire. The RTI is the only
enabled interrupt. However I think that another interrupt is causing
the serial monitor to kick in and take over, since I see strange
characters on the screen from this point forward, until reset.
Other points:
* Interrupts are enabled in the condition code register before doing
write to enable RTI.
* Spurious Interrupt vector set up with code being just an "rti"
instruction.
* Real Time Interrupt routine has been tested with just two instructions:
movb #$80,CRGFLG ;Clear interrupt
* Tested with other code in here too.....
rti
So it is not spending a large amount of time in the routine.
* Interrupt priority level is set up previously to be a "4".
* RTI freq divide = $f7 into RTICTL (with 16 MHz Osc Clock -> 100 ms)
Any ideas as to why RTI is not being processed, or what other
interrupt may be stepping in when RTI is enabled?
Dave
------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
board.) This has the serial monitor programmed into the Flash on the
board.
For ease of use, my program keeps the use of the default vector table
at page $FF in the serial monitor, but has vectors in the
pseudo-vector interrupt table at page $F7.
I have user input/output via SCI0 and a terminal interface. (I can
select when assembling the code whether or not SCI0 uses an
interrupt/buffer scheme, or just polled to handle I/O.)
I have also set up the Real Time Interrupt to trigger every 100 ms.
So, if I set up SCI0 to run in polled mode, and set up RTI without
enabling it, everything works fine. As soon as RTI is enabled though,
(writing $80 to $38 = CRGINT), things go haywire. The RTI is the only
enabled interrupt. However I think that another interrupt is causing
the serial monitor to kick in and take over, since I see strange
characters on the screen from this point forward, until reset.
Other points:
* Interrupts are enabled in the condition code register before doing
write to enable RTI.
* Spurious Interrupt vector set up with code being just an "rti"
instruction.
* Real Time Interrupt routine has been tested with just two instructions:
movb #$80,CRGFLG ;Clear interrupt
* Tested with other code in here too.....
rti
So it is not spending a large amount of time in the routine.
* Interrupt priority level is set up previously to be a "4".
* RTI freq divide = $f7 into RTICTL (with 16 MHz Osc Clock -> 100 ms)
Any ideas as to why RTI is not being processed, or what other
interrupt may be stepping in when RTI is enabled?
Dave
------------------------------------
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Why does enabling Real Time Interrupt on S12XD hork the system? - David Armstrong - Dec 22 14:58:34 2008
Thanks John for your reply.
First of all, an Interrupt Handler for spurious interrupts really can't ack
or disable the interrupt source, since the interrupt source is Unknown.
(Hence the reason it is a "spurious" interrupt.) So an "rti" or increment
counter is really all it can do.
The code doesn't "hang" per se. It just changes what happens on SCI0. So I
don't think a watchdog of COP is what I need here. I don't have a BDM
either. (No $$.)
However you did provide enough for me to try something. I'll set up all the
other interrupt vectors to go to a handler that saves off the source
interrupt vector address somewhere in RAM, and then loops forever with
interrupts disabled. That way I can hit reset once the issue is recreated,
and then examine that one location to see what got called.
Dave
On Mon, Dec 22, 2008 at 11:26 AM, John Hartman (NoICE) <
j...@noicedebugger.com> wrote:
> At 12:05 PM 12/22/08, you wrote:
> >...
>
> >I have also set up the Real Time Interrupt to trigger every 100 ms.
> >...
> >* Spurious Interrupt vector set up with code being just an "rti"
> >instruction.
>
> I have no explicit answer to your problem, just a suggestion:
>
> Just RTI is almost never what you want as a handler for an unused
> interrupt: If the interrupt occurs, you go to the handler. If you
> return without acknowledging or disabling the interrupt source, you
> will come right back in as soon as the RTI completes - the interrupt
> is still pending.
>
> Some more appropriate options might be
>
> 1) Jump to your reset handler. If your code has run amok and somehow
> enabled an interrupt that you didn't want, there is no telling what
> else it might have done. Start over.
>
> 2) Force a watchdog timeout, and let that do a hardware reset. If
> the problem is that the CHIP has run amok (due to cosmic rays, static
> zap, or evil spirits) and caused an interrupt that you didn't ask
> for, the hardware reset might restore its sanity. If I recall
> correctly, your can force the HC12's COP to fire by writing anything
> other then 55 FF to it. If you can't force an immediate watchdog,
> you can usually disable interrupts and enter a spin loop waiting for
> the timeout.
>
> 3) During debugging, have each "unused" handler do something special
> - FOREVER. If you have a BDM pod connected, you can just have each
> handler loop in place (renewing the COP as necessary, since in this
> case you DON'T want the watchdog). When the system stops working,
> use BDM to stop the program and see where you are. In the absence of
> BDM, do a polled output of a string to a serial port. Or flash an
> LED in a particular pattern.
>
> Best regards, John Hartman
> NoICE Debugging Tools
> http://www.noicedebugger.com
>
> [Non-text portions of this message have been removed]
>
>
>
[Non-text portions of this message have been removed]
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
First of all, an Interrupt Handler for spurious interrupts really can't ack
or disable the interrupt source, since the interrupt source is Unknown.
(Hence the reason it is a "spurious" interrupt.) So an "rti" or increment
counter is really all it can do.
The code doesn't "hang" per se. It just changes what happens on SCI0. So I
don't think a watchdog of COP is what I need here. I don't have a BDM
either. (No $$.)
However you did provide enough for me to try something. I'll set up all the
other interrupt vectors to go to a handler that saves off the source
interrupt vector address somewhere in RAM, and then loops forever with
interrupts disabled. That way I can hit reset once the issue is recreated,
and then examine that one location to see what got called.
Dave
On Mon, Dec 22, 2008 at 11:26 AM, John Hartman (NoICE) <
j...@noicedebugger.com> wrote:
> At 12:05 PM 12/22/08, you wrote:
> >...
>
> >I have also set up the Real Time Interrupt to trigger every 100 ms.
> >...
> >* Spurious Interrupt vector set up with code being just an "rti"
> >instruction.
>
> I have no explicit answer to your problem, just a suggestion:
>
> Just RTI is almost never what you want as a handler for an unused
> interrupt: If the interrupt occurs, you go to the handler. If you
> return without acknowledging or disabling the interrupt source, you
> will come right back in as soon as the RTI completes - the interrupt
> is still pending.
>
> Some more appropriate options might be
>
> 1) Jump to your reset handler. If your code has run amok and somehow
> enabled an interrupt that you didn't want, there is no telling what
> else it might have done. Start over.
>
> 2) Force a watchdog timeout, and let that do a hardware reset. If
> the problem is that the CHIP has run amok (due to cosmic rays, static
> zap, or evil spirits) and caused an interrupt that you didn't ask
> for, the hardware reset might restore its sanity. If I recall
> correctly, your can force the HC12's COP to fire by writing anything
> other then 55 FF to it. If you can't force an immediate watchdog,
> you can usually disable interrupts and enter a spin loop waiting for
> the timeout.
>
> 3) During debugging, have each "unused" handler do something special
> - FOREVER. If you have a BDM pod connected, you can just have each
> handler loop in place (renewing the COP as necessary, since in this
> case you DON'T want the watchdog). When the system stops working,
> use BDM to stop the program and see where you are. In the absence of
> BDM, do a polled output of a string to a serial port. Or flash an
> LED in a particular pattern.
>
> Best regards, John Hartman
> NoICE Debugging Tools
> http://www.noicedebugger.com
>
> [Non-text portions of this message have been removed]
>
>
>
[Non-text portions of this message have been removed]
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Why does enabling Real Time Interrupt on S12XD hork the system? - Edward Karpicz - Dec 23 3:51:09 2008
"davidarmstrong72" wrote:
> I've been working on assembly code for S12XDP512. (Technological Arts
> board.) This has the serial monitor programmed into the Flash on the
> board.
>
> For ease of use, my program keeps the use of the default vector table
> at page $FF in the serial monitor, but has vectors in the
> pseudo-vector interrupt table at page $F7.
>
Do you mean you have serial monitor in flash, with serial monitors vector
table at FF10-FFFF. You put your XDP512 vectors are at F710 to F7FF and at
your program entry you write F7 to IVBR?
Isn't your serial monitor using some interrupts? If it is, then did you copy
necessary vectors from serial monitors vector table to your vector table at
F710-F7FF?
Edward
> I have user input/output via SCI0 and a terminal interface. (I can
> select when assembling the code whether or not SCI0 uses an
> interrupt/buffer scheme, or just polled to handle I/O.)
>
> I have also set up the Real Time Interrupt to trigger every 100 ms.
>
> So, if I set up SCI0 to run in polled mode, and set up RTI without
> enabling it, everything works fine. As soon as RTI is enabled though,
> (writing $80 to $38 = CRGINT), things go haywire. The RTI is the only
> enabled interrupt. However I think that another interrupt is causing
> the serial monitor to kick in and take over, since I see strange
> characters on the screen from this point forward, until reset.
>
> Other points:
> * Interrupts are enabled in the condition code register before doing
> write to enable RTI.
> * Spurious Interrupt vector set up with code being just an "rti"
> instruction.
> * Real Time Interrupt routine has been tested with just two instructions:
> movb #$80,CRGFLG ;Clear interrupt
> * Tested with other code in here too.....
> rti
> So it is not spending a large amount of time in the routine.
> * Interrupt priority level is set up previously to be a "4".
> * RTI freq divide = $f7 into RTICTL (with 16 MHz Osc Clock -> 100 ms)
>
> Any ideas as to why RTI is not being processed, or what other
> interrupt may be stepping in when RTI is enabled?
>
> Dave
>
> ------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Why does enabling Real Time Interrupt on S12XD hork the system? - David Armstrong - Dec 23 5:29:13 2008
IVBR has been kept at $FF so the serial monitor would handle all interrupts,
and only transfer to my routines if I had put a vector in the psuedo-vector
table at $F7. However I'm now putting in entries for all the vectors in the
table at $F7 so I can see what got called. (With Christmas, it will take a
few days to run this test.)
Dave
On Tue, Dec 23, 2008 at 1:50 AM, Edward Karpicz wrote:
>
> "davidarmstrong72" wrote:
>
> > I've been working on assembly code for S12XDP512. (Technological Arts
> > board.) This has the serial monitor programmed into the Flash on the
> > board.
> >
> > For ease of use, my program keeps the use of the default vector table
> > at page $FF in the serial monitor, but has vectors in the
> > pseudo-vector interrupt table at page $F7.
> > Do you mean you have serial monitor in flash, with serial monitors vector
> table at FF10-FFFF. You put your XDP512 vectors are at F710 to F7FF and at
> your program entry you write F7 to IVBR?
>
> Isn't your serial monitor using some interrupts? If it is, then did you
> copy
> necessary vectors from serial monitors vector table to your vector table at
>
> F710-F7FF?
>
> Edward
> > I have user input/output via SCI0 and a terminal interface. (I can
> > select when assembling the code whether or not SCI0 uses an
> > interrupt/buffer scheme, or just polled to handle I/O.)
> >
> > I have also set up the Real Time Interrupt to trigger every 100 ms.
> >
> > So, if I set up SCI0 to run in polled mode, and set up RTI without
> > enabling it, everything works fine. As soon as RTI is enabled though,
> > (writing $80 to $38 = CRGINT), things go haywire. The RTI is the only
> > enabled interrupt. However I think that another interrupt is causing
> > the serial monitor to kick in and take over, since I see strange
> > characters on the screen from this point forward, until reset.
> >
> > Other points:
> > * Interrupts are enabled in the condition code register before doing
> > write to enable RTI.
> > * Spurious Interrupt vector set up with code being just an "rti"
> > instruction.
> > * Real Time Interrupt routine has been tested with just two instructions:
> > movb #$80,CRGFLG ;Clear interrupt
> > * Tested with other code in here too.....
> > rti
> > So it is not spending a large amount of time in the routine.
> > * Interrupt priority level is set up previously to be a "4".
> > * RTI freq divide = $f7 into RTICTL (with 16 MHz Osc Clock -> 100 ms)
> >
> > Any ideas as to why RTI is not being processed, or what other
> > interrupt may be stepping in when RTI is enabled?
> >
> > Dave
> >
> >
> >
> > ------------------------------------
> >
> >
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
and only transfer to my routines if I had put a vector in the psuedo-vector
table at $F7. However I'm now putting in entries for all the vectors in the
table at $F7 so I can see what got called. (With Christmas, it will take a
few days to run this test.)
Dave
On Tue, Dec 23, 2008 at 1:50 AM, Edward Karpicz
>
> "davidarmstrong72" wrote:
>
> > I've been working on assembly code for S12XDP512. (Technological Arts
> > board.) This has the serial monitor programmed into the Flash on the
> > board.
> >
> > For ease of use, my program keeps the use of the default vector table
> > at page $FF in the serial monitor, but has vectors in the
> > pseudo-vector interrupt table at page $F7.
> > Do you mean you have serial monitor in flash, with serial monitors vector
> table at FF10-FFFF. You put your XDP512 vectors are at F710 to F7FF and at
> your program entry you write F7 to IVBR?
>
> Isn't your serial monitor using some interrupts? If it is, then did you
> copy
> necessary vectors from serial monitors vector table to your vector table at
>
> F710-F7FF?
>
> Edward
> > I have user input/output via SCI0 and a terminal interface. (I can
> > select when assembling the code whether or not SCI0 uses an
> > interrupt/buffer scheme, or just polled to handle I/O.)
> >
> > I have also set up the Real Time Interrupt to trigger every 100 ms.
> >
> > So, if I set up SCI0 to run in polled mode, and set up RTI without
> > enabling it, everything works fine. As soon as RTI is enabled though,
> > (writing $80 to $38 = CRGINT), things go haywire. The RTI is the only
> > enabled interrupt. However I think that another interrupt is causing
> > the serial monitor to kick in and take over, since I see strange
> > characters on the screen from this point forward, until reset.
> >
> > Other points:
> > * Interrupts are enabled in the condition code register before doing
> > write to enable RTI.
> > * Spurious Interrupt vector set up with code being just an "rti"
> > instruction.
> > * Real Time Interrupt routine has been tested with just two instructions:
> > movb #$80,CRGFLG ;Clear interrupt
> > * Tested with other code in here too.....
> > rti
> > So it is not spending a large amount of time in the routine.
> > * Interrupt priority level is set up previously to be a "4".
> > * RTI freq divide = $f7 into RTICTL (with 16 MHz Osc Clock -> 100 ms)
> >
> > Any ideas as to why RTI is not being processed, or what other
> > interrupt may be stepping in when RTI is enabled?
> >
> > Dave
> >
> >
> >
> > ------------------------------------
> >
> >
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Why does enabling Real Time Interrupt on S12XD hork the system? - Edward Karpicz - Dec 23 6:02:55 2008
Are you sure your serial monitor expects application vectors at F7xx?
Happy Merry Christmas
Edward
----- Original Message -----
From: "David Armstrong"
To: <6...@yahoogroups.com>
Sent: Tuesday, December 23, 2008 12:28
Subject: Re: [68HC12] Why does enabling Real Time Interrupt on S12XD hork
the system?
> IVBR has been kept at $FF so the serial monitor would handle all
> interrupts,
> and only transfer to my routines if I had put a vector in the
> psuedo-vector
> table at $F7. However I'm now putting in entries for all the vectors in
> the
> table at $F7 so I can see what got called. (With Christmas, it will take
> a
> few days to run this test.)
>
> Dave
>
> On Tue, Dec 23, 2008 at 1:50 AM, Edward Karpicz wrote:
>
>>
>> "davidarmstrong72" wrote:
>>
>> > I've been working on assembly code for S12XDP512. (Technological Arts
>> > board.) This has the serial monitor programmed into the Flash on the
>> > board.
>> >
>> > For ease of use, my program keeps the use of the default vector table
>> > at page $FF in the serial monitor, but has vectors in the
>> > pseudo-vector interrupt table at page $F7.
>> >
>>
>> Do you mean you have serial monitor in flash, with serial monitors vector
>> table at FF10-FFFF. You put your XDP512 vectors are at F710 to F7FF and
>> at
>> your program entry you write F7 to IVBR?
>>
>> Isn't your serial monitor using some interrupts? If it is, then did you
>> copy
>> necessary vectors from serial monitors vector table to your vector table
>> at
>>
>> F710-F7FF?
>>
>> Edward
>> > I have user input/output via SCI0 and a terminal interface. (I can
>> > select when assembling the code whether or not SCI0 uses an
>> > interrupt/buffer scheme, or just polled to handle I/O.)
>> >
>> > I have also set up the Real Time Interrupt to trigger every 100 ms.
>> >
>> > So, if I set up SCI0 to run in polled mode, and set up RTI without
>> > enabling it, everything works fine. As soon as RTI is enabled though,
>> > (writing $80 to $38 = CRGINT), things go haywire. The RTI is the only
>> > enabled interrupt. However I think that another interrupt is causing
>> > the serial monitor to kick in and take over, since I see strange
>> > characters on the screen from this point forward, until reset.
>> >
>> > Other points:
>> > * Interrupts are enabled in the condition code register before doing
>> > write to enable RTI.
>> > * Spurious Interrupt vector set up with code being just an "rti"
>> > instruction.
>> > * Real Time Interrupt routine has been tested with just two
>> > instructions:
>> > movb #$80,CRGFLG ;Clear interrupt
>> > * Tested with other code in here too.....
>> > rti
>> > So it is not spending a large amount of time in the routine.
>> > * Interrupt priority level is set up previously to be a "4".
>> > * RTI freq divide = $f7 into RTICTL (with 16 MHz Osc Clock -> 100 ms)
>> >
>> > Any ideas as to why RTI is not being processed, or what other
>> > interrupt may be stepping in when RTI is enabled?
>> >
>> > Dave
>> >
>> >
>> >
>> > ------------------------------------
>> >
>> >
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Happy Merry Christmas
Edward
----- Original Message -----
From: "David Armstrong"
To: <6...@yahoogroups.com>
Sent: Tuesday, December 23, 2008 12:28
Subject: Re: [68HC12] Why does enabling Real Time Interrupt on S12XD hork
the system?
> IVBR has been kept at $FF so the serial monitor would handle all
> interrupts,
> and only transfer to my routines if I had put a vector in the
> psuedo-vector
> table at $F7. However I'm now putting in entries for all the vectors in
> the
> table at $F7 so I can see what got called. (With Christmas, it will take
> a
> few days to run this test.)
>
> Dave
>
> On Tue, Dec 23, 2008 at 1:50 AM, Edward Karpicz
>
>>
>> "davidarmstrong72" wrote:
>>
>> > I've been working on assembly code for S12XDP512. (Technological Arts
>> > board.) This has the serial monitor programmed into the Flash on the
>> > board.
>> >
>> > For ease of use, my program keeps the use of the default vector table
>> > at page $FF in the serial monitor, but has vectors in the
>> > pseudo-vector interrupt table at page $F7.
>> >
>>
>> Do you mean you have serial monitor in flash, with serial monitors vector
>> table at FF10-FFFF. You put your XDP512 vectors are at F710 to F7FF and
>> at
>> your program entry you write F7 to IVBR?
>>
>> Isn't your serial monitor using some interrupts? If it is, then did you
>> copy
>> necessary vectors from serial monitors vector table to your vector table
>> at
>>
>> F710-F7FF?
>>
>> Edward
>> > I have user input/output via SCI0 and a terminal interface. (I can
>> > select when assembling the code whether or not SCI0 uses an
>> > interrupt/buffer scheme, or just polled to handle I/O.)
>> >
>> > I have also set up the Real Time Interrupt to trigger every 100 ms.
>> >
>> > So, if I set up SCI0 to run in polled mode, and set up RTI without
>> > enabling it, everything works fine. As soon as RTI is enabled though,
>> > (writing $80 to $38 = CRGINT), things go haywire. The RTI is the only
>> > enabled interrupt. However I think that another interrupt is causing
>> > the serial monitor to kick in and take over, since I see strange
>> > characters on the screen from this point forward, until reset.
>> >
>> > Other points:
>> > * Interrupts are enabled in the condition code register before doing
>> > write to enable RTI.
>> > * Spurious Interrupt vector set up with code being just an "rti"
>> > instruction.
>> > * Real Time Interrupt routine has been tested with just two
>> > instructions:
>> > movb #$80,CRGFLG ;Clear interrupt
>> > * Tested with other code in here too.....
>> > rti
>> > So it is not spending a large amount of time in the routine.
>> > * Interrupt priority level is set up previously to be a "4".
>> > * RTI freq divide = $f7 into RTICTL (with 16 MHz Osc Clock -> 100 ms)
>> >
>> > Any ideas as to why RTI is not being processed, or what other
>> > interrupt may be stepping in when RTI is enabled?
>> >
>> > Dave
>> >
>> >
>> >
>> > ------------------------------------
>> >
>> >
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )