Callbacks and their contexts

General
1

Hi all,

As discussed in an earlier thread, I still fight with spurious resets of the ESP8266. It seems to be a problem with stack or heap, because both of them are quite small.
All my application code is called inside of Mongoose callbacks, exclusively. So, my questions are the following:

  • In which context are these callbacks called?
  • Are these callbacks called strictly sequentially?
  • Can these callbacks interrupt one another?
  • Is the Uart callback called in the interrupt context?
  • Why some ‘hook functions’ start with ‘mgos_’ and some with ‘mg_’, what is the difference?

I use the following hooks for the application callbacks (while the two server callbacks are hooked from application code called by one timer callback):

Timer:       mgos_set_timer(SHEDULE_TIME_MS, MGOS_TIMER_REPEAT, sheduleTimer_cb, NULL);
UDP server:  mg_bind(mgos_get_mgr(), uri, udpConn_cb, NULL);
Http server: mgos_register_http_endpoint(pUrlPath, httpConn_cb, NULL);
UDP client:  mg_connect(mgos_get_mgr(), url, udpConn_cb, NULL);
Http client: mg_connect_http(mgos_get_mgr(), httpConn_cb, this, pUrl, NULL, NULL);
Uart:        mgos_uart_set_dispatcher(m_iUartNr, uartDispatcher_cb, NULL);

Thanks for any help and
kind regards
Rolf

2

I sort of answered most of your concerns here in another thread
AFAIK from your point of view as an application programmer, everything is one single context unless you use interrupt context callbacks, which AFAIK are restricted to hardware timer interrupts and are clearly indicated in the docs. All your code will behave as run to completion, no callback will preempt another (except hw ints but you don’t seem to be using them).
mgos_ stands for Mongoose-OS, the event-oriented framework; while mg_ seems to stand for Mongoose, which is the HTTP server and protocol stack handling many network services such as MQTT and UDP.

3

Thanks scaprile, I expected this.
But my spurious resets still exist. I monitor the reset reasons and see ‘REASON_SOFT_RESTART’ for all of the unexpected resets.
My application code is not able to cause such a reset. So my next question is:
What can be the reason that Mongoose triggers such a system restart?
Heap problem?
Stack problem?
Too much time spent in an system event (for example because of time consuming UDP or Http connection)?

4

mOS should handle all expected stuff, the only thing it can handle (disregarding possible bugs on their side) is memory trashes, heap overflow, stack overflow… AFAIK there is no on-board PMU.
The usual stuff is a core dump, try to at least post your soft reset, perhaps someone can shine some light.
Power supply issues usually fire BOR and POR but noisy environments could trigger anything…