lpcware

LPC1347 - Group interrupt, can't read pin

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by 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

Outcomes