STM32h743IIT6

[Kiertokanki]

I have made 6-axis motion controller board which is using STM32h743IIT6 MCU. This will be motion controller for my own Pick and place machine with OpenPNP.

I've managed to make the MCU communicate with OpenPnP and ioSender by using BTT SKR 3 H743 configuration in the STM32CubeIDE. But the problem is that as soon as I start to change pin mappings according my own motion controller the things start to go wrong. If I do the pin mappings according my own motion controller board with STM32H743IIT6 it won't communicate with Openpnp/ioSender and it won't be regognized by OS anymore.

So the question is that what needs to be changed to support the STM32H743IIT6?

I assume that because the STM32H743IIT6 has more ports/pins than STM32H743VIT6 it will cause some sort of conflict. Especially if I use pins which are not available in the STM32H743VIT6.

[dresco]

Hi, do you have a pinout / board map you can share? Will try and check it over (though I only have up to 144 pin H7 boards to test on).

One thing off the top of my head, the current driver only enables GPIO clocks for GPIOA - GPIOG, so you will probably need to add GPIOH there also.

[Kiertokanki]

Here is the board map. I've made the chances directly to the btt_skr_v3.0_map.h. I've added the my_machine as well incase it is needed.
Board_Map.zip

[dresco]

Thanks, don't notice anything obviously wrong there..

I see there are GPIOI outputs as well, so same comment as above for those - you'll want to add the extra lines in driver.c to enable the clocks for additional GPIOs.

    __HAL_RCC_GPIOH_CLK_ENABLE();
    __HAL_RCC_GPIOI_CLK_ENABLE();

I also notice you've commented out the SAFETY_DOOR port and pin definitions, but I think that would just result in a compile time error if SAFETY_DOOR_ENABLE was defined and they weren't?

Aside from that, as the original SKR3 map file works for comms at least, I would maybe just add your changes back bit by bit until you find what breaks it?

[Kiertokanki]

"I also notice you've commented out the SAFETY_DOOR port and pin definitions, but I think that would just result in a compile time error if SAFETY_DOOR_ENABLE was defined and they weren't?" Yes it did, I had to remove it as don't need it.

OK will do, step by step. It sounds like I haven't done anything fatal so far. Thank's for your help!

I'll report back once I have tested your suggestion.

[Kiertokanki]

If I change auxiliary port pin mappings to same as in BTT SKR 3 H743 mapping file then the USB communication works. I have no idea why but atleast I can make some testing now. I've added the missing clock configuration for GPIOH and GPIOI.

I'm using TMC5160 as stepper controller. I can't move any of the axes and there is no any activity on step / dir pins. And it looks like the SPI is not transferring any data. Any suggestions what might cause that?

[dresco]

If I change auxiliary port pin mappings to same as in BTT SKR 3 H743 mapping file then the USB communication works. I have no idea why but atleast I can make some testing now. I've added the missing clock configuration for GPIOH and GPIOI.

Ah, that helps actually. Will be because spindle PWM is configured on PE3, which isn't configured as a PWM capable pin (had missed that in my initial look). According to the datasheet, PE3 doesn't appear to be a timer output, so I don't think it can be used for this purpose.

Your spindle enable and direction pins (PI6/PI7) look more suitable though, if you are able swap for one of these? They are both timer8 outputs, so could be added to the PWM configuration code.

I'm using TMC5160 as stepper controller. I can't move any of the axes and there is no any activity on step / dir pins. And it looks like the SPI is not transferring any data. Any suggestions what might cause that?

Being based on the SKR3 map, will be using software SPI, so should be flexible on mapping. Does the $pins output look correct?

You'll need TRINAMIC_ENABLE set to 5160, $338 set to reflect the axis in use, and then M122 should return the status of the driver(s)? When troubleshooting I like to populate/enable just a single axis at a time to verify the initial comms.

However, I would expect activity on the step/direction pins regardless. Is not in an alarm state or anything that would block movement?

[Kiertokanki]

Ok now I have SPI activity and step/dir signal seems to function. If I try to move X, Y or Z-axis nothing happens. Drivers will get control signals but TMC5160 is not reacting to control signals. There is hardware fault in Y-axis. One of the high side mosfet is having low gate voltage, I'll have to figure out why.

If there is fault (s2gb) in Y-axis will it prevent moving of X and Z axis too?

Here is the status of all TMC5160 drivers:

                  X       Y       Z

Driver TMC5160 TMC5160 TMC5160
Set current 2000 2000 500
RMS current 1980 1980 495
Peak current 2800 2800 700
Run current 26/31 26/31 5/31
Hold current 13/31 13/31 2/31
Global scaler 131/256 131/256 148/256
CS actual 13/31 13/31 2/31
PWM scale 15 12 2
vsense N/A N/A N/A
stealthChop false true true
msteps 16 16 16
tstep 1048575 1048575 1048575
pwm
threshold 0 0 0
[mm/s] 0 0 0
OT prewarn false false false
OT prewarn has
been triggered false false false
off time 5 5 5
blank time 1 1 1
hysteresis
-end 2 2 2
-start 6 6 6
Stallguard thrs 22 0 0
DRIVER STATUS:
stallguard
sg_result 86 0 0
fsactive
stst * * *
olb
ola
s2gb *
s2ga
otpw
ot
STATUS REGISTERS:
X = 0xC0:0D:20:56
Y = 0x90:0D:40:00
Z = 0x80:02:60:00

