merging examples with DFU cause NRF_ERROR_NO_MEM

RE: merging examples with DFU cause NRF_ERROR_NO_MEM

Edvin — Mon, 14 Mar 2022 14:09:07 GMT

I'll continue here, so it shows up approximately chronologically 🙂 If you lack a reply button, try reloading the page a couple of times.

[quote user="June20"]I haven't dig deep into the example, all I can tell is that peripheral will enter dfu-mode due to ble package from the central. I want my ble app to run until I decided to connect to dfu device (other case/explanation will be welcomed). How is bootloader_start() triggered?[/quote]

I believe what you want to do is to add the buttonless service to your custom application. Strictly speaking, you don't need this service, but it will be recognized as a DFU target by nRF Connect for Mobile/Desktop if you include it. An alternative is to have a custom service/characteristic that enters DFU mode, like the dfu_buttonless_service does, and then connect to the dfu target (advertisements from the bootloader) after it resets.

So let us assume you are using the DFU buttonless service for now. The workflow here is that you connect to the device (when the application with the buttonless service is running). Then, whenever you want to enter DFU mode, it will write to the buttonless service's characteristic, which will trigger it to reset into DFU mode. In order to reset into DFU mode, it needs to tell the bootloader when it wakes up to not start the application as normal, but to start advertising in DFU mode.

If you open the buttonless dfu example, you can see how this is done in ble_dfu_buttonless_bootloader_start_prepare() in ble_dfu_unbonded.c. in ble_dfu_buttonless_bootloader_start_finalize() (called from ble_dfu_buttonless_bootloader_start_prepare()), you can see that it writes to the GPREGRET register using sd_power_gpregret_set(). This will write to a register that the bootloader will check when it starts. If it has the value that is set here, it will enter DFU mode. This is the minimum that you must do from your application before resetting.

Does that answer the question that you had?

Best regards,

Edvin

RE: merging examples with DFU cause NRF_ERROR_NO_MEM

June20 — Mon, 14 Mar 2022 08:11:08 GMT

I haven't dig deep into the example, all I can tell is that peripheral will enter dfu-mode due to ble package from the central. I want my ble app to run until I decided to connect to dfu device (other case/explanation will be welcomed). How is bootloader_start() triggered?

Edit: Sorry for adding reply here, I don't see reply button below for some reason.

RE: merging examples with DFU cause NRF_ERROR_NO_MEM

Edvin — Fri, 11 Mar 2022 14:11:12 GMT

The guide that you already linked to (https://devzone.nordicsemi.com/guides/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader) is good. But it only covers the basics on how to compile, flash and generate update images. I am not aware of any other guides on related topics, but most use cases are already answered on DevZone, so browsing older cases is not a bad idea.

What exactly is it that you want to do? And what do you mean by "make decent scenario related to buttonless DFU"?

Best regards,

Edvin

RE: merging examples with DFU cause NRF_ERROR_NO_MEM

June20 — Fri, 11 Mar 2022 06:30:16 GMT

After couple of more attempts, I realized that I've been putting in wrong parameters.

After combining ble buttonless dfu example with my project, I was able to make it run.

I am not very familiar with topic related to DFU, is there a good guide how to make decent

scenario related to buttonless DFU?

thanks

RE: merging examples with DFU cause NRF_ERROR_NO_MEM

Edvin — Thu, 03 Mar 2022 20:35:50 GMT

[quote user="June20"]unfortunately my 'attach debugger' doesn't respond (it's just running and not much response from debugger [/quote]

If you try to set a breakpoint at the very start of main() in your application before you attach the debugger, is it reached? Have you turned off optimization in your project?

Can you show me all the commands that you use to generate your bl-settings, and then program it?

Can you also send me the files that you are trying to run? Will I be able to reproduce what you are seeing on a DK?

[quote user="June20"]

Does nrfjprog order matters??

[/quote]

As long as you don't reset the device between programming the files, it shouldn't matter. That is why I added the line "nrfjprog --reset" at the end, to indicate that you shouldn't call it between every "nrfjprog --program ...".

[quote user="June20"]

PS, Programmer gave me this response, "Part of the HEX regions are out of the device memory size, but you can still proceed write operation" <- is this safe?

[/quote]

I have seen this as well. It is a bug in nRF connect for Desktop, because it thinks that the UICR (starting at address 0x10001000) is outside the flash. However, it is not, and using nRF Connect for Desktop to program the device also programs the UICR. You can confirm this by programming the bootloader and reading out the UICR using:

nrfjprog --memrd 0x10001000 --n 128.

It doesn't write much, but you should see two registers holding the addresses of the bootloader and some settings page. (It is written to the UICR->NRFFW registers.

Best regards,

Edvin

RE: merging examples with DFU cause NRF_ERROR_NO_MEM

June20 — Thu, 03 Mar 2022 08:49:51 GMT

Okay, I assume I finally built bootloader. However, I didn't go so well.

I got hex file after building SDK/examples/dfu/secure_bootloader/pca10100_s140_ble (secure_bootloader_ble_s140_pca10100.hex)

I got hex file of Softdevice from SDK/components\softdevice\s140\hex\s140_nrf52_7.2.0_softdevice.hex

Built my application and nrfjprog all 4 hex(app, bootloader, bootloader setting, softdevice)

unfortunately my 'attach debugger' doesn't respond (it's just running and not much response from debugger + nothing on my mobile nRF Connect)

