Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP32 heap corruption in CC1101_Receive_Address example #839

Closed
jeffrizzo opened this issue Oct 1, 2023 · 6 comments
Closed

ESP32 heap corruption in CC1101_Receive_Address example #839

jeffrizzo opened this issue Oct 1, 2023 · 6 comments
Labels
bug Something isn't working resolved Issue was resolved (e.g. bug fixed, or feature implemented)

Comments

@jeffrizzo
Copy link

IMPORTANT: Check the wiki
Before submitting new issue, please check the Wiki and the API documentation. You might find a solution to your issue there.

I checked the wiki just in case; didn't see anything.

Describe the bug

I built the CC1101_Receive_Address example because I'm new to RadioLib and the CC1101 module I'm using. When running the sketch on an ESP32 dev board, I see an assert about heap corruption (from the esp32 arduino code, I believe) and it reboots - then gets the assert again, reboots again, etc.

(The ESP32 board is an old one - "ESP32 Devkit V1 www.doit.am", and I've marked it "Rev 0" which I believe is the revision of ESP32 and is probably buggy - though I don't think the bugs it has necessarily relate to this)

I rebuilt with debugging enabled, and the (large, sorry) output is here:

[CC1101] Initializing ...
RadioLib Debug Info
Version:  6.2.0.0
Platform: ESP32
Compiled: Oct  1 2023 12:07:23

R	71	14
M	CC1101
CMD	W	30	0F
CMD	W	36	0F
R	75	1
R	18	4
W	18	14
R	18	14
R	18	14
W	18	14
R	18	14
R	2	3F
W	2	2E
R	2	2E
R	0	29
W	0	2E
R	0	2E
R	7	4
W	7	4
R	7	4
R	8	45
W	8	5
R	8	5
R	8	5
W	8	5
R	8	5
CMD	W	36	0F
R	D	1E
W	D	10
R	D	10
R	E	C4
W	E	B1
R	E	B1
R	F	EC
W	F	3B
R	F	3B
R	3E	C6
W	3E	C0
R	3E	C0
CMD	W	36	0F
R	10	8C
W	10	87
R	10	87
R	11	22
W	11	83
R	11	83
CMD	W	36	0F
R	10	87
W	10	F7
R	10	F7
CMD	W	36	0F
R	15	47
W	15	17
R	15	17
R	15	17
W	15	14
R	15	14
R	3E	C0
W	3E	C0
R	3E	C0
R	8	5
W	8	5
R	8	5
R	6	FF
W	6	3F
R	6	3F
R	7	4
W	7	64
R	7	64
R	13	22
W	13	2
R	13	2
CMD	W	36	0F
R	75	1
R	12	2
W	12	2
R	12	2
CMD	W	36	0F
R	75	1
R	12	2
W	12	2
R	12	2
R	8	5
W	8	5
R	8	5
R	12	2
W	12	2
R	12	2
R	4	D3
W	4	12
R	4	12
R	5	91
W	5	AD
R	5	AD
CMD	W	3A	0F
CMD	W	3B	0F
success!
[CC1101] Setting node address ... R	7	64
W	7	66
R	7	66
R	9	0
W	9	1
R	9	1
success!
[CC1101] Waiting for incoming transmission ... CMD	W	36	0F
R	75	1
CMD	W	3A	0F
R	2	2E
W	2	46
R	2	46
CMD	W	34	0F
R	3F	0
R	7	66
R	3F	83
R	7F
R	7	66
R	3F	3B
R	3F	27
R	17	30
CMD	W	36	1F
R	75	1
CMD	W	3A	0F
CRC error!
[CC1101] Waiting for incoming transmission ... CMD	W	36	0F
R	75	1
CMD	W	3A	0F
R	2	46
W	2	46
R	2	46
CMD	W	34	0F
R	3F	AE
R	7	66
R	3F	83
R	7F	3B	27	AE	21	EC	23	33	2F	8C	85	95	CF	4	E3	C4	26	BA	0	EB	41	FF	2B	9D	DB	0	D3	81	9B	11	31	34	25	A9	35	62	F4	BB	C2	FC	3B	C4	5E	5A	BE	42	9D	67	84	7D	11	75	25	CA	94	EF	D6	0	57	E2	AD	81	D	40	83	3B	27	AE	21	EC	23	33	2F	8C	85	95	CF	4	E3	C4	26	BA	0	EB	41	FF	2B	9D	DB	0	D3	81	9B	11	31	34	25	A9	35	62	F4	BB	C2	FC	3B	C4	5E	5A	BE	42	9D	67	84	7D	11	75	25	CA	94	EF	D6	0	57	E2	AD	81	D	D	40	83	3B	27	AE	21	EC	23	33	2F	8C	85	95	CF	4E3	C4	26	BA	0	EB	41	FF	2B	9D	DB	0D3	81	9B	11	31	34	25	A9	35	62	F4	BB	C2	FC	3B	C4	5E	5A	BE	42
CORRUPT HEAP: Bad head at 0x3ffb9244. Expected 0xabba1234 got 0xcf95858c

assert failed: multi_heap_free multi_heap_poisoning.c:253 (head != NULL)


