# MCU Clock Problem?

**URL:** <https://klipper.discourse.group/t/mcu-clock-problem/21290>\
**Category:** General Discussion\
**Created:** [January 10, 2025, 9:37pm UTC](https://klipper.discourse.group/t/mcu-clock-problem/21290 "2025-01-10T21:37:12Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![mykepredko](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/mykepredko/32/2085_2.png) [@mykepredko](https://klipper.discourse.group/u/mykepredko)\
**Post date:** [January 10, 2025, 9:37pm UTC](https://klipper.discourse.group/t/mcu-clock-problem/21290/1 "2025-01-10T21:37:12Z")

</div>

### Basic Information:

Printer Model: None  
 MCU / Printerboard: Custom STM32G0B1 with USB Host Connection  
 Host / SBC: BTT CB2  
 [klippy (1).log](https://klipper.discourse.group/uploads/short-url/1TJuCAaeKJSJm3pulCZqi47OSX8.log) (153.1 KB)

I’m bringing up a custom board design and one of the boards periodically crashes. In the latest, attached `klippy.log` you can see that the MCU clock is apparently going down to 1MHz which causes the Klipper connection to break.

Am I interpreting this correctly?

I have three other identical boards running but with a Raspberry Pi CM4, Orange Pi CM4 and BTT CB1 and none of them are presenting the same issues.

I will try with a different host but I was wondering if anybody had any comments beforehand.

Thanx!

---

<div class="post-metadata">

**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\
**Post date:** [January 13, 2025, 11:16pm UTC](https://klipper.discourse.group/t/mcu-clock-problem/21290/2 "2025-01-13T23:16:13Z")

</div>

It’s hard to tell exactly what went wrong, but the Klipper host code definitely got very confused by the clock reports from the mcu. It could certainly be a bad crystal (or similar timing issue) on the mcu.

-Kevin

---

<div class="post-metadata">

**Author:** ![mykepredko](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/mykepredko/32/2085_2.png) [@mykepredko](https://klipper.discourse.group/u/mykepredko)\
**Post date:** [January 14, 2025, 1:13am UTC](https://klipper.discourse.group/t/mcu-clock-problem/21290/3 "2025-01-14T01:13:44Z")

</div>

Hi Kevin,

Thank you for the reply.

Just so you know, I’ve been talking to @sineos about this separately.

Since the initial post, I’ve had seven more crashes of this board/host combination. None of the `klippy.log’ files generated after each of these subsequent crashes shows the same MCU timing problem.

One thing I didn’t put in the initial post (and should have now that I have more experience here) is that there is a heartbeat LED signal that flashes twice every second and I see that when there is a crash, this is stopping with the LED generally off (sometimes on) like the CB2’s CPU has stopped.

My plan is to add a wire on the CB2’s reset pin and see what happens if I force a reset - right now I’m pulling the power from the board (which has the CB2 mounted on it). The reason for doing this is to see if it’s a main controller board MCU (the STM32G0B1) failure - the thinking is that if I reset the CB2 but leave everything else on the board as is then I can isolate whether or not the problem is with the CB2 or the main controller board and it’s MCU.

Any other suggestsions?

---

<div class="post-metadata">

**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\
**Post date:** [January 14, 2025, 2:39am UTC](https://klipper.discourse.group/t/mcu-clock-problem/21290/4 "2025-01-14T02:39:08Z")

</div>

I guess it’s possible that something is wrong with the timing on the Linux machine. However, if that were the case I’d have expected that Linux itself would report tons of errors in its logs. I suppose that there could be a power management mode that is altering the Linux clock (though it’s not supposed to alter the “monotonic” clock rate). Alas, I don’t have any good suggestions.

Cheers,  
-Kevin

---

<div class="post-metadata">

**Author:** ![mykepredko](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/mykepredko/32/2085_2.png) [@mykepredko](https://klipper.discourse.group/u/mykepredko)\
**Post date:** [January 14, 2025, 4:17am UTC](https://klipper.discourse.group/t/mcu-clock-problem/21290/5 "2025-01-14T04:17:25Z")

</div>

Hi Kevin,

That was what @Sineos wondered and I have:

1. Checked for timesyncd and it’s not present on the CB2 (or CB1 or OrangePi CM4) - just the Raspberry Pi CM4.
2. Installed `crony` on the failing system.

I don’t know if this is useful to you but after the sixth crash I recorded the `dmesg` output: [2025.01.13-1000 - cb2-kpg74 dmesg output.txt](https://klipper.discourse.group/uploads/short-url/qNscDWnCAKt6umBdmjLgarZQsMg.txt) (90.6 KB)

Let me know if you have any ideas for me to try.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/klipper/original/1X/64419bf2aac6639e6ef5cef200dcd456b0a01ac3.png) [@system](https://klipper.discourse.group/u/system)\
**Post date:** [March 15, 2025, 4:17am UTC](https://klipper.discourse.group/t/mcu-clock-problem/21290/6 "2025-03-15T04:17:51Z")

</div>

Closed on March 15, 2025, 4:17am UTC

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
