IEEE 802.15.4 doesn't receive packets after calling esp_ieee802154_receive() (IDFGH-10286) #11549
Comments
github-actions
bot
changed the title
|
Hi @spark404 I have already tried your main.c code, but I did not reproduce this issue. I use your main.c, without macro So, could you please try using another board to send some packets to see if the receiver can receive those packets?(using another board to send packets, using |
|
Hi @zwx1995esp, thank you for assisting with this issue. I followed your recommendation, however I still encounter the issue I mentioned. For reference I've uploaded the two project that I use for verification: https://github.com/spark404/ieee802154-receiver The output from the sender is as follows: The receiver output (without the define) as follows: with the define enabled I see the following I tried switching the roles from between the two boards, but that didn't help. The board I'm using is the ESP32-C6-DevKitC-1. Unfortunately I have no other boards to test this with. |
|
Hi I add some debug info function for getting more infomations for the reason why your board can not receive any messages. Could you please try the code with these two steps and send the two logs to me? (Tips, the log may be too long, so you may need to choose a clear channel, which may not have any IEEE802154 packets(or just very little packets) transmitting on.) Step 1, enable Step 2, only enable |
|
Thanks for putting in this effort! I've attached the output files. PHY_DEBUG + MAKE_IT_WORK PHY_DEBUG |
|
Ok, I will ask for the PHY group for some help on your logs, maybe need some times. |
|
@spark404 Hi, I have already synced with PHY group, and they said, IEEE802154 has already entered rx mode after the first log print, so could you please confirm that if there are some codes modified in your you can also add some logs for this API |
|
Hello @zwx1995esp thank you for keeping track of this. I've ran a test with a log statement on the receive function. Attached are the logs. output_not_working_with_receivecheck.txt I noticed something that might be related. On the receiver application I'm setting the address with: I can retrieve the correct settings as shown in the logs: When I send a message from a sender application to that particular combination of pan and long address it isn't received unless I activate promiscuous mode with esp_ieee802154_set_promiscuous(true). I've tried with regular device connected to the same pan and there the packet is received. I've attached a cap file showing that the broadcast is correctly received but the targeted message isn't. |
|
But, I see your code, If you do not enable the promiscuous mode, the hardware will filter the packets using the rules defined in IEEE802.15.4 spec(only packets match the panid and address can be received or the packets contain the broadcast address or panid can be received). |
|
And could you please push your idf branch to your remote repository and give me a link? I want to try to reproduce with your code base. Also I can leave some commits for debugging on your repository directly. |
|
@zwx1995esp I've updated the receiver and sender code I used to demonstrate the case more clearly I hope this helps. This a small summary of where I am with the debugging. I'll update make the esp-idf branch and update the ticket. The sender app sends a series of packets for testing The receiver app prints debug output for every packet it receives The log output and packet capture for the sequence is attached. What seems to be the current case: |
|
I created the debug repository here: https://github.com/spark404/esp-idf/tree/ieee802154-debug Attached the output from the receiver app with the debug statements (MAKE_IT_WORK enabled): And the same with MAKE_IT_WORK disabled |
|
I think I solved at least part of my problem. The call to set the extended address needs to be in reversed order: If I do that the directed frames arrive as expected. |
|
Sorry for the delay, due to some urgent breaks me. Your issue seems due to the bit order, the extended address is not set rightly as expected. So some frames may be filtered by the hardware. But you enable the promiscuous mode.... If you enable the promiscuous mode, I don't think some frame will be filtered by our hardware. Our in your apps, maybe some other logic before the examples you shared to me.... |
|
@spark404 Do you have any update of the issue? Generally speaking, no frame will be dropped if promiscuous mode is enabled. If promiscuous mode is disabled, hardware will perform the frame filter as defined in the 802.15.4 spec, frames including unexpected destination panid / addresses will be dropped. |
|
Your code was able to communicate with the Digi Xbee S2C 802.15.4 firmware. wonderful!
|
|
I've tried the demo projects I've created with the latest version of esp-idf and everything seems to be working. I verified by removing the workarounds in some other code an no issues anymore. Many thanks for all the support on this! |
espressif-bot
added
Status: Done
Answers checklist.
IDF version.
v5.2-dev-823-g903af13e84
Operating System used.
macOS
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32-C6-DevKitC-1
Power Supply used.
USB
What is the expected behavior?
I expected the call to esp_ieee802154_receive() to enable the driver to receive all packets on the network on a particular channel. This should trigger the corresponding hooks like esp_ieee802154_receive_done and esp_ieee802154_receive_failed but neither are called.
What is the actual behavior?
The expected behaviour is a continuous stream of packets passed to the esp_ieee802154_receive_done handler.
It's important to note here that this does work if the esp_ieee802154_transmit(..) is called before calling esp_ieee802154_receive().
Steps to reproduce.
Use the following main.c
On an active Zigbee network the output with the MAKE_IT_WORK define enabled is:
On the same Zigbee network without the MAKE_IT_WORK define
Debug Logs.
No response
More Information.
No response
The text was updated successfully, but these errors were encountered: