Background DFU application source code

RE: Background DFU application source code

AIRAM — Fri, 23 Jun 2023 13:01:52 GMT

Hi Vidar
I am trying to run the same example in nrf52832 sdk 15.3.0 but I am encountering the below error,

Moreover, when I pause during debugging it stops on 0x15xxx BF40 sev
I can't figure out how to solve it,

RE: Background DFU application source code

Harish_C_S_ — Wed, 14 Sep 2022 06:25:31 GMT

Hello all,

I have tried the Background Dfu code3 provided here, I have flashed the Program using the script "program_bl_sd_bl_settings_52840" but when I try to debug using j-link viewer, I get this error.

00> <info> app: Entering DFU mode.
00> 
00> <info> app: NRF_DFU_EVT_DFU_INITIALIZED
00> 
00> <info> app: NRF_DFU_EVT_TRANSPORT_ACTIVATED
00> 
00> <info> app: Application version 1
00> 
00> <error> app: ERROR 12 [NRF_ERROR_DATA_SIZE] at E:\1-Harish-new-workspace\DFU-HTTP-AZTAG\nRF_SDK_15.3.0_background_dfu_3_uart_support\components\libraries\bootloader\serial_dfu\nrf_dfu_serial_uart.c:145
00> 
00> PC at: 0x0003E4E7
00> 
00> <error> app: End of error report
00>

Hardware Used:

Follow Up Reply:

Hardware Usage

I use PCA10056

1.1.0

2019.6

RE: Background DFU application source code

Harish_C_S_ — Wed, 14 Sep 2022 06:23:49 GMT

Follow Up Reply:

Hardware Usage

I use PCA10056

1.1.0

2019.6

RE: Background DFU application source code

Harish_C_S_ — Wed, 14 Sep 2022 06:15:54 GMT

Hello all,

I have tried the Background Dfu code3 provided here, I have flashed the Program using the script "program_bl_sd_bl_settings_52840" but when I try to debug using j-link viewer, I get this error.

00> <info> app: Entering DFU mode.
00> 
00> <info> app: NRF_DFU_EVT_DFU_INITIALIZED
00> 
00> <info> app: NRF_DFU_EVT_TRANSPORT_ACTIVATED
00> 
00> <info> app: Application version 1
00> 
00> <error> app: ERROR 12 [NRF_ERROR_DATA_SIZE] at E:\1-Harish-new-workspace\DFU-HTTP-AZTAG\nRF_SDK_15.3.0_background_dfu_3_uart_support\components\libraries\bootloader\serial_dfu\nrf_dfu_serial_uart.c:145
00> 
00> PC at: 0x0003E4E7
00> 
00> <error> app: End of error report
00>

RE: Background DFU application source code

Honey — Wed, 12 Feb 2020 11:08:57 GMT

It is working. Thanks

/cfs-file/__key/communityserver-discussions-components-files/4/VID_5F00_20200212_5F00_162951.mp4

RE: Background DFU application source code

Satwik — Tue, 31 Dec 2019 09:13:58 GMT

Hi Vidar,

I have used the example code which you shared (nRF_SDK_15.3.0_background_dfu_3.zip). But after doing the firmware update, after running some time its moving to the following error.

RE: Background DFU application source code

twittich — Fri, 05 Jul 2019 09:42:03 GMT

Hello

can i run my application byside the dfu mode in your example?

I tested it already(the 52840 version) and the dfu device is there but where is the entry point so that i can add my app code or for example the blinky code ?

Thanks in advance

twittich

RE: Background DFU application source code

Vidar Berg — Fri, 31 May 2019 06:26:40 GMT

I think you make it work if you use the nRF52840 and have enough space in Bank 1 to store both bootloader and Softdevice.

RE: Background DFU application source code

nrbrook — Thu, 30 May 2019 12:12:14 GMT

Will it ever be possible to perform bootloader and softdevice update through the application?

RE: Background DFU application source code

Cecylia — Fri, 17 May 2019 23:33:43 GMT

Hi Vidar, I've got a new 52840 DK board (1.1.0 2019.9), and I could run the example background_dfu_3 you sent. Thanks so much!

RE: Background DFU application source code

Vidar Berg — Thu, 16 May 2019 12:34:20 GMT

Glad to hear that it worked on the 52832. I've fixed the issue with hashing for the 52840 port now, please see attached below (added RAM buffering in cc310_backend_hash.c).

devzone.nordicsemi.com/.../nRF_5F00_SDK_5F00_15.3.0_5F00_background_5F00_dfu_5F00_3.zip

You have Eng. Rev A on your board, so would strongly recommend that you get a new kit, particularly if you're working with the nRF USB.

[quote user="cecyliaw"]When you asked "is it possible", do you mean whether the size would fit? Or, are there other consideration? I'm a bit clueless on this, and from some info I could find, it doesn't seem like we have the need to use it yet.[/quote]

