starred/OpenEPaperLink
1
0
Fork 0
mirror of https://github.com/OpenEPaperLink/OpenEPaperLink.git synced 2026-03-21 00:04:28 +01:00
Code Issues 472 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #362] BLE only - kernel panic - BTC_TASK stack overflow #213

New Issue
Closed
opened 2026-03-20 17:27:52 +01:00 by sascha_hemi · 1 comment
sascha_hemi commented 2026-03-20 17:27:52 +01:00
Owner
Copy Link

Originally created by @JT-DE on GitHub (Aug 24, 2024).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/362

Thanks you all for this great project, do you have an idea what I can do to stop regular reboots?

I am running the ble only version on a ESP32-S3 N16R8 flashed using the webpage

env: BLE_ONLY_AP
build date: 2024-05-07 18:05
esp32 version: ble_test3
psram size: 8371063
flash size: 16777216

And it is connected to three tags with stock firmware.

Gicisky BLE EPD BWR 2.13"
250x128 fw:33025 0x8101

Once in a while, it seems to lose the ability to connect to the tags but from what I read, this is still an experimental feature, so no worries.

Looking at the logs, I see regular reboots due to kernel panics like these: sometimes every half an hour, sometimes running fine for half a day.

2024-08-23 00:09:31 Reboot. Reason: Panic
2024-08-23 02:50:19 Reboot. Reason: Panic
2024-08-23 03:52:42 Reboot. Reason: Panic
2024-08-23 09:21:30 Reboot. Reason: Panic
2024-08-23 09:28:53 Reboot. Reason: Panic
2024-08-23 10:13:51 Reboot. Reason: Panic
2024-08-23 10:25:56 Reboot. Reason: Panic
2024-08-23 11:20:56 Reboot. Reason: Panic
2024-08-23 11:28:04 Reboot. Reason: Panic

The console output points to a stack overflow in the bluetooth task:

Guru Meditation Error: Core  0 panic'ed (Unhandled debug exception).
Debug exception reason: Stack canary watchpoint triggered (BTC_TASK)
Core  0 register dump:
PC      : 0x40385063  PS      : 0x00060036  A0      : 0x803839c4  A1      : 0x3fcc3590
A2      : 0x3fc9bce0  A3      : 0xb33fffff  A4      : 0x0000abab  A5      : 0x00060023
A6      : 0x00060023  A7      : 0x0000cdcd  A8      : 0xb33fffff  A9      : 0xffffffff
A10     : 0x3fc9bcb4  A11     : 0x00000001  A12     : 0x00060021  A13     : 0x80000000
A14     : 0x02c9bce0  A15     : 0x00ffffff  SAR     : 0x0000001e  EXCCAUSE: 0x00000001
EXCVADDR: 0x00000000  LBEG    : 0x400556d5  LEND    : 0x400556e5  LCOUNT  : 0xffffffff
Guru Meditation Error: Core  0 panic'ed (Double exception).

Core  0 register dump:
PC      : 0x403743c0  PS      : 0x00060436  A0      : 0x0a021a01  A1      : 0x3fcc3330
A2      : 0x00060436  A3      : 0x00040026  A4      : 0x3c16590e  A5      : 0x42059e38
A6      : 0x00021340  A7      : 0x00000002  A8      : 0x3fcc33f0  A9      : 0x00000070
A10     : 0x3fcc34d0  A11     : 0x3fca1f98  A12     : 0x3c16acd7  A13     : 0x3c16590e
A14     : 0x00000000  A15     : 0x3fcc34d0  SAR     : 0x04b13c0a  EXCCAUSE: 0x02a6d73c
EXCVADDR: 0xff060601  LBEG    : 0x6d000040  LEND    : 0x59061102  LCOUNT  : 0xed4a4ac1


Backtrace: 0x403743bd:0x3fcc3330 0x0a0219fe:0x3fcc3350 |<-CORRUPTED

As far as I can tell, there is plenty of memory left
free heap: 138.95 kB ┇ free PSRAM: 7.89 MB ┇ db size: 558 bytes ┇ db record count: 3 ┇ filesystem free: 6.06 MB ┇ uptime: 6h 57m 40s

Do you have any suggestions for me?

Thanks
JT-DE

