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)

[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!