Advertising doesn't change name after code update

[Corapche]

Greetings,

I've been developing a DFU firmware that should update the device through Android. The thing is, the device works, but I changed the advertising name, and it still shows the old name when I try to update the device. I use the following function to update the name:

static void make_dev_name(void)
{
    ble_gap_addr_t device_address;
    uint8_t companyName[] = {"M"};
    uint8_t modelName[] = {"1"};
    uint8_t *macAddressName;
    uint8_t macTmp[12];

    sd_ble_gap_addr_get(&device_address);
    macAddressName = Convert_Hex_To_Ascii(&device_address.addr[0], 4);
    memcpy(&DEVICE_NAME[0], companyName, 1);
    memcpy(&DEVICE_NAME[1], modelName, 1);
    memcpy(&DEVICE_NAME[2], macAddressName, 12);

}

Any idea why this issue occurs?

I used reference from here;
https://novelbits.io/ota-device-firmware-update-part-3/

[Vidar Berg]

Hello,

When is make_dev_name() called, is it only on startup, or are you sending a command over BLE to update the name? 

Best regards,

Vidar

[Corapche]

Only on start-up.

int main(void)
{
    bool erase_bonds;
    ret_code_t err_code;
    ble_gap_addr_t device_address;
    
    // Comment this for new modules
    sd_power_dcdc_mode_set(1);

    // Initialize.
    uart_init();
    log_init();

    // Initialize the async SVCI interface to bootloader before any interrupts are enabled.
    err_code = ble_dfu_buttonless_async_svci_init();
    APP_ERROR_CHECK(err_code);

    timers_init();
    buttons_leds_init(&erase_bonds);
    power_management_init();
    ble_stack_init();

    make_dev_name();

    gap_params_init();
    gatt_init();
    services_init();
    advertising_init();
    conn_params_init();

    //if(nrf_gpio_pin_read(WAKEUP_IN_PIN))
    //{
    //    while(1);   // wait here 
    //}

    sd_ble_gap_addr_get(&device_address);
    nrf_delay_ms(5);
    while(!nrf_gpio_pin_read(WAKEUP_IN_PIN))
    {
        //nrf_gpio_pin_clear(UART_TX_NOTIFY);
        //nrf_delay_ms(250);
        //nrf_gpio_pin_set(UART_TX_NOTIFY);
        for(int i=0; i<6; i++)
        {
            do
            {
                err_code = app_uart_put(device_address.addr[i]);
                if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_BUSY))
                {
                    NRF_LOG_ERROR("Failed receiving NUS message. Error 0x%x. ", err_code);
                    APP_ERROR_CHECK(err_code);
                }
            } while (err_code == NRF_ERROR_BUSY);
            
        }
        //nrf_delay_ms(500);
        nrf_delay_ms(50);
    }

    // Start execution.
    //printf("\r\nApplication started.\r\n");
    NRF_LOG_INFO("Debug logging for UART over RTT started.");
    while(app_uart_tx_done());
    app_uart_close();
    advertising_start();

    wdt_init();

    // Enter main loop.
    for (;;)
    {
        // Feed the watchdog
        feed_dog();
        // Power management 
        idle_state_handle();

    }
}

[Corapche]

I tried to debug it with Ozone, commented log_init() because it got stuck there and now it gets stuck or it crashes on 

ble_dfu_buttonless_async_svci_init(); (line 1041)

[Vidar Berg]

When using Ozone, it is important to select the following checkboxes: 

Otherwise, the softdevice and bootloader will be skipped in the boot sequence. 

Corapche said:

commented log_init() because

What do you use to rebuild the project with?  

[Corapche]

Ok, so I checked those boxes, but now the program doesn't get into the main function when I set a breakpoint.

The debugging is done on NRF52_DK.

[Vidar Berg]

Do you have a bootloader on your device?

[Corapche]

Yes, I merge the following:

1. Generate Settings File from application (a bootloader settings page that contains information about the current DFU process):
nrfutil settings generate \
--family NRF52 \
--application app_file.hex \
--application-version 0 \
--bootloader-version 0 \
--bl-settings-version 2 \
boot_settings.hex

2. Merge Bootloader Settings, Bootloader, Soft Device and Application (to create final application HEX file):

mergehex -m \
boot_settings_file.hex \
secure_bootloader_file.hex \
sXXX_softdevice_file.hex \
app_file.hex \
-o app_uart_0.0.1.hex

Flashing the custom HEX image to your board
3. Program hex file to NRF52 DK

3.1 nrfjprog -f nrf52 --recover
3.2 nrfjprog -f nrf52 --eraseall
3.3 nrfjprog -f nrf52 --program app_file.hex --reset --verify

[Vidar Berg]

For debugging, I recommend creating the settings page with boot validation disabled. 

--app-boot-validation NO_VALIDATION

This will allow the bootloader to boot the app even if the debugger as loaded a slightly different version of the app image.

[Corapche]

Ok, update on the project. I had some issues with the OS, now I am able to debug the DFU part of the project in Segger. So I get NRF_BREAKPOINT_COND whenever a APP_ERROR_CHECK(err_code); is called in the code. This happens during debugging. I also put comments on err_code = ble_dfu_buttonless_async_svci_init();, so it doesn't initialize a bootloader check (seems that was the issue that didn't let me debug.)

Update: When I comment error check function in the timers_init() function, I get the following:

[Vidar Berg]

I have not seen your code, so I can't tell why it is failing. Please check what the error code was. You can check this by enabling debug logs and build with the DEBUG flag set, or by inspecting the variables passed to the erorr handler after NRF_BREAKPOINT_COND is reached.

[Corapche]

This is the error I get in the debug output.

<error> app: ERROR 12 [NRF_ERROR_DATA_SIZE] at C:\Proj\nRF5_SDK_17.1.0_ddde560\PROJECT\MyProj\003p\main.c:832
PC at: 0x000272D5
<error> app: End of error report

So there are 2 outcomes:

1. When I go with step during debugging, the program goes into infinite loop (HardFault_Handler()) on the log_init() part.
2. When I go with Continue execution, the error above appears when the debugger continues to execute from line 1045 (timers_init()).

[Vidar Berg]

This error is raised by the UARTE peripheral if it received invalid data. This can happen if the UART RX input is left floating or if you have an external device sending invalid data packets. You can comment the APP_ERROR_HANDLER line if you want to ignore com. errors.