Skip to main content
S
Softanalle
Visitor II
April 14, 2021
Solved

LIS2DW12 and nRF52840 Feather Express via I2C HW issue

  • April 14, 2021
  • 1 reply
  • 1770 views

I have a simple setup of (Arduino) nRF52840 Feather Express connected to steval-mkiv1-184872 -evaluation board. I was going to use it via I2C bus, and followed the connection diagram almost to last letter.

  •    I connected SDA/SCL to feather
  •    I connected VDD and VDDIO to VCC (3.3V)
  •    I connected GND to feather GND
  •    I connected SA0 to GND

Then I write more verbally my steps:

I wrote simple Arduino program, to open I2C (Wire -library). The program reads WHO_AM_I successfully.

Next step, I added 8bit temperature reading, again successfully get result 0 -- which means +25'C. Also WHO_AM_I is printing ok.

This far everything seems to be ok.

I got more curious; I try to read long temperature (registers OUT_T_L and OUT_T_H) and combining them to float temperature. No compile errors.

And therefore I flashed the latest changes to Arduino (above mentioned nRF board), flashing was successfull.

Program starts....

...Serial monitor states that device does not open communication port (/dev/ttyACM0)...

...board stays blinking only communication LED fast. Board is dead.

Quick re-check of cabling, I find that I have missed pull-up resistors. I add 10k pull-up resistors, and connect new board.

I flash the SW and again this new board dies.

Diagnosis: With multimeter, I/O pins give realistic values (for non-powered board). When connected to USB the board does not give out voltage, so. I guess that LDO has burned. It should however, be able to provide at least 40mA. I however, find that I have not connected the CS of LIS2DW12 to VDD.

Question: what happens, if LIS2SW12 is used via I2C, and the CS is NOT connected to VDD? In some forums I have seen references, that it should be internally connected, but datasheet states that with I2C it should be connected. Can it result of

At this point, I runned out of boards to destroy. Need to order more...

Any ideas?

Tommi

lis2dw12 Arduino

VDD - 3V

VDDIO - 3V

SDA -SDA

SCL - SCL

GND - GND

CS - N/A

INT1 - N/A

INT2 - N/A

    This topic has been closed for replies.
    Best answer by Eleon BORLINI

    Hi Tommi @Softanalle​ ,

    it's very strange that the LIS2DW12 can cause (and sustain) short circuits resulting in a board breaking.

    Consider for example that the CS pin can be low or high in the SPI communication, so both Vdd and GND are valid levels.

    As you pointed out, the datasheet says that CS configuration is by default "input with internal pull-up". Moreover "in order to disable the internal pull-up on the CS pin, write '1' to the CS_PU_DISC bit in CTRL2 (21h)".

    Leaving it unconnected should not give this kind of issues as well: if however you are interfacing only via the I2C, the natural level for this pin is High (and pull-up sets the pin at this level).

    I also see from your picture that you are using the STEVAL adapter, on which the pin has been left floating: so, this is a safe configuration.

    Of course, this cannot prevent the occurrence of ESD discharge, but I believe this is a problem at application level instead of a single pin level.

    You might check if your firmware sets the VDD / VDDIOs at the same time, to avoid any temporary reverse voltage paths during the FW flashing, causing the LDO burning.

    -Eleon

    1 reply

    E
    Eleon BORLINIAnswer
    ST Employee
    April 14, 2021

    Hi Tommi @Softanalle​ ,

    it's very strange that the LIS2DW12 can cause (and sustain) short circuits resulting in a board breaking.

    Consider for example that the CS pin can be low or high in the SPI communication, so both Vdd and GND are valid levels.

    As you pointed out, the datasheet says that CS configuration is by default "input with internal pull-up". Moreover "in order to disable the internal pull-up on the CS pin, write '1' to the CS_PU_DISC bit in CTRL2 (21h)".

    Leaving it unconnected should not give this kind of issues as well: if however you are interfacing only via the I2C, the natural level for this pin is High (and pull-up sets the pin at this level).

    I also see from your picture that you are using the STEVAL adapter, on which the pin has been left floating: so, this is a safe configuration.

    Of course, this cannot prevent the occurrence of ESD discharge, but I believe this is a problem at application level instead of a single pin level.

    You might check if your firmware sets the VDD / VDDIOs at the same time, to avoid any temporary reverse voltage paths during the FW flashing, causing the LDO burning.

    -Eleon

    S
    SoftanalleAuthor
    Visitor II
    April 14, 2021

    Thank you Eleon,

    Now I feel really stupid. It is always the thing which you least suspect. Your instinct on the VDD/VDDIO was spot on. The culprit was faulty wire between VDDIO and VCC. All the other wires were ok. It seems that one really cannot trust new wires. They should be always measured! (I took the connection wires from fresh new set of wires).

    So, STEVAL kit works ok with verified wire.

    Tommi

    Terms & ConditionsAccessibility statement