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

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

trunk — Fri, 17 Jun 2022 19:38:33 GMT

I too had this issue. It's caused by the inputs into SVCALL assembly definition not being fully defined and therefore the parameters never get placed on the stack. I found this solution from the link below which is adding this to CFLAGS or within SES. Of course, it should probably be fixed by correctly defining the inputs, but this is an acceptable fix in interim.

c_additional_options="-fno-ipa-modref"

daniel-thompson fix

You can also isolate the optimization options just for the SVCALL as shown below. I've chosen to apply the above fix as I'm timid of another location running into interprocedural optimization issues with gcc 11.

#define SVCALL(number, return_type, signature)          \
  _Pragma("GCC diagnostic push")                        \
  _Pragma("GCC diagnostic ignored \"-Wreturn-type\"")   \
  _Pragma("GCC push_options")                           \
  _Pragma("GCC optimize (\"-fno-ipa-modref\")")         \
  __attribute__((naked))                                \
  __attribute__((unused))                               \
  static return_type signature                          \
  {                                                     \
    __asm(                                              \
        "svc %0\n"                                      \
        "bx r14" : : "I" (GCC_CAST_CPP number) : "r0"   \
    );                                                  \
  }                                                     \
  _Pragma("GCC pop_options")                            \
  _Pragma("GCC diagnostic pop")

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

Hung Bui — Wed, 08 Jun 2022 06:45:50 GMT

@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

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

kentorth — Tue, 07 Jun 2022 18:00:10 GMT

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?

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

Hung Bui — Mon, 14 Mar 2022 09:18:36 GMT

Hi Michael,

You are right and your suggestions make a lot of sense. Normally, we would keep our SDK compatible with the latest tool chain update and try to match with the newest gcc version.

However, the nRF5 SDK is now considered legacy development platform and we have stopped releasing new major version of it since June 2020 (SDK v17.0). The resource is now focusing on nRF Connect SDK. It's likely that v17 will be the last major version of the nRF5 SDK.

I hope you understand our situation and consider using the gcc version that's tested with the SDK. But of course please provide your feedback to our sales representative in your country. We always listen to you and will try our best to help solving your problem.

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

m5k8 — Sat, 12 Mar 2022 11:45:44 GMT

Thank you for your insight and support, prompt answer is really appreciated.

Unfortunately, that's the kind of answer I was expecting.

[quote userid="2121" url="~/f/nordic-q-a/85677/sdk-17-1-0-secure-bootloader-runtime-failure-when-compiled-with-current-gcc-11-2-0/357667#357667"]It must be something wrong with the declaration of SVC call.[/quote]

Probably. I didn't try to debug it on my own, I thought that you are the right instance to track down the problem. You built the hardware, your wrote all the pieces of software. I must accept your decision to not dig deeper into the problem as thoughtful one. I respect your priorities.

Regarding the preferred choice of the compiler, I beg to differ, please bear with me:

When any software vendor is asked "which version of your software should be used", usually the correct answer is "use the last stable version, it's the best one as of today". When I ask you, you probably will point me to the newest version of your SDK and SoftDevice.

gcc current stable version is 11.2. That's what gcc authors consider as the current compiler. I consider this as the most authoritative opinion. The "blessed" one. But I can understand that using fresh versions of all software is constant churn and sometimes too much.

The second level of blessedness is ARM's distribution of gcc. They decided to stay at one major version behind. It's considerable choice, maybe they prefer to do more testing which is time consuming, maybe there are other objections to stay on the bleeding edge of current compiler technology. Even Debian stable linux distribution, known to be as the software archeology site, is already at gcc major version 10. So let's assume this is the conservative choice, the least common denominator.

Your choice to suggest version 9 that is two major version behind is odd. It's obsolete and archival.

[quote userid="2121" url="~/f/nordic-q-a/85677/sdk-17-1-0-secure-bootloader-runtime-failure-when-compiled-with-current-gcc-11-2-0/357667#357667"]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)[/quote]

Why not? OK, latest newest versions, I can agree. But using current version of ARM's Embedded Toolchain should be good practice if not even mandatory, not some obsolete one. I'm aware that I'm not in the position to tell you what you should and shouldn't, so please consider this as polite suggestion.

Keeping to the obsolete version of compiler is problematic, at least for considerable group of your users. There are ongoing compatibility and maintenance issues. Linux ecosystem, especially development one, moves quite fast. System libraries and other dependencies break. Yes, I know, I can always compile the compiler from sources...

I'm also using C++ in my projects, and try to follow latest language developments. Getting stuck at old compiler version is prohibitive here, I just can't use the good niceties from modern C++. std::byte is a nice abstraction over uint8_t everywhere.

Let's also imagine I'm using some substantial library from another vendor in my project, and this vendor did some mistakes and their piece of code doesn't compile with your selected version of the compiler, and I'm expected to use some another random ancient version. Hell...

[quote userid="2121" url="~/f/nordic-q-a/85677/sdk-17-1-0-secure-bootloader-runtime-failure-when-compiled-with-current-gcc-11-2-0/357667#357667"]v 10.3-2021.10 the nrf_dfu_mbr_init_sd() function worked fine and returned 0.[/quote]

So gcc 10 has a chance to work. But as you say, you don't test your software with this version, only version 9. If gcc 11 doesn't work, then there's chance that there's some code that is trying to outsmart the compiler and can introduce compiler dependent bugs, so using untested by you gcc 10 also doesn't feel safe.

[quote userid="2121" url="~/f/nordic-q-a/85677/sdk-17-1-0-secure-bootloader-runtime-failure-when-compiled-with-current-gcc-11-2-0/357667#357667"]you may need to attach the correct gcc version to the SDK setup[/quote]

If your freshly released software, as of today, doesn't compile and work properly using contemporary compiler version, I consider this to be a bug, the definite one. In your software, or in compiler :)

So I kindly ask you to reconsider your stance, and not stay so far in the past with the compiler choice.

Nevertheless, once again thank you for your prompt support! If you read anything above as harsh, English is my foreign language and I had no intention to. Just a little bit of astonishment.

Best regards,

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

Hung Bui — Fri, 11 Mar 2022 13:03:26 GMT

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. )