Custom DFU imlementation

[KentOverton]

I am implementing DFU using my own transport to retrieve the binary image from AWS.

I'm developing in 2.6.0.

I am using the DFU TARGET libraries. 

When I start my download I look at the first 512 byte block with

     i=dfu_target_img_type   (  buffer2,xblocksize); I get 1 (I think that this is DFU_TARGET_IMAGE_TYPE_MCUBOOT)

But I can't get past dfu_target_init().

When I run   i=dfu_target_init(DFU_TARGET_IMAGE_TYPE_MCUBOOT,0,filesize,NULL); I get an error 19 (No Such Device)

When I run i=dfu_target_reset(); I get an error 13 (Permission Denied)

I believe the issue lies either in my prj.conf or my static partition.

Currently, prj.conf has

CONFIG_FLASH=y

CONFIG_FLASH_MAP=y

CONFIG_BOOTLOADER_MCUBOOT=y

#  Enable DFU Target Library

CONFIG_DFU_TARGET=y

CONFIG_DFU_TARGET_MCUBOOT=y

#  Enable MCUboot Image Manager (if using MCUboot)

CONFIG_STREAM_FLASH=y

CONFIG_STREAM_FLASH_ERASE=y

CONFIG_IMG_MANAGER=y

CONFIG_MCUBOOT_IMG_MANAGER=y

My static partition  is

app:
address: 0xc200
end_address: 0x85000
region: flash_primary
size: 0x78e00
mcuboot:
address: 0x0
end_address: 0xc000
placement:
before:
- mcuboot_primary
region: flash_primary
size: 0xc000
mcuboot_pad:
address: 0xc000
end_address: 0xc200
placement:
align:
start: 0x1000
before:
- mcuboot_primary_app
region: flash_primary
size: 0x200
mcuboot_primary:
address: 0xc000
end_address: 0x85000
orig_span: &id001
- mcuboot_pad
- app
region: flash_primary
sharers: 0x1
size: 0x79000
span: *id001
mcuboot_primary_app:
address: 0xc200
end_address: 0x85000
orig_span: &id002
- app
region: flash_primary
size: 0x78e00
span: *id002
mcuboot_secondary:
address: 0x85000
end_address: 0xfe000
placement:
after:
- mcuboot_primary
align:
start: 0x1000
region: flash_primary
share_size:
- mcuboot_primary
size: 0x79000
settings_storage:
address: 0xfe000
end_address: 0x100000
placement:
align:
start: 0x1000
before:
- end
region: flash_primary
size: 0x2000
sram_primary:
address: 0x20000000
end_address: 0x20040000
region: sram_primary
size: 0x40000

I've been playing with this for five days - any help would be greatly appreciatd.

[Menon]

Hello,

Which Nordic chip or DK are you using here? What build configuration did you use for building the application?

Inside the pm_static file, mcuboot_primary seems to overlap with mcuboot_pad. Try shifting mcuboot_primary to avoid potential conflicts.

Kind regards,
Abhijith

[KentOverton]

It.s  a NRF52840-CKAA-R7.

I'm developing under 2.6.0.

It's a Custom Configuration - I've attached a version of my firmware to this note. You will see  boards directory in the project.

DFUTEST_NORDIC.zip

I've modified my project, - isolating the failing code in src/dfutest.c

In my production code there's a lot of stuff surrounding this code, A connection is made to my AWS server, a firmwaere download is requeted, the firmare downloads blocks of code from the server and processes these blocks.

dfutest.c has an image of the first block of code I get from the server.

main.c loops at the very top, continuously running the test.

[KentOverton]

I've done some more research and testing.

After looking at aother post here I added 

buffer4[1024] to line 44 of dfutest.c, giving

uint8_t buffer[1200],buffer2[1200],buffer3[100],buffer4[1024];

 

I added 

i=dfu_target_mcuboot_set_buf(buffer4,sizeof(buffer4)); at line 140 of dfutest.c.

dfu_target_init(...) now returns 0.

After just a little bit of playing around my firmwar now does the complete DFU update.

 

Could you please 

      1. tell me why this worked

      2. tell me an appropriate size for the buffer in 

                 dfu_target_mcuboot_set_buf

[Menon]

Hello,

Good to hear that you were able to make the DFU work.

This makes sense because if you look at dfu_target_mcuboot_init(), you can see that if no buffer is assigned using dfu_target_mcuboot_set_buf(), the initialization will fail, and the error message you are seeing is generated from here.

I think the appropriate buffer size depends on the flash page size. Since you are working with the nRF52840, I recommend at least 4096 bytes (or try 8192 bytes).

Kind regards,
Abhijith

[KentOverton]

Menon,

Sorry to be such a bother - burt I still have an issue.

My DFU logic woeks perfectly. I can download an update, load it inti the secondary slot and when I reboot the new firmware runs.

When I reboot a second time the firmware reverts to the old version. 

I am sure that the mechanism is fully documented documented - but I have spent more than a little time serchig for a clear description of how to confirm the download.

We are akready using FOTA over BLE, using an Android phone and nRF Connect

I want to do the equivalent of TEST and CONFIRM in nRF Connect. 

If you could point me at an example - or documentation - of how to implement this I would greatly appreciate it.