Peripheral HR Coded Execution failure

[KentOverton]

I've just loaded 2.5.0 onto my system - a Windows 11 laptop running VSCode 1.84.2).

I'm trying to implement DFU.

In recreating the environment described in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.5.0/nrf/device_guides/working_with_nrf/nrf52/developing.html#ug-nrf52

I opted to start with the sample peripheral_hr_coded I 

     1. Copped the samle project into my local worksace.

     2. Configured and compiled it for my PCA10040 (nrf52dk_nrf52830)

When I loaded it onto my board the following was displayed on the debug terminal.

oïû*** Booting Zephyr OS build v3.3.99-ncs1 ***
Starting Bluetooth Peripheral HR coded example
I: SoftDevice Controller build revision:
I: e0 7e 2e c1 5e 05 85 23 |.~..^..#
I: 46 15 dc fa 8e 29 7d 70 |F....)}p
I: 10 93 a5 fc |....
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF52x (0x0002)
I: Firmware: Standard Bluetooth controller (0x00) Version 224.11902 Build 2231721665
I: Identity: DD:07:D5:11:AE:79 (random)
I: HCI: version 5.4 (0x0d) revision 0x1077, manufacturer 0x0059
I: LMP: version 5.4 (0x0d) subver 0x1077
Bluetooth initialized
W: opcode 0x2036 status 0x11
Failed to create advertiser set (err -5)
Advertising failed to create (err -5)

II rebuilt the project for my PAC100456 (nrf52840dk_nrf52840.

When I loaded it onto my board the following was displayed on the debug terminal.

*** Booting Zephyr OS build v3.3.99-ncs1 ***
Starting Bluetooth Peripheral HR coded example
I: SoftDevice Controller build revision:
I: e0 7e 2e c1 5e 05 85 23 |.~..^..#
I: 46 15 dc fa 8e 29 7d 70 |F....)}p
I: 10 93 a5 fc |....
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF52x (0x0002)
I: Firmware: Standard Bluetooth controller (0x00) Version 224.11902 Build 2231721665
I: Identity: C2:A4:B9:14:54:1001bc0 set started

Clearly the progam is running - the LED is flashing on and off.

Using NRF Toolbox on my Android phone I don't see the HRN.

When I run NRF Connect on my Android phone I don't see MAC C2:A4:B9:14:54:10.

Until I resolve this issue i cannot move further on my research.

As an additional note - and perhaps I should write up a separate ticket.

Your DFU Documentation  ( https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.5.0/nrf/device_guides/working_with_nrf/nrf52/developing.html#ug-nrf52) lacks a few essential elements.

It tells you how to generate a module with DFU enabled. But does not tell you how to load it onto a development or production board.

If I add 

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

 to prj.conf in the peripheral_hr_coded example and build it six hex files are created

ap_moved_test_update.hex

app_signed.hex

ap_test_update.hex

mcuboot_primary.hex

mcuboot_primary_app.hex

merged.hex

zepjhyr.hex

There's nothing to indicate which of these are to be loaded.

 

There is also nothing I can see that tells you how to start the DFU udate from within an application.

In any case, thank you for your help.

[PaKa]

That sample is using coded PHY. This is not available on the nRF52832 so explains why that won't run the code.

For cell phones, not many phones support Coded PHY so you must check your phone. You can check this from the nRF Connect app, it's under "Device Information". If your phone doesn't support Coded Phy (the long range mode) then I suggest you try with a normal HR sample instead.

[KentOverton]

Thank  you. I loaded the. Zephyr HRM example and it works for me.

Can you comment on my DFU question's - or should I submit a new ticket?

[Vidar Berg]

Hello,

West flash or the flash button in the vs code extension will automatically load the 'merged.hex' file which contains the FW images included in your build (i.e. bootloader and application). For a detailed overview of the other files generated by the build, please refer to this section of the SDK documentation: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.5.0/nrf/config_and_build/multi_image.html#what-image-files-are and this:

The app_update.bin is the DFU file which you can upload with the nRF Connect app or nRF Device manager app on Android or iOS.

Best regards,

Vidar

[KentOverton]

I sort-of understand this.

The 'merged.hex'  is two bootloaders and the application - correct?

But I'm afraid I still don't understand the mechanics (or for that matter the real world implementation) of the new construct..

I did an NRF51 implementation six years ago where there was a bootloader, the stack, my application and a DFU application.

On a normal boot the bootloader loaded my application.

When I wanted a firmware update my application notified the boot loader to load the DFU application - which handled the Bluetooth transport, validation and installation of the update and then rebooted my (updated) application.

It seems to me that there has to be some module that actually handles these same mechanics - but I don't see any reference to it in the documentation.

[Vidar Berg]

KentOverton said:

The 'merged.hex'  is two bootloaders and the application - correct?

If you are enabling MCUBoot (CONFIG_BOOTLOADER_MCUBOOT=y) and the nRF Secure Immutable Bootloader (CONFIG_SECURE_BOOT=y), then yes. However, most 52832 applications will only include MCUBoot as the only bootloader due to memory constrains. 

The build system in the nRF Connect SDK is far more advanced, allowing for the automation of the bootloader, application build, firmware signing, and other steps in a single build process. Whereas with the old SDK, you had to build the application and bootloader separately, and then manually sign the application and create firmware distribution packets using nrfutil. 

KentOverton said:

When I wanted a firmware update my application notified the boot loader to load the DFU application - which handled the Bluetooth transport, validation and installation of the update and then rebooted my (updated) application.

The bootloader (MCUBoot) is still responsible for booting the application. They key difference now is that the FW updates are received by the application and not by the bootloader when you perform DFU over BLE. The bootloader will validate and activate by the update received by the application. 

The DFU service (SMP) to receive the FW updates is added automatically to the app when you build with CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y