[BUG] SPEAKER issue with Creality DWIN interface - sound turns off

[TheAndr0id]

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

Yes, and the problem still exists.

Bug Description

The buzzer in the standard DWIN Display is capable of playing multiple tones. Unfortunately there are no markings on the surface of the buzzer, but in practice, mine played "Take On Me" well enough.
(some of the "notes" we a little painful, but it worked!)

But... When #SPEAKER is enabled the sound seems to work as usual, but after the print is complete the sound falls silent and requires a power cycle to return.

Bug Timeline

old

Expected behavior

Print completion shouldn't shut off the sound.

Actual behavior

Before and during the print (eg: selecting the "Tune" function) creates a sound as expected. Once the print complete dialog is displayed no further sounds are made.

If #SPEAKER is disabled, sounds play as usual and expected.

Steps to Reproduce

1. Enable #SPEAKER in firmware.
2. Print a job. (sound works)
3. No more sound.

Version of Marlin Firmware

2.1.2.5

Printer model

Ender 3v2

Electronics

stock

LCD/Controller

DWIN (https://marlinfw.org/assets/images/hardware/controllers/T5UIC1_DWIN_back.jpg)

Other add-ons

No response

Bed Leveling

UBL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

One thing I did note was in the encoder.cpp file: (src/lcd/e3v2/common)

if (BUTTON_PRESSED(ENC)) {
    static millis_t next_click_update_ms;
    if (ELAPSED(now, next_click_update_ms)) {
      next_click_update_ms = millis() + 300;
      Encoder_tick();

Encoder_tick() utilizes the ui.sound_on flag that can be enabled to control sound from the LCD interface. I have not enabled this feature nor does the Creality DWIN interface seem to support it. Maybe something somewhere is toggling this flag to false?

void Encoder_tick() {
  TERN_(HAS_BEEPER, if (ui.sound_on) buzzer.click(10));
}

Configurations.zip

[classicrocker883]

I thought the buzzer was only able to play a single tone. you can also use the Gcode to play the sound rather than having to wait for a print

[TheAndr0id]

Turns out there are two types of buzzer, active and passive. (Yes, I've been reading again)

Active buzzers (generally) are magnetic and are turned on an off with current, while passive buzzers can be triggered with a PWM/duty cycle to create different frequencies.

The tone() functions (at least for the STM32F line) create a PWM cycle using the specified frequency and toggle the connected buzzer pin(in digital mode). Active buzzers just generate a single tone while passives generate a frequency/note that's close to the specification.

In the firmware #SPEAKER enables the use of the tone() function instead of just turning on() and off() the buzzer for a specified time. For an active buzzer there will be no difference between using tone() or just turning on the buzzer. The switching mechanism of active buzzers just average out the frequency and if it's high enough it toggles on. Think of a relay vs. a high speed transistor.

I now know more about buzzers than I ever wanted. I was just looking to have my printer play "ta-da" when the first layer was complete...

The problem above isn't that the sound doesn't work, it stops working in the interface. I can still use G-code commands to toggle the buzzer. Sorry, I didn't think to add that...

[classicrocker883]

so it stops working only after the print is done? are you able to go in a terminal or use a gcode file to test?

example

M300 S440 P200
M300 S660 P250
M300 S880 P300

from M300 info

maybe there is something that disables the sound requiring a restart.

[TheAndr0id]

Sound still works. It's an issue with the interface, not the speaker or the sound or G-Code. My instinct says that something is setting ui.sound_on to false that is being called outside of the Creality DWIN environment. The other e3v2 interfaces all have controls for ui.sound_on, DWIN does not.

[thinkyhead]

The configurations you provided are for 2.1.2.5. You should be testing bugfix-2.1.x and you should be providing those configurations here instead of your 2.1.2.5 configurations.

[TheAndr0id]

Here is the same configuration (at least the values I changed) for bugfix-2.1.x.

Configuration_bugfix.zip

I have done quick tests (and checked to see if there were any code differences in buzzer.h or buzzer.cpp), and the problem still exists in bugfix. I don't run bugfix or experimental code as bugfix is a lot more than just bugfixes, and experimental/beta? "No thank you."

Just tried wrapping the ui.sound_on calls with defines, and it didn't make a difference. In fact it might have made it worse. In my recent test selecting the tune submenu while printing at the start of the print produced the buzzer.click() below. After 22 minutes of printing, no noise from selecting the tune submenu. My changes are shown below:

void Encoder_tick() {
  #if ENABLED(SOUND_MENU_ITEM)
    TERN_(HAS_BEEPER, if (ui.sound_on) buzzer.click(10));
  #else
    TERN_(HAS_BEEPER, buzzer.click(10));
  #endif
}

There were other instances where ui.sound_on was checked (buzzer.cpp for example) that I also wrapped in the #if ENABLED(SOUND_MENU_ITEM) as well.

A print just completed, no sound from the UI, but an M300 produces noise (and with different tones for different frequencies). Even after issuing multiple M300 calls, the interface still produces no beeps. For me this says there is nothing wrong with Buzzer::tone() or Buzzer::tick()

[TheAndr0id]

I wasn't going to go down this rabbit hole, but here I am. Digging.

More testing, more information. Seems that the interface sound cuts out after a M300 call when SPEAKER is defined. M300 calls continue to work after, but as soon as M300 is called no sound from the UI afterwards. Why is this happening? My "Ta-Da" tune played at the end of the first layer. If I check the UI before the first layer is done, sound works, after the first layer "Ta-Da", broken. Well maybe not broken, but no longer working.

SPEAKER forces a call to ::tone() which is a function provided by the hardware libraries in .platformio. In my case, this is

void tone(uint8_t _pin, unsigned int frequency, unsigned long duration)
{
  PinName p = digitalPinToPinName(_pin);

  if (TimerTone == NULL) {
    TimerTone = new HardwareTimer(TIMER_TONE);
  }

  if (p != NC) {
    if ((TimerTone_pinInfo.pin == NC) || (TimerTone_pinInfo.pin == p)) {
      timerTonePinInit(p, frequency, duration);
    }
  }
}

In timerTonePinInit() the pin mode is set here:

pin_function(TimerTone_pinInfo.pin, STM_PIN_DATA(STM_MODE_OUTPUT_PP, GPIO_NOPULL, 0));

in encoder.cpp the BEEPER pin is set with:

#if HAS_BEEPER
    SET_OUTPUT(BEEPER_PIN);     // TODO: Use buzzer.h which already inits this
#endif

From what I can tell, that sets the pinmode to just simple OUTPUT. I'm thinking that the mode mask set in timerTonPinInit() is not OUTPUT compatible. Maybe encoder_tick() should be using a tone() call if SPEAKER is defined?

[TheAndr0id]

I saw a string. "This isn't supposed to be here." So I pulled on it.

What have I done.

I want to believe some of this code was not done this way intentionally, but after the 4th or 5th define referencing another define which is only used by the previous define it starts to make my head hurt. Not just keeping track of what calls what, but why?

For example. In the above SET_OUTPUT(BEEPER_PIN); in encoder.cpp:

#define _SET_MODE(IO,M)         gpio_set_mode(PIN_MAP[IO].gpio_device, PIN_MAP[IO].gpio_bit, M)

#define _SET_OUTPUT(IO)         _SET_MODE(IO, GPIO_OUTPUT_PP)

.
.
.
#define OUT_WRITE(IO,V)         do{ _SET_OUTPUT(IO); WRITE(IO,V); }while(0)
.
.
.
#define SET_OUTPUT(IO)          OUT_WRITE(IO, LOW)

(`WRITE()`` just sets up a hardware register turning the pin high or low.)

Now this is all in the same file, fastio.h so it's not that bad(I choose to ignore gpio_set_mode()), but the STM32 libraries reference files under files under files. A simple pin reference is sub defined 3, 4, 5, even 6 levels deep with the final value.

timerTonePinInit() sets up an interrupt that calls tonePeriodElapsedCallback() which calls digital_io_write() which calls LL_GPIO_SetOutputPin() which calls WRITE_REG() which is defined as follows:

#define WRITE_REG(REG, VAL) ((REG) = (VAL))

Thus, LL_GPIO_SetOutputPin() calls:
WRITE_REG(GPIOx->BSRR, (PinMask >> GPIO_PIN_MASK_POS) & 0x0000FFFFU);
which just becomes:
GPIOx->BSRR = (PinMask >> GPIO_PIN_MASK_POS) & 0x0000FFFFU;

All of this spaghetti code is just inlined by the compiler into a single operation. There's no benefit to the code, there's no benefit to the executable, it just creates an impossible to read, obscure, error prone mess. It just makes me sad.

</rant off>

Sorry, I had to vent.

The only difference between these two pin writes is how the internal pull-up resistors are set. The GPIO_NOPULL changes the pin mode slightly by creating a bitmask on the standard OUTPUT (which is the same as GPIO_OUTPUT_PP - PushPull mode, forcing a high or low status on the port - default for OUTPUT mode on the STM32).

Without digging further into the nightmare of the STM32 libraries, I'm going to guess that the standard WRITE() call checks the pin's mode to make sure it is OUTPUT/GPIO_OUTPUT_PP before it changes the hardware register value.

What was I doing again? Oh, right, beeps.

The tone() call in the STM32 library sets the pins mode before it sets it's value. My thought is that the on() and off() calls:

      FORCE_INLINE static void on() { WRITE(BEEPER_PIN, HIGH); }

      FORCE_INLINE static void off() { WRITE(BEEPER_PIN, LOW); }

      static void click(const uint16_t duration) { on(); delay(duration); off();

need to include a SET_OUTPUT(BEEPER_PIN); to make sure the pin's mode is set to OUTPUT not GPIO_OUTPUT_PP+GPIO_NOPULL.

I'm going to try that tomorrow as right now I'm tired. So very tired.

[TheAndr0id]

Just tried adding the SET_OUTPUT(BEEPER_PIN); to the on() and off() functions above. No change, still the same issue.

My only other thought is to update the buzzer.click() function to support the tone() call and use the LCD_FEEDBACK_FREQUENCY_* defines from configuration.h. Something like what the Marlin UI uses for chirp().

static void chirp() {
    TERN_(HAS_CHIRP, TERN(USE_MARLINUI_BUZZER, buzz, BUZZ)(LCD_FEEDBACK_FREQUENCY_DURATION_MS, LCD_FEEDBACK_FREQUENCY_HZ));
  }

(I just have to figure out what the difference between buzz() and BUZZ())

[TheAndr0id]

Here's what I've come up with:

void Encoder_tick() {
  // TERN_(HAS_BEEPER, if (ui.sound_on) buzzer.click(10));
  #if ALL(LCD_FEEDBACK_FREQUENCY_DURATION_MS, LCD_FEEDBACK_FREQUENCY_HZ)
    TERN_(HAS_BEEPER, if (ui.sound_on) BUZZ(LCD_FEEDBACK_FREQUENCY_DURATION_MS, 
                                            LCD_FEEDBACK_FREQUENCY_HZ));
  #else
    TERN_(HAS_BEEPER, if (ui.sound_on) BUZZ(10, 100));
  #endif
}

There are a couple of items remaining that others might be able to help with.

1. The frequency of the default beep when SPEAKER is not defined. I have no idea what that frequency is, so by ear I've guessed at 100Hz. If anyone has that information (Google went huh?) please speak up. I don't have two printers to compare the beeps with.
2. I didn't add in the handle for `SOUND_MENU_ITEM since it didn't have an effect in previous tests.

The LCD_FEEDBACK_FREQUENCY_HZ also has a default value set to 5000. That might work with dogs, but I can't hear it. I also increased LCD_FEEDBACK_FREQUENCY_DURATION_MS to 10 in my configuration.h.

This will work with SPEAKER undefined as BEEP handles the SPEAKER functionality.

One other interesting side note (and so far it happens every time):

After flashing the firmware if I click the knob before moving it, instant reboot. Then it works fine. If I reboot it will work fine from fresh restart. It only happens immediately after the flash of the firmware with the above code.

[classicrocker883]

so by ear I've guessed at 100Hz.

im not sure there is a set value. what I see is that its just HIGH or LOW to the pin. in other words, you can probably make the same noise with 3.3/5v

(I just have to figure out what the difference between buzz() and BUZZ())

i think buzz() is for marlinui, BUZZ() is buzzer.tone()

After flashing the firmware if I click the knob before moving it, instant reboot.

you may need to add a delay - safe_delay(). or its possible that there is some "backfire" and something is grounding/shorting out, which would cause that to happen.

a quick look we have in libs/buzzer.cpp:

void Buzzer::tick() {
...
  if (state.tone.frequency > 0) {
    #if ENABLED(EXTENSIBLE_UI) && DISABLED(EXTUI_LOCAL_BEEPER)
      CRITICAL_SECTION_START();
      ExtUI::onPlayTone(state.tone.frequency, state.tone.duration);
      CRITICAL_SECTION_END();
    #elif ENABLED(SPEAKER)
      CRITICAL_SECTION_START();
      ::tone(BEEPER_PIN, state.tone.frequency, state.tone.duration);
      CRITICAL_SECTION_END();
    #else
      on();
    #endif
  }

not sure how that plays out when speaker is enabled, try having that disabled so it goes right to on();

[TheAndr0id]

So ::tone() depends on what your system board is as it's a function provided in those libraries. For the STM32F series the tone() function creates a PWM signal in software (not via a PWM pin) toggling the pin high/low to match a specified frequency.

Now for active buzzers this will have no effect other than maybe some wobble at low frequencies as active buzzers control the buzzer itself(think buzzer connected via relay). Passive buzzers on the other hand will use this frequency to average out the signal to the buzzer creating a different frequency. That being said they do have bounds (depending on the specs of the buzzer) and if the frequency is too low or too high the buzzer won't.

This restart only happens if the encoder is clicked right after a firmware update. If it's rotated then clicked, no issue. After it's restarted(manual or otherwise), no issue. Time doesn't seem to have any impact as I waited 5 minutes then clicked and reboot.

If there were any sort of brownout/voltage/grounding issue, the restart should happen every time the encoder was clicked.

I also want to make sure there's no confusion, I haven't made any hardware changes, this is a from the factory Creality 4.2.7 board with a first generation DWIN connected display.

My next firmware update I'll try getting the serial connection up and see if anything comes up on the console.

[classicrocker883]

that is definitely a strange occurrence. and to be sure it can depend on the actual UI type, Creality/JyersUI/ProUI. you may have different results