-
Notifications
You must be signed in to change notification settings - Fork 26
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
Bi-directional communication issue / RP2040 stallts / does not boot #38
Comments
Some additional infos: Running Arduino with latest arduino-pico 3.6.0 version. I also tested to have multiple chips attached to multiple UART interfaces, this does work without issue, it really looks that multiple drivers on one line with different addresses seems to provoke some issue. Another thing I realizied using the example BidrectionalCommunication -> TestCommunication: Not matter the setup, if you're booting the RP2040 with the power supply to the TMC2209 switched off, the example will correctly state
If you then turn on the power, following message appears:
At this point the RP2040 stalls, only a reboot helps to get any communication back. Also the serial terminal in the Arduino software locks up, meaning you cannot even close the window. Only after several tries this will work (if it all) - or only disconnecting the RP2040 will help at all. Thank you :) |
Hi. Just to be clear, do you have the address line on the second driver pulled high to set the proper address when you have two drivers connected to the same UART? |
That is correct. I also could add my driver at addr 0, access it alone,
just use the addr 1 driver alone and this also worked, but as soon as I
have both drivers on the same UART at the same time (one with 0 one with 1)
it does not work anymore.
|
Interesting. Can you test the code I just added to a new branch named serial-end? My code calls begin() on the serial instance twice in a row if the same serial port is used for two drivers. Perhaps that causes a problem with the RP2040. I added end() before calling begin() so maybe that will fix any issue that might occur with calling begin() twice in a row. |
I tried this and this seems to move into the correct direction! 👍🏻 One thing to note, it does not like at all having run the setReplyDelay(REPLY_DELAY); during the loop again, I guess its enough to run it on setup and then it should be ok? Because otherwise the board communication becomes quite unstable. Also, addresses 0 and 1 answer now, I see no stalling board anymore, so this is great - however, I can see that after having the drivers successfully configured for the first time and shutting the drivers 12v off and on again, the board tends to "swing", really needing some time until the board stays configured and not is resetting itself/reconfiguring. Maybe there is still some issue there regarding timing? Or I need to increase/add additional delay between accessing driver 0 and 1 (basically it got its own PCB and both drivers are just some centimeters away with the UART connection running over the PCB by a very short distance). Included is the source code I tested and the serial output, thanks a lot already :)
|
Yes, setReplyDelay(REPLY_DELAY) should be run just once in setup. I will go ahead and merge those changes into the main branch as they seem to help. I am not sure about the power timing issues, if you figure out any more details please let me know! |
Thanks for the confirmation and updating the library. Yes, I will keep an eye open and if I find the issue or get some more details/can pin it down i'll let you know :) |
So I did some additional testing. One problem I could quickly pin down and resolve by shortening the wire run for the UART, which helped a lot. However, I still saw that issue that - at random - some drivers would just "toggle" all the time, e.g. being setup and re-setup all the time. I saw that this issue even got worse when I lowered the communication speed (even with increasing the delay). In the end I picked 250000 BAUD and this seemed to do the trick. Upon a toggle of the driver power, the drivers will be reset and re-setup. They might "toggle" some rounds, but after a short time they will settle and stay setup - I attach my testcode below. I also found another issue that might be a problem with my understanding of the overall process/TMC2209 control: The TMC2209 is connected via DIR, STEP, ENABLE and UART lines to the RP2040. For stepping the motor itself I am using https://github.com/laurb9/StepperDriver - which works very well using the BasicStepperDriver. After I setup the TMC2209 before the BasicStepperDriver like this:
and especially software enabled the TMC2209 via UART, the BasicStepperDriver could just normally enable/disable the driver via the hardware interface (at least it looks like it) and everything works as before I included the TMC2209 for the UART interface. However - the issue I see is that - if I connect the UART interface, it seems that the TMC2209 react vastly different to the steps then when the driver is running standalone/without UART. It looks like its having a completly different power profile, not enough torque and overall is louder and weaker. Is there any way to load the same "defaults" the TMC2209 has as if its not operating in UART mode? Thanks so much! :) Added the test script for the communication issues
|
Yes it does not surprise me that strange things happen when the UART baud rate gets too high or the cables too long. The datasheet says that the maximum baud rate should be fclk/16 so with a 12MHz clock you should be able to use 750k baud, but cables and multiple chips probably lower that maximum rate significantly. Maybe 250k is the max with your particular setup. Yes the default values used by the chip are very different than the values used in UART mode with this library. You can change some of the values used during standalone by setting the configuration pins on the chip. I mostly use the chip in UART mode, though, so I have full control over it. There is a mechanism for saving new values that will get loaded as default during standalone power up, but I have never used it. Look up |
Thanks Peter, Yes, I read about the OTP already, its a bit scary to have to know exactly what you want - however, it should be possible to just test the driver settings beforehand until I am sure that this is all ok. |
Good day,
I setup an RP2040 with 2x TMC2209 v1.3 (Bigtree Tech) drivers exactly to ( https://github.com/janelia-arduino/TMC2209#connecting-multiple-tmc2209-chips / - Bidirectional Communication / Chips needing different settings using one UART ).
I can confirm when I run following script and only setup one of the drivers and run their loop routines, it will work - does not matter which of both chips I choose, its ok. However, as soon as I enable both setups and the loop routines as shown below, the RP2040 will not boot at all. Windows Device Manager will show it to be a unknown, erronous USB device. To recover, I need to unplug, hold BOOTSEL and reflash via UF2 or use the nuke.uf2 to reset the chip.
Do you have an idea what I am doing wrong? Thanks a lot :)
The text was updated successfully, but these errors were encountered: