Wireless MCUのトピックKW36 memory optimization for wireless UART profile

KW36 memory optimization for wireless UART profile

nsuresh2 — Sat, 29 Jun 2019 19:22:30 GMT

Please help us in getting the memory footprint (RAM) details of BLE stack/application used for Wireless UART profile.

We could see a memory pool defined in app_preinclude.h file, memory pool sizes are different for application to application. We need exact memory usage considering in worst case scenarios.
Is defined memory pool block sizes in app_preinclude.h file is optimized values or can be customized based on the application needs? if yes, can you please provide us the details.

Regards,

Naven Suresh

Re: KW36 memory optimization for wireless UART profile

Sebastian_Del_Rio — Tue, 02 Jul 2019 14:57:25 GMT

Hi Naven, I hope you're doing well!

The minimum requirements to run the UART profile for the KW36Z can be found in the KW36's Bluetooth Low Energy Release Notes (included in the SDK documentation folder, on the following path: <\SDK_2.2.0_FRDM-KW36\docs\wireless\Bluetooth>).

The requirements are located in the following tables, depending on which IDE you'll develop with:

The cells surrounded by the red square represent the minimum memory (RAM) requirements for each of the components, the rest is free for application development.

Note: These calculations exclude application code, as that may change depending on development.

Please let me know if you have any further questions.

Best regards,

Sebastian

Re: KW36 memory optimization for wireless UART profile

xing_chang — Mon, 29 Jul 2019 05:58:57 GMT

Hi nsuresh2@visteon.com‌,

The use of the memory pool is dynamically allocated. Depending on the usage scenario, the allocation is not the same. You can check the distribution by using the debug interface.

See the 3.3.6 Memory manager debug support section of the ‘Connectivity Framework Reference Manual.pdf’ for details.

Re: KW36 memory optimization for wireless UART profile

nsuresh2 — Mon, 29 Jul 2019 07:08:20 GMT

Hi XingChang,

Thanks for your response.

For Wireless_UART example application, in app_preinclude.h file the memory pool is defined as given below

/* Defines pools by block size and number of blocks. Must be aligned to 4 bytes.*/
#define AppPoolsDetails_c \
_block_size_ 32 _number_of_blocks_ 30 _eol_ \
_block_size_ 64 _number_of_blocks_ 5 _eol_ \
_block_size_ 128 _number_of_blocks_ 5 _eol_ \
_block_size_ 268 _number_of_blocks_ 25 _eol_ \
_block_size_ 512 _number_of_blocks_ 2 _eol_

When we look into applications this configuration is different for each example project.
For our Application, Wireless_UART profile with a maximum data payload of 247 with headers to be supported, for this we need a minimum required pool definition.
For one of our project, we are using this micro where we are running out of memory. We need to support other functionalities.
Seems to be most of the memory out of 64KB RAM is used for this pool. Can this be optimized? If yes, how much maximum we can optimize this memory pool to satisfy our requirement.

Regards,

Naven Suresh.

Re: KW36 memory optimization for wireless UART profile

xing_chang — Tue, 30 Jul 2019 01:21:54 GMT

Hi Naven，

You can enable the macro definition MEM_STATISTICS so that you can adjust the memory pool allocation based on real needs.

Adjusting memory pools configuration
It is a good advice to over-estimate the initial memory pool configuration, and then enable the memory manager debug macros fine tune the number of buffers and their size at run time.
For example, if after the initial memory configuration, the system halts in panic because it ran out of memory, then the number of buffer for the memory pool appropriate for the requested size should be increased.
After the application runs correctly, the memory statistics can be used to further adjust the memory pools.
The allocatedBlocksPeak indicator can be analyzed for every pool and adjust the number of buffers so that: numBlocks – allocatedBlocksPeak <= 1. It is usually a good practice to leave a buffer for unpredicted situations.
The pool fragment waste indicators can be used to decrease the size of the buffers from a pool. The scope is to reduce the overall memory waste. Usually, the minimum waste should reach 0. The new size must be a multiple of 4 bytes.