DFU with NRF52 and Segger Embedded Studio

[RichieJH]

So having first used Kiel, then Eclipse, it was great to finally ditch my clunky windows laptop with its terribly laid out keyboard by making the transition to Segger Embedded Studio. Super easy to set up, looks great on my very large Mac screen and I can now use a keyboard where I don't have to keep checking where the keys are.

Well done Segger and Nordic for making this available.

Anyway, so I have been happily setting up the solutions and going through some of the tutorials like a hot knife through butter thinking this was a piece of cake, especially compared to the time it took to get my head around Eclipse, I came to a grinding halt with the tutorial for setting up the DFU on the nRF51 DK.

I navigated the first issue regarding changing the Omit Frame Pointer to yes for Bootloader_util.c, which got it compiled ok.

However, the issue I have is with the Section Placement Macros. I am using SD 132 V2.0 and am on the pca10040. I have been scraping the App placement addresses from the armgcc .ld script (anyway, these don't change for the other BLE examples so I almost have it memorised). I thought if I set the script for the flash start to be 0x07A000 (top of the memory layout where the DFU Bootloader resides) that will be putting the Bootloader where it needs to go (I am using fu_single_bank_serial_s132). And if I leave Ram at 0x20002080 then at least I have left space for the SoftDevice. Already my logic is starting to flake.

So instead of battling against something that may prove impossible I thought I would pause and ask some questions that someone might be able to help with:

1. Is it indeed possible to use SES in flash the SD and the DFU Bootloader in this manner (and ultimately with the App too) or am I barking up the wrong tree?

2. Depending on 1, of course, what should the Section Placement Macros be?

3. And, is there anything else I need to be aware of trying to use SES to do this that I have not yet uncovered (bearing in mind I want to introduce an App that will be logging significant data into the equation as well)?

Thank you everyone - RJH

[Michael Dietz]

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

[RichieJH]

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

[RichieJH]

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

[Michael Dietz]

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.

[RichieJH]

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