[SOLVED] Strange Micropython Code Execution (ESP32) due to old xtensa compiler
Posted: Fri Dec 17, 2021 5:22 pm
Dear community,
since a certain stage of commits in our development, we are facing strange errors: at seemingly random times, some of the try/except sections catch something like this:
First type of error:
even if the regarding lines of code are executed fine otherwise.
Second type of error:
or in the data JSON in a SD card, this is logged:
before "sensor value" is written to SD card, there is some dataprocessing happening in this style:
(note that the dictionary is also used as a parameter to the function, may that be a good architecture decision or not 
)
So, instead of setting the value to the result of the function, the function object itself is written to the position in the dictionary, and the string serialization transforms that into the <...> representation when the dictionary is json.dumps-ed to the SD card. But that just seems another form of the errors of the first kind.
The errors seem only to appear if there is additional C-code present (beginning with a certain commit). It does not matter if the C-code is acutally used; the errors also appear if none of the C-functions are accessed. But they seem to occur more often, if the statically defined data uint8_t - buffers are larger or the C-code is actually used (creates two additional freeRTOS tasks with around 6k of stack each).
So the current hypothesis is: the C-code generates additional flash and RAM usage for the statically allocated buffers and other variables. That may not leave enough stack for the freeRTOS Python-task on the ESP32 (with external PSRAM) to run uninterruptedly.
This is what the compiler puts out as statistics after compilation:
we are using Pycom 1.20.2.r4 and 1.20.2.r6, error happens in both versions. We already stripped off Bluetooth an CAN modules.
Is the hypothesis correct?
Did anyone here experience such a behaviour?
If that is linked to the size of the C-code and variables, can we, already at compile time, check violation of limits before running that code on the device?
Thanks in advance for help!
PS: also posted here:
https://forum.pycom.io/topic/7408/stran ... sed-c-code
since a certain stage of commits in our development, we are facing strange errors: at seemingly random times, some of the try/except sections catch something like this:
First type of error:
Code: Select all
Reason: unsupported types for __lt__: 'NoneType', 'int'
Reason: unsupported types for __truediv__: 'float', 'function'
Reason: unsupported types for __lt__: 'NoneType', 'int'
Reason: unsupported type for __hash__: 'dict'Second type of error:
or in the data JSON in a SD card, this is logged:
Code: Select all
"sensor value": <function "linear" at 0x3fa0ae50>Code: Select all
sensorvalue['sensor value'] = linear('sensor name', sensorvalue, Y)So, instead of setting the value to the result of the function, the function object itself is written to the position in the dictionary, and the string serialization transforms that into the <...> representation when the dictionary is json.dumps-ed to the SD card. But that just seems another form of the errors of the first kind.
The errors seem only to appear if there is additional C-code present (beginning with a certain commit). It does not matter if the C-code is acutally used; the errors also appear if none of the C-functions are accessed. But they seem to occur more often, if the statically defined data uint8_t - buffers are larger or the C-code is actually used (creates two additional freeRTOS tasks with around 6k of stack each).
So the current hypothesis is: the C-code generates additional flash and RAM usage for the statically allocated buffers and other variables. That may not leave enough stack for the freeRTOS Python-task on the ESP32 (with external PSRAM) to run uninterruptedly.
This is what the compiler puts out as statistics after compilation:
Code: Select all
xtensa-esp32-elf-size build/WIPY/release/application.elf
text data bss dec hex filename
1016180 628056 47060 1691296 19cea0 build/WIPY/release/application.elf
Is the hypothesis correct?
Did anyone here experience such a behaviour?
If that is linked to the size of the C-code and variables, can we, already at compile time, check violation of limits before running that code on the device?
Thanks in advance for help!
PS: also posted here:
https://forum.pycom.io/topic/7408/stran ... sed-c-code