BTT Eddy NACK Error on SV08

General Discussion
1

Basic Information:

Printer Model: Sovol SV08
MCU / Printerboard: Default
Host / SBC
klippy.log

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

Hello everyone, Im currently trying to configure my Eddy Duo on a mainlined SV08. When I attempt to calibrate using LDC_CALIBRATE_DRIVE_CURRENT CHIP=eddy, I recieve the error MCU ‘eddy’ I2C request to addr 42 reports error START_READ_NACK. I have had a member of the Sovol discord go over my printer and eddy cfg files and he sees nothing wrong in either of them at this point. Its connected to the printer via USB.

klippy.log (6.0 MB)

…

2

You have a made a good start but still have Sovol junk hanging around. Eddy-NG? Shouldn’t you get the eddy to function before adding complications?

I don’t have much insight into your particular problems. Things I’d try if I were you.

First I 'd try flashing latest Klipper FW into the Duo. Probably not a fix but worth a shot.
Also Lowering the i2c_speed in your [probe_eddy_current btt_eddy] might be helpfull.
If all else fails, put a U2C in the motherboard port and flip the switch on the Duo.

3

Hi!

So it has been flashed with the latest Klipper and nothing changed there. I attempted to lower the i2c speed however it simply gives me an error saying that it cannot be lower than 100K. I could order a U2C if needed but I would like to try to solve this without going there,

4

Hmm, so:

Sent 98 72924.852668 72924.852668 10: seq: 1b, i2c_transfer oid=0 write=b'~' read_len=2
Sent 99 72924.857881 72924.857881 6: seq: 1c, emergency_stop
...
Receive: 98 72924.853201 72924.852668 11: seq: 1c, i2c_response oid=0 i2c_bus_status=START_READ_NACK response=b'\n\x8d'
Receive: 99 72924.858371 72924.857881 12: seq: 1d, shutdown clock=810233006 static_string_id=Command request
...

So, it seems to me that write succeeds, but right after it, read returns an error.
(Otherwise there should be START_NACK, not START_READ_NACK)
That basically means that the device has answered a write request and then refused a read request.
And it fails here: manuf_id = self.read_reg(REG_MANUFACTURER_ID)

Which is strange.

So, I guess the bus is correct, and the address is correct.

Alas, I’m not aware of any case where LDC1612 can do so. So, it seems to me like some sort of hardware fault.

I guess, you can try to set up software I2C, but I doubt it will help:

i2c_mcu: eddy
# I guess it is the correct order of pins for i2c0f=gpio20,gpio21
i2c_software_scl_pin: eddy:gpio21
i2c_software_sda_pin: eddy:gpio20

-Timofey

5

This is way above my pay grade. I ran your log through Claud AI and the given diagnosis was a problem with the Duo’s USB hardware. I however think your issue may be with Sovol mainboard or the Linux OS interacting with the H616 SOM.

Your host identifies itself as a CM2. You have stripped off the Sovol OS and flashed the CM2 image or are running a VM hack on top of the Sovol OS?

Sovol may have used obscure USB hardware that requires a custom kernel.

What happens if you revert to Sovol’s OS, uninstall klipper, wipe home/sovol, apt update && apt upgrade, install KIAUH then pull mainline klipper? You’ll loose the force plate but with Eddy tap it has no value.

6

I2C NACKs is the MCU answer.
Basically if one sees it, it is automatically means that USB/Serial/CAN (whatever communication between host and mcu used), is fine.

Normally, it is either bad wires/high i2c rate for wires, wrong bus/pins, wrong device address.
Where there is a little that can be done with integrated boards.
Where BTT Eddy is RP2040 + LDC1612, and we have no control over what happening there.

There are I2C HW issues on STM32F103 on the sovols’ boards, but they are not used for communication there, and well, I2C SW would work fine there.

Anyway, everything, including the MCU itself is operating fine, as we see the response from it.

Hope that clarifies something,
-Timofey