Uart DFU failed

RE: Uart DFU failed

ClarkChu — Fri, 17 Dec 2021 05:00:40 GMT

Thanks! I will check that.

RE: Uart DFU failed

Einar Thorsrud — Fri, 10 Dec 2021 13:21:35 GMT

Hi,

[quote user="ClarkChu"]As far as I know, My app size should have 60K - 8K(reserved app data size) = 52K space available. Am I right?[/quote]

We need to look at your memory layout to know this:

What is the start address of the application (that will be the same as the size of the SoftDevice)?
And what is the start address of the bootloader?
How many reserved bytes do you have in the bootloader, configured with NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h? This typically should match whatever is configured for persistent data in the application.

[quote user="ClarkChu"]How can I know exactly how many bytes space for my application? Or there is other reason that I don't know?[/quote]

By finding the numbers I listed above we can know exactly how much space there is for the application, and can visualize the memory layout as is done in the bootloader documentation.

RE: Uart DFU failed

ClarkChu — Fri, 10 Dec 2021 10:58:27 GMT

Hi Einar

I am afraid I have to re-open this ticket.

When I reduce the dfu.bin file size to 43K, it can upgrade successfully. But when I did some development for couple weeks, the dfu.bin file size become as 45K. Then the upgrade failed.

I am confused.

If the dfu.bin file size is 54K or larger, bootloader will return 0x0B0D error code. which means

NRF_DFU_EXT_ERROR_INSUFFICIENT_SPACE = 0x0D, /**< The available space on the device is insufficient to hold the firmware. */

I can know clearly that the file size if too big.

But if the dfu.bin file size is 45K, it doesn't return any error code, just start to DFU, and when the firmware packets are sent

about 35K, it time out. i.e. DFU host can not receive response from nrf52810 any more.

When I reduce the dfu.bin file to 43K. It can upgrade successfully.

As far as I know, My app size should have 60K - 8K(reserved app data size) = 52K space available. Am I right?

How can I know exactly how many bytes space for my application? Or there is other reason that I don't know?

Thank you very much!

RE: Uart DFU failed

ClarkChu — Wed, 24 Nov 2021 07:35:13 GMT

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.

RE: Uart DFU failed

ClarkChu — Wed, 24 Nov 2021 02:11:19 GMT

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?

RE: Uart DFU failed

ClarkChu — Tue, 23 Nov 2021 11:08:01 GMT

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!devzone.nordicsemi.com/.../91_5F00_cross_5F00_dfu.zip

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

RE: Uart DFU failed

Einar Thorsrud — Tue, 23 Nov 2021 09:38:58 GMT

Hi,

[quote user="ClarkChu"]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.[/quote]

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?

RE: Uart DFU failed

ClarkChu — Tue, 23 Nov 2021 08:00:45 GMT

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.

RE: Uart DFU failed

Einar Thorsrud — Mon, 22 Nov 2021 13:06:35 GMT

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.