SKR3 EZ + TMC2209

[xhejtman]

Hello,

I have SKR3 EZ board with old TMC2209 drivers that should be compatible. However, I am getting:

Driver registers:                                                                                                                     
                X       0x00:00:00:00    Bad response!                                                                                
                Y       0xC0:10:00:00                                                                                                 
                Z       0x00:00:00:00    Bad response!                                                                                
                Z2      0x00:00:00:00    Bad response!                                                                                
                E       0x80:14:00:C0                                                                                                 

Testing X connection... Error: All LOW                                                                                                
Testing Y connection... OK                                                                                                            
Testing Z connection... Error: All LOW                                                                                                
Testing Z2 connection... Error: All LOW                                                                                               
Testing E connection... OK                                                                                                            
//action:notification TMC CONNECTION ERROR   

but despite of this, all axis can move, so it looks like a spurious error? Also it changes randomly, which connection is ok and which has an error. Z2 is connected to E1, number of extruders is set to 1.

[Caz3mir]

I have the same problem, but as @vwsurfer also on a SRK3 (not EZ) but with TMC2209. In my case M122 reports "Bad response" and "All low" for all 5 drivers. I tried building different versions of Marlin on a Ubuntu 20.04 machine using VS Code 1.70.2, PIO Core 6.1.4, PIO Home 3.4.3 and on a MacOS 10.13 machine using Atom, PIO Core 6.1.4, PIO Home 3.4.3.

How are you powering the board? All low could be because you are powering from usb. In my case it is getting 24v from a 4A power supply.

[Setix]

Im using a Meanwell UHP-500R-24 so it’s definitely not a lack of amperage.

[Caz3mir]

Has anyone tried compiling Marlin with the BTT EZ drivers found Here ?

I would try this but I’m out of town at the moment

There is no software there, only 3d files and pdfs. Besides, the TMCStepper library is loaded automatically by Platformio, i tried 0.7.3 and a few older ones. I was unable to load the 0.5.5 old one from here https://github.com/bigtreetech/TMCStepper

[Setix]

Has anyone tried compiling Marlin with the BTT EZ drivers found Here ? I would try this but I’m out of town at the moment

There is no software there, only 3d files and pdfs. Besides, the TMCStepper library is loaded automatically by Platformio, i tried 0.7.3 and a few older ones. I was unable to load the 0.5.5 old one from here https://github.com/bigtreetech/TMCStepper

I JUST realized that looking through the repo on my phone…ugh…ok disregard

[FlyingSamson]

How are you powering the board? All low could be because you are powering from usb. In my case it is getting 24v from a 4A power supply.

I used a Siglent lab power supply to generate 24V with Amperage limited to 3A (but that Amerage is not even close to being exhausted)

[TOTA42]

I have the same issue where X, Z, and E1 giving Error: All low as everybody else is having. Running ninjadudexp's firmware.bin showed the connection worked as well. I did a test by swapping the pins around in the pins_BTT_SKR_V3_0_common.h and it follows the pins (i.e. if I swap X & Y and Z & E, the errors are now at Y, E, and E1) so I'm wondering if somehow the IO pins get configured differently or there's some conflict issue. It would be great to know how that firmware.bin differs from everything else. I'm using this for my Ender 3 v2 and this is the only issue I have so far.

[Pardiman]

Any problem with software serial? Can we use hardware serial on the SKR 3 EZ board?

At this point I have no knowledge of how to do it. I have come to see that "Serial1" (in pins_BTT_SKR_V3_0_common.h) is not defined, but I do not know if any other ports have to be sacrificed or if physical pins are necessary.

[Bakorlam]

See something I've been wondering about too; from page 13 of the SKR3 EZ manual-

3.3.2 TMC/EZ-driven UART/SPI Mode TMC series drivers do not support the use of both UART and SPI drivers at the same time, for example: X, Y-axis use TMC/EZ2209 (UART), Z, E0 axis use TMC/EZ5160 (SPI). The EZ series drivers support the simultaneous use of both UART and SPI drivers.

[Pardiman]

