Increasing size of CLI message buffer

[ilnadi]

We have an application using SDK for Thread 4.1.  The application requires sending large custom commands over CLI. 

We increased the size of NRF_CLI_CMD_BUFF_SIZE in sdk_config.h but this does not change the overall RAM usage.  Since we are not able to test yet, we assumed this means the buffer size did not increase.

Searching online indicates we should be modifying OPENTHREAD_CONFIG_CLI_UART_RX_BUFFER_SIZE but we cannot find this anywhere in the SDK.

What is the correct way to make sure large CLI messages can be received by the Thread CLI?

[Edvin]

Hello,

In what example did you find NRF_CLI_CMD_BUFF_SIZE in sdk_config.h? I couldn't find it in the file SDK\examples\thread\cli\ftd\uart\pca10056\blank\config\sdk_config.h.

The openthread stack used in the Thread (and Zigbee) SDK is generated from the openthread github repository:

https://github.com/openthread/openthread

If you want to change parameters in this library, you need to generate a custom build of the openthread repository. You can do so by following this guide.

Please note that you should use the same commit as the one used in the SDK in order to make sure it is compatible.

You will find the commit described in the file:

SDK\external\openthread\project\readme.txt.

Best regards,

Edvin

[ilnadi]

We started from \nRF5_SDK_for_Thread_and_Zigbee_v4.1.0_32ce5f8\examples\multiprotocol\ble_thread\ble_thread_dyn_mtd_coap_cli and can see NRF_CLI_CMD_BUFF_SIZE in sdk_config.h, nrf_cli.h, nrf_cli.c.

Based on the  below from nrf_cli.c, we expected NRF_CLI_CMD_BUFF_SIZE to increase buffer size.

Does you note mean nrf_cli.c is part of the openthread library and not part of the project code?

thank you

/**
* @brief CLI instance context.
*/
typedef struct
{
nrf_cli_state_t state; //!< Internal module state.
nrf_cli_receive_t receive_state; //!< Escape sequence indicator.

nrf_cli_static_entry_t active_cmd; //!< Currently executed command

nrf_cli_vt100_ctx_t vt100_ctx; //!< VT100 color and cursor position, terminal width.

nrf_cli_cmd_len_t cmd_buff_len; //!< Command length.
nrf_cli_cmd_len_t cmd_buff_pos; //!< Command buffer cursor position.

#if NRF_MODULE_ENABLED(NRF_CLI_WILDCARD)
nrf_cli_cmd_len_t cmd_tmp_buff_len; //!< Command length in tmp buffer
#endif

char cmd_buff[NRF_CLI_CMD_BUFF_SIZE]; //!< Command input buffer.
char temp_buff[NRF_CLI_CMD_BUFF_SIZE]; //!< Temporary buffer used by various functions.
char printf_buff[NRF_CLI_PRINTF_BUFF_SIZE]; //!< Printf buffer size.

#if NRF_MODULE_ENABLED(NRF_CLI_STATISTICS)
nrf_cli_statistics_t statistics; //!< CLI statistics.
#endif

#if NRF_MODULE_ENABLED(NRF_CLI_USES_TASK_MANAGER)
task_id_t task_id;
#endif

#if NRF_MODULE_ENABLED(NRF_CLI_HISTORY)
nrf_memobj_t * p_cmd_list_head; //!< Pointer to the head of history list.
nrf_memobj_t * p_cmd_list_tail; //!< Pointer to the tail of history list.
nrf_memobj_t * p_cmd_list_element; //!< Pointer to an element of history list.
#endif
volatile nrf_cli_internal_t internal; //!< Internal CLI data
} nrf_cli_ctx_t;

[ilnadi]

The SDK version we are using (nRF5 SDK for Thread and Zigbee v4.1.0) lists
"OpenThread libraries projects are based on the following commit of OpenThread: c6a258e3a5bd90aa26d8245c435c0ae5797027f4"
which points to this version:
"(12:25:47.890) OPENTHREAD/20191113-00534-gc6a258e3; NRF52840; Apr 5 2020 21:51:18"
Please confirm that this is the correct git commit.

[Edvin]

Yes. That should be the correct commit. Please see my colleague, Jørgen's, reply in this thread on how to check out a commit:

https://devzone.nordicsemi.com/f/nordic-q-a/60923/cli-in-pca10059/249437#249437

As far as I can see, nrf_cli.c is not included in the example ble_thread_dyn_mtd_coap_cli, and it looks like nrf_cli.h isn't included either.

Actually, I think most (if not all) of the CLI functionality comes from the openthread library.

I see that nrf_cli.h is included in the project if NRF_CLI_ENABLED is defined as 1, which it is not by default in this example. That is probably why the RAM isn't affected by the size NRF_CLI_CMD_BUFF_SIZE.

Best regards,

Edvin