• State Not Answered
  • Replies 11 replies
  • Subscribers 71 subscribers
  • Views 220 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 340755
Options

后台是DFU

Mechanical lady

Hello, my current project needs to use back-desktop DFU. I will query related resources and back-end DFU. Found only in the devzone.nordicsemi.com/.../background-dfu-application-source-code about the background DFU corresponds with my needs, But this backbench DFU example project is based on ses, my project SDK is developed in keil, now want to test SES DFU example is working, but when I test the example project nRF_SDK_15.3.0_background_dfu.zip, nrf52840 received the data from the serial port, but it failed to send. What is the reason?

Hello, my current project needs to use back-desktop DFU. I will query related resources and back-end DFU. Found only in the devzone.nordicsemi.com/.../background-dfu-application-source-code about the background DFU corresponds with my needs, But this backbench DFU example project is based on ses, my project SDK is developed in keil, now want to test SES DFU example is working, but when I test the example project nRF_SDK_15.3.0_background_dfu.zip, nrf52840 received the data from the serial port, but it failed to send. What is the reason?
Parents Reply Children
  • 0 in reply to Vidar Berg

    Yes, it has been repeatedly confirmed that the latest version (nRF_SDK_15.3.0_background_dfu_3.zip) was used.
    The error code returned by rsp_send() is 17.
    It was not tested on the DK or custom board. Instead, the nrf52840 module provided by the supplier was used. Are there any differences?

  • 0 in reply to Mechanical lady

    Thanks for confirming. So the UART transport is returning NRF_ERROR_BUSY (17) when trying to send the command response back to the DFU controller. Maybe it is a UART HW flow control problem. Do you have the UART CTS and RTS pins connected on your board? Also, do you have a USB - UART bridge on your board?

  • 0 in reply to Vidar Berg

    The CTS and RTS signals were not connected on the board, and even tried to disable hardware flow control, but still failed.
    There was no USB-UART bridge connected on the board either.
    This nrf52840 module on my hand attempted to use non-background serial DFU for serial port communication, and it was successful.
    I tried to return the received data through rsp_send() to the serial port debugging host in the uart_event_handler, but the same busy error was reported.

  • 0 in reply to Mechanical lady

    DFU is the only task when you DFU within the bootloader, but when you do background DFU there will also be other tasks requiring CPU resources which may potentially slow down the DFU process. Did you disable flow control in the uart_dfu_transport_init() function?

  • 0 in reply to Vidar Berg

    Hello, currently I am disabling the hardware control in uart_dfu_transport_init and there is no more error reporting of sending busy. However, during the DFU ping process, it reports DFU failure (NRF_DFU_EVT_DFU_FAILED).
    I also attempted the following operation to return the received data to the debugging host computer, but the serial port reported communication error (NRF_ERROR_NO_MEM). static void uart_event_handler(nrf_drv_uart_event_t * p_event, void * p_context)
    {
    switch (p_event->type)
    {
    case NRF_DRV_UART_EVT_RX_DONE:
    //on_rx_complete((nrf_dfu_serial_t*)p_context,
    // p_event->data.rxtx.p_data,
    // p_event->data.rxtx.bytes);
    NRF_LOG_HEXDUMP_INFO(p_event->data.rxtx.p_data, p_event->data.rxtx.bytes);
    rsp_send(p_event->data.rxtx.p_data, p_event->data.rxtx.bytes);
    break;


    case NRF_DRV_UART_EVT_ERROR:
    APP_ERROR_HANDLER(p_event->data.error.error_mask);
    break;


    default:
    // No action.
    break;
    }
    }

    This project is using the latest engineering design you replied to above. No modifications have been made to it.




Related
Terms of service