search

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.24k stars 19.23k forks source link

[BUG] (MAX31865 no longer works after recent changes) #23439

Closed kurtis-potier-geofabrica closed 2 years ago

kurtis-potier-geofabrica commented 2 years ago

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

Yes, and the problem still exists.

Bug Description

Marlin now reports 989 as the temperature for both E0 and E1 after the recent changes to the MAX31865.cpp and associated files. With the older versions of Marlin, we were able to read temperatures successfully with the same hardware. Currently running on a Bigtreetech GTR V1.0 board using SPI pins as follows:

#define TEMP_0_CS_PIN                       PD4 
#define TEMP_0_SCK_PIN                      PB3 
#define TEMP_0_MISO_PIN                     PB6 
#define TEMP_0_MOSI_PIN                     PG15 /

#define TEMP_1_CS_PIN                       PC12 
#define TEMP_1_SCK_PIN           TEMP_0_SCK_PIN
#define TEMP_1_MISO_PIN         TEMP_0_MISO_PIN
#define TEMP_1_MOSI_PIN         TEMP_0_MOSI_PIN

These pins are different from the defaults in the firmware, but did work on previous versions of Marlin. Also have confirmed that SPI bus can be read by a Raspberry pi directly before entering the board. I can revert to the older firmware and get readings.

Bug Timeline

new

Expected behavior

Read temperatures correctly.

Actual behavior

Temperatures read 989 on boot. Err is then displayed,

Steps to Reproduce

No response

Version of Marlin Firmware

2.0.9.3

Printer model

No response

Electronics

BTT GTR V1.0 STM32F4

Add-ons

M5 extender

Bed Leveling

No response

Your Slicer

No response

Host Software

No response

Additional information & file uploads

MAX31865_issue.zip

kurtis-potier-geofabrica commented 2 years ago

After some more diagnosis, can confirm that the firmware is trying to access the software SPI bus (turned on debug and added a short delay before the print statements so I could connect over serial before the board errors out).

zeleps commented 2 years ago

Hi @kurtis-potier-geofabrica,