The bootloader version of the cc310 backend has a smaller feature set to reduce memory footprint. It only supports the operations I mentioned earlier. So when I asked if "is it possible", I meant if you needed other crypto operations not available in the bootloader backend.

RE: Background DFU application source code

Cecylia — Thu, 16 May 2019 00:30:45 GMT

Good news, I could run the 52832 example on the NRF52 DK I recently received. I had some hiccups with monitoring the logs on JLink 641a, but with JLink 6.40 I could see the LOG much better.

I look at the link you provided and I couldn't match my board. It seems that my board most likely needs to be replaced to run newer SDK examples. Please let me know if you can tell which IC revision this is.

I haven't tried cc310 in our existing app. When you asked "is it possible", do you mean whether the size would fit? Or, are there other consideration? I'm a bit clueless on this, and from some info I could find, it doesn't seem like we have the need to use it yet.

Thanks,
Cecylia

RE: Background DFU application source code

Vidar Berg — Tue, 14 May 2019 16:01:34 GMT

Hi,

[quote user="cecyliaw"]So the NRF52DK has arrived. But when I try it, the debugger never stops at main() function.
Steps were:
1) Program using program_bl_sd_bl_settings.bat
2) Build the ble_app_hrs_pca10040_s132 project
3) Ran debugger.[/quote]

Please try to do a complete "re-build" and see if it helps. Maybe it's missing the debug symbols. Otherwise, it may be the CRC validation of the app image inside the bootloader that fails, in that case, the bootloader will enter DFU mode instead of booting the app.

[quote user="cecyliaw"]
If I pause the debugger, it stops at address 0x15xxx..but showing no source file..
And, the Teraterm at 115200 shows no log at all. I upload here the screenshot of trying to run the debugger.
Should I use "Debug" or "Release" btw? Although both didn't work as expected for me.[/quote]

0x15xxx is the wait for events loop inside the Softdevice. This is where the program ends up when you call sd_app_evt_wait(). But it's hard to say if it was called from the bootloader or the app.

I used the RTT backend for logging since the UART is used for DFU (there's only 1 UART on 52832). RTT logs should be shown in the console output in SES.

The scripts I made assumes that you use the "Debug" target. This target will also enable more verbose error logging, so suggest that you use this target for now.

[quote user="cecyliaw"]I also made progres with the NRF52840 DK (thanks!) I ran this on the Eval board. Btw, I'm not actually sure if my board is PreviewDK or just DK, I don't know how to tell them apart. Here's the project files.[/quote]

The white sticker on the interface MCU tells you the version number of the board. Version 1.0.0 and later means that you have a non-preview kit. However, it's more important to know what IC revision you have. You can check the laser markings and look up the build code here: https://infocenter.nordicsemi.com/topic/comp_matrix_nrf52840/COMP/nrf52840/nRF52840_ic_revision_overview.html?cp=3_0_3_0. Engineering C and later should be fine.

I'm almost finished with porting the sample project to nRF52840. The only problem is that the final hash validation fails because the cc310 backend needs the hash message (i.e., application image) to reside in RAM, not FLASH. We have solved this in the bootloader by using an immediate RAM buffer.

PCA10056 project:

devzone.nordicsemi.com/.../nRF_5F00_SDK_5F00_15.3.0_5F00_background_5F00_dfu_5F00_2.zip

[quote user="cecyliaw"]But as I'm running the debugger, when I check again, 0xFF8 and 0xFFC become all F's.[/quote]

SES programs the Softdevice along with the application hex, that's why the addresses are being overwritten. A workaround is to disable automatic programming of the Softdevice. Have done that in the attached project.

Edit: Forgot to ask if it's possible to use the cc310 bootloader backend in your existing app? That would fix the problem with hashing. It supports the secp256r1 and secp224r1 curve for ECC, and sha256.

RE: Background DFU application source code

Cecylia — Tue, 14 May 2019 02:37:10 GMT

Hi Vidar,

So the NRF52DK has arrived. But when I try it, the debugger never stops at main() function.
Steps were:
1) Program using program_bl_sd_bl_settings.bat
2) Build the ble_app_hrs_pca10040_s132 project
3) Ran debugger.

If I pause the debugger, it stops at address 0x15xxx..but showing no source file..
And, the Teraterm at 115200 shows no log at all. I upload here the screenshot of trying to run the debugger.
Should I use "Debug" or "Release" btw? Although both didn't work as expected for me.
devzone.nordicsemi.com/.../cantdebug.mp4

I also made progres with the NRF52840 DK (thanks!) I ran this on the Eval board. Btw, I'm not actually sure if my board is PreviewDK or just DK, I don't know how to tell them apart. Here's the project files.
devzone.nordicsemi.com/.../pca10056.zip

