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

[c.arndt]

Hi,

I am currently implementing the protocol for a serial DFU, following the instructions given here:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v14.2.0%2Flib_dfu_transport_serial.html&cp=4_0_0_3_5_2_3.

The general flow I implemented is:

Get MTU (0x07) --> Select Command Object (0x06 0x01) --> Create Command Object (0x01 0x01)  --> Write up to MTU bytes of data (0x08 XX .... XX) --> Execute Command (0x04)

Up to "Execute Command" everything seems to work perfectly fine. The problem is, I do not get any response on the execute command - neither a "Response Execute Success" nor any failure. 

Do you have any idea, what I am doing wrong here?

Thanks,

Christian

[lesher]

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

[c.arndt]

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)

[lesher]

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.)

[c.arndt]

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?

[lesher]

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

[c.arndt]

lesher said:

or the init packet sent does not match the .dat file contents

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)

[c.arndt]

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?

[lesher]

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.

[c.arndt]

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!