[dresco]

If there is fault (s2gb) in Y-axis will it prevent moving of X and Z axis too?

Hi, don't know I'm afraid. May get more visibility asking on the main repo? However, I would think that if grblHAL is sending the enable/step/dir signals as expected, then is okay from that side.

I've not got much experience with the TMC drivers, but it looks like the 5160 can be configured in multiple modes, with either full spi motion control, or spi config + step/dir for motion. Not sure whether this is hardware or software selected?

[Kiertokanki]

I agree that grblHAL is sending what it should be. It's the TMC5160 which is causing troubles. I think I will keep looking for hardware errors in my design incase I have missed something, but so far everything looks ok.

TMC5160 modes are selected by hardware pins. SD / SPI are pulled up or down depending on configuration. In my configuration both pins are pulled up which enables SPI and Step/Dir pins. It's called MODE 2: Step & Direction Driver.

[Kiertokanki]

I can confirm that STM32H743IIT6 functions ok with grblHAL. I had finally time to assemble partly a new PCBA. Now it works perfectly and I can control up to 3 axes. Hardware suppports up to 10 axes but using all of those is different story.

Thank you dresco for your help! Now I can fully assemble the PCBA and continue hardware build.

[phil-barrett]

Do you have page/github/blog where you talk about this? I'd like to see more of what you have done.

[Kiertokanki]

I don't have a webpage, blog or github yet which shares information about this controller. I havent decided what to publish (and when) once this is ready. I am stil at proof of concept phase and I need to make sure everything works as designed before publishing too much information. This started as 6 axis controller but I've made already made a new revision which has 10-axis support.

I started make this because I had new idea for feeders and I needed conveyor. I have two additional machines which are supported by this controller: Vapor phase reflow oven and robot soldering machine for TH-components.

I decided to go with the modular stepper controllers. It makes the whole platform much more versatile. First stepper controller module is based on the TMC5160. What I really would like to do in the future is module which has TMC4671 for closed loop stepper control.

Here is shortly the main details of the controller PCBA:

• 10 x stepper module connectors (64-pin PCIE connector). 10A / phase maximum current. 50VDC maximum voltage.
• 2 X TH terminal blocks for stepper main power supply
• 1 x TH terminal block connector for internal power supplys & HC driver outputs
• 16 x GPIOs, These can be either input or outputs. These are 5V tolerant.
• 12 x high-side drivers. Each one is capable of driving 5A max current, but they are meant for 1A output especially if all are in use. 4 channels have current feedback which are connected in to individual ADC channels.
• 8 x Analog inputs, 3,3V tolerant
• 2 x isolated differential UARTs
• 2 x isolated CAN bus
• Isolated USB
• Connector for RiBUS (for Riverdi LCD)
• 1 X annoying piezo speaker

Here is the picture of partially assembled main PCBA and three stepper modules. I hope the picture shows ok.

Please let me know if there is something specific you would like to know.

[phil-barrett]

That's pretty cool! Are you discussing this on OpenPNP? I've been following a nucleo project there.

Also, did you make the 5160 drivers or are they sourced from somewhere else?

[Kiertokanki]

Thanks! No I haven't yet participate on OpenPNP discussion. This is first time I share information about this motion controller board online.

Yes I made the TMC5160 driver modules.

[Kiertokanki]

I am aware of the JuicyBoard which is similar, did you mean that? I can presentate in the OpenPNP commmunity what I have made once I get the whole PNP machine up and running. That will take some time but I hope to get all ready during next month.

Once I get the TMC5160 drivers fully tested I might consider selling those. Before that I have to make sure it works as designed.

[phil-barrett]

No, I don't think it is JuicyBoard. This appears to be initially based on a Nucleo H755. Looking at the actual thread (I get OpenPNP summaries via email) it's somewhat different from what you are doing. Anyway, here is the thread.

[Kiertokanki]

Thank's for the link, yes it looks different.

BTW, I might have seen you name in some of the OpePNP threads regarding motion controllers. Did you make own controller based on Teensy?

[phil-barrett]

Yes, I design and sell several - one based on the Teensy, one on the RasPi Pico. I thought about doing a version for the OpenPNP crowd but have a lot on my plate already. The iMXRT 1062 in the Teensy is very similar the H7xx line. I regularly consider using the H7xx chip but prices are pretty crazy, even in volume.

[Kiertokanki]

That's cool! I agree that the STM H7-series isn't cheap.