AnsweredAssumed Answered

Strange behaviour with LSM303DLHC

Question asked by Alan Chambers on Apr 30, 2018

I am seeing some curious behaviour with the LSM303DLHC sensor. I am using the magnetometer only, reading at 200Hz. My software responds to interrupts on the DRDY pin by reading six bytes starting from register OUT_X_H_M. I also read the temperature - two bytes at TEMP_OUT_H_M - once a second.


The configuration is as follows:


    // Set CTRL_REG1_A to:
    //    0000        : ODR[3:0] = 0000, Power down mode
    //         0      : LPen = 0, normal mode
    //          000   : Zen, Yen, Xen = 000, all axes disabled
    //    0000_0000   : 0x00
    register_write(A_I2C_ADDRESS, CTRL_REG1_A, 0x00);


    // Set CRA_REG_M to:
    //    1           : TEMP_EN = 1, temperature sensor enabled
    //     00         : always zero
    //       1_11     : DO[2:0] = 111 for 220Hz ODR (highest rate)
    //           00   : always zero
    //    1001_1100   : 0x9C
    register_write(N_I2C_ADDRESS, CRA_REG_M, 0x9C);


    // Set CRB_REG_M to:
    //    111         : GN[2:0] = 111, +-8.1G range (X,Y 230 LSB/G, Z 205 LSB/G
    //       0_0000   : always zero
    //    1110_0000   : 0xE0
    register_write(N_I2C_ADDRESS, CRB_REG_M, 0xE0);


    // Set MR_REG_M to:
    //    0000_00     : always zero
    //           00   : MD[1:0] = 0, continuous conversion
    //    0000_0000   : 0x00
    register_write(N_I2C_ADDRESS, MR_REG_M, 0x00);
Now, this all works just fine most of the time, but there are two issues:


1. There are occasional glitches in the data readings (these do not seem to occur at lower frequencies than 220Hz). These are easy to spot because of a difference in the interrupt timings, so I just interpolate value to smooth out the glitches.  


2. It appears that the sensor stops generating interrupts after a while (some hours). I'm not yet certain of this, but have not managed to trap any I2C errors or found any issues in my own code (always my first assumption, naturally).


Sadly, this is a production board with very little in the way of debuggability. I would love to attach a logic analyser to the DRDY pin, but cannot. I'll see if I can get a lead attached...  


The data read is started in thread mode, rather than directly in the ISR, so there is a possibility for some latency before the read, though the thread has real time priority, and no other thread has this priority. What would happen if DRDY was set and not serviced before the next reading was ready? Could this lead to a stall in interrupt generation?


Anyway, the reason for posting is really just to ask if anyone else has seen similar behaviour with this sensor, especially problem (2), if only to confirm my suspicions. A solution would be lovely, of course. I can easily reset the sensor if I observe that it gets stuck, but would first like to know whether it is actually the sensor that is causing the problem.