STM32F4-discovery + mrf24j40 not working #19711
Comments
|
|
|
mrf24j40 driver seems to work normally, but can´t send any packet from it. |
maribu
added
the
Type: bug
|
Thx for bug report. Are you able to ping (or even txtsend) other nodes? I wonder, if this is indeed an issue with the network device driver or rather an issue independent of the driver. |
I finally got it. I have attached the WAKE pin to the VCC and everything start to work. Next week I will test more nodes to make sure it's working. |
|
Thanks again for the bug report. Documentation was added so that other uses don't run into the same issue. Hopefully someone will find time to also actually extend the driver to handle the wake pin (if specified If you run in other issues, please report :) We are happy to help. |
|
Actually, I can still reproduce this bug. In my case, the spam of |
|
I sadly do not have an mrf24j40 available to reproduce. Would you mind to git bisect to identify which commit introduced the issue? |
is the first commit with these kind of errors like below and as shown by @gustavowd : During my EDIT: After more extensive testing, I can confirm that |
Example of results I have (and this cycles indefinitely). |
|
@Carton32 could you enable debug on |
|
amd could you also apply this patch to 91a299c ? diff --git a/sys/net/link_layer/ieee802154/submac.c b/sys/net/link_layer/ieee802154/submac.c
index 471bc0c32d..548f53e61f 100644
--- a/sys/net/link_layer/ieee802154/submac.c
+++ b/sys/net/link_layer/ieee802154/submac.c
@@ -408,6 +408,7 @@ int ieee802154_send(ieee802154_submac_t *submac, const iolist_t *iolist)
ieee802154_fsm_state_t current_state = submac->fsm_state;
if (current_state != IEEE802154_FSM_STATE_RX && current_state != IEEE802154_FSM_STATE_IDLE) {
+ puts("1");
return -EBUSY;
}
@@ -426,6 +427,7 @@ int ieee802154_send(ieee802154_submac_t *submac, const iolist_t *iolist)
if (ieee802154_submac_process_ev(submac, IEEE802154_FSM_EV_REQUEST_TX)
!= IEEE802154_FSM_STATE_PREPARE) {
+ puts("2");
return -EBUSY;
}
return 0;and post back the results? |
|
This is what I get on the revision 2 of my custom board: The repetition of "1" goes on indefinitely but shell is still responding. I've done the same test on the revision 1 of this custom board and the bug does not occur. The differences in passive components around the MRF24J40MD are:
Rev2:
I've tired on Rev2:
It's definitely hardware related but not only as the commits before |
|
hi @Carton32, from what I can see this is likely a hardware issue which could be triggered by missing an IRQ. Please mind that commit 91a299c introduces a new SubMAC layer for that driver, which expects a completely different behavior from the device. So, it is not possible to compare 91a299c with the previous commits because it is essentially comparing two different things. The Radio HAL + SubMAC implementations are more strict with validation, which exposes bugs that wouldn't have been detected with the old interface. Therefore, if Rev2 works as expected with the right configuration, I would just assume it is a hardware thing that got catched by the SubMAC. |
|
Hi @jia200x, Yes. I'm aware of these big changes and it was no surprise to me that my I think we can close the issue. I will try to find a workaround on my side. Thanks for your help! |
We got in the past some cases of working implementations that had quirks when doing very specific stuff. These usually went undetected for a long time, unless you had the bad luck of triggering some. Could you try reproducing the same bug with the newest SubMAC implementation in master? That should give more information whether there's an invalid state transition of there's a missing interrupt. I prepared this patch on top of 8b83280 that could give some insights: diff --git a/sys/net/link_layer/ieee802154/submac.c b/sys/net/link_layer/ieee802154/submac.c
index 471bc0c32d..6749ae9feb 100644
--- a/sys/net/link_layer/ieee802154/submac.c
+++ b/sys/net/link_layer/ieee802154/submac.c
@@ -81,6 +81,7 @@ static ieee802154_fsm_state_t _tx_end(ieee802154_submac_t *submac, int status,
assert(res >= 0);
submac->cb->tx_done(submac, status, info);
+ puts("D");
return IEEE802154_FSM_STATE_IDLE;
}
@@ -120,6 +121,7 @@ static int _handle_fsm_ev_request_tx(ieee802154_submac_t *submac)
int res = ieee802154_radio_set_idle(dev, false);
if (res < 0) {
+ puts("1");
return res;
}
else {
@@ -149,6 +151,7 @@ static ieee802154_fsm_state_t _fsm_state_rx(ieee802154_submac_t *submac, ieee802
while (ieee802154_radio_set_idle(&submac->dev, false) < 0) {}
if (ieee802154_radio_len(&submac->dev) > (int)IEEE802154_MIN_FRAME_LEN) {
submac->cb->rx_done(submac);
+ puts("3");
return IEEE802154_FSM_STATE_IDLE;
}
else { |
|
I can reproduce on Here's the output with the patch applied: First EDIT: |
|
If I set ENABLE_DEBUG to 1 in |
|
Something interesting. If I maintain the MRF24J40 in a reset state with its reset pin held to low during initialization, the bug disappear. |
|
From the logs it looks like as if the device was not generating more IRQ. But in any case, it could be that the initialization / reset was not done properly (as you describe in #19711 (comment)). Does this completely remove the bug? |
This is what I get on dacc4ff with Interrupts work even after several "pairs of reboots".
Yes. I couldn't reproduce the bug a single time with this patch. EDIT: The patch is not enough if I unplug my STLinkV2 + the UART-USB adapter. The radio doesn't work after all hard boots. Only some of them. If I keep the patch applied and I comment out the at the end of |
Description
Example: Cannot run gnrc_networking application for stm32f4-discovery board + mrf24j40 driver.
Steps to reproduce the issue
Basically compile and flash the example to the board.
Expected results
The gnrc_networking application runs and create a new rpl dodag
Actual results
The gnrc_networking application runs, but there is error in the rpl network.
Versions
Operating system: Ubuntu 23.04
Build environment:
Operating System Environment
Installed compiler toolchains
riscv64-unknown-elf-gcc: missing
riscv-none-embed-gcc: missing
riscv32-esp-elf-gcc: missing
xtensa-esp32-elf-gcc: missing
xtensa-esp32s2-elf-gcc: missing
xtensa-esp32s3-elf-gcc: missing
xtensa-esp8266-elf-gcc: missing
clang: missing
Installed compiler libs
riscv64-unknown-elf-newlib: missing
riscv-none-embed-newlib: missing
riscv32-esp-elf-newlib: missing
xtensa-esp32-elf-newlib: missing
xtensa-esp32s2-elf-newlib: missing
xtensa-esp32s3-elf-newlib: missing
xtensa-esp8266-elf-newlib: missing
avr-libc: missing (missing)
Installed development tools
The text was updated successfully, but these errors were encountered: