MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.3k stars 19.25k forks source link

[BUG] SKR Pro V1.1 + MAX31865 on bugfix 2.0.x. Compiles but does not post #16766

Closed PM2189 closed 4 years ago

PM2189 commented 4 years ago

Marlin will not boot after updating firmware with MAX31865 for a PT100 on Extruder 0.

Board: BTT SKR Pro V1.1 Drivers: TMC5160 on X,Y,Z,E0 I²C EEPROM module

Extruder Temperature by PT100 RTD Bed Temperature by 100KΩ Thermistor Chamber Temperature by 10KΩ Thermistor

MAX31865 MISO, MOSI, and SCK pins were set to the same pins as the TMC5160 drivers (PC11, PC12, PC10). CK was set to PF7.

MAX31865 board was tested and found functional.

Configuration.txt Configuration_adv.txt pins_BTT_SKR_PRO_V1_1.txt

furbyhaxx commented 4 years ago

Is it possible that the max31865 generally don't work on stm32 boards with marlin?

bdelia commented 4 years ago

Not sure this will help, but I have seen that when I set my TEMP_SENSOR_0 = 20 so that I can use a PT100 amplifier I get similar results of the FW compiling without issues but the board not posting or getting recognized by Windows. If I then keep all configurations in place by assign TEMP_SENSOR_0 = 1 everything works. I am beginning to wondering if there is a defect relating to the PT100 amp board selection for the TEMP_SENSORs

wormley commented 4 years ago

This doesn't look like an SPI problem.

There are a number of things that I don't like in the MAX31865 code and I'm working to make changes and ultimately a PR, but the first one that appears to cause this bug is in the function: updateTemperaturesFromRawValues() where it has:

if ENABLED(MAX6675_IS_MAX31865)

          max31865.temperature(100, 400)  // 100 ohms = PT100 resistance. 400 ohms = calibration resistor

This function doesn't want the current temperature in all cases, one time it's used is to try and figure out what the max and minimum raw values are if you set limits.(at the define for _TEMP_MIN_E ) In this case the code gets into an infinite loop since the return value never changes. The fix for that issue is to simply replace the function call with return(raw); as the raw value from the READ call is just the temp.

Of course, now I'm hitting a MINTEMP error so I need to do more debugging and see if the sensor is being read correctly. But at least it's not hanging without an error.

AnHardt commented 4 years ago

if ENABLED(MAX6675_IS_MAX31865)

max31865.temperature(100, 400) // 100 ohms = PT100 resistance. 400 ohms = calibration resistor

Why the hell a hard coded 400 Ohm for the reference resistor? The Adafruit modules and all known Chinese clons do have a 430 +-0.1% Ohm resistor.

sjasonsmith commented 4 years ago

We downgraded the dependency from master to 1.1 to fix compilation broken in 1.2. It is possible that there are important fixes between those two versions, and we need to depend on a specific commit rather than a released version. Just something to consider.

wormley commented 4 years ago

It all looks fine with 1.1 the change from 1.1 to 1.2 appears to just be moving the SPI code from internal to the BusIO library.

I've now enabled TMC on SPI on the same pins as the MAX31865 and nothing has crashed yet and the temperatures look sane. My branch is nowhere near ready to merge, mostly because I broke MAX6675 in the process, but can be viewed here for a diff: https://github.com/MarlinFirmware/Marlin/compare/bugfix-2.0.x...wormley:local

boelle commented 4 years ago

@PM2189 still an issue?

boelle commented 4 years ago

Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.

github-actions[bot] commented 4 years ago

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.