LPC176x USB v0.13.0-579-g6416d3e2c Build Issue

General Discussion
1

Basic Information:

Printer Model: Modified RigidBot with a Smoothieboard V1
MCU / Printerboard: Smoothieboard V1
Host / SBC: rPI 3b

klippy (2).log (148.2 KB)

Hi all,

I’m running into what appears to be a new-ish issue affecting LPC176x (LPC1769) USB CDC enumeration in recent Klipper MCU builds. I wanted to see if anyone else is seeing the same thing, or if this is already a known issue, or if I’m missing something obvious. This is on an old Smoothieboard V1 5x coupled to an rPI v3b.

Somewhere between v0.13.0‑114‑g841a9ca2f (last known working)

And v0.13.0‑579‑g6416d3e2c (currently broken)

The USB serial interface on LPC176x boards stops enumerating entirely when flashing newly‑built firmware. The same hardware, cable, Pi, and configuration work perfectly when reverting to older Klipper commits. I am currently running an old compile I had of v0.12.0‑85‑gd785b396a, and USB CDC works normally again immediately after re-flashing my MCU.

When flashing a new MCU firmware built from the current Klipper commit, the board powers up but the USB interface fails to enumerate. The Raspberry Pi logs the following every time:

usb 1-1.2: new full-speed USB device number XX using dwc_otg

usb 1-1.2: device not accepting address XX, error -32

usb 1-1-port2: unable to enumerate USB device

No /dev/ttyACM0 appears, and /dev/serial/by-id remains empty.

This happens:

- with the same cable and port that worked seconds earlier

- with the same .config settings

- after a clean rebuild (make clean)

I’ve confirming the firmware does flash properly (SD card renames firmware.bin → FIRMWARE.CUR and the file size changes to match the firmware build). So the MCU is running the new firmware, but the USB peripheral never comes up. When reverting to older commits (e.g., v0.12.0‑85‑gd785b396a), USB CDC enumerates normally and everything works as expected.

usb 1-1.2: New USB device found, idVendor=1d50, idProduct=614e

usb 1-1.2: Product: lpc1769

usb 1-1.2: Manufacturer: Klipper

cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device

I’m using the same LPC1769 settings I Always have, but I even tried 1768 with the same result, here’s my normal build settings

- Architecture: LPC176x

- Processor: LPC1769

- Bootloader offset: 16KiB

- Interface: USB

- No extra options

Host-side Klipper works fine, only the MCU firmware is affected. Reverting to older commits restores USB immediately. Is anyone else having an issue with recent LPC176x MCU firmware builds affecting USB CDC enumeration?

Thanks!

-JT

2

Is your Pi close enough to your printer to consider “direct serial” as an option?

I see another thread where another STM32 “clone” seems to have USB issues with the latest Klipper firmware.
https://klipper.discourse.group/t/v0-13-0-549-on-flsun-super-racer-no-joy-and-much-pain

3

Yeah, it’s possible to wire it for serial. I’ll have to consider doing that if this issue continues. I read the other thread before positing here. I am not sure if it’s the same issue as my board won’t connect at all with the newer versions. I also don’t have any stability issues with the rPI, it just won’t connect to the MCU due to the USB not enumerating on the newer versions. My board processor is powered by the SBC, so there is no issue with power on order. It’s not unstable, just consistently refuses to work on new firmware flashes.

4

He does not have issues with Klipper firmware, as has been pointed out.
Klipper firmware can’t kill the host. Python process can’t kill the host

It is not related.

“After this, therefore because of this”

@Speedy64i
As far as I can tell, latest changes in the LPC were at

git describe --always --tags --long --dirty
v0.13.0-11-g8c67adc16

Where there were some changes in the generic (shared) code, alas, nothing looks too suspicious to me.

What can cause your issue is a question.

I can only suggest trying to bisect the commit that causes this:

Basically, update from v0.13.0‑114 in some steps, and check where it happens.

I can suggest testing v0.13.0-416-g9c84895a0:

git checkout 9c84895a0
make menuconfig
make flash ...

Because after that commit, there are some changes, which were supposed for some high-performance STM32 chips, and IDK, if they were supposed for LPC chips.

Not sure if your RPI 3 is affected by the DWC whatever issues, because according to this thread: Discord

Revert to the 6.1 kernel does help with kernel hangs, and you are running the 6.1 kernel.
So, I’m not sure, but it seems unreleated.

-Timofey