Only one of four TMC2209s is "setup", but all communicating

[nhansendev]

Following the example setup for multiple drivers on one UART line with bidirectional communication, I attached four drivers to a Raspberry Pi Pico on UART2 (Pins 8 and 9).

Like so, but with four drivers and unique addresses set for each (VCCIO = 3V3):

However, I've found that at best I get just one driver to be "setup and communicating" (always address 0), while the rest only appear as "communicating, not setup". I can individually enable/disable them via software and run them with step/dir, but only the first responds to more advanced UART config, velocity control, etc.

I've attached my test script which sets-up the drivers, checks the connections, and iterates through each driver, enabling it and running it forwards/backwards, then disabling it again (triggered via pushbutton).
TMC2209_PiPico.zip

I've tried adjusting the reply delay, adding pauses between setup calls, different baud rates, and power cycling the MCU and driver boards, but there were no improvements.

What can I look at next to determine why only one is fully setup?

[nhansendev]

After doing some testing I can report the following:

• Each of the four drivers has non-zero values on IFCNT
• Only the first responds with non-default values when reading GCONF
• Each responds with correct values for IOIN (MS1, MS2, ENN, etc)

So, somehow there are successful writes and reads on each driver, but the global configuration is only being properly transferred to the first driver. Is there another way to test this?

[peterpolidoro]

Have you tried looking at the serial signals on a scope? I do not have a hardware setup to test this situation myself. There may be bugs in this library that prevent this from working properly or perhaps there are electrical issues with wiring it up in this way. Does it work with only two drivers connected? If you do not have any other serial ports available, then you may want to consider connecting a multiplexer like the MUX507 if you still have some digital IO pins available on your microcontroller instead.

I used a serial multiplexer with a Raspberry Pi Pico on this project:

https://github.com/janelia-kicad/cluster-pcb/tree/uart

[nhansendev]

Have you tried looking at the serial signals on a scope?

Slight difference between TX and RX (1k resistor), but otherwise clean enough I think (same appearance when measured adjacent to the pico and the furthest TMC driver):

Attached PulseView file showing setup transmissions per cheap logic analyzer:
setup_sample.zip

Manually transcribed TX->RX for reading memory addresses:
TX -> RX -> Label

05 00 02 8F -> 05 FF 02 00 00 00 15 1D -> Transmission Counter
05 00 06 6F -> 05 FF 06 21 00 00 40 4F -> IOIN
05 00 00 48 -> 05 FF 00 00 00 01 C0 3B -> GCONF

05 01 02 39 -> 05 FF 02 00 00 00 10 74
05 01 06 D9 -> 05 FF 06 21 00 00 44 AF
05 01 00 FE -> 05 FF 00 00 00 01 01 B8

05 02 02 D4 -> 05 FF 02 00 00 00 01 C5
05 02 06 34 -> 05 FF 06 21 00 00 48 3F
05 02 00 13 -> 05 FF 00 00 00 01 01 B8

05 03 02 62 -> 05 FF 02 00 00 00 28 20
05 03 06 82 -> 05 FF 06 21 00 00 4C DF
05 03 00 A5 -> 05 FF 00 00 00 01 01 B8

[vijayk13]

I ran into a similar problem configuring the four TMC2209 drivers on the RP2040-based BIGTREETECH SKR Pico V1.0 board.
The board has the drivers pre wired on the UART2 line (pins 8 and 9) from the RP2040.

After experimenting with a few ideas, I have what appears to be a working setup - would appreciate others giving it a try and reporting back on whether it fixes their problems as well.

The attached zip file (tmc2209-multi-uart.zip) contains a .zip library (my modified version of v10.1.0 of Peter's library), and a small test program.

The test program is hopefully clear enough for others to modify it for their setup. Please ping me if you need any clarifications.

Implementation notes:

To modify the library, I changed the "private" members of the TMC2209 class to "protected", and declared the "read(...)" and "write(...)" member functions to be virtual, so they could be overridden. All of the new code is associated with a derived class TMC2209_MB (for multi, bidirectional), and implements the following functionality:

• Splits the initial "setup" into three stages: (1) stage1 writes the REPLY DELAY register first to ensure clean bus transactions for future operations; (2) stage2 writes the GCONF register to indicate UART-based usage; and (3) stage3 handles the remainder of the initialization.
• In stage1, since the TMC2209 drivers come up in a state where the reply delay is inappropriate for a multi-driver setup, I am using write-retries as the mechanism to increase the probability of the write taking effect. This functionality is contained in the "safeWriteWithRetries" member method.
• In stage2, assuming stage1 has successfully completed (across all drivers on the UART line), we can now use the recommended IFCNT register read mechanism to ensure that the write has taken effect. I ran into some problems using the default "read" method, so ended up writing my own version - "safeRead", which is used by the "safeWrite" method. All three methods include a fair amount of error-checking code and log any unexpected behavior both on the MCU Serial Buffer side and the reply values seen from the drivers.
• In stage3, assuming the REPLY DELAY and GCONF registers have been setup properly, I complete the remainder of the initialization steps ... using overloaded versions of the "read" and "write" methods, which now map to their safe/error-checking variants.

Given the way I ended up evolving the implementation, it is likely more paranoid than it needs to be ... and very likely, only the separation of stage1 from the remainder is perhaps the most impactful change.

[nhansendev]

After experimenting with a few ideas, I have what appears to be a working setup - would appreciate others giving it a try and reporting back on whether it fixes their problems as well.

I've tested it on my setup and it seems to be working perfectly. Thank you for sharing this!

[nhansendev]

I wonder if this is at all related to why I'm having issues with Klipper communicating with the same drivers. It fails to read multiple registers like IFCNT, so maybe they have a similar issue with their protocol. I've seen various mentions of people having such issues, but no real "fix".

[vijayk13]

I've tested it on my setup and it seems to be working perfectly. Thank you for sharing this!

Good to hear!
Can't comment about the Klipper issues, but the multi-driver setup does seem to be fairly sensitive to how the UART bus transactions are managed.

Will defer to @peterpolidoro on what next steps make sense, and whether/how to bring in the (appropriate subset of the) proposed fixes into the TMC2209 library.

[peterpolidoro]

Sounds great! I will take a look at the code and make these changes to the library and release a new version. Thank you!