dev 1153 ???

[osos]

What does:

dev 1153

ets Jan 8 2013,rst cause:4, boot mode:(1,6)

wdt reset

mean?

get this rather random. After a "dev 1153" message the device resets after a short while.

I cant seem to find the cause.

[3bb]

I have the same problem after some socket requests.

[FayeY]

Could you provide any test project or test logs for reproducing the problem and debugging?

[alxAgu]

Getting the same (error?) message and then a wdt reset.

[eriksl]

Watchdog reset. Control not given back to the SDK code in time. Don't have the CPU run in your code for more than 100-1000 milliseconds. 100 milliseconds for fluent WLAN operation, 1 s if you really can't avoid it. Use tasks in task queues.

[alxAgu]

@eriksl, wdt resets don't usually show that particular debug message (dev 1153). A reset by the watchdog doesn't seem to be the cause, but rather an unintended consequence? The dev 1153 shows up right before the system hangs, making the watchdog kick in after a few secs.

After some tests I noticed I can replicate this if:

1. There is a gpio interrupt triggering at 50hz or more.
2. The interrupt routine lasts at least 3ms.
3. The module is connected to an AP (even if no sockets connected)

The bug is rather random at this point, some time takes over 15 mins to show up, sometimes just a few secs after boot up. If you either disable interrupts OR disconnect from the AP, the error stops.

Any ideas?

A.

[eriksl]

That could very well be possible. I have had issues with GPIO interrupts for ages and at some time I gave up. It could be either software (bug in the SDK code that gets called before our ISR) or a hardware issue. The GPIO interrupt handles bouncing and noise very badly. It looks like the GPIO interupt isn't masked until the user ISR is called which can lead to a race where the ISR is called multiple times for one event. And that might trash the stack or something else bad.

I worked around this by adding a hardware debouncer and stop using GPIO interrupts, I now poll the pins using a 100 Hz timer which is quick enough for me.

[FayeY]

Hi @alxAgu , could you share the test code so we can reproduce the issue and help debug it? Thanks.

[alxAgu]

Hi @alxAgu , could you share the test code so we can reproduce the issue and help debug it? Thanks.

Thanks @FayeY, I will try to get something ready soon (it's a private code so I need to prepare a stripped-down version). In the meantime, is there any explanation for the meaning of this message? It looks like it was put there for a reason, It would be very helpful to know what triggers it.

[alxAgu]

@FayeY I'm attaching the test code. It takes 5 to 20 min for the error to show up. Thanks.

DEV_1153-MCVE.zip

Update: Forgot to mention that the interrupt pin should be attached to a clock source of at least 100hz.

[alxAgu]

Is anyone from espressif even checking this? @FayeY? :(

[cnlohr]

It's Chinese New Year, @alxAgu - most companies will come back online in the next few days, but almost all companies are off during this period.

[alxAgu]

Just following up on this. I don't want this bug to remain ignored.

I'm not completely sure at this stage (more testing needed) but I noticed some routers increase the chances of the bug showing up, as it does to have an active TCP connection.

A while back I thought that the cause of this may be an interrupt being triggered while the processor was busy doing some obscure networking magic, so I decided to disable interrupts between espconn_send and sent_callbacks but no luck. In fact, the MCVE example I uploaded last month doesn't even create a TCP connection. So, we are back to square one.

I'm convinced this bug is related to another one I reported directly on espressif's forums since its behavior is VERY similar. Unfortunately, it also remains unanswered: https://bbs.espressif.com/viewtopic.php?f=7&t=25689

Can someone from espressif please let us know if this is even being looked at? @FayeY? Anyone?

Thanks.

[FayeY]

Hi,

Yes, we have came back to work after the Chinese new year.
This issue has been forwarded to our internal engineers, we will feedback to you as soon as there is any update.

Thanks.

[alxAgu]

Hi FayeY, Thanks for getting back to me on this. It looks like you haven't defined the xtensa tools PATH. There is a README file inside the 'doc' folder with instructions on how to compile it. Please have a look and let me know if you are still having issues. Regards, A.

…

On Thu, 21 Feb 2019 at 18:17, FayeY ***@***.***> wrote: Hi @alxAgu <https://github.com/alxAgu> , Sorry that we fail to compile the test code you provided. Here is the fail log. [image: jvon4 m_r69ea j4 t b7c] <https://user-images.githubusercontent.com/26587571/53153803-2c1e8200-35f4-11e9-82c8-d62a288f3287.jpg> Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#90 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACEKzvJDYSUWRT4amLPUuwl3w5Yma_mmks5vPlYlgaJpZM4RooIr> .

[alxAgu]

Hi, just checking on this and humbly requesting to keep it somewhere in your calendar so it won't get pushed back to the end of the queue. Thanks and looking forward to the updates.