2021-02-23 10:41 PM
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?
Solved! Go to Solution.
2021-03-12 02:16 AM
Hi @VSavenia ,
were you able to make some progresses with the scope patterns?
-Eleon
2021-03-12 02:59 AM
Hi @Eleon BORLINI!
Yes, in this pictures source of green signal is the INT1 pad and source of blue signal is the INT2 pad.
There are two different groups of snapshots: first two snapshots was catched with scope attenuator 1:1 and last two pictures was catched with scope attenuator 1:10.
BugOperation:
NormalOperation:
BugOperation1_10:
NormalOperation1_10:
2021-03-12 03:18 AM
@Eleon BORLINI
We tested this situation without INT2 pad, it was enabled but physically removed from steval board J1 header, because we was thinking that this is the crosstalk interference, but it didn't helps. So, now we need to move forward and we make desicion to count ODR with timestamp feature.
One more time:
Normal operation is when we activate fifo_th bit on any INT1 or INT2 pad and then retrieve data
Bug operation is when we use two INT pads for example like in this snapshots on INT2 pad we route fifo_th bit 1 and on INT1 pad we route drdy_xl bit 1.
Note 1: when we switch pads nothing changes, bug doesn't dissapear.
Note 2: we have two iis3dwb sensors, the error is repeated on two devices.
I hope i was understandable to describe our problem, please let me know if you will need some additional information.
Regards.
2021-03-18 08:23 AM
Hi @VSavenia ,
sorry for the delay in my answer.
From software side, could you check if polling the interrupts reading the dedicated registers INT1_CTRL (0Dh) and INT1_CTRL (0Eh), instead of enabling the INTx physical routing, still gives you the same issue?
-Eleon
2021-03-18 11:55 PM
Hi @Eleon BORLINI
We would try your recomendation but a little bit later because at now we want to add math algorithms and we don't have time for experiments.
We solved the problem with a timestamp. The difference between the frequency counted with timestamp method and the frequency on the oscilloscope is 1-2 Hz, this can be attributed to an measurement error.
I will reply as soon as possible regarding your proposal.
Regards,
Vladislav.
2021-03-19 12:34 AM
Hi Vladislav,
glad to hear you faced the issue with a solution, at least temporary so far.
-Eleon