Lis2dw on mellow SHT36 v3 -> Invalid lis2dw id

Basic Information:

Printer Model: Self build
MCU / Printerboard: BTT
Octopus Pro
Host / SBC raspi4
klippy.log
klippy.log (2.2 MB)

Describe your issue:

Hi,
I use an mellow SHT36 v3 toolhead pcb which works well but I’m unable to use the accel lis2dw.

I get “Invalid lis2dw id (got ff vs 44).” which is strange because its the same spi channel the MAX31865 on the toolhead board is using and this works well.

I ordered an new one SHT36 but the error is the same.

I can print without any problems only the accel does not work. The only special thing is that I connect to the SHT36 v3 via rs323 instead of CAN.

Greetings

The schema can be found here

and seems to fit to the klipper config mellow is providing. Same SPI like Max Chip and CS is gpio12

1 Like

Seems starnge. Try replacing it with a soft SPI definition using the same pins.

1 Like

jfyi: Discord
@Sineos

There is probably something on the board with LIS2DW, but no one who has the board seems to have an oscilloscope.
So, it is still mysterious why it does not work correctly.

1 Like

Thanks for making me aware, @nefelim4ag.
Also, good to see that it’s already in the right hands :slight_smile:

1 Like

For what it is worth, if one doesn’t have an oscilloscope, a low cost logic analyzer can often provide a lot of useful information. For example: CANBUS Troubleshooting - Klipper documentation

-Kevin

1 Like

I don’t have any experience with the RP2040 and its SPI port but when I look at the SH36 schematics and the RP2040 datasheet, there is one thing that jumps out at me.

SPI_MAX31865_CS is assigned to GPI017 which has the primary function of being an SPI0 CS pins. BUT, SPI_ACC_CS (GPIO12) is assigned as the SPI1 RX (MISO) pin:

Again, I’m not familiar at all with the RP2040’s SPI function and I don’t know how it is coded in Klipper but I’m wondering if to use the SPI function, the board must use predefined CS pins.

The obvious way to test this is to follow the suggestion from @Sineos and change from the hardware SPI to the software one (you won’t see any difference in performance) for the MAX31865 and LIS2DW.


If going with software SPI pins doesn’t work then you can check for bus contention between the two devices (ie the MAX31865 is driving the bus because it’s CS line is low when LIS2DW communications are taking place).

To check for bus contention, could you:

  1. Replace the PTC with a standard NTC thermistor
  2. Add the sensor statements for the NTC thermistor
  3. Comment out the MAX31865 statements
  4. Force the SPI_MAX31865_CS pin (GPIO17 on the RP2040) high
  5. Repeat test with both the hardware and software SPI configuration to see if there is any difference in operation

Depending on the results of this test, I would recommend looking at the SPI_MAX31865_CS pin on the SHT36’s RP2040 (GPIO17 - Pin 28) with a DMM and see if it ever goes to a high voltage level.


I think you should you have an axis_map: x,z,y statement as I have in my custom board with an LIS2DW:

[lis2dw]
cs_pin: PB1
spi_bus: spi1
axes_map: x,z,y

This is probably not your issue, but I use it when accessing the device.

Can you explain exactly how you made the serial connection between the Raspberry Pi and the SHT36? I’m trying to figure out how you get a serial connection of:

[mcu SHT36]
serial = /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3.1:1.0-port0
baud = 250000
restart_method = command

Could you explain this statement? Is it a complaint endemic to the SHT36 (I’ve used the SHT42 but not with the MAX31865 enabled) using one or both of the LIS2DW and MAX31865?

If it is, then it could be a design problem with the SHT36 PCB and Mellow tech support should be involved.

As far as my understanding goes, all the info is available at the link on the Discord:

SHT36 has worked in LIS2DW, with a quirk that it errors out on the first query: “bad chip ID”.
Then there is a 125MHz → 200MHz RP2040 change.
After that, it does not work.
What is also strange, the reporter said that at “v0.13.0-51-gbfda326c2: neither HW or SW works”
(which is strange, because SW SPI does ensure pulse width time between CS and SCK).

The only thing that probably changed outside of the chip is the time between CS and SCK.
300ns → 200ns.
(Oscilloscope shots are from RP2040 dev board).


LIS2DW should happily work with >10ns CS setup time and 10MHz clock speed.

No more reliable info on my side.

Btw, I suspect test on the SHT42, if you still have one, would be enough to see what we have there, like if it works, then there is a SHT36 specific issue.

Is that a firmware change or are there different chip versions?

Shouldn’t be an issue.

The SHT42 has an STM32F072 as its MCU - not the RP2040. Also, the ones I have don’t have a MAX31865 installed.

I can take a look if you think it would be useful, but I do use the LIS2DW on my STM32F070 board and it works fine. I’m not sure how much value is there for you.

