I don't own this kit, but I have tested on the ESP32 micromod on 2.0.14 and got the same issue.
The root cause is related to the code disabling interrupts at critical moment. An ESP32 will not like that (
https://www.esp32.com/viewtopic.php?f=19&t=30500) :
You can't just go and disable interrupts indefinitely: the OS needs those to handle WiFi, housekeeping etc. As such, interrupts that are disabled for a long time are seen as a symptom of a program gone awry, and we have a watchdog that resets the ESP in that case.
In adi_mac.c there is a macro called : ADI_HAL_ENTER_CRITICAL_SECTION();
In hal.h that is defined as: ADI_HAL_ENTER_CRITICAL_SECTION(...) BSP_disableInterrupts()
This function is defined in boardsupport_ard.cpp on line 89. Here it does noInterrupt() except of the Artemis and RP2040.
It should also exclude ESP32. Maybe in the earlier version of the ESP32 library noInterrrupts() was defined empty.
To make things worse in in BSP_enableInterrupts() (which is called at the exit of a critical section with ADI_HAL_EXIT_CRITICAL_SECTION) instead of enabling it also calls noInterrupt() again !!. ???
As this Macro is used on several different places,
the best way around is in hal.h around line 43 change
Code: Select all/*! Disables all processor interrupts. */
#define ADI_HAL_ENTER_CRITICAL_SECTION(...) BSP_disableInterrupts()
/*! Re-enables processor interrupts. */
#define ADI_HAL_EXIT_CRITICAL_SECTION(...) BSP_enableInterrupts()
to
Code: Select all/*! Disables all processor interrupts. */
#define ADI_HAL_ENTER_CRITICAL_SECTION(...) // BSP_disableInterrupts()
/*! Re-enables processor interrupts. */
#define ADI_HAL_EXIT_CRITICAL_SECTION(...) // BSP_enableInterrupts()
After that it did not panic anymore.. but as I do not have the kit of course I got the message
" Failed to connect to ADIN1110 MACPHY. Make sure board is connected and pins are defined for target."