Hey @mykepredko, so I’ve just moved onto setting up the CM5 with the MANTA M5P board now after trying to implement the stall guard and debugging with the ST Link on the CubeIDE’s debugger. I thought if I can get visibility of the serial port that becomes activated once hooking up the Pi it would make trouble shooting easier and was meaning to get to this stage anyways.
Essentially, I’ve managed to connect to my CM5 using Pi connect and have been successfully dialing into the Linux OS and have plugged in my CM5 in the dedicated slot and have powered it and written the OS image to the eMMC as instructed in the manual which has gone all fine.
Now the issue I’m running into now is actually getting a basic python script that sends LED blink commands as a string to reach the STM32 mcu on the MANTA board. The idea is I’d be able to send a string that commands an LED hooked up to the MANTA board to blink x amount of times by sending over UART and getting the stm32 to receive this string over UART and parse it to execute and it sends back the received message back to the pi as an echo to verify the two way communication works. However, I’ve tried actually physically wiring GPIOS 14 and 15 as the TX and RX for the CM5 to the TX AND RX pins I configured in the cubeide and have set up the serial port for this UART communication to be /dev/ttyAMA0.
However, I suspect this is just wrong as no tutorial I have come across has ever needed to physically wire any tx and rx pins between the Pi and chip. I always see that when setting up Klipper, it appears that they always run /dev/serial/by-id/ in the Pi terminal which gives them something along the lines of serial: /dev/serial/by-id/usb-MySTM32_CDC-if00-port0. Im a little confused what this refers to and how the cm4/5 actually would internally communicate to the mcu in the board without having physical connections.
Essentially, I’m just trying to replicate how kippers achieves that connection with the CM4/5 so eventually I can run motors and sensorless homing from commands I send from an application I run on the Pi.
Okay, I’m literally doing what you’re trying to do with my custom board. It has a CM4 that plugs into it and can communicate with the MCU on the board via the same USB connection as the Manta M5P. In my application, I’m working on producing a functional test - this means I have to access IO features on the main controller board, including the stepper controllers and various other pieces of hardware.
In my case, I’m loading Klipper onto the board’s MCU (no custom firmware) and then accessing the board hardware from a Bash script. For example, to check the status of the board, I use the code:
TTY=~/printer_data/comms/klippy.serial
echo -ne "STATUS\n" > "$TTY"
RESPONSE=$(timeout 2 cat "$TTY") || true
if echo "$RESPONSE" | grep -q "Klipper state: Ready"; then
echo -e "Klipper is running!"
else
echo -e "No Klipper Available"
fi
The “echo -ne…” statement sends a “STATUS” request to Klipper and then returns the response over the next two seconds.
You can access all the features of Klipper and if there are some you can’t, then look to Dynamic Macros and the conversation I had about them with @3dcoded (Read ACCELEROMETER_QUERY response in macro).
If you’re going to be using the basic 3D Printer features of your Manta M5P you might as well install Klipper and access them rather than trying to create your own.
Right I see, really cool stuff you are working on! I will definitely read through the conversation you linked and seeing if I can implement any Dynamic Macros of my own.
I did want to clarify however, when you say the CM4 communicates with the MCU in the board via the same USB connection, which USB connection are you referring to? For the case of the M5P, is it this the route from the USB connection that is used for USB power? I think I’m just having trouble understanding the usb communication between the cm4 and mcu. I understand that the usb/serial communication becomes active when plugging in and setting up the CM4, but how does that look like on the board? The schematics I found in the manual by BTT were just not that clear Any bit more insight and explanation of this would be much appreciated.
When you plug the CM5 into the Manta M5P, there will be a USB connection between the two boards - the two 100 pin connectors that attach the CM5 to the Manta M5P have USB connections to link the CM5 to the MCU on the Manta M5P.
Ok I see, I honestly could not find any documentation saying this so was super confused.
Based on the Klipper configuration and M5P manual, I see that pins PA11 AND PA12 are always used for setting up the USB communication interface with the MCU. So these would be the two pins I believe I would need to configure for USB communication with the Pi in my custom firmware?
When I tried finding out the serial port connected to the micro-controller by running: ls /dev/serial/by-id/*, I just kept getting an error saying no file or directory found rather than reporting something along the lines of: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0.
How else would I set up the serial port for communicating between the CM5 and MCU if I cannot even find which port connects them? Like I was wondering does Klipper set something up or should my board be configured in a particular way to enable finding the serial port from this command? I’m honestly very confused and trying to mimic how Klipper achieves this. All I would like to do is set up USB communication interface on PA11/PA12 to be able to send the commands from the application ran by the Pi to the mcu for controlling motors.
Please bear with these simple questions as I’m very new to this space and type of hardware.
You would have to locate a couple of MCU USART pins that you can wire to pins 2 & 4 of the Raspberry Pi 40 Pin connector.
I just took a look at the Manta M5P schematic and the STM32G0B1RET6 pin mux table and I don’t see any USART RX/TX pin pairs that are easily accessible - you’re probably going to have to remove some parts on the Manta M5P to make USART pins accessible and not have unexpected interactions with other circuitry.
Again, the easiest way of making a connection between the CM5 and the Manta M5P is to use Klipper. If you require specialized functionality, then you can add it to the Klipper C code - but, from your original description of what you want to do, I think you can access the Manta M5P hardware using Bash scripts and Python.
Hmmm ok and then what about actually being able to use USB serial communication between the mcu and cm5. Like I get how when you plug the Pi in the two 100 pin connectors it allows for USB communication between the Pi and the MCU, but how does Klipper actually set it up though and is that something that could easily be replicated in a custom firmware? My understanding so far is klipper needs to first be flashed to the mcu before trying to find which usb serial port the Pi speaks to the mcu on?
I was thinking surely there is a way to use cubeide to set up and enable the mcu as a usb device that can then connect to the Pi over USB serial. This would then allow the mcu to receive string commands from an application run on the Pi host. When the MCU receives a string to move a stepper x amount, it would then do all the parsing and execution by utilising the custom firmware I’ve flashed to write to the TMC drivers registers to move the steppers and carry out sensorless homing. Does that make sense?
Read the Manta M5P “User Guide”. It’s not terribly well written but it will answer your questions and give you an idea of how Klipper firmware is built and Flashed into the Manta M5P’s MCU through the CM4/equivalent board.
Only if you want to torture yourself.
If I can make an observation; you’re going into this with the assumption that you’re going to do everything yourself and essentially write everything from scratch.
I highly suggest that you turn this around and work with the idea that Klipper has the IO interface methods that you need and work at figuring out what is the best way to access them.
In my case, it makes the most sense to put in a full Klipper install with Mainsail and access Klipper using the Bash script code like the fragment I posted above. By doing this, I can monitor what’s happening in Klipper in the Mainsail Console as well as test my macros (dynamic and othewise) from the Console before calling them from the Bash script. There is also the advantage of having the amazing people here as resources when you have a problem.
If you are looking at doing it all yourself, then you are going to be basically alone. I’m sure you can get some comments when you encounter problems from other forums as well as here but it’s not something you can count on. I, personally, have a lot of experience writing code (including for TMC2225s and USB CDC) on NXP Kinetis Cortex MCUs and can give some general advice but I’m not very familiar with STM32 MCUs - yes, there’s both Cortex processor architectures but the peripherals are completely different so I can only offer general advice.
In the end it’s up to you but, at least study, how Klipper is built and installed in the Manta M5P as well as its capabilities before making the decision to go completely you’re own way.
Thanks for this honest response. I actually had a look at the main architecture of Klipper over yesterday to see it a little more from your perspective and can definitely see where you are coming from. See I just did not realise that it comprises of a host software loaded onto the SBC like a CM5 and then a separate firmware on the MCU, which have been pre programmed to communicate to one another using a shared binary protocol.
See my concern initially with using Klipper would have been Intellectual Property for what I’m working on developing. But when I was looking a little more into Klipper, I realised that it may be able to host a proprietary application that compiled using Python lets say. I had a look and actually found that I would be able to leverage Python’s import request module to essentially translate UI activity into executable commands by Klipper host software. I believe this would be feasible since the requests module allows you to send HTTP requests using Python. So in syaing that, this could be used as the application I interface with Moonraker to translate UI actions into actionable Klipper commands and can replace the more common interfaces such as FluidPi and Mainsail. Do you reckon this is feasible?
So if I go with this route, do you reckon this still guarantees my application is fully covered by IP even though Im using an open source host software and MCU firmware?
That sounds like a good plan and there’s a number of people here that you can use for support.
If you’re creating your own application that interfaces with the hardware through Moonraker then you can keep your application proprietary. If you make any modifications to Moonraker, Klipper Host Software or Klipper MCU Firmware, you do have to publish those changes.
Sounds like you’re getting a plan together - I am looking forward to seeing what you come up with!
Hi @mykepredko, so essentially I have began the process of installing Klipper on my MANTA M5P Board via the KIAUH installer. I have ran into my first issue when I tried to flash the Klipper.bin firmware onto the MCU.
The issue that I have encountered is I’m not getting any file or directory found when entering ls /dev/serial/by-id/* in the Pi terminal. So then i tried using the following programming statement to basically override a possibly faulty bootloader and still I suspect no luck:
sudo dfu-util -a 0 -D ~/klipper/out/klipper.bin --dfuse-address 0x08000000:force:mass-erase -d 0483:df11
It may have flashed all fine as I do see an invalid DFU suffix signature and error get_status, which were actually mentioned in the manual as not being a problem. Although, I could not see any explicit indication that the firmware has flashed successfully, unless it has and I’m just being paranoid?
This is the error I see when executing the programming line you mentioned:
I wonder how am I going to update the complete path when configuring the mcu in my printer.config file if I don’t have a path I can use from ls /dev/serial/by-id? I’ve managed to find the MCU ID when going to KIAUH and selecting the USB DFU Mode connection option. Could this be used to compile a path for defining the MCU then? Where would 0483:df11 go in that case?
First off, you need to be clear on what you’re doing.
You won’t get anything for ls /dev/serial/by-id until you’ve flash Klipper into the MCU on your board.
From your screenshot, it looks like you’re in DFU Mode (from the lsusb command) but things are failing when you try to program.
I’ve never seen the “LIBUSB_ERROR_TIMEOUT” and doing a Google search, I can’t find anything solid that would point to your problem; other people that have this problem usually have a bad USB cable, which isn’t an issue here.
I want you to:
Explain your set up clearly. How are you powering the system and what is the CM4 or equivalent that you’re using? Do you have anything attached to the M5P?
Explain the set up process you used for your system. Start with the OS Image you’re using for the CM4/equivalent and go through the steps that you took to get to Flashing the MCU using DFU-UTIL
Ok I would have thought ls /dev/serial/by-id would give you something even if you haven’t finished flashing Klipper into the MCU, unless its only used if you want to update the firmware after already having initially flashed it. The manual states you can do the following:
-Powering the Manta board with 24 VDC Power supply and removed USB jumper
-Using a CM5, the official Raspberry Pi version with the eMMC (not CM4). Wonder if this may need some additional special configuration enable USB serial or DFU??? I just realised that the CM5 does not enable the older USB2 interface that is used on the MANTA so without modifying the config of the CM5 Firmware, USB would not be enabled to the CM5 through the MANTA according to this github thread: Support for Raspberry CM5 ? · Issue #131 · bigtreetech/Manta-M8P · GitHub. USB in this case would be referring to the USB-SERIAL interface to the MCU that is supposed to be activated when plugging in the CM5?
-I so far only have one TMC driver and the jumpers set for SPI from last time when I tried getting SPI running with a custom firmware (Although I don’t reckon this should have any effect?)
-Started by writing the official Raspberry Pi 64 bit OS image (not the lite version) for my CM5 using the RPI imager. I also set up wireless connectivity and enabled SSH.
-Ran sudo raspi-config and set up the following:
1 System Options → S1 Wireless LAN → Follow the WIFI setup (skip for using Ethernet)
3 Interface Options → I2 SSH → Enable yes
3 Interface Options → I4 SPI → Enable yes
3 Interface Options → I5 I2C → Enable yes
6 Advanced Options → A1 Expand Filesystem
-Checked my Linux OS was the recent one and does not have the Debian Bullseye bug leading to lost MCU serials
-Disabled the unwanted Linux services that are known to interfere with Klipper’s operation
-Installed and ran KIAUH after I performed a SSH into the Pi
-Installed Klipper, Moonraker and Fluidd web-interface, after which I was able to access the web-interface from my browser when entering the Pi’s IP address.
-Downloaded the M5P configuration file and reviewed the build settings
-Entered these build settings in KIAUH when I went to build the firmware and built the Klipper.bin firmware file
-Put the board into DFU mode by holding down the BOOT Button and then pressed the RESET button and released both buttons simultaneously.
-Went to then flash the firmware to the mcu via KIAUH. Then I selected ‘Regular flashing method’, then tried both ‘make flash (default)’ and ‘make serialflash (stm32flash)’ flashing methods and then selected USB (DFU mode). The USB method said MCU not found.
-This resulted in the following flashing failed error, saying “No rule to make target ‘serialflash’”:
I have checked and it seems that the necessary USB 2.0 configuration has already been enabled in the config.txt of the OS Image on the Pi. I saw that dtoverlay=dwc2,dr_mode=host
and otg_mode=1. So I don’t know if the CM5 compatibility could still be an issue?
-I have verified that the board is being set to DFU mode as I carried out dmesg -HW and it showed my mcu as being set to DFU mode. It seems like my issue occurs during dfu-util communication, especially at get_status, where I am seeing it just hangs.
-Just an FYI, I was originally just flashing custom firmware hex files to my MCU on this board uisng the ST LINK V2 previously but I made sure to erase the mcu flash memory before attempting to flash klipper firmware. Perhaps there is a bootloader I have wiped off or something? My understanding however is that DFU flashing does not require a bootloader in the flash memory so highly doubt it is relevant here.
The section title is in error. I’m not really sure what the bootloader is that they’re referencing as the process they’re showing is typically used for Katapult.
DFU involves pressing the BOOT0 button, press followed by release the RESET button and then release the BOOT0 button. Once you’ve done that, you Flash the MCU using the DFU-UTIL command.
If you’re powering through the VIN Screw Terminals, then you don’t need the jumper.
From what I can see from your screen shots, you can access the USB2 port on the Manta M5P.
I’m not sure why you are doing all this.
Could you start your SD Card imaging again with:
Use the Raspberry Pi Imager Application on your PC
Select the 64bit Minimal OS Image
in “Edit Settings”:
– Specify your Hostname
– Set Username and Password
– Configure Wireless Lan
– Set your Locale Settings
Insert the SD Card into your Manta M5P/CM5 combination
Apply power to the Manta M5P/CM5 combination
Wait five minutes and SSH into the Manta M5P/CM5 combination
Go to ~/klipper and do a make menuconfig and post a screen shot of how you are configuring your Manta M5P MCU
Execute make clean followed by make
Put the Manta M5P into DFU Mode by pressing the BOOT0 button, press followed by release the RESET button and then release the BOOT0 button. Once you’ve done that, you Flash the MCU using the DFU-UTIL command
Check for a USB device with the address 0483:df11 using lsusb
If the 0483:df11 device shows up, try Flashing your firmware into the Manta M5P using the command: sudo dfu-util -a 0 -D ~/klipper/out/klipper.bin --dfuse-address 0x08000000:force:mass-erase - d 0483:df11
That’s it. Don’t do anything else. Don’t go into raspi-config, don’t make any changes to the CM5’s OS image.
When you’ve done that, report your results.
If things don’t work, don’t go and try to figure out the problem yourself, just report your results as completely as you can.
Thanks for the detailed response. I had set up the rasp config the way I did as I was following a guide posted in another thread on this forum and it was instructed to do so.
Ive actually done everything the way you have said except I’m writing the OS image directly onto the eMMC memory of the Pi and don’t think I need to go via an SD card? Or is SD card still a good precautionary measure to take even if the CM Pi has the eMMC?
I can try again with the SD card and see how it goes just don’t reckon that’s going to make a difference unfortunately.
The purpose of the eMMC on the versions of the CM4/CM5 (and, there are some others) is to provide the fastest possible file storage on the SBCs.
This means that you can boot from them and use them as your primary storage - from what you’ve written, it sounds like you set it up with the OS.
Now, if you set the eMMC with OS so the CM5 to boot from it and then used the SD Card for other storage or visa versa then that could be the reason why you’re having problems with DFU-UTIL - the application is run from one but needs resources from the other that it can’t find.
This is why I was explicit in my instructions to you to only boot and run from the SD Card.