Backtrace: 0x40083609:0x3ffb24b0 0x40088041:0x3ffb24d0 0x4008d20d:0x3ffb24f0 0x4008ce9b:0x3ffb2620 0x4008393d:0x3ffb2640 0x4008d23d:0x3ffb2660 0x400e66fd:0x3ffb2680 0x400e65b5:0x3ffb26a0 0x400d1b45:0x3ffb26c0 0x400d1d87:0x3ffb26f0 0x400d2625:0x3ffb2730 0x400d2bea:0x3ffb2750 0x400d2a62:0x3ffb2770 0x400d32aa:0x3ffb27a0 0x400d17f2:0x3ffb27e0 0x400d50c1:0x3ffb2820




ELF file SHA256: 75db90343d4e43f0

Rebooting...
+G␔Z��b��␞�$�␀␌w�

To Reproduce

Using RadioLib 6.2.0, and the CC1101_Receive_Address example sketch with ONLY the following line changed to reflect the pinout changes of CS, GDO0 and GDO2 connection on my module:

CC1101 radio = new Module(10, 2, RADIOLIB_NC, 3);

... built with PlatformIO with this in the platformio.ini file:

[env:esp32doit-devkit-v1]
platform = espressif32
board = esp32doit-devkit-v1
framework = arduino
lib_deps =
        jgromes/RadioLib@^6.2.0

Platformio is using this arduino-esp32 release: Arduino Release v2.0.11 based on ESP-IDF v4.4.5

Expected behavior

Expected some amount of output on console depending on the RF environment

Screenshots
If applicable, add screenshots to help explain your problem.

Additional info (please complete):

  • MCU: [e.g. Arduino Uno, ESP8266 etc.]
    ESP32
  • Link to Arduino core: [e.g. https://github.com/stm32duino/Arduino_Core_STM32 when using official STM32 core. See readme for links to all supported cores]
    Arduino Release v2.0.11 based on ESP-IDF v4.4.5
  • Wireless module type [e.g. CC1101, SX1268, etc.]
    CC1101
  • Arduino IDE version [e.g. 1.8.5]

Using PlatformIO, but with an Arduino 2.0.11 base

  • Library version [e.g. 3.0.0]
    6.2.0
@jeffrizzo
Copy link
Author

Just a note - i've also tried it on a newer esp32 board with same result, and on an esp32-c3 (which is riscV based) with a very similar result:

[CC1101] Initializing ... success!
[CC1101] Setting node address ... success!
[CC1101] Waiting for incoming transmission ... CRC error!
[CC1101] Waiting for incoming transmission ... CORRUPT HEAP: Bad head at 0x3fc91e24. Expected 0xabba1234 got 0xcf95cf8c

assert failed: multi_heap_free multi_heap_poisoning.c:253 (head != NULL)
Core  0 register dump:
MEPC    : 0x40381e78  RA      : 0x40384d76  SP      : 0x3fc95c70  GP      : 0x3fc8bc00
TP      : 0x3fc8ada8  T0      : 0x37363534  T1      : 0x7271706f  T2      : 0x33323130
S0/FP   : 0x3fc95de8  S1      : 0x0000007f  A0      : 0x3fc95cd4  A1      : 0x3fc8c975
A2      : 0x00000001  A3      : 0x00000029  A4      : 0x00000001  A5      : 0x3fc8f000
A6      : 0x7a797877  A7      : 0x76757473  S2      : 0x3fc95cc8  S3      : 0x00000001
S4      : 0x3fc95cc8  S5      : 0x40389b6a  S6      : 0x3fc91ddc  S7      : 0x00000000
S8      : 0x00000000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x6e6d6c6b  T4      : 0x6a696867  T5      : 0x66656463  T6      : 0x62613938
MSTATUS : 0x00001801  MTVEC   : 0x40380001  MCAUSE  : 0x00000007  MTVAL   : 0x00000000���	␐��H	9␌��m�m�

(No debugging this time, sorry)

@jgromes
Copy link
Owner

jgromes commented Oct 2, 2023

Looking at the debug output, it looks like it receives a "packet", attempts to retrieve its length which is larger than should be possible, hence some overflow and then the crash. Is something transmitting?

@jeffrizzo
Copy link
Author

I mean, it's possible? As far as I know, I'm not transmitting anything. Also, I get the same behavior when I disconnect the antenna...

@jgromes
Copy link
Owner

jgromes commented Oct 5, 2023

I've seen spurious packet detection on the CC1101 in the past, it is possible this happening again so I will investigate. Unfortunately I currently don't have access to the hardware, so it will take me a couple of days to get to this.

@jgromes
Copy link
Owner

jgromes commented Oct 15, 2023

Had some time to investigate, it looks like that after power up, the device will trigger an "packet received" interrupt, despite the fact there is no packet received. The ISR runs and tries to read the packet from the FIFO, which at that point contains random data - hence the impossible packet length and on ESP32, heap corruption exception.

I think the root cause has something to do with the GDO0 on CC1101 being configured to output clock by default. RadioLib turns that off, but if the timing is wrong, it could trigger an interrupt before it is switched from clock to packet received. So far I was not able to resolve the issue, but I'll keep trying.

@jgromes
Copy link
Owner

jgromes commented Nov 18, 2023

Looks like this is caused by incorrect pakcet length read in blocking mode. I added a patch in the latest commit which should resolve this, but overall I would advise against using blocking receive in favor of interrupt-driver receive.

@jgromes jgromes closed this as completed Nov 18, 2023
@jgromes jgromes added the resolved Issue was resolved (e.g. bug fixed, or feature implemented) label Nov 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working resolved Issue was resolved (e.g. bug fixed, or feature implemented)
Projects
None yet
Development

No branches or pull requests

2 participants