[BUG] STM32 HAL software SPI bug

[bigtreetech]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/HAL/STM32/HAL_SPI.cpp#L81

Here is the initialization function of software SPI, but it does call the hardware SPI API of Arduino framework.

Bug Timeline

No response

Expected behavior

No response

Actual behavior

Octopus-Pro, Enable TMC SPI、LCD SD SPI、Max31865 SPI at the same time and use the software SPI. After calling SPI.begin();, Max31865 cannot read the normal temperature and report the max temp error.

Steps to Reproduce

No response

Version of Marlin Firmware

Commits on Nov 2, 2021

Printer model

No response

Electronics

No response

Add-ons

No response

Bed Leveling

No response

Your Slicer

No response

Host Software

No response

Additional information & file uploads

No response

[thisiskeithb]

@slowbro Can you take a look at this?

[Portzal]

I am having the following issues that may be related?

BTT Octopus Pro (429) TMC5160’s I have sensor less homing working great using SPI_ENDSTOPS, but with a SD card with a print file on it in the BTT TFT or onboard SD, the machine false triggers when it goes to home. If I print from the TFT U Disk every thing works as expected.

[slowbro]

I think the issue is that there is not enough grace time for the MAX TC to get a temp reading. I wonder if it would eventaully be able to read the temp OK. @bigtreetech have you tried enabling IGNORE_THERMOCOUPLE_ERRORS in temperature.cpp and seeing it it works otherwise?

[bigtreetech]

No, but I can try it now. However, In theory, after calling SPI.begin();, the GPIO corresponding to MOSI, MISO, SCK will be set to Alternate function mode instead of General purpose output push-pull mode required by the software SPI. Therefore, the software SPI cannot read the correct data

[bigtreetech]

IGNORE_THERMOCOUPLE_ERRORS Can't solve the problem

[thinkyhead]

@bigtreetech — It would help to get calls to SPI.begin() sorted out generally. Maybe it's not the call to SPI.begin() here, but a specific call to spiInit() someplace else…? Maybe some calls to SPI.begin() are supposed to be calls to spiBegin() instead…? I see that HAS_MAXTC_SW_SPI causes spiBegin and spiInit to get called…. Maybe we just need to set a flag after it's been called once to not call it again….

[github-actions]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions]

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.