Pin interrupt triggered without transitioning from HI-to-LOW

RE: Pin interrupt triggered without transitioning from HI-to-LOW

Håkon Alseth — Thu, 24 Oct 2019 11:03:58 GMT

You are doing quite a lot of processing and log printing in this handler, so if you're waking up every 1.3 ms, the log printing alone will account for quite some time.

Try toggling a pin inside the handler, and for debugging purposes; keep the function small, and see how often it toggles using a logic analyzer / oscilloscope.

RE: Pin interrupt triggered without transitioning from HI-to-LOW

Wael — Wed, 23 Oct 2019 16:32:58 GMT

Hi Håkon

I did and it works. but I do not see any current difference between the high and low accuracy. you can see from the plot below the cpu never goes to sleep. the interrupt handler gets triggered very 1.3 ms. the average current for bothe low and high accuracy look the same.

this is what I do in my init_gpio function

    nrfx_gpiote_in_config_t adc_drdy_pin_config = NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(false);
    NRFX_IRQ_DISABLE(GPIOTE_IRQn); // disable the GPIOTE IRQs
    //nrfx_gpiote_in_uninit(SPI_MISO_PIN); // uninit this pin, else we get error
    adc_drdy_pin_config.pull = NRF_GPIO_PIN_PULLUP;
    err_code = nrf_drv_gpiote_in_init(SPI_MISO_PIN, &adc_drdy_pin_config, adc_drdy_interrupt_handler);
    APP_ERROR_CHECK(err_code);
    nrfx_gpiote_in_event_enable(SPI_MISO_PIN, false);
    nrf_gpiote_event_clear(NRF_GPIOTE_EVENTS_PORT); // clear the spontanious interrupt that was triggered from calling nrfx_gpiote_in_event_enable()
    NRFX_IRQ_ENABLE(GPIOTE_IRQn); // enable the GPIOTE IRQs	
    
    
this is my interrupt handler

static void adc_drdy_interrupt_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
    uint32_t       sensor_data = 0;
    uint32_t       dStatus = 0;
    uint32_t       dCRC = 0;
    uint32_t       cCRC = 0;
    ret_code_t     err_code = 0;
  
    NRF_LOG_INFO("Interrupt Counter = %d\n", app_timer_cnt_get());
    nrfx_gpiote_in_event_enable(SPI_MISO_PIN, false);
    nrf_gpiote_event_clear(NRF_GPIOTE_EVENTS_PORT); // clear the spontanious interrupt that was triggered from calling nrfx_gpiote_in_event_enable()      
    CRITICAL_REGION_ENTER();
    sensor_data = dataRead(&dStatus, &dCRC);
    cCRC = compute_adc_crc8(sensor_data, dStatus);
  
    if(cCRC != dCRC)
    {
        NRF_LOG_INFO("Received CRC does NOT match calculated CRC! S%d, ADC DATA = 0x%X, recCRC = 0x%X, cCRC = 0x%X, Status = 0x%X", m_adc_sensor_number, sensor_data, dCRC, cCRC, dStatus);
        return;
    }
    
    CRITICAL_REGION_EXIT();  
    
    NRF_LOG_INFO("S%d ADC DATA = 0x%X\n", m_adc_sensor_number, sensor_data);
    switch(m_adc_sensor_number)
    {
      case 1:
        registers[INPMUX_ADDR_MASK]= ADS_P_AIN2 | ADS_N_AIN3;     // S2  
        regWrite(INPMUX_ADDR_MASK, registers[INPMUX_ADDR_MASK]);
      
        read_strain_gauge_data_result[0] = (uint8_t)((sensor_data >> 16) & 0xFF);
        read_strain_gauge_data_result[1] = (uint8_t)((sensor_data >> 8) & 0xFF);
        read_strain_gauge_data_result[2] = (uint8_t)(sensor_data & 0xFF);      
        m_adc_sensor_number++;
        break;
      case 2:
        registers[INPMUX_ADDR_MASK]= ADS_P_AIN4 | ADS_N_AIN5;     // S3
        regWrite(INPMUX_ADDR_MASK, registers[INPMUX_ADDR_MASK]);
      
        read_strain_gauge_data_result[3] = (uint8_t)((sensor_data >> 16) & 0xFF);
        read_strain_gauge_data_result[4] = (uint8_t)((sensor_data >> 8) & 0xFF);
        read_strain_gauge_data_result[5] = (uint8_t)(sensor_data & 0xFF);
        m_adc_sensor_number++;
        break;
      case 3:
        registers[INPMUX_ADDR_MASK]= ADS_P_AIN6 | ADS_N_AIN7;   // S4
        regWrite(INPMUX_ADDR_MASK, registers[INPMUX_ADDR_MASK]);
      
        read_strain_gauge_data_result[6] = (uint8_t)((sensor_data >> 16) & 0xFF);
        read_strain_gauge_data_result[7] = (uint8_t)((sensor_data >> 8) & 0xFF);
        read_strain_gauge_data_result[8] = (uint8_t)(sensor_data & 0xFF);
        m_adc_sensor_number++;
        break;
      case 4:
        registers[INPMUX_ADDR_MASK]= ADS_P_AIN8 | ADS_N_AIN9;   // S5
        regWrite(INPMUX_ADDR_MASK, registers[INPMUX_ADDR_MASK]);
      
        read_strain_gauge_data_result[9] = (uint8_t)((sensor_data >> 16) & 0xFF);
        read_strain_gauge_data_result[10] = (uint8_t)((sensor_data >> 8) & 0xFF);
        read_strain_gauge_data_result[11] = (uint8_t)(sensor_data & 0xFF);
        m_adc_sensor_number++;
        break;
      case 5:
        registers[INPMUX_ADDR_MASK]= ADS_P_AIN10 | ADS_N_AIN11; // S6
        regWrite(INPMUX_ADDR_MASK, registers[INPMUX_ADDR_MASK]);
      
        read_strain_gauge_data_result[12] = (uint8_t)((sensor_data >> 16) & 0xFF);
        read_strain_gauge_data_result[13] = (uint8_t)((sensor_data >> 8) & 0xFF);
        read_strain_gauge_data_result[14] = (uint8_t)(sensor_data & 0xFF);
        m_adc_sensor_number++;
        break;
      case 6:
        registers[INPMUX_ADDR_MASK]= ADS_P_AIN0 | ADS_N_AIN1; // S1
        regWrite(INPMUX_ADDR_MASK, registers[INPMUX_ADDR_MASK]);
      
        read_strain_gauge_data_result[15] = (uint8_t)((sensor_data >> 16) & 0xFF);
        read_strain_gauge_data_result[16] = (uint8_t)((sensor_data >> 8) & 0xFF);
        read_strain_gauge_data_result[17] = (uint8_t)(sensor_data & 0xFF);
        m_adc_sensor_number = 1;
        break;
      default:
        NRF_LOG_ERROR("Unknown Sensor number! Sensor Number = %d\n.", device_operating_second_count);
        break;
    } 
    nrfx_gpiote_in_event_enable(SPI_MISO_PIN, true);
    nrf_gpiote_event_clear(NRF_GPIOTE_EVENTS_PORT); // clear the spontanious interrupt that was triggered from calling nrfx_gpiote_in_event_enable()
    
}

