nrf52832 OTA over ESB based on SDK17.1.0

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Tue, 19 Sep 2023 01:35:20 GMT

Hi Edvin,

Thanks for your reply, I get it.

Best regards,

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Edvin — Mon, 18 Sep 2023 18:44:13 GMT

Hello Lurn,

I am out of office until January. Please create a new ticket (just checking some work stuff, and stumbled upon this one).

In the nRF5 SDK we don't encrypt the DFU image. It is only signed (private key) and verified (public key).

[quote user="Lurn_Z"]And does the Nordic chip have a unique identification code?[/quote]

No. Not for this use case. The only unique data are calibration data and address data. If you want something unique for every device, other than this, you must generate this yourself. It can e.g. be stored in the UICR registers if you don't intend to change it for the lifetime of the device.

But if you want to encrypt the FW before sending it, you would need to implement this yourself. The bootloader would then need to decrypt it before swapping the old firmware with the new one. This is feasible, and I know of other customers who have done similar things before without too much change in the bootloader.

Again, I will be out of office for the rest of the year, so I will not see any follow up questions until then. I suggest you create a new ticket.

Best regards,

Edvin

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Thu, 24 Aug 2023 06:38:39 GMT

Hi Edvin,

Not sure if you still following this case, but I want to know is the role of public key and private key only for matching? Is there any process of encrypting and decrypting the firmware in the bootloader? I just find the slip_encode/decode.

And does the Nordic chip have a unique identification code? It allows me to do an operation similar to activation to prevent my firmware content from being leaked.

Or do you have any other way to encrypt the firmware?

In this link it shows a way, but it looks using softdevice, but I didn't use the softdevice, just MBR.

Best regards

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Tue, 25 Apr 2023 08:22:27 GMT

Sorry, I didn't do the calculations just saw that the last packet was not 64 bytes.

And yes I saw the code here,

nrf_drv_uart_tx(&p_dfu->uart_instance, encoded_slip_packet, encoded_slip_packet_length+1);

So as you said, I should modify the MTU_SIZE to 131 it will be batter than now.

I will try this.

Update:

After change the values, I can update successfully too. But for now I can't see different whit it, but as you said, I can find that in my bootloader.

...

#define UART_SLIP_MTU (2 * (RX_BUF_SIZE + 1) + 1)

...

so I think the value you suggested should be better than before.

Thanks a lot.

Best regards,

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Edvin — Tue, 25 Apr 2023 08:13:03 GMT

52=n*4, where n = 13, so that is fine.

If you want to skip this part, you can adjust the bootloader to pad the remaining 1, 2 or 3 bytes with 0xFF. It is probably better than just asserting.

I discussed the MTU_SIZE/2 fix with the colleague who wrote the DFU_Master application a few years ago, and we figured out that the reason faulted now is a change in the bootloader. Before, it would gather up several packets, and do a big write containing more packets. The default behavior now is that it writes to flash after every package, which is why it failed.

We also looked at the buffer size, and found the reasoning behind why it was divided by 2.

If you look in the bootloader, you will find:

#define RX_BUF_SIZE                     (64) //to get 64bytes payload
#define OPCODE_OFFSET                   (sizeof(uint32_t) - NRF_SERIAL_OPCODE_SIZE)
#define DATA_OFFSET                     (OPCODE_OFFSET + NRF_SERIAL_OPCODE_SIZE)
#define UART_SLIP_MTU                   (2 * (RX_BUF_SIZE + 1) + 1)

So the reason behind this is that the "SLIP" encoding will sometimes have to add an extra byte in cases where the actual payload byte is the same as the END or ESC character in the SLIP library.

Hence, it needs to double the buffer size. On the last line there, you can see that we take the RX_BUF_SIZE+1, which would be the actual buffer + one byte (I don't remember. It could be the byte indicating the length or something). Then double it, in case all bytes are escape or end characters (which in theory could happen, but probably won't happen). Then you add 1 in the end to account for the actual end byte of the buffer. So you end up with a buffer size of: (2 * (64 +1) + 1 ) = 2*65 + 1 = 130 + 1 = 131 bytes.

So in order to do the exact opposite of this, you can use:

MAX_ACTUAL_PAYLOAD = (((MAX_MTU - 1) / 2) -1)

