how to allocate the MCUmgr buffers dynamically from within the application

hello Nordic

i am working with nre52840 and nrf52832, with ncs v2.8.0

i am using ble SMP service for transferring data with a central device and for DFU.

currently i am using this config CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE in my prj.conf so i can have larger buffer to increase throughput.

but using it like so take static memory.
in my app i have a stage when BLE is working and then another stage where BLE is off and its threads, buffers are free for other uses of the app (i manage it with my own heap pool).
i am looking for a way to dynamically allocate this buffer so i can both use larger size (i am limited statically) and to reduce static ram take.
i looked at this config  CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION
wonder if i have to use it or if setting CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE = 0 is enough
or maybe i should use this macro some how  - NET_BUF_POOL_DEFINE ?
is there an API i can use to give mcumgr the pointer for the buffer and initialize and close the mcumgr each time i start the BLE and close it 
i am off course open to other way to achieve that if there are
hope to read you soon
best regards
Ziv
Parents
  • Hello,

    If you don't want to use statically allocated memory for the mcumgr transport, you would need to modify the implementation itself. There is no configuration option to disable the use of the statically allocated memory pool. The CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION config symbol is not relevant for this. It can be enabled if you want the ability to dynamically add/remove the SMP service in your attribute table at runtime and will likely increase the memory usage.

    Best regards,

    Vidar

Reply
  • Hello,

    If you don't want to use statically allocated memory for the mcumgr transport, you would need to modify the implementation itself. There is no configuration option to disable the use of the statically allocated memory pool. The CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION config symbol is not relevant for this. It can be enabled if you want the ability to dynamically add/remove the SMP service in your attribute table at runtime and will likely increase the memory usage.

    Best regards,

    Vidar

Children
  • Hey Vidar

    i attempted to use that CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION=y

    with that #define NET_BUF_POOL_HEAP_DEFINE(smp_pool, SMP_BUF_COUNT, SMP_BUF_SIZE, NULL);

    and try register and unregister to smp each time i connect and disconect but it seems that if i set CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE=0

    then i have a problem with fs_download -> this CONFIG_MCUMGR_GRP_FS_DL_CHUNK_SIZE is not defined
    use statically allocated memory
    i am a bit confused by terminology you used here, as i understand the buffers size i give here 
    CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE has a footprint in memory through all the application run and are not just allocated when smp is used .. else this ram would probably be free for use when ble is off no ?
    is there a plane to add to the smp service api an option to give the buffers as pointers from the app layer ?
    it seems kind of wasteful to hold that much memory when it may be used only 50% of app runtime 
    and last related question .. i found out there are 4 buffers actually .. and i wonder of all of them have a footprint in memory at the same time (looks like that by ram size indication when i build) so..
    is there a way they can share the memory (cause incoming and out coming are usually not parallel operations i think (might be wrong) )?
    also, since my incoming messages are usually small commands and my out messages are actual data is it possible to give different size for incoming and out coming?
    hope to read you soon
    best regards
    Ziv
  • Hi Ziv,

    You can search through the source files in the SDK tree for CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE to see where this symbol is used. If you want these file(s) to use system heap, etc, you need to modify the implementation to use k_malloc/k_free and provide new configuration symbols to select whether you want to use dynamic or static allocation.

    ziv123 said:
    attempted to use that CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION=y

    As I said in my previous response, this option enables you to add/remove the SMP service from the attribute table at runtime. I don't see how it is relevant to what you are trying to do.

    ziv123 said:
    i am a bit confused by terminology you used here, as i understand the buffers size i give here 
    CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE has a footprint in memory through all the application run and are not just allocated when smp is used .. else this ram would probably be free for use when ble is off no ?

    The buffer allocated at build time and not freed after use, like a regular static variable.

    ziv123 said:
    is there a plane to add to the smp service api an option to give the buffers as pointers from the app layer ?
    it seems kind of wastefull to hold that much memory when it may be used only 50% of app runtime 
    hope to read you soon

    I believe the buffer management should remain decoupled from the application.

  • Hey 

    If you want these file(s) to use system heap, etc, you need to modify the implementation to use k_malloc/k_free and provide new configuration symbols to select whether you want to use dynamic or static allocation

    i don't want to change ncs internally cause we are trying to stay align with updated versions and this is not a wise practice i think

    did you see my lat question (i edit it while you where answering):

    and last related question .. i found out there are 4 buffers actually .. and i wonder of all of them have a footprint in memory at the same time (looks like that by ram size indication when i build) so..
    is there a way they can share the memory (cause incoming and out coming are usually not parallel operations i think (might be wrong) )?
    also, since my incoming messages are usually small commands and my out messages are actual data is it possible to give different size for incoming and out coming?
    I believe the buffer management should remain decoupled from the application.
    why is it better in your view ?, what risks or problem you see in the alternative ?
Related