This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

buttonless_dfu 15.1 not advertising for s112

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,

Parents
  •   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 

  • 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,

  • Hi Simon, 

    Ok, so this is with the bootloader, SoftDevice and Application flashed to the custom nRF52810 board?

    The ble_app_buttonless_dfu example uses the Peer Manager module, which in turn uses the Flash Data Storage(FDS) module to store peer data, e.g. peer addresses, encryption keys and dentity resolving keys, in flash. 

    Hence, the FDS module needs to free flash pages, one as a swap page and one for storing the data. The FDS module will by default use the two last flash pages, but if a bootloader is present it will use the two pages below the bootloader start address. Usually this works with a hitch with the nRF52832 and nrf52840, but with the nRF52810 there is very limited flash with the S112 SoftDevice, application and bootloader, so some care must be taken. 

    So if the bootloader starts at 0x28000, then the last page used by the application must be below 0x26000 in order for FDS to properly initialize. 

  • "so this is with the bootloader, SoftDevice and Application flashed to the custom nRF52810 board?"
    -->> yes

    I can without problem get the s112 buttonless example working on the DK to advertise buttonless by flashing SD, secure, settings, backup, & app.

    I have another 810 custom with just an RGB (used to test basic apps like blinky), and tried repeating the buttonless example adjusting for the board and clock. I can get past the first flash of SD & secure to ADV DfuTarg on the custom, then the same no ADV after second flash of app, backup & settings.

    The DK has 512kB and the 810 has 192kB of flash, ...but has the buttonless example been verified on a standalone 810 (just asking)?

    (same results using sdk 15.2)
    0> <info> app: Setting vector table to bootloader: 0x00028000
    0> <info> app: Setting vector table to main app: 0x00019000
    0> <info> app: Buttonless DFU Application started.
    0> <info> app: Erase bonds!
    0> <info> peer_manager_handler: All peers deleted.

    no ADV
    (SES optimize for size, RTT and Log turned off)

    thank-you,

  • HI Simon, 

    I have verified that the ble_app_buttonless_dfu_pca10040e_s112 example for pca10040e in SDK v15.0.0 works on a nRF52810 DK that I have here. 

    These are the memory settings(Code > Linker > Section Placement Macros) for the ble_app_buttonless_dfu example

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

    These are the secure_bootloader_ble_s112_pca10040e project

    FLASH_PH_START=0x0
    FLASH_PH_SIZE=0x30000
    RAM_PH_START=0x20000000
    RAM_PH_SIZE=0x6000
    FLASH_START=0x28000
    FLASH_SIZE=0x6000
    RAM_START=0x20002390
    RAM_SIZE=0x3c70

    Also note that I have removed the DEVELOP_IN_NRF52832 from the Preprocessor Definitions in both projects (Code > Preprocessor > Preprocessor Definitions). I have also attached the hex file for the application, the bootloader and the settings that works on said nRF52810.

    ble_app_buttonless_dfu_pca10040e_s112.hex

    ble_app_buttonless_settings.hex

     secure_bootloader_ble_s112_pca10040e.hex

  • 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,

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

Reply Children
  • 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,

  • 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?

  • 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,

Related