NRF_LOG_INIT HardFault in balloc. The bootloader also uses logging, is that a problem?

RE: NRF_LOG_INIT HardFault in balloc. The bootloader also uses logging, is that a problem?

Anne van Rossum — Mon, 20 May 2019 18:03:18 GMT

Hi Bjorn, I found the culprit. Somewhere in our build tools we were doing an objcopy. Back then not all those sections did yet exists. By just copying a selected subset using objcopy -j ... we ended up with 0xFFFFFFFFs for particular handlers.

One thing I'm surprised about is that after running the code, those values actually get written. There are too many magic macros to figure this out. Perhaps you can help me out.

Does the following function actually write the callbacks to the proper section?

NRF_SECTION_SET_ITEM_REGISTER

It seems that it does namely. That's why I completely missed the fact that objcopy was stripping the contents of particular new sections!

RE: NRF_LOG_INIT HardFault in balloc. The bootloader also uses logging, is that a problem?

Anne van Rossum — Fri, 17 May 2019 11:43:58 GMT

Hi Bjorn,

I'm just checking in. Is there something I've to know for example about the use of FDS from both bootloader and application. I see there is an option FDS_VIRTUAL_PAGES_RESERVED for example.

Again, both app and bootloaders works individually. It's just when the bootloader starts the app that there is a hardfault somewhere in "balloc" related code.

RE: NRF_LOG_INIT HardFault in balloc. The bootloader also uses logging, is that a problem?

Anne van Rossum — Tue, 14 May 2019 14:54:37 GMT

Hi Bjorn, they are both working. If I just run the bootloader it just works. If I just run the application it works. The only time it goes wrong is if the bootloader starts the application. Hence, I would be very surprised if using the sdk_config.h from some example would help very much. I think it leads you into a tangent, but you can check the particular config at https://github.com/crownstone/bluenet/tree/sdk15 namely https://github.com/crownstone/bluenet/blob/sdk15/include/third/nrf/sdk_config.h for the application and https://github.com/crownstone/bluenet/blob/sdk15/bootloader/sdk_config.h for the bootloader.

It is not a matter of log settings "being different". It is only a matter of the context. When the bootloader starts the application I'm afraid the SoftDevice is again allocating something or does something else it is not supposed to do again. I don't have access to the properietary parts of the SoftDevice so I'm not certain if it frees everything properly after the bootloader stopped doing its thing. I'm assuming there is a bug there.

RE: NRF_LOG_INIT HardFault in balloc. The bootloader also uses logging, is that a problem?

bjorn-spockeli — Tue, 14 May 2019 11:01:46 GMT

By changed I mean if you have modified(i.e. set them to non-default values) any of the definitions used by the Logging module in the sdk.config.h file, i.e.

// <e> NRF_LOG_ENABLED - nrf_log - Logger
//==========================================================
#ifndef NRF_LOG_ENABLED
#define NRF_LOG_ENABLED 1
#endif
// <h> Log message pool - Configuration of log message pool

//==========================================================
// <o> NRF_LOG_MSGPOOL_ELEMENT_SIZE - Size of a single element in the pool of memory objects. 
// <i> If a small value is set, then performance of logs processing
// <i> is degraded because data is fragmented. Bigger value impacts
// <i> RAM memory utilization. The size is set to fit a message with
// <i> a timestamp and up to 2 arguments in a single memory object.

#ifndef NRF_LOG_MSGPOOL_ELEMENT_SIZE
#define NRF_LOG_MSGPOOL_ELEMENT_SIZE 20
#endif

// <o> NRF_LOG_MSGPOOL_ELEMENT_COUNT - Number of elements in the pool of memory objects 
// <i> If a small value is set, then it may lead to a deadlock
// <i> in certain cases if backend has high latency and holds
// <i> multiple messages for long time. Bigger value impacts
// <i> RAM memory usage.

#ifndef NRF_LOG_MSGPOOL_ELEMENT_COUNT
#define NRF_LOG_MSGPOOL_ELEMENT_COUNT 8
#endif

// </h> 
//==========================================================

// <q> NRF_LOG_ALLOW_OVERFLOW  - Configures behavior when circular buffer is full.
 

// <i> If set then oldest logs are overwritten. Otherwise a 
// <i> marker is injected informing about overflow.

