[Bug]: RAK18001 buzzer causes RAK19003 boot failure

[tropho23]

Category

Other

Hardware

Rak4631

Firmware Version

2.3.9

Description

RAK18001 buzzer causes RAK19003 failure to boot

When a RAK18001 buzzer module is configured for the appropriate pin on RAK19003 (IO5/9 for Slot D per RAK documentation for RAK19003) the device fails to boot and a barely audible 'click' is heard emanating from the buzzer, as if it was not configured in PWM mode. While this occurs when the RAK18001 is installed in Slot D, as it should be when a GPS module is installed in Slot C, it also occurs when the RAK18001 is installed in Slot C and configured for IO3/pin 21 (default for that slot). Thus the issue doesn't seem to be a conflict or other issue with pin 9, but has something to do with the combination of RAK18001 buzzer and RAK19003.

Since IO5/pin 9 is used by the user button by default, the user button pin would have to be changed to prevent a conflict between the RAK18001 buzzer and the firmware expecting a user button using pin 9; changing this pin from 9 to anything else has no effect.

Logs are not possible to capture due to immediate crash/failure to boot.

This issue does not occur on RAK19007, and the RAK18001 buzzer operates as expected using pin 21 (IO3), the default for Slot C on the RAK19007.

This issue persists with older firmware, as far back as 2.1.38 that I tried.

[AeroXuk]

I captured this log via the flasher website before the crash / reboot loop,

//\ E S H T /\ S T / C
DEBUG | ??:??:?? 2 MODE (1 Bytes)
DEBUG | ??:??:?? 2 RAK (108 Bytes)
DEBUG | ??:??:?? 2 meshtastic.txt (0 Bytes)
DEBUG | ??:??:?? 2 db.proto (1228 Bytes)
DEBUG | ??:??:?? 2 module.proto (127 Bytes)
DEBUG | ??:??:?? 2 channels.proto (57 Bytes)
DEBUG | ??:??:?? 2 config.proto (144 Bytes)
DEBUG | ??:??:?? 2 Using analog input 5 for battery level
INFO | ??:??:?? 2 Scanning for i2c devices...
DEBUG | ??:??:?? 2 Scanning for i2c devices on port 1
INFO | ??:??:?? 2 No I2C devices found
DEBUG | ??:??:?? 2 acc_info = 0
INFO | ??:??:?? 2 Meshtastic hwvendor=9, swver=2.3.9.f06c56a
DEBUG | ??:??:?? 2 Reset reason: 0x0
DEBUG | ??:??:?? 2 Setting random seed 2431185551
INFO | ??:??:?? 2 Initializing NodeDB
INFO | ??:??:?? 2 Loading /prefs/db.proto
INFO | ??:??:?? 2 Loaded /prefs/db.proto successfully
INFO | ??:??:?? 2 Loaded saved devicestate version 22, with nodecount: 12
INFO | ??:??:?? 2 Loading /prefs/config.proto
INFO | ??:??:?? 2 Loaded /prefs/config.proto successfully
INFO | ??:??:?? 2 Loaded saved config version 22
INFO | ??:??:?? 2 Loading /prefs/module.proto
INFO | ??:??:?? 2 Loaded /prefs/module.proto successfully
INFO | ??:??:?? 2 Loaded saved moduleConfig version 22
INFO | ??:??:?? 2 Loading /prefs/channels.proto
INFO | ??:??:?? 2 Loaded /prefs/channels.proto successfully
INFO | ??:??:?? 2 Loaded saved channelFile version 22
INFO | ??:??:?? 2 File /oem/oem.proto not found
DEBUG | ??:??:?? 2 cleanupMeshDB purged 1 entries
DEBUG | ??:??:?? 2 Using nodenum 0x183265c8
DEBUG | ??:??:?? 2 Expanding short PSK #1
INFO | ??:??:?? 2 Wanted region 3, using EU_868
DEBUG | ??:??:?? 2 Using GPIO28 for button

[AeroXuk]

With some investigating, the crash seems to happen when playStartMelody(); is called within setup().

We suspect that the crash is due to the start up tune being played before the buzzer gpio pin has been read from the nodedb or before the output pin is properly initialised.

With the function call commented out within setup() then there is no crash issue and the buzzer sounds as expect on message received / bell received.

If we move the playStartMelody(); function call to be the last line in setup() it still crashes, so maybe something is still being setup in another thread even after setup() completes?