Are there things I might have forgot?

Does nrfjprog order matters??

PS, Programmer gave me this response, "Part of the HEX regions are out of the device memory size, but you can still proceed write operation" <- is this safe?

Thanks for replies.

RE: merging examples with DFU cause NRF_ERROR_NO_MEM

Edvin — Wed, 02 Mar 2022 08:37:33 GMT

[quote user="June20"]tutorial I was relying on[/quote]

That is a good guide. I use to point at this one when someone have questions about DFU in the nRF5 SDK.

I suggest that you consider upgrading to python 3.8, as most of our tools use that.

You don't need to use mergehex, really. Do you have nrfjprog, and does that work? If so, you can just program all the components separately:

nrfjprog --program bl.hex
nrfjprog --program softdevice.hex
nrfjprog --program app.hex
nrfjprog --program bl_settings.hex
nrfjprog --reset

I am not sure how nRF Connect for Desktop handles several writes. The issue is that if the chip is flashed between the bootloader being flashed and the bl settings being flashed, then the bootloader will generate its own settings, and the bl_settings.hex will not be able to be programmed correctly. That is why I prefer to use nrfjprog.

BR,
Edvin

RE: merging examples with DFU cause NRF_ERROR_NO_MEM

June20 — Wed, 02 Mar 2022 04:50:52 GMT

Thanks for the reply!

You were right, it was due to lack of bootloader - I didn't program the bootloader.

So I did 'nrfutil setting' (is nrfutil setting ... same as programming bootloader?)

nrfutil settings generate --family NRF52 --application "my_app.hex" --application-version 0 --bootloader-version 0 --bl-settings-version 2 bootloader_setting_user.hex

I couldn't use 'mergehex', my cmd promt didn't recognize the command. (Python27)

Instead, I used nRF Connect - Programmer v2.3.3.

I added my bootloader_setting_user.hex + my_application.hex + softdevice_s140.hex(found on dfu example) and programmed over it.

Sadly it didn't went well (Sometime same error from 'attach debugger', sometime no response, sometime hardfault error)

About bootloader programming, am I heading the right direction?

I'm on Windows 10 + Python27, how do I get mergehex to work?

Is it alright to use Programmer instead of mergehex?

BTW thanks for the 'Attach Debugger' tip, I was using Segger Studio.

I also rely on 'Tera Term' to debug via serial.

tutorial I was relying on: https://devzone.nordicsemi.com/guides/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader

RE: merging examples with DFU cause NRF_ERROR_NO_MEM

Edvin — Mon, 28 Feb 2022 23:17:42 GMT

Hello,

If ble_dfu_buttonless_async_svci_init() returns 4, it basically means that there are no bootloader programmed. The buttonless dfu service checks that there is actually a bootloader present by reading out some register addresses. If there isn't, it will fail.

So try flashing the bootloader as well. Unfortunately adding a bootloader makes it a bit more tricky to debug. What IDE are you using? If you are using Segger Embedded Studio, you can use "attach debugger" for the reasons I will explain now:

When a bootloader is flashed it will check on startup that the application has the correct signature. If you just program the softdevice, application and bootloader, then the application doesn't have the correct signature. So what we need to do is to generate something called bootloader settings. You can generate this using nrfutil ("nrfutil settings generate --help").

If you generate a DFU image using nrfutil, then this image is signed, and when the image is transferred to the DFU target, it will carry on that signature and CRC check and store it's own generated bootloader settings, so this is what we are essensially bypassing by generating and programming the bootloader settings directly.

The next obstacle when you want to debug is that when you start a debug session in an IDE, then the IDE will most likely program something other than the .hex file that you used for your bootloader settings. It will use some other file that is almost identical, but since changing a single bit will change the signature of the application, the bootloader will reject it, and enter DFU mode. This is why you need to use the "attach debugger" method. By doing so, you are telling your IDE that "I have already flashed the application. Just start debugging without uploading anything". If you follow this, you should be able to debug when a bootloader is flashed. If you are not using Segger Embedded Studio, look for a similar option. If your IDE doesn't provide one, you can use Segger's debugging tool Ozone, which does have this option, and it works with almost all build files (Keil, IAR, armgcc, etc...).

Since compiling, generating bootloader settings, flashing application and bootloader settings can be a bit tedious every single time you change a tiny piece of your code, I suggest that you write some sort of script (.bat scripts are easy to use on Windows). Just make it generate all the files from the .hex file that your compiler spits out, and then flash the application and bootloader settings (using nrfjprog:

nrfutil settings generate -- ....
nrfjprog --program <path_to_app.hex> --verify --sectorerase
nrfjprog --program <path_to_bootloader_settings.hex> --verify --sectorerase
nrfjprog --reset

I hope this gave some clarity. Let me know if anything was unclear.