Driver Trinamic 5160 - SKR3EZ MB don't communicate with IOSender

[MrKapim]

Hi Terjeio, I'm trying to use GrblHal on a SKR3-EZ board with 5160 drivers (4 axis). I had some problems with USB communication, but @Dresco helped me and solved it. Now I'm having problems with Trinamic. The steppers don't move, they're dead. Below is a photo of the IOSender with information, where I receive the drive not communicating message after sending the M122 command. Can you help me please?

[terjeio]

Motor power is on before booting the controller? If not communication will fail. Have you tried with M122I to reinit the drivers? Same response?

There is not much I can do without access to a board as it uses soft SPI for communicating with the drivers. Enabling a single driver with $338 and using a logic analyzer or oscilloscope to check that the signalling is ok is one way forward, another is to set breakpoints in the driver code to see what the drivers responds with. Can you, or @dresco, do that?

[MrKapim]

Yes, the motors is power on before boot. Yes, I send M122I and the answer is the same (Could not communicate with stepper driver!). This M122I command was made for all 4 axes first and then separately with only 1 of the axes enabled (1 at a time). I don't have an oscilloscope available but I'll try to get one to evaluate the signals from the drives. I think that next weekend I will have some results, answers. For now, thank you very much for your help...

[dresco]

Hi, afraid I'm still travelling at the moment, without access to any development hardware..

There was this issue raised on the H7 repo, but it shouldn't affect the PlatformIO or web builder builds.

[dresco]

Hi, just back home and looking into this. It does appear to be working fine for me. Testing with a single 5160 breakout board attached via jumper wires, as I don't have the EZ5160 plug-in modules.

Are you able to share your build configuration?

[MrKapim]

Hi Dresco, It doesn't matter the configuration. For testing, I put in the standard firmware, and the dimensions of X, Y and Z only. No other information has been added and even so, the drivers not communicating message remains (via IO-Sender send M122 I and the message continues)... In my opinion, the hardware is not configured (drivers or libraries are missing), but this is just speculation because I don't have the expertise...

[MrKapim]

Adding... I'm new to GRBL... But I've had some experience in Marlin (I have a 3D_Printer) for a few years now. Take a look at my comparison... When I turn on 3DPrinter, the "positions" of the axes appear with values, "crazy, weird" numbers but after referencing (home position) these values, numbers become "cute, suitable". On the CNC when I turn it on, the numbers are at "ZERO". And since I can't "reference" due to the communication error (drivers don't communicate), these numbers don't change...

[dresco]

For testing, I put in the standard firmware, and the dimensions of X, Y and Z only. No other information has been added and even so, the drivers not communicating message remains..

What exactly is this "standard firmware" though? Are you building through the web builder or locally. and what options are you using? It would be helpful to see the build configuration either way.

I think it is most likely to be a configuration issue, as it seems to be working as expected here..

[terjeio]

$338 is set to enable the drivers? For a 3 axis machine set $338=7. There are other related settings as well as some M codes that can be used to query driver status etc.

[MrKapim]

Hi, I'll transcribe my steps... 1. Download firmware and dependents (STM32H7xx-master, core-master, Plugin_SD_card-master, Plugins_motor-master, Trinamic-library-master, Plugin_WebUI-main) 2. Copy contents to STM32H7xx-master folder >>> core-master to "grbl" folder, Plugin SD_card to "sdcard" folder, Plugins_motor to "motors" folder, Plugins_Webui to "webui" folder and Trinamic-library to "trinamic" folder 3. Move "server.c" file from webui folder to src folder and add number of errors to platformio [common/buid_flags] 4. After platformio compile, copy the file "firmware.bin" (just the 723) to sdcard, install on board and reset to MB read the firmware 5. Open IOSender. In the "Grbl_Settings tab, I set up the pins (without inversions), home, etc. And finally the axes for "trinamic driver". Save to eprom click 6. Tests and receive the message "could not communicate with stepper drivers"...

[MrKapim]

There is an error that I have "commented" for the compilation to complete (photo below). I still need to figure out how to fix it... But that's another issue...

[dresco]

