Klipper: Support TMC2208 configuration at runtime via UART

[Artefact2]

Klipper can already configure TMC2130 drivers at run-time using SPI. It would be nice if the same could be done for TMC2208 drivers, which can be configured at run-time too using UART.

The featureset is mostly the same: control driver current, interpolation, microstepping, stealthChop, etc.

Regards

[ghost]

I am also interested about TM22xx support. Have one RAMPS 1.4 board modified for Arduino Duo that has for X and Y - TMC2208 drivers. Probably first has to be decided how the communication with the step-motor drivers would be done.

1) Directly from UART/s on the Klippy host server.
2) From UART/s on the MCU.

According to TM2208 datasheet the communication can be multiplexed:

But also in some cases when TMC22xx is used just for 2 axes, such analog switching seems unnecessary, since separated UARTs can be used for communication.

[Artem-B]

Alternatively, you can implement soft-uart operating via single bidirectional GPIO pin.
I have a DMA-driven implemented for LPC176x here:
https://github.com/Artem-B/TMC2208Stepper/blob/soft-uart/src/source/TMC2208Stepper_uart.cpp

[ghost]

@Artem-B, This looks good, but not so sure how fast would work on 8-bit MCUs without DMA, like AVR etc.
I tried today to configure some TMC2208 V2.0 modules by using CONFIGURATOR FOR TMC2208 (ScriptCommunicator + TMC2208.scez ) (http://learn.watterott.com/silentstepstick/configurator/). Was not able to establish communication.
Based on the info especially from MarlinFirmware other people experienced similar issues, some were solved by using new software, other seem not be solved. The pictures of those I tried are bellow, any issues with this model ?

[Artem-B]

Searching on GitHub brings up number of implementations for AVR. E.g. https://github.com/blalor/avr-softuart

Soft-uart is fairly simple to implement and an implementation sufficient for TMC22XX would be even simpler as it only needs to handle half-duplex, so receive can be done synchronously. You can actually get by with transmit-only if all you care is configuring settings. All you need is OK-ish timing of pin toggling and you can use pretty low baud rate for one-shot init of the drivers. With DMA I can go as high as ~1Mbps, but that's an overkill.

It's hard to tell what's working or not on particular stick variant clone. For what it's worth, the sticks I've been using are from digikey (TMC2130, TMC2208) and Panucatt(TMC2224) and they all worked as expected.

[KevinOConnor]

Looking closer at the TMC spec, I suspect it would be possible to configure and query the drivers via a bit-banging implementation using Klipper's "software timers". Such an implementation should work across all MCUs without requiring any particular MCU specific code. It should also work with all common GPIO pins (no special irq or dma support would be needed).

@Artem-B - if you use the same MCU pin for both rx and tx, do you have to do anything special with pullups, pulldowns, or resistors?

The Panucatt drivers look pretty sane (no funky soldering). I may pick up a couple.

-Kevin

[Artem-B]

+1 Yup. Bitbanging may work at reasonably low baud rate.

Datasheet says "The UART line must be logic high during idle state.".
When MCU is done with thansmit, it needs to switch GPIO to input. That's the tricky part as the PDN_UART has a pulldown and will pull the signal to GND until TMC starts actively driving the pin.
Ideally you do want a pullup which is strong enough to drive the line up during this period. That's why the TMC datasheet has a resistor between TX and RX pins -- when TX is idle, it drives the signal high via that resistor until TMC starts driving it. The "idle is high" also means that we are guaranteed to miss the first bit of reply. Fortunately, all replies start with 0b10100000, so it's easy enough to find the start of the reply.

One caveat of Panucatt's sticks is that they have 0.045Ohm current sense resistors. If I read the datasheet correctly, that's borderline too low. It makes VREF voltage-to-current calculation convenient, but it's likely to affect the current measurement. Most of the other sticks use 0.11 Ohm, which is within the range recommended by Trinamic. The sticks worked OK on my board, but I would not be surprised to see issues on lower quality boards or with noisy power supplies.

[Artem-B]

After another look at the datasheet, it appears that pull-up is not needed if we're only writing to the TMC driver. Fig 4.1 in chapter "4.3 UART Signals" in TMC22xx manual shows tx-only configuration with TX pin directly connected to PDN_UART on the TMC chip.

That implies that the pullup is only needed to make a standard UART RX logic work as it would have trouble handling the idle state otherwise. With soft-uart and known start-of-reply pattern that should not matter much as we can always adapt to potential noise at the beginning of the reply.

All we need is ability to toggle the pins and read the values at reasonably stable fixed intervals. We should be able to deal with fair amount of jitter if we capture RX at a rate N times higher than we used for TX and then use transitions in captured values to figure out where the next sample should be. That's what I do in my DMA-driven UART (though it turns out it's not really needed there. DMA produces really nice and low-jitter (on UART timing scale) signal transitions/captures).

