Marlin: [BUG] Endstop switches not being read properly when connected to OctoPi

[bholzer]

Bug Description

When connected to an OctoPi, my X and Y endstop switches are always being reported as "open." This causes the printer to try and move beyond its minimum bounds. This does not happen when the Pi is disconnected. I have filed an issue with both OctoPi and OctoPrint, and both have indicated that this appears to be a firmware problem.

If I connect the Pi when the printer is already homed, I can send M119 and see the following:

Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: TRIGGERED
Recv: z_min: open

My Configurations

My configurations are exactly as provided in the example configs for my printer model (ender 3 v2): https://github.com/MarlinFirmware/Configurations/tree/import-2.0.x/config/examples/Creality/Ender-3%20V2

Steps to Reproduce

On an Ender3 v2 with the example configurations, attempt to home the printer with OctoPi connected.

Expected behavior: [What you expect to happen]

The printer should stop at the endstops

Actual behavior: [What actually happens]

The printer continues to try and move the carriage beyond the minimum bounds.

Additional Information

• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[Pieterv24]

I can confirm this bug.
I've the same issue.

Please confirm this, but does the issue persist when an SD card is inserted?
For me inserting an SD card fixes the problem.

With some help of the Marlin Discord I've narrowed down the issue to the following commit: https://github.com/MarlinFirmware/Marlin/commit/60b61de395a02bce6f1a7b4663780ae9b8ef4d11

Specifically spiInit(SPI_SPEED); seems to be the cause.
When firmware is compiled with that line commented out everything works as expected

[rhapsodyv]

I have been working a lot with SPI in marlin recently, and that spiInit(SPI_SPEED); // Return to base SPI speed really don't need be there.
Is responsibility of each code that use SPI to call init/begin as they need, so no code need to reset the SPI state to some "default".

If that line is causing some sort of conflict, it came be removed without any problem, as that line wasn't there before.

[bholzer]

Great find, thanks for the help @Pieterv24. I will just leave the card inserted for now until the fix proposed by @rhapsodyv gets merged.

[thisiskeithb]

https://github.com/MarlinFirmware/Marlin/pull/19226 has been merged. Closing.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.