Hi @Sineos,
Firstly thank you for the clear instructions and tips! I just wanted to clarify however, is this an approach you can use for flashing a custom firmware onto the SKR V1.4 or is it exclusively for flashing Klipper firmware?
Looking forward to your response.
Cheers.
I might be able to offer a better answer if you conveyed what you are trying to do. So, as general remarks:
What I am essentially trying to do is upload my own firmware onto the SKR V1.4 board that executes basic stepper motor commands. I’m trying to advance basic microcontrollers such as a regular Arduino UNO, considering the SKR board allows you to control a number of steppers at a time through its in built driver connections and has superb processing speed and peripherals at the user’s disposal. I do not require all the features of a 3D printer in what I’m trying to execute so I was wondering if it is possible to still use the board but with a customised firmware I have coded (a custom python script for example) that is purely used for driving stepper motors, rather than having to use and customise existing Marline firmware which would be more cumbersome and overkill for what I’m trying to do. Hope that makes sense.
I have moved this discussion into its own topic.
You are opening a very wide field here, and probably, I’m not the right authority for a fully comprehensive answer - I’m just a user. My basic understanding:
firmware.bin file from the SD card and flash it.Thank you very much for clarifying all this, really helpful to someone who is a newbie in this space. Very true, starting with what already works and has been developed such as the Klipper firmware would be the most reasonable first approach so will give that a go.
Hi, I was wondering if you know whether it is possible to get a MANTA M5P Board into DFU mode for accessing the flash memory and flashing firmware onto the STM32 mcu via an application like STTM32CubeProgrammer without having a CB1 or CM4 board connected. I have been trying to plug my board straight into my Windows PC via the usb connection and do not get any response from my PC after putting the board into DFU mode as per the manual and plugging the board. I suspect I might need specific drivers to pick up the device when in DFU mode and I thought if I had downloaded STM32CubeProgrammer it may recognise the board via the USB port. This is a completely new board so confident the board is not damaged. Would be good to know if something like this without having the CB1/CM4 installed on the board is possible and whether you knew of any particular drivers needed as a prerequisite for recognising the board.
No. The USB Hub built into the board must have an active upstream device wired to it - this is the CB1 or CM4 plugged into the two 100 pin sockets with an SD Card imaged with an operating system.
You can program the STM32G0B1 built into the board using an ST-Link running STM32CubeProgrammer (or STM32CubeIDE) and you may be able to get a serial connection to the MCU but you can’t get a USB connection to an external device because of the Hub issue I noted above.
Right I see then that makes sense because it just would not recognise my board no matter what drivers I installed in my PC. Thanks for clarifying, I will have to see how using an ST-Link goes.
Cheers.
Hi @mykepredko, I suspect I am very close, although, I have just ran into a wall trying to connect the ST-Link to my MANTA Board. I can’t actually find any dedicated RESET pin to connect to the Reset pin of the ST LINK and for that reason I was getting errors such as “Error: Problem occurred while trying to connect”, “UR Connection mode is defined with the HWrst reset mode” and “ST-LINK error (DEV_US_COMM_ERR).” when trying to access the flash memory and flash firmware via STM32CubeProgrammer. When I had a look at the pinouts for the STM32G0B1RET6 mcu on STM32CubeIDE, I saw that Pin 7, VREF, actually refers to a RESET State, although, I can’t seem to identify where this pin is located on the M5P Board. Would you have any idea where this pin is or how to bypass this reset connection to get ST-Link flashing working? I feel like I am very close and hope this could work.
You need to connect to the “J18” connector on your board:
The wiring I use for my ST-Link 2 looks like:
The white painted pin is Pin1.
As for the ST-Link 2 connector:
Pin connections are:
Function ST-Link 2 Pin J18 Pin
+3V3 1 1
SWDIO 7 2
GND 8 3
SWCLK 9 4
RESET 15 5
Then you can use STMCubeIDE or STMCubeProgrammer as required.
Thanks so much for the clear explanation! However, when I was looking at the pin out diagram for the MANTA M5P Board, I could not find any J18 Connector? Is it supposed to be literally called “J18”?
I don’t have an MP-5 but:
When you find something that looks likely (ie the 5 pin header I highlighted above) then beep it out with a DMM to make sure that the pins match what you expect.
Wow turning the board and looking at its backside really helps doesn’t it hahaha. Thanks so much honestly I have found the pins by looking at the labels at the backside and it is indeed the 5 pin header you marked. I appreciate this very much and will hopefully get this working!
Just a heads up @mykepredko, I finally got it to work!!!
Thank you so much for your guidance and insight, I really appreciate it and thank you for helping a fellow developer get through a major setback. So now anyone who is trying to repurpose their MANTA board for applications other than 3D printing will know its definitely possible.
Cheers!
Hi @mykepredko, I was wondering, if I wanted to basically control only one stepper motor on the x-axis for now by flashing custom STM32Cube IDE firmware on the MANTA M5P board using a TMC2209 Stepper driver via UART mode, do you reckon it is plausible to just use half duplex UART communication between the CS pin for each driver and the TMC2209? My current driver from BTT has a separate TX and RX pin for UART rather than a single PDN_UART pin that some drivers have. I had a look online and apparently the TMC2209 communicates best with the STM32 MCU via half duplex. So then would that mean that as per the schematic, I would configure PD9 on STM32CubeIDE to be the single STM32 USART_TX Pin and then does it become a RX pin when the tmc wants to write back to the STM? Although, I was not actually able to set PD9 a USART_TX pin initially and only gave me the option to set it as a USART_RX pin. Does this affect initial communication to the TMC Driver as the UART communication would need to begin with the firmware sending a command to the tmc driver via the mcu or should it not matter? I was thinking then I could just use PD8 as the tx and PD9 as rx for the x axis and just use a full duplex config, although, doesn’t this become problematic when I want to drive multiple axis simultaneously since the CS pin for UART to the y driver is PD8 and therefore it would override the Y axis UART line and so on? I was also wondering, does the board somehow actually connect the TX and RX pin together to make them into a single pin (as if it were a PDN_UART) pin on the driver? I found through my initial research that a 1Kohm resistor should be added between the STM32 Pin and the TMC2209 TX line to keep the line idle high when no one is driving and safely allow for half duplex communication. If these things can be clarified from you experience controlling steppers via UART with these boards that would be awesome.
This is a really difficult to parse paragraph and, in the future, could you break up things up into paragraphs with separate topics?
What I think you’re asking is, can you use one pin for serial communications with TMC stepper driver chips and the answer is yes. From my perspective, that’s the better way of doing things.
Now, stepper driver modules often have the ability to have one or two pins set by a 0Ω resistors on it’s PCB. From what I’ve seen, the 0Ω resistors are normally set so that the RX/TX pins on the TMC driver chip are routed to one pin on the module.
Let me know if that answers your questions. I feel like you’re asking more here but I need you to break things out into separate topics.
My apologies @mykepredko will ensure to break things up better next time.
So essentially you have clarified that you can use one pin for serial communication with the TMC, although, was also wondering whether it mattered if this mcu pin was configured to be a transmitter or receiver? I was wondering this since the CS Pin for the X Driver (PD9) could only be set to USART_RX pin on STM32CubeIDE. So would it affect initial sending of the signals to the driver?
However, I was able to select the CS Pin for the Y axis as a TX Pin , but I was concerned that this would override the Y axis UART line when I come to running multiple motors.
Thanks also for clarifying that RX/TX pins on the TMC are routed to one pin of the module, meaning half duplex UART communication is actually more ideal? Does this basically mean the driver’s RX signal is activated when the mcu sends a command and then it switches to the TX pin when the driver sends the response back?
Cheers for the support.
The use of “UART” in the Trinamic datasheets is in error. The “datagram” sent from the MCU to the TMC#### consists of 64bit serial data bits for a Write and is 32bits for a read request which causes the TMC#### to reply with a 64bit datagram. There are no Start/Stop bits for each byte the way you would expect with traditional NRZ serial communications - the Start information is in the first four bits of each datagram.
I would be very surprised if the STM32 USART could generate the required datagrams and read the replies.
When I set up communications for my product, I did it the same way as is done in Klipper, using a simple bit-banging approach. This means that you can use any IO pin capable of Digital Inputs/Digital Outputs you want - you will be using basic GPIO functionality, NOT UART/USART.
Wow that is interesting considering the MANTA Board has dedicated instructions and configuration for UART Driver communication in the manual. I’m going to move on to SPI control with a TMC5160T Pro Driver in that case, as I want to eventually make use of sensorless homing functionalities the driver offers when using SPI.
For now though, I went on to compile a basic stepper rotation firmware on STM32CubeIDE using basic step and direction commands by configuring the STEP, DIR and ENABLE pins of the manta board’s mcu as GPIO_OUTPUTS. I managed to successfully flash the firmware again using the ST LINK on STMCubeProgrammer and the motor rotated as expected. I made sure to configure the jumpers as laid out in the manual as such and used the TMC2209 Driver:
When I tried using this basic approach for TMC5160 Pro, nothing was working despite using the exact same setup, firmware and power. I tried using 2 of my TMC5160 Drivers I only recently purchased and never used. So now Im left wondering if the TMC5160 Pro are even capable of being driven using basic STEP AND DIRECTION commands? I was under the impression that they are able to be used for this basic approach and also SPI.
I just wanted to clarify this to check if the drivers are faulty or not before testing them with an SPI based firmware and being driven mad if the issues I shall face end up being because of faulty drivers.
Did you read the TMC5160 datasheet?
You can have basic control over the chip but there are a number of pins that must be set appropriately (more than on other TMC chips). From the datasheet:
You’re going to have to go through your module schematics and try to figure out if you can set the SD_MODE, SPI_MODE and the CFG0 to CFG6 pins for the parameters you want the chip to run in. If I were doing this, I’d look at the voltage level at the SPI_MODE pin first to see if it’s possible to even get into “standalone driver” mode.
I would recommend keeping with the “STEP/DIR application” mode which your module is probably wired as:
And configure the chip for STEP/DIR operation.
Good luck!
