Flashing firmware OTA for nRF Connect SDK nRF52840

RE: Flashing firmware OTA for nRF Connect SDK nRF52840

Edvin — Mon, 28 Oct 2024 14:43:15 GMT

Try to enable logging in the bootloader, by following step 2 in this exercise:

https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/topic/exercise-1-dfu-over-uart/

What does the log say when you try to execute the DFU from your C# application?

BR,
Edvin

RE: Flashing firmware OTA for nRF Connect SDK nRF52840

MatiM — Fri, 25 Oct 2024 13:36:35 GMT

I will try to explain it step by step what problems I get 🙂:)

I have a custom board using nRF52840 and want to flash firmware to its board using Xamarin Forms.

I have an LED mounted on this board that blinks with different patterns when connected to the BlueTooth device or sends data, advertising, low battery, etc.

As I know we need to connect to the device first and then when we find the DFU characteristic we can send data to that one. I can also see in the example of nRF Connect for Android that after sending all the data, the code is verified and replaced with a new one.

What I can also see, is when I upload the code using the nRF app when the packets are sent, my LED still blinks, indicating e.g. battery level, meaning the old code is still working and showing the status even though there packets are being uploaded to the board. However, when the validating is performed, it looks like the board goes off as my LED doesn't work. After that, I can see the new code working.

So I can understand from that, that "validating" checks and replaces the code.

However, in my case with C#, validating takes no time, and there is no time when I can see the LED not working, which would mean that the code is not replaced.

I tried to replicate exactly the behavior from the nRF app, but apparently something is different. Also, I can see that the characteristic has no response, but we need to validate the flash so how do we do that?

Here I put a screenshot from the nRF app to show you the service and characteristics I am working on, I hope you can help me with understanding that.

Best Regards

Mateusz

RE: Flashing firmware OTA for nRF Connect SDK nRF52840

Edvin — Wed, 23 Oct 2024 19:26:33 GMT

What characteristic?

You are talking about the LED behavior. I am not sure which one you refer to. When performing a DFU, the application will reset the device, and it will enter DFU mode in the bootloader. When this happens, there is a different LED pattern. After everything is complete (upload/download, validation and swapping) the new application is started. Which of these are we talking about?

Best regards,

Edvin

RE: Flashing firmware OTA for nRF Connect SDK nRF52840

MatiM — Tue, 22 Oct 2024 11:46:31 GMT

Hi Edvin,

thank you for your answer.

Could you maybe help me with understanding the protocol, especially validating. After sending the packets, I try to send a validation packet.

I can see in the nRF Connect for Android app while uploading my firmware code is still working (blinking LED), but when it shows validating it is off (so I assume the program is stopped) and then the new program works.

Meanwhile in my app after uploading it doesn't take to verify and sometimes it shows an error that this characteristic doesn't support read. (when I try to read validation).

RE: Flashing firmware OTA for nRF Connect SDK nRF52840

Edvin — Tue, 22 Oct 2024 11:41:46 GMT

Hello,

[quote user=""]The problem I am getting is that sometimes it sends the packages and sometimes it doesn't[/quote]

We don't have any support for C#, or any tools or examples using it that shows how it should work, so unfortunately I don't know why it is not working. If you have questions on the protocol, I might be able to help, but if the issue is that the C# application is not working as intended, then I don't know what the issue might be.

Perhaps these questions can help you along the way:

Does your application find the DFU target device?

Is it able to connect to it?

When you say it is not sending packets, perhaps you are writing them too fast?

Do you check the return values when trying to send a packet? Does it indicate that something is wrong when the packets are not sent?

Best regards,

Edvin