MCU 'mcu' configured for 64Mhz but running at 63Mhz!

Basic Information:

Printer Model: ANET ET5 with new board
MCU / Printerboard:M8P + CB1 V2
Host / SBC
klippy.log

“MCU ‘mcu’ configured for 64Mhz but running at 63Mhz!”
I had that message on the Bell after he stopped printing because of a timing error.
Well the message shows what it is but how can I fix that?

thx in advance

The first thing would be to provide all the requested information - please reply with your klippy.log.

Next, you need to list the parameters you used for make menuconfig.

With this informatio, we can probably suss out what the problem is.

2 Likes

Hi, klippy.log should be available HERE

I didn´t use any “make menuconfig”. I just installed the image for the CB1 from the btt site and followed the tutorial steps.

Please drag and drop your files onto the edit window as that will attach them to the post rather than requiring you to find somewhere to place them. Much more convenient for everybody.

As for the make menuconfig, that should have been presented to you in the Manta M8P User Manual, page 36:

Did you follow these steps?

How did you burn the firmware image onto the board itself?

Please provide as much information as possible - nobody here is a genuine psychic. Clearly explaining the steps you took along with the resources you used. Include any observations you made of things that may have seemed out of place.

2 Likes

How do you know that you’re running at “63Mhz”?

When I look at your klippy.log, I see the line:

MCU 'CB1' config: ADC_MAX=4095 CLOCK_FREQ=50000000 MCU=linux PCA9685_MAX=4096 PWM_MAX=32768 STATS_SUMSQ_BASE=256

Which means that the MCU is running at 50MHz.

I’m also confused about how you are connecting the CB1 to the Manta M8P - according to your klippy.log, you’re connecting with the ID:

[mcu]
serial = /dev/serial/by-id/usb-Klipper_stm32g0b1xx_m8p-if00

When it should look something like (this was taken from one of my printers):

[mcu]
serial = /dev/serial/by-id/usb-Klipper_stm32g0b1xx_42004D000C504B5735313920-if00

As noted in the User Manual, Page 37:

Again, please provide as much information as possible so this can be resolved quickly and with a minimum of pain.

Hi, I used the precompiled Image using RasPi Imager.
All I had to do was the “ls /dev/serial/by-id/” move to get the mcu serial.
And it works. I had only one time a crash or error with a shutdown, where some mcu timing message came, but i didn´t screen it sadly. After that the bell notification showed exactly and only that message: "MCU ‘mcu’ configured for 64Mhz but running at 63Mhz! "

I don´t know where that comes from, that´s why i opened this thread :stuck_out_tongue:

To be honest, i didn´t whant to make a big mess with it and hoped, the provided out of the box solution will work as promissed ((
Do I really have to make the Firmware update that way? I have the updatebuttons on my webinterface. Isn´t that enought? All are up to date.

Well, if you see it again here, please post it.

What is the “provided out of the box solution”?

I’m not sure why you feel that the instructions for making the Firmware are so onerous.

Regardless, if you haven’t created a Klipper firmware image as you were instructed, you’re going to have problems.

I have no idea what firmware is running on your M8P, I believe the initial firmware is just a bootloader but I’ve never been able to get the bootloader on a Manta (M4P, M5P and M8P) to accept a firmware.bin file on an SD card so I’ve always ended up with using the DFU utilities built into Klipper.

You say that you received a message saying the main controller is running at 63MHz but your klippy.log is stating that its running at 50MHz after it failed during a print.

Personally, I’d recommend that you start over, reimaging the code on the CB1 and then following the instructions in the M8P user manual for building and flashing the Klipper firmware as nothing you’re reporting seems to be making sense.

But, that’s just me.

I was curious and Googled it, apparently others have had the issue too but I didn’t dig into it enough to see if they figured it out.

I was mostly curious cause I’ve never seen that notification.

But apparently it exists.

Someone elses post on Reddit:

Found it, It’s actually a warning in Klipper I just never noticed it.

    def _ready(self):
        if self.is_fileoutput():
            return
        # Check that reported mcu frequency is in range
        mcu_freq = self._mcu_freq
        systime = self._reactor.monotonic()
        get_clock = self._clocksync.get_clock
        calc_freq = get_clock(systime + 1) - get_clock(systime)
        mcu_freq_mhz = int(mcu_freq / 1000000. + 0.5)
        calc_freq_mhz = int(calc_freq / 1000000. + 0.5)
        if mcu_freq_mhz != calc_freq_mhz:
            pconfig = self._printer.lookup_object('configfile')
            msg = ("MCU '%s' configured for %dMhz but running at %dMhz!"
                    % (self._name, mcu_freq_mhz, calc_freq_mhz))
            pconfig.runtime_warning(msg)

It compares the mcu_frequency to the calculated frequency but it’s changing a floating point division to an integer.

It’s probably just a rounding error since the frequency was only 1 Mhz off, I wouldn’t worry about it.

Probably not worth submitting a PR to add more robust checking to avoid rounding errors, especially on such a non-critical piece of code.

I consider the “63MHz” warning to be of secondary concern.

It’s something we can worry about after understanding why klippy.log is showing that the MCU is running at 50MHz.

As mentioned, I think @van3st should go through the installation process again and make sure they create new Klipper firmware for the MCU and flash it into the MCU.

2 Likes

You’re correct, I got fixated on the original warning.

64 to 63 MHz is a rounding error
64 to 50 Mhz is an issue

1 Like

Should be the same reason as with the 400/401 MHz that got fixed with properly configed and compiled firmware.
I have the same setup in my Micron+ and did not get this message.

Well, I tried to make a own klipper installation. to be honest, that is more confusing where to put what instad of having the feel i did something right or better than last time. The minimal OS image from btt didn´t work, but i was abled to build the firmware.bin and I hope i placed it right and he did it.
The serial didn´t change to what you guys expected. find it on the screenshots.
Maybe you see what i do wrong. Honestly i really like to print not configuring a robot o0

I am only allowed one attached picture per post so here is screenshot nbr 2

That looks fine and is equal to my setup:

However your MCU still runs Klipper v10?!
There have been massive changes since that old version and I’m astonished that there is no error due to version mismatch.
Best is to avoid other errors, especially when using canbus or ADXL345, to update the main MCU to v12 as well!

@van3st will have problems running their M8P with firmware at Klipper 10.

I really don’t understand their reluctance to do the update as it takes about a minute and is explained in the M8P’s user manual. Not to mention people being here to help.

@van3st if you want to print reliably, take the minute. You’re showing that you can SSH into the CB1 - that is literally the hardest part!

1 Like

@mykepredko
may you be so kind to provide me what user manual you are using … the things i find are different. Looks like yours is better.

For M8P V1.0 and V1.1 it can be found here:

For M8P V2.0 it can be found here:

1 Like

Well, I followed the instruction to flash the firmware.
In the end everything showed up as in the description plus one line:
make: *** [src/stm32/Makefile:111: flash] Error 255

now klipper is gone. so exactly that stuff that i didn´t want. I´m willing to throw that sh… away!

Screenshot 2024-05-09 230235

Which version of the M8P are you using? Any chance you can take a picture of the board so we can all be on the same page?