Strange nRF52833DK behaviour with nRF Connect SDK 2.3.0

Dear Support Team,

I recently started evaluating a nRF52833 DK board with the nRF Connect SDK 2.3.0. 

I noticed a very strange behaviour while developing an ADXL accelerometer driver with interrupt handling. This is the setup and the symptoms:

Interrupt is configured on pin 4:

// dts file IRQ pin 
custom_gpios {
	 compatible = "gpio-keys";

	 acc_irq_pin1: acc_irq_pin_1 {
		gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
		label = "ACC IRQ pin";
    };  
};


// handler
void ADXL_IRQhandler(const struct device *dev, struct gpio_callback *cb, uint32_t pins)
{
	if(gpio_pin_get_dt(&sIRQ_pin) == 0)
	{
		printk("Inactivity interrupt\n");
	}
	else
	{
		printk("Activity interrupt\n");
	}
}

//IRQ setup
int32_t ADXL_initIRQ(void)
{
  
	if (!device_is_ready(sIRQ_pin.port)) 
	{
		printk("Error: gpio device %s is not ready\n", sIRQ_pin.port->name);
		return -1;
	}


	if (gpio_pin_configure_dt(&sIRQ_pin, GPIO_INPUT) != 0) 
	{
		printk("Error: failed to configure %s pin %d\n", sIRQ_pin.port->name, sIRQ_pin.pin);
		return -2;
	}

	if (gpio_pin_interrupt_configure_dt(&sIRQ_pin, GPIO_INT_EDGE_BOTH) != 0) 
	{
		printk("Error: failed to configure interrupt on %s pin %d\n", sIRQ_pin.port->name, sIRQ_pin.pin);
		return -3;
	}

    gpio_init_callback(&sIRQ_callback, ADXL_IRQhandler, BIT(sIRQ_pin.pin));

    if (gpio_add_callback(sIRQ_pin.port, &sIRQ_callback)!= 0) 
	{
		printk("Error: failed to add ACC IRQ callback\n");
		return -4;
	}
        
    return 0;
}

After freshly flashing the MCU everything works fine, interrupt handling is great, no problems. Until I power down the kit... when it is repowered again interrupt handling stops working completely and even resetting the board won't help. But when re-flashing the exact same firmware it starts working again!

Do you have any guess why this is happening?

Thank you and all the best,

Viktor

Parents
  • Hello Viktor,

    I can't tell what's wrong from your snippet. Did you try to debug the application after the power cycle? How about logs? Do you see any logs? Try adding a piece of logging at the very start of your main() to see if this is even reached.

    If you are replicating this issue on nRF52833 DKs, would it be possible to upload the application folder here so that I can try to replicate the same behavior on my desk?

    Best regards,

    Edvin

  • Hello Edvin!

    Thank you very much for the reply! In the meantime I figured out that the source of the strange behavior is not the DK but the accelerator triggering the interrupt.

    Thank again and sorry for wasting you time! :) From my side this case can be deleted!

    All the ebst,

    Viktor

Reply Children
Related