SES import of SDK 10.0 examples ble_app_uart

[Tim]

Hello,

I need to develop two applications for nRF51822 using SES version 4.18 (macOS). One is a DFU bootloader. The other is an application based on the ble_app_uart (ble_peripheral) example of SDK 10.0. I will be using SoftDevice 110 and I understand that SDK 10.0 is that latest version compatible with S110.

I've been following this blog post to import a Keil project. Seems it is written for nRF52 development using an older version of SES (v3.10e) and is, therefore, inaccurate in some ways.

I would be grateful for some assistance in importing/building the ble_app_uart example from SDK 10.0 into SES.

The first step asks to install the CMSIS-CORE Support Package. In SES 4.18, it appears this package is already installed.

After importing the file nRF51SDK/examples/ble_peripheral/ble_app_uart/pca10028/s110/arm5_no_packs/ble_app_uart_s110_pca10028.uvprojx, I see a project configuration named nrf51422_xxac_s110. As I am developing for nRF51822, I wonder about additional project configuration changes needed? I understand that the nRF51422 is an nRF51822 with ANT support. I will be developing/testing with an nRF51 DK.

In the section Adding nRF5 MDK Files ...

I create embedded_studio folder inside nRF51SDK/components/toolchain.

I download ses_nrf51_startup.s and ses_nrf52_startup.s and save them into nRF51SDK/components/toolchain/embedded_studio/

When I download ses_nrf51_startup.s and ses_nrf52_startup.s, they download as 3324.ses_nrf51_startup.s and 5543.ses_nrf52_startup.s. I rename to ses_nrf51_startup.s and ses_nrf52_startup.s.

I remove Cortex_M_Startup.s from Internal Files in project explorer.

I notice that the remaining file in Internal Files is SEGGER_THUMB_Startup.s and I do not see thumb_crt0.s.

Next instructed to add NRF5_SDK/components/toolchain/system_nrf52.c to Internal Files. I assume that since I'm importing a project for nRF51, I should add system_nrf51.c instead, which I do. Same for NRF5_SDK/components/toolchain/embedded_studio/ses_nrf52_startup.s - I add ses_nrf51_startup.s instead.

As instructed, I add ../../../../../../components/device to the Preprocessor User Include Directories, which results in the following:

../../../../../../components/device
../../../config
../../../../../bsp
../../../../../../components/toolchain
../../../../../../components/ble/ble_advertising
../../../../../../components/ble/ble_services/ble_nus
../../../../../../components/ble/common
../../../../../../components/drivers_nrf/common
../../../../../../components/drivers_nrf/delay
../../../../../../components/drivers_nrf/gpiote
../../../../../../components/drivers_nrf/hal
../../../../../../components/drivers_nrf/pstorage
../../../../../../components/drivers_nrf/uart
../../../../../../components/drivers_nrf/config
../../../../../../components/libraries/button
../../../../../../components/libraries/fifo
../../../../../../components/libraries/timer
../../../../../../components/libraries/trace
../../../../../../components/libraries/uart
../../../../../../components/libraries/util
../../../../../../components/softdevice/common/softdevice_handler
../../../../../../components/softdevice/s110/headers

It appears that Peer Manager/Flash Data Storage applies if the application uses Peer Manager. It appears that ble_app_uart example of SDK 10.0 does not use Peer Manager, so I'm not sure if any of the instructions in Peer Manager/Flash Data Storage apply.

I see no flash_placement.xml file inside nRF51SDK/examples/ble_peripheral/ble_app_uart/pca10028/s110/arm5_no_packs. Do I still need to create this file?

I do see thumb_crt0.s inside SEGGER_app_folder/source, but not sure if the changes for fs_data should be added. I presume no.

I notice that there's no sdk_config.h file and appears this file was added to the SDK architecture after SDK 10.0?

So I do NOT do any of the steps in Peer Manager/Flash Data Storage and proceed to attempt to build the application. I got the compile error "nrf.h No such file or directory". I found that this file exists inside nRF51SDK/components/toolchain/gcc so I added that to the User Include Directories and build proceeds but then I get the compile error seen in attached compile log. I'm now lost.

Appreciate any assistance to getting ble_app_uart (ble_peripheral) of SDK 10.0 successfully imported/built for nRF51 DK (compatible with nRF51822).

I see that using S130 would mean I could use SDK 12.3 instead of 10.0. All my application needs is basic peripheral support plus access to the Timeslot API. I presume S130 would add unnecessary capabilities and size, so would prefer to stick with S110 and SDK 10.0.

Many thanks,

Tim

[Tim]

UPDATE: If I remove retarget.c from project, compile succeeds, but then get linker error. See attached log.

Thank you,

Tim

[Edvin]

Hello Tim,

I don't know if the tutorial you point to will work for SDK10. It is quite old, and the guide was written for SDK 12 and primarily for nRF51/52 with S130/132.

I am not saying it will not work, but I don't know the exact setup.

Try to use the attached thumb_crt0.s file:
thumb_crt0.s

Try to click "import section placement in SES to generate the flash_placement.xml file. 

I remember there were some issues with printf(). I found this workaround in an internal email. You can try to apply it:

Note the thumb_crt0.s has added sections for loading on boot (one “nrf_section” to load them all), and the reference to debug_putchar is removed.

If using printf + UART, add something like this to your project:

int __putchar(int ch)
{
  return app_uart_put(ch);
}

Try this, and let me know how that works.

Best regards,

Edvin

[Tim]

Hi Edvin,

It's now clear that for nRF51822 development, I should be using SDK 12.3 with SoftDevice 130. Here's what I need to achieve, all using SES 4.18 on macOS 10.14.6:

1. Build a secure bootloader for DFU over BLE

2. Build the ble_app_uart example (which I will extend and further customize)

3. Enhance ble_app_uart for buttonless dfu (by following example experimental_ble_app_buttonless_dfu)

I've read many posts on importing SDK 12.3 Keil projects into SES and it seems there are two contrasting approaches: 1) import the SDK 12.3 Keil project and configure, or 2) start with an SDK 14.1 and back port to SDK 12.3.

In this post, Hung Bui said:

"To be honest, I did try to convert a bootloader project in SDK v12 and 13 to SES but gave up by some issue that I couldn't solve. If you don't plan to modify the bootloader a lot, my suggestion is to simply use make and gcc to compile it. It could save you a lot of time.

Another option is similar to my original answer, you follow what we define and use in the bootloader project in SDK v14.1 and back port it to SDK v12."

Which approach would you recommend? I see that buttonless DFU is experimental in 12.3, production quality in 14.1. Once I choose the approach, I'll work at it and post issues for assistance.

