Progress with STM32H7

[Demitrius]

Hello Terje Io and All.

Same question like in #88

I want to use BTT motherboard with STM32H743VIT6 cpu.
How about progress with STM32H7 ?
May I help you some how?

[terjeio]

May I help you some how?

You can by adding a board map for the STM32H7 driver written by @dresco.

[Demitrius]

Good. I will try when board arrival. About 1 month.

Also, found this board added to Marlin firmware.
MarlinFirmware/Marlin@e63d692

[dresco]

Hi @Demitrius

Is that the BTT SKR 3 board you have on order? I had been wondering about getting one for testing.

Thanks for the link to the Marlin code, will probably be something useful in there..

[dresco]

For info, have ordered a BTT SKR 3 EZ board with 2209 drivers. Will pull some pin definitions out of the Marlin code and get it up & running when it arrives.

One thing I've noticed from the Marlin code already, for some reason the I2C EEPROM has been put on the SWD pins, so looks like no proper debug on this board :(

Am hoping to make my own board for the H743, but will realistically be a (northern hemisphere) winter project, so a while away..

[Demitrius]

Hi @dresco

Ordered a BTT SKR 3 EZ board with EZ5160 PRO drivers.
Its not good about debugging...

[dresco]

My board arrived today (that was quick).
I'll try to find some time this week to create a board map and bring it up for initial testing..

[Demitrius]

Great! My still on the road.

[Demitrius]

Hello. Board arrived. Can I do something for you?

[dresco]

Cool. I've been updating issue #158 - I have my board up and running with the 2209 drivers using software UART.

I plan to pick up a 5160 breakout for testing when they come back into stock. In terms of porting the code to the H7, I think the F4 repo is the best place to start - as it has Trinamic SPI code for SKR 1.1, SKR 2, and Nucleo boards.

@terjeio I've just noticed that the SKR 2 board driver has a s/w SPI implementation already - I'd missed that previously. What do you think the best approach is, to try and refactor both h/w and s/w SPI implementations out of the board drivers into a tmc_spi.c or similar?

[terjeio]

@dresco - refactoring into a tmc_spi.c sounds like a good idea. I can backport to the F4 if you do it for the H7.

[dresco]

@terjeio Am making progress with this - but something in the trinamic driver is puzzling me...

Within on_driver_setup(), driver_setup() is called before trinamic_drivers_setup(). This means the GPIO init logic runs before the CS pins have been enumerated, and therefore they never get set as outputs?

https://github.com/grblHAL/Plugins_motor/blob/f371ebcd5fd8e2edf6aa7e77146189eb1c425bde/trinamic.c#L1622-L1632

I can't see how this would work for the existing drivers, or am I missing something? Thanks!

[terjeio]

This is where and how all outputs pins are configured in driver_setup() for the F4. Its this what you are looking for?

[dresco]

From what I see here, the issue is that function is called before hal.enumerate_pins(true, add_cs_pin) has been executed, so the CS outputs aren't there to be configured?

In the link I posted above, the HAL driver setup is called first (configuring the pins), and then the trinamic driver setup is called (adding the chip select pins as outputs)..

[terjeio]

so the CS outputs aren't there to be configured?

I am not sure what you mean by this - they are configured as outputs and set high in driver_setup() and then bound to the axes during enumeration. Do you want to add more to the configuration?

[dresco]

I am not sure what you mean by this

Ahh - I've just realised my mistake. I was assuming the enumeration had to happen before driver_setup() was run in order to configure them, but I now see that is not the case at all.

I had tripped myself up by (a) initially forgetting to add the PinGroup_Motor handling to driver_setup(), and then (b) forgetting to change DIGITAL_OUT to suit the F7/H7 implementation (shifting by the pin number instead of using it directly).

Had convinced myself it wasn't working for all the wrong reasons, apologies! ;)

[dresco]

