You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I am not at the point to call this a bug yet. However, spent the last 2 days trying to figure out why a join operation would always fail with a 'NoBufs' while connecting issue, across multiple platforms/boards.
It turns out there was a memory allocation error in CoapSecure:Connect. Tracking this down, I found that the MBED (internal/CONFIG_MBEDTLS_BUILTIN=y) does not use its own heap, but uses the HeapCMalloc from the OpenThread Library. This means that the configuration option CONFIG_MBEDTLS_HEAP_SIZE=65536 is ignored, and the actual used heap size is buried within openthread-core-zephyr-config.h, hardcoded with no configuration option, other than editing that file within the zephyr codebase.
To Reproduce
Steps to reproduce the behavior:
mkdir build; cd build
cmake -DBOARD=board_xyz
make
See error
Expected behavior
There are many ways this might be resolved, but I am thinking that the above named .h file should include some ifdefs based on MBEDTLS_HEAP_SIZE if that is defined.
Another option would be to allow the .h file to be located outside of the tree and let the user/program define its internal settings.
Impact
Device is unable to join an existing thread network due to memory allocation errors as soon as the joiner device attempts to connect to the responding commissioner.
Screenshots or console output
None - unless someone needs them.
Environment (please complete the following information):
OS: cross compile from Ubuntu 18.4
Toolchain (e.g Zephyr SDK, ...)
Commit: master branch/updated 4/3/2020
Additional context
Additionally, after increasing the OPENTHREAD_CONFIG_HEAP_SIZE to (32768), I was able to reduce CONFIG_MBEDTLS_HEAP_SIZE to 8 (some very small value) and run/join device normally.
I would be happy to work on the patch here, but I would rather get this working across all boards/platforms I am working with. (frdm-k64f/mcr20a, NRF52840_pca10056, and frdm_kw41z. I have made other changes (unrelated) to work around a few other issues, which I will document once code complete (minor issues).
If I am missing some configuration option that handles this, I plead ignorance and would appreciate guidance.
The text was updated successfully, but these errors were encountered:
From your description it seems you're facing a bug that was introduced during recent OpenThread update. It is fixed already though: #23688, zephyrproject-rtos/openthread#8. Perhaps you forgot to sync repos with west update?
Just as a clarification - OpenThread running with Zephyr is supposed to use heap provided by Zephyr, not by the OpenThread, it's explained here.
I've just tested commissioning, to be sure, with current master and it worked fine for me in default configuration (nrf52840_pca10056). Let me know if the problem persists for you, we'll dig further then. I'd also be happy to hear about the other issues you've faced as well.
Thanks for the response. I just did a double check, and these are what I am working with:
=== updating mbedtls (modules/crypto/mbedtls):
HEAD is now at cf7020e mbedtls: Update mbedTLS 2.16.4
=== updating openthread (modules/lib/openthread):
M CMakeLists.txt
HEAD is now at 46194ba9 openthread: Merge up to commit ab9c0a4
The change to CMakeLists.txt is due to changes for -pedantic-errors which is another bug.
I did a pull from the master, which then really broke everything, because of renaming nordic boards, and adding tx_csma modes to the nrf driver...openthread will now not link.
I will close this issue, and turn my attention to other parts of my project, and revisit when I am more serious about getting openthread implemented. This was just an investigation if I could get it to work so I don't do a bunch of development, only to find later that openthread can not be implemented. This project is rather large incorporating usb, ethernet, serial comm (custom 9 bit protocol).
Perhaps there are specific configuration options that are in conflict.
I will close this issue and revisit at later time.
Thanks.
Describe the bug
I am not at the point to call this a bug yet. However, spent the last 2 days trying to figure out why a join operation would always fail with a 'NoBufs' while connecting issue, across multiple platforms/boards.
It turns out there was a memory allocation error in CoapSecure:Connect. Tracking this down, I found that the MBED (internal/CONFIG_MBEDTLS_BUILTIN=y) does not use its own heap, but uses the HeapCMalloc from the OpenThread Library. This means that the configuration option CONFIG_MBEDTLS_HEAP_SIZE=65536 is ignored, and the actual used heap size is buried within openthread-core-zephyr-config.h, hardcoded with no configuration option, other than editing that file within the zephyr codebase.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
There are many ways this might be resolved, but I am thinking that the above named .h file should include some ifdefs based on MBEDTLS_HEAP_SIZE if that is defined.
Another option would be to allow the .h file to be located outside of the tree and let the user/program define its internal settings.
Impact
Device is unable to join an existing thread network due to memory allocation errors as soon as the joiner device attempts to connect to the responding commissioner.
Screenshots or console output
None - unless someone needs them.
Environment (please complete the following information):
Additional context
Additionally, after increasing the OPENTHREAD_CONFIG_HEAP_SIZE to (32768), I was able to reduce CONFIG_MBEDTLS_HEAP_SIZE to 8 (some very small value) and run/join device normally.
I would be happy to work on the patch here, but I would rather get this working across all boards/platforms I am working with. (frdm-k64f/mcr20a, NRF52840_pca10056, and frdm_kw41z. I have made other changes (unrelated) to work around a few other issues, which I will document once code complete (minor issues).
If I am missing some configuration option that handles this, I plead ignorance and would appreciate guidance.
The text was updated successfully, but these errors were encountered: