Problem with custom DFU Buttonless app (bootloader + settings + app .hex with bond_forwarding doesn't run)

[Bruno Santamaria]

Hello,

I'm developing an app for NRF52832 SDK 15.3, SD 132 6.1.1 with NUS service and Peer Manager with LESC JustWorks security and other FDS records. My app information is more extensively described here.

I want to use the DFU bootloader with the Buttonless Service and Characteristic. This is what I have tried so far, following this guide:

1. Tested DFU Bootloader and Buttonless app with DK and nRF Connect for Android
2. Customized Bootloader with own keys and for custom board. Advertistiment OK and custom LEDs.
3. Generated signed .zip for my custom app and uploaded through DFU and nRF Connect for Android. Successfull.
4. Merged DFU Buttonless example into my custom app for adding DFU Service
   1. Added adv_uuid for DFU service
   2. Added all functions from example and initialization
   3. Increased NRF_SDH_BLE_VS_UUID_COUNT to 2
   4. Updated RAM start according to debug information
5. Uploaded my app through DFU and nRF Connect Android and app runs

   1. 00> <info> app: Setting vector table to bootloader: 0x00078000
      00> 
      00> <info> app: Setting vector table to main app: 0x00026000
      00> 
      00> <debug> app: FDS started.
      00> 
      00> <debug> app: Initializing fds...
      00> 
      00> <debug> app: Event: FDS_EVT_INIT received (FDS_SUCCESS)
      00> 
      00> <info> app: FDS Found 0 valid records.
      00> 
      00> <info> app: FDS Found 0 dirty records and 0 freeable words.
      00> 
      00> <info> app: FDS Writing config file...
      00> 
      00> <info> app: FDS Event data not found.
      
      CONNECT from ANDROID nRF Connect
      
      00> 
      00> <debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
      00> 
      00> <debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
      00> 
      00> <info> app: Connected
      00> 
      00> <debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
      00> 
      00> <info> app: Data len is set to 0xF4(244)
      00> 
      00> <debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7
      00> 
      00> <debug> nrf_ble_gatt: Data length updated to 123 on connection 0x0.
      00> 
      00> <debug> nrf_ble_gatt: max_rx_octets: 123
      00> 
      00> <debug> nrf_ble_gatt: max_tx_octets: 123
      00> 
      00> <debug> nrf_ble_gatt: max_rx_time: 1096
      00> 
      00> <debug> nrf_ble_gatt: max_tx_time: 1096
      00> 
      00> <debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7
      00> <debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7
      00> 
      00> <debug> nrf_ble_lesc: BLE_GAP_EVT_LESC_DHKEY_REQUEST
      00> 
      00> <info> app: BLE_GAP_EVT_LESC_DHKEY_REQUEST
      00> 
      00> <info> nrf_ble_lesc: Calling sd_ble_gap_lesc_dhkey_reply on conn_handle: 0
      00> 
      00> <info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Bonding
      00> 
      00> <info> app: BLE_GAP_EVT_AUTH_STATUS: status=0x0 bond=0x1 lv4: 0 kdist_own:0x3 kdist_peer:0x2
      00> 
      00> <debug> app: Event: FDS_EVT_WRITE received (FDS_SUCCESS)
      00> 
      00> <debug> app: Record ID:  0x0002
      00> 
      00> <debug> app: File ID:  0xC000
      00> 
      00> <debug> app: Record key:  0xC007
      00> 
      00> <debug> app: Event: FDS_EVT_WRITE received (FDS_SUCCESS)
      00> 
      00> <debug> app: Record ID:  0x0003
      00> 
      00> <debug> app: File ID:  0xC000
      00> 
      00> <debug> app: Record key:  0xC006
      00> 
      00> <debug> app: Event: FDS_EVT_WRITE received (FDS_SUCCESS)
      00> 
      00> <debug> app: Record ID:  0x0004
      00> 
      00> <debug> app: File ID:  0xC000
      00> 
      00> <debug> app: Record key:  0xC008
      00> 
      00> <debug> app: Event: FDS_EVT_WRITE received (FDS_SUCCESS)
      00> 
      00> <debug> app: Record ID:  0x0005
      00> 
      00> <debug> app: File ID:  0xC000
      00> 
      00> <debug> app: Record key:  0xC009
      00> 
      00> <debug> app: Received data from BLE NUS. Writing data on UART.

   2. Issue #1: App seems to work but seems not to be stable. Sometimes NUS service doesn't seem to work (RTT doesn't show messages and I get no reply), other times it does, not all Debug data appears on RTT, on some ISR of my buttons, app seems to freeze. None of these happened before adding DFU. Anything I have to take care of? E.g. Flash zones for peer_manager and for custom data have to be moved? ISRs are now too long?
6. If I try from nRF Connect to upload the same app again, it says:
   1. Initializing, Connecting, Starting Bootloader, and even Uploading...
   2. LEDs on board indicate that Bootloader has started and connected to nRF Connect...
   3. But after a while disconnects and App Starts again. I assume it is because my app is bonded and has security, so I try next point in the guide.

   4. 00> <info> app: Device is preparing to enter bootloader mode.
      00> 
      00> <debug> app: Disconnected connection handle 0
      00> 
      00> <info> app: Disconnected 1 links.
      00> 
      00> <debug> app: In ble_dfu_buttonless_bootloader_start_finalize
      00> 
      00> 
      00> 
      00> <info> app: Device will enter bootloader mode.
      00> 
      00> <info> app: Power management wants to reset to DFU mode.
      00> 
      00> <info> app: Power management allowed to reset to DFU mode.
      00> 
      00> <info> app: Setting vector table to bootloader: 0x00078000
      00> 
      00> <info> app: Setting vector table to main app: 0x00026000
      00> 

7. I follow the guide steps Bond forwarding with buttonless DFU changing the sdk_config.h of bootloader and app
   1. flash the softdevice
   2. generate settings 

      Bootloader DFU Settings:
      * File:                     setting.hex
      * Family:                   nRF52
      * Start Address:            0x0007F000
      * CRC:                      0xDF50196E
      * Settings Version:         0x00000001 (1)
      * App Version:              0x00000001 (1)
      * Bootloader Version:       0x00000001 (1)
      * Bank Layout:              0x00000000
      * Current Bank:             0x00000000
      * Application Size:         0x00022CF8 (142584 bytes)
      * Application CRC:          0x27DC8B99
      * 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)

   3. flash the bl + settings + app with nrfjprog 

      nrfjprog --family nRF52 --program APP_BL_ST.hex
      Parsing hex file.
      Reading flash area to program to guarantee it is erased.
      Checking that the area to write is not protected.
      Programing device.

   4. Issue #2: But no LEDs are blinking, the app doesn't start nor the bootloader, I see nothing on RTT viewer. No device is advertising.
   5. Also tried to flash every hex with nRF Connect Desktop (SD + BL + Settings + App). I get the same error that when I flash SD + DFU (see attached log) but this time doesn't work neither 2020-05-04T12_38_04.395Z-log.txt

