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

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.

[Vidar Berg]

No, it is just that it has only been tested with HW flow control enabled. Since you keep getting UART com. errors even after lowering the baudrate and enabling packet receipt notification for every packet, I'm afraid you have to make larger changes to the UART transport to be achieve reliable reception. For instance, you may consider changing the implementation to using the Libuarte - advanced  UARTE driver. This will allow you to utilize larger DMA buffers.

[Mechanical lady]

Hello, Vidar Berg，thank you for taking the time to reply. I have been studying nrfutil recently and have changed the serial port channel to TCP because my ultimate goal is to be able to OTA (Over-The-Air) update 52840 products in different places in large batches through a remote server. The main purpose of the background DFU is not to modify the bootloader. Of course, I have been trying but failed. However, it is possible to use non-background DFU (after all, it works). Regarding your suggestion of changing uart to uarte, I will try to modify it to provide a larger buffer.