I got it from this and no I don’t speak German which would be awful helpful during this watch.
#90 - Flash Guide - Manta M8P, M5P & M4P (USB) (youtube.com)
I got it from this and no I don’t speak German which would be awful helpful during this watch.
#90 - Flash Guide - Manta M8P, M5P & M4P (USB) (youtube.com)
I don’t speak German either.
I just spent a couple of minutes on the video and I think I understand what he’s doing but I wouldn’t rely on what I got out of it.
Again, could you go through your process and show what you get in response to each step?
Yes, but it seemed to be yet another dead end.
I put it into DFU mode using the boot0 and reset buttons.
I need to step away from my computer for a bit, but I’ll flash the CB1 and go through those steps again making a log as I go.
I’m asking you to go through the process and show me the responses so I can see if you’re going in the wrong direction somewhere or something is going awry.
This is supposed to be an alternative to ls /dev/serial/by-id/* that some folks have had luck pulling the ID when the regular method isn’t working.
make clean
make menuconfig - entered the info for my M8P v2.0
make
dfu-util -a 0 -d 0483:df11 --dfuse-address 0x08002000 -D out/klipper.bin
#Received the “File downloaded successfully” message
dmesg -HW
#Looked through the list for my serial-id but no luck. I need to get to bed, but I’m going to battle with this again tomorrow. I really appreciate the help!
If we’re going to figure out what’s wrong, you really need to be a lot more explicit and provide complete information.
For example, how are you putting the Manta V2.0 into DFU mode? How are you checking to see that it is in that mode?
Along with that, how are you verifying that the new firmware is actually loaded into the board?
I’ve got a Manta M8P V2.0 around here somewhere and I’ll go through the process as well but you are going to need to be a lot more detailed in your replies.
I’m not sure which information you need. I can’t get my boards ID for mcu. Over the past four days I’ve searched for every fix I can find and none of them have worked. If you want, I can start from scratch and go through the initial process and let you know what is happening, but I posted all of that earlier in this thread including logs. Let me know if anything is missing and I’ll gladly provide it.
The only way I know how to put it into DFU mode is by pressing the holding the boot button, pressing and releasing the reset button and then releasing the boot button.
The only way that I know of to verify if the firmware is loaded onto the board is to put the SD card back in my PC and see if the firmware.bin has changed to firmware.cur. Unfortunately the board stopped updating the firmware through the SD card route.
I used the command line method to flash the firmware, and it went through the process stating “file downloaded successfully” at the end, which I believe indicates it flashed correctly. Unfortunately the fact the board isn’t working would indicate otherwise. I’m also completely new to the CB1, M8P and know enough Linux to realize I need to learn a lot more.
ISSUE RESOLVED!!!
There is an issue with menuconfig, I was entering everything as shown by Bigtreetech but found a thread where someone said their info is wrong.
Bootloader offset is supposed to be “128KiB bootloader” according to the BTT information, however if SERIAL ID isn’t showing up the bootloader setting should be turned off. I changed that one setting and now my CB1 is happily talking to my M8P.
I also saved that ID in case it goes haywire on me again.
Glad to hear that you found your problem.
I’m looking forward to seeing what you print.
I’ll still go through the process my self in the morning and put up any comments here.
I probably have 30hrs into trying to get this thing to work and it was as simple as unchecking a box.
My other Raspberry Pi’s are running a GUI interface so I had virtually no command line experience until this week. I first learned how to use a computer back in the days of DOS which really screwed me up at first because I kept trying to use DOS commands.
The good news is I went from a complete Linux noob to being able to do a lot of things. I’m really going to dig into Linux and try to improve my new moderate Linux skills from knowing enough to screw everything up to knowing enough to fix what I screw up.
Thanks for the assist everyone.
This seems to be a strange solution. It rather sounds like that either:
Generally, it makes sense that flashing a board with a Bootloader offset
, but without correctly working bootloader is not going to fly. The “startup sequence” is:
The correct offsets and make
settings are ensuring that this process can jump from 1. to 2. to 3.
Now, if 2. is missing / defect the board is stuck.
Probably the preferred solution would be to either:
I’m sure you are correct, because this all started right after I had initially flashed the bootloader.
For now I’m just happy it’s working even if with an odd fix. Will leaving that setting the way I have it cause issues in the future?
I will give that a try sometime this week and let you know how it works out.
I will try the original bootloader and if that puts me where I was before I will reflash the firmware with the bootloader option off. I will then flash Katapult and see what that does.
For running the board it will have no impact.
The definitive drawback is that you have to manually put the board into the DFU bootloader mode to flash / update Klipper and you have to remember that you cannot follow the “official” settings for the board.
With a working bootloader, Klipper is able to put the board into the programming mode with a software call. This is what the command make flash FLASH_DEVICE=...
is doing. This means you can flash / update the board without physically accessing the board.
Here’s my process:
Get CB2 OS Image/V1.05 - I get the “Minimal” from here:
Releases · bigtreetech/CB2 · GitHub
Using Raspberry Pi Imager running on a Windows 11 PC, I set Raspberry Pi Device “NO FILTERING”/Operating System “CB2_DEBIAN11_MINIMAL_KERNEL4.19.2_20240619.img.xz”/No “OS customization settings” and load a 128GB Micro SD Card with it.
While the SD Card is loading, I attach the WiFi antenna to the CB2 and install the CB2 into the Manta M8P V2.0. I also open up the Manta M8P V2.0 user manual as a reference.
I added the VUSB jumper to the Manta M8P V2.0 board as I’m only doing a setup and not running it off of a bulk power supply. I make no other changes to the board.
When the SD Card Imaging is complete, I remove the SD Card and then plug it back in. Using NotePad++, I then go to File Explorer for the SD Card’s root folder and open system.cfg
in Notepad++.
In Notepad++, I make the following changes:
a) I set my hostname. This is done by uncommenting the line and putting in a unique name for me. I don’t know why this isn’t explained in the BTT documentation - it makes things a lot easier.
b) I set my WiFi SSID (Name)
c) I set my WiFi Password
Save the updated system.cfg
, close the Notepad++ tab and pull the SD Card from the PC.
Insert the SD Card into the “SOC Card” slot in the Manta M8P V2.
Using a Raspberry Pi Power Supply, plug in the Manta M8P V2 and wait a couple of minutes.
Login to the CB2 using SSH (I do it from the Windows 11 terminal) as “root” with password “root”. Then follow the prompts to create a userID with passworld. I use “biqu” simply because the CB1 uses it as default:
You will need to logout
as “root” and then login again as “biqu”
I make sure everything is at the latest level and I install git using the command:
sudo apt-get update && sudo apt-get install git -y
git clone https://github.com/dw-0/kiauh.git
./kiauh/kiauh.sh
Then install Klipper
, Moonraker
and Mainsail
followed by doing the system updates. This takes about twenty minutes. When you’re done, exit out of KIAUH.
NOTE: As I did the install today, I was given the option to try an all new version of KIAUH - it seems to be significantly faster than the older version.
With Klipper
, Moonraker
and Mainsail
installed and updates done, I then make sure the Mainsail web page comes up (using the CB2 network name, in my case it’s http://cb2-m8p-v2/
). There will be an error saying that you can’t connect to the ‘mcu’ but this is okay as we’re just looking for the webpage at this time.
From the SSH, terminal, go to the klipper
folder using the command cd ~/klipper
.
Execute make menuconfig
and, as you found, mostly use the settings in the user manual (you should be specifying No bootloader
if you have going to use DFU). The user manual instructions are a) skimpy and b) incorrect when it comes to DFU.
“Q” out of make menuconfig
and “save configuration”. Then execute make clean
and then make
to build the Klipper firmware. Make sure it completes successfully and creates the hex file:
Put the Manta M8P into DFU Mode by pressing the “BOOT0” button and holding it, then press and release “RESET” and then reelease “BOOT0” (The spacing of the buttons isn’t great for anybody with adult fingers).
Check to see that the Manta M8P V2 is in DFU mode using the lsusb
command. I’m not sure where the idea for using dmesg
comes from - it spews out a lot of information and is difficult to wade through:
Burn the Klipper firmware using the basic DFU Command (Note that you will get the message “dfu-util: Error during download get_status”):
sudo dfu-util -a 0 -D ~/klipper/out/klipper.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11
Execute lsusb
again, and you should see that Klipper is installed by the “OpenMoko” device:
Now when you execute `ls /dev/serial/by-id/*" you will get your Klipper ID:
Add it into your printer.cfg
. The one below is a pretty minimal one but note that I am tracking the MCU and CB2 temperatures - This gives me a good proof of life. Along with that, I also use the “STATUS”/“STATE” LED built into a main controller board as a way to see that things are working - when you add the LED, you get a nice slider on the main page (just note that in the Manta M8P V2, the LED is wired so the higher the value, the dimmer the LED is).
[include mainsail.cfg]
[virtual_sdcard]
path: /home/biqu/printer_data/gcodes
on_error_gcode: CANCEL_PRINT
[mcu]
serial: /dev/serial/by-id/usb-Klipper_stm32h723xx_330034000651313433343333-if00
[temperature_sensor mcu_temp]
sensor_type: temperature_mcu
[temperature_sensor cb2]
sensor_type: temperature_host
min_temp: 10
max_temp: 100
[printer]
kinematics: none
max_velocity: 300
max_accel: 3000
[led state]
red_pin: PC3
#green_pin:
#blue_pin:
#white_pin:
# The pin controlling the given LED color. At least one of the above
# parameters must be provided.
cycle_time: 0.010
# The amount of time (in seconds) per PWM cycle. It is recommended
# this be 10 milliseconds or greater when using software based PWM.
# The default is 0.010 seconds.
hardware_pwm: False
# Enable this to use hardware PWM instead of software PWM. When
# using hardware PWM the actual cycle time is constrained by the
# implementation and may be significantly different than the
# requested cycle_time. The default is False.
initial_RED: 0.95
#initial_GREEN: 0.00
#initial_BLUE: 0.0
#initial_WHITE: 0.0
# Sets the initial LED color. Each value should be between 0.0 and
# 1.0. The default for each color is 0.
This should probably go in a new thread.
I think the tide is turning toward only using DFU when working with Klipper.
It’s easier and cheaper for board manufacturers to eliminate the SD Card and flashed bootloader and, it’s easier for users to Flash Klipper using DFU.
When I look at BTT’s instructions for the CB2 (or CB1) and the Manta M8P V2 (or any other flavour) they’re generally a mess with a number of errors as @burkej27 found through this process.
The process I went through was successful for me on the first attempt because I’ve gone through it dozens of times and I now know the things to watch out for and I expect to trash the manufacturer supplied bootloader.
The real problem is that things are still a moving target, software is changing continuously and, for the most part, it’s getting better but it’s changing and instructions written on day one will not necessarily be right for day two.
This is compounded by the preferences people put in to the processes they publish. If you go through my process for @burkej27 you’ll see that I eschew the use of dmesg
for verifying that the MCU is in DFU mode and I use the basic dfu-util
command rather than make flash
. I also avoid host images that include Klipper in them - I’ve found that they tend to be downlevel and configured according to what somebody thinks is best, not what I want. In all three cases, I’ve found that things work best for me when I stick with the more basic commands that explicitly spell out what is being done.
So, if you were to ask me what would be one of the things that would make Klipper more mainstream/user friendly, is a consistent flashing process that works across multiple boards and hosts.
I don’t think it needs to be simple (the process I just published is almost thirty steps) but it needs to be consistent.
Since I have my boards ID I will start all over and reflash to see if I can get it to work with that bootloader setting on.
If it works then this might be a viable solution for others having the issue with the /dev/serial/by-id/ not providing the data.
Flash with the CB1 with bootloader off.
Flash M8P
Get the ID AND SAVE THE FREAKING THING SOMEWHERE!!!
Flash the M8P again with bootloader on.
It worked. I reflashed it with the bootloader setting on and the boards are communicating.
I am putting this here in case anyone else comes looking for a solution.
For m8p v2.0
If you run ls /dev/serial/by-id/*
and get this Error:
ls /dev/serial/by-id/ No such file or directory
The fix that worked for me.
cd klipper
make clear
make menuconfig
make
make flash FLASH_DEVICE=0483:df11
reboot
ls /dev/serial/by-id/*
You should now receive the id.
SAVE THIS ID SOMEWHERE ELSE
I made a text file where all of my serial IDs will not live. Lets just call this lesson freaking learned!
Put the following either in printer.cfg or if you are using the bigtreetech config file put it in there, for example mine is named generic-bigtreetech-manta-m8p-V2_0.cfg.
[mcu]
serial: /dev/serial/by-id/your board id
Mine looks like this:
[mcu]
serial: /dev/serial/by-id/usb-Klipper_stm32h723xx_3E0034001751313434373135-if00
If you are using the bigtreetech configuration file you need to reference it in printer.cfg with:
[include generic-bigtreetech-manta-m8p-V2_0.cfg]
You can also simply copy/paste the contents of the bigtreetech config file directly into your printer.cfg instead of having two separate config files.
save
reboot
At this point the dashboard should load which means everything is working. Sineos advised me that I should keep the bootloader setting on so I went back in and repeated the flashing process adding the bootloader setting back.
cd klipper
make clear
make menuconfig
make
make flash FLASH_DEVICE=0483:df11
reboot
Everything SHOULD still work.
I’m no expert, not even in the ballpark, hell I should probably spellcheck the word expert when I type it.
This is a combination of solutions that I found on the internet including recommendations from the folks in this thread. Who I hope will proofread this solution for me to make sure that others will not run into any issues in case I forgot a step.
Glad to hear that things are working.
In your previous post I noticed:
Get the ID AND SAVE THE FREAKING THING SOMEWHERE!!!
That’s step 26. above. I guess it’s automatic for me because I used to forget it or put it down on a slip of paper - it’s easiest just to put it in the printer.cfg
and then, when things are communicating, download printer.cfg
and save it on Dropbox or in your email.
Oh it’s automatic for me too now!!!