Example01a_BasicSendReceive crashes on ESP32

[daveismith]

When attempting to run the Example01a_BasicSendReceive on the ESP32 I get a crash and reboot part way through printing the text from the second frame transmitted. The specific text that is displayed is "Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1)."

Looking into this, it appears to be commonly caused by attempts to print inside an interrupt context. An example of someone having this issue is visible in this stack overflow question. It seemed reasonable the library might be calling this RX callback in an interrupt context, so I removed the prints and replaced them with:

bool messageWaiting = false;
byte rxMessage[MAX_MSG_SIZE];

static void rxCallback(byte * data, int dataLen, byte * senderMac)
{
  memcpy(rxMessage, data, dataLen);
  messageWaiting = true;
}

In my loop, after the delay(5000) I added

    if (messageWaiting) {
      messageWaiting = false;
      Serial.print("Recieved:\t");
      Serial.print(" ");
      Serial.println((char *)rxMessage); //This is ok since we know they are all null terminated strings
      Serial.println();
    }

and the example now works as expected when running against the echo example on the other end. The approach that I took to check this isn't necessarily the cleanest, which is why I haven't PR'd the changes.

[vChavezB]

I am not affiliated with this repo but I have been using the adin1110 in a research project with some arduino boards :)

The ADIN1110 requires an interrupt to process PHY events such as TX complete, RX complete, etc. This is called in an interrupt context

https://github.com/sparkfun/SparkFun_ADIN1110_Arduino_Library/blob/main/src/boardsupport_ard.cpp#L236

Regards
Victor

[alin180493]

When attempting to run the Example01a_BasicSendReceive on the ESP32 I get a crash and reboot part way through printing the text from the second frame transmitted. The specific text that is displayed is "Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1)."

Looking into this, it appears to be commonly caused by attempts to print inside an interrupt context. An example of someone having this issue is visible in this stack overflow question. It seemed reasonable the library might be calling this RX callback in an interrupt context, so I removed the prints and replaced them with:

bool messageWaiting = false;
byte rxMessage[MAX_MSG_SIZE];

static void rxCallback(byte * data, int dataLen, byte * senderMac)
{
  memcpy(rxMessage, data, dataLen);
  messageWaiting = true;
}

In my loop, after the delay(5000) I added

    if (messageWaiting) {
      messageWaiting = false;
      Serial.print("Recieved:\t");
      Serial.print(" ");
      Serial.println((char *)rxMessage); //This is ok since we know they are all null terminated strings
      Serial.println();
    }

and the example now works as expected when running against the echo example on the other end. The approach that I took to check this isn't necessarily the cleanest, which is why I haven't PR'd the changes.

Hi David,

Did you manage to solve the issue? I am confruting with the same thing at the moment.

Is there a sparkfun example pair that might work?

Any code you might be able to share that would be nice.

Regards,
Alin

[daveismith]

I actually switched to ESP-IDF and wrote my own component for the part. I haven't published it because I'm not sure what the licensing of publishing code which relies on the driver from Analog Devices looks like. I was a little disappointed with the lack of support on this repo from SparkFun tbh.

[alin180493]

Thanks for the reply. Unfortunately, I am not as good as you to write my on library. Software is not my strongest skill and I was hoping to have a starting point though the already written library.

The interesting thing is that they have published the codes that they used for the youtube demo and the getting started guide from their website, and none of them are working.

Hmmm...maybe an uprev library will be published soon to fix the issues.

[daveismith]

Possibly. One of the other things that I wanted was the ability to do IP transport from the end device, which wasn't something that the examples supported. That was the primary reason I ended up going a different way.

[alin180493]

Oh wow! that sounds so cool! Any tips of where to start if I want to follow your foot steps?

[daveismith]

I copied one of the SPI ethernet drivers in the ESP-IDF and modelled a driver based on that. Essentially I set up a HAL to be able to talk to the device from the Analog Devices driver, and then started to hook the esp netif functions into that driver.

[alin180493]

Quick update. The Arduino IDE - The ESP32 Board version 2.0.9 is not working with the demo codes. I have installed an older version of 2.0.4 and i made the first example work only if ESP32 has example 1B on it and Artemis has example 1A. The other way around is not working, still getting the boot loop on the ESP32. So i it might be the board firmware used by the Arduino IDE which is not compatible with the SPE library.

Keeping in mind this is a year old issue, I do not expect to get this solved too quickly.

ESP32 - 1B
Artemis - 1A
Working

ESP32 - 1A
Artemis - 1B
NOT Working

[Nacros115]

Hi everyone, does anyone have found a solution to the interrupt problem, without rely on the firmware downgrade of the esp32 board?