Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TMC220x UART on a version 1.0 board with some modifications? #35

Open
sverd opened this issue Aug 17, 2020 · 4 comments
Open

TMC220x UART on a version 1.0 board with some modifications? #35

sverd opened this issue Aug 17, 2020 · 4 comments

Comments

@sverd
Copy link

sverd commented Aug 17, 2020

Hi,
I saw that in the v1.1 board the option has been added to use UART with TMC220x chips. This is great, but unfortunately I have a version 1.0 board.
After looking at the schematics it seems that the main difference is the presence of 1k resistors between the CX and the TX pins. It is not completely clear to me what the purpose of these resistors is: they are mentioned in the Watterott documentation, but also without explanation why it is necessary.

Nevertheless I am wondering whether it is possible to obtain the UART behavior of the v1.1x boards by soldering some 1k resistors between some pins at the stm32 side. So for the x driver between pin 76 and 8, for y between pin 72 and 3, for z between pin 97 and 47, for e0 between pin 7 and 58, for e1 between pin 89 and 86 and for e2 between pin 90 and 82.
This will not be the easiest thing to do but does seem feasible. In order to reduce the amount of connection at the stm32 side it might then also be an option to solder between the stm32 tx pin(76,72,47,58,89,90) and the corresponding MS3 pin.

@chrissbarr do you think this is a viable option or were (many) more things changed regarding the UART communications when they were made available for the v1.1x boards?

@sverd sverd changed the title TMC220x UART on a version 1.0 board? TMC220x UART on a version 1.0 board with some modifications? Aug 17, 2020
@chrissbarr
Copy link
Contributor

Hi @sverd,

Generally speaking, each TMC220x driver needs to be connected to two microcontroller pins for serial - one for RX, and one for TX. Both of these signals connect to the same pin of the TMC220x driver, with the 1K resistor required in the TX line (so that damage does not occur if both the MCU and TMC220x drive the line at the same time).

The V1.1 boards add an extra signal to each socket (to work as the TX), along with a resistor between the TX and the serial pin of the stepper driver.

What you have proposed, in terms of connecting 1K resistors between the extra pins and the existing RX/CS pins, is feasible and should work if done correctly. I would advise against directly soldering to the pins of the MCU (I know I'd have trouble with it), and would suggest instead using some of the spare pins available on the expansion headers (say EXP3, if otherwise unused).

This could look something like this:

tmc220x-wiring

Those are just suggestions for the EXP3 pins to use, but they should be acceptable. Whichever pins are used, you would need to define the pins in Marlin - an example is in the current pins.h file, as below:

    #define X_SERIAL_TX_PIN                 PA14
    #define X_SERIAL_RX_PIN                 PC14

    #define Y_SERIAL_TX_PIN                 PA13
    #define Y_SERIAL_RX_PIN                 PE4

    #define Z_SERIAL_TX_PIN                 PB10
    #define Z_SERIAL_RX_PIN                 PE0

    #define E0_SERIAL_TX_PIN                PD11
    #define E0_SERIAL_RX_PIN                PC13

    #define E1_SERIAL_TX_PIN                PB3
    #define E1_SERIAL_RX_PIN                PD5

    #define E2_SERIAL_TX_PIN                PB4
    #define E2_SERIAL_RX_PIN                PD1

You would be able to keep the RX_PIN values, but would need to change the TX_PINs to match the ones you connect each driver to. You could either change them in the V1.1 pin definitions, and then use those files, or just add the above definitions (with pins changed as appropriate) to your Configuration.h file.

For reference on pin numbering in the EXP3 header, refer to this image:

image

Some suppliers ship the TMC220x drivers with pins that extend above the board, like this:

image

If possible, sourcing something like that would likely make the setup easier (you could make up 6 x jumper cables with the 1k resistor in the middle, and just plug one end of each into the EXP3 header, and the other into the top of a driver).

Otherwise, if you wanted a more permanent solution, you could solder wire + resistors onto the back of the board.

So, it is definitely feasible to do what you're after - there is a bit of wiring/soldering involved, but if you are happy to do that there's no reason it wouldn't work. I'm happy to offer more info if you'd like, just let me know.

@sverd
Copy link
Author

sverd commented Aug 30, 2020

Hi @chrissbarr ,

Thanks for the extensive response, it is VERY helpful!
I think you have a good point that it is better to avoid soldering on the pins of the microcontroller directly. Hence I started my update following your suggestions for the UART. I did not yet finish it because of limited available time but thought it would be good to share my progress and other small details that might be helpful for others who want to follow his approach.

I had already bought some TMC2208 modules, unnamed both most likely BigTreeTech TMC2208 V2.0 clones:
Bovenkant-2208
Onderkant-2208

This turned out to be not really optimal: the PDN pin is not at the expected position and the same goes for the motor connections. Hence I first modified the module in the following places:
TMC2208-v20 aanpassingen
1: connect the NC and the PDN pin and make the NC pin stick out on top of the board
2: make a solder bridge to enable UART
This resulted in something similar to the option you suggested:
CorrectPinUp

Remains the problem of the different ordering of the motor outputs. As these basically "hard-coded" on both the RUMBA32 board and the module, the easiest way probably is to neglect the marking printed on the board and interpret the printed "1B 1A 2A 2B" as "2A 1A 1B 2B" (effectively 1B becomes 2A and vice versa).

As already mentioned I did not test everything yet, but I will report further progress here as well!

@sverd
Copy link
Author

sverd commented Sep 5, 2020

Hi @chrissbarr ,
Thanks a lot for the descriptive answer!
I think I managed to come at least closer to my goal. However, things are not working yet.
When using the the modified stepper drivers with the modified jumper cables and changing the X_SERIAL_TX_PIN values Marlin seems to communicate over UART with the TMC2208's. At least that is what is being reported when running M122 in Pronterface.
When trying to move along an axis, either the motor reacts shortly and than stops responding or nothing happens at all (this happens only at the Y-motor). Also when the TX-line was removed (leading to problems in the UART communication, which in turn makes the stepper driver operate in standalone mode) the Y-motor did not react at all. This surprised me quite a bit and I used a logical analyzer on the STEP and DIR pins after the initialization was finished. It turned at out that at least for the X-stepper pulses were present on the STEP line (expected behavior), but for the Y-stepper there were no pulses at all (which may explain why nothing happens at the Y-motor)

All this led me to believe that maybe it is just a firmware thing and something is wrong with my Marlin configuration. I could however not even get a complete "standard" config with minimal enabled options to work....
At this point I am kind of stuck.. Any suggestion to get the steppers working is very welcome. Is there maybe somewhere a "known to work" RUMBA32 configurationthat uses UART for the stepper drivers? That could be a good starting point to build up my system.

@sverd
Copy link
Author

sverd commented Oct 13, 2020

Hi @chrissbarr,
It took a long time but just to complete this topic: I did manage to get things working but not in a completely straightforward way. Following your advice I got all motors controlled through UART. The Y-motor did however have the issue that it would not work when connected to the Y-connection. For some reason no stepping pulses were sent to the appropriate pin in the Y-connection. Probably there is reason for that, but I was not able to figure it out.

Re-routing the control of the Y-motor to the E2 port and connecting the motor there solved that problem and enabled me to finally get a working system. I will not be able to connect an extra extruder, but at this moment that is no problem.
However, if there is a simple solution for this, please let me know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants