INT0 not firing.

I have a ISR tied to INT0 on PD2 ( pin 2 of PORTD ). It is not firing as I expect.

I look at the disasm output and see vector_1 in the vector table and a code section <vector_1> matching what I’ve written.

volatile uint8_t inFlagInt=0;

ISR(L6474_FLAG_INT_vect){
    inFlagInt=1;
}

I can introduce a hardware error on the L6474 board that forces the pin low. This is verified on the scope, by an LED on the driver board and by reading the pin PD2 and printing the result.

[#0,#1,#2 status = FE13FE03FE13 ]
FLAG_pin dir; 00
FLAG_pin bit: 04 
inFlagInt:00 ]

// manual trigger error condition here 

[#0,#1,#2 status = FC13FC03FC13 ]
FLAG_pin dir; 00
FLAG_pin bit: 00 
inFlagInt:00 ]

The software shows the pin drops but the ISR does not modify the value of inFlagInt, so I conclude that it is not triggering for some reason.

I’m setting the INT0 interrupt to trigger on falling edge and enabling it like this:

  #define L6474_FLAG_PORT PORTD
  #define L6474_FLAG_DDR DDRD
  #define L6474_FLAG_BIT  2
  #define L6474_FLAG_MASK  (1<<L6474_FLAG_BIT)  // ie =4
  #define L6474_FLAG_PINS  PIND  // r.o. access to PORTD, write sets pull-up
  #define L6474_FLAG_INT_vect   INT0_vect 

  L6474_FLAG_DDR  &= ~ L6474_FLAG_MASK;  // set L6474_FLAG_Pin to Input (leave tri-state, pullup res on board)

  //  EIFR flag off by default , autocleared on exiting ISR
  EICRA |= 0x10;  // set falling edge trigger for INT0
  EIMSK != 0x01;  // enable INT0

sei() gets called just after the above.

I’ve checked the data sheet several times and it seems correct.
Is there anything obviously missing from that part?
Thanks.

I have a ISR tied to INT0 on PD2 ( pin 2 of PORTD ). It is not firing as I expect.

Why are you not using attachInterupt()?

Why are you not using attachInterupt()?

Thanks. This is a modification I'm doing to GRBL. The object code is just under 31kb at the moment. None of it uses the cumbersome arduino libs.

It's speed and size critical and is close to the limits of what can be done on this hardware.

None of it uses the cumbersome arduino libs.

Apparently, you misspelled functional.

It's speed and size critical

Attaching the interrupt handler is speed critical? I must have missed something...

and is close to the limits of what can be done on this hardware.

So, why stick to this hardware? The Due, for instance, has far more memory and far faster.

Good questions.

I'm using this hardware since GRBL provides most of what I need to do. As a first step for developing the hardware it will be sufficient.

I also had an arduino lib that illustrated using a daisy chain of the SPI driven L6474 driver cards which have Arduino pinout format.

That meant I only have to marry the two together to have something to move the hardware. That is mostly done now. I have the chain of three SPI devices communicating nicely with GRBL and have rearranged the port usage on GRBL to free up the SPI port.

Since this will get ported to a more capable platform as soon as I have it properly tested I don't want to build in a dependency on a convoluted jumble like Winterupts.c just to set three or four h/w addresses.

Since _vector_1 is in the jump table and the code with that label is in place, it will get called when it triggers.

So either there's something I've forgotten to do, or something elsewhere is messing it up.

Typo:

  EIMSK != 0x01;  // enable INT0
It's speed and size critical
Attaching the interrupt handler is speed critical? I must have missed something...

"speed and size" , that just leaves size then.

I just added a call to attachInterupt() and it added 240b to the code. As well as messing up the other ISR() code in GRBL :wink:

GRBL avoids using any of arduino libs and does a damned good job of what it gets into a Uno and how fast it runs. I don't intend to evaluate each and every call for speed and size. The standard libs are clunky and not suitable for the task on a Uno, at least.

GRBL avoids using any of arduino libs

So, why not try AVRfreaks?

MarkT:
Typo:

  EIMSK != 0x01;  // enable INT0

LOL ! Crap , how did that sneak in there ?!

I know every comma and semicolon counts in programming but that's the first time I've seen a one pixel bug :wink:

Thanks for pointing out what my tired eyes could not see.

I just spotted that is was not clearing bit 0 either, so it not have always worked.

  L6474_FLAG_DDR  &= ~ L6474_FLAG_MASK;  // set L6474_FLAG_Pin to Input
  EICRA &= ~0b11; 
  EICRA |= 0b10;   // set falling edge trigger.
  EIMSK |= 0x01;  // enable INT0

That now works fine and cost me 24b, not 240b.

Many thanks to MarkT for spotting the pixel bug. I'd looked at that line at least 10 times and only saw what I expected to be there. I probably subconsciously dismissed it as a fly spot on the screen.

( Time for some off-screen work, perhaps :wink: )

Time for some off-screen work, perhaps

Or Windex. 8)

Optrex, more like :wink: ... or a new pair of glasses !