ESP-Marius
commented
1 year ago Hi @SolidStateLEDLighting,
I just updated my IDF 4.4.1 to newest branch
By newest branch do you mean v4.4.5 or master?
Just from looking at the log here it is a bit hard to see what is wrong but here are some suggestions/questions:
Is the queue allocated on the heap? Are you able to hook up a JTAG and watch the variable? Then you could at least find who/what is writing to it when it changes. Is it possible to isolate the error, e.g. can you reproduce it by just running parts of the app (lets say without the wifi/network communication)?
SolidStateLEDLighting
Answers checklist.
IDF version.
4.4.1
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
Custom Board
Power Supply used.
USB
What is the expected behavior?
I just updated my IDF 4.4.1 to newest branch. The execution binary did increase in size substantially. The error has persisted.
What is the actual behavior?
Over the course of development I have seen and continue to see mysterious changes in variables which are subtle. I have seen a boolean change in value, I have seen pointers become invalid. And currently I am seeing a pointer to an RTOS queue change during run time - making that pointer unusable.
Here is some print statements that show the change in the value of the pointer. The image here captures a change early in operation before I call on that Queue pointer for action inside the Camera object. (the Queue works in other objects). When I call on that pointer, the program tries to send a message to this queue and then hangs on a statement looking for the queue to be emptied from the receiver.
TAG values indicate all the different objects in the build.
This code area has been stable and running correctly for a while now. So, I'm thinking this has something to do with the expanding size of the program file and how it is configured in memory. I have studied all that I can and tested a variety of selections of memory configuration without any forward progress.
Steps to reproduce.
My systemCmdRequestsQue variable is corrupted just after I cross over this xQueuePeek function during the normal course of option. That variable is ok and useable before that point.
if (xQueuePeek(camCmdRequestsQue, &(ptrCAMCmdRequest), pdMS_TO_TICKS(95))) // Acts as just a single document Mailbox { heap_caps_check_integrity_all(true); ESP_LOGW(TAG, "Run POST-xQueuePeek systemCmdRequestsQue %d", (int)systemCmdRequestsQue); }
Debug Logs.
More Information.
I have been developing on the Esp32 for about 4 years in C/C++. This project is fairy large and running on a Esp32s3 WROOM-1 N16R8. There are 21 threads running. heap_caps_check_integrity_all(true) is called on a regular basis and reveals nothing in this case. The project has Wifi, AWS IOT Core, and a Camera driver. Project is component based and builds in a predictable fashion.
................................................... Total Number of Tasks 21 name priority high water mark ipc0 24 1360 ipc1 24 1352 wifi 23 4388 esp_timer 22 3176 camtask 23 2268 SYS::TMR 8 3404 SYS::RUN 7 3068 SYS::GPIO 7 2380 IND::RUN 7 1228 WIFI::RUN 7 2720 SNTP::RUN 7 1188 RFID::RUN 7 3212 PROX::RUN 7 6236 IOT::RUN 7 3404 IOT::AWS 7 14648 CAM::RUN 7 15976 sys_evt 20 1580 tiT 18 2604 main 1 1652 IDLE0 and IDLE1 tasks are always priority 0. ...................................................
Total sizes: Used static IRAM: 80538 bytes ( 206182 remain, 28.1% used) .text size: 79511 bytes .vectors size: 1027 bytes Used stat D/IRAM: 48905 bytes ( 86263 remain, 36.2% used) .data size: 20841 bytes .bss size: 28064 bytes Used Flash size : 1274968 bytes .text : 990123 bytes .rodata : 284589 bytes Total image size: 1376347 bytes (.bin may be padded larger)