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?

[VSavenia]

When data required i use:

//preparation before execution
//... 
//... 
  // : enable watermak treshold interrupt
    accHalFifoTresholdIrqEnable();
//...
//...
// end of the preparation 

static inline void accHalFifoTresholdIrqEnable(void)
{
    /* Disable fifo watermark interrupt */
    AccHalIIS3DWBirq1Cfg.fifo_th = 1;
    iis3dwb_pin_int1_route_set(&AccHalIIS3DWBio, &AccHalIIS3DWBirq1Cfg); // route interrupt source to the INT1 pin
}

and when data is retrieved i use

//stop execution procedures
//... 
//... 
    /* Disable fifo watermark interrupt */
    accHalFifoTresholdIrqDisable();
//...
//...

I didn't saw in datasheet that i need to go to something like powerdown mode before starting to change this params, correct if i am wrong.

[Eleon BORLINI]

HI @VSavenia​ ,

>> I didn't saw in datasheet that i need to go to something like powerdown mode before starting to change this params, correct if i am wrong.

Well, it depends on how the switch between the interrupts is performed...

In the Github code, before configuring an interrupt a reset step such as the following one is drawn:

  /* Restore default configuration */
  iis3dwb_reset_set(&dev_ctx, PROPERTY_ENABLE);
 
  do {
    iis3dwb_reset_get(&dev_ctx, &rst);
  } while (rst);

Are you using a latched or a pulsed interrupt (if not configured, the default is pulsed)?

-Eleon

[VSavenia]

Sorry for late answer, we was searching the problem, but found nothing.

Well, when i configure interrupt settings and others i do reset and all procedures that describes in application note in chapter 4.1.

As i said i used pulsed mode. My purpose is to use the int1 pad for reading procedure interrupt caused by fifo_th bit of INT1_CTRL and to use int2 pad to count real-time ODR value by setted drdy_xl = 1 of INT2_CTRL and i want all to be parallel. But as i said, when we turn on two interrupt pins we've got abnormal work of steval board.

Is it even possible to use two pins at the same time?

[Eleon BORLINI]

Hi @VSavenia​ ,

there should not be problems in using both interrupts at the same time.

Did you check if you are able to check if the event flags have been raised in the INT1_ DRDY_XL bit of the INT1_CTRL (0Dh) register and in the INT2_ FIFO_TH bit of the INT2_CTRL (0Eh) register, in the case you don't route the two interrupts on the physical INT1 and INT2 pins?

An alternative could be use the same INT (for example, INT2) in an AOI configuration, polling the above mentioned registers to understand which of the two interrupts has been raised.

-Eleon

[VSavenia]

After activating the data ready interrupt on any INT1 or INT2 pad (we tested both), we have abnormal work of microcircuit i can't explain all situations that we had because everytime it's something new for example one case out of many: when enabling drdy_xl we start catching spurious interrupts. When we catch them, we checked the event flags of INT2_CTRL in the irq handler and found the setted bits that we did not set, namely int2_ctrl drdy_temp bit = 1, we also found the set bits in other registers after reading, which in principle we do not change during the operation of the entire program, such as int2_ctrl not used bits, we have a suspicion that after activating the data ready interrupt in the microcircuit itself, noise is created on the other lines, which provokes arbitrary writing of bits to the registers, because before enabling data ready interrupt mode all pads looks clean and almost has no noise and after enable drdy_xl bit all pads looks noisy (tomorrow i will send you pictures from oscilloscope).