BLE DFU Issue

RE: BLE DFU Issue

Einar Thorsrud — Thu, 07 May 2020 13:40:15 GMT

Hi JK,

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

Einar

RE: BLE DFU Issue

jawadk — Wed, 06 May 2020 14:42:12 GMT

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

RE: BLE DFU Issue

Einar Thorsrud — Wed, 06 May 2020 14:01:12 GMT

Hi JK,

[quote user="jawadk"]How can we found what is the problem to solve it ?[/quote]

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

RE: BLE DFU Issue

jawadk — Wed, 06 May 2020 10:58:59 GMT

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 ?

RE: BLE DFU Issue

Einar Thorsrud — Wed, 06 May 2020 10:45:24 GMT

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

RE: BLE DFU Issue

jawadk — Wed, 06 May 2020 10:20:55 GMT

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.

RE: BLE DFU Issue

jawadk — Wed, 06 May 2020 06:44:12 GMT

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

RE: BLE DFU Issue

jawadk — Wed, 06 May 2020 06:16:22 GMT

Hi Einar,

you were right.

my application starts and !!

but when I flash just the softdevice + application it works fine.

what can be the problem ? because I tried to DFU the ble_app_buttonless_dfu example and its also didn't start advertising

RE: BLE DFU Issue

jawadk — Tue, 05 May 2020 15:50:12 GMT

Hi,

I an using the latest SDK with softdevice 7.0.1

I don't think the problem is in my application, cause it worked fine with the softdevice.

besides I tried the ble_app_buttonless_dfu example instead of my application, and I faced the same problem.

besides I will try to print something at the beginning of my application and will inform you when I have the result.

RE: BLE DFU Issue

Einar Thorsrud — Tue, 05 May 2020 15:03:46 GMT

Hi JK,

[quote user="jawadk"]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.[/quote]

You should not put much emphasis in the addresses ranges from nRF Connect programmer when it reads the memory of a device and attempts to interpret it. This is just an issue with nRF Connect Programmer app. The last two words of the MBR page 0xFF8-0xFFF are used by the bootloader and written to either when you program the bootloader hex or by the MBR itself (depending on SDK version etc). Since they are not empty (not all FFFF's, the programmer app interprets it as the start of the application, but that is not the case. I do not think this is related to the issue you are seeing.

[quote user="jawadk"]So I think this way when the bootloader jumps to the address 0x1000 the softdevice will not be able to run properly ! [/quote]

No, that is not the problem.

[quote user="jawadk"]What can cause this problem !??[/quote]

Good question. Can you try to verify that the application is not started? My assumption is that the application is started, but misbehaving for some reason, perhaps because the bootloader did not clean up properly after itself. Checking what happens in the application (or verifying that it does not start) should be the next step. I also wonder what SDK version you are using?

Einar

RE: BLE DFU Issue

jawadk — Tue, 05 May 2020 10:27:30 GMT

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

RE: BLE DFU Issue

Einar Thorsrud — Tue, 05 May 2020 09:38:40 GMT

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

RE: BLE DFU Issue

jawadk — Tue, 05 May 2020 07:41:46 GMT

Hi,

I just debugged the boot loader after performing a successful DFU.

the last function running after the bootloader lose control is the app_start(uint32_t vector_table_addr) function from nrf_bootloader_app_start_final.c file.

after the jump_to_addr function, the bootloader stop running but the application didn't start at all, and can't see the device advertise as it does without the bootloader.

Help please.

RE: BLE DFU Issue

jawadk — Mon, 04 May 2020 13:08:50 GMT

Hi,

tried to DFU the example ble_app_buttonless_dfu with no success.

flashed the softdevice, then the bootloader, then DFU using the nrf connect app on mobile, the application DFUs successfully but the bootloader not activating the application.