If it’s down to a specific release, could somebody do a kDiff on the files before and after to see what difference there are?

Firmware 2f6d2409

:frowning:

The link is above, we basically change the MCU sys frequency + slightly increase voltage, that is it, all according datasheet.
I doubt it is an MCU problem or SPI code.
Like, MAX31865 is working, and at first glance it seems to be much more picky.

But I’m not sure what sort of workaround is needed here.
Again from discord info, it seems like +1us pause between CS and SCK should help.
But this contradicts the info that SW SPI at low frequency does not help.
(SW SPI at 1Mhz should work in this case).

So, idk.

If things were working before the code change and now it isn’t…

I believe the scope waveforms you’re showing above are with an RP2040 development board generating a SPI transfer without anything attached to the IO pins. Maybe you could buy something like:

and wire it in with the SPI interface on the SPI0 pins and take a look at the actual signals to/from the LIS2DW.

If you can’t do that, I’m happy to order a SHT36 and look at the SPI signals myself. It will take 2-3 weeks to come in.

1 Like

Soft SPI only for the accel does not work because pins for SPI are allready used by max.
If I change the Max also to use Soft SPI klipper can start but the error still is the same.
“Invalid lis2dw id”

With a UTOR (instead of UTOC) board from mellow. It is in principle an usb to rs323 adapter. The SHT36 has dip switches to configure the 4Pins connector to connect to PIN0/PIN1 aof the rp2040 UART instead of CAN. Think every rs323 adapter should work.

If someone is living in germany and have an oscilloscope I can send you one of the SHT36 boards. Or is there a klipper postal address for hardware presents :smiley:

1 Like

Logs with SW spi and reduced spi speed. Does not work
klippy.log (378.3 KB)

Logs with no configured MAX sensor. Only the accel. Does not work
klippy.log (606.7 KB)

1 Like

I have an cheap logic analyzer but I’m not sure if I’m able to connect it to such small pins.
From the schema and the board I would assume the spi pins of the lis2dw should be this ?

1 Like

you have the signals swapped.
signals on the resistors from top to bottom:

  1. interrupt (dont care)
  2. SCK
  3. CS
  4. MISO
  5. MOSI
1 Like

:plus: , I just checked the timings, like SPI rate is correct and how large the pause is, because it is mentioned to be somewhat important.
I could connect ADXL if it helps.

Yep, I could order and test if it helps.
Hmmm..

For SPI SW and LIS2DW, I hope it would be helpful if you set a low SPI speed, like 1MHz/500KHz.

btw, not sure why you decrease it everywhere except this one specific chip
Klipper is able to distinguish devices and use different SPI rates for them

Unfortunately, I’m in NL, and it looks like we will spend a price of the unit, sending it back and forth :frowning:

Groan. RS-232 (aka “rs323”) is a fairly ambiguous standard that has really fallen out of favour over the past twenty years. Yes I know people will come back and say they use it all the time at work but, for basic PCs and most of today’s electronic devices, it is rarely used today because it requires non-standard voltages (-15V to -3V for a “1” and +3V to 15V for a “0”) and has a plethora of handshaking (both hardware and software options).

What seems to be used here is NRZ (Non-Return to Zero) serial with 3.3V positive logic.

I’m saying this because when I look at the SHT36 V3 schematics, the connections from the main CAN connector (“CN1”) can be bypassed using DPDT (not “dip”) switches on the board. There are no voltage conversion chips which would be required if actual RS-232 signals were being passed.

Now, I can’t find schematics for the UTOR board but, when I look around, I think you’re following this diagram for the SHT36 v3 switch settings:

and, you’re using this diagram for the UTOR connection wiring:

Sorry for being pedantic here but I think it’s important to understand how things are working here. Yes I know Mellow is using the term “RS232” when describing the connection but it is wrong, misleading and could lead to damaged hardware due to the voltage levels used by “true” RS232.


You should be able to solder 28-30AWG wires to the resistors and run them to your logic analyzer - these are normally referred to as “fly wires”. I haven’t checked the pinout to see whether or not your labeling is correct but I wouldn’t consider it a big deal if you’re wrong; the actual pin functions will become obvious when you look at the wires on the logic analyzer and you can change the pin definition to get the right signals.


I don’t see anything on the SHT36 V3 schematic that looks like its wiring would be a problem.

I don’t think it’s going to become clear what’s happening here until somebody takes a look at an actual RP2040/LIS2DW combination.

Yes exactly. No idea what they really transmit I trusted their RS232 description.
I only connected the raspi via USB to UTOR and the UTOR to the SHT36. The rest like octopus pro and ERCF is connected via usb to the raspi.
Maybe they transmit TTL and it’s an usb to TTL converter ? Often USB to TTL adapter are wrongly named “USB rs232 adapter” on amazon and ali.