后台是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?

[Vidar Berg]

Hello,

I posted multiple versions of that project in that thread you linked to, please make sure you're using the most recent one (nRF_SDK_15.3.0_background_dfu_3.zip).  The log indicates that the rsp_send() function in the uart transport is returning with an error. Are you able to debug the project and find out what the error code is? Also, are you testing this on a nRF52840 DK or a custom board? 

Best regards,

Vidar

[Mechanical lady]

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?

[Vidar Berg]

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?

[Mechanical lady]

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.

[Vidar Berg]

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?

[Mechanical lady]

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.

[Vidar Berg]

Hello,

It looks like you are getting a UART Framing error. In this case, it is likely caused by the UART receive buffers overflowing.The DFU transport implementation is designed to be used with HW flow control. You can try to set the packet receipt notification to 1 (nrfutil ... -prn 1). to see if it is enough to avoid the framing errors. If not, you may need to lower the baudrate.

[Mechanical lady]

Hello, I apologize for taking up your time. I have tried all the methods you suggested, but still got the same error message of buffer overflow. I also tried lowering the baud rate to 9600, but it didn't work either. Even when I directly transmitted one character with the serial port debugging to the upper computer, it still reported an error. Could you please tell me if there are any other back-end DF sample projects verified on the 52840 non-DK board? If not, I plan to try the Jlink simulation on the weekend to see the specific problem.