Fix BLTOUCH and FAN PWM conflicts on SKR E3 boards

[sjasonsmith]

Description

Fix a conflict between the PWM timer used by FAN_PIN and the timer used for Software PWM output for SERVO0.

This impacts all of the SKR "E3" boards (E3 Mini, E3 Mini 1.2, and E3 DIP). The MKS Robin Lite is also impacted, although it doesn't currently implement BLTouch support. These all use the PA8 pin for FAN_PIN, which corresponds to timer 1's TIM1_CH1 PWM pin.

I'm including scope captures of the SERVO0 output line, prior to this change, on an SKR E3 Mini.

All my testing was done with an SKR E3 Mini. I am assuming the same solution works for the other boards including in the change.

Immediately After Boot (Without fix)
Logic is held high with a 1.4us glitch low every 20ms (PWM period).

When commanding a BLTouch probe to deploy, using M280 P0 S10 (Without Fix)
Logic drops low, and only two pulses are observed before returning to prior erroneous state. Occasionally up to 5 pulses are sent. The BLTouch seems to recognize the command when at least 4 pulses are sent.

Benefits

This makes manual control very reliable. I'm using the Octoprint BLTouch plugin, but that is just sending M280 commands.

I have also not had any probing failures since making this change. Prior to this change about 60-80% of my probes would crash into the bed. After this change, I have performed at least 125 probes with no failures. 25 of those were at temperature, with the bed at 100C and nozzle at 230C.

I suspect that the erroneous behavior of holding the signal line high between commands is preventing the BLTouch from performing correctly.

Scope captures show the "Fixed" behavior with this change, on the same board. I verified with my old Melzi board that this matches the behavior of my old working BLTouch system.

Immediately After Boot (With Fix)
Logic low, with proper continuous "Probe Up" pulses every 20ms.

When commanding a BLTouch probe to deploy, using M280 P0 S10 (With Fix)
New command pulse continues until another command replaces it.

Related Issues

For as many complaints as I can find on Reddit about BLTouch being unreliable on the SKR E3 boards, I can't find specific issues in Marlin. I feel like I must be a little blind today, they must be there somewhere!

[sjasonsmith]

@Roxy-3D and I discussed this on Discord, and they recommended working around this in timers.h for now. Unfortunately I had to change the include order in a couple other files to ensure it always behaved correctly, which may or may not be ok.

I didn't change all STM32F1 boards to use timer 8 because (1) not all F1 chips has a TIM8, and (2) other boards have their fans attached to TIM8.

I think long-term this needs restructured to allow the pins files to override all the timer selections in timers.h. It's not really a board flaw to connect a FAN to an arbitrary timer on the board. There should be some way to configure the HAL accordingly. I attempted to implement this approach, but it wasn't as simple as adding some ifdefs due to the include order of the HAL and pins files.

[sjasonsmith]

Another improvement I just noticed is that when I sent a Self-Test command to my BLTouch, it consistently performs 10 Probe/Stow cycles. Prior to this, it would perform 2-5 cycles, seemingly randomly.

It seems that the BLTouch "forgets" what mode it is in without this fix. That could explain why when probing it would simply ignore the pin being pressed into the probe, and why it was more likely to happen if the bed started a long distance from the probe.

[sjasonsmith]

I just finished 250 successful probes with this change (5 iterations of M48 P50). It seems like maybe all those complaints about hardware could be solved in software after all!

Edit: This was done with bed at 100C and nozzle at 230C. Infrared thermometer shows voltage regulator area on the board is at 50C.

[thisiskeithb]

Great work.

I wonder if a similar patch can be applied to the SKR 1.3 since the servo & fans share the same timer making FAST_PWM_FAN incompatible with BLTOUCH.

[tpruvot]

may be replaced by #if STM32_HAVE_TIMER(8)

only the CB/C8 card need timer 1... STM32F103CB_malyan

[sjasonsmith]

I did not do this, because other boards have FAN pins on timer 8. It would trade a fix on the SKR E3 boards for potential problems on other boards.

[tpruvot]

but also locks 2 timers in Marlin for the same feature...

[sjasonsmith]

Let me see if I can solve the problem by switching to different channels, rather than a different timer.

[tpruvot]

I just meant the list of boards could take 5 pages in a few months, using this kind of code :p better to do the reverse... if the timer 8 doesnt exist...

[tpruvot]

i coded it like that first, someone has put it then in this file.... was intended to be set in the pins file if used

[tpruvot]

something to try:
#ifndef SERVO0_TIMER_NUM
#define SERVO0_TIMER_NUM 1
#endif

and define 8 in your board file, in theory the Servo cpp file will load the config before this .h

[sjasonsmith]

That is the first thing I tried, and it did not work. This file ends up included before the pins file. That would work if I moved this #DEFINE into Servo.cpp.

[sjasonsmith]

It seemed like there was some intention to have the timer numbers listed all in timers.h. If that is not true, then moving it to Servos.cpp and adding the #ifndef would be the easy fix.

[tpruvot]

maybe let a comment in the .h ... #14407 seems related

[sjasonsmith]

Based on @tpruvot's concern regarding this making fewer timers free for future use, I experimented with moving the Servo output to different channels on Timer 1, rather than to a completely new timer. Images were taken with the fan at 50%, to produce a square wave.

This still resolves the BLTouch issues (I think, I only probed it, did not test it), but changes the fan PWM period to 20ms.

(Notice that the X scale is changed in the second picture, so that you can clearly see the higher frequency PWM signal. The Servo pulse is the same length in all images.)

[sjasonsmith]