[KevinOConnor]

That implies that the pullup is only needed to make a standard UART RX logic work as it would have trouble handling the idle state otherwise. With soft-uart and known start-of-reply pattern that should not matter much as we can always adapt to potential noise at the beginning of the reply.

Interesting. Looking at the watterott stepstick schematics, it appears the board adds a pull-down on pdn_uart - so it's unclear what an on-chip pull-up would accomplish. But, you're right in that it shouldn't matter for a simple bit-banging interface - as it should be possible to parse with a pull-down as easily as with a pull-up.

We should be able to deal with fair amount of jitter if we capture RX at a rate N times higher than we used for TX and then use transitions in captured values to figure out where the next sample should be.

I was actually thinking that we could take a very precise measurement of the baud rate and then avoid oversampling on rx. That coarse granularity might result in sporadic read errors, but the host code could detect a read error and just re-request the read.

-Kevin

[Artem-B]

That coarse granularity might result in sporadic read errors, but the host code could detect a read error and just re-request the read.

Each reply has a checksum, so error detection should be pretty reliable. As long as typical timings are stable enough to give us a good result most of the time, this should be fine.

My guess is that on idle system that should work fine. Can the 'stable enough' part be achieved during a print? Let's say, we're running at ~10Kbaud, that's 100us/bit and for 64-bit word transfer w/o oversampling, we'll need the sampling period to be 100us +/- 1.5us, otherwise, we'll miss at least one bit.

[KevinOConnor]

My guess is that on idle system that should work fine. Can the 'stable enough' part be achieved during a print? Let's say, we're running at ~10Kbaud, that's 100us/bit and for 64-bit word transfer w/o oversampling, we'll need the sampling period to be 100us +/- 1.5us, otherwise, we'll miss at least one bit.

Well, I don't think we'll ever have to program the driver when printing.

That said, I think we can obtain the sampling rate (ie, baud) with an accuracy measured in nano-seconds. The trick is that the tmc2208 uses a baud calculated from the time between the first bit toggle and the fifth bit toggle in the initial sequence sync nibble. It's difficult to schedule software timers with nano-second precision, but it's trivial to determine when the software timer is actually run with great precision. So, we can measure the time between first and fifth bit toggle and use that value when scheduling future writes and reads. Those subsequent read/write events may drift a few us, but the drift should not accumulate. Only testing will tell, of course.

Amazon had some fystec 2208s reasonably priced and with same day delivery, so I purchased some. I guess I'll find out if I'm right or wrong. :-)

-Kevin

[Artem-B]

If toggling/sampling is driven by the timer, we should be OK. For RX we'll need to shift phase to sample in the middle of the RX bit. It may be hard to control that directly, unless we assume that TMC responds in phase with the tx. The datashees seems to suggest that it should -- response is sent SENDDELAY bit times after the end of request. If it's not reliable enough, we may need to oversample after all. 3x would make it easy to get the right rx value by simple majority voting, regardless of sampling timer alignment relative to RX bit start.

As for the sticks, digikey.com has waterott's 2208 sticks. https://www.digikey.com/product-detail/en/trinamic-motion-control-gmbh/TMC2208-SILENTSTEPSTICK/1460-1201-ND/6873626
Shipping is pretty fast. I typically get stuff from them within 3 days with regular USPS shipping.