#ifndef NRF_LOG_ALLOW_OVERFLOW
#define NRF_LOG_ALLOW_OVERFLOW 1
#endif

// <o> NRF_LOG_BUFSIZE  - Size of the buffer for storing logs (in bytes).
 

// <i> Must be power of 2 and multiple of 4.
// <i> If NRF_LOG_DEFERRED = 0 then buffer size can be reduced to minimum.
// <128=> 128 
// <256=> 256 
// <512=> 512 
// <1024=> 1024 
// <2048=> 2048 
// <4096=> 4096 
// <8192=> 8192 
// <16384=> 16384 

#ifndef NRF_LOG_BUFSIZE
#define NRF_LOG_BUFSIZE 1024
#endif

// <q> NRF_LOG_CLI_CMDS  - Enable CLI commands for the module.
 

#ifndef NRF_LOG_CLI_CMDS
#define NRF_LOG_CLI_CMDS 0
#endif

// <o> NRF_LOG_DEFAULT_LEVEL  - Default Severity level
 
// <0=> Off 
// <1=> Error 
// <2=> Warning 
// <3=> Info 
// <4=> Debug 

#ifndef NRF_LOG_DEFAULT_LEVEL
#define NRF_LOG_DEFAULT_LEVEL 3
#endif

// <q> NRF_LOG_DEFERRED  - Enable deffered logger.
 

// <i> Log data is buffered and can be processed in idle.

#ifndef NRF_LOG_DEFERRED
#define NRF_LOG_DEFERRED 1
#endif

// <q> NRF_LOG_FILTERS_ENABLED  - Enable dynamic filtering of logs.
 

#ifndef NRF_LOG_FILTERS_ENABLED
#define NRF_LOG_FILTERS_ENABLED 0
#endif

// <o> NRF_LOG_STR_PUSH_BUFFER_SIZE  - Size of the buffer dedicated for strings stored using @ref NRF_LOG_PUSH.
 
// <16=> 16 
// <32=> 32 
// <64=> 64 
// <128=> 128 
// <256=> 256 
// <512=> 512 
// <1024=> 1024 

#ifndef NRF_LOG_STR_PUSH_BUFFER_SIZE
#define NRF_LOG_STR_PUSH_BUFFER_SIZE 128
#endif

// <o> NRF_LOG_STR_PUSH_BUFFER_SIZE  - Size of the buffer dedicated for strings stored using @ref NRF_LOG_PUSH.
 
// <16=> 16 
// <32=> 32 
// <64=> 64 
// <128=> 128 
// <256=> 256 
// <512=> 512 
// <1024=> 1024 

#ifndef NRF_LOG_STR_PUSH_BUFFER_SIZE
#define NRF_LOG_STR_PUSH_BUFFER_SIZE 128
#endif

The log settings does not necessarily need to be identical, but if the log settings are different and one is working and the other isnt, then please post the relevant sections from the sdk_config files.

Best regards

Bjørn

RE: NRF_LOG_INIT HardFault in balloc. The bootloader also uses logging, is that a problem?

bjorn-spockeli — Tue, 14 May 2019 11:01:45 GMT

By changed I mean if you have modified(i.e. set them to non-default values) any of the definitions used by the Logging module in the sdk.config.h file, i.e.

// <e> NRF_LOG_ENABLED - nrf_log - Logger
//==========================================================
#ifndef NRF_LOG_ENABLED
#define NRF_LOG_ENABLED 1
#endif
// <h> Log message pool - Configuration of log message pool

//==========================================================
// <o> NRF_LOG_MSGPOOL_ELEMENT_SIZE - Size of a single element in the pool of memory objects. 
// <i> If a small value is set, then performance of logs processing
// <i> is degraded because data is fragmented. Bigger value impacts
// <i> RAM memory utilization. The size is set to fit a message with
// <i> a timestamp and up to 2 arguments in a single memory object.

#ifndef NRF_LOG_MSGPOOL_ELEMENT_SIZE
#define NRF_LOG_MSGPOOL_ELEMENT_SIZE 20
#endif

// <o> NRF_LOG_MSGPOOL_ELEMENT_COUNT - Number of elements in the pool of memory objects 
// <i> If a small value is set, then it may lead to a deadlock
// <i> in certain cases if backend has high latency and holds
// <i> multiple messages for long time. Bigger value impacts
// <i> RAM memory usage.

