Post Go back to editing

ADXL372 self test steps in ERRATA

Category: Datasheet/Specs
Product Number: ADL372

I'm a DFAE in Japan . 

When my customer runs self test procedure in ADXL372 datasheet page 24, ST_DONE bit is set to 1 after 300ms.

But, judging from  Table1 in B-sample errata datasheet RevB on 2021/3/24 (attached) , he needs to follow the steps described in ERRATA to run self test.

However, when he run self test steps described, ST_DONE is NOT set to 1 .

Does this self test procedure in ERRATA work correctly?

why is ST_DONE bit NOT set to 1 after 300ms?

  • Hi  , 

    We have done extensive testing to validate this workaround and is the current test we run in production to validate the ST feature.  We have not found the issue you describe in any part. 

    Can you please share your customer code? So I can double check their ST routine is exactly as described in the workaround. 



  • Hello, I am working on the same workaround for which I don't wait 300ms but read the z axis and the ST_DONE bit every 5ms after the start of the ST bit. I consistently get about 43 samples (or around 215ms) before the ST_DONE bit is set, which prompts the code to exit the loop. For the first 20 samples I always get 0xFF0 (or 4080 in decimal) and the rest are much lower centering around 100 or so range. This is opposite with the graphic seen in the workaround doc here with larger values at the front end. I then average the first 8 samples (about 50ms worth of data) and the last 8 samples (skipping sample #43 since it always shows 0xFF0 for some reason). The 'absolute' delta (4080 - 100 or so) is so far always greater than 31, which I assume this is what it means by 5 LSB? Please let me know if this is the proper way of implementing the workaround. Thanks!


  • Hi  , 

    your results are okay, and you are right, you should look at the absolute delta between the acceleration read before an after the ST force is applied. I am not sure why you always get 0xFF0 for the first 20 samples, does it happen for multiple sensors? 



  • Thanks for the reply. Yes this has happened in 2 boards so far. Correction: The first 21 samples (not 20) are always 0xFF0 for both boards. After that the samples are at much lower values until sample 42nd. Then the last sample 43rd is always 0xFF0 again, which I ignore.

    Also, it is stated in the workaround that the result bit USER_ST will be removed. What does it really mean? Right now I only check the samples and do the workaround when USER_ST bit fails (0). Should I be doing the calculation at all times regardless of the USER_ST bit?

  • Hi  , 

    We will remove the automated self test response (indicated by USER_ST bit) in the next datasheet revision. Other bits in the ST register stay the same.  

    Regarding your implementation of the workaround, i think is fine. The USER_ST would randomly fail (0) but when it passes (1) the result is valid and reliable. 



  • Thanks again  

    One more question! Does the setting up for self test alter the configuration for normal operation? In other words, do I need to re-configure the accelerometer after the self test to bring it back to normal operation?

  • yes it does alter the configurations, if you see in the recommended workaround, the first step is to reset the sensor.