STM32F4 port of RepRap Firmware 3.1.x+

I have just uploaded beta test versions of an experimental STM32F4 port of RepRap Firmware V3.1.x+. The firmware files can be found here:
[drive.google.com]

This port is an enhanced version of the RepRap Firmware LPC176x port and much of the documentation/features etc. applies to both.
Currently the following boards are supported:

• BTT SKR Pro V1.1
• BTT SKR Pro V1.2
• BTT GTR V1.0 (The expansion board is not currently supported)

Two versions of the firmware are provided:

• firmware-wifi.bin supports access by an ESP8266 WiFi module.
• firmware-sbc.bin supports connection to a Raspberry Pi SBC.

Both versions have USB and serial ports enabled.

For more information on installing and configuring the firmware please see the STM32F4 sections of the Wiki:
[github.com]

For help with generating RRF configuration files please see the online configuration tool (which has been updated for this release):
[jaysuk.github.io]

For help and general discussion please use the discord server:
[discord.gg]

I'd like to thank jay_s and PCR for their work in supporting the LPC version (WiKi, Hardware, Config tool, Discord and lots more) and all of their support and testing of
early versions of this software. I'd also like to thank SDavi and DC42 for all of their contributions to RRF.

Please note the following:

• The WiFi version of this firmware requires updated firmware on the ESP8266 (it removes the small number of active socket limitation
  used with the LPC version). The updated ESP8266 firmware is provided in the link above (see the WiKi for programming details).
• The SBC version of this firmware removes many of the limitations present in the LPC port (which are due to memory constraints), because of
  this the STM32F4 version now uses the standard Duet3D SBC RPi software not the version modified for the LPC.
• As with the LPC version of RRF the WiFi module and SBC is connected via the EXP1 and EXP2 headers. However it should be noted that the orientation of
  these headers is different on the STM32F4 boards which may make using existing adaptors difficult. Watch this space for news of
  STM32F4 specific boards.
• PLEASE DO NOT LEAVE ANY HARDWARE RUNNING THIS FIRMWARE UNATTENDED. This version is very new and has only received
  a small amount of testing. It may be used to control heaters and other hardware that in some situations could be dangerous. Please
  monitor operation carefully and use this firmware at your own risk.

Hello,
I have an issue withe your nodemcu preflashed. I have set the SSID and the password. The nodemcu reports "Recv: WiFi reported error: no known networks found"
I found, i have to write the ' before the letters. So it works now, but, when i power the printer, the nodemcu dont connect to the wifi.
Is the nodemcu has the old config that not worked in his memory ?
How can i save the good config ?
Can you help me ?
Thanks.

Edited 1 time(s). Last edit at 08/21/2020 02:29PM by Serge_P.

You probably used pronterface or octoprint to send the M587 command in which case, the password will have been converted to uppercase.
From the wiki...
If you are using pronteface, it will convert all text to upper case, in which case, if you wanted to use “PassWord”, you would write P”P’a’s’sW’o’r’d” with the ‘ indicating the following letter should be lower case

---

Based in Darlington, North East

Many thanks. In fact, i have send a M552 Snnn Pnnn when i have to send M587 Snnn Pnnn.
Sorry.

gloomyandy this is great news I want to thank you

How can I build this firmware from the source code?

You can't yet as it hasn't been released.
It will be, it just needs further work first

---

Based in Darlington, North East

@ghent360, can I ask why do you need to build from source? What is it you are trying to do?

Gloomyandy,
Can the Raspberry pi interface plug / ribbon cable on the BTT GTR V1.0 be used for the SBC Duetpi connection?
Is the +M5 expansion module functionality part of the project?

Thanq for the great work

