Skip to content
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

Zephyr/Openthread/MBEDTLS heap size/usage #24089

Closed
marketideas opened this issue Apr 3, 2020 · 2 comments
Closed

Zephyr/Openthread/MBEDTLS heap size/usage #24089

marketideas opened this issue Apr 3, 2020 · 2 comments
Labels
area: OpenThread bug The issue is a bug, or the PR is fixing a bug

Comments

@marketideas
Copy link

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:

  1. mkdir build; cd build
  2. cmake -DBOARD=board_xyz
  3. make
  4. 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.

@marketideas marketideas added the bug The issue is a bug, or the PR is fixing a bug label Apr 3, 2020
@rlubos
Copy link
Contributor

rlubos commented Apr 6, 2020

Hi @marketideas,

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.

@marketideas
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: OpenThread bug The issue is a bug, or the PR is fixing a bug
Projects
None yet
Development

No branches or pull requests

2 participants