SDK 17.1.0: secure bootloader runtime failure when compiled with current gcc (11.2.0)

[m5k8]

Hi, I have encountered the following problem, using SDK 17.1.0:

secure bootloader compiled with current gcc stable version (11.2.0) fails during runtime with the following error:

<info> app: Entering DFU mode.
<debug> app: Initializing transports (found: 1)
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> app: Failed to initialize transport 0, error 9
<error> app: Could not initalize DFU transport: 0x00000009
<error> app: Received an error: 0x00000003!

And sometimes, when trying many combinations of everything, I was getting error 7.

There's also small problem during compilation with components/libraries/bootloader/ble_dfu/nrf_dfu_ble.c file - there are warnings treated as errors, but temporary removal of

CFLAGS += -Wall -Werror

from Makefile silences this.

Earlier I noticed that whole SDK somewhat suggests gcc 9.3.0 (I had to modify components/toolchain/gcc/Makefile.posix to use my system-wide installed compiler, instead of the path hardcoded there). So, I finally tried compilation with this version of compiler. I had to install it side by side with the current compiler, compile the bootloader with it, and voila - bootloader works.

So there's certainly some problem depending on the compiler version. And that's odd, because I have dozen of various ARM projects here, using MCUs from NXP, Freescale, ST, and current compiler version works flawlessly with all of them. Even my own nRF firmware that I'm currently working on, works just fine with the fresh compiler. Bootloader is the only piece of code that's causing trouble.

Yes, I can hear you - just use that old compiler. That's acceptable as temporary solution, but not really maintainable, looking into the future.

I'm using unmodified bootloader straight from SDK examples, so I think it'd be easily reproducible.

Please have a look at the issue.

[Hung Bui]

Hi Michael, 

I have tried here and got the same error when testing with gcc v11.2

I managed to trace back the error down to the     err_code = nrf_dfu_mbr_init_sd(); call in ble_stack_init(). It's the function that returns error 9. 

It's a call to the MBR. It must be something wrong with the declaration of SVC call. I checked the source of MBR and it has no option to return error 9 from there.

The problem is that we don't test with any other gcc compiler version (and we can't keep continue to test with new gcc releases) except for the one comes default in the SDK. Without thorough test we can't recommend to use newer gcc compiler. So we don't have any other recommendation other than you may need to attach the correct gcc version to the SDK setup and make it separate from your system wide compiler. 

(FYI: At least in my test here the last version of GNU ARM Embedded Toolchain (before they merged ) v 10.3-2021.10 the nrf_dfu_mbr_init_sd() function worked fine and returned 0. )

[kentorth]

Hi Hung,

I am currently running 10.3-2021.10 and am having the same error with SDK 17.1.0.  Are you positive it is a compiler issue?

[Hung Bui]

@kentorth: Please create a new ticket for your question. Please try using the version that's recommended for the SDK: GCC ARM Embedded 9.2020-q2.major