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

[Anne van Rossum]

NRF_LOG_INIT HardFault in balloc (see stack trace below).

(gdb) bt
#0  HardFault_HandlerC (hardfault_args=0x2000fed8) at /home/anne/workspace/bluenet/bart-source/src/util/cs_Error.cpp:74
#1  <signal handler called>
Reading 64 bytes @ address 0x2000FEC0
Read 4 bytes @ address 0x00039142 (Data = 0xD1026822)
Read 4 bytes @ address 0x000394A8 (Data = 0xB9104604)
#2  0x00039142 in nrf_balloc_init (p_pool=0x461ac <log_mempool>) at /home/anne/software/nrf5_sdk/nRF5_SDK_15.2.0_9412b96/components/libraries/balloc/nrf_balloc.c:280
Reading 64 bytes @ address 0x2000FF00
Read 4 bytes @ address 0x0003617E (Data = 0xF8B1F003)
#3  0x000394a8 in nrf_log_init (timestamp_func=<optimized out>, timestamp_freq=<optimized out>)
    at /home/anne/software/nrf5_sdk/nRF5_SDK_15.2.0_9412b96/components/libraries/log/src/nrf_log_frontend.c:133
#4  0x0003617e in main () at /home/anne/workspace/bluenet/bart-source/src/cs_Crownstone.cpp:983
Reading 64 bytes @ address 0x2000FFC0
Read 4 bytes @ address 0x0002628E (Data = 0xFA2DF016)
Reading 64 bytes @ address 0x00026240
Read 4 bytes @ address 0x00026298 (Data = 0x20010000)
Read 4 bytes @ address 0x00026296 (Data = 0x00000008)
Read 4 bytes @ address 0x000262A4 (Data = 0x20002598)
Read 4 bytes @ address 0x000262AA (Data = 0xC6A92000)
#5  0x0002628e in _start ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Code works perfectly without bootloader. However, when the bootloader is present it seems to already have initialized things? Or what exactly is happening here? Should we not call  
    NRF_LOG_INIT(NULL);                                                                                                 
    NRF_LOG_DEFAULT_BACKENDS_INIT();       

If this is already done in the bootloader? Or should we "clean up" the bootloader in some way?

More info:

133	    ret_code_t err_code = nrf_memobj_pool_init(&log_mempool);
(gdb) p m_log_data
Reading 1060 bytes @ address 0x20004AAC
$11 = {
  wr_idx = 0, 
  rd_idx = 0, 
  mask = 255, 
  buffer = {0 <repeats 256 times>}, 
  timestamp_func = 0x0, 
  p_backend_head = 0x0, 
  log_skipping = 0, 
  log_skipped = 0, 
  log_dropped_cnt = 0, 
  autoflush = false
}
(gdb) p log_mempool
Reading 20 bytes @ address 0x0004619C
$12 = {
  p_cb = 0xffffffff, 
Read 1 bytes @ address 0xFFFFFFFF (Data = 0x00)
  p_stack_base = 0xffffffff "", 
Read 1 bytes @ address 0xFFFFFFFF (Data = 0x00)
  p_stack_limit = 0xffffffff "", 
  p_memory_begin = 0xffffffff, 
  block_size = 65535
}

[Anne van Rossum]

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.

[Anne van Rossum]

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!