Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents Reply Children
  • 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?

  • 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?

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

  • 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?

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

Related