I've pushed my work so far to a new tmc_spi branch on my repo. I don't have the hardware to test yet, but both software and hardware SPI implementations appear to be starting okay.

One thing of note, I've not been able to change the prescaler after the SPI peripheral has been initialised. The writes to the config register don't have any effect (possibly locked if in use?), will look into that...

[dresco]

The writes to the config register don't have any effect (possibly locked if in use?), will look into that...

Fixed in latest commit I think, the SPI peripheral just needed to be disabled before writing to the register.

[terjeio]

If you have time you may want to try WebUI v3, it stresses the networking code (http and websocket daemons) as well as the SD card so great for testing. I have added a new API call to enet.c that is required, you'll have to add that as well as update to the latest core.

[dresco]

If you have time you may want to try WebUI v3

Cool, will do..

[dresco]

@Demitrius I've just pushed the TMC5160 support to my master branch if you want to test?

I don't have the 5160 modules to test on my SKR3, but have successfully verified communication with a TMC5160-BOB on my WeAct dev board.

[Demitrius]

@dresco Good news!

Could you provide me list of task I can do?
Similar:

1 - Connect TMC5160 (EZ my case) to board
2 - Connect USB Board - PC
3 - Need I connect 24V power supply ? (It still on the road)
4 - Install PlatformIO (or other) env to build firmware
5 - Upload firmware to board
6 - See logs (how?)

[dresco]

@Demitrius

From my testing with the 5160 breakout, it does need motor power to be supplied before it will respond, so you will need the 24v power supply.

Is probably easiest to build and program with PlatformIO (STMCubeIDE needs another tool for DFU uploads), or I can provide a binary for testing if easier.

Please note however, there is currently something odd with the PlatformIO builds - for instance SD Card access issues that I don't see on my STMCubeIDE builds. (I haven't spent much effort investigating this yet, as their H7 library is out of date anyway - so am unable to make any PlatformIO Ethernet builds, and was waiting for that to be updated first)..

[terjeio]

STMCubeIDE needs another tool for DFU uploads

If you enable binary output that should be usable?

[dresco]

If you enable binary output that should be usable?

Yep, I've added an entry to my "External Tools" menu to call a command line DFU uploader, that seems to work well enough. (Incidentally, the ST32CubeProgrammer CLI also accepts .elf files for DFU upload, but I expect most people would use something like dfu-util instead)..

I think the issues I was seeing with PlatformIO builds are resolved also. I may eventually try to set up a GitHub action to build the PlatformIO firmwares automatically.

[dresco]

I may eventually try to set up a GitHub action to build the PlatformIO firmwares automatically.

This turned out to be easier than I expected - is now building automatically on each push to master, and the resulting firmware files are archived in the artifacts for each run.

Am currently building the following, in standard 3-axis configurations;

• BTT SKR 3 with SDCard, USB serial, and TMC 2209 driver support.
• BTT SKR 3 with SDCard, USB serial, and TMC 5160 driver support.
• WeAct MiniSTM32H743 with SDCard and USB serial.
• Nucleo H743ZI with Ethernet and SDCard support (SDCard is required for WebUI & needs a breakout board)

[andrewmarles]

@dresco did you find any specific documentation to set up the automatic builds? This is something I would like to do on the F4xx driver.

[dresco]

@dresco did you find any specific documentation to set up the automatic builds? This is something I would like to do on the F4xx driver.

@andrewmarles Only from the platformio docs, and looking at other examples online. My config is here, and I think it should work as-is in the F4 repo. The workflow file(s) just need to go into a .github/workflows folder in the main/master branch.

Am archiving any generated firmware files into the artifact for each run - however these are only stored for 90days from the build.

Possibly a good next step could be to create a more permanent release action. Perhaps creating tags & releases based off the hal.driver_version string? But that's getting more ambitious, and not something I've tried before either..

[Demitrius]

@dresco early we made successfull test TMC2209 and 5160 drivers with STM32H7. Will you merge changes to master branch?