Hello,
I am using a Wytec microdragon with serial monitor & trying to get a 25ms
interrupt. I had it working in a previous similar project, so I believe the
code should work. The keypad & lcd work fine. My question is: is there some
input pin that could be affecting the modulus counter?
As soon as the interrupts turn on all control is lost. Any code after
(interrupts_on) is not executed - Jeff
(pll is set to 48mhz)
DDRT=0xFF;
TSCR1 = 0x80; // TIMER ENABLE
MCCTL=0xC7; // MCZI int ena, mod mode ena, mod dwn cntr ena, div/16
MCCNT7500; // should be every .02sec
interrupts_on; // enable the interrupts;
void interrupt 26 handler_MODULUS()
{
MCFLG = 0x80 ; //mod cntr underflow flag
if(PTT_PTT1==0) {PTT_PTT1 = 1;} else {PTT_PTT1 = 0;} // squarewave 20 Hz
}
Modulus down counter not working
Started by ●March 25, 2012
Reply by ●March 26, 20122012-03-26
OK the modulus counter doesnt even need to be enabled or set up.
Just turning on the interrupts seems to cause the lockup problem.
I believe some part of the mcu is generating an interrupt.
Is there any way to find out where it is coming from? Then maybe I can make a handler for it or ignore it somehow. Thanks for any help or suggestions. Jeff
Hello,
>I am using a Wytec microdragon with serial monitor & trying to get a 25ms interrupt. I had it working in a previous similar project, so I believe the code should work. The keypad & lcd work fine. My question is: is there some input pin that could be affecting the modulus counter?
>As soon as the interrupts turn on all control is lost. Any code after (interrupts_on) is not executed - Jeff
>
>(pll is set to 48mhz)
>
>DDRT=0xFF;
>
>TSCR1 = 0x80; // TIMER ENABLE
>MCCTL=0xC7; // MCZI int ena, mod mode ena, mod dwn cntr ena, div/16
>MCCNT7500; // should be every .02sec
>interrupts_on; // enable the interrupts;
>
> void interrupt 26 handler_MODULUS()
>{
> MCFLG = 0x80 ; //mod cntr underflow flag
>
>if(PTT_PTT1==0) {PTT_PTT1 = 1;} else {PTT_PTT1 = 0;} // squarewave 20 Hz
>
>}
>
>
Just turning on the interrupts seems to cause the lockup problem.
I believe some part of the mcu is generating an interrupt.
Is there any way to find out where it is coming from? Then maybe I can make a handler for it or ignore it somehow. Thanks for any help or suggestions. Jeff
Hello,
>I am using a Wytec microdragon with serial monitor & trying to get a 25ms interrupt. I had it working in a previous similar project, so I believe the code should work. The keypad & lcd work fine. My question is: is there some input pin that could be affecting the modulus counter?
>As soon as the interrupts turn on all control is lost. Any code after (interrupts_on) is not executed - Jeff
>
>(pll is set to 48mhz)
>
>DDRT=0xFF;
>
>TSCR1 = 0x80; // TIMER ENABLE
>MCCTL=0xC7; // MCZI int ena, mod mode ena, mod dwn cntr ena, div/16
>MCCNT7500; // should be every .02sec
>interrupts_on; // enable the interrupts;
>
> void interrupt 26 handler_MODULUS()
>{
> MCFLG = 0x80 ; //mod cntr underflow flag
>
>if(PTT_PTT1==0) {PTT_PTT1 = 1;} else {PTT_PTT1 = 0;} // squarewave 20 Hz
>
>}
>
>
Reply by ●March 26, 20122012-03-26
OK I wrote 57 irq handlers & it turns out to be the ext irq #6 was being
triggered for some reason, so I disabled it via INTCR=0x00.
This makes me a bit nervous, is the default operation to just hang the mcu
on unhandled irq's? Is there a solution to proceed past unexpected irq's?
Jeff
This makes me a bit nervous, is the default operation to just hang the mcu
on unhandled irq's? Is there a solution to proceed past unexpected irq's?
Jeff
Reply by ●March 26, 20122012-03-26
Jeff,
How much resistance is pulling up IRQ* pin/connections to pin?
Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Lab (417)836-3770
SPRINGFIELD, MO 65897 USA Dept (417)836-5131
In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.
________________________________________
From: 6... [6...] On Behalf Of j...@bendnet.com [j...@bendnet.com]
Sent: Monday, March 26, 2012 7:33 PM
To: 6...
Subject: [68HC12] Re: Modulus down counter not working
OK I wrote 57 irq handlers & it turns out to be the ext irq #6 was being triggered for some reason, so I disabled it via INTCR=0x00.
This makes me a bit nervous, is the default operation to just hang the mcu
on unhandled irq's? Is there a solution to proceed past unexpected irq's?
Jeff
How much resistance is pulling up IRQ* pin/connections to pin?
Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Lab (417)836-3770
SPRINGFIELD, MO 65897 USA Dept (417)836-5131
In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.
________________________________________
From: 6... [6...] On Behalf Of j...@bendnet.com [j...@bendnet.com]
Sent: Monday, March 26, 2012 7:33 PM
To: 6...
Subject: [68HC12] Re: Modulus down counter not working
OK I wrote 57 irq handlers & it turns out to be the ext irq #6 was being triggered for some reason, so I disabled it via INTCR=0x00.
This makes me a bit nervous, is the default operation to just hang the mcu
on unhandled irq's? Is there a solution to proceed past unexpected irq's?
Jeff
Reply by ●March 26, 20122012-03-26
The action for ANY interrupt is the same: push registers and jump
through the interrupt vector.
If you don't have an interrupt handler at the location the vector
points to, then the processor will execute whatever it DOES find
there. Whether that looks like "hanging" depends on what instruction
the processor finds. And it will usually find something bad...
So you should ALWAYS have a handler for all the interrupt
vectors. In most cases, all the unused vectors can go to the
same place (although as you have found, having unique vectors can be
useful if you can afford the space). Usually, you want to restart
your program, making the assumption that some sort of code runaway or
hardware glitch has caused a spurious interrupt. Many people will
force a COP watchdog, since that will cause a processor reset, to
reset all peripherals.
If you are getting an "external interrupt", it is because that pin is
low (or high, depending on how you have programmed the pin). So
verify that you have correctly programmed all the interrupt sources
before you enable processor interrupts.
At 07:33 PM 3/26/2012, j...@bendnet.com wrote:
>OK I wrote 57 irq handlers & it turns out to be the ext irq #6 was
>being triggered for some reason, so I disabled it via INTCR=0x00.
>This makes me a bit nervous, is the default operation to just hang the mcu
>on unhandled irq's? Is there a solution to proceed past unexpected irq's?
>
Best regards, John Hartman
NoICE Debugging Tools
http://www.noicedebugger.com
through the interrupt vector.
If you don't have an interrupt handler at the location the vector
points to, then the processor will execute whatever it DOES find
there. Whether that looks like "hanging" depends on what instruction
the processor finds. And it will usually find something bad...
So you should ALWAYS have a handler for all the interrupt
vectors. In most cases, all the unused vectors can go to the
same place (although as you have found, having unique vectors can be
useful if you can afford the space). Usually, you want to restart
your program, making the assumption that some sort of code runaway or
hardware glitch has caused a spurious interrupt. Many people will
force a COP watchdog, since that will cause a processor reset, to
reset all peripherals.
If you are getting an "external interrupt", it is because that pin is
low (or high, depending on how you have programmed the pin). So
verify that you have correctly programmed all the interrupt sources
before you enable processor interrupts.
At 07:33 PM 3/26/2012, j...@bendnet.com wrote:
>OK I wrote 57 irq handlers & it turns out to be the ext irq #6 was
>being triggered for some reason, so I disabled it via INTCR=0x00.
>This makes me a bit nervous, is the default operation to just hang the mcu
>on unhandled irq's? Is there a solution to proceed past unexpected irq's?
>
Best regards, John Hartman
NoICE Debugging Tools
http://www.noicedebugger.com
Reply by ●March 28, 20122012-03-28
Gentlemen,
Thank you both for your responses.
I learned quite a bit while thrashing about for the last few days trying to resolve the problem. As it turned out, the pull-up PUCR was not set for port E inputs & the external IRQ input pin was always low.
That certainly confirms my status as a novice, but it sure would have helped if the book I used from Huang had said in BIG BOLD PRINT:
Before you turn on interrupts, make sure to check if the PUCR for the external IRQ is set high, the default is OFF! :)
Jeff
Thank you both for your responses.
I learned quite a bit while thrashing about for the last few days trying to resolve the problem. As it turned out, the pull-up PUCR was not set for port E inputs & the external IRQ input pin was always low.
That certainly confirms my status as a novice, but it sure would have helped if the book I used from Huang had said in BIG BOLD PRINT:
Before you turn on interrupts, make sure to check if the PUCR for the external IRQ is set high, the default is OFF! :)
Jeff
Reply by ●March 29, 20122012-03-29
No, pull up for port E and IRQ is ***enabled by default***. See datasheets.
I don't know what portal are you using to send messages to [68HC12], but it
is not clear who are you are thanking. Are you cutting original messages to
save few bytes, while in >terabytes era?
Edward
----- Original Message -----
From:
To: <6...>
Sent: Wednesday, March 28, 2012 5:38 PM
Subject: [68HC12] Re: Modulus down counter not working
> Gentlemen,
>
> Thank you both for your responses.
> I learned quite a bit while thrashing about for the last few days trying
> to resolve the problem. As it turned out, the pull-up PUCR was not set
> for port E inputs & the external IRQ input pin was always low.
>
> That certainly confirms my status as a novice, but it sure would have
> helped if the book I used from Huang had said in BIG BOLD PRINT:
>
> Before you turn on interrupts, make sure to check if the PUCR for the
> external IRQ is set high, the default is OFF! :)
>
> Jeff
>
>
I don't know what portal are you using to send messages to [68HC12], but it
is not clear who are you are thanking. Are you cutting original messages to
save few bytes, while in >terabytes era?
Edward
----- Original Message -----
From:
To: <6...>
Sent: Wednesday, March 28, 2012 5:38 PM
Subject: [68HC12] Re: Modulus down counter not working
> Gentlemen,
>
> Thank you both for your responses.
> I learned quite a bit while thrashing about for the last few days trying
> to resolve the problem. As it turned out, the pull-up PUCR was not set
> for port E inputs & the external IRQ input pin was always low.
>
> That certainly confirms my status as a novice, but it sure would have
> helped if the book I used from Huang had said in BIG BOLD PRINT:
>
> Before you turn on interrupts, make sure to check if the PUCR for the
> external IRQ is set high, the default is OFF! :)
>
> Jeff
>
>
Reply by ●March 29, 20122012-03-29
Edward,
You are correct, my mistake.
Most of my project is in "C", but the keypad & lcd functions are in assembly (which I tend to avoid).
I finally found my problem which was turning off the port E pullup
and generating the #6 irq in the assembly code:
keypad_enable:
movb #$0f,DDRB ;B7:B4 inputs, B3:B0 outputs
movb #$02,PUCR ;enable pull-up resistors
rts
should be:
movb #$12,PUCR ;enable port B and E pull-up resistors
I guess I should learn how to do |= #$02,PUCR in assembly.
My apologies to Mr. Huang & the group.
Jeff Morrison
****************
Hello,
>I am using a Wytec microdragon with serial monitor & trying to get a 25ms interrupt. I had it working in a previous similar project, so I believe the code should work. The keypad & lcd work fine. My question is: is there some input pin that could be affecting the modulus counter?
>As soon as the interrupts turn on all control is lost. Any code after (interrupts_on) is not executed - Jeff
>
>(pll is set to 48mhz)
>
>DDRT=0xFF;
>
>TSCR1 = 0x80; // TIMER ENABLE
>MCCTL=0xC7; // MCZI int ena, mod mode ena, mod dwn cntr ena, div/16
>MCCNT7500; // should be every .02sec
>interrupts_on; // enable the interrupts;
>
> void interrupt 26 handler_MODULUS()
>{
> MCFLG = 0x80 ; //mod cntr underflow flag
>
>if(PTT_PTT1==0) {PTT_PTT1 = 1;} else {PTT_PTT1 = 0;} // squarewave 20 Hz
>
>}
>
>
You are correct, my mistake.
Most of my project is in "C", but the keypad & lcd functions are in assembly (which I tend to avoid).
I finally found my problem which was turning off the port E pullup
and generating the #6 irq in the assembly code:
keypad_enable:
movb #$0f,DDRB ;B7:B4 inputs, B3:B0 outputs
movb #$02,PUCR ;enable pull-up resistors
rts
should be:
movb #$12,PUCR ;enable port B and E pull-up resistors
I guess I should learn how to do |= #$02,PUCR in assembly.
My apologies to Mr. Huang & the group.
Jeff Morrison
****************
Hello,
>I am using a Wytec microdragon with serial monitor & trying to get a 25ms interrupt. I had it working in a previous similar project, so I believe the code should work. The keypad & lcd work fine. My question is: is there some input pin that could be affecting the modulus counter?
>As soon as the interrupts turn on all control is lost. Any code after (interrupts_on) is not executed - Jeff
>
>(pll is set to 48mhz)
>
>DDRT=0xFF;
>
>TSCR1 = 0x80; // TIMER ENABLE
>MCCTL=0xC7; // MCZI int ena, mod mode ena, mod dwn cntr ena, div/16
>MCCNT7500; // should be every .02sec
>interrupts_on; // enable the interrupts;
>
> void interrupt 26 handler_MODULUS()
>{
> MCFLG = 0x80 ; //mod cntr underflow flag
>
>if(PTT_PTT1==0) {PTT_PTT1 = 1;} else {PTT_PTT1 = 0;} // squarewave 20 Hz
>
>}
>
>
