SES 6.32: Strange behaviour

RE: SES 6.32: Strange behaviour

Einar Thorsrud — Fri, 08 Jul 2022 11:42:19 GMT

Aha, I see. I was not able to reproduce here, but that could be a coincidence. Generally it could be a good idea to use a toolchain version that is mentioned in the release notes of the SDK you are using, as that version was used during release testing. It is not the first time we have seen issues with specific compiler versions, though it is quite rare.

RE: SES 6.32: Strange behaviour

cmag — Fri, 08 Jul 2022 08:31:03 GMT

With the old compiler release I used to have the following settings for DEBUG and RELEASE:

With the new compiler DEBUG configuration works fine, while RELEASE crashes, unless I set gcc_optimization_level="None".

This was the origin of all.

What I have noticed that in RELEASE configuration the sec_mode parameter was not initialized before calling sd_ble_gap_device_name_set and sd_ble_gap_device_name_set gave an error of invalid parameter.

RE: SES 6.32: Strange behaviour

Einar Thorsrud — Thu, 07 Jul 2022 13:00:35 GMT

Hi,

All SoftDevice API calls are SVC calls, so you should not compare with normal function calls.

I am still unsure about what the issue issue is and why you are digging into this, though? What is not working? Which problem are you trying to solve?

RE: SES 6.32: Strange behaviour

cmag — Thu, 07 Jul 2022 09:52:16 GMT

My mistake: the call was by reference, so the register overwritten is not the problem.

Still there is a difference when calling the Softdevice function defined as follows (a few excerpts):

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

SVCALL(SD_BLE_GAP_DEVICE_NAME_SET, uint32_t, sd_ble_gap_device_name_set(ble_gap_conn_sec_mode_t const *p_write_perm, uint8_t const *p_dev_name, uint16_t len));

With the following line of code:

err_code = sd_ble_gap_device_name_set(&sec_mode, (const uint8_t *)cfgGetDeviceName(),
strlen(cfgGetDeviceName()));

R0 point to sec_mode:

R0: 0x2003ff8c -> 07 79

And calling a function with a standard C signature:

__attribute__ ( (noinline))
uint32_t sd_ble_gap_device_name_set0(ble_gap_conn_sec_mode_t const *p_write_perm, uint8_t const *p_dev_name, uint16_t len)

{
sd_ble_gap_device_name_set0test = *p_write_perm;
}

With the following line of code:

err_code = sd_ble_gap_device_name_set0(&sec_mode, (const uint8_t *)cfgGetDeviceName(),
strlen(cfgGetDeviceName()));

R0 points to sec_mode:

R0: 0x2003ff8c -> 11 0C

But the time the correct value is stored in memory.

So maybe it is an incompatibility between the compiler and the library. It seems that the compiler still tries to pass &sec_mode in R0 (I do not know if this is correct with SVCALL) but the fails to initialize sec_mode.

I will try to recompile with the latest library to check if this solves the problem.

RE: SES 6.32: Strange behaviour

Einar Thorsrud — Thu, 07 Jul 2022 08:03:26 GMT

Hi,

I must admit I am not fluent in assembly, but I do not see what is obviously wrong here? Also, I still do not get why you are digging into this particular part? I wonder if it is related to the next question though, with SoftDevice version compatibility?

[quote user="cmag"]

What happen if I switch to SDK version 2; I suspect that having:

SoftDevice 1
Bootloader 1
Application 2.3

Could cause problems, as Application 2.3 would expect to interact with SoftDevice 2; what is the correct way to proceed at this point, using the BLE DFU?

[/quote]

The SoftDevice API is generally not compatible between major versions, so in this case you cannot update the application without also updating the SoftDevice. Moreover, the BLE bootloader also relies on the SoftDevice, so you need to update this at the same time as well. If you want to keep the old SoftDevice and bootloader, you could change the SoftDevice header files in the application to use the old header files and port the new application to the old SoftDevice (there will typically be some API changes, and this goes both ways). If you build the new application for the old SoftDevice, then you can update just the application via DFU.

I would generally say that if you update SDK version it probably also makes sense to update the SoftDevice, though. And if you update the SoftDevice, you must also update the BLE Bootloader, as that depends on the SoftDevice. So in this case you would need to update all three, and make a DFU zip package that include all three. Then the DFU procedure works so that the application is deleted, and the SoftDevice and bootloader are updated together (first transferred to the application region, before being copied into the correct place by the MBR which is never updated). Lastly the new application is transferred.

RE: SES 6.32: Strange behaviour

cmag — Wed, 06 Jul 2022 17:58:21 GMT

I am using the standard SDK, but I am starting to suspect that the SDK has nothing to do with it.

To prove this I have defined my version of the called procedure:

