System reset by watchdog after UDP send, message "mac 662"

[ghost]

This issue seems new using core 2.0.0. The sketch sends an UDP broadcast message every 30 seconds and crashes randomly several times a day.

Serial debug shows this message from the core:

mac 662

and then the watchdog kicks in and reboots the ESP.

The sketch does not really much more than this:

IPAddress broadcastIP(255, 255, 255, 255);
portUDP.beginPacket(broadcastIP, Settings.UDPPort);
portUDP.write(data, 20);
portUDP.endPacket();

Anyone that knows what the mac 662 message is telling me?
(if I disable the UDP send, sketch is stable)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[igrr]

Make sure you (or libraries which you use) do not disable interrupts for
more than 20 microseconds.
Disabling interrupts is the usual cause of "mac 662" assertion.

On Wed, Dec 16, 2015, 19:05 mvdbro [email protected] wrote:

This issue seems new using core 200 The sketch sends an UDP broadcast
message every 30 seconds and crashes randomly several times a day

Serial debug shows this message from the core:

mac 662

and then the watchdog kicks in and reboots the ESP

The sketch does not really much more than this:

IPAddress broadcastIP(255, 255, 255, 255);
portUDPbeginPacket(broadcastIP, SettingsUDPPort);
portUDPwrite(data, 20);
portUDPendPacket();

Anyone that knows what the mac 662 message is telling me?
(if I disable the UDP send, sketch is stable)

—
Reply to this email directly or view it on GitHub
#1229.

[ghost]

Thanks for your reply! Some comments on this:

1. We're using dallas sensors and the ESP8277 onewire library contains stuff like this:

noInterrupts();
DIRECT_MODE_INPUT(reg, mask); // allow it to float
delayMicroseconds(70);
r = !DIRECT_READ(reg, mask);
interrupts();

So this 70 uSec delay could be an issue? Sending through HTTP client right after reading the sensor has never been a problem.

2. The whole sketch runs fine without using UDP. The HTTPclient is much more heavily used in the same sketch without issues.

So it seems specific only to UDP (or just coincidence that when it crashes, it's allways just after the UDP send...)

[igrr]

Actually this should happen shortly after you return from an interrupts/noInterrupts block.
I guess OneWire library needs to be fixed. I wonder if it will work if you just remove interrupts/noInterrupts.

[devyte]

@mvdbro is this issue still valid with latest git? with PR #3362 ?

[devyte]

Closing due to lack of feedback and age.