nRF5_SDK_17.0.2_d674dde\examples\dfu\secure_bootloader\pca10056_s140_ble_debug\ses won't advertise DfuTarg name

[gfmoore]

So I now have nRF 52840 dk and I'm working through the secure bootloader example. I am using SES. (Windows).

So I built and flashed the the app and it looks fine, it has Leds 1 and 2 lit and the software layout looks fine (in nRF Connect)

In trying to use the Connect J-Link, I see the output (in part)

<debug> nrf_dfu_ble: Enabling the BLE stack.
<debug> nrf_dfu_ble: No advertising name found
<debug> nrf_dfu_ble: Using default advertising name
<debug> nrf_dfu_ble: Advertising...

As far as I know the advertising name is defined in the sdk_config.h?

// <s> NRF_DFU_BLE_ADV_NAME - Default advertising name.
#ifndef NRF_DFU_BLE_ADV_NAME
#define NRF_DFU_BLE_ADV_NAME "DfuTarg"
#endif

I've tried following the code and stepping into, but it's a rabbit warren and I got lost.

Can you help please.

Gordon

[gfmoore]

Okay then.

So what could I be doing wrong, or what should I be doing to see DfuTarg on my phone. It worked fine when I followed through on the ble_blinky example. Saw the advertisment fine.

I have rebooted my phone, turned off bluetooth, left it a few minutes, turned it on again. (To clear any cache?)

I don't understand why, if I'm using the pure code I can't see DfuTarg? Is it something to do with the public key?

[Einar Thorsrud]

gfmoore said:

I have rebooted my phone, turned off bluetooth, left it a few minutes, turned it on again. (To clear any cache?)

It is a problem that phones cache device names etc, but I would expect it should have been cleared by turning it off and on again like you did. Do you by any chance have an addition DK or dongle so that you can test with nRF Connect for Desktop and the Bluetooth app? With that there is no caching issue, and you get full control.

gfmoore said:

I don't understand why, if I'm using the pure code I can't see DfuTarg? Is it something to do with the public key?

It is not used at this point in the bootloader so I do not see how an issue with the signature could make it fail. Does it help to revert back to the example signature (it obviously will not work with firmware you sign, but it would be interesting to double check if that is related to the issue you see here or not just to rule it out.)

[gfmoore]

I started absolutely fresh. Redownloaded sdk, redownloaded and installed Segger Embedded Studio

I made the change to Makefile.windows to look at the arm gcc toolchain.

Went through all the steps in: https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader

No joy.

Okay so I reverted back to the original dfu_public_key.c (which is in the examples/dfu folder - I assume Segger Studio knows this as there is a statement in the (old) script that says: and include it into your project? This document is using Keil rather than SES?

B2. Copy the public_key.c file generated at step A2 to your bootloader folder, or a folder of your choice and include it into your project. Remove the dummy dfu_public_key.c in the project because it's replaced by public_key.c

How do you quote?

I just copied the content of my public key intot he dfu_public_key.c - I assume SES knows where to look for this or do I have to tell it?

No difference.

The only other potential issue is with Step b1a with the uECC library.

 

In my case I chose SDKFolder\external\micro-ecc\nrf52_keil\armgcc and type make to start building uECC.

The instructions don't quite match the new sdk structure, so I ran make in this folder:

C:\nRF5_SDK_17.0.2_d674ddev\external\micro-ecc\nrf52hf_armgcc\armgcc

It seemed to work. Will SES see that? There is no explicit ses folder???

I assume so as it all builds and flashes, but no DfuTarg.

Perhaps the app isn't actually advertising even though the two leds are on?

Then the step D1. Flash bootloader and softdevice. Use nRFGo Studio or nrfjprog or the IDE to flash the softdevice first, then the bootlaoder. 

I assume? that SES is doing these steps together when I do Target>Download secure_bootloader ...

(I do have a VS Code toolchain setup, but I was getting exactly the same issue, which I why I moved to SES to test).

This is driving me nuts. If it has worked for you - following these steps, I'm at a loss. 

I don't have any other dk. 

[gfmoore]

Oh sorry I do have a nRF52840 usb dongle, but I have no idea of what I would have to do?

[gfmoore]

I note that the debug statements  does say "advertising..."  but the place where it writes this is in that nrf_dfu_ble.c file??

[gfmoore]

So I turned off the dk board. Rescanned the bluetooth devices (and there are many near me!!! :sigh) Turned on the dk board and saw nothing new? In that case can we assume that the device isn't advertising at all? 

I'll go and try ble_app_blinky again.