which will be 64. So if the payload buffer is maximum 64 bytes, it should always be safe:

#define MTU_SIZE 131
#define MAX_ACTUAL_PAYLOAD (((MTU_SIZE - 1)/2) - 1) // = 64 bytes.

Note that MTU_SIZE is also increased to 131, which corresponds to the actual MTU size of the UART buffer in the bootloader from SDK17.1.0.

Best regards,

Edvin

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Tue, 25 Apr 2023 07:49:33 GMT

Hi Edvin,

I used a custom board, and the UART connection method is jump wire. So the connection will be a bit unstable.

After I ported the code to an Android device(No more jump wire connections), it works fine.

And I only change the MAX_ACTUAL_PAYLOAD to MTU_SIZE/2 as you do.

On the Android device I tested 5 times, they are all successful, althougt the final package isn't 64 bytes. and I checked it that only the final package isn't n*4 bytes.

00> <debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0000AA40, src=0x20000558, len=64 bytes), queue usage: 1
00> <debug> nrf_dfu_flash: Flash write success: addr=0x0000AA40, pending 0
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
00> <debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0000AA80, src=0x200005DC, len=52 bytes), queue usage: 1
00> <debug> nrf_dfu_flash: Flash write success: addr=0x0000AA80, pending 0
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1

Update:

If you want I can show you the code on android, but it is not much different with DFU master, just modified the underlying code of the serial port communication.

Best regards,

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Edvin — Tue, 25 Apr 2023 07:27:56 GMT

Sorry for the late reply. I have been out of office.

I am sorry, but I am a bit confused.

Did you figure out the length problem? If the length of the .bin / .dat file is not n*4 bytes, you can try to open it in a binary editor (e.g. Hex Editor Neo), and add 0xFF's until it is n*4 bytes long before you convert it to a hex file.

And on your failing tests, are you running this on 2x DKs, or do you have some custom HW? Are you using UART Flow Control (on both sides) of the UART connection?

Regarding the Error 4 it is a bit difficult to say, because the error handler in the bootloader is very limited. You can try to set a breakpoint there, and look at the callstack to see if you can figure out what triggered the error handler to be triggered. It should be an APP_ERROR_CHECK() or an assert of some sort.

Best regards,

Edvin

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Fri, 21 Apr 2023 11:11:23 GMT

Hi Edvin,

First of all thank you for taking so much time to help me with this problem.

Now I can update successfully although I always get something wrong, but I think the question is on my hardware and the connect way.

I'll start porting it to other devices to test.

Thanks again for your help

Best regards,

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Fri, 21 Apr 2023 10:33:34 GMT

OK, I was update successfully one time(I think), after I modify the TX pin state, and then, I never success.

The last log shows:

devzone.nordicsemi.com/.../0421_5F00_DFU_5F00_test_5F00_1828.log

And I still get the error “ Hash verification failed. ”

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Fri, 21 Apr 2023 10:01:05 GMT

Hi Edvin,

I think the reason is that the UART tx pin of my mast device is floating, causing some unpredictable things.

I set the gpio to PULLUP, and it solved tht problem.

    if (p_config->pselrxd != NRF_UART_PSEL_DISCONNECTED)
    {
        nrf_gpio_cfg_input(p_config->pselrxd, NRF_GPIO_PIN_PULLUP);
    }

But after that I get anoter error.

00> <debug> nrf_dfu_validation: Hash verification. start address: 0x1000, size: 0x9E60
00> <warning> nrf_dfu_validation: Hash verification failed.
00> <debug> nrf_dfu_validation: Expected FW hash:
00> <debug> nrf_dfu_validation:  58 BD B7 97 03 3B 8A 07|X....;..
00> <debug> nrf_dfu_validation:  50 C0 C3 07 70 B5 37 10|P...p.7.
00> <debug> nrf_dfu_validation:  DC 8D 10 71 31 F3 FF 54|...q1..T
00> <debug> nrf_dfu_validation:  1D 39 BF 14 77 EC 79 AD|.9..w.y.
00> <debug> nrf_dfu_validation: Actual FW hash:
00> <debug> nrf_dfu_validation:  43 FB 69 A9 B1 CF FB A8|C.i.....
00> <debug> nrf_dfu_validation:  98 9C D5 89 FA D5 4D BB|......M.
00> <debug> nrf_dfu_validation:  9A 65 6E E1 30 58 CD DE|.en.0X..
00> <debug> nrf_dfu_validation:  CB 38 DB E3 D9 33 F8 07|.8...3..
00> <warning> nrf_dfu_serial: DFU request completed with result: 0xB
00> <debug> nrf_dfu_serial: Sending Response: [0x4, 0xB]
00> <debug> nrf_dfu_settings: Writing settings...
00> <debug> nrf_dfu_settings: Erasing old settings at: 0x0007F000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007F000, len=<info> app: Inside main

