K64F ethernet driver enables interrupts before the interrupt handlers are set

[kuggenhoffen]

Description

• Type: Bug
• Priority: Minor

---

Bug

Target
K64F

Toolchain:
IAR

Toolchain version:
7.80

mbed-cli version:
1.0.0

meed-os sha:
a1c0840 (HEAD, tag: mbed_lib_rev129, tag: mbed-os-5.2.2) Merge pull request #3227 from ARMmbed/release-candidate

DAPLink version:
0242

Expected behavior
Ethernet driver IRQ handlers (ENET_Transmit_IRQHandler, ENET_Receive_IRQHandler or ENET_Error_IRQHandler) should not get called when s_ENETHandle[0] is null.

Actual behavior
It seems that there is a small time window in ENET_Init where interrupts are enabled but the instance handle has not been added to s_ENETHandle resulting in null pointer usage in the interrupt handles in case an interrupt happens within this time window.

Steps to reproduce

1. Debug mbed-os-example-sockets using IAR
2. Run -> observe that example works correctly
3. Reset (Software reset by default)
4. Run -> observe that hardfault happens

In step 3. if one does hardware reset instead of software, the example works correctly.

[0xc0170]

cc @geky

[0xc0170]

cc @mmahadevan108

[mmahadevan108]

Thank you. Indeed seems like an issue, I have passed this on to the driver developer.

[mmahadevan108]

Can this be closed?

[JanneKiiskila]

Should be re-opened. We're still seeing this, unfortunately. Right now with registration-unregistration loop it's popping up with 100% repeatability. @mmahadevan108 @0xc0170

[JanneKiiskila]

16:11:51.831 | D1 <<< DutThread: [3773][DBG ][mClt]: M2MNsdlInterface::find_resource - token ()
16:11:51.841 | D1 <<< DutThread: assertion "handle != NULL" failed: file "./mbed-os/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/drivers/fsl_edma.c", line 826, function: EDMA_HandleIRQ

[0xc0170]

@JanneKiiskila How to reproduce the problem you are seeing?

[JanneKiiskila]

Repeat mbed-cloud-client registration / unregistration in a loop.
@ilposalo has an automated test case for this.

[mmahadevan108]

@JanneKiiskila I had tried the mbed-os-example-sockets test that was mentioned when this issue was created. I do not see the hard fault failure with the steps mentioned.

This issue might be a different one, kindly provide the app and steps to reproduce.

[JanneKiiskila]

Hi @mmahadevan108,

yes indeed it can be a different issue as well. Also this is happening when the device has been running some time already, but I'm afraid I can't share that. Need to see what we can do for a reproducible case.

[bridadan]

@JanneKiiskila It sounds like there's definitely still an outstanding issue here, though the reproducible case may have changed.

I suggest that we leave this issue closed and you can reopen an updated issue when you have a reproducible case you can share. Does that work for you?