@Crunch69. No the GTR ribbon cable interface is pretty useless all it has connected is power and one UART connection, we need more than that for the SBC. The M5 is not currently supported (because among other reasons I don't have one!). We are trying to get hold of an M5 for testing/development and if/when we do I'll take a look at it. But I'm pretty busy at the moment merging the LPC and STM code together and tracking DC42's latest changes ready for RRF 3.2, so the M5 will be a while.

@gloomyandy I want to port it my STM32 board.

@ghent360
The source has been released at [github.com]

RRF 3.2 beta 1 has also been released at [github.com]

---

Based in Darlington, North East

@jay_s Thank you this is excellent work. Much obliged for using regular makefiles.

@ghent360 What board/mcu are you trying to port this to?

@gloomyandy It's my design (STM32F407VE):
[github.com]

Edited 1 time(s). Last edit at 09/20/2020 08:21PM by ghent360.

@gloomyandy
Great news, Im building a corexyu machine, is there any change of the extension board becoming an option ?
I need about 10 drivers, and already have the gtr with ext board...

The M5 board is supported as of 3.2 Beta 2, allowing up to 11 drivers to be used.

---

Based in Darlington, North East

Cant wait for the new control board and possibly running RepRap firmware from BTT check out the 400MHZ SKR SE BX It will first come out on their new printer with a 7 inch TFT. The new board appears to have all the features of the Duet3 and more including High speed bus to raspberry pi built in, CAN-bus, closed loop steppers. [www.bigtree-tech.com]

Is there any chance this would work on Mingda's STM32F4 board in their D2 and D3 models? Is there any risk of frying things if I flash this for testing? I know to keep my finger on the power switch.

Safest route would be to replace the control board with a BTT board they are inexpensive.

@DeltaDroid I'd say there is very little chance it will work and a small but real chance you will damage something. I really wouldn't advise just flashing the firmware.

That's what I thought, because we don't know what pins are registered to what address, unless they just cloned another common board. Thanks @gloomandy, I'll just replace it with a SKR Pro 1.2.

I just wanted to express my thanks to gloomyandy and everybody else involved in this port. I'm turning my Robo3D R1+ into a testbed for upgrades and experimentation, the first of which was to replace its 8-bit Arduino/RAMPS control board with a BTT SKR Pro v1.2. (I wanted six steppers so that I could independently control both of the printer's two Z-axis motors and eventually upgrade the printer to support two extruders.) At this point it's working pretty well; it's done several successful prints, and it's doing things like physically auto-leveling the X-axis gantry that Robo3D's Marlin firmware couldn't do. On the off chance that anybody wants to use this board in a Robo3D R1+ printer, here's my design for a mounting adapter to get the two to fit together.

I have been having one problem, though: G-code command output is sometimes lost. This is mostly a problem with the BTT TFT35-E3 LCD I'm using with the printer; attempts to begin a print from the SKR Pro's micro-SD card using the TFT35-E3 usually fail with a hung LCD because it's waiting for a file list that never comes. This happens with the stock TFT35-E3 firmware and with both the bcmob and JimmymaDdness forks of that firmware. When I use the LCD's built-in console to type "M20", it usually just hangs. On rare occasion (maybe 1 in 10 tries), I can get a file list, but the one time I tried to start a print, it failed. I originally thought this was a failing of the screen, but then I began noticing that commands sometimes display no results using the Web interface, too. I was trying out the new PID tuning feature last night, for instance, and it never produced any output for me, although I saw the temperature rise and fall repeatedly in the display, and typing "M500" produced a change to config-override.g with new M307 values. I also saw the output on a second computer's Web browser, which was simultaneously connected to the printer. (Two simultaneous Web sessions.) Thus, I suspect that g-code return data are getting lost somewhere internal to RepRapFirmware, or are being directed to the wrong output. I haven't had these problems with another printer with a genuine Duet 2 WiFi, so I suspect this may be specific to this fork of RepRapFirmware, although it's also possible that I just haven't noticed it on the Duet. Any clues about what's going on?

Edited 1 time(s). Last edit at 11/22/2020 09:19PM by srs5694.

@srs5694 Firstly please if you can use the discord server for discussions like this. I only check this forum now and again so you will get faster responses over there.

Without knowing what versions of things you are running it is hard to be sure what is going on. I would be surprised if there is a general problem with responses. I have seen no problems when using a PanelDue to list files etc. I've just tested that configuration on beta3 with a GTR and that seems to work fine. It sounds more like an issue with the way that the TFT is talking to RRF. I don't have a TFT and so have no direct experience of using one, sorry, but there are a number of people using them and I have not seen this problem reported by any of them (but they may not be using the same hardware/firmware version as you so it is hard to say).

Have you tried the tuning thing on the Duet with two browser sessions active (using the same version of the firmware). I have been running a lot of tuning tests and have always seen correct responses. I'm not sure if using the tuning tests is a good as idea as a) This code is very new (and still experimental) b) It sort of runs the test in the background and so messages produced by it may get routed in a different way to the responses to more normal commands. You may be better off using something like m20 or m122 to test things.

I know this thread is 2 years old but has anyone done a successful port to the STM32F407 as found in the BTT002 board?

That board only has 512kb of flash so the firmware won't fit

---

Based in Darlington, North East