devzone.nordicsemi.com/.../0421_5F00_DFU_5F00_test_5F00_1755.log

Best regards,

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Fri, 21 Apr 2023 06:47:09 GMT

Update:

1. I modify the bootloader addr and size.

due to the bootloader is debug mode, I can't set the address to 0x78000, because if end address is 0x7E000, the size is not enough.

this is my set now.

2. Base the 1. sometime the error like this.

devzone.nordicsemi.com/.../0421_5F00_DFU_5F00_test_5F00_1356.log

Is this error because the length is not a multiple of 4 bytes?

But I think this packet is the last packte, so i can't decide his size.

Should I need to modify the bootloader? I mean if the target device in DFU mode need some special state?

such as the macro NRF_DFU_SINGLE_BANK_APP_UPDATES is 0 now.

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Fri, 21 Apr 2023 03:00:47 GMT

Sorry, I still can't update.

this log is program the mbr, bootloader, app, settings.

devzone.nordicsemi.com/.../0421_5F00_DFU_5F00_test_5F00_1032.log

and this is my flash region

I also try to make a script even use your script, but not worked.

I was only used bootloader and mbr.hex without application too.

this log is only have bootloader and mbr.

devzone.nordicsemi.com/.../0421_5F00_DFU_5F00_test_5F00_1051.log

Is my file too large causing insufficient space? Because the return error is 4.

But my application should be this size, and I can update via nrfutil.

I have no idea about this.

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Thu, 20 Apr 2023 13:02:01 GMT

Hi Edvin,

At first, thanks for your help.

So now you can run the DFU master correctly.

Due to the time difference, I will try to modify the MAX_ACTUAL_PAYLOAD to MTU_SIZE/2 tomorrow.

And I used the j-flash to program the init.bin and app.bin, it can set the offset. and I think there won't be a problem with that. If something wrong, I will make a script to do this.

Best regards,

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Edvin — Thu, 20 Apr 2023 11:33:46 GMT

Ok, so I ran the DFU Master sample (for the first time, actually).

It is correct, as you said that at least the UART sample expects the application binary to be present at address 0x30000 on the device running the DFU Master application. The init packet is expected at address 0x9000.

Important:

I found one bug that caused the bootloader to assert after the first application image packet was sent. The reason was that the bootloader was trying to write 62 bytes to flash. The reason for this was that in the DFU Master application, the MAX_ACTUAL_PAYLOAD is set to (MTU_SIZE/2-2), which gives 62. nrf_fstorage_write requires the length of the chunk that it is going to write to be a multiple of 4 bytes. So I changed MAX_ACTUAL_PAYLOAD to MTU_SIZE/2 instead of (MTU_SIZE/2-2), and after that it worked.

So, what I did was that I unzipped the dfu image which was a zip file. Inside that file, there are 3 files. The json file we will not use. The smallest file, called new_app.dat is the init packet. I renamed it init_packet.bin. The other, which is the application file, I renamed app_image.bin. Just to keep track of what is what.

Then I used this script (in a .bat file):

del files\dfu_img\app_image.hex
del files\dfu_img\init_packet.hex
bin2hex.py --offset 0x9000 files\dfu_img\init_packet.bin files\dfu_img\init_packet.hex
bin2hex.py --offset 0x30000 files\dfu_img\app_image.bin files\dfu_img\app_image.hex

This generated the init packet and app image hex files, which I then programmed together with the dfu master (compiled in SDK14.2.0)

nrfjprog -e --snr 682396787
nrfjprog --program files\DFU_MASTER.hex --verify --snr 682396787
nrfjprog --program files\dfu_img\init_packet.hex --verify --snr 682396787
nrfjprog --program files\dfu_img\app_image.hex --verify --snr 682396787
nrfjprog --reset --snr 682396787

