[BUG] Fysetc Cheetah mainboard not working with STM32RC_fysetc build envs

[rlagerweij]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

When compiling recent versions of the 2.0.x branch for the Fysetc Cheetah 1.2b using the STM32F103RC_fysetc default_envs in platformio.ini it creates a firmware file which does not work on the board. The mainboard seems frozen.

The compilation completes with no errors. Flashing completed with no errors. The screen remains blank (backlight is on) and it is not possible to connect to the printer over the serial port with either putty or pronterface. Flashing another hex file remains possible.

Tested with the latest code of today in both the 2.0.x and Bugfix-2.0.x branches.

Using git bisect I have found that the issue started with commit b6cb56f396e58b95d7e3f7750f388373bfbd01dd

That commit introduces new build_envs for STM32 targets. It also renames the old STM32F103RC_fysetc to STM32F103RC_fysetc_maple and introduces a new set of parameters under that name.

Building the exact same code and config with the default_env set to STM32F103RC_fysetc_maple results in a working firmware on the latest commits.

Issue is the same as #23067

Bug Timeline

The bug was introduced just after the 2.0.9.1 release with commit b6cb56f396e58b95d7e3f7750f388373bfbd01dd

Expected behavior

LCD screen shows bootlogo and can be operated from the status screen

Actual behavior

LCD remains blank and the printer cannot be communicated with over usb(serial). Flashing remains possible.

Steps to Reproduce

• checkout latest version of the Marlin code
• set default_envs to STM32F103RC_fysetc in platformio.ini
• copy default configs from "Merlin-Configurations/config/examples//Creality/Ender-3/FYSETC Cheetah 1.2/base" to the Marlin folder
• Build with VS code using the platform.io extension
• Flash the hex file with FlyMCU program from Fysetc Github page

Version of Marlin Firmware

2.0.9.3 (maple)

Printer model

Ender 3 pro

Electronics

Fysetc Cheetah v1.2b

[J0hnMatrix]

I can confirm this is working with _STM32F103RC_fysetcmaple in platformio.ini and is NOT working with _STM32F103RCfysetc

[rlagerweij]

@GerogeFu do you have any ideas?

[BRS3CTY]

I have the same here, only maple is working.

[rlagerweij]

may be related to https://github.com/MarlinFirmware/Marlin/issues/22670

[rlagerweij]

I'm happy to test things or try to code a solution, but I just don't know where to start on this. If anyone has a hint what to look for....

[BRS3CTY]

I'm trying to fix this too but i have no idea how to edit source of platformio board, i think that there is some clue. Look at log of build, if you're building STM32F103RC_fysetc it takes files from src\HAL\STM32. When you build STM32F103RC_fysetc_maple it takes from src\HAL\STM32F1 and it works. But i never could build non maple because of error:

Marlin\src\HAL\STM32\timers.cpp:328:40: error: static assertion failed: One or more timer conflict detected. Examine "timers_in_use" to help identify conflict.

So i can't even get blank lcd of STM32F103RC_fysetc.. I would never have tried to figure it out if not for the message in maple build:

#warning "Maple build environments are deprecated. Please use a non-Maple build environment. Report 
issues to the Marlin Firmware project."

[rlagerweij]

my binaries build without error. but they don't work

[thinkyhead]

Examine "timers_in_use" to help identify conflict.

After a build (or attempt) in Visual Studio Code you can open the file HAL/STM32/timers.cpp and hover the mouse pointer over the definition of timers_in_use (line 304) and it should display the contents of the array in a popup. If two or more of the timers are the same, that tells us where the conflict lies.

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.