In my application I read out the sensor values (register 0x20-0x2D) with an interrupt every 20ms. After a software reset I have the strange behaviour that the acceleration value of the X-axis stops at a certain value (somewhere in the range of the current acceleration). The Logic Analyzer shows that the sensor value of the X-axis read via SPI is always the same, while the values of the Y- and Z-axis always change slightly. Since this is a safety-relevant application, a static value over a certain period of time is considered a sensor defect and an error is registered. With a software reset, the power supply to the sensor remains and the application is reinitialised.
I have tried to solve the problem in different ways (reload boot register, CR1 power down/on, axis desable/enable, the mentioned options in combination and different order) but nothing has helped. If the sensor axes are deactivated and reactivated (CR1) after the software reset, valid values come from the sensor again for a certain time, but then stagnate at a certain value.
It seems to me that a power up on the power supply is necessary to initialise the sensor cleanly. If the power supply is switched off and on again, everything works without errors.
Is there a known problem with this Sensor that results in this behaviour? What else could be the cause?
Further questions:
- Must the voltage at the sensor be completely removed before initialisation in order to guarantee a proper behaviour?
- Can the control registers be changed on the fly? What conditions must be met when changing the control registers on the fly?
Let me know if you need further information.
Thank you for your support!
Sensor configuration:
Read sensor values after software reset and disable/enable of axes:
Hardware design:
Hi Eleon
Thanks for your answer! I have invested some time in various tests to investigate the problem further.
A software reset from the point of view of the accelerometer means the following:
- SPI interface for communication with the sensor is reinitialised
- Sensor configuration is reinitialised (control registers 1-5 are written, configuration listet below)
For my further tests, I have extended the test interface to the unit so that I can read and write sensor registers via the terminal programme. I noticed the following behaviour:
- Except for the registers with the sensor values (partly also status), no other registers change when the X axis is blocked
I also checked the SPI signals with the KO and the edges and timing are fine.
Are there influences that can lead to the sensor assuming a special state and only changing back to the operational state through a reset (reboot)?
On the device on which the sensor is used, there is also a radio module and a mobile radio modem in use.
When I compare data transfers of the SPI with the Logic Analyzer in the unblocked and blocked state, I see no difference except for the static value for the X axis in the blocked state. From the software side, there is not much else I can do to address the sensor. I have also studied the code example from ST and I don't see any serious difference to my implementation. Regardless of the fact that the data on the bus can be read out every 20ms without an error being apparent.
The sensor is configured as follows.
Control register 1: (configuration value = 0x27)
Power mode selection = Normal mode (ODR)
Data rate selection = 50Hz
Enable all axis: Xen = 1 / Yen = 1 / Zen = 1
Control register 2: (configuration value = 0x00)
Reboot memory content = normal mode
High pass filter mode selection = normal mode (0x00)
Filter data selection = internal filter bypassed
High-pass filter enable INT1 = filter bypassed
High-pass filter enable INT2 = filter bypassed
High-pass filter cutoff frequency = 1Hz (0x00)
Control register 3: (configuration value = 0x00)
Interrupt active-high/low = active high (0x00)
Push-pull/open-drain selection = push-pull (0x00)
Latch INT2 request = interrupt request not latched (0x00)
Data signal INT2 = Interrupt source (0x00)
Latch INT1 request = interrupt request not latched (0x00)
Data signal INT1 = Interrupt source (0x00)
Control register 4: (configuration value = 0x80)
Block data update = output registers not updated between MSb and LSb
Big/little endian data selection = data LSb @ lower address
Full scale selection = +/-2g
Self-test sign = self-test plus
Self-test enable = self-test disabled
SPI serial interface mode selection = 4-wire interface
Control register 5: (configuration value = 0x00)
Turn-on mode selection for sleep-to-wake function = disabled
As you can see the BDU bit in CTRL_REG_4 is already activated in my configuration.
I'm running out of ideas on how to narrow down the problem.
What else could be causing this behaviour?
Regards
Simon
