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

[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.

[Vidar Berg]

Hello,

Are you getting the NRF_DRV_UART_EVT_ERROR even if you enable the packet receipt notification and lower the baudrate to 9600?

Mechanical lady said:

I also tried lowering the baud rate to 9600,

Just to confirm, you changed the baudrate both in the terminal and in the FW?

Mechanical lady said:

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.

I think the relevant difference here is that you are using a different UART USB bridge without the HW flow control. 

[Mechanical lady]

Hello

Vidar Berg said:

Are you getting the NRF_DRV_UART_EVT_ERROR even if you enable the packet receipt notification and lower the baudrate to 9600?

Yes, even if I enable the packet notification and set the baud rate to 9600, I still receive NRF_DRV_UART_EVT_ERROR and throw [NRF_ERROR_NO_MEM].

Vidar Berg said:

Just to confirm, you changed the baudrate both in the terminal and in the FW?

Yes, change the baud rate in both the terminal and the FW at the same time.

In my project, there is no hardware flow control pin introduced. It's just a simple connection of serial port RX and TX.

[Mechanical lady]

Is it only the 52840 DK with the UART bridge that is supported? Ordinary 52840 SoC does not support it.