ESP8266 Developer Zone

Re: dev 1153 ?

2019-04-08T07:26:35+08:00

Well done! I think I've experienced this before so Ill note it.

Statistics: Posted by AgentSmithers — Mon Apr 08, 2019 7:26 am

Re: dev 1153 ?

2019-04-08T05:53:05+08:00

For those having this issue, the Espressif team released an update (v3.0.0) back on March that among other things tried to address this problem. Although the number of error messages was reduced significantly, a new error code (dev 1163) seemed to have replaced the previous one with pretty much the same effects (wdt reset).

Last week @FayeY pointed out that the time inside the ISR is limited to only microseconds, which was significantly less than what my application was using. After reducing this time to something less than 100us, these error messages stopped showing up.

I'm linking again the original thread in GitHub in case it helps anyone else: https://github.com/espressif/ESP8266_NO ... /issues/90

Cheers.

A.

Statistics: Posted by alex323qp — Mon Apr 08, 2019 5:53 am

Re: dev 1153 ?

2019-02-04T21:06:01+08:00

alex323qp wrote:
I uploaded a mcve to the issue tracker a week ago. No one from espressif seems to care about this though. I'm leaving the link here in case anyone wishes to confirm:

https://github.com/espressif/ESP8266_NO ... /issues/90

A.

Thank you for coming back and leaving a trail.

Statistics: Posted by AgentSmithers — Mon Feb 04, 2019 9:06 pm

Re: dev 1153 ?

2019-02-04T17:50:21+08:00

I uploaded a mcve to the issue tracker a week ago. No one from espressif seems to care about this though. I'm leaving the link here in case anyone wishes to confirm:

https://github.com/espressif/ESP8266_NO ... /issues/90

A.

Statistics: Posted by alex323qp — Mon Feb 04, 2019 5:50 pm

Re: dev 1153 ?

2019-01-26T10:36:15+08:00

Thanks @AgentSmithers appreciate the response!

The WTD reset is not the cause of the problem it is just being triggered after the dev 1153 message and the system hangs for a couple of seconds. Feeding the WTD (already tested from the gpio IRQ) just causes the chip to never come back to life since it gets stuck in whatever dev 1153 is.

Can't, unfortunately, share the code since is the private property of the company I work for. I know it is hard to help without seeing the actual code, apologies. To give you/others more background on what I'm doing, I have an I2C (slave) software implementation that triggers the IRQ routine when the SDA line goes down (START condition). From there, I:

1) Pause interrupts with gpio_pin_intr_state_set.
2) Increase the processor speed to 160 to cope with the demand.
3) A while loop waits for the clock signals and reads the SDA line to decode the message. Bytes are accumulated in a global buffer.
4) Once a STOP condition is detected, a task is posted to allow the user's thread to process the whole message.
5) Restore processor speed to 80Mhz
6) Resume interrupts.

A whole I2C transaction takes between 2.8 to 5ms and repeats every 6ms to 40ms. While this is happening the chip is connected to an AP but no packages are coming in/going out.

Any other suggestions?

Thanks again,

A.

Statistics: Posted by alex323qp — Sat Jan 26, 2019 10:36 am

Re: dev 1153 ?

2019-01-26T00:26:57+08:00

So I think the 1153 means your WDT triggered.
This is due to an amount of time passing in a BLOCKING USERLEVEL thread. So if one of your functions take a full Human second to clear this is where you start to get into trouble..
If the 1153 is your WDT then there is a WDT Feed function that can reset the state of the WDT, If you call it within your loops then you can keep the chip from resetting everything it legitimately can take a full minute for the function to complete.. While that happens other things will queue and process.

What GMT are you on? I'm -8 so if you want to coordinate a remote session (Skype) to review the code let me know.

Statistics: Posted by AgentSmithers — Sat Jan 26, 2019 12:26 am

Re: dev 1153 ?

2019-01-25T15:09:17+08:00

Hi again, sorry for the VERY late response.

Yes, I'm using TCP. I reduced the buffer to 1024 and always waiting for the sent_callback to be called before attempting to send the next package (via task signalling of course). The problem persists.

I have a pin interrupt also working which is the one that triggers the send (again, via task signalling). I thought it could be the cause of the problem so I'm disabling interrupts between espconn_send and sent_callback. It seemed to improve things but still happening from time to time.

Does anyone know what the debug message means and what can I do to fix it?

Thanks and regards,

A.

Statistics: Posted by alex323qp — Fri Jan 25, 2019 3:09 pm

Re: dev 1153 ?

2018-07-07T07:21:34+08:00

TCP?
Im pretty sure the MTU of the esp is like 1460 or so.. Normal PC's are 1500..
What protocol are you using? If it's TCP it may be easyer to split the load and do a WatchDog Soft timer feed to let it breath?

Statistics: Posted by AgentSmithers — Sat Jul 07, 2018 7:21 am

dev 1153 ?

2018-07-06T13:40:40+08:00

Has anyone encountered this error?

It shows up randomly mainly while sending lots of data (the send buffer always full with around 2k bytes), and after a while, I get a wdt reset.

Thanks,

A.

Statistics: Posted by alex323qp — Fri Jul 06, 2018 1:40 pm