Getting TMC2209 working on SKR PRO

[Creepop]

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.

[terjeio]

Try with this:

btt_skr_1.1.zip

[Creepop]

That seems to have done the trick. Thanks.
Did you already have this prepared or was some of my rambling actually helpful?

[terjeio]

Did you already have this prepared or was some of my rambling actually helpful?

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.

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).

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.

[terjeio]

I have now committet an update with the final modifications, It will be helpful if you can test this and report back.

[Creepop]

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.
One thing I wanted to clarify though: do I have to configure something extra in the STM32CubeIDE project? When pulling a fresh project from github, the compiler is always complaining about any header include that points to a folder. It seems that it is looking for files in the path referenced to the current folder rather than the project root folder, meaning, I have to manually replace all "grbl/hal.h" with "../grbl/hal.h" (hal.h is just an example, it works this way for all includes that point inside of a folder).
Also just to clarify: where does the 25MHz crystal requirement come from? I looked into the SKR PRO (v1.1) schematic on github and the schematic matches my board: it runs on an 8 MHz crystal.
https://github.com/bigtreetech/BIGTREETECH-SKR-PRO-V1.1/blob/master/Schematic/SKR-PRO-V1.1%EF%BC%88SCH%EF%BC%89.pdf

[terjeio]

One thing I wanted to clarify though: do I have to configure something extra in the STM32CubeIDE project? When pulling a fresh project from github, the compiler is always complaining about any header include that points to a folder.

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.

Also just to clarify: where does the 25MHz crystal requirement come from? I looked into the SKR PRO (v1.1) schematic on github and the schematic matches my board: it runs on an 8 MHz crystal.

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?

[Creepop]

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:
I pulled the repository in the workspace folder using git:
git clone --recurse-submodules https://github.com/grblHAL/STM32F4xx.git
And imported the project into the workspace without copying (since it is already in the workspace folder). Didn't change any names anywhere (wasn't aware that I can do that), so I'm not 100% sure what you mean.

[terjeio]

Do you happen to have a link for this?

Here is one - in my experience when the USB clock is not correct the port will not enumerate. Confusing...

And imported the project into the workspace without copying...

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:

cproject.zip

[Creepop]

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.

Here is one - in my experience when the USB clock is not correct the port will not enumerate. Confusing...

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.

[terjeio]

As stated earlier, if the interrupt handler for TIM7 is not defined, the board hangs, so USB ends up not being able to enumerate.

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.

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.

This is not always possible since many are not marked at all or with cryptic letters.

[olijouve]

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.
You are definitely right for 8MHz crystal ! I visually checked it on my board and i took some pics:
https://ibb.co/L9G5fxn
https://ibb.co/C0p6nP9

One step further for my next tests !

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.

I tried to understand but i cannot see what you meant saying "if the interrupt handler for TIM7 is not defined."
Any direction to define it ?

[terjeio]

I tried to understand but i cannot see what you meant saying "if the interrupt handler for TIM7 is not defined."
Any direction to define it ?

This should be fixed in the latest build. First step for you is to get communication up and running, disable Trinamic drivers until then.

[olijouve]

It's alive !

 GrblHAL 1.1f ['$' or '$HELP' for help]
[MSG:'$H'|'$X' to unlock]
error:9
G-code locked out during alarm or jog state.
error:18
[VER:1.1f.20211209:]
[OPT:VNMSL,35,1024,3,0]
Target buffer size found
[NEWOPT:ENUMS,RT+,TC,SED]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:STM32F407]
[DRIVER VERSION:211209]
[BOARD:BTT SKR PRO v1.1]
ok

Here are the flags used with a fresh clone of repository:

  -D BOARD_BTT_SKR_PRO_1_1=
  -D USB_SERIAL_CDC=1
  # Boot loader offset (32K)
  -D HSE_VALUE=8000000
  -D HAS_BOOTLOADER

EDIT:
it also loads with -D TRINAMIC_ENABLE=2209
GRBL ouput one more line:
[PLUGIN:Trinamic v0.07]

[olijouve]

That seems to have done the trick. Thanks. Did you already have this prepared or was some of my rambling actually helpful?

How do you get that output ?

[terjeio]

How do you get that output ?

See the plugin readme for settings and M-commands provided.

Start with enabling one motor with $338, e.g. $338=1 for the X-axis. If initialization of the TMC2209 goes well M122 will output the report.