first of all, uncomment line 28 in temperature.cpp (#define IGNORE_THERMOCOUPLE_ERRORS), which will allow you debug the issue properly. Please keep in mind that this disables basic thermal runaway protection, so don't try to heat up your printer with this setting. Also enable MAX31865 debugging option (line 44 @ MAX31865.h).

Which is the last marlin release that worked for you? Is the SPI you're trying to use a hardware SPI? If yes, you may also try #define TEMP_SENSOR_FORCE_HW_SPI to see if it works for you.

I haven't had much luck using it with software SPI myself, but I didn't really look into it further, since I'm using HW SPI on my setup. Please provide some feedback on the questions above and we'll see what we can try next.

kurtis-potier-geofabrica commented 2 years ago

I will do that and be careful of that. The Marlin release 2.0.9.1 is working (downloaded in late September of 21). I have enabled MAX31865 debugging. I'm using Software SPI. I used to the debugging for MAX31865 to confirm this as well. I can also consider what hardware SPI would look like for my board. I'm using a screen that I believe also uses that bus though. My only reason to upgrade is that I get the occasional amount of interference where the temp will spike around 30C. I've seen this go away on my pellet extruder printers by using bang bang heating instead of PID. The new options implemented in 2.0.9.3 look very intriguing so that I could use PID again with my smaller systems without any random spikes. I will try out all of these options tomorrow. Thank you!

thinkyhead commented 2 years ago

Changes were most recently made in #23216 by @zeleps — so please check to see if reverting those changes helps. I am taking changes in this area on faith, so your testing is very important to helping get this stuff stabilized.

zeleps commented 2 years ago

There are also some important changes regarding software SPI in #22682, which are not included in 2.0.9.1. Try a commit before #23215 first and before #22682 after that, to see which causes the problem. I'll try to help you pinpoint the issue and fix it.

Regarding hw SPI, you can share an SPI with other devices (like the screen you're mentioning, that's what I'm doing), just use a different CS pin.

kurtis-potier-geofabrica commented 2 years ago

Good info. This gives me a bunch of things to try. I will have some results to share later today.

zeleps commented 2 years ago

If you're thinking of trying hw SPI btw, take a look at this hack: https://github.com/GadgetAngel/Adafruit-MAX31865-V1.1.0-Mod-M/issues/1#issuecomment-827122286

kurtis-potier-geofabrica commented 2 years ago

I flashed with everything prior to #23215 (Fix and improve MAX31865 by Zeleps). I get somewhat normal temps (room temp + 5C) for a few seconds and then Temp Measurement Errors. If I flash back to 2.0.9.1 (before #22682), then I get normal room temps and there is no errors. It looks like there was some renaming also done between #23215 and #22682. My working version is after #22660, so the problem is somewhere between then and now (likely #22682 or the renaming). This is still on the SW spi bus. I will next look at ordering parts for the hack Zeleps mentioned (unless I have other reasonable access on the board) there so that can be an option for me to try for now.

zeleps commented 2 years ago

That's good testing @kurtis-potier-geofabrica! Now that you mention it, the few-seconds-normal pattern has occurred in my tests as well, but I didn't test it further with sw SPI. I'll try some tests myself and see what I can find.

kurtis-potier-geofabrica commented 2 years ago

That would be great! Thank you

zeleps commented 2 years ago

I switched to sw SPI, and just like @kurtis-potier-geofabrica, I am receiving normal values at first (for a few reads):

Recv: MAX31865 RTD MSB:64 LSB:118

This is still being read after setup completes. Then, after a few more processes complete, SPI only reads 0xFF:

Recv: MAX31865 RTD MSB:255 LSB:255 Recv: MAX31865 read fault: 65535

Most obvious explanation is that some process affects SPI. I'll try to pin it down and return with more info.

zeleps commented 2 years ago

Just confirmed that disabling SD support eliminates the issue. @kurtis-potier-geofabrica please verify this. I'll delve into this later.

kurtis-potier-geofabrica commented 2 years ago

@zeleps I tried this, but it did not fix the problem for me. (I tried on both the non-working versions I've been experimenting with). My output from the SPI debug is a little different. I get the attached ouptut with ignore thermocouple errors on and max31865 debug on. Will look into the code more as well and see if I can find anything and try things out. I'm not the strongest with C++ but not totally illiterate either.
temp_errors_sdsupport_disabled

zeleps commented 2 years ago

The last bit of the LSB is an error flag, and in all the values you've posted the bit is set. From the messages I understand that this is the version prior to my changes, so could you please share the output you're getting with #23215?

I took a look at your board's pinout and I see that you're using the stepper driver SPI pins. Are you using the SPI for controlling the stepper drivers as well?

kurtis-potier-geofabrica commented 2 years ago

I did test both, but didn't log output. Here is the output after #23215. For my board, I am not using the spi bus for steppers. My drivers are external drivers. I have them configured as A4988, which is not using the spi. I do not use any of the other pins on the traditional E0,E1,E2 for steppers. My extruder is on the traditional Z axis slot and my Z axis steppers are on the M5 extender. My full pins file is attached here for reference.

temp_errors_sdsupport_disabled_2 0 9 3 pins_BTT_GTR_V1_0.zip

Edit: The extruder was at room temp when I booted.

zeleps commented 2 years ago

The line MAX31865 Fault: (1) >> shows the fault register value of the sensor. This value - 1 - is not a valid fault register value. It's strange, because the RTD values you're getting (e.g. 16599) are valid room temperature values, but the least significant bit is set, indicating fault.

Obviously your case is different from my case. It would have some value if you could connect to the serial as soon as the screen is cleared on reboot, in order to catch the early initialization messages. This would show what the first few reads look like, and when faulty reads occur.

It would also be a good indication for a possible issue with SoftwareSPI.cpp if you could hook up the sensor on the hw SPI (MISO=PB14, SCK=PB13, MOSI=PB15, any free pin will do for CS) and see if it works.

There is also this text by @GadgetAngel, which is specific to your board, and it might give you some insight: https://github.com/bigtreetech/BIGTREETECH-SKR-PRO-V1.1/issues/179#issue-741317998

kurtis-potier-geofabrica commented 2 years ago

I temporarily added a delay of 3 seconds to the softSPIBegin function and was able to connect during this delay period. initial_temp_errors_2 0 9 3

I will test out the hardware spi bus as well and see how that does. I'll assume that I can keep my current chip select pins the same and just switch the communication lines over as you have outlined there.

kurtis-potier-geofabrica commented 2 years ago

The behavior is the same on the hardware spi bus for me as the software. I dont have screen hooked up, so can't see quite as much. I slipped in an M105 before error to get a temp report. T0 read -242 while T1 read about room temperature. HW_SPI

zeleps commented 2 years ago

Ok, now T0 reads only 255 from the SPI (obvious read error) while T1 is working correctly. This is quite different than the screenshots you sent before, where both sensors read the room temperature with some fault indication. What was the exact setup you used this time? (meaning pin assignments)

kurtis-potier-geofabrica commented 2 years ago

I did the SPI pins as you suggested above and left my chip selects as PD4 and PC12.

zeleps commented 2 years ago

You must omit the definitions for sck/miso/mosi though, in order to enable hw SPI (or uncomment #define TEMP_SENSOR_FORCE_HW_SPI in Configuration_adv.h). You only need to declare the CS pins.

kurtis-potier-geofabrica commented 2 years ago

Yeah, I had #define TEMP_SENSOR_FORCE_HW_SPI uncommented.

zeleps commented 2 years ago

I'll get a second sensor on Monday and do some tests with two sensors. Since one of them works, this could have something to do with the SPI initialization being done more than once. I'll get back to you on this. Meanwhile, you could unplug one of the sensors and see if the other works.

zeleps commented 2 years ago

@kurtis-potier-geofabrica have you tried 1-shot mode? (commenting out #define MAX31865_USE_AUTO_MODE)

kurtis-potier-geofabrica commented 2 years ago

Yeah, I've tried both modes to see if that mattered. Didn't change anything for me unfortunately.

zeleps commented 2 years ago

I got a second sensor and run some tests. It seems that the second sensor does not initialize correctly in auto mode (it reads the correct temperature, but returns the fault bit set, and the fault register returns 64 - low threshold), but it does work after a while in 1-shot mode. I tried a hack that seems to work on my system (run a fault detection cycle during initialization), and now both sensors work ok in any mode under hw / sw SPI (sw SPI still conflicts with SD support). @kurtis-potier-geofabrica could you try this: https://github.com/zeleps/Marlin/commit/5d745e4b16828d2ea13f69e834a3c83d7523882f and see if it works for your setup?

GadgetAngel commented 2 years ago

I remember seeing this problem before.

If I am reading this correctly, the current problem is that with SPI and the MAX31865 you get an error bit set when doing TEMP readings.

I believe the problem is a startup issue between the two modules talking to each other (the MAX31865 module and the Printer's mother board). The TEMP readings are correct but for some reason the MAX31865 module sets the error bit. I believe this is a buffering problem on the side of the MAX31865 module.

Since we can not fix the firmware on the MAX31865 board, I messed around with the idea of doing a short temperature reading dump (5 TEMP readings and dump the values) after the first TEMP read and throw them away if they are determined to be obvious errors generated by the MAX31865 module.

I tried to watch the TEMP readings and set a acceptable range that I would expect the TEMP values to fall in. So If a TEMP readings come in and the next TEMP value is 10 degree higher then this is a obvious temperature error because temperature does not change values instantaneously when you are reading temperature values in milliseconds.

I determined later that Marlin does do a check of temperature readings and I could not get it working. But I honestly believe the MAX31865 module is setting the error bit and it should not be doing this.

The error bit could also being set due to noise on the SPI lines. When I did my testing I had bought two Logic Analyer devices so I could look at the actual data bits coming from the MAX31865 modules Logic Pro 8 (Red) - Saleae 8-Channel Logic Analyzer and DreamSourceLab DSLogic Plus USB-Based Logic Analyzer with 400MHz Sampling Rate .

Try dumping or ignoring the first 10 reading coming from the MAX31865 board (ignore the error bits) and then look at the error bit from temperature sample 11 and on. This might fix the issue.

zeleps commented 2 years ago

@GadgetAngel, this really clears things up, thanks! I found out all sorts of random things happening on power on, so I'm now running an automatic fault detection cycle and manually set threshold registers (I found out that sometimes they initialize to wrong values, e.g. I had low threshold = 0xffff after power on). This seems to tackle all issues so far and the cost is minimal (less than 1ms), so I'm not making it optional.

I've also implemented the hack you mentioned - just in case - so now you can #define MAX31865_IGNORE_INITIAL_FAULTY_READS XX to ignore and clear the fault bit for a limited (XX) number of times. This doesn't affect the temperature reading, so if the reading is not a valid temperature, a temp error will still occur.

@kurtis-potier-geofabrica please try this:

https://github.com/zeleps/Marlin/tree/bugfix-2.0.x-FixMAX31865

kurtis-potier-geofabrica commented 2 years ago

I will give this a shot. These solutions look like they have a good chance of fixing the problems. My cables are overall pretty solid (running shielded cables the whole way, properly grounded). Even with the current working version, I still see some random spikes and get the occasional error. I don't see this when reading through a Raspberry Pi, so it definitely has something to do with how the MAX31865 and the board talk to each other.

zeleps commented 2 years ago

Judging from your screenshots, I think that resetting the threshold registers will do the trick for you. Please remember to uncomment MAX31865.h line 44 (#define DEBUG_MAX31865).

kurtis-potier-geofabrica commented 2 years ago

I have (mostly) good news. If I use hardware SPI and:

define TEMP_SENSOR_FORCE_HW_SPI

define MAX31865_SENSOR_WIRES_0 2

define MAX31865_SENSOR_WIRES_1 2

//#define MAX31865_50HZ_FILTER

define MAX31865_USE_READ_ERROR_DETECTION

//#define MAX31865_USE_AUTO_MODE

define MAX31865_MIN_SAMPLING_TIME_MSEC 100

define MAX31865_IGNORE_INITIAL_FAULTY_READS 10

I am able to read both temperatures successfully. The readings seems stable without any random spikes (I'm reading over pronterface) that I would often see before. I am not using the screen at the moment because I have jumpers to those pins (I have to source the device to splice in that gadget angel was using). I was not able to replicate this success on software spi. I would initially get sort of decent readings (mid 30s at room temp) and then T0 would spike to mid 300s after a few seconds. I tried changing a number of settings to see if different options could get this to change, but the behavior remained the same. I'm going to get my wiring to a little more stable setup and hopefully get back my screen and then try some printing to see how it performs and if I get errors like I occasionally do with 2.0.9.1.

zeleps commented 2 years ago

Ok, it's obvious that some process is fiddling with the sw SPI. In my case it was SD. The last time you tried disabling SD was in this comment, and the result you posted was correct reads (meaning the SPI worked ok) with the fault bit set (which is now corrected by the latest changes I made). Please try this again (sw SPI, disable SDSUPPORT), and if it works we can be certain that SD SPI handling breaks the sw SPI used by the sensor.

I tried scratching the surface of the sw SPI issue on my system (SDSUPPORT + sw SPI for MAX31865), but it's something I haven't had any experience with, and I'm not sure I can help any more with that. So, unless someone else takes this up, I suggest you try the hw SPI with the injection hack I suggested above. I tried it with two sensors yesterday on my system and it works fine.

In order to do it properly, you'll need a couple of 2x5 female IDC connectors and a couple of 2x5 Dupont connectors (2x3 will also do) with male crimps (2x3 crimps). Crimp the IDC connectors at a convenient position on your EXP2 ribbon cable (same orientation as the end connectors):

image image

Then, make 2 Dupont connectors as shown (green = MISO, grey = SCK, blue = MOSI):

image image

Please keep in mind that the connectors may come off easily, so it might be a good idea to keep them out of reach or maybe use some kind of binder to keep them securely fastened.

CS pins may be hooked up to any pair of free digital pins.

I suspect you've already figured out the above, but I guess it might be helpful to post them for people who end up here looking for the same thing.

kurtis-potier-geofabrica commented 2 years ago

I have those parts on order, should be coming in on Wednesday. I will double check the software spi, but I believe those were the settings I had when I tested (no sdsupport). I understand the hardware spi may be more robust, so I think its best I move to that long term.

zeleps commented 2 years ago

In that test (disabled SD), your SPI seemed to work ok, but the issue with threshold registers having invalid values remained, so you got normal reads with the fault bit set. It should work flawlessly now (with SD disabled, obviously).

kurtis-potier-geofabrica commented 2 years ago

I tried again with the software spi bus. I got the same result as before. This could potentially be board specific. I'm personally fine with using the hardware spi since it seems like the most optimal way to go anyway and we now have it working. If you have other ideas, I'm happy to test them though. Attached is some output from my testing with software spi. sw_spi_fault

zeleps commented 2 years ago

Can you please try and capture serial output right after boot? It starts emitting as soon as the display goes blank (before boot screen appears) and there's some relevant data logged at that time that would be useful...

kurtis-potier-geofabrica commented 2 years ago

Yep, I will do this. I have a print running for a couple hours right now with the output going to pronterface and auto report of temps on (and MAX debugging) so I can look and see how the performance is over a print. After, I will convert back and try to log the output again. Will probably have to throw the delay in again on startup since the connection doesn't happen too fast.

zeleps commented 2 years ago

What I want to see is a line like MAX31865 Regs: CFG XX|RTD YY|..., it's a dump of all register values at initialization. Preferably, after a power on, not just a reset. It will probably show why you're receiving faulty values.

I'd also suggest you use AUTO_MODE. There's no sense in 1-shot mode in marlin, just waste of time.

kurtis-potier-geofabrica commented 2 years ago

got the output needed. Here it is, settings are same as before with the exception of using auto mode. Also, once I converted back to hardware SPI, I used auto mode and that also works fine. sw_spi_fault_initial

zeleps commented 2 years ago

Thank you so much for all the trouble you went through! Unfortunately, the numbers don't clear up things, in fact it seems that the temperatures read are off the charts at first (1st sensor), then they settle towards room temperature. I added some more debug info, in case of fault. If you could do one last test (I promise I won't ask for more after this) with sw SPI and AUTO_MODE with my latest commit, that would be great (unfortunately, I cannot reproduce the issue you're having with sw SPI on my board).

zeleps commented 2 years ago

Also, a M43 I to dump your pin usage and states would be useful.

kurtis-potier-geofabrica commented 2 years ago

Added your commits on today and yesterday to the MAX31865.cpp file. My results unfortunately are not different. I still get a high reading on T0 and a slightly high but not terrible reading on T1. I tried M43 I, for some reason, it is not recognized and I get back echo:Unknown command: "M43 I", also tried regular M43. I have no issue trying stuff out. I would like to help get this to a stable state since I plan to work with these sensors a lot more in the future. sw_spi_fault_1_11_22

zeleps commented 2 years ago

This does not make sense, at least not with what can be made out of the sensor's datasheet. It appears that the sensor is in an invalid state. My only guess is that the sw SPI does not handle signaling as it should in your case, but that's not something I can help with, at least not without a way to reproduce the error, which probably means I need to get the same board as you have. So, since hw SPI is performing well now, I'll leave the sw SPI problem to someone else to tackle.

It would still be worthwhile to look at your pin states, you can enable M43 by uncommenting #define PINS_DEBUGGING at the end of Configuration_adv.h. I'm not sure I'll find something interesting, but still it costs little to do this.

Thanks again for the tests, at least we managed to find and correct some of the issues.

kurtis-potier-geofabrica commented 2 years ago

Got that turned on and went back to the software spi quickly. Here is the output, it is very lengthy: PIN: PA2 (A2) M42 P37 HEATER_BED_PIN Output = 0 PIN: PA3 (A3) M42 P38 <unused/unknown> Input = 1 PIN: PA4 (A4) M42 P39 <unused/unknown> Output = 1 PIN: PA5 (A5) M42 P40 <unused/unknown> Alt Function: 5 - SPI1/SPI2 PIN: PA6 (A6) M42 P41 <unused/unknown> Alt Function: 5 - SPI1/SPI2 PIN: PA7 (A7) M42 P42 <unused/unknown> Alt Function: 5 - SPI1/SPI2 PIN: PA8 M42 P16 <unused/unknown> Input = 1 PIN: PA9 M42 P17 <unused/unknown> Input = 1 PIN: PA10 M42 P18 <unused/unknown> Input = 1 PIN: PA11 M42 P19 <unused/unknown> Alt Function: 10 - OTG PIN: PA12 M42 P20 <unused/unknown> Alt Function: 10 - OTG PIN: PA13 M42 P21 <unused/unknown> Alt Function: 0 - system (misc. I/O) PIN: PA14 M42 P22 <unused/unknown> Alt Function: 0 - system (misc. I/O) PIN: PA15 M42 P23 <unused/unknown> Alt Function: 0 - system (misc. I/O) PIN: PB0 (A8) M42 P43 HEATER_2_PIN Output = 0 PIN: PB1 (A9) M42 P44 HEATER_0_PIN Output = 0 PIN: PB2 M42 P5 <unused/unknown> Input = 0 PIN: PB3 M42 P28 TEMP_0_SCK_PIN Output = 0 . TEMP_1_SCK_PIN Output = 0 PIN: PB4 M42 P29 <unused/unknown> Alt Function: 0 - system (misc. I/O) PIN: PB5 M42 P30 <unused/unknown> Input = 1 PIN: PB6 M42 P31 TEMP_0_MISO_PIN Input = 1 . TEMP_1_MISO_PIN Input = 1 PIN: PB7 M42 P32 E0_DIR_PIN Output = 1 PIN: PB8 M42 P33 E0_STEP_PIN Output = 0 PIN: PB9 M42 P34 E0_ENABLE_PIN Output = 1 PIN: PB10 M42 P6 <unused/unknown> Input = 1 PIN: PB11 M42 P7 <unused/unknown> Input = 1 PIN: PB12 M42 P8 <unused/unknown> Input = 1 PIN: PB13 M42 P9 <unused/unknown> Input = 1 PIN: PB14 M42 P10 <unused/unknown> Input = 1 PIN: PB15 M42 P11 <unused/unknown> Input = 1 PIN: PC0 (A10) M42 P45 <unused/unknown> Analog in = 0 Input = 0 PIN: PC1 (A11) M42 P46 <unused/unknown> Input = 1 PIN: PC2 (A12) M42 P47 <unused/unknown> Input = 1 PIN: PC3 (A13) M42 P48 <unused/unknown> Input = 1 PIN: PC4 (A14) M42 P49 <unused/unknown> Input = 0 PIN: PC5 (A15) M42 P50 <unused/unknown> Input = 1 PIN: PC6 M42 P12 <unused/unknown> Input = 1 PIN: PC7 M42 P13 <unused/unknown> Input = 1 PIN: PC8 M42 P14 FAN2_PIN Alt Function: 3 - TIM8..11 (probably PWM) PIN: PC9 M42 P15 <unused/unknown> Input = 0 PIN: PC10 M42 P24 <unused/unknown> Input = 1 PIN: PC11 M42 P25 <unused/unknown> Input = 1 PIN: PC12 M42 P26 E2_CS_PIN Output = 1 . TEMP_1_CS_PIN Output = 1 PIN: PC13 M42 P0 Y_MIN_PIN Input = 0 . Y_DIAG_PIN Input = 0 . Y_STOP_PIN Input = 0 PIN: PC14 M42 P1 <unused/unknown> Input = 1 PIN: PC15 M42 P2 X_STEP_PIN Output = 0 PIN: PD0 M42 P81 E2_DIR_PIN Input = 1 PIN: PD1 M42 P82 E2_STEP_PIN Input = 1 PIN: PD2 M42 P27 E2_ENABLE_PIN Input = 0 PIN: PD3 M42 P83 E2_DIAG_PIN Input = 1 PIN: PD4 M42 P84 TEMP_0_CS_PIN Output = 1 PIN: PD5 M42 P85 E1_DIR_PIN Output = 0 PIN: PD6 M42 P86 E1_STEP_PIN Output = 0 PIN: PD7 M42 P87 E1_ENABLE_PIN Output = 1 PIN: PD8 M42 P73 <unused/unknown> Alt Function: 7 - USART1..3 PIN: PD9 M42 P74 <unused/unknown> Alt Function: 7 - USART1..3 PIN: PD10 M42 P75 <unused/unknown> Input = 1 PIN: PD11 M42 P76 Z2_DIR_PIN Output = 1 PIN: PD12 M42 P77 HEATER_5_PIN Output = 0 PIN: PD13 M42 P78 HEATER_4_PIN Output = 0 PIN: PD14 M42 P79 Z2_STEP_PIN Output = 0 PIN: PD15 M42 P80 HEATER_3_PIN Output = 0 PIN: PE0 M42 P88 Z_DIAG_PIN Input = 1 PIN: PE1 M42 P89 <unused/unknown> Input = 1 PIN: PE2 M42 P59 Y_DIR_PIN Output = 1 PIN: PE3 M42 P60 Y_STEP_PIN Output = 0 PIN: PE4 M42 P61 Y_ENABLE_PIN Output = 1 PIN: PE5 M42 P62 FAN_PIN Alt Function: 0 - system (misc. I/O) PIN: PE6 M42 P63 E0_AUTO_FAN_PIN Output = 1 . E1_AUTO_FAN_PIN Output = 1 . E2_AUTO_FAN_PIN Output = 1 . FAN1_PIN Output = 1 PIN: PE7 M42 P64 Z3_CS_PIN Input = 1 PIN: PE8 M42 P65 Z4_ENABLE_PIN Output = 1 PIN: PE9 M42 P66 FAN4_PIN Alt Function: 0 - system (misc. I/O) PIN: PE10 M42 P67 Z3_DIR_PIN Output = 1 PIN: PE11 M42 P68 FAN5_PIN Alt Function: 0 - system (misc. I/O) PIN: PE12 M42 P69 Z3_STEP_PIN Output = 0 PIN: PE13 M42 P70 HEATER_6_PIN Output = 0 PIN: PE14 M42 P71 <unused/unknown> Input = 0 PIN: PE15 M42 P72 Z2_CS_PIN Input = 1 PIN: PF0 M42 P90 X_DIR_PIN Output = 1 PIN: PF1 M42 P91 X_ENABLE_PIN Output = 1 PIN: PF2 M42 P92 X_MIN_PIN Input = 0 . X_DIAG_PIN Input = 0 . X_STOP_PIN Input = 0 PIN: PF3 (A16) M42 P51 Z_STEP_PIN Output = 0 PIN: PF4 (A17) M42 P52 X_MAX_PIN Input = 0 . Z2_MIN_PIN Input = 0 PIN: PF5 (A18) M42 P53 <unused/unknown> Input = 1 PIN: PF6 (A19) M42 P54 Y_MAX_PIN Input = 0 . Z3_MIN_PIN Input = 0 PIN: PF7 (A20) M42 P55 <unused/unknown> Input = 1 PIN: PF8 (A21) M42 P56 Z_ENABLE_PIN Output = 1 PIN: PF9 (A22) M42 P57 <unused/unknown> Input = 1 PIN: PF10 (A23) M42 P58 <unused/unknown> Input = 1 PIN: PF11 M42 P93 <unused/unknown> Input = 1 PIN: PF12 M42 P94 <unused/unknown> Input = 1 PIN: PF13 M42 P95 <unused/unknown> Input = 1 PIN: PF14 M42 P96 Z3_ENABLE_PIN Output = 1 PIN: PF15 M42 P97 Z4_CS_PIN Input = 1 PIN: PG0 M42 P98 Z4_STEP_PIN Output = 0 PIN: PG1 M42 P99 Z4_DIR_PIN Output = 1 PIN: PG2 M42 P100 Z2_ENABLE_PIN Output = 1 PIN: PG3 M42 P101 Z_DIR_PIN Output = 1 PIN: PG4 M42 P102 <unused/unknown> Input = 1 PIN: PG5 M42 P103 <unused/unknown> Input = 1 PIN: PG6 M42 P104 <unused/unknown> Input = 1 PIN: PG7 M42 P105 <unused/unknown> Input = 1 PIN: PG8 M42 P106 <unused/unknown> Input = 1 PIN: PG9 M42 P107 E1_DIAG_PIN Input = 1 PIN: PG10 M42 P108 <unused/unknown> Input = 1 PIN: PG11 M42 P109 <unused/unknown> Input = 1 PIN: PG12 M42 P110 <unused/unknown> Input = 1 PIN: PG13 M42 P111 <unused/unknown> Input = 1 PIN: PG14 M42 P112 E0_DIAG_PIN Input = 1 PIN: PG15 M42 P113 TEMP_0_MOSI_PIN Output = 0 . TEMP_1_MOSI_PIN Output = 0 PIN: PH0 M42 P3 <unused/unknown> Input = 0 PIN: PH1 M42 P4 <unused/unknown> Input = 0 PIN: PH2 M42 P118 <unused/unknown> Input = 0 PIN: PH3 M42 P119 <unused/unknown> Input = 0 PIN: PH4 M42 P120 <unused/unknown> Input = 0 PIN: PH5 M42 P121 <unused/unknown> Input = 0 PIN: PH6 M42 P122 <unused/unknown> Input = 0 PIN: PH7 M42 P123 <unused/unknown> Input = 0 PIN: PH8 M42 P124 <unused/unknown> Input = 0 PIN: PH9 M42 P125 <unused/unknown> Input = 0 PIN: PH10 M42 P126 <unused/unknown> Input = 0 PIN: PH11 M42 P127 <unused/unknown> Input = 0 PIN: PH12 M42 P128 E7_STEP_PIN Input = 0 PIN: PH13 M42 P129 <unused/unknown> Input = 0 PIN: PH14 M42 P130 E7_CS_PIN Input = 0 PIN: PH15 M42 P131 E7_DIR_PIN Input = 0 PIN: PI0 M42 P132 E7_ENABLE_PIN Input = 1 PIN: PI1 M42 P133 <unused/unknown> Input = 1 PIN: PI2 M42 P134 <unused/unknown> Input = 1 PIN: PI3 M42 P135 <unused/unknown> Input = 1 PIN: PI4 M42 P136 Z_MIN_PIN Input = 0 . Z_STOP_PIN Input = 0 PIN: PI5 M42 P137 FAN3_PIN Alt Function: 0 - system (misc. I/O) PIN: PI6 M42 P138 HEATER_7_PIN Output = 0 PIN: PI7 M42 P139 Z_MAX_PIN Input = 0 . Z4_MIN_PIN Input = 0 PIN: PI8 M42 P114 <unused/unknown> Input = 1 PIN: PI9 M42 P115 <unused/unknown> Input = 1 PIN: PI10 M42 P116 <unused/unknown> Input = 1 PIN: PI11 M42 P117 <unused/unknown> Input = 1

zeleps commented 2 years ago

The only thing that sticks out is that you're using the same pin for E2_CS and TEMP1_CS:

PIN: PC12 M42 P26 E2_CS_PIN Output = 1 . TEMP_1_CS_PIN Output = 1

This shouldn't be a problem, since you're not actually using E2 or TMC driver control, but I guess you could use any other unused pin instead and see if it helps.

Did you ever try using only one of the sensors (and completely unhook the other)?

Anyway, since you're moving to hw SPI and I've run out of ideas, let's leave it at that. Unless someone else has something to add / try.

kurtis-potier-geofabrica commented 2 years ago

Did not get around to do only the one sensor. Also, agreed, no driver is hooked up to those pins, so not shared.

zeleps commented 2 years ago

Hey @kurtis-potier-geofabrica, I just finished refactoring the sw SPI code in MAX31865. Now it works fine on my board, even with SD support enabled, with one or two sensors hooked up. I fixed a lot of stuff that had to do with timing, trying to be as close to the MAX31865 datasheet as possible.

If you're still eager to help out, please check it out here.

GadgetAngel commented 2 years ago

This does not make sense, at least not with what can be made out of the sensor's datasheet. It appears that the sensor is in an invalid state. My only guess is that the sw SPI does not handle signaling as it should in your case, but that's not something I can help with, at least not without a way to reproduce the error, which probably means I need to get the same board as you have. So, since hw SPI is performing well now, I'll leave the sw SPI problem to someone else to tackle.

It would still be worthwhile to look at your pin states, you can enable M43 by uncommenting #define PINS_DEBUGGING at the end of Configuration_adv.h. I'm not sure I'll find something interesting, but still it costs little to do this.

Thanks again for the tests, at least we managed to find and correct some of the issues.

@zeleps I have a BTT GTR board I can send to you (if you live in the USA) so you can debug the issue. Where do you live?

@zeleps Do you really live in Greece? I can ship the GTR board to you via USPS but I will need your address and it will take about a week to get to you (I think). How do we get in touch with each other? Are you on the Voron Discord server? If you are you can direct message me at "GadgetAngel#8701" that is my discord handle

@zeleps Here is an invite to the Voron Discord channel

zeleps commented 2 years ago

Mine's zeleps#8169, I'll dm you later when I'm somewhere more comfortable.

kurtis-potier-geofabrica commented 2 years ago

I can definitely try this out. My wiring is a little more permanently switched to HW SPI now, but converting back for a test shouldn't be too bad.