I wonder if a similar patch can be applied to the SKR 1.3 since the servo & fans share the same timer making FAST_PWM_FAN incompatible with BLTOUCH.

I don't know. I've never had issues with BLTouch on my SKR 1.3, I guess because I use FAN_SOFT_PWM. My fan won't turn at less than 100% with the hardware PWM.

[sustmi]

Nice work @sjasonsmith !

I may not fully understand how are timers configured and how are the pins assigned. However, I can see in https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F1/variants/generic_stm32f103r/board.cpp#L124 and also in the STM32F103RCT6 datasheet (on page 34) that timer 8 is assigned to pins PC6, PC7, PC8 and PC9.
According to SKR E3 DIP V1.0 schematic, pin PC8 is used for HE0_PWM signal and PC9 for BED-PWM.

Correct me if I am wrong but isn't the BLTOUCH servo now in conflict with those two PWMs?

As you shown here #15547 (comment), setting SERVO0_TIMER_NUM to 1 causes change of the PWM period from ~1.8 ms to 20 ms. Isn't something similar happening now with hotend and heated bed PWMs?

I can see in https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/HAL/HAL_STM32F1/Servo.cpp#L180 that the servo control code uses channels 1 and 2 of the timer while PC8 and PC9 correspond to channels 3 and 4 but the timer_set_prescaler() setting is common for all channels.

[sustmi]

Oh, I can see by looking here:

Marlin/Marlin/Configuration.h

Line 2083 in 899e0fc

// Use software PWM to drive the fan, as for the heaters. This uses a very low frequency

and here:

Marlin/Marlin/src/module/temperature.cpp

Line 2360 in 899e0fc

static SoftPWM soft_pwm_hotend[HOTENDS];

... that hotend and heated bed actually use software PWM (ie. generated by directly setting the output signals to 0 or 1; not a hardware PWM where the signals are generated by appropriate timer channels).

And the code that generates software PWMs for heaters uses timer 2 according to:

Marlin/Marlin/src/module/temperature.cpp

Line 2314 in 899e0fc

HAL_timer_isr_prologue(TEMP_TIMER_NUM);

and:

Marlin/Marlin/src/HAL/HAL_STM32F1/timers.h

Line 55 in 899e0fc

#define TEMP_TIMER_NUM 2 // index of timer to use for temperature

So there should be no new conflict after this fix. 👍

[sustmi]

Update: I found there actually is a conflict after changing SERVO0_TIMER_NUM to 8. 😞

I noticed that after this fix the buzzer sound played during splash screen (when the printer is turned on) sounds a bit different - it's longer and sounds distorted.
I found out that timer 8 is actually used by tone generator: https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/83ae7019d8085181e8d9b622ce90201b61b5c719/STM32F1/cores/maple/tone.cpp#L31 .
And this tone generator is used by Marlin's Buzzer class:

Marlin/Marlin/src/libs/buzzer.cpp

Line 71 in 15f94e5

::tone(BEEPER_PIN, state.tone.frequency, state.tone.duration);

Side note: Timer 8 is a default value that can be overwritten by calling setToneTimerChannel().

This is the current assignment of timers for SKR E3 boards

• Timer 1 - FAN0 PWM (because FAN_PWM is connected to PA8 and pin PA8 belongs to timer 1)
• Timer 2 - Used for generating software PWM that is used for temperature regulation (see TEMP_TIMER_NUM and Temperature::isr())
• Timer 5 - Used for controlling stepper drivers see STEP_TIMER_NUM and Stepper::isr())
• Timer 8 -
  1. tone generator
  2. After this PR: SERVO0_TIMER_NUM (used to control BLTOUCH)

As far as I can tell, the other timers are not used. According to Table 4. High-density timer feature comparison in STM32F103RCT6 datasheet (page 19), timers 6 and 7 have zero capture/compare channels so they are not suitable for SERVO0_TIMER_NUM. So we are left with timer 3 or timer 4.

Since on some boards (that have "medium-density" STM32F103xx chips with just 4 timers) timer 4 is used for steppers instead of timer 5, I would choose timer 3 (to avoid confusion) as SERVO0_TIMER_NUM while hoping that we do not find some other feature that already uses this timer.

What do you think @sjasonsmith ?

[sjasonsmith]

@sustmi All I can do it laugh 🤣

These timer conflicts are such a pain. I wonder if something could be done in the STM32 Core to make it easier to detect conflicts at compile time.

Can you submit a pull request to fix this? I don't have that board connected anymore, so cannot test a fix. If you cannot fix it right away you should create a new issue with the details you included here.

[sjasonsmith]

At least a weird sounding buzzer is better than crashing during probes 😄

[sustmi]

🤦‍♂️ I've just found that the sound does not actually come from the buzzer but it's a noise from the hotend fan that gets spinned-up for a short time when the printer is turned on.
As the fan PWM period is now different after your fix (not 20ms forced by SERVO0) it makes sense that the noise is different too.

At least a weird sounding buzzer is better than crashing during probes

As long as the buzzer does not change timer's pre-scaler or output compare value for channels 1 and 2 during probing, I guess it should not introduce any probing errors.

[donjakobo]

I know this is closed and an old issue, but if it helps anyone. None of the above fixed my BLTouch issue. I swapped hardware (Bltouch) with a backup, tweaked firmware multiple ways. The ONLY fix that eliminated the "stuttering probe" issue was installing a 5V stepdown (24v -> 5V) and running my BLtouch power/ground off that vs the board. I don't know if its noise or weak 5v line, I tried as a last ditch effort on this board and just a simple pololu stepdown did the trick beautifully. Now all my probing is reliable and works great.