What can I do for fixing these issues?

What could be the problem for Issue 2, something in the bootloader with the sdk_config changes, or in the app? Or with the merged files?

Thanks in advance and regards,

Bruno Santamaria

[Vidar Berg]

Hi Bruno,

I recommend going with the unbonded variant without bond sharing if you don't have a requirement to have a secured link during the DFU transfer. It less complicated and there's is less things that can go wrong with it. This does not have any impact on bonding support in the main app.

App seems to work but seems not to be stable. Sometimes NUS service doesn't seem to work (RTT doesn't show messages and I get no reply), other times it does, not all Debug data appears on RTT, on some ISR of my buttons, app seems to freeze. None of these happened before adding DFU

 This is a known limitation when working with the bootloader. RTT keeps log messages in a RAM buffer which the debugger locates by scanning the RAM area on connection. Problem is that this buffer is not linked to a fixed RAM address and will as a result get moved when transitioning between bootloader and app code. The easiest solution to this is to disable RTT logging in the bootloader when you want to logs from the APP. The other solution is to link the RTT block to a fixed RAM section shared by bootloader and app.

Best regards,

Vidar

[Bruno Santamaria]

Hi Vidar Berg, thanks. I think I understand what you mean. Just to be clear, does this RAM address get moved when changing from Bootloader to Application even though my Bootloader is not writing debug messages nor even using nRF_Log? (I didn't use the "_debug" example).

If this is so, what do you mean by "disable RTT logging in the bootloader"? Do you mean that I should connect with Segger RTT to my device only when I'm sure the application is running and closing it before it changes to bootloader?

Especially if the answer to the previous cuestion is that is not enough to use RTT just taking care that only the application is running, how can I link the RTT block to a fixed RAM position? I haven't found any documentation but this post from a regular user.

Regards,

Bruno

[Vidar Berg]

Hi Bruno,

Bruno Santamaria said:

If this is so, what do you mean by "disable RTT logging in the bootloader"? Do you mean that I should connect with Segger RTT to my device only when I'm sure the application is running and closing it before it changes to bootloader?

 I assumed you were using the bootloader with logging. I didn't know it could become a problem without. Does it fail consistently and do you see any pattern? E.g., does not work after power-cycle, etc.

The best solution is to allocate a fixed portion of RAM to rtt as explained in the forum thread you linked to. But it requires some work, and the approach will differ depending on toolchain type.

Regards,

Vidar

[Bruno Santamaria]

Hi Vidar Berg,

Vidar Berg said:

The best solution is to allocate a fixed portion of RAM to rtt as explained in the forum thread you linked to. But it requires some work, and the approach will differ depending on toolchain type.

For now I'm trying to avoid doing this, especially since my bootloader is not logging.

Vidar Berg said:

Does it fail consistently and do you see any pattern? E.g., does not work after power-cycle, etc.

What I've tried is to divide my last commits into two branches, one for DFU and one for encryption/pairing/fds. This way I can tell apart what is not working.

What I see is that from my three buttons - all of which work fluently using only SD + App, now only two still work. When using SD + DFU + APP or SD + DFU + DFU_Buttonless_App, when I press my button my app resets. It seems like the bootloader is using that same pin for reset, but I haven't found any information on that regard.

That button is on PIN 21 as defined in my custom_board.h file.

For now the rest of my app seems to work as before. How can I solve the problem with that button?

Thanks in advance.

[Vidar Berg]

Hi,

The reset pin (P0.21) is enabled by default in all of our SDK examples by including the CONFIG_GPIO_AS_PINRESET flag in the preprocessor definitions.  So it must be removed if you are using P0.21 as a regular GPIO.

Note that the pin reset setting is stored in the non-volatile UICR section, so you will need to perform an ERASEALL or UICRERASE to clear this setting. 

[Bruno Santamaria]

Hi, that was it!

Of course, the reset pin! I removed the CONFIG_GPIO_AS_PINRESET months ago at the beggining of the development. What I didn't expect is that, if the bootloader has that flag, the pin is still used for reset in the app.

Now I applied the same configuration of my app to the bootloader and my button on P0.21 works again.

Thanks Vidar Berg!