cancel
Showing results for 
Search instead for 
Did you mean: 

LIS3DHTR returns 0xffc0 for all channels

MarkL
Associate

I'm having some issues in trying to get valid data out of the LIS3DH. For some reason I am only receiving a constant value of -1 [0xffc0 10 bits left aligned] on all channels and FIFO slots. I can read/write all other registers just fine, it's just the sensor data that is not working. I'm sure it's something I'm missing in the config, but for the life of me I can't seem to find it.

VCC and VCCIO is 3V3

Communications is over I2C @ 400KHz

I have repeated this failure mode on multiple devices

My Init process is as follows:

  • Read the Who_AM_I register and abort if it does not return the correct ID
  • Reset the device state by zeroing out all critical registers (TEMP_CFG, CTRL[1-6], REF, FIFO_CTRL, INT1_CFG, INT1_THS, INT1_DUR, INT2_CFG, INT2_THS, INT2_DUR, CLICK_CFG, CLICK_THS, TIME_LIMIT, TIME_LAT, TIME_WIN)
  • Set BDU and 2g range in CTRL4
  • Enable ZYXDA interrupt on INT1 in CTRL3
  • Clear FIFOEN in CTRL5
  • Set BYPASS mode, Threshold 0, and INT1 Trigger in FIFO_CTRL
  • Set FIFOEN in CTRL5
  • Set STREAM mode, Threshold 10, and INT1 Trigger in FIFO_CTRL
  • Set HPF mode to Normal, Cutoff=0, FDS=Bypass, Filter disabled for all sources
  • Perform Dummy Read of REF
  • Set Normal Mode (HR=0) and 2g range in CTRL4
  • Set Normal Mode (LPEN=0) , and ODR of 1344HZ in CTRL1, enable X, Y, Z

After which I poll for data by reading the FIFO_SRC register, and then reading the data registers if it shows data available. I have tried addig a delay up to 100ms after init and before checking, with no difference in behavior.

If anyone has any insight or a solution it would be greatly appreciated.

Cheers

This discussion is locked. Please start a new topic to ask your question.
3 REPLIES 3
Eleon BORLINI
ST Employee

Hi @MarkL​ , you say:

>> I have repeated this failure mode on multiple devices

Do you mean that there are a few devices working or that all the devices show this behavior?

Btw, before the step where you enable the BDU / 2g in CTRL4, write the CTRL_REG1 turning on the sensor, and enabling X, Y, and Z and ODR=100 Hz (e.g. 57h), and check if you can get a data output.

Regards

MarkL
Associate

Hi Eleon,

Thanks for the reply. Sorry I wasn't clearer, I meant that all devices I tried exhibited the same behavior.

I had tried previously without the FIFO, but not quite as stripped down of an init as you proposed. (the current state is as a result of trying to solve my issue, I started off much simpler too) Having said that, I tried running the test with only the register reset and the setting of CTRL1 as you suggested, and it does appear that I'm getting data. I then repeated at 400Hz and again at 1344Hz, in all cases I got what appears to be valid data, though at 1344 I do occasionally see a blip of bad data [all 3 channels reporting 0x0000 or 0xffc0 (at the same time)].

[edit] After running a bit longer at 100Hz I do start to see blips of invalid data as well. It does appear to be orientation specific however, If I have the chip facing the sky it doesn't happen very often, whereas when I have it facing the test bench it almost continuously shows the fault.

[edit2] After investigating furhter by selectively turning on and off each of the various settings, it only seems to manifest when I enable the FIFO. One thing I can't tell is if this happens immediately, or if it quickly degrades into this mode. I have some additional hardware due to arrive sometime today that will help me debug this further.

Is there a particular setting you can see that I'm doing wrong that could be causing this?

Cheers

Thank you @MarkL​ for your detailed analysis. Referring to your [edit2] point, are you synchronizing well the FIFO as detailed in the AN3308, from p.46 on? E.g. in BYPASS mode is the device working well? Regards

Announcement

We’re moving the ST Community to a new platform to give you a better and more reliable community experience.