MPU Fault when running central coded bluetooth and ENC28J60 dhcpv4_client

[kienasv]

Describe the bug
I am building the coded bluetooth gateway using nrf52840 and ENC28J60. Integrated between two examples:

• https://github.com/nrfconnect/sdk-nrf/tree/master/samples/bluetooth/central_hr_coded
• https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/dhcpv4_client

I created two task:

void ethernet_task(void) {
  struct net_if *iface;

  printf("Run dhcpv4 client");

  net_mgmt_init_event_callback(&mgmt_cb, net_handler,
				NET_EVENT_IPV4_ADDR_ADD);
  net_mgmt_add_event_callback(&mgmt_cb);

  iface = net_if_get_default();

  net_dhcpv4_start(iface);

  /* Wait for a lease. */
  k_sem_take(&got_address, K_FOREVER);

  printk("Got IP Address");

  while(1) {
    //printk("ethernet task polling");
    k_msleep(1000);
  }
}

void ble_task(void) {
  int err;

  err = bt_enable(NULL);
  if (err) {
    printk("Bluetooth init failed (err %d)\n", err);
    return;
  }

  printk("Bluetooth initialized\n");

  bt_conn_cb_register(&conn_callbacks);

  scan_init();

  err = bt_scan_start(BT_SCAN_TYPE_SCAN_ACTIVE);
  if (err) {
    printk("Scanning failed to start (err %d)\n", err);
    return;
  }

  printk("Scanning successfully started\n");

  while(1) {
    //printk("ble task polling");
    k_msleep(1500);
  }

}

There is no main function. I start two tasks using:

K_THREAD_DEFINE(ethernet_task_id, 1024, ethernet_task, NULL, NULL, NULL,
		3, 0, 0);
K_THREAD_DEFINE(ble_task_id, 1024, ble_task, NULL, NULL, NULL,
		3, 0, 0);

If I just run one task (comment one K_THREAD_DEFINE to prevent it from running), the running task can work perfectly. But if I let two tasks to run simultaneously , the MPU fault occur and CPU reset.

Expected behavior
There is no MPU fault.

Impact
Critical impact on the application when MPU fault occur and CPU reset. The application cannot work.

Logs and console output
�[1B�[9D�[8D�[J[00:00:00.542,663] �[1;31m os: ***** MPU FAULT *****�[0m
�[8D�[J[00:00:00.542,694] �[1;31m os: Data Access Violation�[0m
�[8D�[J[00:00:00.542,694] �[1;31m os: MMFAR Address: 0x30a03�[0m
�[8D�[J[00:00:00.542,694] �[1;31m os: r0/a1: 0x40003000 r1/a2: 0x20007174 r2/a3: 0x00030a03�[0m
�[8D�[J[00:00:00.542,694] �[1;31m os: r3/a4: 0x00000000 r12/ip: 0x20000618 r14/lr: 0x0002ac21�[0m
�[8D�[J[00:00:00.542,724] �[1;31m os: xpsr: 0x81003813�[0m
�[8D�[J[00:00:00.542,724] �[1;31m os: Faulting instruction address (r15/pc): 0x00034688�[0m
�[8D�[J[00:00:00.542,724] �[1;31m os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0�[0m
�[8D�[J[00:00:00.542,724] �[1;31m os: Fault during interrupt handling
�[0m
�[8D�[J[00:00:00.542,755] �[1;31m os: Current thread: 0x20005718 (idle 00)�[0m

Environment (please complete the following information):

• OS: Windows
• Zephyr SDK v2.4.99-nsc1
• nRF Connect SDK v1.5.0
• Commit SHA or Version used

Additional context
Does anyone meet this problem?

[jukkar]

Have you checked where the app is crashing, try for example something like this to get some more info

arm-zephyr-eabi/bin/arm-zephyr-eabi-addr2line -e build/zephyr/zephyr.elf -a 0x00034688

the addr2line program can be found in Zephyr SDK.

net_mgmt_init_event_callback(&mgmt_cb, net_handler,
NET_EVENT_IPV4_ADDR_ADD);

There is also NET_EVENT_IPV4_DHCP_BOUND event that can be also used. The ADDR_ADD event is ok too but if you are using DHCPv4, then the IPV4_DHCP_BOUND event is probably more suitable one to use.

[kienasv]

@jukkar thanks for your help.

I checked with addr2line, the crash position is /nRFConnectSDK/v1.5.0/modules/hal/nordic/nrfx/drivers/src/nrfx_spi.c:254

It happens on the SPI transfer byte process. I increased thread stack size but the problem still occur.

When I run only ethernet task, there is NO problem. The problem only happen when run two tasks simultaneously.

Do you know any method to find out more information about this problem to solve it?
Thanks.

[jukkar]

This seems to be a downstream (nRFConnectSDK) issue, perhaps you could ask info from Nordic forum. @carlescufi does this sound right?

[carlescufi]

This is an nRF Connect SDK issue. Please ask the question in the Nordic Devzone instead. Thanks!