DFU with NRF52 and Segger Embedded Studio

RE: DFU with NRF52 and Segger Embedded Studio

bjorn-spockeli — Mon, 29 Aug 2016 09:43:12 GMT

@nateperry : You can set the valid application flag in the bootloader settings by editing the following line in bootloader_settings.c form

uint8_t m_boot_settings[CODE_PAGE_SIZE] __attribute__ ((section(".bootloaderSettings")));

uint8_t m_boot_settings[CODE_PAGE_SIZE] __attribute__ ((section(".bootloaderSettings"))) = {BANK_VALID_APP};

and setting the .bootloaderSettings sectoni to load="Yes" in the flash placement xml.file. I have attached the Memory Map and Flash placment files below.

Attachments:

nRF52832_xxAA_MemoryMap.xml

flash_placement.xml

RE: DFU with NRF52 and Segger Embedded Studio

Nate — Mon, 22 Aug 2016 15:48:54 GMT

Is there somewhere the bootloader_setting_nrf52.hex file is available at? The github link above is gone.

RE: DFU with NRF52 and Segger Embedded Studio

bjorn-spockeli — Thu, 28 Apr 2016 11:59:15 GMT

The dfu_gcc_nrf52.ld linker scripts is located in \examples\dfu\bootloader

RE: DFU with NRF52 and Segger Embedded Studio

RichieJH — Thu, 21 Apr 2016 13:05:16 GMT

Hi Mike - there doesn't seem to be any .ld files in the dfu project folders I can see. I know SES creates some additional files in a project, could this be causing the boot loader "application" to swell beyond what the hex is when you open it as a solution? Just a guess. Let me know how you get on. RJH

RE: DFU with NRF52 and Segger Embedded Studio

Michael Dietz — Thu, 21 Apr 2016 12:14:14 GMT

OK, I'm trying to do this now. I thought you were just doing an application that has DFU. Usually I just use the pre-compiled bootloader in hex and don't touch it so I've never done this in Embedded Studio. I'm seeing the same problems you are. Have you looked at dfu_gcc_nrf52.ld in the dfu project folder in the SDK? It will tell you the RAM addresses you were looking for. Will keep you posted if i fix this

RE: DFU with NRF52 and Segger Embedded Studio

RichieJH — Thu, 21 Apr 2016 11:36:22 GMT

Right, in properties there is "Code Generation Options" under which there is "Optimisation Level". It has a drop down of 5 choices, 3 of these are level 1 through level 3. Unfortunately when changing the setting to each of these still yields the following: 1> /Applications/SEGGER Embedded Studio 2.16a/gcc/arm-none-eabi/bin/ld: Output/Debug/Exe/nrf52832_xxaa.elf section .bootloaderSettings' will not fit in regionUNPLACED_SECTIONS' 1> /Applications/SEGGER Embedded Studio 2.16a/gcc/arm-none-eabi/bin/ld: region `UNPLACED_SECTIONS' overflowed by 4097 bytes Good news is that a lot of the other warnings about things not fitting have gone away, but we are left with the above. Thanks once more - RJH

RE: DFU with NRF52 and Segger Embedded Studio

Michael Dietz — Thu, 21 Apr 2016 11:23:30 GMT

OK, I might know what's going on. On nRF52 the bootloader is reserved the flash at 0x7A000-0x80000. This is 24,576 bytes. In Keil, the bootloader project has optimizations configured to minimize code size and the compiled bootloader is small enough to fit in this section.

In Embedded Studio optimizations are turned off by default. You need to configure the optimization level in Project Properties. Simply setting it at -0s (smallest) or -03 (highest performance, still small) should solve this problem for you.

As for your application: You will be able to flash the SoftDevice, application and bootloader all at once. Just make sure you also flash the hex file I attached that writes the flag in the bootloader settings along with them. This can be done very efficiently in Embedded Studio by setting each of those files to be loaded with the application.

RE: DFU with NRF52 and Segger Embedded Studio

RichieJH — Thu, 21 Apr 2016 11:14:02 GMT

Just to confirm that when I close the solution down fully, open it alter the section macro addresses as above, point to the SD hex for loading I still get the message above. So it is not me having somehow expanded the bootloader through tampering - RJH

RE: DFU with NRF52 and Segger Embedded Studio

RichieJH — Thu, 21 Apr 2016 10:52:09 GMT

Hi Mike,

Thanks, very useful, and good to hear that this can largely be done through SES.

My application is somewhat ambitious using sensors that can be a little tricky, so for development and debugging purposes it is crucial I can flash straight through the IDE. Anyway, the logical workflow is to largely finish the development of the app and then introduce the boot loader at the end, I get that.

I was just trying to flash the boot loader itself for the moment (single_bank_serial_s132_) together with the SD. I have FLASH_START at 0x07A000 (end of memory region as you confirm) but I am unsure where to get the RAM_START from. Normally I scrape it from the .ld file in the armgcc folder but I notice for all of the boot loader examples the armgcc folder does not have an .ld. What is another way in which I can find out the RAM_START for the boot loader?

Currently when I try to flash I get this message (using RAM_START of 0x20002080):

1> Linking nrf52832_xxaa.elf 1> /Applications/SEGGER Embedded Studio 2.16a/gcc/arm-none-eabi/bin/ld: Output/Debug/Exe/nrf52832_xxaa.elf section .bootloaderSettings' will not fit in regionUNPLACED_SECTIONS' 1> /Applications/SEGGER Embedded Studio 2.16a/gcc/arm-none-eabi/bin/ld: error: .text is too large to fit in FLASH memory segment 1> /Applications/SEGGER Embedded Studio 2.16a/gcc/arm-none-eabi/bin/ld: error: .rodata is too large to fit in FLASH memory segment 1> /Applications/SEGGER Embedded Studio 2.16a/gcc/arm-none-eabi/bin/ld: error: .data is too large to fit in FLASH memory segment 1> /Applications/SEGGER Embedded Studio 2.16a/gcc/arm-none-eabi/bin/ld: region `UNPLACED_SECTIONS' overflowed by 4097 bytes 1> /Applications/SEGGER Embedded Studio 2.16a/gcc/arm-none-eabi/bin/ld: error: .text is too large to fit in FLASH memory segment 1> /Applications/SEGGER Embedded Studio 2.16a/gcc/arm-none-eabi/bin/ld: error: .rodata is too large to fit in FLASH memory segment 1> /Applications/SEGGER Embedded Studio 2.16a/gcc/arm-none-eabi/bin/ld: error: .data is too large to fit in FLASH memory segment

