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

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

Vidar Berg — Thu, 07 Feb 2019 10:05:26 GMT

Hi Basava,

I'm a bit surprised that you need a longer delay when lowering the baudrate, I would have expected the opposite. Did you try to debug the bootloader to see what was causing the hardfault? The hardfault handling library can help you to trace back to the source of the fault. Also, do you have a way to monitor the transactions between the host and nrf52 to see if the data is transferred correctly?

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

Goudra — Wed, 06 Feb 2019 20:00:25 GMT

Hi,

Is there any suggestions on this?

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

Goudra — Fri, 01 Feb 2019 14:56:13 GMT

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.

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

Vidar Berg — Tue, 29 Jan 2019 07:23:06 GMT

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.

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

Goudra — Tue, 29 Jan 2019 05:07:39 GMT

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.

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

Vidar Berg — Mon, 28 Jan 2019 14:15:17 GMT

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.

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

Goudra — Fri, 25 Jan 2019 16:19:18 GMT

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

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

Vidar Berg — Fri, 25 Jan 2019 07:57:43 GMT

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.

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

Goudra — Thu, 24 Jan 2019 17:55:27 GMT

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.

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

Vidar Berg — Thu, 24 Jan 2019 13:55:05 GMT

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

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

Vidar Berg — Thu, 24 Jan 2019 13:55:03 GMT

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>

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