In order to ensure the performance (and especially the reliability) of the Simple script programmable Controller, it took me a while to upgrade the ESP8266 sdk used by the controller from version 2.xx to version 3.xx;
The ESP8266 RTOS SDK V3.0 updates the system architecture and adjusts it to be consistent with the ESP-IDF. This means that the same set of application code has the opportunity to be applied to products with different chips (ESP8266, ESP32, ESP32-S2 chips).
The updates are mainly:
1, using eso-idf code framework
2、 Refactor some and core libraries, including WiFi libraries and libmain.
3、 Update third-party libraries, such as freertos, lwip, mbedTLS, noPoll, libcoap, SPIFFS, cJSON, wolfSSL and so on.
4, update some driver libraries
After modifying the code and compiling it, I cleaned up the compiler's warning messages one by one, mainly the warning signals of data conversion, unused data, and variables that may not be initialized when used;
The whole migration process mainly encountered the following problems.
(1) with the upper automatic test web page download, run for a period of time after the esp8266 program crash restart, respectively, there are two kinds of error messages:
assertion “tcp_write: no pbufs on queue => both queues empty” failed: file “E:/software/esptool/ESP8266_RTOS_SDK/components/lwip/lwip/src/core /tcp_out.c”, line 347, function: tcp_write_checks
abort() was called at PC 0x4022a500 on core 0
Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled.
Based on the information from coredump, use the command xtensa-lx106-elf-addr2line.exe -pfiaC -e build/IOMODULE.elf 0x40221bba:0x3fff2d90
The stack trace of the error, found to be lwip's tcp_out and tcp_write function execution error, troubleshooting found to be freertos start task when the allocation of stack space is not enough, so that the data placed on the stack is destroyed, resulting in some inexplicable problems, when the size of the stack space is set to 8192, tcp long time automatically send and receive not found again. program crash restart problem.
xTaskCreate(&httpd_task, “http server”, 8192, NULL, 10, NULL);
2) The problem of mutual exclusion of the data receiving event response of the tcp server and the variable of the main task. In the controller's code, in order to ensure the real-time execution of the control program, in the data receiving event of the tcp server, only the data is put into the ring queue of receiving, while in the main task, the data is taken out from the ring queue to be processed and the answer is sent;
Therefore, there is a situation where two different tasks operate the ring queue at the same time, and due to the misplacement of the mutex lock, the dequeuing count value in the ring queue is mistakenly cleared before it is processed by the main task, resulting in interruptions of the TCP auto-communication test with the test host every once in a while;
The problem was solved when the mutex lock was used correctly.
if (xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
...
xSemaphoreGive(xMutex);
}
Top comments (0)