The function mbedtls_ssl_write get stuck forever when there is low heap memory, about 3-4kb of heap. The ssl_write will block forever until you reset the device, it only occurs when the heap memory is low. The interrupts still works while the write is blocking forever. Please investigate.
File -> RTOS_SDK\third_party\mbedtls\library\ssl_tls.c
Function -> int mbedtls_ssl_write( mbedtls_ssl_context *ssl, const unsigned char *buf, size_t len )
Digging a little bit more on the issue, I've added vPortEnterCritical() and vPortExitCritical between the "ssl_write" call, then the code always crashes and prints ShowCritical:1 message on the uart.
Which version of SDK are you using? Can you attach a log?
I would like to know if this failure occurs during a callback or just before a callback.
For temporarily fixing this, try to check free heap before calling the function that causes failure with low heap space.
Without enough memory, you can do nothing.
Running an infinite loop and waiting gives developers no clue to what is wrong and how to resolve the issue.
In case of low memory, you can return an error code or message indicating this explicitly.
Silent default behavior will poison everything and should be completely eliminated.
Note that no silent action is ever taken up by SDK. You will get a reboot if there is an issue, always. Unless it is power supply issue, of course.
Note that no silent action is ever taken up by SDK.
I dare to disagree with this statement, because I personally
encountered these in non-RTOS library.
Endless loops while waiting for resources is a doubtful practice.
Such loops should be interrupted and error generated.
Apart from hiding such internal issues from developers,
lots of other things in SDK are also not documented.
We often have hard time figuring out what went wrong
and how to resolve it.
Of course, we can certainly make and "educated guess", but
do you really think this is how SDK issues should be handled?
You will get a reboot if there is an issue, always.
in the order of importance:
1. in this particular case, the system freezes, but does not reboot,
simply because it is running an internal loop that resets WD timer.
2. the system should never reboot unless the error is fatal.
A "fatal error" means that the system cannot function whatsoever.
Low memory should not be a fatal error.
Give the application some time to complete its current
task so it would release previously allocated memory.
3. system reboot should only be last resort when where is no other
way to recover from an error.
Who is online
Users browsing this forum: No registered users and 1 guest
Newbies Start Here
Are you new to ESP8266?
Unsure what to do?
Dunno where to start?
Start right here!
We also have a RTOS version and a MESH version too!
Complete listing of the official ESP8266 related documentation release by ESPRESSIF!
Must read here!