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
  • Are you sending ALL of the .dat file Bytes before calling Execute?

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

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

Children
  • For Create Command Object, use the non-slip-encoded size.
    The best way to see what's happening is to see the bootloader's logs - RTT is built in to the examples.

    Also, refer to this file for the host-side details: github.com/.../dfu_transport_serial.py

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

Related