Originally created by @JT-DE on GitHub (Aug 24, 2024). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/362 Thanks you all for this great project, do you have an idea what I can do to stop regular reboots? I am running the ble only version on a ESP32-S3 N16R8 flashed using the webpage ``` env: BLE_ONLY_AP build date: 2024-05-07 18:05 esp32 version: ble_test3 psram size: 8371063 flash size: 16777216 ``` And it is connected to three tags with stock firmware. ``` Gicisky BLE EPD BWR 2.13" 250x128 fw:33025 0x8101 ``` Once in a while, it seems to lose the ability to connect to the tags but from what I read, this is still an experimental feature, so no worries. Looking at the logs, I see regular reboots due to kernel panics like these: sometimes every half an hour, sometimes running fine for half a day. ``` 2024-08-23 00:09:31 Reboot. Reason: Panic 2024-08-23 02:50:19 Reboot. Reason: Panic 2024-08-23 03:52:42 Reboot. Reason: Panic 2024-08-23 09:21:30 Reboot. Reason: Panic 2024-08-23 09:28:53 Reboot. Reason: Panic 2024-08-23 10:13:51 Reboot. Reason: Panic 2024-08-23 10:25:56 Reboot. Reason: Panic 2024-08-23 11:20:56 Reboot. Reason: Panic 2024-08-23 11:28:04 Reboot. Reason: Panic ``` The console output points to a stack overflow in the bluetooth task: ``` Guru Meditation Error: Core 0 panic'ed (Unhandled debug exception). Debug exception reason: Stack canary watchpoint triggered (BTC_TASK) Core 0 register dump: PC : 0x40385063 PS : 0x00060036 A0 : 0x803839c4 A1 : 0x3fcc3590 A2 : 0x3fc9bce0 A3 : 0xb33fffff A4 : 0x0000abab A5 : 0x00060023 A6 : 0x00060023 A7 : 0x0000cdcd A8 : 0xb33fffff A9 : 0xffffffff A10 : 0x3fc9bcb4 A11 : 0x00000001 A12 : 0x00060021 A13 : 0x80000000 A14 : 0x02c9bce0 A15 : 0x00ffffff SAR : 0x0000001e EXCCAUSE: 0x00000001 EXCVADDR: 0x00000000 LBEG : 0x400556d5 LEND : 0x400556e5 LCOUNT : 0xffffffff Guru Meditation Error: Core 0 panic'ed (Double exception). Core 0 register dump: PC : 0x403743c0 PS : 0x00060436 A0 : 0x0a021a01 A1 : 0x3fcc3330 A2 : 0x00060436 A3 : 0x00040026 A4 : 0x3c16590e A5 : 0x42059e38 A6 : 0x00021340 A7 : 0x00000002 A8 : 0x3fcc33f0 A9 : 0x00000070 A10 : 0x3fcc34d0 A11 : 0x3fca1f98 A12 : 0x3c16acd7 A13 : 0x3c16590e A14 : 0x00000000 A15 : 0x3fcc34d0 SAR : 0x04b13c0a EXCCAUSE: 0x02a6d73c EXCVADDR: 0xff060601 LBEG : 0x6d000040 LEND : 0x59061102 LCOUNT : 0xed4a4ac1 Backtrace: 0x403743bd:0x3fcc3330 0x0a0219fe:0x3fcc3350 |<-CORRUPTED ``` As far as I can tell, there is plenty of memory left `free heap: 138.95 kB ┇ free PSRAM: 7.89 MB ┇ db size: 558 bytes ┇ db record count: 3 ┇ filesystem free: 6.06 MB ┇ uptime: 6h 57m 40s ` Do you have any suggestions for me? Thanks JT-DE
sascha_hemi added the bug label 2026-03-20 17:27:52 +01:00
sascha_hemi commented 2026-03-20 17:27:52 +01:00
Author
Owner
Copy Link

@atc1441 commented on GitHub (Sep 4, 2024):

This is the current state of the BLE Implementation.
Crashes and overheating do happen every now and then, the AP should recover from it.
It is currently advised to use the ZigBee OEPL Connection variant if possible

<!-- gh-comment-id:2328234344 --> @atc1441 commented on GitHub (Sep 4, 2024): This is the current state of the BLE Implementation. Crashes and overheating do happen every now and then, the AP should recover from it. It is currently advised to use the ZigBee OEPL Connection variant if possible
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
88MZ100 FW
ARM Tag FW
ap fw
bug
documentation
enhancement
good first issue
nRF FW
pull-request
Mirrored from GitHub Pull Request
 question
tag fw
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
sascha_hemi
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#213
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?