IIS328DQ value freeze after software reset

[SThei.1]

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:

SPI read of two cycles (X axis unchanged, Y and Z axis change):

 

Read sensor values after software reset and disable/enable of axes:

Hardware design:

 

[Eleon BORLINI]

Hi @SThei.1​ ,

What do you exactly mean with software reset (I see that with hardware reset everything is ok)? Are you resetting all the configuration registers or just some of them? And do you rewrite all the CTRL registers' values after the reset?

I suggest you to check the online drivers on Github (iis328dq_STdC), in particular the iis328dq_read_data_polling.c file, if you might find differences with other sections of your code. For example, you may try with enabling the BDU bit in the CTRL_REG4 (23h) register, to prevent the update of output registers between reading MSB and LSB.

About your questions:

>> Must the voltage at the sensor be completely removed before initialization in order to guarantee a proper behavior?

Of course, an hardware reset assures the complete reset of the chip (except the factory calibration stored in the internal flash memory, but better to investigate a little more on the "soft" reset.

>> Can the control registers be changed on the fly? What conditions must be met when changing the control registers on the fly?

Well it depends on the register: it's for example unsafe to change the ODR and the FS (CTRL1 or CTRL2) while you are acquiring data, but you can safely change interrupt control registers (e.g. CTRL3) while you are not using the interrupt features.

-Eleon

[SThei.1]

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

 - After reading out all sensor registers via the terminal, the blocked value of the X axis changes, but the axis remains blocked

- If only the low byte register of the X axis (0x28) is read, suddenly changing sensor values are read again at the X axis

It is possible that the sensor has a brief overflow when a reset is carried out. Does the sensor have to be specifically reset after an overflow?

I also checked the SPI signals with the KO and the edges and timing are fine.

 Since I read the sensor values with Multiple Read and the first byte (low byte X axis 0x28) was always blocked, I started reading at the status register (0x27). Also with this procedure, it is the value of the X axis that blocks. This behaviour leads me to conclude that the sensor is effectively in an undefined state.

  

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