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.

[Kiertokanki]

I have been using my custom board with the OpenPNP and so far it has been working extremely well. There is only one problem which is ralated to the STM32H743IIT6 internal ADC. I have installed laser distance sensor in the PnP machine. The sensor has analog output which is connected to GPIOF pin 14 (ADC2, ADC_CHANNEL_6). I have added three AD ports and pins for the analog inputs in the board map. I would be happy if one of the AD-channels would work, as the two remaining AD-channels are for the future use.

#define AUXINPUT0_ANALOG_PORT GPIOF
#define AUXINPUT0_ANALOG_PIN 14

#define AUXINPUT1_ANALOG_PORT GPIOF
#define AUXINPUT1_ANALOG_PIN 12

#define AUXINPUT2_ANALOG_PORT GPIOF
#define AUXINPUT2_ANALOG_PIN 11

These pins are not claimed anywhere else. With the OpenPNP plugin enabled, I can't read the ADC value with M-code: M143 E0

It gives this error:
error:3 - '$' system command was not recognized or supported

I noticed that with the $pins command there isn't definition for the analog ports E0,E1 and E2:

[PIN:PF14,Aux analog in 0]
[PIN:PF12,Aux analog in 1]
[PIN:PF11,Aux analog in 2]

What am I missing here, or have done wrong? I was only able to find information about the external ADC MCP3221, but nothing regarding the internal ADC of STM32H7XX with grblHAL.

[terjeio]

Could be a plugin bug. Is M66 working? Try M66E0L0, the returned value is in the next status report (in the In: element) - or you can get it via sending $#=5399.

[dresco]

Honestly, might be a driver bug also, am not sure I've even tested analog inputs.. Will verify behaviour here on a H7 Nucleo board.

[Kiertokanki]

I've used build 20250910 so far and I decided to try slightly newer, which is 20251111. Now the error message has slightly changed. For M-code M143 E0 I get this error:
error:39 - Value out of range

M66E0L0 gives this:
error:20 - Unsupported or invalid g-code command found in block.

$#=5399 gives this:
[PARAM:5399=-2]

[dresco]

Have just tried on a bare Nucleo144 dev board, no code changes except for un-commenting the aux inputs in the reference map.

I don't get an error, but the values returned don't appear to reflect the actual voltage applied to the pin(s). I'll try to have a look into this next week..

[dresco]

Forgot to add, I do see the E0/E1 entries in my $pins output;

[PIN:PF7,Aux analog in 0,E0]
[PIN:PF8,Aux analog in 1,E1]

[Kiertokanki]

Thanks for testing the analog input. This means I should have working analog inputs too, but there is something else wrong with my configuration, which causes missing of the E0, E2 and E3. Maybe it's best if I compare my changes to the unmodifed grblHAL and look if I have accidentally made changes which should not be there.

[dresco]

I found some issues with the ADC setup code that caused my bad readings. I'll test more thoroughly against all three ADCs and push an update for that next week..

[Kiertokanki]

That's great! So far I have not been able to find anything which might cause the errors I'm receiving, but I'll continue searching today and tomorrow.

[dresco]

fyi, have just pushed some updates to the H7 branch, which include the ADC fixes.

Have bench tested on a Nucleo here with 3 analog inputs, one channel each on ADC1/ADC2/ADC3, and also with multiple channels on a single ADC.

[terjeio]

I've updated the Web Builder

[Kiertokanki]

Thanks for the update, I'll test this with my setup.

[dresco]

@Kiertokanki

See also this new issue in the H7 repo.

I can replicate this behaviour, the pins are registered as expected on my Nucleo board, but not on the WeAct Mini. I suspect will be the same issue as you are seeing..

[Kiertokanki]

That problem sounds familiar. So the issue has been now fixed?

[dresco]

Yes I believe so, I could replicate when analog inputs were defined in the board map, but no analog outputs..

[Kiertokanki]

Good! I'll have to test it too.