Bakorlam, I think the manual refers to the fact that the EZ series, unlike normal TMCs, does not use physical pins for its configuration, does almost everything by software and will have designed or programmed something to make UART and SPI drivers compatible on the same board.

My problem is that the EZ2209 are exclusively UART by software, but if they do not communicate with the board to be able to configure them by software, they are useless. My Z axis has a very low torque and loses steps, but if I do not have communication I can not raise the current via software, or at least, I raise the current and does not improve the torque. I think that those of you who have normal TMC2209, at least, can regulate the current adjustment potentiometer, even if you lose the other characteristics.

By the way, with the firmware of ninjadudexp I have not managed to improve the torque of the Z axis either.

Bakorlam, xhejtman tested with TMC5160 drivers and it seems that SPI works correctly. I have ordered some EZ5160 drivers, to test, although they are totally oversized for what I needed.

It does work with TMC5160 drivers, they are all connected.

Sorry if I've been a little confused in explaining it, I'm not sure it works exactly like that either.

[JoaquinBerrios]

So I tried Klipper and everything works as expected, so definitely not a hardware issue. I'm able to debug and configure all the drivers without issue, they all work as expected and don't appear to be loosing steps.

At this point I would lean towards an incompatibility of the TMCStepper library with other dependencies of this board. The 2209 and 5160 drivers are handled differently by the library, where the 2208 and 2209's share a ton of the code and both are having issues with this board. Unfortunately, I'm not a good enough coder to troubleshoot beyond that.

It's still weird to me that some people are able to get a build that works while others can't using the same version of the library. It would be nice to have a build log from someone who built this successfully to compare (HINT HINT BTT!).

[vwsurfer]

JoaquinBerrios My SKR 3 Is fixed with no errors. I Built the Marlin for my printer tried it and got the TMC error, then i sent the .h and .adv and platform.ini to my friend. He compiled it in his vscode V1.60 and sent me the bin file, Works perfectly with no errors. Its something to do with VScode or VScode enviroment.

[JoaquinBerrios]

vwsurfer, any way your friend cloud send the build log from that build? I get that he's doing you a favor so no worries if no, but it would be interesting to see if a diff of his build log and mine give any clues. If he's building using VSC 1.60 I may try that. Currently using 1.70.2. Would be interesting to get the details from his VSC Help>About. Here are mine.

Version: 1.70.2 (user setup) Commit: e4503b30fc78200f846c62cf8091b76ff5547662 Date: 2022-08-16T05:35:13.448Z Electron: 18.3.5 Chromium: 100.0.4896.160 Node.js: 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0.19044

[TOTA42]

Uninstalled and reinstalled using VSC 1.60 and still have the same issue. Other possible variables are the extension versions (PlatformIO IDE or the C/C++) The versions I'm using for those is 2.50 for PlatformIO IDE and 1.71 for C/C++ extensions.

[Caz3mir]

Just recompiled on 1.60.2 and i have the same errors. I did manage to get different results by changing _SLAVE_ADDRESS for each axis on the adv configuration. I just don't understand the whole UART stuff very well.

[Bakorlam]

So I just downloaded VS code from Jan 22 (1.64.2) and it gave me errors when I compiled that the most recent version did not. Including the incompatibility with the BTT driver lib and a missing ;

[TOTA42]

@Caz3mir The slave address should be 0's for the EZ2209. They are controlled by the TMC2209's MS1 and MS2 pins, which according to BTT's schematic, they are floating and the TMC2209 datasheet says it has an internal pull down, so "00".

[xhejtman]

could you try to define #define TMC_USE_SW_SPI ? I know it is not related to TMC2209, but it influences MS1 and MS2 pins, perhaps floating side on MCU randomly selects address?

[TOTA42]

could you try to define #define TMC_USE_SW_SPI ? I know it is not related to TMC2209, but it influences MS1 and MS2 pins, perhaps floating side on MCU randomly selects address?

Don't see how TMC_USE_SW_SPI impacts it as the MS1 and MS2 pins are part of the TMC2209, not the MCU and there's no electrical connection from the MCU to the TMC2209's MS1/MS2 pins.