now, connecting the UART wires between the two DKs. Put the target DK in DFU mode, and pressed button 1 on the DFU Master. That performed the DFU transfer of the new image, and the application changed.

Actually, I scripted everything, except unpacking the application image (which you could probably also script). Attached for reference:

make -j9
make -j9 -C ..\..\..\..\peripheral\blinky\pca10056\mbr\armgcc



del files\app.hex
del files\settings.hex
del files\bl.hex
copy ..\arm5_no_packs\_build\nrf52840_xxaa_mbr.hex files\bl.hex

copy ..\..\..\..\peripheral\blinky\pca10056\mbr\armgcc\_build\nrf52840_xxaa.hex files\app.hex
nrfutil settings generate --family NRF52840 --application files\app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 files\settings.hex

nrfjprog -e --snr 683963588
nrfjprog --program ..\..\..\..\..\components\softdevice\mbr\hex\mbr_nrf52_2.4.1_mbr.hex --verify  --snr 683963588
nrfjprog --program files\bl.hex --verify  --snr 683963588
nrfjprog --program files\app.hex --verify --snr 683963588
nrfjprog --program files\settings.hex --verify --snr 683963588
nrfjprog --reset --snr 683963588

nrfutil pkg generate --application files\new_app.hex --application-version 2 --hw-version 52 --sd-req 0x00 --key-file ..\..\..\private.key files\dfu_img.zip

timeout 10

del files\DFU_MASTER.hex
copy ..\..\..\..\..\..\14.2.0\examples\test\DFUMaster_UART\pca10040\blank\arm5_no_packs\_build\nrf52832_xxaa.hex files\DFU_MASTER.hex
del files\dfu_img\app_image.hex
del files\dfu_img\init_packet.hex
bin2hex.py --offset 0x9000 files\dfu_img\init_packet.bin files\dfu_img\init_packet.hex
bin2hex.py --offset 0x30000 files\dfu_img\app_image.bin files\dfu_img\app_image.hex

nrfjprog -e --snr 682396787
nrfjprog --program files\DFU_MASTER.hex --verify --snr 682396787
nrfjprog --program files\dfu_img\init_packet.hex --verify --snr 682396787
nrfjprog --program files\dfu_img\app_image.hex --verify --snr 682396787
nrfjprog --reset --snr 682396787
::nrfutil dfu serial -pkg files\dfu_img.zip -p COM8

Best regards,

Edvin

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Thu, 20 Apr 2023 07:26:25 GMT

Update:

I can transfer files but never succeed.

The process is as follows.

1. I flash the DFU master application on the master board.

2. make sure my target board in DFU mode.

3. program the init.bin and app.bin to master board.

4. connect master board and target board.

5. run the DFU master.

In source code the application_image_address = 0x30000;

and I get error like this

00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (data)
00> <debug> nrf_dfu_req_handler: Whole firmware image received. Postvalidating.
00> <error> app: Received a fault! id: 0x00004002, pc: 0x00000000, info: 0x200046F0

the full log file is here.

devzone.nordicsemi.com/.../0420_5F00_DFU_5F00_test_5F00_1448.log

In readme it shows the address.

so I change the application_image_address = 0x10000;

the error log is here

00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (data)
00> <error> nrf_dfu_req_handler: Cannot create data object without valid init command
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x8
00> <warning> nrf_dfu_serial: DFU request completed with result: 0x8
00> <debug> nrf_dfu_serial: Sending Response: [0x1, 0x8]
00> <error> app: Received an error: 0x00000004!

and log file:

devzone.nordicsemi.com/.../0420_5F00_DFU_5F00_test_5F00_1456.log

Another question:

In readme it said that

3) Open the .zip file and unzip the init .dat file and the binary image .bin of the application or the softdevice/bootloader.

it should be unzip the .zip file instead of unzip the init.data?

Hope you can give some solutions.

Best regards,

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Thu, 20 Apr 2023 03:16:49 GMT

Hi Edvin,

Yes, I won't run it on nRF, but I think the quickest way to test whether there is a problem with this process is to use this example

About the DFU master, I can transfer the packet successfully(i think), but my pending update device log shows no data received.

The process is as follows

I set the device in DFU mode, connect the DFU master with UART, then just run the DFU master.