It shows some printfs on Teraterm, but it has issue with the Bootloader address so it fails to continue.

After I program with program_bl_sd_bl_settings, 0xFF8 shows the right address.
>nrfjprog --memrd 0xff8 --n 100
0x00000FF8: 00078000 0007E000 20001380 00024B19 |........... .K..|
0x00001008: 0000C005 00024A7F 0000C005 0000C005 |.....J..........|
0x00001018: 0000C005 00000000 00000000 00000000 |................|
0x00001028: 00000000 00024B75 0000C005 00000000 |....uK..........|
0x00001038: 0000C005 0000C005 00024BDD 00024BE3 |.........K...K..|
0x00001048: 0000C005 0000C005 0000C005 0000C005 |................|
0x00001058: 0000C005 |....|

But as I'm running the debugger, when I check again, 0xFF8 and 0xFFC become all F's.
>nrfjprog --memrd 0xff8 --n 100
0x00000FF8: FFFFFFFF FFFFFFFF 20001380 000257B1 |........... .W..|
0x00001008: 0000C069 00025717 0000C069 0000C069 |i....W..i...i...|
0x00001018: 0000C069 00000000 00000000 00000000 |i...............|
0x00001028: 00000000 0002580D 0000C069 00000000 |.....X..i.......|
0x00001038: 0000C069 0000C069 00025875 0002587B |i...i...uX..{X..|
0x00001048: 0000C069 0000C069 0000C069 0000C069 |i...i...i...i...|
0x00001058: 0000C069 |i...|

Please let me know how to proceed. Thanks 🙂

RE: Background DFU application source code

Vidar Berg — Fri, 10 May 2019 12:15:20 GMT

Hi,

I think you can use the ble_app_hrs example for PCA10056 as a starting point and add the following files to your *.ewp file:

Then replace main.c file with the one from the other project. You also need to copy the DFU configuration from the sdk_config.h file. Just let me know if you run into any problems, I can probably help with porting next week if neccessary.

RE: Background DFU application source code

Cecylia — Thu, 09 May 2019 03:20:21 GMT

Hi Vidar, I don't have a DK, and Segger SES is kind of new for me actually (we're mostly using IAR). I'm ordering one nRF52-DK that will arrive in 2 days. But in the meantime do you have some pointers on how to try to change the linker settings so I can try it on 52840?

RE: Background DFU application source code

Vidar Berg — Wed, 08 May 2019 09:49:43 GMT

Hi,

I've uploaded the project to the other thread. It's configured for the 52832, so some porting will be required to make it run on the 52840 (mainly linker settings). Do you have a nRF52 DK to test with so you can verify that everything works first?

[quote user="cecyliaw"]For the app side, porting the bootloader code to "copy the DFU request handling" from the app seems very involved. So, I'm thinking to just manually copy the new FW to the flash chunk by chunk (and do simple CRC check). Will this be enough?[/quote]

I think would be easier to re-use the "dfu" files from the bootloader. This gives you support for FW signing, and you will not have to modify the existing bootloader. The remaining task will then be to create a custom DFU transport to be used by the app.

RE: Background DFU application source code

Cecylia — Wed, 08 May 2019 01:45:51 GMT

Hi Vidar,

Thanks for your prompt response!

For the app side, porting the bootloader code to "copy the DFU request handling" from the app seems very involved. So, I'm thinking to just manually copy the new FW to the flash chunk by chunk (and do simple CRC check). Will this be enough?

Or, will I also need to update the Bootloader Settings to notify the Bootloader that there's image in Bank 1?

The bootloader that I have in mind is very similar to what you wrote on the other ticket:

1. Checks to see if should enter DFU mode or not (I already have this working via USB)
2. Check if there are any new FW images to activate (could be an image that the app has stored).
3. If dfu_enter == true, initialize transport and wait for DFU master to initiate a DFU
4. if dfu_enter == false, verify CRC of app image and boot the app.

I notice in the other ticket that you will release a sample bootloader that can validate FW in flash. I'll probably wait for that also because I'm not sure how to tell the bootloader that there's a new FW image to activate.

RE: Background DFU application source code

Vidar Berg — Tue, 07 May 2019 13:57:37 GMT

The install folder is the same as "SDK root", so \nRF5_SDK_15.3.0_59ac345\examples\iot\bootloader. What you need to do is to copy the DFU request handling from the bootloader to the application, then make your own custom ESB/WIFI transport layer for DFU. The transport layer requirements are outlined in the Bootloader documentation here: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.3.0/lib_dfu_transport.html?cp=5_0_3_5_2. The same bootloader is also used in our thread/zigbee SDK for background DFU, so may use those as a reference.

Another relevant thread https://devzone.nordicsemi.com/f/nordic-q-a/46336/bootloader-no-transport-dual-bank-dfu-and-dependencies.