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

[Einar Thorsrud]

Hi,

gfmoore said:

How rude.

That was not my intention.

gfmoore said:

Did you read the first post?

Yes. But it does not describe a problem with the example (which does indeed advertise with DfuTarg as the name). So I lack information about any changes you have done or how you see this issue.

gfmoore said:

The rest of the thread is to show what I have attempted to solve the problem whilst awaiting some reponse from Nordic!

You should normally get an answer by the next business day, but there is no 24/7 support here.

gfmoore said:

It says: No advertising name found

Yes, and that is not an error. It just explains that no advertising name has been set by the application via the method I described in my initial reply (which is a workaround for iPhone).

Did you actually check if there is any error anywhere? The log does not show anything out of the ordinary. Have you checked if the devices advertises with DfuTarg? (which the unmodified bootloader example does). How did you check this?

gfmoore said:

btw why did you mention ios, I'm not using an iPhone?

Because that is the reason for the code you were asking about in nrf_dfu_ble.c. In any case that is not used by the bootloader, but by the buttonless DFU service in the application (to configure the name of the bootloader). The fact that this has not been used to set the name is the reason you get the "No advertising name found" in the log. This is perfectly find and expected. No indication of any issue.

[gfmoore]

Hold on. Something doesn't compute here.

I've just explained in great detail what I am doing with pure  Nordic code that I have not changed.

I am just working through the example on how to develop a secure bootloader. I haven't got to buttonless yet.

If you do what I just explained in detail on your system, do you get a BLE advertisement of DfuTarg appearing on your phone under nRFConnect?

Is that not what I expect to see?

Step D1 https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader

(The reason for mentioning the nrf_dfu_ble.c file is because that is where my attempts to figure this rats nest led me, if it's got nothing to do with the code fine, my bad.)

[Einar Thorsrud]

Hi,

gfmoore said:

I've just explained in great detail what I am doing with pure  Nordic code that I have not changed.

I see, good. Then there must be an issue with how you test as the example does work out of the box and does indeed advertise as DfuTarg. 

gfmoore said:

I am just working through the example on how to develop a secure bootloader. I haven't got to buttonless yet.

I understand that. I was just explaining why the code you were looking at is irrelevant at this point.

gfmoore said:

If you do what I just explained in detail on your system, do you get a BLE advertisement of DfuTarg appearing on your phone under nRFConnect?

Yes, I see DfuTarg on my phone.

[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.)