In order to confirm that there is no abnormality in my DFU mode, I use the nrfutil to update it, and it was worked.

the dfu master log like this

devzone.nordicsemi.com/.../dfu3.txt

and my device in DFU mode log is here

devzone.nordicsemi.com/.../dfu.txt

Can you tell me what is wrong?

Update:

I checked the log when updating with nrfutil, at first I get a PING event and the data is 0x9, 0x1 with a SLIP_BYTE_END 0300

10> <info> nrf_dfu_serial_uart: len = 1, ret_code = 17, p_data[0] = 9
10> 
10> <info> nrf_dfu_serial_uart: len = 1, ret_code = 17, p_data[0] = 1
10> 
10> <info> nrf_dfu_serial_uart: len = 1, ret_code = 0, p_data[0] = C0
10> 
10> <debug> nrf_dfu_serial: Received ping 1
10> 
10> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
10> 
10> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_PING
10> 
10> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
10> 
10> <debug> nrf_dfu_serial: Sending Response: [0x9, 0x1]

in the DFU master, it also send the ping command log, you can see it in the dfu mater log, but my device didn't get it.

In order to confirm that the DFU mater send it ok, I connect it to my pc with UART, and I can get the data.

So I think maybe my device which is in DFU mode didn't receive the packet, but why?

Update 2:

I found that the GND of both of them is not connected, when I connect them, I can receive data.

Best regards,

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Edvin — Wed, 19 Apr 2023 12:16:20 GMT

Regarding the 8.15.9 DeviceFamilyPack, click the "Select Software Packs button in the toolbar in Keil, and select "latest" instead of "fixed":

Then, you need to click "OK" -> "OK" (in the next popup), then right click "device" in the project menu to the left, select "options for..." then select "8.44.1" in the "Version" option (or whatever version the "latest" in the previous step selected).

As long as you placed the sample in SDK14.2.0\examples\peripheral, so that it has a similar folder structure as the other examples, it should compile.

[quote user="Lurn_Z"]can you give me a code base SDK 17.1.0 ? I want to test it.[/quote]

Sorry, I don't have time to port this to 17.1.0 now. Seeing as you probably won't be running this on an nRF in the end either way, and this is only to see a possible implementation, I don't think you need to port it either.

What you probably want to start looking into is how the uart_send_init_packet() sends the init packet, and how uart_send_application_image() is used to send the application image (which is split over several packets).

Best regards,

Edvin

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Wed, 19 Apr 2023 11:37:35 GMT

Hi Edvin,

I want to port this code to an example for my SDK such as \examples\peripheral\blinky

but it have too much Compile Error, although I included the header file still got many undefined errors.

can you give me a code base SDK 17.1.0 ? I want to test it.

Best regards,

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Wed, 19 Apr 2023 11:19:26 GMT

I didn't find the file "nrf_serial_dfu.h"

and also I did not have the pack.

the download log is here.

Cannot download file developer.nordicsemi.com/.../NordicSemiconductor.nRF_DeviceFamilyPack.8.15.0.pack: Object not found

RE: nrf52832 OTA over ESB based on SDK17.1.0

Edvin — Wed, 19 Apr 2023 10:35:41 GMT

The DFU master does what the computer running nrfutil does when transferring the image.

[quote user="Lurn_Z"]

what I should do is make sure my nrf-device is in DFU mode, and just run the "DFU Mast code", am I understand currently?

[/quote]

Yes.

I have not tested this, but I believe there is some description saying how to do the test. Check out the DFU_SPI_readme.docx (yes, it is written for the SPI variant, but it covers your questions).

It explains how to transfer the DFU image (.zip file) to the flash of the DFU master by using JFlash. I played around with .bin files the other day. The thing with these is that they are not address mapped, like hex files are. But there is a tool that you can test (pip install bin2hex.py), and you can use this to convert .bin files to .hex files with an offset, so that you can program them using nrfjprog (for testing purposes).

bin2hex.py --offset 0x12000000 bin_file.bin hex_file.hex
nrfjprog --program hex_file.hex

[quote user="Lurn_Z"]And a question about it, what is the format of image .hex/.bin or .zip?[/quote]

Read the doc for the SPI sample, and you will see, but in short, it is the .bin and .dat inside the .zip that actually contains the data that is needed.

