Peripheral HR Coded Execution failure

RE: Peripheral HR Coded Execution failure

KentOverton — Mon, 27 Nov 2023 17:14:46 GMT

That did the trick - I used nRFConnect on my phone.

I made the same changes in my application and they also seemed to work.

Thank yo for your help.

RE: Peripheral HR Coded Execution failure

Vidar Berg — Mon, 27 Nov 2023 15:03:47 GMT

It seems like your phone is attempting to perform Device Firmware Update (DFU) using the secure DFU protocol from the nRF5 SDK. For DFU over BLE, the MCU manager protocol in the nRF Connect SDK should be used. Have you selected the MCU Manager app in the nRF Toolbox? If not, please do so. If that doesn't resolve the issue, attempt the update using the nRF Connect or nRF Device Manager app.

RE: Peripheral HR Coded Execution failure

KentOverton — Mon, 27 Nov 2023 14:58:21 GMT

So - I added

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

to the HRM sample - Zephyr Heartrate Sensor

I've built in in VSCode for a PCA10040 (nrf52dk_nrf52832)

I've flashed the PCA10040 using the VSCode flash.

I've loaded the dfu_application zip file to my android phone.

When I run NRF Toolbox and select Firmware Update I can

1. Select the Zip file

2. Select the device (ZEPHYR HEARTRATE SENSOR)

But when I select "START" it doesn't do anything - the red X next to 'Enabling Bootloader' never changes

RE: Peripheral HR Coded Execution failure

Vidar Berg — Mon, 27 Nov 2023 13:53:17 GMT

[quote userid="66554" url="~/f/nordic-q-a/106045/peripheral-hr-coded-execution-failure/457582"]The 'merged.hex' is two bootloaders and the application - correct?[/quote]

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.

[quote userid="66554" url="~/f/nordic-q-a/106045/peripheral-hr-coded-execution-failure/457582"]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.[/quote]

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

RE: Peripheral HR Coded Execution failure

KentOverton — Mon, 27 Nov 2023 13:40:40 GMT

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.

RE: Peripheral HR Coded Execution failure

Vidar Berg — Mon, 27 Nov 2023 11:41:27 GMT

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

RE: Peripheral HR Coded Execution failure

KentOverton — Fri, 24 Nov 2023 15:09:01 GMT

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?

RE: Peripheral HR Coded Execution failure

PaKa — Fri, 24 Nov 2023 14:09:28 GMT

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.