SES 6.32: Strange behaviour

[cmag]

I am experiencing a strange behavior with SES 6.32, using GCC and I wonder if I should choose a different compiler.

COMPILING THIS PART OF CODE (I added line numbers for reference)

342 static void gap_params_init(void)
343 {
344    ret_code_t err_code;
345    ble_gap_conn_params_t gap_conn_params;
346    ble_gap_conn_sec_mode_t sec_mode;
347
348    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode);
349
350    err_code = sd_ble_gap_device_name_set(&sec_mode,
351                                          (const uint8_t *)cfgGetDeviceName(),
352                                          strlen(cfgGetDeviceName()));

USING MY RELEASE CONFIGURATION

<configuration Name="Release"
   c_preprocessor_definitions="NDEBUG"
   gcc_debugging_level="None"
   gcc_optimization_level="Level 1" />

--- main.c -- 346 ------------------------------------------
ble_gap_conn_sec_mode_t sec_mode;
BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode);
err_code = sd_ble_gap_device_name_set(&sec_mode,
F001FEF6 bl 0x00029278 <cfgGetDeviceName>
4604     mov r4, r0
F001FEF3 bl 0x00029278 <cfgGetDeviceName>
F011FEEF bl 0x00039274 <strlen>
B282     uxth r2, r0
4621     mov r1, r4
A801     add r0, sp, #4
F7FFFFA2 bl 0x000273E4 <sd_ble_gap_device_name_set>

No trace of BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode);

USING MY DEBUG CONFIGURATION

<configuration Name="Debug"
   c_preprocessor_definitions="DEBUG"
   gcc_debugging_level="Level 3"
   gcc_optimization_level="None" />

--- main.c -- 344 ------------------------------------------
ret_code_t err_code;
ble_gap_conn_params_t gap_conn_params;
ble_gap_conn_sec_mode_t sec_mode;
BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode);
F89D3004 ldrb.w r3, [sp, #4]
2201     movs r2, #1
F3620303 bfi r3, r2, #0, #4
F88D3004 strb.w r3, [sp, #4]
F89D3004 ldrb.w r3, [sp, #4]
2201     movs r2, #1
F3621307 bfi r3, r2, #4, #4
F88D3004 strb.w r3, [sp, #4]
--- main.c -- 349 ------------------------------------------
err_code = sd_ble_gap_device_name_set(&sec_mode,
(const uint8_t *)cfgGetDeviceName(),
F003FC76 bl 0x0002B0B8 <cfgGetDeviceName>
4604     mov r4, r0
--- main.c -- 352 ------------------------------------------
strlen(cfgGetDeviceName()));
F003FC73 bl 0x0002B0B8 <cfgGetDeviceName>
4603     mov r3, r0
4618     mov r0, r3
F023F857 bl 0x0004A888 <strlen>
4603     mov r3, r0
--- main.c -- 350 ------------------------------------------
err_code = sd_ble_gap_device_name_set(&sec_mode,
B29A     uxth r2, r3
AB01     add r3, sp, #4
4621     mov r1, r4
4618     mov r0, r3
F7FFFF7C bl 0x000276E0 <sd_ble_gap_device_name_set>
9007     str r0, [sp, #28]

Not even constant folding, but the code works.

USING MY RELEASE CONFIGURATION AGAIN
<configuration Name="Release"
   c_preprocessor_definitions="NDEBUG"
   gcc_debugging_level="None"
   gcc_optimization_level="Level 1" />

BUT
REPLACING: ble_gap_conn_sec_mode_t sec_mode;
WITH : static ble_gap_conn_sec_mode_t sec_mode;

--- main.c -- 348 ------------------------------------------
BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode);
B510     push {r4, lr}
4C17     ldr r4, =0x20008688 <sec_mode.5>
B084     sub sp, sp, #16
2311     movs r3, #17
7023     strb r3, [r4]
--- main.c -- 349 ------------------------------------------
err_code = sd_ble_gap_device_name_set(&sec_mode,
F002FB1F bl 0x00029A40 <cfgGetDeviceName>
9001     str r0, [sp, #4]
F002FB1C bl 0x00029A40 <cfgGetDeviceName>
F015FC4C bl 0x0003CCA4 <strlen>
9901     ldr r1, [sp, #4]
B282     uxth r2, r0
4620     mov r0, r4
F7FFFFE7 bl 0x000273E4 <sd_ble_gap_device_name_set>

I have no clue about this behavior of the compiler; is someone experiencing the same problem?

I am using GCC; is any other compiler (SEGGER, SEGGER-NG or CLANG) better?

[cmag]

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:

1. SOFTDEVICE
2. DFU
3. FIRMWARE

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

[Einar Thorsrud]

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)

cmag said:

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

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.

cmag said:

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

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.

[cmag]

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?

[Einar Thorsrud]

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?

cmag said:

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?

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.