BR,
Edvin

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Wed, 19 Apr 2023 08:42:25 GMT

Hi Edvin,

I read the code about "DFU Master", I think in this code it use another nrf-device, and what I should do is make sure my nrf-device is in DFU mode, and just run the "DFU Mast code", am I understand currently?

And a question about it, what is the format of image .hex/.bin or .zip?

If it run a part of nrfutil that does the transfer, I think it should be a .zip which made by nrfutil, Am i right?

Best regards,

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Edvin — Wed, 19 Apr 2023 07:56:10 GMT

No worries, Lurn,

What you are writing makes sense to me! So we are back at having a UART bootloader without the possibility to use nrfutil, if I understand correctly.

However, you could still use nrfutil to generate the DFU images on a computer, and then somehow transfer that to the computer that will transfer the image to the nrf-device, right?

In that case, you would only need the ARM device to run the part of nrfutil that does the transfer, which is only a small part of nrfutil.

While we do not have a strip down version of nrfutil, the colleague that wrote the getting started with DFU guide also wrote a sample application that can run on another nRF device, and will update the target nRF device over UART. Click that link, and search for "DFU Master Code".

I believe it may be easier to analyze and reverse engineer the process from that sample than it is to interpret the nrfutil source code.

Unfortunately, we don't have very much good documentation on nrfutil, but a couple of useful links are:

A general description of the DFU procedure can be found here.

The UART Serial protocol is described here.

Just in case, the link to nrfutil source code. But I find it difficult to navigate to understand the protocol.

Lastly, one additional hint could be to hook on a UART to computer sniffer/analyzer, and observe an update, to see if you can make sense of the packets, as described in the links above.

Best of luck!

Best regards,

Edvin

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Wed, 19 Apr 2023 03:49:37 GMT

Hello Edvin,

I'm so sorry for finding out that I've entered a misunderstanding.

Originally I was saying that I need to upgrade via UART, and yes it worked, but But after I finished testing, my colleague told me that we are using ARM architecture, so I can't update my nrf-device by use nrfutil, Because the source code has some libraries that cannot be ported to the host device.

So I wanted to use the bluetooth update and ask you a lot of questions about it, but when I finished work yesterday and asked my colleague about bluetooth related things ready to debug the bluetooth upgrade, he told me that our host device does not have bluetooth enabled (I Know that our host device has bluetooth, but I don't know it won't be used).

Sorry for taking up so much of your time with these wrong questions.

Let me sort out the current situation.

1. I can enter the DFU mode normally.

2. I can update success via UART on PC.

3. I can't port the ntfutil to host device, because it use ARM.

4. Since 3 is not established, I can't upgrade nrf-device on the host device.

So I think the question should be how to update nrf-device without ntfutil.

And I think there is a method like this:

I can receive the update file and save it to bank1, then enter the DFU mode, it will check and update itself.

But I don't know how to receive the file and save it to bank1.

I found an example made by Vidar, but it also used nrfutil.

Apologies again for the previous question.

Best regards,

Lurn

RE: nrf52832 OTA over ESB based on SDK17.1.0

Edvin — Tue, 18 Apr 2023 12:57:17 GMT

Hello Lurn,

NRF_DFU_BLE_REQUIRES_BONDS is set to 0 in your bootloader's sdk_config.h file, right?

If it is not set to 0, try to set it to 0. If it is set to 0, please try to debug ble_dfu_transport_init() in nrf_dfu_ble.c.

Does the line:

if (nrf_dfu_settings_adv_name_is_valid())

return true? (you can simply add a log line using NRF_LOG_INFO(); and it will pop up in the log that you pasted)).

Also check if the line:

    if ((m_flags & DFU_BLE_FLAG_USE_ADV_NAME) != 0)

in gap_params_init() returns true. If it does, it will use a different advertising name.

Let us start with those, and take it from there, depending on what you see.

Best regards,

Edvin

RE: nrf52832 OTA over ESB based on SDK17.1.0

Lurn_Z — Tue, 18 Apr 2023 09:32:09 GMT

Hi Edvin,

I use the bootloader_ble_s132_pca10040_debug to build the bootloader.

Then I use this cmd to program it.

nrfutil settings generate --family NRF52 --application app.hex --application-version 0 --bootloader-version 0 --bl-settings-version 2 settings.hex

