• State Verified Answer
  • Replies 4 replies
  • Subscribers 74 subscribers
  • Views 1062 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 253273
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU OTA 52832 error (SELECT command) - works only when running debug version and RTT channel open

Harry

I port the DFU OTA bootloader from 52840 to 52832. It is using:

  • SDK v15.3.0
  • SoftDevice S132 v6.1.1
  • nrfUtil v5.0.0 to generate the zip package.

It is running on custom board. On PC side, I use nRFConnect for Desktop v3.4.1 with 52840 DK board.

I made all necessary changes to port it to 52832 (replaced the crypto to micro_ecc, updated sdk_config.h, added libraries, etc.). It works fine on 52840, however, I got this error on 52832.

It connects and started sending, and then the error occurred during the first "EXECUTE" command.

First, I got EXECUTE error, INVALID_OBJECT. Then I implemented the suggestion here: https://devzone.nordicsemi.com/f/nordic-q-a/51088/dfu-execute-code-4-failed-result-code-5

I still got the same EXECUTE error, but now it's because of different cause - Insufficient Resources.

Found the issue with the spread out of the hex file (gap in the middle). It's fixed now.

Now, I got this SELECT error.

DFU failed with error: When writing 'SELECT' command to Control Point Characteristic of DFU Target: Could not write SELECT command: Device disconnected.

2020-07-17T21:24:48.787Z DEBUG GATTC_EVT_WRITE_RSP time:2020-07-17T21:24:48.788Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:15 writeOp:1 offset:0 len:0
2020-07-17T21:24:48.787Z INFO Attribute value changed, handle: 0x0F, value (0x): 04
2020-07-17T21:24:48.929Z DEBUG   901/ 0 <-  [02 39 00 00 00 00 00 00 00 0f 00 01 03 00 60 04 01 ] type:     VENDOR_SPECIFIC reliable:yes seq#:4 ack#:3 payload_length:11 data_integrity:1 header_checksum:5 err_code:0x0
2020-07-17T21:24:48.929Z DEBUG      904 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:5 payload_length:0 data_integrity:0 err_code:0x0
2020-07-17T21:24:48.930Z DEBUG GATTC_EVT_HVX time:2020-07-17T21:24:48.930Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:15 type:1 len:3
2020-07-17T21:24:48.930Z INFO Attribute value changed, handle: 0x0F, value (0x): 60-04-01
2020-07-17T21:24:48.944Z DEBUG      905 ->  [00 9c 00 00 01 01 00 0f 00 00 00 02 00 01 06 02 ] type:     VENDOR_SPECIFIC reliable:yes seq#:3 ack#:5 payload_length:10 data_integrity:1 header_checksum:6 err_code:0x0
2020-07-17T21:24:48.976Z DEBUG   902/ 0 <-  [N/A] type:                 ACK reliable: no seq#:0 ack#:4 payload_length:0 data_integrity:0 err_code:0x0
2020-07-17T21:24:48.976Z DEBUG   903/ 0 <-  [01 9c 00 00 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:5 ack#:4 payload_length:6 data_integrity:1 header_checksum:ad err_code:0x0
2020-07-17T21:24:48.977Z DEBUG      906 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:6 payload_length:0 data_integrity:0 err_code:0x0
2020-07-17T21:24:54.974Z DEBUG   904/ 0 <-  [02 11 00 00 00 08 ] type:     VENDOR_SPECIFIC reliable:yes seq#:6 ack#:4 payload_length:6 data_integrity:1 header_checksum:ac err_code:0x0
2020-07-17T21:24:54.974Z DEBUG      907 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:7 payload_length:0 data_integrity:0 err_code:0x0
2020-07-17T21:24:54.974Z DEBUG GAP_EVT_DISCONNECTED time:2020-07-17T21:24:54.975Z connHandle:0 reason:8 reasonName:connectionTimeout
2020-07-17T21:24:54.974Z DEBUG Destroying DFU transport.
2020-07-17T21:24:54.974Z ERROR DFU failed with error: When writing 'SELECT' command to Control Point Characteristic of DFU Target: Could not write SELECT command: Device disconnected.

Update:

I found that I can make it work if I load debug build (running independently), and connect J-Link to the board to open RTT channel (via J-Link RTT Viewer).

Any idea? Is it the debug log level? Or something is waiting for RTT channel to open?

Weird thing is, this very same source code runs fine on 52840 custom board.

Parents
  • 0

    Hi Harry, 
    From the log I can see that the DFU target would have an assert and stopped working. It's the reason why you get connection timeout before the "Could not write SELECT command: Device disconnected." log. 

    But I'm not sure why you need to port the code for nRF52840 to nRF52832 ? Wouldn't it work if you just use the bootloader made for nRF52832 that we provided ? Or you have any modification to the bootloader ? Even in that case I would suggest you to start with the bootloader we provided for nRF52832 and then add your modification in. 

  • +1 in reply to Hung Bui

    Hi Hung,

    Regarding the porting, it's because I need to port the existing Bootloader (for nRF52840 product) to a different product, and this "new" product is running on nRF52832 (perhaps to different platform in the near future).

    You're right, I have some modification to the bootloader, not in the bootloader SDK itself, but there is a thin layer on top of it (HW initialization, etc) because it runs on custom board. I am not aware of any modification in the bootloader SDK library part, other than the start address and bootloader settings location.

    Ok, I will try to compare to ensure there is no "bizarre" change that I missed.

    It's just baffled me why would it runs fine when I opened the RTT channel, or when I run it from debugger. Do you think it stopped working due to hard-fault situation?

    UPDATE: I got it work. I found that I forgot to update the MBR PARAM address. It used 52840 address. Btw, I thought MBR Param is written only on Bootloader update.

Reply
  • +1 in reply to Hung Bui

    Hi Hung,

    Regarding the porting, it's because I need to port the existing Bootloader (for nRF52840 product) to a different product, and this "new" product is running on nRF52832 (perhaps to different platform in the near future).

    You're right, I have some modification to the bootloader, not in the bootloader SDK itself, but there is a thin layer on top of it (HW initialization, etc) because it runs on custom board. I am not aware of any modification in the bootloader SDK library part, other than the start address and bootloader settings location.

    Ok, I will try to compare to ensure there is no "bizarre" change that I missed.

    It's just baffled me why would it runs fine when I opened the RTT channel, or when I run it from debugger. Do you think it stopped working due to hard-fault situation?

    UPDATE: I got it work. I found that I forgot to update the MBR PARAM address. It used 52840 address. Btw, I thought MBR Param is written only on Bootloader update.

Children
Related
Terms of service