Hard Fault in ble_dfu_unbounded.c from SDK 17.1.0 (secure bootloader)

[ms360]

Hi!

I'm using some common bootloader code for different devices. 
One of my devices is a bit different, with an LED library that caused me to increase the BL size in the linker. 
This is not happening on my other devices, which is why I mentioned the different linker.
2 of them also have a modified linker for a small LCD driver. Those work great!

When I debug the application jumping to bootloader with NRF DFU IOS app, 
I get a hard fault in nrf_dfu_set_adv_name(). Name should be "DfuTarg", from my bootloader make file

CFLAGS += -DDEVICE_NAME=\"DfuTarg\" -DNRF_DFU_BLE_ADV_NAME=\"DfuTarg\"

CFLAGS += -DNRF_DFU_DEBUG_VERSION

CFLAGS += -DNRF_DFU_SETTINGS_VERSION=2

CFLAGS += -DNRF_DFU_SVCI_ENABLED

In my application makefile 

CFLAGS += -DNRF_DFU_SVCI_ENABLED -DNRF_DFU_TRANSPORT_BLE=1

CFLAGS += -DNRF_DFU_SETTINGS_VERSION=2

As you can see here, Dfu31280 is showing up instead of DfuTarg, 

Here is the call stack, HardFault is where the PC indicates inside NMI_Handler

[Vidar Berg]

Hello,

When I debug the application jumping to bootloader with NRF DFU IOS app, 
I get a hard fault in nrf_dfu_set_adv_name(). Name should be "DfuTarg", from my bootloader make file

The iOS DFU lib will send the "Set advertisement name" command to change the advertisement name to be used in DFU mode before sending the "Enter DFU mode" command. Setting a unique adv. name (like "Dfu31280" in this case) is how the phone is automatically able to recconnect to the device after it has entered DFU mode. On android you don't have to do this as it allows you to specify which BLE address you want to connect to.

Does your application call ble_dfu_buttonless_async_svci_init() at the beginning of main()? If not the function pointer for nrf_dfu_set_adv_name() will not be initialized correctly which will result in  a fault exception when called.

Best regards,

Vidar

[ms360]

That was good advice Vidar. 
I added that to my application, and the jump to the bootloader happens successfully with no hardfault. 

The new issue - The bootloader is using adv name Dfu91426 instead of DfuTarg. 
The NRF DFU app just hangs after 'Bootloader Enabled' and Fails at 'DFU initialization' 

<debug> app: Initializing transports (found: 1)
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> nrf_dfu_ble: Setting up vector table: 0x000F0000
<debug> nrf_dfu_ble: Enabling SoftDevice.
<debug> nrf_dfu_ble: Configuring BLE stack.
<debug> nrf_dfu_ble: Enabling the BLE stack.
<debug> nrf_dfu_ble: Setting adv name: Dfu91426, length: 8
<debug> nrf_dfu_ble: Advertising...
<debug> nrf_dfu_ble: BLE DFU transport initialized.
<debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.
<debug> app: Enter main loop

[Vidar Berg]

Good to hear that you are no longer experiencing the hardfault. 

ms360 said:

The new issue - The bootloader is using adv name Dfu91426 instead of DfuTarg. 
The NRF DFU app just hangs after 'Bootloader Enabled' and Fails at 'DFU initialization' 

It sounds like the issue is that the phone is not trying to reconnect after the device as entered DFU mode. Have you tried testing this with our nRF Connect app on iOS? 

[ms360]

yeah I just tried that from the nRF connect app. Same result. the device shows up as DfuXXXXX instead of DfuTarg, then the DFU fails. Shouldn't the device be advertising as DfuTarg? The nRF connect app says 'no DFU Target found'

[Vidar Berg]

Yes, iOS changes the advertisement name from "DfuTarg" to "DfuXXXXX" before entering DFU mode to ensure it will be able to reconnect to the correct device and not another device within range that is also advertising as "DfuTarg". Could you post the log from the nRF Connect app here?