nrf52832 OTA over ESB based on SDK17.1.0

[Lurn_Z]

Hi everyone:    I developed an application based on ESB wireless communication protocol ofr the nRF52832, and I would like to perform an OTA DFU with it.    Do you know any example of some over the air FW upgrade of nRF52832 chip via ESB protocol.

    SDK is 17.1.0.

Best regards,

Lurn.

[Lurn_Z]

I only found examples of ble and uart in the dfu/secure_bootloader folder, Which one should I use or how should I modify it to adapt my program.

[Edvin]

Hello,

It is correct that you will only find BLE and UART in our samples, but I know that several customers have ported this to SPI, so if you need it over ESB, then that should also be possible. The transport layers in the bootloader for the nRF5 SDK are on purpose quite separated from the rest of the libraries, to make it easier to change the transport layer, or to add your own transport layer.

But you do need to implement it yourself. Also note that we do not have the "DFU Master" as an official part of our SDK. We have tools like nrfutil (open source) or nRF Connect for Desktop (not open source), and applications for mobile phones that are open source (but mobile phones doesn't have ESB). However, there is an unofficial implementation (not properly tested. You can use it, but on your own "risk"), which you can find here. I have not tested these myself, but you can give it a go. I suggest you test out the UART master, in combination with the uart bootloader, and then you can port both to ESB once you are up and running.

Best regards,

Edvin

[Edvin]

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

[Lurn_Z]

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

[Edvin]

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

[Lurn_Z]

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

[Lurn_Z]

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

[Edvin]

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).

Lurn_Z said:

And does the Nordic chip have a unique identification code?

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

[Lurn_Z]

Hi Edvin,

Thanks for your reply, I get it.

Best regards,

Lurn