-
-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vPortFree 517 line assert fail #2720
Comments
The SDK issue you mention should not affect Sming code. It seems to boil down to whether IRAM can be used by the allocator. According to the SDK documentation this feature was added in version 3.0 but requires applications to define a function The Below are the bits you'd need to add to your application.
|
as usual, I'm impressed by the quality of answers here, thanks @mikee47 |
It'll build for Esp32 also, though never had occasion to use it. |
I can't say that I'm making progress here...
that decodes to
I can't really say much about the circumstance apart from the fact that it's reliably triggered at the end of an OTA, before rebooting into the new ROM. I've also seen it happen in a few other circumstances, when the software was writing to flash. Since that is code, I have not touched a whole lot yet, it might just be memory pressure triggering this. It's very odd at any rate. |
I have now rewritten the OTA component to use the same code as the SimpleOTA example (which, iirc, is the newer, Esp32 compatible OTA code?) but the result is still the same.
the configuration of the otaUpdater is this:
and this is the flash layout:
so, clearly something reproducibly triggers this vPortFree assert - but I can't say why. It might be this mix of older and newer ota code in my codebase (although I think I've now fully switched to the new model) or something else. Not sure where to go with this now. |
some more analysis.
The result is much the same, though.
this message is output at the end of the otaupdate callback
I'm not sure if the messages after this are due to the restart of if there are parallel operations ongoing.
The vPortFree 517 line assert fail reliably comes after the TCP onReadyToSendData message
but I'm not sure if it's at all connected. |
this is where the stack dump seems to match up with the output:
I have a hard time breaking down the code at 0x40257fc9 |
Can you get the code running in GDB? The backtrace might be easier to follow. See https://sming.readthedocs.io/en/latest/arch/esp8266/debugging. If you can provide an example application which demonstrates the fault I could assist further? |
I have just tested it with the BasicOta example with the following changes:
I can reproduce the error with this. Note: since I'm only using one ROM file, I have removed the RBOOT_USE_TWO_ROMS #ifdefs my experiments with gdb and remote development haven't been really successful so far, but I'll try again. here's the decoded stack:
I am a little bit confused, I tried to find the offending code but the only reference I found was somewhere in the nonos tree in mem.h - is that part not open source? I guess I've never looked at it. |
One thought: have you tried the 'new' memory allocator? Build with |
umm... what I can say is: it does make a difference wonder if the "unaligned" is the problem in the first case.
|
so I can 100% reproduce this now flashing this code: |
OK, so problem is the
(Found by judicious application of |
@pljakobs I've raised a PR which should fix this issue. Would you give this a test? |
I've learned that you cannot take some of this debug output too literally! I took this to mean that both memory allocators get 'messed up' so first place to look is something getting de-allocated twice. |
Something else I should have thought about earlier is using the malloc_count component https://sming.readthedocs.io/en/latest/_inc/Sming/Components/malloc_count/. Enabling it produces the following output:
Curiously we also get an 'already freed' message from the OS. Either way it can help. For completeness, enable the above functionality thus:
|
I'm getting a compile error
I looked at the documentation and couldn't find that on item - am I missing something? Is there more to the patch than the HttpUpgrader.h and .cpp files? |
The |
my fault entirely bangshead |
so for now, all I can really say is that the error has changed a bit.
|
Right, so
Done a quick test (success and failure) and both seem OK. |
I think I can confirm this fixed, at least from first tries with the Basic OTA code. Will try with my project. edit: confirmed for my larger project, too! This is great! |
I'm experiencing the above error when running an OTA on my firware. The OTA seems to not update the spiffs partition, but I'm not sure if this is a result of the above Error.
What I could find about the error is a very old issue on NONOS 3.0.0 here: espressif/ESP8266_NONOS_SDK#243
Is that a patch that needs to be cherry-picked into Sming, is it something unavoidable like I'm using too much heap or is it something else?
I know I have some memory pressure, running with a free heap of about 16kB, I could terminate all tcp connections before attempting the OTA but I'm wondering if that's really the only way.
pj
The text was updated successfully, but these errors were encountered: