• State Verified Answer
  • Replies 3 replies
  • Subscribers 90 subscribers
  • Views 666 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 284112
Options

DPU Packet information

Randy Lee

Using nRF52840 and SDK15.3

I'm seeing some documentation on the DFU process and all that but I'm having to write my own bootloader transport (and lower) layer to implement grabbing the contents of the zip file from QSPI instead of say a serial port.  I figure the best way to approach that is to replace said serial port transport layers and simulate talking to some master device to the upper layers.

What I'm not seeing is the deeper documentation and I'd need a couple of things if they exist:

1) the actual packet layout of the DFU packets that are being sent over say serial likes (without the SLIP encoding).... I see the page with the opcodes listed but I'm not finding anything that says where that is in the packet or what else (and where it lives byte, by byte) is in the packet itself (presumably sizes and that kind of thing) by opcode.

2) the state machine around the opcodes... Presumably there is some sort of handshake order for most of these (although it looks like several can happen at any time).

Thanx

Parents
  • +1

    I found some valuable information on this at https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.0/lib_dfu_transport_ble.html which is assuming a BLE transfer but that uses the same upper code so this is usable, I think for what the handshake is about and what to expect in what order from it...  There is one minor bug in the documentation in the response to the data packet being the wrong number but otherwise this is good documentation..

    Some important notes that took me a bit to realize:

    • Most of the XXXXX things in there are 32bit values and are in LSB-MSB order. Use uint32_encode() to properly encode those.
    • The NRF_DFU_OP_OBJECT_EXECUTE packet wants the argument in 16 bits so use uint16_encode() for that one
    • The init packet is pretty simple: create an object of it's size (it's always small), fill it and execute.
    • The App is much bigger so you have to create objects of the size of the FLASH pages (4K in the 52840), fill them and execute them as you go until you reach the last one, then create that one in the remaining size, fill and execute it.
Reply
  • +1

    I found some valuable information on this at https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.0/lib_dfu_transport_ble.html which is assuming a BLE transfer but that uses the same upper code so this is usable, I think for what the handshake is about and what to expect in what order from it...  There is one minor bug in the documentation in the response to the data packet being the wrong number but otherwise this is good documentation..

    Some important notes that took me a bit to realize:

    • Most of the XXXXX things in there are 32bit values and are in LSB-MSB order. Use uint32_encode() to properly encode those.
    • The NRF_DFU_OP_OBJECT_EXECUTE packet wants the argument in 16 bits so use uint16_encode() for that one
    • The init packet is pretty simple: create an object of it's size (it's always small), fill it and execute.
    • The App is much bigger so you have to create objects of the size of the FLASH pages (4K in the 52840), fill them and execute them as you go until you reach the last one, then create that one in the remaining size, fill and execute it.
Children
No Data
Related
Terms of service