nrfjprog --eraseall -f NRF52
nrfjprog --program s132_nrf52_7.2.0_softdevice.hex --verify -f NRF52
nrfjprog --program bootloader.hex --verify -f NRF52
nrfjprog --program app.hex --verify -f NRF52
nrfjprog --program settings.hex --verify -f NRF52
nrfjprog --reset -f NRF52

[quote userid="26071" url="~/f/nordic-q-a/96494/nrf52832-ota-over-esb-based-on-sdk17-1-0/420464"]

Strictly speaking, we don't have a size of 5A000, because the bootloader takes up address 0x71000 to 0x80000, so you can set start address 0x26000 and size 0x4B000

But it wouldn't be an issue unless your application is so big that it starts growing into your bootloader.

The IRAM1 settings (RAM settings) you can leave as is. The softdevice requires 8 bytes (the same as MBR) if you do not enable it in your application.

[/quote]

I set the application start address to 0x26000 adn size is 0x4B000, Since I'm not using bluetooth just ESB in my application, no other modifications about the RAM/ROM.

To enter the DFU mode, I use the NRF_POWER_GPREGRET register.

#define BOOTLOADER_DFU_GPREGRET_MASK                 (0xF8)      /**< Mask for GPGPREGRET bits used for the magic pattern written to GPREGRET register to signal between main app and DFU. */
#define BOOTLOADER_DFU_GPREGRET                      (0xB0)      /**< Magic pattern written to GPREGRET register to signal between main app and DFU. The 3 lower bits are assumed to be used for signalling purposes.*/
#define BOOTLOADER_DFU_START_BIT_MASK                (0x01)      /**< Bit mask to signal from main application to enter DFU mode using a buttonless service. */
#define BOOTLOADER_DFU_START    (BOOTLOADER_DFU_GPREGRET | BOOTLOADER_DFU_START_BIT_MASK)      /**< Magic number to signal that bootloader should enter DFU mode because of signal from Buttonless DFU in main app.*/


static void enter_dfu_mode(void)
{
    uint8_t old_gpregret = nrf_power_gpregret_get();
    UART_PRINTF("get the old_gpregret = %d", old_gpregret);
    uint8_t temp = 0;

    nrf_power_gpregret_set(BOOTLOADER_DFU_START);
    while((temp & BOOTLOADER_DFU_START) != BOOTLOADER_DFU_START)
    {
        temp = nrf_power_gpregret_get();
        UART_PRINTF("temp = %d", temp);
    }
    UART_PRINTF("nrf_pwr_mgmt_shutdown NRF_PWR_MGMT_SHUTDOWN_GOTO_DFU and system reset.");
    nrf_delay_ms(10);
    nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_DFU);
    NVIC_SystemReset();
}

I get the log over RTT shows "nrf_pwr_mgmt_shutdown NRF_PWR_MGMT_SHUTDOWN_GOTO_DFU and system reset", then I reconnect the RTT it shows

00> In nrf_bootloader_init
00> Calling nrf_dfu_settings_init()...
00> Initializing nrf_fstorage_nvmc backend.
00> Using settings page.
00> Copying forbidden parts from backup page.
00> Destination settings are identical to source, write not needed. Skipping.
00> Backing up settings page to address 0x7E000.
00> Destination settings are identical to source, write not needed. Skipping.
00> Enter nrf_bootloader_fw_activate
00> No firmware to activate.
00> CRC check of app failed. Return 1
00> App is valid
00> DFU mode requested via GPREGRET.
00> WDT is not enabled
00> in weak nrf_dfu_init_user
00> timer_stop (0x20005980)
00> timer_activate (0x20005980)
00> Entering DFU mode.
00> Initializing transports (found: 1)
00> Initializing BLE DFU transport
00> Setting up vector table: 0x00071000
00> Enabling SoftDevice.
00> State request: 0x00000000
00> Notify observer 0x0007C9E8 => ready
00> State change: 0x00000000

but I can't find the ble name via nrf_connect on my phone. I didn't change the name, so the name should be "DfuTarg"

#ifndef NRF_DFU_BLE_ADV_NAME
#define NRF_DFU_BLE_ADV_NAME "DfuTarg"
#endif

Can you please tell me where I am wrong?

Best regards,

Lurn