nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

c.arndt — Tue, 22 May 2018 09:43:40 GMT

I figured out it was some watchdog issue, this is fixed now. So far there is no open point and everything seems fine now.

Thank you for your support!

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

lesher — Wed, 16 May 2018 17:45:07 GMT

I would look at the RTT log from the bootloader. If the flash queue is overflowing, you may need to increase NRF_DFU_<something>_BUFFERS.

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

c.arndt — Wed, 16 May 2018 11:53:44 GMT

After further research I noticed that the UART might be busy and not transmit all data so I added a delay. This showed some progress but after 20kB the transmission stops with a reset.

Any idea why?

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

c.arndt — Tue, 15 May 2018 11:53:54 GMT

[quote userid="6410" url="~/f/nordic-q-a/33852/nrf52832-serial-dfu---transfer-init-packet---no-response-after-execute-command/130894"]or the init packet sent does not match the .dat file contents[/quote]

That was exactly the issue. The bytes which I transmitted were not 100% the same compared to what actually is inside the .dat file. This happened due to some ASCII-HEX conversion issue.

Fixing this I could make some progress - the init packet can now be transmitted successfully.

Now I actually run into some issues with the actual firmware .bin-file. The test FW I intend to transmit is some 71 kB in size. The maximum object size is 4 kB -> so I need to create 18 objects. After every object I want to calculcate the CRC, but when sending CRC (0x03) after the first object was transmitted, I do not get any reply from nRF.

Could that again be an indication, that the previous 4kB object was not transmitted properly (e.g. wrong content)? Or am I calling "CRC" at the wrong point of time? (i do not use PRN)

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

lesher — Mon, 07 May 2018 21:38:43 GMT

That looks ok. I learned the most from the code Nordic publishes for a serial DFU controller: github.com/.../dfu_transport_serial.py

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

c.arndt — Fri, 04 May 2018 09:33:20 GMT

Okay with the keys everything should be fine for now. I will follow the lead of improper data from init packet.

As far as I understood I need to transfer the data from init packet in the following format:
0x08 0xXX 0xXX .... 0xXX (depending on MTU/2)

Lets assume I have an init packet of 10 bytes and max transmission payload size is 4 bytes. Then this is how it is currently going:

uint8_t Init_Packet [10] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x10}

Transmitting first 4 Bytes of Init Packet (slip encoded not showed here):
--> 0x08 0x01 0x02 0x03 0x04
--> tx[0] = 0x08
--> tx[1] = 0x01
--> tx[2] = 0x02
.
--> tx[4] = 0x04

Same way transmitting second 4 Bytes of Init Packet (slip encoded not showed here):
--> 0x08 0x05, 0x06, 0x07, 0x08

Same way transmitting last 2 Bytes of Init Packet (slip encoded not showed here):
--> 0x08 0x09 0x10

Could here be the mistake?

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

lesher — Thu, 03 May 2018 21:44:29 GMT

I only started using RTT once SES became available. Before that, I'd redirect bootloader logs to UART. RTT Viewer was just too tricky to use with multiple jlinks and multiple gcc debuggers happening.

That log tells me that either the private key used during "nrfutil pkg generate" does not match the public key built in to the bootloader - or the init packet sent does not match the .dat file contents.

Search the SDK for "Invalid signature type". (It's in nrf_dfu_validation.c.)

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

c.arndt — Wed, 02 May 2018 16:18:48 GMT

Okay I got some RTT logs:

<debug> app: Received get serial mtu
<debug> app: Sending Response: [0x7, 0x1]
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> app: Received get serial mtu
<debug> app: Sending Response: [0x7, 0x1]
<debug> app: Waiting for events
<debug> app: Received select object
<info> dfu_req_handling: Valid Command: NRF_DFU_OBJECT_OP_SELECT
<debug> app: Sending Response: [0x6, 0x1]
<debug> app: Received create object
<info> dfu_req_handling: Before OP create command
<info> dfu_req_handling: Valid Command Create
<debug> app: Sending Response: [0x1, 0x1]
<info> dfu_req_handling: Before OP write command
<info> dfu_req_handling: Before OP write command
<info> dfu_req_handling: Before OP write command
<debug> app: Received execute object
<info> dfu_req_handling: Before OP execute command
<info> dfu_req_handling: Valid command execute
<info> dfu_req_handling: PB: Init packet data len: 58
<info> dfu_req_handling: Handling signed command
<info> dfu_req_handling: Invalid signature type
<error> dfu_req_handling: Prevalidate failed!
<debug> app: Sending Response: [0x4, 0xB]
<debug> app: Received execute object
<info> dfu_req_handling: Before OP execute command
<info> dfu_req_handling: Valid command execute
<info> dfu_req_handling: PB: Init packet data len: 58
<info> dfu_req_handling: Handling signed command
<info> dfu_req_handling: Invalid signature type
<error> dfu_req_handling: Prevalidate failed!
<debug> app: Sending Response: [0x4, 0xB]

What do they tell you?

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

c.arndt — Wed, 02 May 2018 15:58:40 GMT

Actually I was trying some time to get RTT logs.. unfortunately after starting Segger RTT Logger I only get a screen saying "Searching for RTT Control Block"..

Any idea how I can enable RTT logging?

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

lesher — Fri, 27 Apr 2018 14:38:14 GMT

For Create Command Object, use the non-slip-encoded size.
The best way to see what's happening is to see the bootloader's logs - RTT is built in to the examples.

Also, refer to this file for the host-side details: github.com/.../dfu_transport_serial.py

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

c.arndt — Fri, 27 Apr 2018 13:13:47 GMT

Okay I got some new information:

It was a good hint to ask whether really all bytes are transmitted via "Write" command.

I changed the interpretation of "Get MTU" response into little endian --> 0x00 0x81 --> resulting in 129 Bytes (before I interpreted as 0x81 0x00 --> 32k).

With "Create Command Object" I actually reserve the space I need for the .dat file (which is 135 Bytes). Is that enough or do I need to reserve space for the whole slip encoded message (in this case 141 bytes)?

However, I tried with creating 141 Bytes command object and now I do receive response for "Execute" command:

DFU ERROR OPCODE <0x4 0x8> OPERATION_NOT_PERMITTED

Now the question is, why is this operation not permitted?

(when I tried with creating 135 Bytes command object, again I do not receive any response after execute command)

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

c.arndt — Fri, 27 Apr 2018 07:08:52 GMT

Yes I do, I have a .dat file of size 135 Bytes. Wrapping it with "Write ID (0x08)" + Slip encoding I have a total size of 138 Bytes which I am transmitting via UART to nRF.

As far as I could see I have max MTU size of 33024 Bytes (is it possible that I am exchanging big endian with little endian?). However, even half of the MTU size means I can transfer .dat file completely at once.

Might here be some issue?

RE: nRF52832 Serial DFU - Transfer Init Packet - No Response after "Execute Command"

lesher — Thu, 26 Apr 2018 21:51:45 GMT

Are you sending ALL of the .dat file Bytes before calling Execute?