DFU separate files. inside

RE: DFU separate files. inside

Mikhail — Wed, 17 Jan 2018 12:51:08 GMT

Thanks for help a lot!

RE: DFU separate files. inside

Hung Bui — Wed, 17 Jan 2018 12:49:24 GMT

Hi Mikhail,

You are right, it was 0x73000 for _debug version and 0x78000 for normal version. Sorry that I didn't asked which version you used.

RE: DFU separate files. inside

Mikhail — Wed, 17 Jan 2018 12:21:28 GMT

No, I said that bootloader in the SDK13 already has 0x7300 proof and we located our data incorrect into 0x77800. But with located 0x72400- all works correct. I suppose, 0x7800 -just mistake in the documentation- from previous SDK.

RE: DFU separate files. inside

Hung Bui — Wed, 17 Jan 2018 12:16:43 GMT

You are saying you changed the bootloader start address to 0x73000 ? And after you moved your data to 0x72400 it worked fine?

RE: DFU separate files. inside

Mikhail — Wed, 17 Jan 2018 08:24:29 GMT

Hi! I decided problem- should locate my data from 0x72400 because bootloader starts not from 0x7800 and from 0x73000 !!! I don't know exactly why we try to write data like bootloader starts 0x77000???

RE: DFU separate files. inside

Hung Bui — Fri, 22 Dec 2017 15:57:17 GMT

Looks like it's resetting all the time. You may want to follow this guide to debug your application.

RE: DFU separate files. inside

Mikhail — Fri, 22 Dec 2017 15:33:43 GMT

Hi!

if struct located in the first start address (0x1F800)- all works correct. Also merged bootloader is job. I can make DFU and new image (.zip) works good. But we now talk that I just flash this merged file via j-link. And in the case of struct located by 0x77000 addr- always reboot.
Yes. I use RTT debug and right after main() and LOG init

NRF_LOG_INFO("nInside main\r\n");

And after flash I see this string again and again proof

third question- I don't know how to catch it.

RE: DFU separate files. inside

Hung Bui — Fri, 22 Dec 2017 15:11:19 GMT

Hi Mikhail,

You need to find a way to debug. There are something you need to check:

If the bootloader does it job, copy the image correctly ?
If the bootloader manage to start the application ( the PC move to application , and run into main() )
If the application started, what causes it to reset ?

RE: DFU separate files. inside

Mikhail — Fri, 22 Dec 2017 07:49:54 GMT

HI!

with struct 0x77000 same result- always restart system. As you remember, only with bootloader merged.

RE: DFU separate files. inside

Hung Bui — Thu, 21 Dec 2017 16:59:26 GMT

Could you try 0x77000 ? 0x77800 is not page aligned (4KB) you could have overwriten the bootloader.

RE: DFU separate files. inside

Mikhail — Thu, 21 Dec 2017 16:23:31 GMT

I see when merge app with bootloader that app always restarting again and again. It happen with struct located to 0x77800 If it located to 0x37800- all ok.

RE: DFU separate files. inside

Mikhail — Thu, 21 Dec 2017 16:02:32 GMT

ok, now works. I made changes in the sdk_config.h. I transfer this file settings from work project where it works. Now I build bootloader again and will givw you more info

RE: DFU separate files. inside

Mikhail — Thu, 21 Dec 2017 15:35:54 GMT

my settings does any incorrect? LOG_ENABLED, files.c are included... ?

RE: DFU separate files. inside

Hung Bui — Thu, 21 Dec 2017 15:27:05 GMT

You need to enable LOG in sdk_config.h file, if you use Keil you can open the file in Configuration Wizard tab. NRF_LOG_ENABLED need to be enabled, and the Back end serial use RTT should be selected. nrf_log library files should be included.

RE: DFU separate files. inside

Mikhail — Thu, 21 Dec 2017 14:43:38 GMT

I have some problems with RTT debug. Let's do it first. I able to run ...\examples\dfu\bootloader_secure_ble\pca10040_debug\ and receive dubug info. All correct. But In my project, based on an one of examples, there is no same debug info. I can't receive it. As I see, I included RTT .c files, I added

uint32_t err_code = NRF_LOG_INIT(NULL);

right after main()

I added RTT enable in a sdk_config.h

Whats reason that no debug info?

