grblHAL
Driver Trinamic 5160 - SKR3EZ MB don't communicate with IOSender
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?
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?
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...
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.
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?
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...
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...
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..
$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.
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"...
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...
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?
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".
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;
One note... the version of the grbl is out of date (when I downloaded it via github, I cloned it)...
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?
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..
Yes I also tried only one axis (X axis) and the result was the same... Message "Could not communicate with stepper driver!"
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?
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?
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.
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
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
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)...
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.
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.
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...
Okay thanks, have ordered a EZ5160pro V1.0 module to verify against my setup here..
Hi Dresco, good and bad news. The good is the drivers communicate and the bad, the motors don't move...
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....