DFU: SDK14.1.0 to 17.1.0

RE: DFU: SDK14.1.0 to 17.1.0

Hung Bui — Tue, 15 Aug 2023 08:11:31 GMT

Hi Peter,
No BL setting should not be included in the .zip file.
The BL setting is only used when you want to flash (via a programmer) your application at the same time as the bootloader and the softdevice/MBR.

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Mon, 14 Aug 2023 22:00:26 GMT

Hi Hung Bui,

the difference in your approach and mine is that in the first step I generate settings and then merge them with the BL hex file, This is why I used settings page in the BL size calculation and also why the bl_size is as it is.

Now I am confused how to use settings. It looks you dont use them at all?

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Hung Bui — Mon, 14 Aug 2023 14:14:02 GMT

Hi Peter,

The new bootloader also have the length of 0xC000 ?

FLASH (rx) : ORIGIN = 0x72000, LENGTH = 0xc000

I did a quick test here with both version of the bootloader (SDK v17.1), the non-debug and the debug one.
On the non-debug

Here is the setting:

So the bootloader is located from 0x78000 until 0x7E000 with the size of 24576 bytes.

When I generated the .zip file (test2) the manifest show 23624 bytes so it well within the range.

In the debug bootloader :

The size is 0xd000 = 53248 and the result when generate .zip file (test.zip) is 48088 <53248.
Here is the command I used to generate the .zip file

nrfutil nrf5sdk-tools pkg generate --key-file private.key --softdevice s132_nrf52_7.2.0_softdevice.hex --bootloader secure_bootloader_ble_s132_pca10040.hex test2.zip --hw-version 52 --sd-req 0x0101 --bootloader-version 2

So the question is why in your case the size of the bootloader in the .zip increased over the actual size of it ?

Did you modify the bootloader binary ? Did you change anything with the MBR Param page ?

devzone.nordicsemi.com/.../14082023.zip

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Mon, 14 Aug 2023 12:41:07 GMT

Please look at

(Missing Ticket)

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Mon, 14 Aug 2023 12:34:44 GMT

Hi Hung Bui,

both old and new BL start at 0x72000.

You can see size and location of the new BL:

Th DFU zip json is as follows:

{
    "manifest": {
        "softdevice_bootloader": {
            "bin_file": "sd_bl.bin",
            "dat_file": "sd_bl.dat",
            "info_read_only_metadata": {
                "bl_size": 53340,
                "sd_size": 149868
            }
        }
    }
}

The bl_size = 0x7F000 - 0x72000 + 0x5C = 0xD05C = 53340

The sd_size is correct SD size.

I can upload the zip file to a separate private thread (already used for Vidar).

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Hung Bui — Fri, 11 Aug 2023 15:23:11 GMT

Hi Peter,
I'm a little bit confused.

Please let me know:

- The start address of your original bootloader (0x72000 ?)

- The actual size of your original bootloader (the size of bootloader's flash when you compile it)

- The start address of your new bootloader (before your modification) (0x70000 ? )

- The actual size of your new bootloader (the size of bootloader's flash when you compile it)

As far as I know BL setting and MBR page is not send via DFU. They are not included in the .zip file.

You can move the new BL address to upper address but if the size of the BL is not reduced, it will exceed the maximum amount of flash (the celling) and you will have problem when sending it to the old bootloader.

Please also look into the .zip file and find the binary, it tells exactly the size of the bootloader image.

Why can't you re-build the new bootloader to address 0x72000 ?

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Fri, 11 Aug 2023 10:49:45 GMT

Hi Hung Bui,

I returned back to the former DFU problem I face - NRF_DFU_RES_CODE_INSUFFICIENT_RESOURCES indication at start of the DFU. I identified it fails in the file dfu_req_handling.c, line:

if (p_init->bl_size > NRF_MBR_PARAMS_PAGE_ADDRESS - BOOTLOADER_START_ADDR)
{
NRF_LOG_ERROR("BL too large (SD+BL)");
return NRF_DFU_RES_CODE_INSUFFICIENT_RESOURCES;
}

Result of the expression in the if condition is 0x7E000 - 0x72000 = 0xC000. The dfu zip file shows "bl_size": 53340 that is 0xD05C. This is not the real BL size (around 28kB) but the size from the start address of the BL up to the end of 92 bytes of BL setting page. This I understand that the DFU zip package contains the BL image + MBR page + BL settings page + empty space in between.

In reality there might not be a space problem in this address setting, it is only what BL size is passed and how it is interpreted.

When I moved the BL start address to upper addresses, it fixed the DFU error but the BL was placed at the original address 0x72000 but the BL was built for different addresses location (and thus probably it fails).

Please, can you advise me how to fix this?

Thanx.

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Hung Bui — Thu, 10 Aug 2023 14:06:14 GMT

Hi Peter,
It's normal to have some segmented memory like it showed. It's because the new image is received on the swap bank and it may cause nRFConnect Programmer to interpret the flash memory like that. You may want to a flash read out and compare with what you have when you flash the SD+BL+APP with a programmer.

I'm not so sure why the SD address changed like it showed in the screenshot.

It's a long discussion so I may not have the overview of what is going on here. But my suggestion is to try testing only with SD+BL and try to update from one SD+BL in old SDK to new SD +BL in new SDK and verify that it work.
After that you can try doing SD+BL then do APP separately , so 2 .zip files and 2 DFU.

Only after you can verify that you can do that with no problem, then you can start the process again with SD+BL+APP in one shot.

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Thu, 10 Aug 2023 13:56:00 GMT

Hi Hung Bui,

thanx for your feedback. I dont need necessarily to use a different BL address. The reason for that is that the DFU complained NRF_DFU_RES_CODE_INSUFFICIENT_RESOURCES. That I identified it is due to I used lower BL address. When I used a higher BL address, the problem disappeared. This is not my primary problem.

What I need to resolve is that after a successful BL + SD (process) update I can see the flash memory like you can see on the pictures above and the device is not answering, due to corrupted flash memory and wrong SD size I believe. My question is what can be the reason for flash memory segmented like above although the DFU process passes ok.

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Hung Bui — Thu, 10 Aug 2023 11:33:31 GMT

Hi Peter,
Vidar is away and I will take over his case in the mean time. Sorry for the late response.

I don't know if you aware but it's not straight forward to change the BL start address.
It's stored either in the UICR or in the MBR info page in flash.
It's written to flash/UICR when you flash the bootloader for the first time and will stay the same after DFU update.
So in your case, you are trying to change the bootloader start address from address 0x72000 (in the old bootloader) to address 0x76000 in new bootloader ?
Can you confirm that ?
If it's the case you may want to build your new bootloader using the same start address of 0x72000.
If it's the opposite then it can be more challenging on how we can erase the MBR info page and then write a new start address during the DFU process. This may require an intermittent bootloader and risk of bricking the device. We will try to avoid doing it if possible.

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Fri, 04 Aug 2023 21:10:47 GMT

Hi Vidar,

I managed to debug the DFU of BL+SD+app. It showed that it passed ok, resulting in positive result and initiating reset.

I tried to read back flash memory after the DFU. The image shows how it should look like (left side) and how the flash looks like after DFU (right side).

So the flash was mixed up. I can find there BL settings (correct location and size) and BL (wrong location, correct length). SD is correctly located but wrong size. Application is wrongly located and also wrong size.

I tried to make BL+SD only DFU. The memory image after DFU is as below:

You can see that it is the same as in the BL+SD+app case. The only difference is that the end of the DFU process is correct, no error message.

In both cases I can see that the BL is placed at 0x72000 address and the size is correct. The project file of the new BL specifies address 0x76000. My understanding was that the nrfutil reads the BL start address from its hex file and uses that one.

Now I am confused how can I change / specify the new BL start address? But, of course, this is probably only one problem. The other one is why the flash look like it is and SD has a wrong size?

Thanx.

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Wed, 02 Aug 2023 14:51:05 GMT

Hi Vidar,

using LED "debugging" of Release version I came to the result. This is the condition that triggers the NRF_DFU_RES_CODE_INSUFFICIENT_RESOURCES, for the DFU_FW_TYPE_SOFTDEVICE_BOOTLOADER case:

if (p_init->bl_size > NRF_MBR_PARAMS_PAGE_ADDRESS - BOOTLOADER_START_ADDR)

Looking into the manifest file I can see that the BL size is really bigger than the old BL size. So I changed the BL start address the opposite way to 0x75000, size to 0x9000 and the DFU started to work.

Now I am trying to make DFU BL + SD + app in one shot. The transfer works ok but at the end (100%) I am getting an error: DFU failed with error: Connect timed out

Any idea what to check?

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Wed, 02 Aug 2023 13:28:43 GMT

Hi Vidar,

I managed to get the bootloader 14.1.0 working in both Release and Debug versions, in SES environment.

The Release version shows INSUFFICIENT_RESOURCES as the original build.

The Debug version, I had to change flash memory settings to start at 0x6D000 and size 0x11000 (vs 0x72000 and size 0xc000 for Release) to get it build. Unfortunately, the DFU passes ok, so no break point was triggered. Probably this flash memory change helped to the problem not appear.

Do you have an idea what to try now?

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Wed, 02 Aug 2023 10:30:37 GMT

Sorry, it looks I found the way.

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Wed, 02 Aug 2023 10:21:00 GMT

Hi Vidar,

after a break I came back to finalize this problem. I want to debug the BL 14.1.0 as you suggested. As the original project was done in a different environment that I dont have available now, I created a SES project for the bootloader. I used the project file from examples, secured BLE bootloader, debug.

I can compile successfully the project for Release version. But I am not getting the Debug option in the SES Options. On contrary, I can switch to Debug in the SDK 17.1.0 version of the project.

I compared both the SES project files but I cant see any difference that could make the Debug option visible.

Please, can you advise me how to enable the SES project for the Debug option?

Thanx.

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Vidar Berg — Wed, 19 Jul 2023 12:06:24 GMT

Hi peter,

Thanks. I looked over the "init" command and the binaries, and I don't see anything indicating the update should be too big. Next thing I would suggest you try is to debug the bootloader (SDK 14) and place breakpoints at the lines where 'NRF_DFU_RES_CODE_INSUFFICIENT_RESOURCES' is returned.

Best regards,

Vidar

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Wed, 19 Jul 2023 11:47:35 GMT

Hi Vidar,

created.

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Vidar Berg — Wed, 19 Jul 2023 11:41:59 GMT

Hi peter,

Strange, it should not be a problem to fit the Softdevice in bank 0 (it overwrites the existing application). Can you upload your DFU .zip file here or in a private ticket?

Thanks,

Vidar

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Wed, 19 Jul 2023 11:38:42 GMT

Hi Vidar,

I changed the start to 0x72000 and size to 0xc000. Rebuild works, also I checked map file, saying 0x72000 __reserved_flash_start__. I created a new package and it gives the same result, INSUFFICIENT_RESOURCES.

Can it be SD size related? Or what else to check?

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Vidar Berg — Wed, 19 Jul 2023 11:02:31 GMT

Hi Peter,

Yes, this explains the INSUFFICIENT_RESOURCES. It is not possible to safely change the bootloader start address through DFU. Therefore, the solution should be to build the new bootloader with the same start address (i.e. 0x72000) as the old one.

Does the project build if you change FLASH_START from 0x70000 to 0x72000?

Best regards,

Vidar

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Wed, 19 Jul 2023 10:50:33 GMT

Hi Vidar,

thanx for your feedback. The old BL has the following settings (.ld file):

MEMORY
{
FLASH (rx) : ORIGIN = 0x72000, LENGTH = 0xc000
RAM (rwx) : ORIGIN = 0x20002830, LENGTH = 0xd7d0

bootloader_settings_page (r) : ORIGIN = 0x0007F000, LENGTH = 0x1000
uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
mbr_params_page (r) : ORIGIN = 0x0007E000, LENGTH = 0x1000
uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4
}

The new BL has the following settings (SES project):

      linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x80000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x10000;FLASH_START=0x70000;FLASH_SIZE=0xe000;RAM_START=0x20005968;RAM_SIZE=0xa698"
      linker_section_placements_segments="FLASH1 RX 0x0 0x80000;RAM1 RWX 0x20000000 0x10000;mbr_params_page RX 0x0007E000 0x1000;bootloader_settings_page RX 0x0007F000 0x1000;uicr_bootloader_start_address RX 0x10001014 0x4;uicr_mbr_params_page RX 0x10001018 0x4"

If I read it correctly then the old BL starts on 0x72000 while the new one on 0x70000 so this could explain not enough space.

I checked nrfutil settings generate options how to specify BL start address but I dont see it there (only settings address).

Can you please help me if my understanding is correct and how to fix it.

Thanx.

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Vidar Berg — Wed, 19 Jul 2023 07:58:04 GMT

Hi Peter,

In this case, since you didn't get to the second round where the app is updated, the INSUFFICIENT_RESOURCES error indicates that the bootloader is too big for your allocated bootloader region. Please check if the bootloader start address in flash is the same for both the existing and the new bootloader.

Best regards,

Vidar

RE: DFU: SDK14.1.0 to 17.1.0

Peter.J — Mon, 17 Jul 2023 11:21:47 GMT

Hi Abhijith,

I am sorry, I totally forgot to mention that I am using nRF52832 MCU.

I checked the mentioned tickets and also several others but they dont help. Also, they refer to quite old target SDKs.

Best regards,

peter

RE: DFU: SDK14.1.0 to 17.1.0

Menon — Mon, 17 Jul 2023 10:44:20 GMT

Hello,

Could you share which Nordic chip or Dk you are trying with?

Have you checked this below old threads based on the same error you are getting? Please let me know if you have already gone through this and still struggling.

We are very thinly staffed due to summer vacation here in Norway So please expect some delay from my side. Sorry for any inconvenience caused (if any) because of this.

Kind Regards,

Abhijith