Let me know when you have something to try. I can give it a spin on my printer (uses lpc1769 smoothieboard variant). I've been itching to try klipper, and support for 2208 drivers is a bit of a showstopper.

[Artem-B]

Well, I don't think we'll ever have to program the driver when printing.

During initial printer tuning, I've found it pretty convenient to be able to monitor driver status (specifically status bits that indicate over-temperature pre-warning) and adjust current limit during the print. If we could make it work during the print, that would have some value. Granted, it's closer to the "bells and whistles" end of the feature wishlist.

[KevinOConnor]

For RX we'll need to shift phase to sample in the middle of the RX bit. It may be hard to control that directly, unless we assume that TMC responds in phase with the tx.

I ran a bunch of tests and it looks like the TMC responds predictably, and interestingly it seems it implements an rx phase shift on its side. So, we can just do rx samples by continuing with the same tx interval.

FYI, the rx and tx looks very stable in my tests. I haven't seen a corrupted message yet. Oddly, though, the driver is very noisy - significantly louder than the a4498 I was previously using. I suspect I need to tune the parameters.

-Kevin

[KevinOConnor]

I've put up a test branch for those wishing to use the tmc2208 (and/or tmc2224) driver's uart configuration feature. Only a single mcu pin is needed to control the driver - on my fysetc driver I had to bridge the MS3/PDN_UART solder jumper, and then I wired the MS3 pin to a free port on my MCU. It's also possible to use separate rx/tx pins (but that's not particularly useful).

The code is pretty raw. If you run tests, let me know what the results are (success or failure). See the config/example-extras.cfg file on the test branch for instructions on configuring the driver. (The configuration is nearly identical to the tmc2130 configuration.)

cd ~/klipper ; git fetch ; git checkout origin/work-tmc2208-20180817 ; sudo service klipper stop ; make flash ; sudo service klipper start

[Artefact2]

Thank you, I will try it tomorrow. I have mine wired with the standard Y-cable and 1k resistor so I'll try using two pins.

[Artefact2]

I have tried the work-tmc2208-20180817 branch with mixed success. Reading registers seems to work. I can also hear that spreadCycle is used as configured. However, I am having trouble with regards to the microstepping setting; no matter what I put in the configuration, the driver sticks to 16 (I can see it in the registers and while moving the axis.)

Here's an example:
~
[tmc2208 stepper_x]
uart_pin: ar64
tx_pin: ar40
microsteps: 64
run_current: 0.6
~

~
Send: DUMP_TMC STEPPER=stepper_x
Recv: // GCONF: 00000104
Recv: // GSTAT: 00000001
Recv: // IFCNT: 00000006
Recv: // OTP_READ: 00000010
Recv: // IOIN: 2000014d
Recv: // FACTORY_CONF: 00000010
Recv: // TSTEP: 000fffff
Recv: // MSCNT: 00000008
Recv: // MSCURACT: 00f7000c
Recv: // CHOPCONF: 14028384
Recv: // DRV_STATUS: 80130000
Recv: // PWMCONF: 00050480
Recv: // PWM_SCALE: 00000016
Recv: // PWM_AUTO: 00040024
Recv: ok
~

Checking the miscrostepping setting in the CHOPCONF register: (14028384 >> 24) & 7 gives 4, which means 16 microsteps according to the datasheet.

[KevinOConnor]

However, I am having trouble with regards to the microstepping setting; no matter what I put in the configuration, the driver sticks to 16

Apparently the tmc2208 has a flag that must be set in order to set MSTEP - should be fixed now.

cd ~/klipper ; git fetch ; git checkout origin/work-tmc2208-20180817 ; sudo service klipper restart

-Kevin

[Artefact2]

Yes, I can confirm it working now. Thank you very much for your work!

[ghost]

I also tried work-tmc2208-20180817 branch, got:

ERROR:root:Config error
Traceback (most recent call last):
File "./klipper/klippy/klippy.py", line 252, in _connect
cb('ready')
File "/home/deb/klipper/klippy/extras/tmc2208.py", line 192, in printer_state
self.set_register(reg_name, val)
File "/home/deb/klipper/klippy/extras/tmc2208.py", line 209, in set_register
self.ifcnt = ifcnt = self.get_register("IFCNT")
File "/home/deb/klipper/klippy/extras/tmc2208.py", line 203, in get_register
"Unable to read tmc2208 '%s' register %s" % (self.name, reg_name))
Error: Unable to read tmc2208 'stepper_x' register IFCNT

