mirror of
https://github.com/OpenEPaperLink/OpenEPaperLink.git
synced 2026-03-21 00:04:28 +01:00
[GH-ISSUE #403] missing esp_ieee802154_receive_handle_done() function call causing stop of ZigBee reception #3004
Assignees
sascha_hemi
Clear assignees
sascha_hemi
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/OpenEPaperLink#3004
Reference in New Issue
Block a user
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?
Originally created by @m-meltner on GitHub (Nov 25, 2024).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/403
Describe the bug
After 20 receptions on OpenEPaperLink_esp32_C6_AP no more packets are received over ZigBee. All previous packets arrive just fine.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
continuous reception of packets
Additional context
See: https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/migration-guides/release-5.x/5.1/ieee802154.html
Fix:
I added a call to esp_ieee802154_receive_handle_done() in function esp_ieee802154_receive_done in file "radio.c". This makes it work just fine.
@skiphansen commented on GitHub (Nov 25, 2024):
I think this is related to the version of IDF used. The auto builds use "the latest" and do not have this issue. What version of IDF do you use?
@m-meltner commented on GitHub (Nov 25, 2024):
Hello,
here my output when I activate IDF:
. espdl/esp-idf/export.sh
Checking "python3" ...
Python 3.11.7
"python3" has been detected
Activating ESP-IDF 5.5
Done! You can now compile ESP-IDF projects.
Go to the project directory and run:
idf.py build
@skiphansen commented on GitHub (Nov 25, 2024):
Interesting.
Commit
5c421648d1deleted that exact call and replaced it with a call to esp_ieee802154_receive_sfd_done() because it caused compile errors with ESP-IDF v5.3-dev-1043-g8c9e29898f.I'll do some testing.
I'm reluctant to merge the change even though it looks correct because the current code seems to be working for the majority of the users.
What kind of AP are you using?
It would be interesting to know if the official 2.70 release works for you.
@m-meltner commented on GitHub (Nov 26, 2024):
Hello,
first big thanks for this software, really nice!
For reference my code as it works fine now is this:
void esp_ieee802154_receive_done(uint8_t *frame, esp_ieee802154_frame_info_t *frame_info) { ESP_EARLY_LOGI(TAG, "RX %d", frame[0]); BaseType_t xHigherPriorityTaskWoken; static uint8_t inner_rxPKT[130]; memcpy(inner_rxPKT, &frame[0], frame[0] + 1); xQueueSendFromISR(packet_buffer, (void *)&inner_rxPKT, &xHigherPriorityTaskWoken); portYIELD_FROM_ISR_ARG(xHigherPriorityTaskWoken); ESP_ERROR_CHECK(esp_ieee802154_receive_handle_done(frame)); esp_ieee802154_receive_sfd_done(); }Then I use this as hardware:
https://www.waveshare.com/wiki/ESP32-C6-DEV-KIT-N8
Initially I tried to use web gui to download the AP software but this download never finished successfully. I tried many times and it interrupted always at 100000 to 200000 bytes. So then I switched to actual compilation using ESP-IDF framework (v5.5) and then I stumbled upon this error, investigated and added this one line of code to make it work.
I am not very experienced in usage of this ESP-IDF framework so how can I use your official software if this web gui download option does not work for me?
@skiphansen commented on GitHub (Nov 26, 2024):
The binaries are here: https://github.com/OpenEPaperLink/OpenEPaperLink/tree/master/binaries/ESP32-C6
You can use the esptool to flash. I find that copying the command line that IDF uses when flashing and then modifying the arguments is easiest for me. In my case it looks like this:
Thanks for the kind words about the project, but I'm not a primary author. Jelmer, nlimper, atc1441, and jonasniesner are the pillars of the project.
I'm a bit player who added SubGhz support, and probably the one that screwed up the C6 code.
@m-meltner commented on GitHub (Nov 26, 2024):
Hello,
I flashed your release files and the result is the same: after 20 packets the reception stops.
Here the logs:
@skiphansen commented on GitHub (Nov 27, 2024):
Thanks for testing it. I'll do some local testing after Thanksgiving and verify the fix.
@skiphansen commented on GitHub (Dec 7, 2024):
@m-meltner I've verified the problem and fix locally. It turns out that this bug was introduced in version 0x001d but the version installed by the WEB GUI is 0x001c which explains why most people are not experiencing this issue. I'll commit a fix shortly.
Thanks for reporting the issue and fix !!