Hi, am a bit confused, you shouldn't have to change anything for compilation to complete. The CI workflow test builds all environments from platformio.ini each time the H7 GitHub repo is updated..

Could you perhaps have a mismatch of driver and submodule versions? It would be a more common workflow just to clone the repo and it's submodules in one command, e.g. git clone https://github.com/dresco/STM32H7xx.git --recurse

I committed a couple of small updates this morning, and this is the CI generated firmware for the btt_skr_30_h723_tmc5160_bl128 environment. Is this any different?

firmware.zip

[MrKapim]

Following your comments and notes, I downloaded the firmware.zip attached. Same issue. Then via GitHub Desktop I cloned the repository (cool, it comes complete, I don't need to "handle" anything). But it also has the same issue. I still have the message of "could not communicate with the stepper drives".

[dresco]

Could you paste the output from $i, $pins, and $$ commands?

When testing, I usually set $338=1, which just enables the X axis driver. Do you have access to an oscilloscope or logic analyser. Would expect to see something like this on the pins;

You can pick up the SPI signals from these pins around the module;

[MrKapim]

the infos... $_Command.txt $i_Command.txt $pins_Command.txt

[MrKapim]

One note... the version of the grbl is out of date (when I downloaded it via github, I cloned it)...

[dresco]

the infos.

Thanks, that all looks correct to me. And you've tried (for instance) setting $338=1 to enable just the X axis driver - makes no difference?

[dresco]

One note... the version of the grbl is out of date (when I downloaded it via github, I cloned it)...

Is expected, the driver needs updating for core changes etc. Currently testing the latest changes in a local repo..

[MrKapim]

Yes I also tried only one axis (X axis) and the result was the same... Message "Could not communicate with stepper driver!"

[dresco]

Afraid I'm pretty much out of ideas, as it seems to be working as expected here - within the limitations of my slightly different hardware setup (H743 SKR3 variant + external 5160 module).

I think probably next step would be a scope or logic analyser to check the SPI signals on the module connector, if you have access to one?

[dresco]

Actually, one more idea... Looking at the manual + schematic, the drivers can either be powered by the main DC IN supply or a separate Motor Power terminal.

Which one is used depends on the jumper position above the module connector. Jumper on the right uses the main DC supply, and jumper on the left uses the separate motor power terminal - worth checking they're actually getting power?

[MrKapim]

I'm using the "Motor supply" selection (pic 3.2.2). The multimeter show me the voltage is OK!!! I bought a low cost oscilloscope (car maintenance) with 1 channel and 18 MHz. Should arrive tomorrow...Then I'll try to analyze the signs of SPI.

[MrKapim]

Hi dresco. Let me try to help... Analyzing some signals, commands, definitions... In the stm32h7xx_hal_gpio_ex.h file (DriversSTM32H7xx_HAL_DriverInc) - (pic_01) there are definitions for SPI's (1 to 6)... Searching via "cross reference" I find SPI's 1, 2 and 3 in the file (Src\spi.c) - (pic_02) . According to the motherboard wiring diagram and the 32H723 manual, the SPI for the motors is the SPI4 (pic_03). And this SPI I can't find via "cross-reference" starting in file STM32H7xx_HAL_Driver... Wouldn't this be the problem, i.e. there is the "guy" in the definition of the "controller" but it is not being "indexed" in the utility software (grblhal)... pic_01

pic_02

pic_03

[dresco]

And this SPI I can't find via "cross-reference" starting in file STM32H7xx_HAL_Driver...

The SKR3 board uses a soft SPI implementation for the motor drivers (code is in Src/tmc_spi.c) - as the wiring doesn't quite match any of the hardware SPI pins..

https://github.com/dresco/STM32H7xx/blob/1d814cfb62a58d0a5056f74676f03e0b9cec69f7/Inc/btt_skr_v3.0_map.h#L155C1-L158C26

[MrKapim]

Initially I was happy, there was no 5Vdc (2 modules lowering the voltage). I removed them, I left only 1. I adjusted it to only 1 axis, #338=1. The supply voltage (5Vdc) is OK now, but it still has no communication. Checking the signals, I don't have any frequency on any of the pins (MISO, MOSI and CLK, CS)...

[MrKapim]

I don't know what happened, but now I'm getting 3 times the pins for SPI. Nothing has changed, except for the drivers, now I have only 1 physically installed and with setup #338=1.

[dresco]

Initially I was happy, there was no 5Vdc (2 modules lowering the voltage).

That's a red flag, how are you powering the modules? Have you tried a known good firmware (e.g. Marlin) to verify the hardware setup?

The 5V VIO pin is only for the signalling, also needs 8-46V on the VM pin before it will respond - this comes from either the main board supply, or from the separate motor power pins if selected by jumper...

it still has no communication. Checking the signals, I don't have any frequency on any of the pins (MISO, MOSI and CLK, CS)...

Are you triggering off one of the SPI channels? The communication attempt will be over very quickly (~70uS) without a response from a module. Here's a startup soft spi trace from a dev board with no module attached.

Which driver modules do you have from here, the 5160 Pro? Maybe I'll get one for peace of mind, will take a couple of weeks to arrive though..

I don't know what happened, but now I'm getting 3 times the pins for SPI.

That implies the trinamic driver setup function is running multiple times. No idea how that happens, I have only seen it called once from grbl_enter() on startup.

[MrKapim]

The motors are powered by the board. There are the 5VDC (Vin) and also the 24VDC (Vm) on the pins of the modules. I know there are other SPI channels, but they are not being used (yet), i.e. only SPI motors. I'm using the EZ5160pro V1.0 (the same one you're waiting for). Today I set up Marlin to test and communicated normally, no errors. I'm only using the X-axis (a single driver on the board). I'm buying new drivers to replace the damaged ones. They should arrive this week...