And Klippy stopped there. Shouldn't Klippy include some error handling ?

I tested two Bigtreetech TMC2208 V2.0 boards, both didn't work. At least it was confirmed that some TMC2208 boards might have hardware problems.

[KevinOConnor]

@Artefact2 - great, thanks. Would you be able to run a test for me? Does it still work if you comment out the tx_pin line and just use the uart_pin line (leave the hardware itself unmodified)? Does it still work if you set uart_pin=ar40 and do not specify a tx_pin (leave the hardware itself unmodified)?

-Kevin

[KevinOConnor]

@EmbDevices - did you modify the tmc2208 board to enable the uart? (Most of the tmc2208 stepsticks are based on the watterott design and require bridging a solder jumper.) How did you wire the tmc2208 to the host mcu? The "read tmc2208" error is raised only after multiple attempts to access the driver fail.

Finally, if you think this is a software issue please attach the full klipper log file to this issue - see:
https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

[ghost]

@KevinOConnor, Yes, the TMC2208 boards were modified to enable the UART as it is shown with a red line on the first picture above. The TMC2208 was wired with singe wire to the MCU, tried two pins on Arduino Due board. Do not think that there is need to submit software issue since this looks like a hardware problem. The boards work only in legacy mode. There are other comments on Internet with same issue that state they were unable to solve it. People should be careful what models and where they purchase such boards.

[Artefact2]

@KevinOConnor I've commented out tx_pin from the configuration, and it seemed to works OK. Settings get applied, DUMP_TMC returns sensible data.

[Artem-B]

I've tried it on my printer and can confirm that it works on smoothieboard + waterott's TMC2208 sticks.
I didn't print anything yet, but I've tested basic functionality. Register dump shows sensible values and motors move at expected speed.

[KevinOConnor]

FYI, I committed this series to the master branch (commit ca7a80a9).

@grigorig and @FHeilmann - FYI, I made some minor changes to the sam4e8e and stm32f103 gpio code as part of this effort.

-Kevin

[FHeilmann]

@KevinOConnor thanks for the heads up, I'll check the changes once I'm back from vacation.

[FHeilmann]

@KevinOConnor I checked the latest master and everything seems to work as expected with the new gpio changes

[GriffinPaquette]

@Artem-B I saw that you mentioned that you used soft-UART with the Smoothieboard and the TMC2208's. What pins did you try with? I am trying to do the same using the ethernet pins (Port-1) but I have been warned that ports 0 and 2 on the board might be the only ones that offered pin change interrupts.

[ghost]

@ghost

did you found a solution for bigtreetech tmc2208 and uart?

[Artem-B]

@Artem-B I saw that you mentioned that you used soft-UART with the Smoothieboard and the TMC2208's. What pins did you try with? I am trying to do the same using the ethernet pins (Port-1) but I have been warned that ports 0 and 2 on the board might be the only ones that offered pin change interrupts.

I do use ethernet port pins (P1.{0,8,10,16}) to drive four TMC2208.

The soft-UART that I mentioned used DMA so it didn't need pin-change interrupts for timing.

[bobhuang1]

Do NOT buy TMC2208 drivers with the main chip on top! They do not support UART mode by design. BIGTREETECH V2.0 is just one of them! Soldering the jumper pads does nothing. They can only be used as standalone mode. Do NOT buy if you intend of use UART.

[vladT0]

Hi All !
For the ppl, who are using TMC2208 Ver. 2.0 ( Layout from the post Aug 18, 2018 ) and SGEN_L.
I had the same error : Error: Unable to read tmc2208 'stepper_x' register IFCNT
Solution is presented on the pic.

You need another one bridge, between NC and PDN, because motherboard layout expects UART signal on NC pin, but UART is connected to the PDN only on the stepsticks board.
Regards,
Vlad.