Self Test fails intermittently fails

Hello kfroshhh 

Could you check the output value while the sensor stands still in a table maybe it is a calibration/offset matter.

I will also allocate some time to review your code,

regards,

Mario SM

Hi Mario,

The results are obtained while the device is sitting flat on a desk.

Was able to reproduce the issue two more times recently where diff = 1678 and diff = 0

Hi kfroshhh 

right after entering to Measure mode, could you please try adding a 100ms delay as recommended in the DS?

Can you please also share the values that you read on x_axis_2 and x_axis_1? that might give us an idea what is going on. 

Tip: we usually recommend averaging several data points to reduce the noise on the self test measurement. So on the DS self test routine steps 4 and 7 I would read something like 10 samples from x-axis and get the average value out of those 10 samples as your x_axis_1 and x_axis_2. 

I hope this helps, 

Pablo. 

Regarding 100ms delay, this already exists as part of set_power_mode function.

/***************************************************************************//**
 * @brief Places the device into standby/measure mode.
 *
 * @param dev      - The device structure.
 * @param mode     - Power mode.
 *                   Accepted values: 	ADXL367_OP_STANDBY = 0,
 *										ADXL367_OP_MEASURE = 2
 *
 * @return 0 in case of success, negative error code otherwise.
*******************************************************************************/
int adxl367_set_power_mode(struct adxl367_dev *dev,
			   enum adxl367_op_mode mode)
{
	int ret;

	ret = adxl367_reg_write_msk(dev,
				    ADXL367_REG_POWER_CTL,
				    field_prep(ADXL367_POWER_CTL_MEASURE_MSK, mode),
				    ADXL367_POWER_CTL_MEASURE_MSK);
	if (ret)
		return ret;

	//100 ms wait time before reading acceleration data.
	if (mode == ADXL367_OP_MEASURE)
		OsDelayMs(100, OS_OPT_TIME_DLY);

	dev->op_mode = mode;

	return 0;
}

Hello kfroshhh hope you are doing well, any news on this?

Hi Mario, appreciate the follow-up. We still need to obtain the data referenced above to provide to you. I will push to get this done in next couple of days.

Karl

Hi Mario,

Just wanted to update you that reason for delay is struggling to reproduce issue again. Will let you know once we can and we have the data.

Hi Mario,

We finally were able to sit down and reproduce the issue.

In the case where diff = 0, x axis1 = 0xFFFF and x axis2 = 0xFFFF

I assume this is always the case when we observe diff = 0.

hello kfroshhh 

those results are found even after averaging 10 or more times? I also suppose that we are running the test with the same measurement range (2g is the recommended one) are the outputs in LSB proportional to the different ranges? (sensitivities)

regards,

Mario SM

No sorry, this is still following the adxl367_self_test function from,

https://github.com/analogdevicesinc/no-OS/blob/main/drivers/accel/adxl367/adxl367.c

Per your suggestion on averaging, do you recommend modfying the adxl367_self_test directly to perform a loop where samples are retrieved? In the case of invalid sample which we have seen (0xFFFF), do you recommend discarding?

No sorry, this is still following the adxl367_self_test function from,

https://github.com/analogdevicesinc/no-OS/blob/main/drivers/accel/adxl367/adxl367.c

Per your suggestion on averaging, do you recommend modfying the adxl367_self_test directly to perform a loop where samples are retrieved? In the case of invalid sample which we have seen (0xFFFF), do you recommend discarding?

Hi kfroshhh 

Can you please verify the 0xFFFF response is not related to comms issues? 

Regards, 

Pablo. 

Hi Mario,

We don't believe this to be the case as the command status is returning success, indicating the communication part worked ok.

FYI, I would slap a Saleae analyzer on the I2C lines to confirm this, however the issue is only observed on an enclosed battery powered device. We do not encounter issue when attempting to replicate on evalutation.

To confirm comm behavior, we can grab a Saleae trace using eval board to observe message timing and related.

Hello kfroshhh 

Thanks for the feedback. We would really appreciate it if you could cross-check it. That way, we can eliminate that source of the problem.

Since you could only find this issue in the enclosed device, does this error occur consistently in different PCBs and sensors, or does it only occur in one?

Regarding the device itself, could you verify any characteristics different from the test environment? Perhaps the battery is experiencing a voltage drop when the entire system tries to operate simultaneously. There may be signal integrity problems that could corrupt data. Alternatively, the mounting recommendations for the part may not have been followed, causing mechanical stress and inaccurate outputs.

regards,

Mario SM

Hi Mario,

I learned sniffing SPI lines on the physical device is not possible. For now, we have added code to verify the return status of all commands within XL Self Test is valid.

Also, we are looking to add a command that returns some type of data inside the XL Self Test to confirm that this works and not related to comm issue.

I also learned XL Self Test always fails, even when commanded after initial power-on.

We should be able to verify voltage level at least.

Please disregard previous message. I learned engineer performing testing was using older device with different XL model.

We likely still have failures, but guess is the data will not be 0xFFFF.

Will update when we have fresh data using correct hardware...

No problem, you are welcome.

have a nice weekend,

Mario SM