Uart DFU failed

[ClarkChu]

Hi 

I have a project as the follow 

What I have done:

1. Compiled app.hex ( Configured with my board), works fine.

2. Compiled bootloader.hex ( Configured with my board)

3. Generate app_setting with nrfUtil

4. Merge app, app_setting, bootloader and flash to target board

5. Compile app again, and generate zip file with nrfutil.

6. Convert zip file to bin file and upload to web. (xxx.yyy.zzz/app_2_dfu.bin)

7. nRF9160 download app_2_dfu.bin successfully and ready to do DFU

But it failed. Please see the bellow picture

I understand the payload between DFU host(here is nRF91) and target(here is nRF52810)

First, host ping target and get response

Then, send command to target to enter bootloader

Then, wait a moment, host ping target to make sure target is bootloader mode

and then ..... it seem everything is OK,

But, when host send operation 0x03, which means to get CRC check, but the target don't have any response. 

I looked into the source code, if there is error, target should send error code back to host. But unfortunately, nothing, just like the target didn't receive 0x03.

Further, I changed both side hardware flow control ON and OFF, both don't work.

I set breakpoints for all NRF_DFU_OP_CRC_GET in bootloader. But none of them executed.

I set breakpoints for such as NRF_DFU_OP_OBJECT_CREATE in bootloader, it can stop at the breakpoint as expected.

Please help me.

[Einar Thorsrud]

Hi,

Nordic does not provide any DFU master implementation for running on a nRF device, so I am not sure what you are using here.

Can you elaborate on which bootloader you use on the nRF52 device (based on what you write I assume it is a nRF5 SDK based)? And then, can you share details about your DFU master implementation and how you test it?  Please elaborate.

[ClarkChu]

Thanks!

I am using nRF5SDK160098a08e2\examples\dfu\secure_bootloader\pca10040e_uart as the code base, and modified the UART pin config

//UART

#define RX_PIN_NUMBER       16

#define TX_PIN_NUMBER       18

#define CTS_PIN_NUMBER      17

#define RTS_PIN_NUMBER      15

#define HWFC                true

And finally I can send data to 52810 with 10 ms delay for every packet. I think HWFC should do this job. But seems that HWFC didn't work. But anyway, with 10 ms delay, data can be sent.

I searched devzone several days ago, it says that bootloader write flash has error. But I try to search again, and can not find it any more. ( I think I forget the search key word) 

I will look into the bootloader's flash part. If you can provide some guide or information where should I begin, it will help me a lot. 

The DFU master implementation (9160 side) is provide by Nordic China support team, and it just download the file and send the bin to 52810 according to DFU payload.

[Einar Thorsrud]

Hi,

ClarkChu said:

And finally I can send data to 52810 with 10 ms delay for every packet. I think HWFC should do this job. But seems that HWFC didn't work. But anyway, with 10 ms delay, data can be sent.

So the DFU process is successful if you use a 10 ms delay for every packet? If so, this looks like a known issue if data is provided too fast. Adjusting the packet receipt notification (PRN) is one way of handling that, where the DFU target can limit the pace of the incoming data (this is at a higher level in the protocol than simply using UART flow control). I suggest try setting PRN to 1.

If setting PRN to 1 does not work, perhaps it is worth testing a debug bootloader with RTT logging and see if that provides some useful information.

I have not seen this DFU master implementation myself, perhaps you can share it or send me a PM with who in Nordic you got it from?

[ClarkChu]

It's a good idea to enable logging in bootloader. But I encounter a problem. When I enable log by "NRF_LOG_ENABLED 1" in sdk_config.h I got error "section .mbr_params_page VMA [000000000002e000,000000000002efff] overlaps section .text VMA [00000000000283d4,000000000002e03f]"

Seems that the image size is too big when enable log. How can I only enable minimum necessary so that image size is not so big?

 

While in my previous post, I think I make an unclear statement.

dfu.bin file size is 54K. Selecting Object size is 4096. So the file is divided into (54K/4096) objects.

the first 4096bytes was sent successfully. Then request to create 2nd object, there is no response.

And finally I can send data to 52810 with 10 ms delay for every packet.

means that the 4096 bytes is divided into (mtu-1)/2-1 packets. (here mtu is 131). So there are 64 packets. These 64 packets were sent successfully. Not mean the whole file sent successfully.

When the first 4096 bytes is sent dfu master receive "60 03 01 xx xx ...." means CRC is OK. Then dfu master send object select and again target response "60 04 01", it's OK. Then dfu master send object create, there is no response any more.

I add the dfu master code for your reference. Thank you very much!91_cross_dfu.zip

182.92.8.154/yy_app_0012_dfu.bin is valid. you can use it directly for test.

[ClarkChu]

Hi,

I looked into the bootloader source code, find that when create new data object, the flash should be erased. But actually, the flash keep unchanged even target response with 01 01 (create object success) and 04 01(execute success).

How do I know that the flash page is not erased?

I restart the system by power off power on, I can still find the BLE and connect it and do some operations. If the application page is erased, how the application can work normal?

Further more, I switch on the single bank dfu feature in sdk_config, it return 04 04 error code, mean that there is no enough memory. I don't understand, if single bank dfu feature is enabled , it should replace the current application, why it says not enough memory?

[ClarkChu]

Hi Einar

Thank you very much for your support. I have resolved this issue.

The root cause is my app size is two big.

But why 52810 don't response the error code 0x04 which means that memory is not enough.