This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents
  • 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

Reply
  • 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

Children
No Data
Related