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.

[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