#ifndef NRF_LOG_MSGPOOL_ELEMENT_COUNT
#define NRF_LOG_MSGPOOL_ELEMENT_COUNT 8
#endif

// </h> 
//==========================================================

// <q> NRF_LOG_ALLOW_OVERFLOW  - Configures behavior when circular buffer is full.
 

// <i> If set then oldest logs are overwritten. Otherwise a 
// <i> marker is injected informing about overflow.

#ifndef NRF_LOG_ALLOW_OVERFLOW
#define NRF_LOG_ALLOW_OVERFLOW 1
#endif

// <o> NRF_LOG_BUFSIZE  - Size of the buffer for storing logs (in bytes).
 

// <i> Must be power of 2 and multiple of 4.
// <i> If NRF_LOG_DEFERRED = 0 then buffer size can be reduced to minimum.
// <128=> 128 
// <256=> 256 
// <512=> 512 
// <1024=> 1024 
// <2048=> 2048 
// <4096=> 4096 
// <8192=> 8192 
// <16384=> 16384 

#ifndef NRF_LOG_BUFSIZE
#define NRF_LOG_BUFSIZE 1024
#endif

// <q> NRF_LOG_CLI_CMDS  - Enable CLI commands for the module.
 

#ifndef NRF_LOG_CLI_CMDS
#define NRF_LOG_CLI_CMDS 0
#endif

// <o> NRF_LOG_DEFAULT_LEVEL  - Default Severity level
 
// <0=> Off 
// <1=> Error 
// <2=> Warning 
// <3=> Info 
// <4=> Debug 

#ifndef NRF_LOG_DEFAULT_LEVEL
#define NRF_LOG_DEFAULT_LEVEL 3
#endif

// <q> NRF_LOG_DEFERRED  - Enable deffered logger.
 

// <i> Log data is buffered and can be processed in idle.

#ifndef NRF_LOG_DEFERRED
#define NRF_LOG_DEFERRED 1
#endif

// <q> NRF_LOG_FILTERS_ENABLED  - Enable dynamic filtering of logs.
 

#ifndef NRF_LOG_FILTERS_ENABLED
#define NRF_LOG_FILTERS_ENABLED 0
#endif

// <o> NRF_LOG_STR_PUSH_BUFFER_SIZE  - Size of the buffer dedicated for strings stored using @ref NRF_LOG_PUSH.
 
// <16=> 16 
// <32=> 32 
// <64=> 64 
// <128=> 128 
// <256=> 256 
// <512=> 512 
// <1024=> 1024 

#ifndef NRF_LOG_STR_PUSH_BUFFER_SIZE
#define NRF_LOG_STR_PUSH_BUFFER_SIZE 128
#endif

// <o> NRF_LOG_STR_PUSH_BUFFER_SIZE  - Size of the buffer dedicated for strings stored using @ref NRF_LOG_PUSH.
 
// <16=> 16 
// <32=> 32 
// <64=> 64 
// <128=> 128 
// <256=> 256 
// <512=> 512 
// <1024=> 1024 

#ifndef NRF_LOG_STR_PUSH_BUFFER_SIZE
#define NRF_LOG_STR_PUSH_BUFFER_SIZE 128
#endif

Best regards

Bjørn

RE: NRF_LOG_INIT HardFault in balloc. The bootloader also uses logging, is that a problem?

Anne van Rossum — Tue, 14 May 2019 09:05:33 GMT

Hi Bjørn,

What do you mean by "changed"?

With "changed" do you mean changed in the application compared to the bootloader? Do you mean that all logging settings have to be the same in bootloader and application?

RE: NRF_LOG_INIT HardFault in balloc. The bootloader also uses logging, is that a problem?

bjorn-spockeli — Mon, 13 May 2019 11:48:49 GMT

HI Anne,

there should not be any issues with calling

NRF_LOG_INIT(NULL);
NRF_LOG_DEFAULT_BACKENDS_INIT();

in both the application and in the bootloader, we do this in our SDK examples( i.e. bootlaoder and buttonless DFU application)

So the Hardfault must be caused by something else. Have you changed any of the logging related defines in sdk_config.h?

Best regards

Bjørn