[xhejtman]

It is. According to schema, pine PE13, PE14, PE15 are connected - they must be because in case of TMC2130 drivers, they are used for SPI.

[Caz3mir]

could you try to define #define TMC_USE_SW_SPI ? I know it is not related to TMC2209, but it influences MS1 and MS2 pins, perhaps floating side on MCU randomly selects address?

Same error occurs, ALL LOW.

[vwsurfer]

JoaquinBerrios I will ask him tonight, I onlu get to speak to him when its my 1am so it can be hit or miss if im asleep. I would suggets you send me youre 3 files and ill have the compiled. I downloaded vscode to two other machines with no fix.

[TOTA42]

It is. According to schema, pine PE13, PE14, PE15 are connected - they must be because in case of TMC2130 drivers, they are used for SPI.

Interesting, the EZ2209 schematic does not have MS1/MS2 connected, but the EZ2208 schematic as well as the old TMC2209 driver does have MS1/MS2 connected mostly so it can control the microstep configuration in standalone mode. I wonder if you set the drivers for TMC2208 or TMC2209 (with the non-EZ2209 driver), the software configures MS1/MS2 pins to match the _SLAVE_ADDRESS. I haven't bothered to check as I'm using the EZ2209 where MS1/MS2 are not connected.

[donmahallem]

I wonder if you set the drivers for TMC2208 or TMC2209 (with the non-EZ2209 driver), the software configures MS1/MS2 pins to match the _SLAVE_ADDRESS. I haven't bothered to check as I'm using the EZ2209 where MS1/MS2 are not connected.

i could try that later. Would you mind to elaborate a little more on this what I should try? I do know my way around source code but electronics is 50% witchcraft for me

[JoaquinBerrios]

vwsurfer, I appreciate the offer, but I don't want to put your friend in the position of building firmware for strangers. :-) I know the hardware works since I'm running Klipper and can configure and debug the drivers just fine, and the drivers work fine with the version of Marlin posed earlier in the thread.

I also would like to know the root cause for this issue since this is unlikely to be the last time I want to build Marlin for this board.

[Pardiman]

JoaquinBerrios and vwsurfer, I don't think it's VSCode's problem, because I've tried building with PlatformIO Core from the command line with VSCode uninstalled and the problem persists. If it is an environment problem, then it is Platformio or some library.

D:\>platformio --version
PlatformIO Core, version 6.1.4

I'm looking for a way to install an older version, but I don't see how.

[FlyingSamson]

JoaquinBerrios My SKR 3 Is fixed with no errors. I Built the Marlin for my printer tried it and got the TMC error, then i sent the .h and .adv and platform.ini to my friend. He compiled it in his vscode V1.60 and sent me the bin file, Works perfectly with no errors. Its something to do with VScode or VScode enviroment.

@vwsurfer did you also try exchanging the entire Marlin folder (the one containing the .ini file) with your friend? Both ways might be interesting: I.e. if he opens your version of the Marlin folder in VSCode and builds it, is the resulting .bin file working on your machine and the other way round if you open his Marlin folder in your VSCode and build it, is the resulting .bin file working on your machine? This would make sure that it is indeed not a matter of a different commit or otherwise different source tree.

In any case it would be interesting to have his entire Marlin folder after the build (including the sources but also the build directory including the linked libs and compiled sources) and of course as already mentioned by JoaquinBerrios the build log.

[FlyingSamson]

Btw, did anyone run into issue that variant_MARLIN_STM32H743VX.h cannot be found as the repo contains variant_MARLIN_STM32H743Vx.h file (lowercase x).

@xhejtman: I run into this problem, too. Can you enlighten me how to fix this? I was unable to find the place in the code where the variant with upper case X stems from (only found a .json file containing this but changing it in there to lower case did not help)

---

Update: Never mind, I only searched in the Marlin subfolder. For anyone having the same issue: Renaming <marlin root>/buildroot/share/PlatformIO/variants/MARLIN_H743Vx/variant_MARLIN_STM32H743Vx.h to have a capital X at the end 'fixes' this.