Prior to this I learned Nordic SDK 15.3 building a boatloader and BLE app for nRF52832 (Laird's BL652) and have both working well. I didn't need to learn about flash_placement.xml and thumb_crt0.s and ses_nrf51_startup.s and ses_nrf52_startup.s. I should probably understand how these fit in. Any resources you could point me to?

Many thanks,

Tim

[Edvin]

Tim said:

I didn't need to learn about flash_placement.xml and thumb_crt0.s and ses_nrf51_startup.s and ses_nrf52_startup.s. I should probably understand how these fit in. Any resources you could point me to?

 I'm sorry. I don't really know much details about these files either. Hung's idea may be a good idea if you need to use SES. But the armgcc projects are probably easier to modify. Not that many hidden settings and weird file formats. Only the makefile and the .ld file you need to worry about.

I would try this first at least. It should be pretty straight forward to build the bootloader using armgcc, and you can check if the already flashed bootloader would accept this new bootloader via a DFU.

[Tim]

Thanks Edvin. My only experience is in building applications with SES on macOS. How do I build using armgcc? Do I need Keil on Windows?

Thank you,

Tim

[Edvin]

You need an armgcc compiler, which is a command line tool. The version you need is mentioned in:

SDK\components\toolchaing\gcc\makefile.windows for windows. For mac, perhaps it is in the makefile.posix. 

These compilers are usually found here:

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

But it is a fairly old SDK, so I can't find it in the list. For SDK12.3.0, you would need gnu version 4.9 2015q3, version 4.9.3.

Check out this one:

https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update

To compile, on windows you would open a cmd terminal in the folder where the project's makefile is located and type "make"

[Tim]

Hi Edvin,

Thanks. I've made some progress. To start, I built ble_app_uart example for pca10028 using armgcc make. (I already had armgcc installed and used it to build micro-ecc.) Then on nRF51 DK I used nrfjprog to:

nrfjprog --recover
nrfjprog -f nrf51 --program s130_nrf51_2.0.1_softdevice.hex
nrfjprog -f nrf51 --program ble_app_uart_nrf51422_xxac.hex
nrfjprog --reset

ble_app_uart runs and I can connect/disconnect using nRF Connect (iOS). So I know I have a stable environment for building with armgcc.

Next, I built bootloader_secure dfu example for pca10028. I used my public key and also needed to add to Makefile:

$(SDK_ROOT)/external/micro-ecc/micro-ecc/micro-ecc \

to INC_FOLDERS so uECC.h could be found.

Next, I built experimental_ble_app_buttonless_dfu application.

I now have:

ble_app_buttonless_dfu_nrf51422_xxac.hex
bootloader_secure_nrf51422_xxac_s130.hex

Next I make the bootloader settings file:

nrfutil settings generate --family NRF51 --application ble_app_buttonless_dfu_nrf51422_xxac.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 bl_settings.hex

Output is:

Generated Bootloader DFU settings .hex file and stored it in: bl_settings.hex

Bootloader DFU Settings:
* File: bl_settings.hex
* Family: nRF51
* Start Address: 0x0003FC00
* CRC: 0xC5344558
* Settings Version: 0x00000001 (1)
* App Version: 0x00000001 (1)
* Bootloader Version: 0x00000001 (1)
* Bank Layout: 0x00000000
* Current Bank: 0x00000000
* Application Size: 0x0000ADD4 (44500 bytes)
* Application CRC: 0x3A1674DE
* Bank0 Bank Code: 0x00000001
* Softdevice Size: 0x00000000 (0 bytes)
* Boot Validation CRC: 0x00000000
* SD Boot Validation Type: 0x00000000 (0)
* App Boot Validation Type: 0x00000000 (0)

Next I attempt to merge the bootloader settings file with the bootloader and SoftDevice:

mergehex --merge bl_settings.hex bootloader_secure_nrf51422_xxac_s130.hex s130_nrf51_2.0.1_softdevice.hex --output bl_settings_s130.hex

Get output/error:

Parsing input hex files.
Merging files.
ERROR: The hex files cannot be merged since there are conflicts.

I found that merging bootloader settings file with application (ble_app_buttonless_dfu_nrf51422_xxac.hex) and SoftDevice (s130_nrf51_2.0.1_softdevice.hex) works. So the conflict is between settings file and bootloader (bootloader_secure_nrf51422_xxac_s130.hex).

I've attached the hex files.

Separately, I tried programming nRF51 DK with SoftDevice and bootloader and, after reset, the bootloader runs, I can connect with nRF Connect and see the DFU service, characteristics, etc. I've not tried creating a DFU image and initiating DFU with nRF Connect. I presume the bootloader settings file is necessary for this to work.

This was all with SDK 12.3.

Thanks for ongoing help. Much appreciated.

Tim

bl_settings.hex

bootloader_secure_nrf51422_xxac_s130.hex

ble_app_buttonless_dfu_nrf51422_xxac.hex

[Edvin]

Hello Tim,

Try to use the option --no-backup when you generate the bootloader settings hex file. The older SDK's bootloaders didn't use this, so there is not set aside space for it.

Let me know if it doesn't work.

Best regards,

Edvin

[Jimmy Wong]

HI,

You can refer to example (https://github.com/jimmywong2003/SES-Project-For-NRF51). It is using the SDK 12.3 / S130v2.0.1 on SES.

[Tim]

Thanks Edvin. --no-backup fixed the mergehex issue. When I merge bootloader_s130+buttonless_app and program nRF51 DK and reset, LED 3 (of 4) blinks (500 ms on, 500 ms off) and it appears the bootloader does not run the app (no advertising of "Nordic_Buttonless"). Then I built ble_app_uart example and used it instead of experimental_ble_app_buttonless_dfu and it worked. The bootloader starts the app, it advertises, I can connect/disconnect with iOS nRF Connect.

Next I'll try extending ble_app_uart for buttonless dfu using experimental_ble_app_buttonless_dfu as a guide and also this Nordic Infocenter content. Any other useful resources?

Thanks to Jimmy Wong, I have ble_app_uart working in SES so I can debug.

Many thanks,

Tim

[Tim]

Thanks Jimmy. Very helpful.

Tim

[Edvin]

Hello,

 

Tim said:

--no-backup fixed the mergehex issue.

 Good.

 

Tim said:

LED 3 (of 4)

 Hehe, I struggle at quite a bit with this, since the DK marks them 1-4, some parts of the SDK uses 1-4, but others use 0-3 :) But I understand what you mean.

Actually, I saw this yesterday, when I did some testing. I assumed I had introduced some errors in the buttonless examples at an earlier point in time, so I tested the ble_app_uart example instead of the ble_app_buttonless. The reqson for my suspicion was that I tested the pca10040_debug bootloader (I don't have an nRF51 DK in the home office). The log said that the application was valid, and that the bootloader started the app, but then the log comes from the bootloader again, suggesting that the application has failed, and triggered a reset.

Can you try with another application? e.g. the ble_app_uart example? There is something fishy with this bootloader since it prints "app is valid" several times before "starting application" (this is only printed in the RTT log if you use the pca100[40/28]_debug bootloader project).

Can you try to use the ble_app_uart application instead of the buttonless example, just to check whether this works on the 51DK (since I can't do that).

BR,

E