Just bought Single Pair Ethernet kit (KIT-19628 + 1 additional SparkFun MicroMod ESP32 Processor) and found ALL SparkFun examples are causing WDT triggering:
Guru Meditation Error: Core 1 panic’ed (Interrupt wdt timeout on CPU1).
After quick research I found the examples are functional if the ESP32 core is downgraded to 2.04. Unfortunately I can not use this version of the core for the rest of my code. Please support.
The easiest workaround is to simply choose a different processor - which esp32 were you using? I can suggest some comparable alternatives
Thanks for your prompt reply. Changing the processor is not an option. We are developing a device that supports WiFi, Bluetooth and lot of peripheral devices that are already implemented (HW & FW). It is based on ESP32 WROOM and our target is to integrate SPE. That is the reason we choose your ESP32 devkit.
While trying to debug the problem, we reached the macDriverEntry.Init() function - line 91 of adin1110.c file. It looks like the problem is one and same for all SparkFun examples and some support from your side will be appreciated.
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
/*! 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
/*! 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."
Thank you Paul.
It still reboots after it starts communicating with the second board, but your observations and advice are great. I also need to pay attention to the other interrupts used in our program, but taking your advice into account, I hope we can adapt the rest of the code. Thank you!
good to hear the progress.
I would first try to get example1 going and build from there.
This was very helpful in getting the Example ADIN1110 library working. Thanks