BLE DFU Issue

[jawadk]

Hi,

I am trying to develop the DFU capability for my device.

I added the necessary code from the example ble_app_buttonless_dfu to my application.

then started as explained in this step by step guide:

https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader#h23sjziacp7vrw0scs2t3tua1ax0426

I flash the softdevice then the bootloader, then DFU the application successfully, but the application doesn't start up at all,

then I tried to debug the application and it is also doesn't start up, it behaves like when flashing the application without the softdevice.

I noticed in the.

when I flash only the softdevice and the application everything works fine when I comment the DFU service and the ble_dfu_buttonless_async_svci_init function.

seems like the bootloader not jumping to the application even after a successful DFU.

Please help

BR

JK

[Einar Thorsrud]

Hi JK,

I don't have an immediate suggestion about what causes this issue, but I have some suggestions about how to narrow down the problem:

• Which address does app_start() jump to? 0x1000? If so, that would be correct and should cause the application to be started (by the SoftDevice in this case).
• Can you try verifying if the application is started or not? It could be that for some reason the presence of the bootloader causes the application to hit an error, and therefore it does not start to advertise. Can you try putting a breakpoint in the start of main in the application? If that causes problems, can you try toggling a GPIO a few times at the start of main, and check with a logic analyzer if that happens.
• You could also add RTT logging to the bootloader to see what is going on, but based on what you have written it seems likely that the application is likely started and that we need to look there to understand what is happening.
• Which SDK version do you use?

Einar

[jawadk]

Hi Einar,

And thank you for your help.

I figured something using the nRF Connect Programmer.

when I flash the soft device alone and rea the memory every thing seems right.

But after that when I flash the bootloader and read the memory again by the nRF Connect Programmer the region name of the sofdevice switched to Application ( the color switches from blue to green) and the start address of the softdevice switches to be 0xFF8 instead of 0x1000.

So I think this way when the bootloader jumps to the address 0x1000 the softdevice will not be able to run properly ! 

What can cause this problem !??

here is a screen shot for the problem using nRF Connect Programmer.

Thank you again for your help

BR

JK

[jawadk]

Hi Einar,

just tried to DFU the my nominal application without the ble_app_buttonless_dfu example code I added to the application and it works, my application start working.

No I need your help to solve this please.

when I run the application with the ble_app_buttonless_dfu code without the bootloader the ble_dfu_buttonless_async_svci_init function return an error, but I think it should be doesn't it ? cause their is no bootloader

BR

JK

[jawadk]

Hi,

Now I managed to perform the DFU correctly.

The remaining problem now is the buttonless DFU part at the application.

when I initialize thw DFU service I can't use the NUS service !

I increased the NRF_SDH_BLE_VS_UUID_COUNT from 1 to 2

And have the ble_uuid updated to: 

static ble_uuid_t m_adv_uuids[]          =                                          /**< Universally unique service identifier. */
{
    {BLE_UUID_DEVICE_INFORMATION_SERVICE, BLE_UUID_TYPE_BLE},
    {BLE_UUID_NUS_SERVICE, NUS_SERVICE_UUID_TYPE}
};

Also updates the RAM-Start address to give the softdevice the memory size needed !

But still I have a Problem.

[Einar Thorsrud]

Hi JK,

It ooks like you are close to solving the issue. Is the error still coming from the call to ble_dfu_buttonless_async_svci_init()? If yes, what is the error code? If this is not it, which function call returns an error, and what is the error? This is essential information that narrowed down the issue a lot.

It could potentially be that adding the call to ble_dfu_buttonless_async_svci_init() would make a subsequent function call fail (for instance when you had NRF_SDH_BLE_VS_UUID_COUNT  and if NUS is initialized after the buttonless DFU service. In that case, initializing NUS would fail.)

Einar

[jawadk]

Hi Einar,

I am very stressed to solve this issue and I am running out of time  .

the function ble_dfu_buttonless_async_svci_init returns an error only when there s no bootloader flashed to the device.

after I am DFUs the device I finally can debug the application FW, and I don't have any errors, so I don't know where the problem this !

How can we found what is the problem to solve it ?

finally some question I don't know if it is relevant:

do I have to add the following code

            err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
            APP_ERROR_CHECK(err_code);

under the BLE_GAP_EVT_CONNECTED case in the ble_evt_handler function ?

BR

JK

[Einar Thorsrud]

Hi JK,

jawadk said:

How can we found what is the problem to solve it ?

You need to understand what error occurs in the application. I suggest we start by summing up what we know after the tests you have done so far:

• The application works and runs correctly when you don't have a bootloader and don't initialize the buttonless DFU service by calling ble_dfu_buttonless_async_svci_init() (this function will return an error if a bootloader is not present).
• DFU works, and the bootloader starts the application.
• When the application is started by the bootloader and you don't call ble_dfu_buttonless_async_svci_init() everything works correctly.

Is the above a correct understanding?

If yes, then you need to debug the application when the bootloader is present after adding the call to ble_dfu_buttonless_async_svci_init(). The simplest way to get started is to enable debug logging in the application. Is an error printed? If so, and you are using a debug build, you should see the file name, line number, and error code, which corresponds to a function call. Do you see that? Please past the log here. (Just to be clear, now we are talking about the log form the application, we are no longer interested in the bootloader since we know that is working.)

To be clear: the key question now is what exactly is it that fails in the application and how? You need to find that through logging or debugging.

Regarding the question about nrf_ble_qwr_conn_handle_assign(), then yes, you should do that if you are using the Queued write module (which most SDK examples do). If not, then you should not add it.

Einar

[jawadk]

Hi Einar,

when I was testing the third point you noted above the nrf connect app wasn't able to connect anymore to the nRF52840 device anymore.

I did a communication reset for the phone and suddenly everything works fine !!!

I spent the whole day on this and the solution is a communication reset for the phone .

so basically my problem was to increase the NRF_SDH_BLE_VS_UUID_COUNT and to set the RAM start address correctly.

Thank you very much for your help

BR

JK

[Einar Thorsrud]

Hi JK,

I am glad to hear you got it working. Thanks for letting us know.

Einar