[dresco]

Okay thanks, have ordered a EZ5160pro V1.0 module to verify against my setup here..

[MrKapim]

Hi Dresco, good and bad news. The good is the drivers communicate and the bad, the motors don't move...

[MrKapim]

In pic above, the drivers response and the settings. The last line is the command to Home and the motors don't moves... My settings to homing....

[MrKapim]

forgive me. motor A missing...

[MrKapim]

Other information... I tested before with Marlin and all motors (4) moves

[dresco]

I'll take a look, my EZ module should be on the way also....

[MrKapim]

Hi @dresco, Information for you to think about... Yesterday I noticed that there was H7 driver update. I cloned it and put it on the motherboard. The communication error goes straight in. I put the previous version back in and I have communication with the drivers normally. Another important detail!!! If you leave the motherboard on, in about 15 minutes, the drivers heat up and a lot (they fry!!). Especially the Z driver (tested only previous version). This is probably what damaged my other drivers (remember that I put in new drivers because the previous ones were draining the 5v, sending it to 0v).

[dresco]

Interesting, thanks. My 5160 EZ driver arrived this weekend, will test tomorrow & compare to a Marlin build..

[MrKapim]

New information (to me terrible, horrible information). The motherboard no longer turns on. I left it on for about three hours (I removed the Z drive, which was "frying". The other drives (X, Y, and A) were "manually touchable", i.e. I can put my fingers in and hold). Loss of 60 dollars.... I'm going to buy another motherboard and we'll talk again... Now I need a few days...

[dresco]

