I'm reading acceleration from an ADXL355 in the evaluation board EVAL_ADXL355Z to an ESP32-WROVER on the ttgo evaluation board.


ADXL345 Pin name (number) -------- ESP32 Pin name (number)
VDD (P1-3) -----------------------------> 3v3
GND (P1-5) -----------------------------> GND
CS/SCL (P2-2) -------------------------> vspi cs (D5)
SCLK/VSSIO (P2-4) ------------------> vspi scl (D18)
MISO/SDA (P2-5) ---------------------> vspi miso (D19)
MOSI/SD6 (P2-6) ---------------------> vspi mosi (D23)

Note: the accelerometer arrived with STBY-1 (VDDIO) connected to STBY-2 (RESERVED). I removed this connection because it seemed strange to me to connect something to a reserved pin, I didn't try yet to reproduce the problem with those pins tied and nothing about the usage of those pins is present in any datasheet.


I got stuck with a problem that seems very similar to that described here.: I can read/write everything from/to the device but the acceleration data are stuck to -2g. That is the lowest boundary of the measurement range. It happens that by chance I tried unplugging and re-plugging the wire that supply power from the master to the accelerometer while the master is on after that operation acceleration data are correct. What surprises me is that simply turning off and on the whole system (powering down the master but not removing the supply wire that connects the accelerometer to the master) doesn't solve the problem, and at following restart the problem persists

What can be causing this? How could I fix it so that I dont have to manually act on the system to make it work?


2 Answers 2


There are multiple voltages going into that chip (analog + digital supplies) so DKNguyen's answer sounds good. The design of the WROVER may not be performing the power-up sequence correctly.

You should be able to give the ADXL355 Accel chip a software reset (write 0x52 to 0x2F) which is 'similar' to a Power-On-Reset. This is buggy and the datasheet specifies:

  1. Read the shadow registers, Register 0x50 to Register 0x54 (five 8-bit registers) after power-up, but before any software reset.
  2. Store these values in a host device (for example, a host microprocessor).
  3. After each software reset, read the same five registers. If the values differ, perform a software reset again until they match.

So on boot, read the five registers, set 0x2F to 0x52, delay a while and a half, then read the 5 again and make sure they match, and repeat up to X times if they don't.

  • \$\begingroup\$ Amazing answer thank you. I'll try this as soon as I can and accept the answer accordingly. What a pain is this device \$\endgroup\$ Nov 15, 2020 at 12:20

On powerup, something is trying to talk before the other is ready to listen and respond and causing it to hang. Add a power supervisor IC or make your MCU code wait on powerup before doing anything.

Confirm by resetting just your MCU. Use wires or probes to pull the reset line high if you have to.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.