ATMega interrupts using avr's libc is failing

[mstacho]

And failing horribly.  Ultimately, my interrupts just aren't firing at all.  Here's the deal, though: the SPI code I'm working with works fine without interrupts (just polling the SPIF).  So I know that the sending and wiring works.  Here is how I'm doing this:

I've basically stripped it bare: all it is supposed to do is turn an LED off once the interrupt fires.  It's on initially.

Code: [Select]

#include WhateverINeedToMakeThisCompile

void appInitHardware(void)
{
SNIP
//Initialize SPI.
SPCR = (1<<SPE) | (1 << SPIE);

//turn on global interrupts
sei();
}

//Now make an interrupt handling function
ISR(SPI_STC)
{
pin_set(LEDPIN, FALSE);
}

SO, in theory, what this should do is just turn the LED off once the interrupt fires.  But what actually happens is...the LED stays on forever.  I know that the master is sending, because it hangs in a while loop until it's done sending, and it turns LEDs on and off whether it's sending or not, so all is well there.

I'm going to guess I'm not setting up my interrupts correctly at all.  But what is it that isn't right?

**EDIT: I keep forgetting how to get the

Code: [Select]

block working :-P

MIKE

[joe61]

What's your main() look like? You're not setting it again in the main loop or anything right? Can you post the whole program?

How did you verify the connection between the master and slave?

Joe

[mstacho]

I posted the code below.  I'm using webbot, so it relies relatively heavily on its own functions.  I generally don't reset anything related to the interrupt in this version of the code.

The connection between master and slave worked well when I wasn't using interrupts: I just polled SPDR, and turned the LED on when its value was 1, and off when it was 0.  The slave and the master, at that point, should have turned their LEDs on and off at the same time, and that's what happened.  If it matters, both chips are ATMega644s, and there is an LED on PB0 for both of them.

Here is the code:

Code: [Select]


#define F_CPU 16000000UL //CPU Frequency
#define LEDPIN B0
#define MOSIPIN B5
#define MISOPIN B6
#define SCKPIN B7
#define SSPIN B4

#include <avr/interrupt.h>
#include <avr/io.h>
#include <avr/signal.h>
#include "sys/atmega644.h"
#include "i2cBus.h"
#include "iopin.h"

//global variables
char readt;


//Apparently we're allowed to interrupt like this
ISR(SPI_STC_vect)
{
//So, if SPI_STC_vect has triggered, it means that communication is done.  So let's set readt.
readt = SPDR;
pin_set(LEDPIN,FALSE);
delay_ms(2000);
}

void appInitHardware(void)
{
pin_make_input(MOSIPIN,FALSE);
pin_make_input(SCKPIN,FALSE);
pin_make_input(SSPIN,TRUE); //I believe it's LOW to select...

pin_make_output(MISOPIN,FALSE);
pin_make_output(LEDPIN,FALSE);
//initialize SPI.  SPE == SPI Enable.  SPIE == SPI INTERRUPT Enable
SPCR = (1<<SPE) | (1 << SPIE);
sei(); //Uh...this enables interrupts in general?
}

TICK_COUNT appInitSoftware(TICK_COUNT loopStart)
{

return 0;
}

TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart)
{
pin_set(LEDPIN,TRUE);
// while(!(SPSR & (1<<SPIF)))
// {
// ;
// }
// if(readt == 1)
// ;
//pin_set(LEDPIN,TRUE);

return 20000;
}


Maybe my interrupts just aren't doing anything?

[joe61]

I'm at work now and can't look at it very closely, but if this is using webbotlib, check to see if the library is setting things up in a way that turns off the interrupt. I'm not familiar with that library, so this is just a guess.

I'll take a closer look a bit later when I get home.

Joe

[joe61]

I downloaded webbotlib and took a look at the code to see if it sets anything related to this interrupt, but didn't see anything. Some observations though.

Delaying 2 seconds in an interrupt service routine isn't a good idea. In this case there's apparently nothing else going on, but the interrupt routine should be as fast as possible.

I don't see where you set the data mode for the transfer. If the default is the same as what the master is using that's probably ok, but something to check. I doubt that would keep the interrupt from happening though.

Are you getting an end of transmission interrupt in the master device? Try uncommenting the lines in the appControl function and toggle the LED if you see SPIF go high there.

I don't see anything that looks like an error. Do you have a schematic for the system? It might be a connection issue somewhere.

Sorry I can't help more.

Joe

[mstacho]

Thanks a lot.  I'm going to guess then that there's just a bit of weirdness going on that I'll have to check out.  If I'm doing everything like I should be, then you're probably right about the connection error. 

I'll have a look at it tomorrow,

thanks!