Basic Information:
Printer Model: Ender 3
MCU / Printerboard: BIGTREETECH SKR Mini E3 V3.0 (STM32G0B1)
Host / SBC: Raspberry Pi 4
klippy.log: Unfortunately, I no longer have the log captured while the issue was occurring because it was solved during troubleshooting. Therefore, I cannot provide the original log. I am posting this to document the solution for other users who may experience the same behavior.
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,
I would like to report a startup issue that I was able to reproduce and solve.
Hardware:
- Ender 3
- SKR Mini E3 V3.0
- Raspberry Pi 4
- Generic blue ADXL345 module
Original configuration:
axes_map: x,y,z
cs_pin: PD9
spi_bus: spi1
Problem:
When the ADXL345 was connected to the hardware SPI1, Klipper frequently failed to connect after powering on the printer.
The printer stayed in:
“Printer is not ready”
The only way to make it work was:
- Disconnect only the ADXL345 GND wire.
- Execute FIRMWARE_RESTART.
- Reconnect GND.
After that, the accelerometer worked normally.
Troubleshooting performed:
- Tested two different ADXL345 modules.
- Verified the 3.3V supply.
- Measured all SPI pins.
- Tested series resistor on MISO.
- Tested power supply capacitors.
- Verified wiring.
- Measured voltages on all pins.
None of these solved the problem.
Solution:
I moved the ADXL345 to Software SPI using free IO pins.
Configuration:
axes_map: x,y,z
cs_pin: PD0
spi_software_sclk_pin: PD2
spi_software_mosi_pin: PD3
spi_software_miso_pin: PD4
After this change:
- Klipper starts normally every time.
- No need to disconnect GND.
- ACCELEROMETER_QUERY works.
- TEST_RESONANCES works.
- SHAPER_CALIBRATE works.
Based on my testing, switching from hardware SPI1 to software SPI completely eliminated the startup issue. I cannot determine whether the root cause is the SPI1 peripheral, the board, or a firmware interaction, but the behavior was consistently reproducible on my setup.
I’m posting this in case it helps someone else or if the developers know why SPI1 behaves differently during startup.
This is not a support request anymore. The issue has already been solved. I’m sharing the solution because it may help other users and to understand why hardware SPI behaves differently from software SPI on this board.
The wiring used in my final solution follows this GitHub guide:
The only difference is that, in my case, the hardware SPI (SPI1) caused startup issues, while the software SPI configuration worked reliably.
Hardware SPI (PD9 / SPI1): Printer failed to initialize when the ADXL345 was already connected.
Software SPI (PD0, PD2, PD3, PD4): Printer starts normally every time and TEST_RESONANCES / SHAPER_CALIBRATE work correctly.
