NEW: Learning electronics? Ask your questions on the new Electronics Questions & Answers site hosted by CircuitLab.
Microcontroller Programming » Application Resetting after Adding Interrupt Handler
September 14, 2012 by jlaskowski |
I'm connecting my ATMega168 to a CC3000 WiFi chip. The start-up sequence is that the MCU raises a line, called power-enable (PWR_EN), on the CC3000 and the CC3000 soon lowers its SPI_IRQ line back to MCU to indicate the CC3000 is ready to talk SPI with the MCU. I have the CC3000's SPI_IRQ connected to PD2. When I raise PWR_EN, I can tell that the CC3000 is lowering SPI_IRQ by polling PD2 and turning on a yellow LED when it goes low:
It worked fine, but I want to have PD2 serviced by an interrupt handler instead of polling PD2 like I do in the above code. So, I added this to my start-up configuration code:
I also added a red LED on PC2 and this code:
...and here's my interrupt handler:
Instead of turning on the red light, it restarts the application. Since the interrupt handler is only triggered on the falling edge, when the application is restarted, SPI_IRQ is already low and so it's not constantly restarting. Any idea why my application is restarting instead of the interrupt handler being executed? Is my handler defined incorrectly? |
---|---|
September 14, 2012 by BobaMosfet |
jlaskowski--
Side Notes: You only need to use '{' adn '}' around compound statements, although sometimes you might put them to avoid confusion in how the code looks. Your top statement could be done using a do...while():
Notice, I don't use an '==' to test against zero? That's because everything is tested against zero. It's either zero, or it isn't. In other words, the statement says "do...while(!zero)". In case that doesn't make sense, '!' = 'not'. Just say 'not' when you see it. As for your problem with it resetting; could be current or code related. I don't know enough about your problem to say more. BM |
September 14, 2012 by BobaMosfet |
Just a thought, as I've been away from this MCU for about 3 months, can your ISR make that call to your routine turn_on_red()? At all? In order for it to call that function, perhaps it's stack frame at the time of ISR code being executed must know about your LED function via the jumptable available to it. There might be something more you need to do, to tell the chip what context you're referring to, to reach that function. BM |
September 14, 2012 by jlaskowski |
Thanks for the "C" programming style tips. I switched from using INT0, which is supposed to allow interrupts on falling edge or rising edge, to a Pin Change Interrupt PCINT, which triggers when the pin value changes. I was able to get that to work:
and here's the interrupt handler:
Since I wanted the interrupt to trigger only on falling-edge (when the PD2 goes from high to low), I can just add a test inside the interrupt handler:
I'm not sure why INT0 didn't work. If anyone can tell, please do. |
September 14, 2012 by Noter |
I think you were setting the wrong interrupt vector so the right one didn't have anything in it thus when the interrupt occurred it reset the mcu. INT0_vect is the correct vector for PD2. The best way to be sure of your vectors is to look at them in the iom168p.h include file.
This is from iom168p.h:
|
September 15, 2012 by jlaskowski |
I'm sure that's it! I had PCINT0 instead of INT0. Thanks! |
Please log in to post a reply.
Did you know that you can build a giant scrolling LED array with our microcontroller kit? Learn more...
|