Firmware v2.35 - Continuous Crash and Reboot After Power Cycle

[CodeKibbut]

1. Turn off the radio
2. Turn it back on
3. The system starts crashing and rebooting repeatedly

I attached the flash dump (changed from bin to txt)

1020ba591df0_0x000_0x10000_20260520_184840.txt

Information:
AMNVOLT V3S
ESP32-S3-WROOM-1-MCN16R8

[max-arnold]

The boot loop you described sometimes happens with all firmware versions. My recommendation is to try resetting the settings (press and hold the encoder, then power on the receiver)

Also see this if you have Wi-Fi enabled: #307

[CodeKibbut]

Hi
I already performed a factory reset (held the encoder while powering on), and Wi-Fi is disabled in the settings. Unfortunately, the issue still occurs - turning the radio off and back on causes the device to enter a crash/reboot loop.

I rolled back to v2.33, which was my last before the update.

[CodeKibbut]

Hi
I’ve been reviewing version 2.35 and wanted to share some important findings regarding the recent stability issues and crashes (specifically Guru Meditation Error / LoadProhibited) we've been encountering.

To get a clear picture, I analyzed the v2.35 BLE codebase using AI-assisted code review tools. The analysis highlighted three critical vulnerabilities that directly correlate with our runtime panics:

1. Race Conditions in BLE Ring Buffers (cbuf)

Issue: BleUartPeripheral handles rxBuf and txBuf using cbuf, which is not thread-safe.

Impact: NimBLE callbacks (onWrite, onSubscribe) execute on a separate FreeRTOS task, while read(), write(), and pumpTx() run on the main Arduino loop. Accessing these buffers concurrently corrupts buffer indices, leading to memory corruption and core panics during active data transmission.

2. Unprotected NULL Pointer Access in BlePeripheral

Issue: BlePeripheral::end() and BlePeripheral::onDisconnect() attempt direct calls such as server->getAdvertising()->start() or ->stop() without null-checks.

Impact: If getAdvertising() returns nullptr (e.g., during a reset or uninitialized state), calling a method on it immediately triggers a LoadProhibited crash (accessing 0x00000000).

3. DRAM Heap Exhaustion

Issue: Concurrent usage of NimBLE and TFT_eSPI (with active sprites) pushes internal DRAM to its limits.

Impact: Any failed allocation inside BLEDevice::init() or dynamic malloc calls leads to immediate reboots or watchdogs triggering.

Recommended Fixes:

Wrap all cbuf read/write operations with a std::mutex or portMUX_TYPE critical section in BleUartPeripheral.cpp.

Add explicit checks before calling advertising methods:

C++
if (currentServer && currentServer->getAdvertising()) {
currentServer->getAdvertising()->stop();
}
Monitor ESP.getFreeHeap() during TFT rendering and BLE handshake to ensure we maintain a safe heap margin.

Please let me know if you would like me to perform any further analysis or run additional checks.
Best regards,