RAK3172 RUI3 Inconsistant Interrupt Attachment

I have placed two active low circuits for PB5 and PA5 (SPI is never initialized). The following is the code extract:

void interrupt_handler() {
  // running something...

void alert_handler() {
  // running something...

// Startup Function called in setup()
void startup_config() {



  pinMode(PB5, INPUT);
  attachInterrupt(PB5, interrupt_handler, FALLING);

  pinMode(PA5, INPUT);
  attachInterrupt(PA5, alert_handler, FALLING);

I tried this code with manually altering the logic levels, but RAK3172 performs in an extremely wierd way as follows:

  1. When the code is run in the same init order, PB5 runs normally, but alert from PA5 can never be called.
  2. When the init code for PB5 is commented out, PA5 runs normally.
  3. When the init code order of the two pins interchanged, PA5 cannot be called but PB5 is calling the alert_handler of PA5.

I have no idea on why this happens only on the SPI pins. Is this situations impliing there is one and only one interrupt allowed for the GPIO5 family, or this is just a limitation of RUI3 init process of the I/O pins? Can I use both of them in the same time.

I will check with the R&D team. It might indeed be a problem with the SPI pins.

Do you have the option to use other pins?

We have PA4 as the alternative for PA5 and it somehow works for the same code. Still, we hope we can also use PA5 interrupt to extend our features supported within the program.

Possible explanation (I did not verify yet).
When using deep sleep, the SPI, I2C and UART pins are de-initialized to reduce power consumption.

Can you try to disable LPM mode with api.system.lpm.set(0); and check whether the interrupts work as expected?

I got this info from another RUI3 user who had problems when he used (unused) UART pins for interrupts.

Just tried commented out api.system.lpm.set(0); The handlers still perform in the same way.

Thanks for checking.
I will let our R&D team know, so they can look into the problem.