-
Notifications
You must be signed in to change notification settings - Fork 90
Getting TMC2209 working on SKR PRO #337
Comments
Try with this: |
I have hardware UART mode working for my Nucleo-64 BOB so I knew that it was likely the low level driver code that was at fault. So I wired up my board with only one driver and checked signalling with my scope. Comparing hardware UART with the one generated by this code I saw that the initial state was incorrect, the UART line has to be driven high at startup or driver communication fails.
I did not know about this so I moved the handler to the board code, will do so for the SKR2 as well. This comment was helpful for sorting that out. |
I have now committet an update with the final modifications, It will be helpful if you can test this and report back. |
Seems to be working. I haven't yet checked if the steppers are working fine, but I can confirm that they are being read without any issues, same as before. |
This is due to you choosing a different name for the project than the suggested one when importing. I will commit a fix for this later.
Some has mentioned that a 25 MHz crystal has to be configured or USB will not work. I do not have a board to check with so cannot tell what is correct. Or perhaps there are two versions floating around? Does USB comms work for you when compiling for a 8 MHZ crystal? |
Do you happen to have a link for this? I have checked the schematic for the SKR PRO v1.2 aswell and that also indicates the crystal to be 8MHz. I would highly doubt that any atleast semi-reputable manufacturer (even a far east one) would have a significant change like the main clock crystal frequency changing be undocumented. That would break tons of code. If the HSE value doesn't match the crystal frequency then plenty of other timing critical things should break, including UART baudrate (assuming auto-baudrate isn't used), not just USB. And yes, USB works with HSE set to 8MHz. Haven't tested if it hangs or the computer just doesn't recognize the device (due to heavy baudrate mismatch on the USB data lines), but I can confirm that USB does not work with HSE set to 25MHz. Regarding the project name: |
Here is one - in my experience when the USB clock is not correct the port will not enumerate. Confusing...
Ok, then it has the name you gave the project when initially importing it, or it lives in a differently named folder. If not GRBL Driver STM32F401 many files will not be found. There are folder specifications in the .cproject file that has GRBL Driver STM32F401 as part of the path, I have changed those to a variable reference instead. See this issue for a similar problem. Try replacing the .cproject file with this: |
I quickly read through the topic: the person also has TMC 2209 defined. As stated earlier, if the interrupt handler for TIM7 is not defined, the board hangs, so USB ends up not being able to enumerate. Since the author doesn't seem to have the board running yet, I think that this is at least a part of the problem. Anyway, the crystal value is clearly stated on the crystal itself, please have people just read the value off the crystal itself if there is confusion, that should clear it up.
What I believe happens here is that pull-ups get enabled on the MCU end, so the host tries to enumerate a newly detected device, but since the clocks are mismatched therefore the transfered data is a mess and always fails CRC and gets discarded, after 5 or 10 seconds (can't remember) windows just gives up. So it makes sense. This also happens if the device stops responding before enumeration finishes (the situation described in the previous paragraph). All in all, so far this whole crystal situation seems dubious at best. I will try the C project in the evening if I remember to. |
This should be fixed in the latest build. The main problem was to to get the the binary up and running via the bootloader. I guess it is now.
This is not always possible since many are not marked at all or with cryptic letters. |
Hi @Creepop, glad to read that thread and to see your more skilled than me on that ! My board is a SKR Pro 1.2. One step further for my next tests !
I tried to understand but i cannot see what you meant saying "if the interrupt handler for TIM7 is not defined." |
This should be fixed in the latest build. First step for you is to get communication up and running, disable Trinamic drivers until then. |
It's alive !
Here are the flags used with a fresh clone of repository:
EDIT: |
See the plugin readme for settings and M-commands provided. Start with enabling one motor with |
Thanks. M122 returns It's very cold in my worshop where my CNC is, so for testing purpose i do my test at home with only one motor connected on X and anything else(no limit switch connected). |
Yes, could be that the reset pin is read as asserted if not connected to ground. Try |
M122 doesn't report expecting infos, but if i try a movement on X the motor moves ! Edit: I precise i did replaced Src/btt_skr_1.1.c with the one you shared 4 days ago. |
Pull the latest version from the repository again, it should be working. Just make sure to use 8MHz as the clock frequency (possibly comment out the part where doing so throws an error). |
terjeio: Regarding the cproject file: Thanks, it did the trick. Git automatically created the folder with the name of the repository (STM32F4xx), I'm guessing that was the issue. With the new cproject file, that is no longer a problem. I always pull projects directly into the workspace to be able to track any changes I make if necessary. Is there an issue with this workflow?
The topic mentioned has the last comments 4 days ago so the author would have used the unfixed version. Therefore anything he did would result in crashed firmware as long as TMC2209 was enabled. olijouve: First thing to check is whether you have power going to the stepper drivers (the motor power rail). I just build a totally unchanged code directly from the repository (only commenting this line from btt_skr_pro_v1_1_map.h): |
The setup i've followed on my board is entirely describe here(with pictures): My setup use Dual End Stops (with EXTRUDERS 0 and 1 ), so i do not use Sensorless homing and i bended the corresponding drivers pin as describe. I guess Marlin(v1engineering preconfigured release) is able to talk with drivers as i had absolutely nothing to configure(2209 UART current...) and every thing moves nicely. Does a correctly moving motor means that the firmware can communicate correctly with the drivers ? I only use the SD card bootloader and thanks to @terjeio flashed firmware now loads ok. |
@Creepop, would you mind to share a picture of how you connected everything on your board ? |
I flashed back to Marlin to see what Marlin M122 is returning:
M122 doc doesn't say much on output but at least i guess this output means that communication with drivers is ok. So i have just built a fresh clone of grabHAL STM32F4xx, comment the #error for 25Mhz and flash the board again but i still got that communicartion issue with stepper drivers:
Could it be a different pinout between SKR pro 1.1 and 1.2 ? I will try to activate M43 pin debug command in Marlin to see if i can get a pin report. |
Not sure if it could be helpfull:
Seeing at Marlin sources, the pinout for 1.1 and 1.2 are the same, |
@olijouve What is your I have made a small blunder with |
@terjeio, yes $338=1 and $14=7 still have same error after reboot: $338 |
The UART jumpers are set properly in the images shown, the only difference is that I'm powering the board from USB, not the input power rail (don't even have that connected right now). Just 24V on the motor input and USB cable. Here is the firmware file I used (regenerated it for the bootloader, hopefully that doesn't affect anything): If this doesn't work, then you can try to change the UART pin numbers. If you look at the schematic, you will find that all UART pins are connected to the MCU through a 1k resistor as well as directly, you can try the direct path (grblHAL uses the pin number that are connected through the 1k resistors by default). I run the direct path on klipper and that is also working normally. Not quite sure what else could be different. I have a v1.2 of the board on hand as well, but it is on a working printer that I don't wish to mess around with unless necessary. |
@Creepop, I just reconnected my board just like yours, removed Power VCC to USB(with jumper),remove the 2 jumpers between Z and E0, also 24V on motors and i tried your firmware but changed nothing on M122 / driver communication. I have compared schematics of v1.1 and v1.2 but i can't see any difference on drivers pinout. EDIT : I also tried to unbend the sensorless homing pin |
The only changes between V1.1 and V1.2 I was able to spot in the schematic (entierly possible that I didn't look hard enough) is the introduction of D23 in V1.2 so I highly doubt that it has anything to do with the board revision. Sensorless homing should also have nothing to with this. |
Yes i did flashed you firmware but same result. I'll try to connect the board to my cnc this week end, maybe more chances with more motors connected and limit switchs... |
@Creepop, you're a freaking genious ! You were right !! I changed STM32F4xx/Inc/btt_skr_pro_v1_1_map.h
And now, after reconfiguring $338 and reseting the driver i get TRINAMIC report !!
So I guess we will need a dedicated map file for v1.2. Many thanks to both of you for your time, patience... and skills ! |
Good catch!
Ganging/auto squaring is defined in my_machine.h, pins are defined for motors M3_xx - M5_xx in the map file. Motors are allocated to axis and function automagically by a bit of preprocessor code. |
If this is the case, @terjeio, I don't see a good reason against setting the direct path in the default pin map, both variants work just fine on the V1.1 board. Good to know that it is working for you, olijouve. |
I have just commited an update with direct patch in the pin map and SKR 1.2 added as a synomym for SKR 1.1 (they use the same map file for now). Note that I have added separate Startup folders for F407 and F446, I do not know how that will affect PIO builds - perhaps those not needed has to be deleted to avoid duplicate symbols? In Eclipse I can configure which folder to use for which build, but I have not found compiler (or assembler flags as the startup file is assembler code) controlling it. |
Seems to do the right thing automatically. Is building the startup file for the selected processor out of it's own CMSIS framework folder.. The only one that doesn't build out of the box is the skr pro 1.1 - failing with "This board has STM32F407 processor with a 8MHz crystal, select a corresponding build!". Was the consensus that it should be changed to 8MHz in platformio.ini? |
@dresco, yes crystal is definitely oscillating at 8Mhz. Lines 24 to 26 in STM32F4xx/Inc/btt_skr_pro_v1_1_map.h sould be changed to:
|
I was going to propose just changing the platformio.ini entry for the SKR 1.1;
|
It has already been changed in the latest commit.
I have not updated this, are there other changes pending as well? |
I think just this?
|
For SKR PRO v1.2 i had to add -D HAS_BOOTLOADER in place of -D VECT_TAB_OFFSET=0x8000 but maybe it has same effect. Here are my build flags that work well for sdcard bootloader and usb serial communication: |
Hello everybody.
I have a SKR PRO board that I wanted to use for a small CNC router project. I've been trying to get the trinamic TMC2209 drivers working for the past few days to no avail. The first thing to fix is the if statement in the interrupt file in the software uart timer interrupt (the handler is not included for SKR PRO, just SKR 2). Secondly, I'm not sure if I am somehow special, but my board has an 8MHz crystal on it, yet the firmware forces HSE to be set to 25MHz. Ok, those two things are easy enough to fix and that is not a problem. However:
The firmware does appear to be able to communicate with the drivers through UART. I'm getting the message:
Warning: Could not communicate with stepper driver!
Removing the requirement of the attempt succeeding in the trinamic_drivers_init() while loop, therefore causing it to attempt to communicate with all the stepper drivers, not just the first one, I see that all of them fail, outputting the same message 3 times.
Tracing it further I noticed that in tmc_uart_read() it sometimes passes and reads the data properly, sometimes times out. Looking at the UART line on a scope confirms this, I can see 5ms gaps in the data transfer (reffering to the 5ms timeout period). I can also see that since the connection on the microcontroller side of things is through a 1K resistor and there is a 20k pulldown resistor on the TMC2209 module itself, the high voltage level when the microcontroller is in control of the UART line is lower than when the TMC2209 takes control of the line. I can use this to differentiate when one or the other device controls the UART line and this is apparent on the scope as well. However, it seems that the driver is not always responding, sometimes I can see communication from just the MCU. I haven't delved deep enough into the code just yet to know what data to expect to read going in either direction (or exactly how the single-wire UART on the TMC2209 works), so decoding the UART signals doesn't provide all that much value at this point in time.
In the TMC2209_Init() function it returns true (1) if exactly 7 registers have been read (as far as I can tell). Placing a breakpoint at the end of this function, I can see that sometimes it fails the status register check, sometimes it passes and gets to the end of the function where it has managed to read a random number of registers (0-7).
That is about as far as I've gotten. To rule out a hardware failure, I quickly flashed klipper (a 3D printer firmware for those unaware) and managed to confirm that klipper is able to comunicate with the drivers just fine with no hardware adjustments. I did use the direct path to the GPIO pins of the microcontroller (not through 1k resistor) for the klipper firmware, however I did also try that on GRBLHAL with no success.
Anyone has any ideas on what the cause might be and where to look? Tracing all of the trinamic code to figure out what does what and how would take days for me and at that point it makes more sense for to just use the drivers in standalone more. Might be able to figure out what is going on with some pointers though.
Also, if there is something that needs testing on the SKR Pro, I would be happy to help.
The text was updated successfully, but these errors were encountered: