DFU SDK15 CRC problem.

RE: DFU SDK15 CRC problem.

Mikhail — Wed, 26 Sep 2018 07:36:29 GMT

Thanks. I'll check all my bootloader settings and will write.

RE: DFU SDK15 CRC problem.

Einar Thorsrud — Wed, 26 Sep 2018 07:24:18 GMT

[quote user="metcenger"]After reset, starts SD, than transfer management to bootloader?[/quote]

Yes.

[quote user="metcenger"]But how SD known wich address of bootloader starts? 0x72000 or 0x6D000 or another?[/quote]

The SoftDevice checks the UICR.NRFFW[0] register for the bootloader start address, and this is set by the bootloader .hex file (you can search for uicr_bootloader_start_address in the bootloader code and linker script / flash placement to see how it is done). See Bootloader in the SoftDevice specification for details.

RE: DFU SDK15 CRC problem.

Mikhail — Tue, 25 Sep 2018 15:16:36 GMT

seems, work. But I need check with real DFU update. I'll write later.

Einar, one more question-

I need into bootloader insert a crypto library. For this reason I expand size of bootloader from 0x72000 to 0x6D000. All works.

Could you explain me chain of work. After reset, starts SD, than transfer management to bootloader? But how SD known wich address of bootloader starts? 0x72000 or 0x6D000 or another?

RE: DFU SDK15 CRC problem.

Mikhail — Tue, 25 Sep 2018 14:25:07 GMT

ofcourse in the bootloader project. I'll check all.

RE: DFU SDK15 CRC problem.

Mikhail — Tue, 25 Sep 2018 14:19:58 GMT

Thanks. But DFU_APP_DATA_RESERVED where should to set? In the bootloader or app projects?

RE: DFU SDK15 CRC problem.

Einar Thorsrud — Tue, 25 Sep 2018 13:37:26 GMT

[quote user="metcenger"]FDS used (0x6F000-0x71FFF). Is it right?[/quote]

Yes, that is correct. FDS uses flash pages directly beneath the bootloader. In your case your bootloader starts at 0x72000, and as you use 3 pages for FDS, this means that FDS starts at 0x6F000.

[quote user="metcenger"]Therefore, I should plase data below 0x6F000. Right?[/quote]

Yes.

[quote user="metcenger"]Is it incorrect to locate data at 0x6EC00? [/quote]

No, that is OK.

[quote user="metcenger"]Or should set DFU_APP_DATA_RESERVED more than 3? Because this means for total reserve FDS and my storage data?[/quote]

YES! You need to set it to 4, as that is the total amount of pages below the bootloader you want to preserve.

RE: DFU SDK15 CRC problem.

Mikhail — Tue, 25 Sep 2018 13:30:15 GMT

Let's speak one more time again.

FDS used (0x6F000-0x71FFF). Is it right?

Therefore, I should plase data below 0x6F000. Right?

Is it incorrect to locate data at 0x6EC00?

Why?

Or should set DFU_APP_DATA_RESERVED more than 3? Because this means for total reserve FDS and my storage data?

RE: DFU SDK15 CRC problem.

Einar Thorsrud — Tue, 25 Sep 2018 10:37:28 GMT

No, you cannot. FDS uses three pages, and you would need to reserve an additional page for your data (starting at 0x6E000). Your current DFU_APP_DATA_RESERVED value will only tell the bootloader to leave the three pages used by FDS alone (0x6F000-0x71FFF), so you must set DFU_APP_DATA_RESERVED higher to reserve the additional page:

#define DFU_APP_DATA_RESERVED (CODE_PAGE_SIZE * 3)

RE: DFU SDK15 CRC problem.

Mikhail — Tue, 25 Sep 2018 10:18:39 GMT

I have now in the bootloader project

#ifndef DFU_APP_DATA_RESERVED
#define DFU_APP_DATA_RESERVED (CODE_PAGE_SIZE * 3)

and located my data at the main app at 0x6EC00 right beneath FDS.

Therefore , can I count on normal storage data between DFU or no?

RE: DFU SDK15 CRC problem.

Einar Thorsrud — Tue, 25 Sep 2018 06:49:39 GMT

The data will never be preserved between DFU if they are between the start address and end address of the application .hex file. So if you want to preserve the data after DFU you cannot include it in the application like you do (with __attribute__((section(".ARM.__at_0x71400")))...) as we have discussed. This will mean that everything between the application start address and the page with the data section will be erased when you do DFU, which is expected and correct behavior.

To keep the data during DFU, make sure to not include the data in the application hex, and put it on the page right beneath FDS. Then adjust DFU_APP_DATA_RESERVED accordingly so that the bootloader does not overwrite the data during a DFU upgrade.

RE: DFU SDK15 CRC problem.

Mikhail — Mon, 24 Sep 2018 14:02:47 GMT

I lockated my data __at_0x6EC00

and seems works good.

But this location __at_0x6EC00 posiible to store data between DFU?

RE: DFU SDK15 CRC problem.

Mikhail — Mon, 24 Sep 2018 13:42:24 GMT

Good idea, I'll check it. But if I transfer this data before 0x6F000, have I unerased data after DFU update?

RE: DFU SDK15 CRC problem.

Einar Thorsrud — Mon, 24 Sep 2018 13:25:48 GMT

Ah, there we have it, then. You write that you use a debug bootloader starting at address 0x72000. Below there you have three FDS pages, which is 3*4*1024 = 0x3000, so they start at 0x6F000, which is below your fixed data starting at 0x71400, so they overlap. This means that when your application initializes FDS it writes to the flash area that is within the application region, which in turn will result in a different CRC (as it should). You simply have to move the fixed below the FDS pages to correct this.

RE: DFU SDK15 CRC problem.

Mikhail — Mon, 24 Sep 2018 09:41:23 GMT

My flash settings:

Yes, information stored into flash via fds. #define FDS_ENABLED 1, #define FDS_VIRTUAL_PAGES 3

Any idea?

RE: DFU SDK15 CRC problem.

Einar Thorsrud — Mon, 24 Sep 2018 09:04:22 GMT

The only reason I can think of that would make the CRC not correct is if your application write something to flash within that region. Can you let me know your flash memory layout? Does the application store any other information to flash? Doe sit use FDS or similar for something? If so, how many pages? There seems to be somthing that is different within the application flash region once your application runs compared to when you calculate the bootloader settings page of the application image, but I cannot say what without knowing the details of what/how/when/where you use the flash.

RE: DFU SDK15 CRC problem.

Mikhail — Mon, 24 Sep 2018 08:40:46 GMT

Thanks. And what should I do for decide this problem? I only write flash data like an application and also located data

... __attribute__((section(".ARM.__at_0x71400"))) =

There are no any else data.

Should at this case correct calculate crc? Why crc calculated not correct? Or I can't to lacate data at this memory region?

RE: DFU SDK15 CRC problem.

Einar Thorsrud — Mon, 24 Sep 2018 08:25:53 GMT

Hi,

This is relevant information. When you place information in flash this way, the application area extends over the whole flash between the start of the application and the end of the data below the bootloader, and the CRC is calculated over the whole range. Do you for instance write any other data to flash between this regions from your application? In that case you will modify the flash within the (in this case large) application region, leading to the CRC mismatch.

RE: DFU SDK15 CRC problem.

Mikhail — Fri, 21 Sep 2018 16:04:04 GMT

Hi again!

I still wait any help from you. I can say that with lockated data struct at_0x71500

crc incorrect. With this struct located at_0x26B00 all works fine.

???

Also problems in the calculate crc in the function

bool nrf_dfu_app_is_valid(bool do_crc)

I print data from bootloader:

 0> <debug> app:      s_dfu_settings.bank_0.image_crc: 0xA067C472
 0> <debug> app:      s_dfu_settings.bank_1.image_crc: 0x00000000
 0> <debug> app:      s_dfu_settings.bank_0.image_size: 0x0004B514
 0> <debug> app:      crc: 0x217DC205

Therefore, crc is different.

Why?

And this only with struct located at_0x71500.

RE: DFU SDK15 CRC problem.

Mikhail — Thu, 20 Sep 2018 15:59:39 GMT

I think, I understand my problem.

I need use non updated storaged data. And like in the SDK13 I locate some structure before bootloader. In the SDK13 this works. I use in the SDK15 bootloader with debug and it starts from 0x72000. Therefore I can locate my data 3 KB before it. I lockated my data

... __attribute__((section(".ARM.__at_0x71400"))) =

but this is doesn't work. (like discribed in this topic)

When I located this struct in the main code

... __attribute__((section(".ARM.__at_0x26A00"))) =

all works fine. I can run bootloader and starts my app correct.

How should locate my unupdatable data?

RE: DFU SDK15 CRC problem.

Mikhail — Thu, 20 Sep 2018 10:12:59 GMT

additional info:

when I prepare with my .bat file example from SDK15 (hid_keyboard), all works fine. Boot transfer management to app and I see in the air HID_Keyboard advertise. But my project works fine with only SD132 and app but doesn't work with bootloader merged.

Settings on a photo:

RE: DFU SDK15 CRC problem.

Mikhail — Thu, 20 Sep 2018 09:08:01 GMT

only change

dfu_public_key.c

to my key...

RE: DFU SDK15 CRC problem.

Mikhail — Thu, 20 Sep 2018 09:05:07 GMT

No, I haven't any modifications. Is it possible to transfer this case to private and I'll give you project and you will try it self.

RE: DFU SDK15 CRC problem.

Einar Thorsrud — Thu, 20 Sep 2018 09:03:16 GMT

Have you done any other changes to the bootloader? Or any other modifications at all that might be relevant? I ask because I am having problems understanding how this could happen with an unmodified bootloader provided that you have generated the bootloader settings correctly (as it seems from your previous post).

RE: DFU SDK15 CRC problem.

Mikhail — Thu, 20 Sep 2018 08:53:25 GMT

No, I yet do not use encryption. First part I want just run project with bootloader. And tranfer management from app to bootloader. But instaed of this I have crc error and start bootloader app.

One more time, I just try to run app with boot wo encryption.

RE: DFU SDK15 CRC problem.

Einar Thorsrud — Thu, 20 Sep 2018 08:36:09 GMT

I see. All that looks good. Have you made any modifications to the bootloader? If so, which? If you are still using encryption of the DFU image you have to make adjustments for that so that you calculate the correct CRC in the bootloader.