__attribute__ ((noinline))
uint32_t sd_ble_gap_device_name_set0(ble_gap_conn_sec_mode_t const *p_write_perm, uint8_t const *p_dev_name, uint16_t len)

{
sd_ble_gap_device_name_set0test = *p_write_perm;
}

The code generated to call this function is:

BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode);
B500 push {lr}
B087 sub sp, sp, #28
2311 movs r3, #17
F88D300C strb.w r3, [sp, #12]
--- main.c -- 358 ------------------------------------------
err_code = sd_ble_gap_device_name_set0(&sec_mode,
F001FE7F bl 0x0002935C <cfgGetDeviceName>
9001 str r0, [sp, #4]
F001FE7C bl 0x0002935C <cfgGetDeviceName>
F012F93A bl 0x000398DC <strlen>
9901 ldr r1, [sp, #4]
B282 uxth r2, r0
A803 add r0, sp, #12
F7FFFFE9 bl 0x00027644 <sd_ble_gap_device_name_set0>

It keeps sec_mode in r3, then calls strlen, which (I checked) uses R3, and has any right to use R0 to R3 for its own purposes, then calls sd_ble_gap_device_name_set0 with R3 corrupted.

Frankly I cannot believe that GNU C compiler makes such mistakes; I am starting to suspect that the project has some settings appropriate with the old version that interfere with the new version.

I will try to rebuild the project settings from scratch with the new release.

To make the second part of my question more clear. Say that I build my application with version 1 of the SDK and libraries, then I deploy and my device has:

SoftDevice 1
Bootloader 1
Application 1.1

No problem till I keep using the same SDK; I will get:

SoftDevice 1
Bootloader 1
Application 1.2

What happen if I switch to SDK version 2; I suspect that having:

SoftDevice 1
Bootloader 1
Application 2.3

Could cause problems, as Application 2.3 would expect to interact with SoftDevice 2; what is the correct way to proceed at this point, using the BLE DFU?

RE: SES 6.32: Strange behaviour

Einar Thorsrud — Tue, 05 Jul 2022 10:43:29 GMT

Hi,

Are you using a vanilla SDK or have you made any changes to it?

What error do you get now? Is it sill that you get NRF_ERROR_INVALID_PARAM returned from sd_ble_gap_device_name_set(), or is the issue something else? Please explain. If this is the error, then what parameters do you provide to sd_ble_gap_device_name_set()? (the error indicate an issue here)

[quote user="cmag"]Maybe I should try upgrading to latest softdevice; but I wonder what happens on existing products; I mean, a product contains:[/quote]

The application (firmware) is built with header files for a specific SoftDevice. If you change to a new SoftDevice you need to rebuild the application. Also, a SoftDevice with a different version number typically has a number of API changes that needs to be addresses when updating SoftDevice.

[quote user="cmag"]What happens of the other components when I upgrade the FIRMWARE compiled for the new SDK/SOFTDEVICE?[/quote]

If you update just the application, then that is OK as long as it is built for the SoftDevice you are using. Typically the bootloader has no dependency on the application. However, the bootloader also has dependencies on the SoftDevice (provided it uses Bluetooth), so you also need to re-build the bootloader if changing SoftDevice.

RE: SES 6.32: Strange behaviour

cmag — Tue, 05 Jul 2022 07:59:09 GMT

I have tried on a clean machine, to check if there was an interference with other software, but the problem persists.

I am using:

nRF5 SDK v16.0.0
------------------------
Release Date: October, 2019

Maybe I should try upgrading to latest softdevice; but I wonder what happens on existing products; I mean, a product contains:

SOFTDEVICE
DFU
FIRMWARE

What happens of the other components when I upgrade the FIRMWARE compiled for the new SDK/SOFTDEVICE?

RE: SES 6.32: Strange behaviour

cmag — Thu, 30 Jun 2022 11:58:04 GMT

Actually the problem was that sd_ble_gap_device_name_set returned an error for invalid parameters.

Besides SES 6.32 crashes very frequently with my PC.

So I reverted to version 5.66 which works fine.

RE: SES 6.32: Strange behaviour

Einar Thorsrud — Thu, 30 Jun 2022 11:28:44 GMT

Hi,

I am not sure I understand the main issue here. Do you see unexpected behavior, or is it just that you decided to take a look at the disassembly and are wondering about what you are seeing?

Generally, debug configurations should not do any optimization, to make the machine code map as closely to the C code as possible. So it is intentional and expected that there is no constant folding etc. For the release configuration it is different, but exactly how the compiler optimized the code depends on the optimization configuration. Generally though the compiler is much better at finding smart optimizations than humans, so it is not normally so that you can look at a small piece of disassembly and with good reason conclude that "here the compiler did something wrong/stupid".