buttonless_dfu 15.1 not advertising for s112

[Simon]

I have SD and BL secure flashed to the device, and now trying to get the second part of buttonless_dfu + app with settings flashed next.
After flashing the second part, DfuTarg no longer advertises, or any advertising.
The app works fine on its own based on the ble_template, then combined the app with buttonless_dfu as the base, which also seems to be based on the template, and that combination compiles fine.
(I have the buttonless tutorial working start to finish, but tutorial does not have a combined example).

RTT does not seem to display any info after this flash, and now not sure of where to look for clues.
Checking section placements in SES, the standalone app has the same flash & ram settings as the template, but not the buttonless_dfu template which has slightly different values.

15.1_template_custom_app
FLASH_PH_START=0x0
FLASH_PH_SIZE=0x30000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x6000
FLASH_START=0x19000
FLASH_SIZE=0x17000
RAM_START=0x20001b48
RAM_SIZE=0x44b8

15.1_buttonless_custom_app
FLASH_PH_START=0x0
FLASH_PH_SIZE=0x30000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x6000
FLASH_START=0x19000
FLASH_SIZE=0xf000
RAM_START=0x20001c18
RAM_SIZE=0x43e8

Changed the combined buttonless_custom_app settings to template_custom_app but same results of no advertising. Maybe other section placements settings would work.

Any other way to debug and find the error for buttonless_dfu not advertising?

thank-you,

[bjorn-spockeli]

  So just to clarify, you are merging the ble_app_buttonless_dfu example with the ble_app_template example?  Are you using a nRF52 DK with a nRF52832 or is it a custom board with a nRF52810?

Could you debug your merged example and place a breakpoint at app_error_handler_bare() in app_error.c and see if you end up there? If so take a look at the call stack to see which function that caused the assert. My hunch is that its the sd_ble_enable() call in nrf_sdh_ble_enable() in srf_sdh_ble.c that is returning NRF_ERROR_NO_MEM, if that is the case then examine the variable pointed to by  p_app_ram_start, that is the application ram start address that should be used, i.e. RAM_START. 

Best regards

Bjørn 

[Simon]

I am merging the ble_app_buttonless_dfu example with the ble_app_template example (with an added TWI sensor using custom_ble_service_example as a guide), and it is a custom 810.

I followed Step 6 in the tutorial, adjusted for the custom, on how to get into debug with the BL secure already flashed, had set the breakpoint at app_error.c, and now not sure of how to advance to trigger the assert (no adv on nrf connect either).

I tried repeating the debug steps from the tutorial on the DK just to see what to expect, but it seems just the same state as with the custom in SES (expect adv as nordic_buttonless). If I could understand how to do it in the tutorial using just the DK with some ram error maybe that might help.

thank-you,

[Simon]

I can also confirm your findings, ...which I did in my previous reply using the DK.

The only difference in placements is that the base buttonless example uses flash_size=0xf000 and you are using 0xd000 (secure is the same).
Either way, no ADV on the 810 chip.
(DEVELOP_IN_NRF52832 had been removed)

Rather than using the 832 on the DK, what is the result using the examples on an actual 810 chip?
for me, ....no ADV.

thank-you,

[Jørgen Holmefjord]

Like Bjørn said, he tested this and verified that it works on a nRF52810 DK (we have some internal DKs with 810 ICs to test things like this).

[Simon]

This got me thinking to keep hammering away on the DK (the DK we can buy with the 832 chip).
The Bjorn hex files ADV on the 832 DK as well, so good there.
I took the buttonless example from new, adjusted only the clock to LF RC, tested on the DK, then flashed again to custom, and all good again.
Except this custom is a different board, basically the RGB led.
I changed the pins for the LED's, and now no ADV on the custom, back to square one.
Then I changed the pca10040 led pins for the s112 buttonless example that was working on the DK.
And now the DK is no longer ADV.
Here are the LED pins that I'm talking about:

#define LED_START 15
#define LED_1 15
#define LED_2 16
#define LED_3 12
#define LED_4 14
#define LED_STOP 14

LED pins used on the custom 810 and 832 DK to stop ADV for the buttonless example.
These pins on the datasheet seem to be General Purpose I/O.
(secure and buttonless use the same board files)

thank-you,

[Jørgen Holmefjord]

Did you change the BUTTON_x defines in pca10040.h as well, to avoid that the same pins are initialized for buttons and LEDs?

Have you tried debugging the application to see if you get any error codes, or see where the application is stuck?

[Simon]

Excellent, the button conflict resolved the ADV issue. Much thanks for this suggestion and to the others in helping to work this out.

thank-you,