Uploading issue of Application and Softdevice file from the Master serial DFU.

[Goudra]

Hi,

I have implemented the Master serial DFU code to update application and SD file. I'm following DFU packet send sequence. Ping, inti packet, FW packet.

I'm framing packet of 116 byte and sending to nrf device. But device is not properlly uploading my packet.

To check this issue, i used development kit. I have created separate packages for Soft device, Application and bootloader.

nrfutil.exe pkg generate --hw-version 52 --softdevice s132_nrf52_6.1.0_softdevice.hex  --sd-req 0xAF  --key-file private.pem sd.zip

nrfutil.exe pkg generate --hw-version 52 --bootloader-version 2 --bootloader  secure_bootloader_uart_mbr_pca10040.hex --sd-req 0xAF  --key-file private.pem boot.zip

nrfutil.exe pkg generate --hw-version 52 --application-version 2 --application blinky.hex --sd-req 0xAF --key-file private.pem app.zip

I have loaded the boot loader file using nrfUtil dfu serial -b 115200 -p COM22 -pkg boot.zip command and I logged this data exchange between CMD prompt and nrf device.

Please check the attachment for the log file.securebootloader.htm

Below points i'm not able to understand from the log file.

1. is MTU  0x0183 byte ?

2. Why 0x08 opcode packet size is always changing?  some time 65 bytes, 64 bytes, 795bytes... etc

3.When we should ask for a CRC from the device? as in log its random time its asking for CRC. 

4. How many bytes for data split need to do?

5. As in the log, while sending data to device, First it sending ~64bytes of 5 packets, then around 750 to 850 bytes of packet and at the last it sending around 3k bytes to device. after this its asking for CRC. Why this pattern?  Why number of bytes varying  packet to packet?

Please provide the details.

Thanks

Basava

[Vidar Berg]

Hi,

1. It's actually 0x83 bytes because the value is little endian. From your log:

60<RESPONSE> 07<OPCODE MTU GET> 01<NRF_DFU_RES_CODE_SUCCESS> 83 00 <VALUE - LSB comes first>

2. What version of nrfutil are you using? I thought the PRN was set to '0' by default but appears to be 192 here.  Note that the transfer size shown in the log does not reflect the packet size, see SLIP encoding. I couldn't spot any large packages at least.

3. It is up to the controller. If you have a reliable transport you might not need it at all. You could do before every execute command to ensure that you don't have to re-start the entire upload if there was a transfer error. 

4. The MTU size limits the packet size. So the number of "splits" depends on packet size and the size of your data objects.

Regards,

Vidar

[Vidar Berg]

Hi,

1. It's actually 0x83 bytes because the value is little endian. From your log:

60<RESPONSE> 07<OPCODE MTU GET> 01<NRF_DFU_RES_CODE_SUCCESS> 83 00 <VALUE - LSB comes first>

2. What version of nrfutil are you using? I thought the PRN was set to '0' by default but appears to be 192 here.  Note that the transfer size shown in the log does not reflect the packet size, see SLIP encoding. I couldn't spot any large packages at least.

3. It is up to the controller. If you have a reliable transport you might not need it at all. You could do before every execute command to ensure that you don't have to re-start the entire upload if there was a transfer error. 

4. The MTU size limits the packet size. So the number of "splits" depends on packet size and the size of your data objects.

Regards,

Vidar

[Goudra]

Hi Vidar,

Thanks for the reply.

While testing with nrfutil i found this issue

https://devzone.nordicsemi.com/f/nordic-q-a/42975/op_code-error

I"m suspecting below reason for that 

https://devzone.nordicsemi.com/f/nordic-q-a/42982/secure-dfu-without-flow-control-sdk-15-2

i request you please check these and help me to understand it.

Thanks

Basava.

[Vidar Berg]

Hi Basava, 

Since you don't have HWFC enabled it may help to request the checksum more frequent. This will lower the throughput some but also help reduce the risk of buffer overflow on the uart interface. As a test I would suggest to try requesting it after every data packet.

[Goudra]

Hi,

I tried with 64 bytes with 57600 baud, but I'm getting Hardfault error.

then i tried with  32 bytes with 57600 baud and 1 sec delay in between each packet. Now its working fine.

 I was tested it with 500msec and it is going for hardware fault. It didn't write it to flash.

I really don't know why it need 1sec to write 32bytes Flash memory. I'm not trace out where its going wrong. 

But the issue is, i'm sending 34k bytes of data. It will take lot of time to send. So is there any solution for this?

Thanks, 

basava