need DFU description explanations

[amicus]

Hello,

I'm started implementing DFU over serial port and see documentation from this link:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v14.2.0%2Flib_dfu_transport_serial.html

And for me is misunderstanding about little and big endian in your descriptions. In examples I see is big endian format (PRN number is 02 01 00 - it means 256) but in description is mentioned little endian format ("Value (uint16, little endian) "). What I should believe? Example or description?

Same situation is with MTU message, where is the true?

And other think if in other messages not mentioned little endian format it does it mean that it is in big endian format?

Then how it understand that some messages value (Create and PRN) fields is in little endian format and another  all messages is in big endian format?

It does it mean that  DFU protocol mixing endian between messages?

Wait for comments!

FW developer

Remigijus

[ivansanchez]

What I should believe? Example or description?

I suggest you base your implementation in the already existing reference implementation: pc-nrfutil. See https://github.com/NordicSemiconductor/pc-nrfutil/tree/master/nordicsemi/dfu

In examples I see is big endian format (PRN number is 02 01 00 - it means 256) but in description is mentioned little endian format ("Value (uint16, little endian) ")

That example is wrong, in fact. A PRN value 0x0100 means decimal 1, not decimal 256.

Refer to https://github.com/NordicSemiconductor/pc-nrfutil/blob/7f20bb89b1df082990c94bc58ceb26393fe52341/nordicsemi/dfu/dfu_transport_serial.py#L299, it looks like:

    def __set_prn(self):
        self.dfu_adapter.send_message([DfuTransportSerial.OP_CODE['SetPRN']]
        + map(ord, struct.pack('<H', self.prn)))

If you check https://docs.python.org/2/library/struct.html#byte-order-size-and-alignment , you'll see that 

struct.pack('<H', self.prn)

 means that PRN is a little-endian unsigned short (16-bit) integer. The same goes for all other fields involved in the DFU procedure, you'll find similar struct.pack() calls.

If I remember correctly, some of the metadata (in particular the crc32 hashes and sha256 hashes) might be in big-endian due to libraries used to calculate those values. Please be aware that you should check those separately.

[amicus]

I think it's a logical to have all value field in one (little endian) format. But of cause another talk when we talk about CRC field.

Thank You, for fast help!

[amicus]

I have one additional question according DFU start packets sending. I've found something strange. COuld You explain me please what's happen?

I'm trying to send:
nrfutil dfu serial -pkg d:\nRF5_SDK_14.2.0_17b948a\examples\dfu\secure_dfu_test_images\serial\nrf52832\ble_app_buttonless_dfu_without_bonds_s132.zip -p COM14

and sniffing on serial port and found hexadeciomal bytes:
C0 D1 4E 01 E0 03 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 FC 9D 00 00 7C 45 C0

I read DFU documentation from here:
infocenter.nordicsemi.com/index.jsp

I don't found 0xD1 in second byte and other bytes. What does it mean this hexadecimal bytes?
C0 in begining and end is SLIP protocol markers this point I understand bytes what means other bytes I totaly not understand.

Maybe I in wrong way and don't understand main DFU things..

Wait for comments!

[ivansanchez]

Please do not ask a new question in a reply. It's better to open a new question, and remember to explain as best as possible where those bytes appear, and when (what DFU commands have been sent before?).

[Somesh Burkule]

ivansanchez said:

That example is wrong, in fact. A PRN value 0x0100 means decimal 1, not decimal 256

Please confirm.  the following image shows its decimal 256.