Question regarding application with DFU and bootloader

RE: Question regarding application with DFU and bootloader

Hung Bui — Thu, 10 Aug 2023 09:14:47 GMT

Hi Clake,
Please make sure to add DEBUG to the preprocessor symbols in project setting. This will turn off the reset when an assert occurs.

RE: Question regarding application with DFU and bootloader

clake — Thu, 10 Aug 2023 06:37:38 GMT

Hi Hung Bui!

Yes, I see usage when I build, but it does not say RAM usage, but yeah I can check the amount used in data+bss that is the RAM consumption.

Great so I only have to check the RAM usage of my application, thanks for the confirmation.

I was changing a little bit my application looking at ble buttonless dfu, but I can make it work yet, it is failing in the mail, I can see just one log an anything else, I have also changed the RAM start address. I'll continue debugging and then try to tell more information about the error.

Best regards

RE: Question regarding application with DFU and bootloader

Hung Bui — Wed, 09 Aug 2023 14:58:36 GMT

Hi,

It's been a while I didn't use gcc, I assume you see the RAM and flash usage when you build.
https://embeddedartistry.com/blog/2020/08/17/three-gcc-flags-for-analyzing-memory-usage/

Please be aware that the bootloader and the application doesn't run at the same time. So any RAM used by the bootloader is free after it switch to the application. So you don't need to worry about the RAM used by the bootloader .

RE: Question regarding application with DFU and bootloader

clake — Wed, 09 Aug 2023 13:35:13 GMT

Hi Hung Bui and again many thanks for all your replies!

I think I have one more question. How can I know the use of RAM (I'm using armgcc to compile)? and also the bootloader uses RAM and when it start the application, the RAM that have use the bootloader is free? just to make sure that I have enough RAM for my application, since now it will have bootloader.

Best regards

RE: Question regarding application with DFU and bootloader

Hung Bui — Wed, 09 Aug 2023 12:13:46 GMT

Hi again,

[quote user="clake"]So, if I have to modify the behavior of the ble_dfu, for example to link in another GPIO instead of the pre-defined one, I have to modify it in that project right? This means that now my project will have the app (I have to merge my app and the example of ble buttonless dfu) and the secure bootloade[/quote]

The bootloader and the application is two different entity. They flashed separately and you don't combine them. What you combine is the DFU buttonless service into your application and the only task this does is to reset the device to the bootloader.

If you change the GPIO button that the bootloader used by default, you simply recompile the bootloader , not the application.

[quote user="clake"], I 'm also using NUS for ble in my application, this will lead to a conflict of having the ble buttonless dfu?[/quote]

No, it should work fine if you combine them correctly. Combining BLE NUS and Buttonless DFU

[quote user="clake"]If the application is ok and the bootloader take it as a good application but suddenly it, for some reason, doesn't work, is there a way to enter in DFU mode without using a button?[/quote]

No, the bootloader will always jump to the application if it's a valid application. It wouldn't know if it's buggy or not. But what you can do is instead of (or inaddition to) entering DFU via a button you can do a 10 seconds wait when booting up to enter DFU mode in such 10 seconds. If there is any connection in the 10 seconds then you can do DFU. After 10 seconds the bootloader can start the app.

[quote user="clake"]If I want to put the system in deep-sleep and wake it up using a button, this configuration has to be made in the bootloader? or in the application? because I whant that my device start off and when I long-press a button it wake ups and start the system.[/quote]

There is no option to wake up from a long press. We only have an option to put device in deep sleep and wake up from a GPIO interrupt. This mean it wouldn't be able to detect if it's a long press or short press. No code needed to detect this wake up source, it's done in the hardware.
Implementing the code to put the device in deep sleep should be done in bootloader or application, it's you to decide.

You can implement the code in the bootloader so that if it's power reset it will immediately enter deep sleep. If it's wake up from power reset then it will enter application. Or you can implement the same thing in the application. It's up to you.

RE: Question regarding application with DFU and bootloader

clake — Wed, 09 Aug 2023 11:16:01 GMT

Yes, since I'm using nRF52810 I have to use a single bank update.

I understand better now, thanks to your blog. So, if I have to modify the behavior of the ble_dfu, for example to link in another GPIO instead of the pre-defined one, I have to modify it in that project right? This means that now my project will have the app (I have to merge my app and the example of ble buttonless dfu) and the secure bootloader.

Also one more question, I 'm also using NUS for ble in my application, this will lead to a conflict of having the ble buttonless dfu?

Another question: If the application is ok and the bootloader take it as a good application but suddenly it, for some reason, doesn't work, is there a way to enter in DFU mode without using a button?

EDIT: one more question: If I want to put the system in deep-sleep and wake it up using a button, this configuration has to be made in the bootloader? or in the application? because I whant that my device start off and when I long-press a button it wake ups and start the system.

Best regards

RE: Question regarding application with DFU and bootloader

Hung Bui — Wed, 09 Aug 2023 07:51:17 GMT

Hi Clake,

It depends on how you configure your bootloader, would it do single bank update or dual bank update. Please take a look here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/lib_bootloader_dfu_banks.html?cp=9_1_3_5_1_2

For dual bank update, the original is preserved and the new image is copied to a swap bank.

For single bank update, the original application will be erased to get space to receive the new image. If the DFU process fail, it will fall back to the DFU bootloader and your device is only go back to normal operation after a successful update.

In your case, you use nRF52810 with limited flash space, I would assume you are using single bank update ?

RE: Question regarding application with DFU and bootloader

clake — Tue, 08 Aug 2023 18:12:06 GMT

Hi Hung Bui, thank you for your answer.

I meant the process of DFU. Does it first receive the application, then erase the application memory from the flash, and then start writing the new application? I can't see where in the memory the new application is allocated. So, if the DFU process first deletes the app partition of the flash and the process fails, the application will be empty. That is my question.

I'll check out your blog!

Best regards

RE: Question regarding application with DFU and bootloader

Hung Bui — Tue, 08 Aug 2023 10:22:57 GMT

Hi Clake,

Most of the DFU feature will be handled by the bootloader so if you plan to simply enter DFU mode by holding a button when the device reset or for example give a 15 seconds window when the device reboot to wait for DFU command then you don't need to modify the application. Simply add DFU bootloader will work. Please follow the documentation or my blog here.

However, if you plan to have "buttonless DFU" where the application would receive the DFU command via BLE when in operation to enter DFU mode, then you would need to implement buttonless service. Please take a look at the ble_app_buttonless_dfu example. It's also covered in Appendix 3 in my blog above.

[quote user=""]If the upload fails, the nrf52810 will be able to get a DFU from BLE?[/quote]

I don't get what you meant. If the DFU update fails it will return to the application and you would need to start DFU again.