STEVAL-MKI208V1K: Error caused by switching on the pulsed mode.

[VSavenia]

Hi! Since I am not a native speaker, I apologize in advance for my English.

When switching on the pulsed mode strange things start to happen.

Until yesterday I used int1 pad, everything worked fine, but at a certain moment it became necessary to count the ODR in real time and i activated pulsed mode for int2 pad (I am not interested in alternative counting options). I was doing this as it said in datasheet:

-set the dataready_pulsed bit of the COUNTER_BDR_REG1 (0Bh) register to 1

-set int2_drdy_xl bit to 1

/*IIS3DWB interrupt setup register
* \brief acc data-ready interrupt value
*/
static iis3dwb_pin_int2_route_t AccHalIIS3DWBirq2Cfg=
 {
 .drdy_xl = 1, /* Accelerometer data ready */
 .drdy_temp = 0, /* Temperature data ready */
 .fifo_th = 0, /* FIFO threshold reached */
 .fifo_ovr = 0, /* FIFO overrun */
 .fifo_full = 0, /* FIFO full */
 .fifo_bdr = 0, /* FIFO Batch counter threshold reached */
 .wake_up = 0, /* wake up event */
 .sleep_change = 0, /* Act/Inact (or Vice-versa) status changed */
 .sleep_status = 0
};

and then route set to int2.

Code:

/**
* \brief INT2 dataready pulsed mode setup
* \param[in] no
* \param[out] no
* \return int16_t error code, 0 - no errors
*/
static int16_t accHalInt2DrdySignalSet(void)
{
 int16_t status = 0;
 status = iis3dwb_data_ready_mode_set(&AccHalIIS3DWBio, IIS3DWB_DRDY_PULSED);
 if(status) return -1; //Exit: error code -1: pulsed mode setting error
 
 /* Sending parameters to int2 register */
 status = iis3dwb_pin_int2_route_set(&AccHalIIS3DWBio, &AccHalIIS3DWBirq2Cfg);
 if(status) return -2; //Exit: error code -2: int2 route set failed 
 
 return 0; //Exit: 0 - no errors. 
}

I do not use this interrupt anywhere and the MCU does not know about this pad. I want interrupt1 to work as before to read data, and on int2 pad there were pulses to count the ODR, but then after a random period of time, int2 stops pulsing or the signal disappears on both pads. The only interrupt source for int1 pad is the fifo_th_bit of the int1_ctrl register. I call function accHalInt2DrdySignalSet(); only once in init sequence.

Any ideas?

[VSavenia]

Perhaps I did not fully describe the situation, I will be happy to share the details.

[Eleon BORLINI]

Hi @VSavenia​ ,

you said that the day before everything was working and the day after you faced this issue, right?

If so, I'm not sure it is a device issue... Did you try to turn off and on the device at least once?

-Eleon

[VSavenia]

Hi Eleon.

I meant that before I started using both interrupt pins, everything worked well. At any time I can change the version of the code where I work with one interrupt pin and the problem disappears. Only when two interrupt pins are turned ON do "anomalies" appear.

I have a question. When handling an interrupt, I reset the interrupt at the source i.e. at the sensor.

In code it looks like this:

/**
* \brief External IRQ1 Handler
* \param[in] no
* \param[out] no
* \return no
*/
static void accHalIrq1Handler(void)
{
 int32_t retErr = 0;
 iis3dwb_all_sources_t irqsSrcStatusWord;
 iis3dwb_fifo_status2_t fifoIrqsStatusWord;
 
 /* Read irqs sources status registers */
 retErr = iis3dwb_all_sources_get(&AccHalIIS3DWBio, &irqsSrcStatusWord);
 ASSERT(!retErr);
 retErr = iis3dwb_fifo_status_get(&AccHalIIS3DWBio, &fifoIrqsStatusWord);
 ASSERT(!retErr);
 
 /* Checking and processing irqs sources */
 if(fifoIrqsStatusWord.fifo_wtm_ia)
 {
 /* Disable fifo watermark interrupt */
 accHalFifoTresholdIrqDisable();
 
 /* Generate irq event for retrieving data task */
 accHalIrqEventGenerate();
 }
 else
 {
 AccHalIrqsSpuriousCount++;
 }
}

and

/**
* \brief Disables FIFO threshold interrupt on INT 1 pin
* \param[in] no
* \param[out] no
*/
static inline void accHalFifoTresholdIrqDisable(void)
{
 /* Disable fifo watermark interrupt */
 AccHalIIS3DWBirq1Cfg.fifo_th = 0;
 iis3dwb_pin_int1_route_set(&AccHalIIS3DWBio, &AccHalIIS3DWBirq1Cfg); // route interrupt source to the INT1 pin
}

The question is: is it correct that I change the iis3dwb pin_int1_route_t structure on the fly? Maybe this is the problem?