mac 985 ?

[alex323qp]

Hi guys,

I started to get this message and a WTD reset after implementing a UDP sender.

I'm sending less than 100 bytes every 20ms or so. The send is triggered by an external interrupt. After the first espconn_send the IRQ is disabled until sent_callback is called, then the IRQ is re-enabled.

Does anyone have any idea of what it means?

Thanks,

A.

[alex323qp]

Just an update. This is also happening when only TCP is working, so no UDP related as I originally thought. Having been able to isolate the problem. Very similar to the dev 1153, also still unanswered:

https://github.com/espressif/ESP8266_NO ... /issues/90
https://bbs.espressif.com/viewtopic.php?f=7&t=10424


A.

[AgentSmithers]

How are you implementing these functions? Are they from including a header then calling an init function to the respective TCP or UDP setup you have? This is the way I do it and one of the landmines I landed on was that the headers sometimes shared variables with the same name so when I called functions to the UDP it would tug on TCP sockets and crash. Took me an hour to figure it out then start comparing the files making the variables unique so the TCP functions would only affect the TCP espconn and the UDP with the UDPespconn.

Another thing is WDT only kicks off when frozen so I would add os_printf lines to your code to see where the execution pauses before the WDT kicks off. Things can be a bit harder to track down if you have timers kicking off functions too as they can cause a WDT in the background and cause red herrings.

[alex323qp]

Hi AgentSmithers,

Thanks for the reply!

Yeah, I do have wrappers in the header files that are used as event handlers for the espconn_xxxx callbacks, but my socket class has a private variable (_protocol) that should be unique between instances:

Code: Select all

// Callback wrapper in the header file (MySocketClass.h)
static void _onDataWrapper(void *args, char *data, unsigned short len) {
      if(NULL != args){
         struct espconn *connection = (struct espconn *) args;
         // "reverse" points to the original object ( _conn.reverse = (void *) this; )
         MySocketClass *obj = static_cast<MySocketClass*>(connection->reverse);
         if(obj->_protocol == SOCKET_TYPE_TCP){
            obj->onTCPDataSent();
         }else if(obj->_protocol == SOCKET_TYPE_UDP){
            obj->onUDPDataSent();
         }
      }
}


Anyway, as I mentioned in my update post, I rolled back to a version of the code without the UDP implementation and the same issue showed up, so it doesn't seem to be related.

Regarding the debug messages, it's a good idea, but I've been reluctant to do it because it would require adding printfs inside ISRs that might affect the behaviour in other unexpected ways, not to mention the full application has dozens of files some with thousands of lines, and since we don't know what's causing the problem It will take a while to debug the whole thing. Will give it a try though.

I'm still hoping someone from espressif will step in and throw some light on this issue.

Thanks again,

A.

[Her Mary]

ESP8266 RTOS may be a better choice, it is much more active. https://github.com/espressif/ESP8266_RTOS_SDK

[alex323qp]

Migrating the code is not an option at this stage, would take months.

[AgentSmithers]

Migrating the code is not an option at this stage, would take months.

Dude, No shit.. I feel you on that one
I have a bunch I have to convert myself to move to ESP32 to the point where I almost never want to.

I don't know if this will help your situation but are you debugging with that Breakpoint Stub? The issue is I'm not sure if it will disclose the stack trace for the WDT. Hmmmm, Not your kinda just spurred an idea. I'm pretty sure I want to write a Stacktrace tracker in SPI.. if the chip crashes maybe I can emulate a crash dump somehow to track current processes hmmmm.....