CONFIG_HEAP_MEM_POOL_SIZE > 8192 creates system reset

RE: CONFIG_HEAP_MEM_POOL_SIZE > 8192 creates system reset

Didrik Rokhaug — Mon, 08 Mar 2021 17:05:04 GMT

As your prj.conf looks like the one from the http_application_update sample, I have tried to compile it with your prj.conf file in both NCS 1.4.1 and 1.5.0. However, I have not been able to find any significant change in stack sizes alone.

Could you share your code, so that I could try to reproduce your issue, and debug it myself? If you don't want to share your code in a public ticket, you can create a private one where you tag me.

@John coud you make a new ticket for your error?

Just because it is a bus fault doesn't mean it is caused by the same problem.

Best regards,

Didrik

RE: CONFIG_HEAP_MEM_POOL_SIZE > 8192 creates system reset

John — Mon, 08 Mar 2021 07:51:45 GMT

I seem to have a similar problem when using v1.5

AWS connection (connected: 0, in progress: 0)
Not connected to AWS, trying to connect
Received: T60BADA7AD5D3/60BADA7AD5D3/B929E82A85F4/02475F00FF662890
Woo hoo, listener has heard something:
Received: T60BADA7AD5D3/60BADA7AD5D3/6A78B6E6F5F6/51792B00FF733609
[00:01:04.637,939] [1;31m<err> os: ***** HARD FAULT *****[0m
[00:01:04.643,859] [1;31m<err> os: Fault escalation (see below)[0m
[00:01:04.650,512] [1;31m<err> os: ***** BUS FAULT *****[0m
[00:01:04.656,372] [1;31m<err> os: Precise data bus error[0m
[00:01:04.662,475] [1;31m<err> os: BFAR Address: 0x20040af6[0m
[00:01:04.668,823] [1;31m<err> os: r0/a1: 0x2001aed0 r1/a2: 0x00004b84 r2/a3: 0x20040af0[0m
[00:01:04.678,131] [1;31m<err> os: r3/a4: 0x00002001 r12/ip: 0x00000000 r14/lr: 0x00029f59[0m
[00:01:04.687,408] [1;31m<err> os: xpsr: 0x8100001a[0m
[00:01:04.692,993] [1;31m<err> os: s[ 0]: 0x00000000 s[ 1]: 0x00000000 s[ 2]: 0x00000000 s[ 3]: 0x00000000[0m
[00:01:04.704,162] [1;31m<err> os: s[ 4]: 0x00000000 s[ 5]: 0x00000000 s[ 6]: 0x00000000 s[ 7]: 0x00000000[0m
[00:01:04.715,332] [1;31m<err> os: s[ 8]: 0x00000000 s[ 9]: 0x00000000 s[10]: 0x00000000 s[11]: 0x00000000[0m
[00:01:04.726,501] [1;31m<err> os: s[12]: 0x00000000 s[13]: 0x00000000 s[14]: 0x00000000 s[15]: 0x00000000[0m
[00:01:04.737,640] [1;31m<err> os: fpscr: 0x20022208[0m
[00:01:04.743,255] [1;31m<err> os: Faulting instruction address (r15/pc): 0x00029d8c[0m
[00:01:04.751,678] [1;31m<err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0[0m
[00:01:04.760,009] [1;31m<err> os: Fault during interrupt handling
[0m
[00:01:04.766,845] [1;31m<err> os: Current thread: 0x20016920 (unknown)[0m
[00:01:04.779,174] [1;31m<err> os: Halting system[0m

RE: CONFIG_HEAP_MEM_POOL_SIZE > 8192 creates system reset

khodidas — Tue, 02 Mar 2021 10:44:03 GMT

I found one more thing.

Before "k_malloc" is called to create buffer to store data from flash "k_calloc" is called in my application.

It is inside "at_params_list_init" function. This function is called from "modem_info_init" function.

Regards,

Smitesh Mali

RE: CONFIG_HEAP_MEM_POOL_SIZE > 8192 creates system reset

khodidas — Tue, 02 Mar 2021 09:21:39 GMT

[quote userid="81181" url="~/f/nordic-q-a/72164/config_heap_mem_pool_size-8192-creates-system-reset/296890#296890"]Could you try to enable logging, and disabling auto-resetting on faults?[/quote]

I have done this. Following is the log.

*** Booting Zephyr OS build v2.4.99-ncs1  ***<CR><LF>
<LF>
I: 4 Sectors of 4096 bytes<CR><LF>
I: alloc wra: 0, 828<CR><LF>
I: data wra: 0, 7ec<CR><LF>
E: ***** HARD FAULT *****<CR><LF>
E:   Fault escalation (see below)<CR><LF>
E: ***** BUS FAULT *****<CR><LF>
E:   Precise data bus error<CR><LF>
E:   BFAR Address: 0x2109aa8c<CR><LF>
E: r0/a1:  0x2001aa48  r1/a2:  0x00000029  r2/a3:  0x0000000c<CR><LF>
E: r3/a4:  0x00210008 r12/ip:  0x00000000 r14/lr:  0x00035ad9<CR><LF>
E:  xpsr:  0x81000200<CR><LF>
E: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000<CR><LF>
E: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000<CR><LF>
E: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000<CR><LF>
E: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000<CR><LF>
E: fpscr:  0x20014898<CR><LF>
E: Faulting instruction address (r15/pc): 0x00035940<CR><LF>
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0<CR><LF>
E: Current thread: 0x200165e0 (unknown)<CR><LF>
E: Halting system<CR><LF>

[quote userid="81181" url="~/f/nordic-q-a/72164/config_heap_mem_pool_size-8192-creates-system-reset/296890#296890"]What libraries/subsystems is it using? What stack sizes are you using for the different threads? etc.[/quote]

Following are the settings in prj.conf file

#
# Copyright (c) 2019 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#
# General config
CONFIG_NCS_SAMPLES_DEFAULTS=y
CONFIG_REBOOT=y
#CONFIG_HW_STACK_PROTECTION=y
CONFIG_ASSERT=y
CONFIG_REBOOT=y

# Trusted execution
CONFIG_TRUSTED_EXECUTION_NONSECURE=y
#CONFIG_TEST_RANDOM_GENERATOR=y

# Network
CONFIG_NETWORKING=y
CONFIG_NET_SOCKETS_OFFLOAD=y
CONFIG_NET_SOCKETS=y
#CONFIG_NET_SOCKETS_POSIX_NAMES=y
CONFIG_NET_NATIVE=n

# LTE link control
CONFIG_LTE_LINK_CONTROL=y
CONFIG_LTE_AUTO_INIT_AND_CONNECT=n
# Requested Periodic TAU
CONFIG_LTE_PSM_REQ_RPTAU="10111110"
# Requested Active Time
CONFIG_LTE_PSM_REQ_RAT="00000000"
CONFIG_MQTT_KEEPALIVE=1200

# Modem library
CONFIG_NRF_MODEM_LIB=y
CONFIG_NRF_MODEM_LIB_SYS_INIT=n
CONFIG_MODEM_KEY_MGMT=y

# Library for buttons and LEDs
CONFIG_DK_LIBRARY=y
CONFIG_DK_LIBRARY_INVERT_LEDS=n

# Console
CONFIG_CONSOLE_SUBSYS=y
CONFIG_CONSOLE_HANDLER=y
CONFIG_CONSOLE_GETCHAR=y

# Main thread
CONFIG_MAIN_THREAD_PRIORITY=7
# Heap and stacks
CONFIG_HEAP_MEM_POOL_SIZE=32768
CONFIG_MAIN_STACK_SIZE=16384

# Image manager
CONFIG_IMG_MANAGER=y
CONFIG_FLASH=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y

# GPIO
CONFIG_GPIO=y

# FOTA library
CONFIG_FOTA_DOWNLOAD=y

# Download client
CONFIG_DOWNLOAD_CLIENT=y
CONFIG_DOWNLOAD_CLIENT_STACK_SIZE=4096

# DFU Target
CONFIG_DFU_TARGET=y

# Modem key management
CONFIG_MODEM_KEY_MGMT=y

# Application Upgrade support
CONFIG_BOOTLOADER_MCUBOOT=y

# Sample configuration
CONFIG_DOWNLOAD_HOST="nrfconnectsdk.s3.eu-central-1.amazonaws.com"
CONFIG_DOWNLOAD_FILE="app_update.bin"
CONFIG_APPLICATION_VERSION=1

CONFIG_CJSON_LIB=y
CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
CONFIG_DEPRECATED_ZEPHYR_INT_TYPES=y
#CONFIG_LEGACY_TIMEOUT_API=y

# MQTT
CONFIG_MQTT_LIB=y
CONFIG_MQTT_LIB_TLS=y

#Modem_Info

CONFIG_MODEM_INFO=y
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_NRFX=y
CONFIG_SERIAL=y
CONFIG_DEBUG=y
CONFIG_LOG=y
CONFIG_RESET_ON_FATAL_ERROR=n



#Flash Storage
CONFIG_NVS=y
CONFIG_NVS_LOG_LEVEL_DBG=y
CONFIG_NVS_LOG_LEVEL_INF=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y

#Watchdog
CONFIG_WATCHDOG=y
CONFIG_WDT_NRFX=y
CONFIG_NRFX_WDT=y

[quote userid="81181" url="~/f/nordic-q-a/72164/config_heap_mem_pool_size-8192-creates-system-reset/296890#296890"]Do you see the same resets if you use a different application, e.g. Zephyr's hello_world sample (modified so that it allocates some heap memory)?[/quote]

I checked with CONFIG_HEAP_MEM_POOL_SIZE=32768 in "MQTT_Simple" example firmware.

It is not getting reset.

[quote userid="81181" url="~/f/nordic-q-a/72164/config_heap_mem_pool_size-8192-creates-system-reset/296890#296890"]Could you describe your application?[/quote]

My application reads some data from flash (host name etc) and stores it in a buffer allocated through "k_malloc".

After this it connects with two brokers after power on through MQTT.

Important thing is My application hasn't changed between 1.4.1 and 1.5.0.

But still I am getting this error in 1.5.0 while in 1.4.0 application runs without error.

Regards,

Smitesh Mali

RE: CONFIG_HEAP_MEM_POOL_SIZE > 8192 creates system reset

Didrik Rokhaug — Mon, 01 Mar 2021 14:18:10 GMT

Hi,

This sounds like a stack overflow or similar.

Could you try to enable logging, and disabling auto-resetting on faults?

To do that, you can add the following lines to your prj.conf file (if you build with SES, you must run 'Project -> Run CMake...' for changes to prj.conf to take effect)

CONFIG_LOG=y
CONFIG_RESET_ON_FATAL_ERROR=n

Could you describe your application?

What libraries/subsystems is it using? What stack sizes are you using for the different threads? etc.

Do you see the same resets if you use a different application, e.g. Zephyr's hello_world sample (modified so that it allocates some heap memory)?

Best regards,

Didrik