It is possible I have contaminated the size of the files with the project open in SES during my investigative probings, so I haven't completely scrapped it and started again. Before I did that I just wanted to see if there was a way to progress from here since this is good learning for going forward.

Thanks once again - RJH

RE: DFU with NRF52 and Segger Embedded Studio

Michael Dietz — Thu, 21 Apr 2016 08:23:15 GMT

Hey,

I've used SEGGER Embedded Studio with DFU apps so we'll figure this out.

First problem with the compile error in bootloader_util.c. I ran into this at well. I believe it is a GCC problem. Setting the -fomit-frame-pointer flag in the compiler settings fixes it as you have discovered.

1.) Yes this is possible. I was doing some DFU stuff and Embedded Studio was great because of how easy it was to flash the SoftDevice, Bootloader and application at once. (Remember when you flash the application along with the SD and BL instead of updating it via DFU you need to write a flag to tell the BL there is a valid application in flash already that it should run).

2.) Section placement macros should not be complicated. Should be the same as you would see in Keil project settings or the GCC linkers you've been looking at.

Now there are two scenarios:

Is your project an application with DFU capabilities or are you working on the actual bootloader?

If working on an application with DFU you shouldn't have to do anything special. Just make sure the section placement macros have FLASH_START and SRAM_START defined the same as they would for any application with a SoftDevice present. (This is [0x1C000, 0x20002080] I believe for the s132 2.0 SD but double check). These shouldn't change at all for DFU because the bootloader is located at the end of FLASH (and RAM doesn't change at all).

The tricky part: You can't just flash the SoftDevice, application and bootloader at once. The straight forward way I suggest you try first is flash the Softdevice and bootloader using nrfjprog or a similar tool. Then upload the application you compile in Embedded Studio to your board via the DFU process (using master control panel on PC or mobile app probably). This should work.

But this is a pain for developing! More info on the dev zone about this: devzone.nordicsemi.com/.../. But its not as complicated as they make it in that thread so don't read to much..

1.) Flash the softdevice, application and bootloader all at once (don't run the cpu yet though). 2.) Write the flag in memory telling the bootloader a valid application is already present in flash and that it should run that. This is one word in flash. And this can be done either with nrfjprog or you can flash a hex file that programs the one word: github.com/.../bootloader_settings_nrf52.hex

So if you use the hex file I attached then you can automate your process nicely in Embedded Studio: flash the sd.hex, app.hex, bl.hex, bootloader_setting_nrf52.hex and then reset and run the program. It should work now! And remember in Debugger->Loader Options you can have 4 files loaded every time you program the board so this is perfect!

If you are working on an actual bootloader its straightforward: Just set the FLASH_START to 0x7A000 or something like that. And I forget about RAM start but jsut double check Keil and GCC projects.

-Mike