RE: DFU separate files. inside

Hung Bui — Thu, 21 Dec 2017 14:09:36 GMT

Can you debug with your app, either by running in debug mode or printing log, checking if it's getting to main and what kind of error it face ? We can't debug with blackbox style like this.

RE: DFU separate files. inside

Mikhail — Thu, 21 Dec 2017 08:21:29 GMT

Hi!

I located 2.hex by address 0x77800. Nrf52 qfaab0- mean 512k?. Bootloader starts from 0x78000. But after generated packed with bootloader and app. After flash SD and this generated packed - doesn't work my app. Possible, my struct in 2.hex can't read. What is my wrong?

RE: DFU separate files. inside

Hung Bui — Wed, 20 Dec 2017 16:46:41 GMT

Ok, so please follow the guide to preserve application data. Make sure that the location of the 2.hex in flash match with the area preserved (X number of pages right under the bootloader) . If you use 512kB flash variant, you may need to move the 2.hex to address 0x77000 for example.

RE: DFU separate files. inside

Mikhail — Wed, 20 Dec 2017 16:33:05 GMT

sorry for one string text. Can't edit it

RE: DFU separate files. inside

Mikhail — Wed, 20 Dec 2017 16:31:21 GMT

My app depends from this struct in 2nd hex. If 2nd hex erased- my app will doesn't work. It is normal. For generate output boot hex, I use nrfutil.exe.

nrfutil pkg generate --hw-version 52 --application-version 1 --application 1.hex --sd-req 0x98 --key-file private.key app_dfu_package.zip

nrfutil settings generate --family NRF52 --application 1.hex --application-version 0 --bootloader-version 0 --bl-settings-version 1 bootloader_setting.hex

RE: DFU separate files. inside

Hung Bui — Wed, 20 Dec 2017 15:44:06 GMT

Hi Mikhail,

What did you use to generate the .zip file and the bootloader setting file ? using 1.hex ?

One thing you can do to quickly check is to dump the flash out and compare before and after doing DFU. Then compare them. Pay attention to the original application area, and the bootloader setting area. I suspect either the flash area 2 is erased (don't know if it's the reason your app stop working, it's depend on your application), or the CRC checking inside bootloader setting no longer match with the content in the area of 1.hex

RE: DFU separate files. inside

Mikhail — Wed, 20 Dec 2017 13:38:59 GMT

in my bootloader (bootloader_secure_ble) we use single or dual bank updates?

RE: DFU separate files. inside

Mikhail — Wed, 20 Dec 2017 13:26:44 GMT

may be best way will use spetial zone for settings like discribed here: infocenter.nordicsemi.com/.../lib_bootloader_dfu_banks.html

RE: DFU separate files. inside

Mikhail — Wed, 20 Dec 2017 13:25:10 GMT

Hi again!

I'll try to explan again in more details: in the my app I have structure located by separate sddress-

struct_t abc __attribute__((section(".ARM.__at_0x37800"))) =

After compiling I have .hex. This .hex I manual divide for two .hex.

1- 0x1F000 - 0x377FF ...

:1077F0000000000000000000000000000000000089
:00000001FF

...

2 0x 37800- 0x37940

...

:0C7940002FC490D003146137022303FF12
:040000050001F20103
:00000001FF

...

Via nrf go studio I can flash SD than 1 and 2 .hex. Works fine.

I can run merge with nrfutil.exe. And get merged bootloader_setting.hex nrf52832_xxaa_s132.hex 1.hex --output boot_55.hex

before I get .zip for DFU.

Ok. Via nrf go studio erase all, flash SD, flash boot_55.hex, flash my hex 2 with struct. Works fine.

go next. Transfer by UART command into bootload mode- ok. DFU upgrade-ok. my same flashed app- does not work any more. ???

RE: DFU separate files. inside

Hung Bui — Wed, 20 Dec 2017 12:56:42 GMT

Hi Mikhail,

What exactly you mean nRF doesn't work more ? Have you tried to debug if it can get to main() in the application ? Would it be the result of your application data being erased ?

Where do you locate the your application data ? If you want to preserve your data you need to follow this guide.

Note that the bootloader assume the application data starts right before the beginning of the bootloader.

Make sure you also count the room for fds data if you use that module (by default used by peer manager)