DFU not working

[dmleone]

SDK 15.2 API 6.10 SES custom board

I am trying to get DFU to work and it is not seeming to work right. 

I am trying to engage DFU mode by holding in button on board for 10-20 seconds. after releasing during allotted time i call enter_dfu_mode()

static void dfu_flash_cb(void *p_buf)
{ 
    uint32_t result = *((uint32_t*)p_buf);
    if(result == NRF_SUCCESS)
    {
        NRF_LOG_DEBUG("resetting into DFU...\n");

        //blink the led 4x
        tb_led_blink(TLBX_LED_LOGO, 4, 500);
        
        NVIC_SystemReset();
    }
    else
    {
        NRF_LOG_DEBUG("error 0x%x writing DFU settings\n");
    }
}

static void enter_dfu_mode(void)
{
    NRF_LOG_DEBUG("writing dfu settings\n");
    
//    uint32_t err_code = sd_power_gpregret_clr(GPREGRET, BOOTLOADER_DFU_START);
//    APP_ERROR_CHECK(err_code);

    //write the bootloader settings and reset
    s_dfu_settings.enter_buttonless_dfu = true;
    (void)nrf_dfu_settings_write(dfu_flash_cb);
}

I am using the dfu secure_bootloader no changes to it

I added the buttonless dfu service, not sure if necessary considering my way of wanting to enter DFU mode, from the buttonless_dfu example.

When i call the function it does nothing. When i try and write to the settings nrf_dfu_settings_write returns the following

<error> nrf_fstorage: p_fs->p_api check failed in nrf_fstorage_erase() with value 0x8.
<warning> nrf_dfu_flash: nrf_fstorage_erase() failed with error 0x8.
<error> nrf_dfu_settings: Could not erase the settings page!

Is there something i am missing with how i want to do this or is there a method to enter DFU mode with a button press i have not seen in examples yet.

Also. Once in DFU mode. How do you reset the device either after OTA is complete or after 20sec of no transfer?

[dmleone]

I got it to enter DFU mode. I modify the function to this

static void enter_dfu_mode(void)
{
    uint32_t err_code;

    // Dsiconnect all BLE connections
    disconnect_all();                       //static function
    
    // Set DFU mode bit
    //NRF_POWER->GPREGRET = 0xB1;             // Non softdevice way
    err_code = sd_power_gpregret_set(GPREGRET_ID1, 0xB1);
    APP_ERROR_CHECK(err_code);

    //Disable SoftDevice. It is required to be able to write to GPREGRET2 register (SoftDevice API blocks it).
    //GPREGRET2 register holds the information about skipping CRC check on next boot. 
    err_code = nrf_sdh_disable_request();
    APP_ERROR_CHECK(err_code);

    NRF_LOG_DEBUG("resetting into DFU...\n");

    NVIC_SystemReset();
}

Even though i enter DFU mode and connect. When i try and upload the compiled DFU .zip file created following this help site, https://devzone.nordicsemi.com/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader, It disconnects immediately. What would cause it to disconnect immediately? Here is my batch file which makes the DFU .zip file

set APP_FILE=app
set APP_FILE_LOC=Output\Release\Exe
set SOFTDEVICE_LOC=sdk_nRF1520\components\softdevice\s132\hex
set SOFTDEVICE=s132_nrf52_6.1.0_softdevice.hex
set BOOTLOADER_LOC=secure_bootloader\pca10040_ble\ses\Output\Release\Exe
set BOOTLOADER=secure_bootloader_ble_s132_pca10040.hex
set OUTPUT_FILE_LOC=Output\Release
@echo Preparing: nordic dfu settings file...
nrfutil settings generate --family NRF52 --application %APP_FILE_LOC%\%APP_FILE%.hex --application-version 1 --bootloader-version 2 --bl-settings-version 1 %APP_FILE_LOC%\%APP_FILE%_bl_settings.hex
mergehex --merge %APP_FILE_LOC%\%APP_FILE%.hex %APP_FILE_LOC%\%APP_FILE%_bl_settings.hex --output  %APP_FILE_LOC%\%APP_FILE%_app+bl_settings.hex
@echo Preparing: nordic DFU zip
nrfutil pkg generate --hw-version 52 --sd-req 0xAE --application-version 1 --application %APP_FILE_LOC%\%APP_FILE%.hex --key-file %APP_FILE_LOC%\..\..\..\keys\app_private_key.pem %OUTPUT_FILE_LOC%\%APP_FILE%_app_dfu_pkg.zip
@echo merging softdevice, secure bootloader, bootloader settings and application...
mergehex --merge %SOFTDEVICE_LOC%\%SOFTDEVICE% %BOOTLOADER_LOC%\%BOOTLOADER% %APP_FILE_LOC%\%APP_FILE%_app+bl_settings.hex --output  %OUTPUT_FILE_LOC%\%APP_FILE%_sd_app_bl.hex

[bjorn-spockeli]

dmleone:You are using the incorrect  --sd-req, you are setting it to 0xAE(S140 v6.1.0), but you should use 0xAF(s132_nrf52_6.1.0)

[dmleone]

I saw that and corrected it still did not work.

[bjorn-spockeli]

Ok, then please flash the debug bootloader ( nRF5_SDK_15.2.0_9412b96\examples\dfu\secure_bootloader\pca10040_ble_debug) and then post the debug log from when you perform a DFU. 

[dmleone]

I cannot figure ou thow to view the NRF_LOG_DEBUG output. I can view the NRF_LOG_INFO outputs, but how can i view the debug output. I am using SEGGER RTT Viewer to see th einfo an dtried starting debug logger but nothing is being recorded apart from NRF_LOG_INFO

[bjorn-spockeli]

Can you verify that the the NRF_LOG_DEFAULT_LEVEL in sdk_config.h is set to 4 (i.e. Debug).

[dmleone]

I did have it set to log level 3. After setting it to log level 4 i can now see debug info in the RTT Viewer. However, after i start the DFU i cant seem to use RTT Viewer to see or log any information after that. Is there another setting somewhere to enable DFU debug data logging?

Also i was able to get it to upload the dfu .zip file. After it uploads it says application sent successfully, but the system does nothing. The only thing i changed in the application is instead of flashing LED 2 times when i push a button it flashes 4 times.

Do I need BLE_DFU_ENABLED set to '1'? I had it set to '0' but changed it to '1' and it does not help.

It appears it locks up after accepting the new firmware. 

[bjorn-spockeli]

Segger RTT uses a control block in RAM to store the loggin data. When you jump to the bootloader, you are resetting the device and the bootloader code is reinitializing the RAM, which means that the RTT control block placed at a different location. So this is why you do not see any more log output after starting the DFU. 

My suggestion would be to start the Bootloader in debug session, countinue the execution so that the application starts up and then trigger DFU. You should then see all the log data from the bootloader during the DFU. 

Can you check if nrf_bootloader_app_start is being called? If it is then it means that the bootloader has passed execution to the new application and if the device is not responding then the fault is in the new application. 

Best regards

Bjørn