Hi support,
I'm using the LIS2DUXS12. I make you a short recap about the use of the LIS2DUXS12 with our prototype:
- We use 3 FSM:
- FSM_1: To detect the significant motion;
- FSM_2: To detetct the no motion;
- FSM_3: To detect the situation where the acceleration is above a threshold;
- All the FSM use as input the filter differential of the MLC engine;
In our application we need to change some parameters of the FSM. For example regarding the FSM_2, we should change the threshold or the timer ( we use the timer in order to verify that that samples of the differential filter is under the threshold for a period specified ).
To manage these situations, as I anticipate you in the previous mail, we implement these steps:
- Stop the FSM (using the register FSM_ENABLE – 1Ah);
- Re-configure some FSM’s parameters;
- Restart the FSM (using the register FSM_ENABLE – 1Ah);
To re-configure the FSM’s parameters, we update the FSM’s code; as example, I report you the code that we’re using to update the timer od the FSM2:
int32_t accUpdate_FSM2_TI1(stmdev_ctx_t *ctx, uint16_t value)
{
int32_t result = IMU_NO_ERROR;
uint16_t address = ((0x3 << 8) | (0x98));
uint8_t buff[2];
do
{
buff[1] = (uint8_t)(value / 256U);
buff[0] = (uint8_t)(value - (buff[1] * 256U));
result = lis2duxs12_ln_pg_write(ctx, address, (uint8_t *)&buff[0], 2);
if(result != IMU_NO_ERROR)
break;
}
while(0);
return result;
}
I do this recap because during the tests, we’re observing that the FSM after some re-configurations enter in a block state, we don’t receive any interrupts. In your opinion, what ‘s the cause of this strange behaviour? We should change something in the re-configuration procedure?I’ve a dobut perhaps should I stop the FSM and MLC engine before do the reconfiguration procedure?
