Fix BTT002 timer conflict with SPEAKER enabled

[sjasonsmith]

Description

The TONE timer on the BTT002 conflicted with the STEP timer. If using the SPEAKER feature this caused neither the speaker nor steppers to function.

This now uses the same timers as the SKR Pro, which does not appear to conflict with other board resources.

I originally pushed this to my PR to update STM32 dependencies (#17970), but there is no reason for this fix to wait for that entire PR.

@thisiskeithb already confirmed this change works on his BTT002 board, inside the above referenced PR.

Benefits

Allows enabling SPEAKER on BTT002 boards.

Related Issues

[thisiskeithb]

Thanks for breaking this out of the other PR! I've submitted PR MarlinFirmware/Configurations#106 to enable SPEAKER in the BTT002 config once this is merged.

[qwewer0]

Could this somehow be applied to SKR Mini E3 v1.2, or is that a whole different story?

[sjasonsmith]

@qwewer0 I didn’t know anything was wrong with the mini E3. This fix could not apply directly to it, but if there is a problem most likely it could be fixed.

[qwewer0]

@sjasonsmith SPEAKER isn't working on SKR Mini E3 v1.2 board.
The Ender 3s LCD (piezo beeper, buzzer or who knows) can produce different tones with M300 command.
But with the SKR Mini E3 v1.2 board:

• When SPEAKER is enabled the LCD doesn't makes any sound.
• When BUZZER is enabled the LCD makes sound and reacts to M300 command but only with a fixed frequency.

Related:

• 15828
• 17320

[thisiskeithb]

Oh right. I tired to address this once by disabling SPEAKER In the SKR pins, but hadn’t looked into timer conflicts.

[qwewer0]

I'm all up for testing anything on my board.

[sjasonsmith]

Oh right. I tired to address this once by disabling SPEAKER In the SKR pins, but hadn’t looked into timer conflicts.

@thisiskeithb, do you know if the Mini E3 1.0 has the same issue? I don't have a 1.2.

[thisiskeithb]

do you know if the Mini E3 1.0 has the same issue?

You mean the Mini E3 1.1? I’m not sure, but probably. The Mini E3 DIP is also probably affected.

I have a regular Mini 1.1 and Mini E3 1.2 I can test.

(These names are so fun to keep track of)

[qwewer0]

@thisiskeithb @sjasonsmith This might be helpful for the SKR Mini speaker problem. At least I hope it is.

Want to keep this problem active, and in mind of the Marlin geniuses, but not sure how, as the main issue page is kinda bleak, so I wrote here. I apologise for the inconveniences.

[sjasonsmith]

@thisiskeithb @sjasonsmith This might be helpful for the SKR Mini speaker problem. At least I hope it is.

Want to keep this problem active, and in mind of the Marlin geniuses, but not sure how, as the main issue page is kinda bleak, so I wrote here. I apologise for the inconveniences.

I just got the speaker working on an SKR Mini E3 1.0. I need clean it up a bit but will post something for it soon.

[bigtreetech]

@sjasonsmith Hello, after this PR rogerclarkmelbourne/Arduino_STM32#796, speaker in stm32f1 should work normal (including SKR-mini-E3-V1.0/V1.2/V2.0, E3-DIP-V1.0, mini-V1.1, etc...), you need to delete the maple library for stm32f1 in "C:\Users<your usr name>.platformio\packages\framework-arduinoststm32-maple" (delete this folder), enable SPEAKER in Marlin's configuration.h, Then compile again, vscode will download the latest maple dependency library automatic, compile and update, and M300 should work normally.

But there are still some questions need to test. according to here https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/5a7d8da9773c30dab6e29fd2c7b1ac73184f50d7/STM32F1/cores/maple/tone.cpp#L31, maple use TIMER8 for tone function (speaker in marlin) in STM32_HIGH_DENSITY,
but here

Marlin/Marlin/src/HAL/STM32F1/timers.h

Line 76 in e4d8336

#define SERVO0_TIMER_NUM 8 // tone.cpp uses Timer 4

also user TIMER8 for servo function (Bltouch in marlin) in STM32_HIGH_DENSITY.
According to the comment, Marlin's stm32f1 Hal library may be confusing in STM32_HIGH_DENSITY or not.

Marlin/Marlin/src/HAL/STM32F1/timers.h

Line 75 in e4d8336

#ifdef STM32_HIGH_DENSITY

here should be

 #ifdef STM32_HIGH_DENSITY
    #define SERVO0_TIMER_NUM 3  // tone.cpp uses Timer 8
  #else
    #define SERVO0_TIMER_NUM 8  // tone.cpp uses Timer 4
  #endif

It's need more test for Bltouch.

[qwewer0]

Tested it, but it is still the same with no sound at all if SPEAKER is enabled in firmware, and only fixed frequency when BUZZER is enabled. BLTouch works as before.

SKR Mini E3 v1.2
Ender 3 original 12864 display
BLTouch v3.1
Latest bugfix version of marlin.
"C:\Users.platformio\packages\framework-arduinoststm32-maple" folder deleted

[sjasonsmith]

The changes @bigtreetech mentioned is one of the problems. The timer conflict is the other. There aren’t enough timers available to enable everything on some boards. I have a change to allow using Timer 6 (a basic timer), but have not yet had time to finalize it for a PR. I will probably finish that this weekend.

[qwewer0]

@sjasonsmith Timers are hardware based / limited?

[bigtreetech]

Tested it, but it is still the same with no sound at all if SPEAKER is enabled in firmware, and only fixed frequency when BUZZER is enabled. BLTouch works as before.

SKR Mini E3 v1.2
Ender 3 original 12864 display
BLTouch v3.1
Latest bugfix version of marlin.
"C:\Users.platformio\packages\framework-arduinoststm32-maple" folder deleted

Hello, please confirm “tone.cpp” file in “C:\Users\Administrator.platformio\packages\framework-arduinoststm32-maple\STM32F1\cores\maple” folder is set correctly. If not, please modify it manually and then compile the test.
What needs to be changed is line 34
should be change from

    #define TONE_CHANNEL 8

to

    #define TONE_CHANNEL 4

[sjasonsmith]

If there is a need to discuss the STM32F1 implementation further, it should move to its own issue rather than tagging along on this already merged PR for a completely different HAL. I do have everything working together on an SKR Mini E3, I just didn't have time to finish preparing the PR yet.

[thisiskeithb]

If there is a need to discuss the STM32F1 implementation further, it should move to its own issue rather than tagging along on this already merged PR for a completely different HAL.

100% agree and I meant to create a Feature Request earlier.

Please continue the SPEAKER discussion in #18203.