Using sections in serialization project

[Dmitry]

Hi,

We use NRF52832-based BLE module running serialization (SDK 14, softdevice 5.0.0) and STM32F407 MCU running application firmware on a custom board. The project is created in Eclipse and compiled using GCC. Also there is micro SD card that is used to store logs over SPI interface. We faced strange issue: once connection is established we get hardfault when the very first log is being written onto SD card. Our guess that the reason is in using sections in SDK 14. Previously we worked with SDK 13 and there were not any problems with storing logs. Maybe the reason is that we didn't use modules that work with sections (for instance .fs_dataand .pwr_mgmt_data).

The questions are:

1. Could it be that using sections is the reason of issue?
2. If yes, how we can fix the issue or avoid using sections?
3. If no, what also could be the reason?

I've attached linker script for more details:

STM32F407XG.ld

Also we've discovered that one of the sections contains information which is not used by the SDK. Here is a part of such section dump:

0807f9b8 <sdh_soc_observers>:
 807f9b8: 08086178 08086180 00000008 6e5c2e2e     xa...a........\n
 807f9c8: 535f4652 315f4b44 6f735c34 65647466     RF_SDK_14\softde
 807f9d8: 65636976 66726e5c 6864735f 636f735f     vice\nrf_sdh_soc
 807f9e8: 0000632e 2d6a626f 6e69703e 203d2120     .c..obj->pin != 
 807f9f8: 6e695028 656d614e 00434e29 445c3a44     (PinName)NC.D:\D
 807fa08: 73696e65 65726853 72656269 726f775c     enisShreiber\wor
 807fa18: 6170736b 655c6563 6170657a 6d5c6b72     kspace\m
 807fa28: 5c646562 6465626d 6c61685c 7261745c     bed\mbed\hal\tar
 807fa38: 73746567 6c61685c 5241545c 5f544547     gets\hal\TARGET_
 807fa48: 5c4d5453 47524154 535f5445 32334d54     STM\TARGET_STM32
 807fa58: 672f3446 5f6f6970 656a626f 682e7463     F4/gpio_object.h
 807fa68: 00000000 735c2e2e 625c6372 632e656c     ......\src\ble.c
 807fa78: 00007070 75257a45 00000000 70657a45     pp..Ez%u....Ezep
 807fa88: 006b7261 454c425b 5053523a 00003a5d     .[BLE:RSP]:..
 807fa98: 5f444d43 5f505352 43435553 00535345     CMD_RSP_SUCCESS.
 807faa8: 5f444d43 5f505352 48434554 5353495f     CMD_RSP_TECH_ISS
 807fab8: 00004555 5f444d43 5f505352 425f4f4e     UE..CMD_RSP_NO_B
 807fac8: 4e414c41 455f4543 5245544e 00000000     ALANCE_ENTER....

Here is an example of four section dumps without data from user application:

0807f95c <sdh_req_observers>:
 807f95c: 08086110 08086110 00000008              .a...a......

0807f968 <sdh_state_observers>:
 807f968: 08086110 08086110 00000008              .a...a......

0807f974 <sdh_stack_observers>:
 807f974: 08086100 08086110 00000008 00020100     .a...a..........

0807f984 <sdh_ble_observers>:
 807f984: 08086110 08086178 00000008 6e5c2e2e     .a..xa........\n
 807f994: 535f4652 315f4b44 6f735c34 65647466     RF_SDK_14\softde
 807f9a4: 65636976 66726e5c 6864735f 656c625f     vice\nrf_sdh_ble
 807f9b4: 0000632e                                .c..

Update #1.

Here is the code where hardfault is happening:

int SPI::write(int val) {
  lock();  // <-- fault. This is the empty function
  aquire();
  ..
}

Disassembler:

str r1, [r7, #0]
  lock();
ldr r3, [r7, #4]
ldr r3, [r3, #0]
adds r3, #4
ldr r3, [r3, #0]
ldr r0, [r7, #4]
blx r3         // <-- fault
  aquire();

Before BLX command R3 = 0x1FBBC00. This address is out of range STM32 memory map.

Probably the reason of fault is stack overflow. I tried to increase stack of thread where SD card is used but it did'n help. I use mbed RTOS.

[Jørgen Holmefjord]

Are you checking all error codes from function calls? Could you post a code snippet from the part where the hardfault is happening?

[Dmitry]

Hello, Jørgen! Yes, we check error codes. I've added code snippet in the initial question under Update #1 text.

[Jørgen Holmefjord]

I'm a bit confused, is the hardfault happening on the nRF or STM32 device? You are running SPI connectivity firmware from the SDK on the nRF, and mbed RTOS on the STM32?

[Dmitry]

Hardfault is happening on STM32 device when we try to write some data on the microSD card. We're running UART connectivity on the nRF and mbed RTOS on the STM32. Please note that previousely when SDK 13 was used we didn't have such problems so we think that problem is in using sections (please see questions 1-3 in the original request).

[Dmitry]

We've solved the issue by increasing interrupt stack size in mbed RTOS. It turns out that NRF52 SDK 13 consumed less stack memory than SDK 14 that's why we didn't faced the issue in older SDK version.