Hello everyone,
We tried to follow the IMXRT1176 reference manual to gain access to GPIO_DISP_B2_00 pin from CM7 core.
gpio_pin_config_t config = {
kGPIO_DigitalInput,
0,
kGPIO_IntRisingEdge,
};
SETUP(IOMUXC_GPIO_DISP_B2_00_GPIO_MUX5_IO01, 1, AD_PULL_UP + AD_SLEW_SLOW);
GPIO_PinInit(GPIO5, 1, &config );
This happens in the pin_mux during the start-up. Somewhere later in our application we code which initialises the interrupt for that gpio:
GPIO_PortClearInterruptFlags(GPIO5, 0xFFFFFFFF);
GPIO_PortEnableInterrupts(GPIO5, 1 << 1);
NVIC_SetPriority(GPIO5_Combined_0_15_IRQn, configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY);
EnableIRQ(GPIO5_Combined_0_15_IRQn);
volatile uint32_t a = GPIO_PortGetInterruptFlags(GPIO5);
PRINTF("%lu\r\n", a);
This code prints:
4 294 901 757
Which is
0x FFFE FFFD --> 0b1111 1111 1111 1110 1111 1111 1111 1101
As you can see it looks like the pin 1 bit is 0. So we can assume reset affected it.
However what i don't get, is why are the other bits set to 1, and why is bit 17 set to 0?
Reference manual states 1402/6259:
```
Interrupt status bits
Bit n of this register is asserted (active high) when the active condition (as determined by the
corresponding ICR bit) is detected on the GPIO input and is waiting for service. The value of this register
is independent of the value in IMR register.
When the active condition has been detected, the corresponding bit remains set until cleared by software.
Status flags are cleared by writing a 1 to the corresponding bit position
```
So i would assume that all values should be 0 as it's default reset state. Other GPIOs also follow somewhat similar pattern and have many bits set in it's ISR register.
Could someone point me to what i misunderstand here? Thanks in advance for any help
Best Regards,
Jakub
Hi @jslota13245 ,
The misunderstanding is that the GPIO ISR reset value only describes the register state immediately after reset. It is not a guarantee of what software will read later during boot. The ISR is a latched status register: once the configured condition is detected, the bit stays set until software clears it, and this is independent of IMR. To determine which interrupt sources are currently enabled, we can use: GPIOx->ISR & GPIOx->IMR;
For RT1170, NXP also documents erratum ERR050643: DISP_B2 pins can see a brief internal pull-up pulse during initial power-up, so GPIO_DISP_B2_00 may legitimately have a pending status before the application reads the ISR. Therefore, a non-zero ISR after startup does not mean reset failed.
Best regards,
Gavin
Dear @Gavin_Jia,
thank you very much for detailed response. Your message has cleared up few things.
1) Just to confirm, as you could've noticed, in the example code i sent before, we explicitly write 0xffff ffff to status register to clear it, we do some no operation cycles, after that operation we almost immediately try to read it and get non-zero values in GPIO->ISR. That would mean that hardware has registered interrupt condition on most of pins between clear/read calls, which is hard to believe, since we don't even use them. This happens after the early start-up when GPIOs are initialized. So what you're suggesting is there is some hardware noise that may cause this behaviour when we write 0xffffffff to GPIO->ISR?
2) By the way, reading forums i found this thread:
https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/GPIO-ISR-and-Clearing-ISR/m-p/1059441
With this answer:
''In your case you need to beware that the interrupt status of bits that are not configured for interrupt operation will read as being pending. Therefore you can not use just a check of the interrupt status like''
I was wondering if it's true because it somewhat fits the observed behavior. However I couldn't find anything about it in reference manual.
Once again thank you very much for your support!
Best Regards,
Jakub