FRDM‑RW612 Zephyr BLE and Ethernet concurrently error

[dani56]

Hello,

I am working with an FRDM‑RW612 board using Zephyr OS 4.3.0 and Zephyr SDK 0.17.4,  Ethernet and Bluetooth LE enabled at the same time.

I am seeing a full board reset whenever the Ethernet link goes down, even though there is no Zephyr panic, assert, watchdog timeout, or software reboot. The ethernet cable stays connected, the error seems to be happening when BLE starts.

I am running a mongoose webserver with HTTP and BLE as an peripheral. During bootup, BLE seems to be initialized fine and also the network starts up and i get an IP and everything, but after a few seconds i get a eth_nxp_enet_mac: Link is down error and the whole board reboots. I observed that i happened when BLE starts after the network init, but it also happens after a few seconds when i change the starup order. Sometimes i cant even get into the main function, the board just restarts.

When I run BLE or the mongoose server alone, everything works fine, its just when both are started together, the board initializes the network and a bit of BLE and then restarts because it gets the link down error and gets stuck in a kind of bootloop.

I also increased the Workqueue stack size and set CONFIG_NET_CONNECTION_MANAGER_AUTO_IF_DOWN=n  but to no effect.

I would like to ask whether this behavior is a known hardware or driver limitation of RW612 when using Ethernet + BLE concurrently or if there is any other solution to this problem.

[RomanVR]

Hi @dani56, hope you are doing well.

In order to better analyze this behavior, I will make some questions:

Could you please provide more details on your integration process?

Additionally, you mentioned that the device reboots when initializing BLE, how is this reboot happening? Is the project freezing at some point or is a full reset going on? In case a full reset is happening, could you please share the reset cause? The latter should be contained in the Reset status Register (SYS_RST_STATUS).

[dani56]

Hello,

thank you for your reply!

My workflow is as following: During boot-up, Zephzyr automatically inits the Ethernet and connects to my local network. After that  my main function is entered and BLE is set up (bt_enable(); and  bt_ready();) and after that mongoose is polling for incoming HTTP traffic in an endless loop.
Usually the program crashes right after initialization of the ethernet, although this can differ depending of the order of BLE or mongoose initialization. 

The System fully resets, the reset cause was read using POWER_GetResetCause() and equals 2, which is a CM4 Lockup according to the reference manual RM00278.

A typical outputlog looks like this, with the cause being printed (first line of the main function):

*** Booting Zephyr OS build v4.3.0 ***
[00:00:09.021,428] <27>[0m<inf> net_config: Initializing network<27>[0m
[00:00:09.021,445] <27>[0m<inf> net_config: Waiting interface 1 (0x10043e08) to be up...<27>[0m
[00:00:09.520,355] <27>[0m<inf> phy_mc_ksz8081: PHY (2) is entering autonegotiation sequence<27>[0m
cause: 2
[00:00:13.359,823] <27>[0m<inf> eth_nxp_enet_mac: Link is down<27>[0m
*** Booting Zephyr OS build v4.3.0 ***
[00:00:13.360,531] <27>[0m<inf> net_config: Initializing network<27>[0m
[00:00:13.360,548] <27>[0m<inf> net_config: Waiting interface 1 (0x10043e08) to be up...<27>[0m
[00:00:13.859,458] <27>[0m<inf> phy_mc_ksz8081: PHY (2) is entering autonegotiation sequence<27>[0m
cause: 2

Best regards,
Daniel

[RomanVR]

Hello @dani56.

Would you help us adding to your project Bluetooth debug logs and share them with me? This will help us printing the logs to try to identify what might be causing the issue.

To do this, please add the following settings to your prj.conf file:

CONFIG_BT_LOG_LEVEL_DBG=y
CONFIG_BT_LOG_LEVEL_ERR=y
CONFIG_BT_LOG_LEVEL_INF=y

As a side note, please make sure that there is enough stack allocated for your threads and ISRs just to discard any overflow issue.

Also, would you help us with more details on how you are carrying the integration process between both functionalities? Since the reset cause seems to be related to a hardfault that goes beyond the first one.