LPC1347 - Group interrupt, can't read pin

[lpcware]

Content originally posted in LPCWare by andrewgatt on Mon Jun 08 09:43:15 MST 2015
Hi,

I'm using the grouped interrupt to check on two pins, here's the set up code.

    pPin_t IRQ0;
    IRQ0.bit = 13;
    IRQ0.port = 1;
    IRQ0.pGPIO = LPC_GPIO_PORT;

    // configure IRQ1
    pPin_t IRQ1;
    IRQ1.bit = 15;
    IRQ1.port = 1;
    IRQ1.pGPIO = LPC_GPIO_PORT;

    Chip_IOCON_PinMuxSet(LPC_IOCON, IRQ0.port, IRQ0.bit, (IOCON_MODE_PULLDOWN | IOCON_HYS_EN));
    Chip_IOCON_PinMuxSet(LPC_IOCON, IRQ1.port, IRQ1.bit, (IOCON_MODE_PULLDOWN | IOCON_HYS_EN));

    Chip_Clock_EnablePeriphClock(SYSCTL_CLOCK_GROUP0INT);
    uint32_t pins = PININTCH(IRQ0.bit) | PININTCH(IRQ1.bit);

    Chip_GPIOGP_SelectHighLevel(LPC_GPIO_GROUP_INT0, 0, IRQ1.port, pins);
    Chip_GPIOGP_EnableGroupPins(LPC_GPIO_GROUP_INT0, 0, IRQ1.port, pins);
    Chip_GPIOGP_SelectOrMode(LPC_GPIO_GROUP_INT0, 0);
    Chip_GPIOGP_SelectEdgeMode(LPC_GPIO_GROUP_INT0, 0);

    NVIC_EnableIRQ(GINT0_IRQn);

If I set up a basic toggle LED on interrupt these seem to be working fine when I manually toggle the inputs. But when I use it with an SPI device that has IRQ lines I can't seem to read the correct pin levels. I've checked the voltages using a scope and both go high at exactly (I've gone down on the scope as fast as I can go and I see no time difference) the same time. This does create an interrupt, but when I read both the pins using this function

Chip_GPIO_GetPinState(pin->pGPIO, pin->port, pin->bit);

It tells me that one of the pins is still low. This physically isn't the case, I've verified it with both a scope and a logic analyser and there is a full 10uS between the interrupt being called and the pins being read.

So my question is, is there some mechanism where reading the port byte does NOT reflect what is happening at the pin. I'm wondering if the interrupt is triggered from one pin, the interrupt code is executed and I can't get a full picture of the port pins until the interrupt is cleared. If I debug the code and break where it reads one pin, it always successfully reads the second, so it must be some kind of timing.

Any ideas, this is a bit of a head scratcher? I know I can change these to individual interrupts, but in this instance it is convenient to use them as a grouped interrupt and I can see no reason why it shouldn't work.

Thanks

Andrew

[lpcware]

Content originally posted in LPCWare by andrewgatt on Wed Jun 10 12:27:56 MST 2015
Annoyingly this is the second time an undiscovered capacitor has screwed up my timing, so I really should have spotted it. There are a lot of jumpers on this board though and this time scoping it at the expansion connector didn't it up.

OK I wont stop using the debugger in ISRs then, just wamted to check there wasn't anything fundamentally wrong with the process.

[lpcware]

Content originally posted in LPCWare by R2D2 on Wed Jun 10 02:03:26 MST 2015

---

Quote: andrewgatt
...used breakpoints extensively inside the CAN bus ISR with no problems, so what kind of issues can I expect?

---

In your case I was assuming that hardware problems (a bouncing button) would cause unexpected behaviour...

So NVIC (especially tail chaining and interrupt priorities) and optimization can generate a confusing debug behaviour  :O

Therefore I recommend to avoid breakpoints in interrupts in such cases...

Of course there's nothing wrong with breakpoints in interrupts in general, especially if optimization is switched off and there's only one interrupt enabled (what's not clear without seeing the project)  :) 

[lpcware]

Content originally posted in LPCWare by andrewgatt on Wed Jun 10 01:13:03 MST 2015
OK so it turned out to be hardware. I thought I'd traced the input, but I missed a cap on the base board. So when I was scoping the signal, I wasn't getting a true representation of what was going on at the processor. P1_13 needs J33 unconnected on the embedded artists base board. Once done all is working well.

Can I ask you to expand on the problems with using the debugger in an ISR? I completed a previous project with an LPC1769 and used breakpoints extensively inside the CAN bus ISR with no problems, so what kind of issues can I expect?

Thanks.

[lpcware]

Content originally posted in LPCWare by R2D2 on Mon Jun 08 12:39:04 MST 2015
I'm not sure how you trigger your pins in detail, but  I would strongly recommend to add a counter to check how often your interrupt has been triggered 

volatile uint16_t counter;

void GINT0_IRQHandler(void)
{
   Chip_GPIOGP_ClearIntStatus(LPC_GPIO_GROUP_INT0, 0);

...
   counter++;
}

Also I would avoid to set breakpoints in an ISR, especially before Chip_GPIO_GetPinState...

[lpcware]

Content originally posted in LPCWare by andrewgatt on Mon Jun 08 12:07:20 MST 2015
OK I've attached the smallest amount of code that replicates the probllem. I've got P1_13 and P1_15 physically tied together and I apply +3.3V to them (bit of wire plugged into +3.3V scientifically applied with my fingers!).

When you apply +3.3V to the pins, the interrupt fires, but the condition on both Chip_GPIO_GetPinState calls returning 1 is not met, when running normally. However if you put a break point at line 46 while applying +3.3V to both pins, then step through the code, both Chip_GPIO_GetPinState calls return true and the LED toggles.

I used the latest LPCOpen and copied this file over the periph_grouped_int example, as I don't have my own project going yet.

I hope this is enough to go on. I should add that this is in debug mode with optimisation turned off completely -O0. C only with redlib. And I should also add thank you for taking the time to look into this.

[lpcware]

Content originally posted in LPCWare by R2D2 on Mon Jun 08 11:03:35 MST 2015
I'm not sure what you are doing in detail  :((

Could be useful to post your project to understand your ISR and project settings...

[lpcware]

Content originally posted in LPCWare by andrewgatt on Mon Jun 08 10:37:54 MST 2015
I can't use this because sometimes the SPI device will only set one pin depending on the outcome of operation. Also the Or mode interrupt is firing at the right time.

What really confuses me is that reading the pin byte, which the manual states reads the hardware regardless of any other setting, is reading a 0 when I can see the input is at 3.3V.

[lpcware]

Content originally posted in LPCWare by R2D2 on Mon Jun 08 10:04:42 MST 2015

---

Quote: andrewgatt
Any ideas...

---

And-Mode  :quest: