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

[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 

[Vidar Berg]

Hi Basava,

have you tried with nrfutil with the same baudrate without flow control? I took ~30 seconds to upload the softdevice (145K) image here. Would be nice to know if you get the same result.  

[Goudra]

HI Vidar,

Thanks for the reply. I have tried with 9600 baud rate with nrfutil. Its taking around 50 sec to upload and it updated properly.

So same thing i have implemented C code to transmit FW packet to BLE. I'm making 64 bytes of packet of 4 bytes and sending it to BLE. It receiving properly. After sending 4k asking for CRC. I'm getting CRC.

I'm facing issue here.

1. After sending 4 or 5 4kbytes packet. Bootloader code going for Hardware fault.

2. I'm not understanding this issue. It will update the FW using CMD prompt nrfutil commands.

3. But with my code it is going for Hardware fault.

Is there any delay required for each packet?

What will be the reason for this hardware fault issue?

Please let me know the suggestions.

Thanks 

Basava.

[Vidar Berg]

Hi Basava,

Are you able to debug the bootloader to see where the Hardfault occurred? The bootloader should not hardfault because of data being transferred too fast. 

[Goudra]

Hi Vidar,

Now i'm sending data at 9600 baud rate using nrfutils command from the Prompt. Its working. But we have implemented same in St controller side(C code), here we saw same issue with hardware fault. 

Then we log the working CMD prompt data, we observe the log packet by packet. While sending  Firmware packet, after every 3 packet its need 200msec delay. (I really dont know why this delay is needed after 3packet?).

So, we considered it in our code and implemented it. Now issue got resolved. We struggled a lot to find out this and took 2 week of time. 

To verify that delay, we tested with different baud like 4800. Now it is taking 400msec after every 3 packet.

and for 14400baud it is taking ~150msec delay. 

I request you, Can you please let us know why the bootloader needs a delay after 3 packet? and

why the delay is changing based on the baud rate?

You can find the log file in the below link:

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

" Baudrate_9600.htm "

Because of this delay requirement some time its not working with 57600baud.

Please let us know the delay requirement.

Thanks ,

Basava.