nRF51822 & Zephyr - OTA DFU

RE: nRF51822 & Zephyr - OTA DFU

liteyear — Thu, 04 Apr 2024 03:49:23 GMT

FWIW I tried to get the same outcome with a different approach. After some study of CONFIG_CODE_DATA_RELOCATION (only works for different regions it seems, not within a region) and flash_map (only suited for storage, not XIP code) I went down the custom-sections.ld linker script route. Things were looking good, separating out the app segments from the Zephyr segments, thanks to this trick that allows segments to be specified by library. Alas I hit a brick wall because there's some symbols in the app library (eg. _static_thread_data* that by default get grouped with some Zephyr symbols. If I try to move them, the app silently hangs, so I assume there's some address arithmetic going on that relies on them being grouped together.

I gather this might be the class of challenge that have led others to conclude that OS and app cannot be separated, and I have, very reluctantly, come to the same conclusion. I'd love to hear otherwise! Prior to hitting the brick wall, I had 5kB of application code isolated from >600kB of Zephyr library, and the Zephyr library was not changing as I made meaningful changes to the application. You can imagine the benefits this could bring for OTA, including opening the door to a two-stage upgrade strategy - OTA for incremental updates and cabled for OS or major updates.

RE: nRF51822 & Zephyr - OTA DFU

Hung Bui — Wed, 16 Nov 2022 11:41:27 GMT

Hi Bojan,

I'm not aware of a way to seperate zephyr OS from application. I don't think by defining a "zephyr_partition" you would be able to put the OS into a separate partition that you can split it using arm-none-eabi-objcopy.

My understanding is that when you build a Zephyr application, the OS and the application is mixed and there is no easy way to separate them.

What you see as zephyr.hex is the mixture of the Zephyr OS and the application.

This may also explain why when you change anything in the application, the zephyrOS.hex also change.

My suggestion, if the internal flash is too small, you may want to think of either using external flash to receive new image, or use our nRF5 SDK solution (Bootloader + Softdevice) and then have the zephyr application running as a NRF5 SDK application.

But i'm not so sure if you have enough space.

RE: nRF51822 & Zephyr - OTA DFU

bojan — Wed, 16 Nov 2022 09:21:47 GMT

Hello, Hung Bui !

Sorry for the delayed reply.

[quote userid="2121" url="~/f/nordic-q-a/93855/nrf51822-zephyr---ota-dfu/395537"]Could you give us more information on how you separate Zephyr from the app and how you locate Zephyr in a different partition ?[/quote]

In our custom .dts file, we have defined our memory layout in the following way:

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0x6000>;
		};
		slot0_partition: partition@6000 {
			label = "image-0";
			reg = <0x00006000 0x6000>;
		};
		slot1_partition: partition@c000 {
			label = "image-1";
			reg = <0x0000c000 0x6000>;
		};
		scratch_partition: partition@12000 {
			label = "image-scratch";
			reg = <0x00012000 0x1000>;
		};
		zephyr_partition: partition@13000 {
			label = "zephyr";
			reg = <0x000013000 0x2C000>;
		};

		storage_partition: partition@3f000 {
			label = "storage";
			reg = <0x0003f000 0x00001000>;
		};
	};
};

We separate Zephyr from the app by using the arm-none-eabi-objcopy executable from the compiler:

                // Extract app section to bin
                "${config:TOOLCHAIN_PATH}/bin/arm-none-eabi-objcopy -O binary --only-section=rom_start --only-section=app_flash ${workspaceFolder}/build/zephyr/zephyr.elf ${workspaceFolder}/images/${config:BOARD_NAME}.bin;",
                // Extract app section to hex
                "${config:TOOLCHAIN_PATH}/bin/arm-none-eabi-objcopy -O ihex --only-section=rom_start --only-section=app_flash ${workspaceFolder}/build/zephyr/zephyr.elf ${workspaceFolder}/images/${config:BOARD_NAME}.hex;",
                // Extract Zephyr section to bin
                "${config:TOOLCHAIN_PATH}/bin/arm-none-eabi-objcopy -O binary --remove-section=rom_start --remove-section=app_flash ${workspaceFolder}/build/zephyr/zephyr.elf ${workspaceFolder}/images/ZephyrOS.bin;",
                // Extract Zephyr section to hex
                "${config:TOOLCHAIN_PATH}/bin/arm-none-eabi-objcopy -O ihex --remove-section=rom_start --remove-section=app_flash ${workspaceFolder}/build/zephyr/zephyr.elf ${workspaceFolder}/images/ZephyrOS.hex;",

Here is what we have noticed recently:

Once we change the application code, compile it, and separate Zephyr from the app, ZephyrOS.hex file is different compared to the ZephyrOS.hex file we get after compilation of the initial version of the code. We found ~26 lines of difference between the two ZephyrOS.hex files. This might be the reason for HardFault after DFU.

How can we get consistent/deterministic content of the ZephyrOS.hex file? We don't change anything related to the Zephyr when we update our application code. Consequently, we expect ZephyrOS.hex part to always be the same.

[quote userid="2121" url="~/f/nordic-q-a/93855/nrf51822-zephyr---ota-dfu/395537"]Which bootloader did you use ? I assume it's MCUBoot ? [/quote]

Yes, we are using the MCUBoot bootloader.

Best,
Bojan.

RE: nRF51822 & Zephyr - OTA DFU

Hung Bui — Mon, 14 Nov 2022 11:59:22 GMT

Hi Bojan,

Could you give us more information on how you separate Zephyr from the app and how you locate Zephyr in a different partition ?

Which bootloader did you use ? I assume it's MCUBoot ?

If you try to DFU update with very simple application , for example blinking LED, do you see the same issue ?

Please be aware that we don't support nRF51 in our nRF Connect SDK. You can use it with Zephyr but it's pretty much on your own. For new development we suggest to go with nRF52 or nRF53.