Ah, sorry to hear that @MrKapim :( Will try to figure out what is going on...

[dresco]

Hi @MrKapim

I've done some initial testing here, and (unfortunately?) I'm not able to reproduce your issue..

Documenting my testing setup here;

Hardware setup SKR3 board (H743 variant), powered from DC bench supply at 12V Single EZ2209 or EZ5160pro driver module installed for each test

Initial software setup for each firmware version Flash latest firmware image (with bootloader, 231121 driver version) $RST=* (full reset) $14=70 (invert inputs for bare board) $5=7 (invert limits for bare board) $338=1 (Trinamic axis mask, X only)

Results for 2209 Bare board (idle): 106mA Single driver installed (idle): 111mA Motor attached (idle): 111mA Motor running (G0 rapid move, no load): 900mA

Results for 5160 Bare board (idle): 106mA Single driver installed (idle): 119mA Motor attached (idle): 119mA Motor running (G0 rapid move, no load): 3500mA

I then used M906 X1000 to set a lower stepper current limit, bringing the current during G0 moves down to around 500mA.

I then physically moved the 5160 module to the Y and Z slots, changing the Trinamic axis mask ($338), and the M906 command each time to reflect the new axis. Results from these tests were exactly the same..

Further thoughts

Each Trinamic module should only sink a few mA unless the enable pin is pulled low, which should only happen during movement (and momentarily at startup).

Need to have a think about how to re-test your setup. If it was me, I would start with a bare board, no connections apart from power and USB, then add a single driver module, then add the stepper motor - checking the voltages & current draw after each change..

Regarding your board, there is a fuse on the board for the DC input, perhaps worth checking that out to start with?

[MrKapim]

Hi @dresco The new card arrived, I did new tests and I have good news and bad news... The good is Board, Drivers and Motors running and responding to commands. The bad... When I boot the system (cnc and IOsender), I get the message that it can't communicate with the drivers. Go into the GRBL Settings tab and untick Z driver, save it and have normal communication. Return and tick Z driver, and normal continuous communication. But if I turn it off and restart, the communication error returns, but if I turn off and restart with Z untick, normal communications...

[MrKapim]

There must be something in the initialization that is not quite right (in relation to the Z I say). For now it's working (I have to untick and tick the Z driver after turning on the set) to have the Z axis drive (first in the Home sequence).

[dresco]

I am wondering whether it is related to current draw? Some things to note..

There was an issue with the driver enable pins glitching on during initialisation, that is fixed in my latest commit (driver version 231205), but would have caused a brief current surge during startup.

Also, please check the current limits in the $14x settings. There was also an issue with the default current values after a settings reset. Have just noticed it's been fixed upstream, will get these latest changes pulled into my repo over the next couple of days.

Probably best to keep these values to 500mA while troubleshooting. And if you do see a communication error, then I would proceed with caution, as presumably has not been able to configure a safe current limit either.

How are you powering the board, are you able to check the current? Does it make any difference to the Z behaviour if the stepper motors are unplugged before you power up the board?

[MrKapim]

hi @dresco... good news!!! I made a change to the logic (trinamic.c) and now have the drivers initializing and communicating normally (no tick untick required to eliminate the communication error).

[MrKapim]

I also made another change (trinamic.c), which I think was typo (I replicated it on lines 441 and 458, b and c axes).

[MrKapim]

About your question, even starting the motors after booting the system, the communication problem continues... The current shows no "peaks", surges or overflows, $14x is at 500mA

[MrKapim]

Not. No difference if the motors are off when you turn on the system. Even if you send it to be moved (home for example) the logic interprets normal and IOsender updates the position values, but there was no movement because the motors are out of power.

[dresco]

hi @dresco... good news!!! I made a change to the logic (trinamic.c) and now have the drivers initializing and communicating normally (no tick untick required to eliminate the communication error).

Good news, maybe the drivers aren't all powered up in time.. Does it also work if you move that delay into the main function, somewhere before grbl_enter()?

@terjeio see typo above, trinamic.c lines 424, 441, and 458

[terjeio]

Typos has now been fixed.

[T4KUUY4]

Hi @MrKapim Im having the same issue i think. My 5160´s on an octopus max ez, arent recognized either. They do get warm and definately have power to them. Did you find a fix?

[MrKapim]

Hi @T4KUUY4, the firmware was fixed about this problem by @dresco. But I remember that when my drivers were heating up and there was no movement and/or they were not recognized it was because they were damaged. After I replaced the drivers they worked normally. An important detail!!! I discovered that I had changed the driver enable inversion signal and this was causing them to "burn", damaging them (in config.h the DEFAULT_ENABLE_SIGNALS_INVERT_MASK signal).

[T4KUUY4]

@MrKapim Thanks for the quick response. I was able to determine that 2 of my 5160´s were DOA aswell. Im currently trying to get them replaced by Biqu as they got very hot as soon as they got power. I had 2 other ones laying around from the same spec which are working just fine in the same configuration.

Thanks for the headsup with the inversion signal, even though it wasnt the culprit in my case.