RE: Pin interrupt triggered without transitioning from HI-to-LOW

Håkon Alseth — Mon, 21 Oct 2019 12:57:37 GMT

[quote user="whazin"]also, how can I make sure they are on different GPIOTE_IN channels?[/quote]

For the PORT event (high_accuracy = false), there's no dedicated channel. All pins, configured with SENSE, will generate a EVENTS_PORT.

RE: Pin interrupt triggered without transitioning from HI-to-LOW

Håkon Alseth — Mon, 21 Oct 2019 12:55:53 GMT

Hi,

[quote user="whazin"]calling nrfx_gpiote_in_event_enable always seem to trigger the PORT event, even when it was already handled before. this does not make any sense. Does the nrfx_gpiote_in_event_enable function suppose to trigger the interrupt handler when the pin is configured for a high-to-low transition? the pin is low when the handler is triggered and never transitioned from high-to-low. I tried using the NRF_GPIO_PIN_PULLUP which does nothing since the ADC is keeping the pin low until it is configured and operating. Are there any configurations I am missing in the sdk_config file to setup the port event? this issue is killing our device power so please any help is greatly appreciated.[/quote]

When you are reconfiguring, did you try the workaround as posted in the thread you linked to? Ie: clearing the event, then enabling it.

Kind regards,

Håkon

RE: Pin interrupt triggered without transitioning from HI-to-LOW

Wael — Fri, 18 Oct 2019 17:11:32 GMT

also, how can I make sure they are on different GPIOTE_IN channels?

RE: Pin interrupt triggered without transitioning from HI-to-LOW

Wael — Fri, 18 Oct 2019 14:55:39 GMT

Hi Håkon:

Thanks for the reply! yes, I am assigning the same pin to both the MISO and ADC interrupt GPIO. This works when using high accuracy and according to the above link, the SPI driver takes over the pin when needed which I can confirm since the it works. I also disable the event in the interrupt handler with

nrfx_gpiote_in_event_enable(SPI_MISO_PIN, false);

prior to executing any SPI transactions.

moreover, when NOT using high accuracy, the handler is getting triggered before I even configure my SPI pins. according to this link,

https://devzone.nordicsemi.com/f/nordic-q-a/39768/port-event-interupt-while-sensed-pin-is-active/156280#156280

calling nrfx_gpiote_in_event_enable always seem to trigger the PORT event, even when it was already handled before. this does not make any sense. Does the nrfx_gpiote_in_event_enable function suppose to trigger the interrupt handler when the pin is configured for a high-to-low transition? the pin is low when the handler is triggered and never transitioned from high-to-low. I tried using the NRF_GPIO_PIN_PULLUP which does nothing since the ADC is keeping the pin low until it is configured and operating. Are there any configurations I am missing in the sdk_config file to setup the port event? this issue is killing our device power so please any help is greatly appreciated.

Regards,

RE: Pin interrupt triggered without transitioning from HI-to-LOW

Håkon Alseth — Fri, 18 Oct 2019 11:28:25 GMT

Hi,

Are you assigning the same GPIO to be MISO, and GPIOTE_IN channel? That would be a pin conflict if both SPIM and GPIOTE is enabled at the same time.

Is the pin floating externally? Your current configuration does not enable any pull-resistor, so if there's nothing external to pull the pin to a defined level, the event is very likely to occur.

Kind regards,

Håkon

RE: Pin interrupt triggered without transitioning from HI-to-LOW

Wael — Thu, 17 Oct 2019 16:23:39 GMT

also, the interrupt handler shows that its the MISO pin that is triggering the event. Note, I do not execute any SPI read/write functions up to this point.