[Pardiman]

I have only been able to downgrade Platformio to version 6.1.1 and it has not worked:

Error: Marlin requires PlatformIO >= 6.1.1. Use 'pio upgrade' to get a newer version.

To downgrade Platformio to version 6.1.1:

pip install -U "platformio<6.1.2"

[donmahallem]

Do we want to raise/move this issue maybe over to the Marlin repository as it looks like it is a firmware issue?

[TOTA42]

I wonder if you set the drivers for TMC2208 or TMC2209 (with the non-EZ2209 driver), the software configures MS1/MS2 pins to match the _SLAVE_ADDRESS. I haven't bothered to check as I'm using the EZ2209 where MS1/MS2 are not connected.

i could try that later. Would you mind to elaborate a little more on this what I should try? I do know my way around source code but electronics is 50% witchcraft for me

@donmahallem , well you can turn on GCODE M42 (remove the comment in configuration_adv.h "#define DIRECT_PIN_CONTROL". You can supposedly force the two pins to be low and see if that would work. PE13 is pin 75, which goes to MS1 PE14 is pin 76, which goes to MS2 (Taken from the variant_MARLIN_STM32H7343VX.h)

So you can type the following GCODEs: M42 P75 T1 M42 P76 T1 M42 P75 S0 M42 P76 S0

The T1 turns it into an output pin and S0 will drive out 0.

This didn't work for me as the EZ2209 doesn't have a connection to MS1/MS2, but you can see if this works on the EZ2208 or the non EZ2209 driver.

[donmahallem]

@TOTA42 I recompiled Marlin with only Drivers specified, TMC_DEBUG and DIRECT_PIN_CONTROL enabled. It doesn't seem to do change anything using the settings with the M42 commands. Still getting the TMC errors

[BrasilWill]

All I have the same issue... but I am not even sure what the ALL LOW message means as my test prints are coming up fine.

Monitoring one right now... Send: N108110 G1 X143.12 Y177.951 E1387.1546188 Recv: ok Send: N108111 G1 X143.001 Y177.991 E1387.15795111 Recv: ok Send: N108112 G1 X142.7 Y177.992 E1387.16596106 Recv: ok Send: N108113 G1 X142.7 Y179.614 E1387.2091297 Recv: ok Send: N108114 G1 X143 Y179.614 E1387.217167 Recv: ok Send: N108115 G1 X143.12 Y179.654 E1387.2204793 Recv: ok Send: N108116 G1 X143.2 Y179.814 E1387.2252398 Recv: ok Send: N108117 G1 X143.2 Y180.336 E1387.2391198 Recv: ok Send: N108118 G1 X143.128 Y180.491 E1387.24366*99

[JoaquinBerrios]

It means the MCU is not able to communicate reliably over UART with those steppers and read all registers as 0. The drivers will still drive the motors as long as they get signals to their step and dir pins, but if you have TMC_DEBUG enabled and you issue an M122 command you will see that the steppers that are having issues will not be properly configured with regard to current, stealthchop, microsteps, etc.

While the motors may work, you may be driving them with too much current, and would not be able enable stealthchop, set microsteps, etc. for the drivers reporting ALL LOW. The most significant thing here is that supplying too much current to the motors will cause them to overheat and potentially loose steps, and in extreme circumstances damage the motors. The added noise from not being able to enable stealthchop is also annoying considering that was a feature that influenced my choosing 2209s.

In my case, the drivers reporting ALL LOW were supplying way too much current to the motors, and did not enable stealthchop. My printer "works" but the motors got really hot, and were loud.

[BrasilWill]

It means the MCU is not able to communicate reliably over UART with those steppers and read all registers as 0. The drivers will still drive the motors as long as they get signals to their step and dir pins, but if you have TMC_DEBUG enabled and you issue an M122 command you will see that the steppers that are having issues will not be properly configured with regard to current, stealthchop, microsteps, etc.

While the motors may work, you may be driving them with too much current, and would not be able enable stealthchop, set microsteps, etc. for the drivers reporting ALL LOW. The most significant thing here is that supplying too much current to the motors will cause them to overheat and potentially loose steps, and in extreme circumstances damage the motors. The added noise from not being able to enable stealthchop is also annoying considering that was a feature that influenced my choosing 2209s.

In my case, the drivers reporting ALL LOW were supplying way too much current to the motors, and did not enable stealthchop. My printer "works" but the motors got really hot, and were loud.

@JoaquinBerrios perfect overview for a newb like me. Thank you so much. Truly appreciate it.

[Caz3mir]

Looking at people from youtube it seems they are using older versions of vscode/pio. Can anyone try and compile from something like this? I have some errors unpacking Arduino_Core_STM32 on these portable versions. https://github.com/Jason2866/Portable_VSC_PlatformIO/releases

[TOTA42]

One of the issues is that the SKR 3 variant calls out platform_packages = framework-arduinoststm32@https://github.com/stm32duino/Arduino_Core_STM32/archive/main.zip in the stm32h7.ini, which seems to grab the head instead of the latest tag and seems there's commits every few days, so that's another variable other than the PlatformIO. I'm concerned that it may be a combination of finding the right PlatformIO version AND framework-arduinoststm32 commit.

[Caz3mir]

I managed to downgrade the Platform.IO core to 6.0.1 and 6.0.0 without any good results. Those old versions from that guy Jason are failing to extract main.zip and after so many failed attempts I hate my life...

[JoaquinBerrios]

I downgraded to older versions of VSC, PIO and Auto Build Marlin, going about a year back, in various combinations and was unable to get a build that would not give me errors. My gut tells me this a problem with serial comms for STM32, but I don't have anything concrete other than a feeling after reading about multiple issues with multiple boards in the past.

It may be worth reporting this on the Marlin github just to give it more visibility, but I didn't want to do that right now since I'm working on getting Klipper up and tuned so I can use the printer. I'll likely do so sometime this weekend when I get things sorted with Klipper and can flash Marlin back on to capture details for the issue and will post a reference here if/when I do so unless someone else files an issue for this first.

[JoaquinBerrios]

TOTA42, you may be on to something there. Let me see what I can do with that this weekend...

I also finally heard back from BTT support yesterday and asked them to have a look at this issue and maybe have one of their software folks join the discussion. If nothing else, it would be great to get a build log of a working build from them so we can compare it to our logs and see if anything jumps out as a potential cause for the errors. Differences in the STM32 or TMCStepper libraries are high on my list of potential causes. The SMT32 more so than TMCStepper since the TMC32 libraries hve had a lot more updates that TMCStepper.

[Pardiman]

I have managed to successfully compile a firmware. I haven't been able to test if everything works, but the M122 is correct and my Z axis seems to have correct torque.

If you look at the build log the problem seems to be in:

- framework-arduinoststm32 @ 0.0.0

When you delete the following line in "..\ini\stm32h7.ini":

platform_packages = framework-arduinoststm32@https://github.com/stm32duino/Arduino_Core_STM32/archive/main.zip

Platformio installed version 2.0.0 in a predefined way, looking in the build log like this:

- framework-arduinoststm32 @ 4.20000.210603 (2.0.0)

Here it already works, but by adding the following to the "stm32h7.ini" file, instead of the previously deleted line, I have managed to install version 2.2.0:

platform_packages = framework-arduinoststm32@>4.20000.210603

Or also:

platform_packages = framework-arduinoststm32@4.20200.220530

Here I have stayed, there is version 2.3.0, which is the one that should be installed with the original code, but I have not managed to install it. Please try one of you to confirm that this is correct or if there is a better way to do it.

[Caz3mir]

I can 100% confirm stm32 2.20 works. All OK on my build. Pardiman , send me your details because you sir, deserve a beer.

[Pardiman]

Thank you, we have all collaborated. The funny thing is that after so many tests, I corrupted the line of code unintentionally and I realized that version 2.0.0 was installed.

[Caz3mir]

I tried everything but that. hahahhaah

[donmahallem]

framework-arduinoststm32 @ 0.0.0

It's probably 0.0.0 because it is pulling an archive and not a tag and can't retrieve it's version.

I will try your findings over the weekend.

Would you mind trying something else too?

platform = ststm32@~14.1.0

Is locked to 14.1.x and 15.4 seems to be available already

15.3 specifies 2.2 explicitly: https://github.com/platformio/platform-ststm32/releases/tag/v15.3.0

[FlyingSamson]

@Pardiman I can also confirm that this fixes the problem for me (SRK3 with 5x TMC2209). Thanks so much for finding this. I guess I can stop digging through the Marlin and TMCStepper sources for an issue that does not exist now :D

[Pardiman]

Donmahallem That I already tried, just edit the version in the file "stm32h7.ini" and leave it like this:

platform = ststm32@>14.1.0

Or also:

platform = ststm32@~15.4.1

There are also updates for "toolchain-gccarmnoneeabi", but I don't know what they add and if it's good to update. I've tried updating and downgrading a lot of things until something has worked.

This is how the updated "stm32h7.ini" file can be:

#
# BigTreeTech SKR V3.0 / V3.0 EZ (STM32H743VIT6 ARM Cortex-M7)
#
[env:STM32H743Vx_btt]
extends                     = stm32_variant
platform                    = ststm32@>14.1.0
platform_packages           = framework-arduinoststm32@4.20200.220530
                            toolchain-gccarmnoneeabi@>1.90201.191206
board                       = marlin_STM32H743Vx
board_build.offset          = 0x20000
board_upload.offset_address = 0x08020000
build_flags                 = ${stm32_variant.build_flags}
                            -DPIN_SERIAL1_RX=PA_10 -DPIN_SERIAL1_TX=PA_9
                            -DPIN_SERIAL3_RX=PD_9 -DPIN_SERIAL3_TX=PD_8
                            -DPIN_SERIAL4_RX=PA_1 -DPIN_SERIAL4_TX=PA_0
                            -DSERIAL_RX_BUFFER_SIZE=1024 -DSERIAL_TX_BUFFER_SIZE=1024
                            -DTIMER_SERVO=TIM5 -DTIMER_TONE=TIM2
                            -DSTEP_TIMER_IRQ_PRIO=0
                            -DD_CACHE_DISABLED
upload_protocol             = cmsis-dap
debug_tool                  = cmsis-dap

And here's the result:

CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/marlin_STM32H743Vx.html
PLATFORM: ST STM32 (15.4.1) > STM32H743VI (1024k RAM. 2048k Flash)
HARDWARE: STM32H743VIT6 400MHz, 1MB RAM, 2MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, jlink, stlink)
PACKAGES:
 - framework-arduinoststm32 @ 4.20200.220530 (2.2.0)
 - framework-cmsis @ 2.50700.210515 (5.7.0)
 - toolchain-gccarmnoneeabi @ 1.100301.220327 (10.3.1)

In the absence of updating framework-arduinoststm32 to version 2.3.0.

By the way, I imagine it is a generic data that does not affect, but the 400MHz, is not 480MHz on the SKR 3 board?

[donmahallem]

@Pardiman yeah, it's 480 but from my limited understanding the MHz shouldn't matter at least in terms of serial/UART communication

[FlyingSamson]

I think one would need to add

board_build.f_cpu = 480000000L

to the

[env:STM32H743Vx_btt]

section. Albeit I'm not sure what this will do really. According to the documentation of this option it does not change the clock on a hardware level.

[FlyingSamson]

Interestingly f_cpu is set to 400000000L in Marlin/buildroot/share/PlatformIO/boards/marlin_STM32H743Vx.json. Which seems weird since in the platformio documentation all STM32H743Vx boards are listed with a frequency of 480MHz.

Maybe somebody from the @bigtreetech team can shed more light onto why it is set to 400MHz then?

[ninjadudexp]

great work, i just compiled a version flash taking a lot longer coming off klipper to marlin. Wonder if im having a seperate issue now.