OTA over serial failure| sdk 15.2

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Tue, 19 May 2020 06:24:27 GMT

Ok. I'll try with reducing size.

[quote userid="26071" url="~/f/nordic-q-a/55089/ota-over-serial-failure-sdk-15-2/249103"]It works independently, but you don't want to do DFU over Serial and BLE at the same time. If you start with serial, then you finish that DFU with Serial. Don't to BLE simultaneously. But it is possible to support both protocols.[/quote]

Nice.

Thanks for your support.

I'm closing this now.

RE: OTA over serial failure| sdk 15.2

Edvin — Mon, 11 May 2020 08:01:45 GMT

Make sure to decide whether you want to go down this way as well, and maybe it is easier to create a new ticket? This is no longer related to "OTA over serial failure", which the title reads on this ticket.

[quote user="Somesh Burkule"]I am downloading dfu files from server. so if speed is slow ota will fail or I'll need to get file saved in 4Kb packets.[/quote]

Ok. Set it to 1kB then. Does it change the behavior? Do you run into any issues? I don't see why it shouldn't work, but I don't know what your bootloader project looks like, so perhaps you have made some changes that would affect this.

[quote user="Somesh Burkule"]does it work independently? or need some other setting while DFU over Serial or BLE? or need to only enter in boot mode?[/quote]

It works independently, but you don't want to do DFU over Serial and BLE at the same time. If you start with serial, then you finish that DFU with Serial. Don't to BLE simultaneously. But it is possible to support both protocols.

The only thing to keep in mind while using BLE is that your application must always use the same softdevice version as your bootloader uses. Because your bootloader needs to use the same SD api as the softdevice that is programmed. So if you update the softdevice version, you must update the bootloader as well.

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Sat, 09 May 2020 05:34:53 GMT

[quote userid="26071" url="~/f/nordic-q-a/55089/ota-over-serial-failure-sdk-15-2/248976"] Why?[/quote]

I am downloading dfu files from server. so if speed is slow ota will fail or I'll need to get file saved in 4Kb packets.

Is it possible 2048? any impact?

[quote userid="26071" url="~/f/nordic-q-a/55089/ota-over-serial-failure-sdk-15-2/248976"]It is possible.[/quote]

does it work independently? or need some other setting while DFU over Serial or BLE? or need to only enter in boot mode?

RE: OTA over serial failure| sdk 15.2

Edvin — Fri, 08 May 2020 13:29:36 GMT

NB: I manually changed the status of the ticket, so it will pop up when you write something again.

RE: OTA over serial failure| sdk 15.2

Edvin — Fri, 08 May 2020 13:29:03 GMT

Hello,

Sorry for the late reply. When a ticket has a verified answer, it falls out of the system, because the issue is solved.

[quote user="Somesh Burkule"]can we use this to 2048 or 1024?[/quote]

Why?

[quote user="Somesh Burkule"][/quote]

one more question... As I saw in sdkconfig of uart secure bootloader, there is option to use DFU over BLE.

Can we use single bootloader for DFU over Serial and BLE both?

It is possible. You have to add the other transport layer. It is usually done by just including the .c and .h files to the project, as the transport layers are registered through some macros from those. Then, from main() -> nrf_bootloader_init() -> nrf_dfu_init() -> nrf_dfu_transports_init() it will fetch the list of registered transport layers.

In the BLE bootloader, the BLE transport layer is included by the following define in nrf_dfu_ble.c:

DFU_TRANSPORT_REGISTER(nrf_dfu_transport_t const ble_dfu_transport) =
{
    .init_func  = ble_dfu_transport_init,
    .close_func = ble_dfu_transport_close,
};

And it is done similarly in the serial bootloader. Search for "DFU_TRANSPORT_REGISTER" in the project.

BR,

Edvin

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Fri, 08 May 2020 12:11:47 GMT

Awaiting your reply.

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Wed, 06 May 2020 16:40:41 GMT

Hello Edvin,

MAX_OBJECT_SIZE = 4096bytes.

If code size is 28kB. we send MAX_OBJECT_SIZE x 7 over serial.

can we use this to 2048 or 1024?

one more question... As I saw in sdkconfig of uart secure bootloader, there is option to use DFU over BLE.

Can we use single bootloader for DFU over Serial and BLE both?

RE: OTA over serial failure| sdk 15.2

Edvin — Wed, 06 May 2020 13:43:04 GMT

What parameter are you talking about, exactly? What is it called?

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Wed, 06 May 2020 13:03:56 GMT

Hi Edvin,

What is the minimum MBR size we can use for OTA?

I am using 4096 for now. I want to reduce it.

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Tue, 28 Apr 2020 13:55:48 GMT

Hi Edvin,

Resolved. actually I was checking third byte in response is 0x01 or not(04 01 01) for init packet. if not gives an error. As I removed this code and tried OTA again it gets successfull.

Thank you for your help.

RE: OTA over serial failure| sdk 15.2

Edvin — Tue, 03 Mar 2020 10:00:41 GMT

Can you check the logging information in your bootloader and see if you can determine why the packet is not executed? You probably need to use the pca10040_uart_debug project in order to activate logging.

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Tue, 03 Mar 2020 09:25:27 GMT

How to check init packet is present? is there any Command? and how to delete init packet?

Actually I am generating zip package and using app.bin and app.dat file for ota.

so app.bin -> application image

app.dat -> init packet

RE: OTA over serial failure| sdk 15.2

Edvin — Tue, 03 Mar 2020 09:12:10 GMT

If the init packet is already transmitted, you can start directly on the application image. Wouldn't that be a better approach?

You can probably delete the init packet as well, If you want that, the sequence on the bootloader would be:

startup -> check if the init packet is present -> check if a valid application is present -> delete the init packet if the application is invalid.

Exactly why it is rejected if it doesn't work on first try I am not sure.

Out of curiousity, is it an image containing bootloader or application?

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Tue, 03 Mar 2020 04:57:25 GMT

I think that is not the issue.

I have used 10ms of delay when sending packet.

As per my observation, nrf is not executing second init packet if first one is executed successfully and stored in flash. so that I was asking to erase flash in boot mode.

Is it correct?

RE: OTA over serial failure| sdk 15.2

Edvin — Mon, 02 Mar 2020 14:00:17 GMT

If you do not use HWFC then the issue may be that it doesn't have time to write the packets to flash with the speed you are sending them. Try to add some delay between each packet, and see if the issue remains. Alternatively, try to enable HWFC and see whether that may be the issue. If the nRF Has no way of holding back the UART packets, and they are received too fast, I am not sure how the bootloader would react.

BR,

Edvin

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Mon, 02 Mar 2020 12:16:34 GMT

Let me explain in briefly.

I first sent two files( Baud:115200, HWFC Disabled )

Init packet -> executes successfully

application file -> does not executes( I am downloading file from server then sending file to nrf through serially so if network failor occurs it fails)

then I send two files again( Baud:115200, HWFC Disabled )

Init packet -> does not executes

application file -> does not executes

RE: OTA over serial failure| sdk 15.2

Edvin — Mon, 02 Mar 2020 10:29:40 GMT

One way to reset the device is to call a systemreset from the sourcecode if the second init (application image) fails. Depending on whether you have a valid application or not you may have to set the correct reset register (the way that you set it to get it to run DFU mode instead of the application) in the first place.

The way this is typically done is to write to the NRF_POWER->GPREGRET register.

Please see how this register is checked in dfu_enter_check() in nrf_bootloader.c:

    if (NRF_BL_DFU_ENTER_METHOD_GPREGRET &&
       (nrf_power_gpregret_get() & BOOTLOADER_DFU_START))
    {
        NRF_LOG_DEBUG("DFU mode requested via GPREGRET.");
        return true;
    }

So this register has to be written before the reset (you can use bootloader_reset() to reset the bootloader).

But perhaps it would be more interresting to know why the execute command doesn't work? Do you use HWFC? At what rate are you sending the packets?

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Mon, 02 Mar 2020 09:43:24 GMT

Hi,

I have generated init packet.

I tried sending init packet and app file. that time init packet executes successfully but app file not due to some reason.now want to send again init packet and app file but init packet does not executes because it was done before. I need to execute this init packet from crash now again. is there any command to set bootloader to recieve init packet from crash again.

RE: OTA over serial failure| sdk 15.2

Edvin — Mon, 02 Mar 2020 09:32:06 GMT

Hello,

I am sorry. I didn't see this until now. When a message is marked as a "verified answer", it no longer pops up in the queue. Did you manage to generate the init packet?

Do you know why the init execute command fails? Where was it "done before"? I didn't understand that part.

Could the problem be that you don't use Flow Control on the UART? Or do you use flow control?

BR,
Edvin

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Mon, 02 Mar 2020 05:33:00 GMT

Hello,

Please help me for this as soon as possible.

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Wed, 26 Feb 2020 06:22:10 GMT

Hello Edvin,

I have a problem while upgrading firmware. I am upgrading firmware by sending init packet and then app file serially. In some condition init packet is sent successfull and executed using ( 0x04 ) command but while sending app file due to some reason not executed successfully and OTa over serial fails.

after that I tried again to do the same but init packet is not getting executed successfully becuase it was done before. so my question is, Is there any way to reset nrf bootloader so that after if ota fails then second time bootloader should start again( erase all files) from init packet.

Please help me to handle this.

Awaiting your quick response.

With warm regards,

Somesh Burkule

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Mon, 13 Jan 2020 05:07:34 GMT

Hello Edvin,

Thank you very much for your support. OTA over serial is sucessfull. ☺

The problem was in the init packet. I had used softdevice.dat file for init packet. I converted this file into hex by online hex converter. now I used application.dat file for the init packet and sent over serial and after that sent app file and OTA worked.

Can you please tell me how to make init packet. please share init packet structure. I checked nrfutil code but its quit confusing for me. I have sent following packet.

uint8_t init_packet1[] = {8, 10, 67, 8, 1, 18, 63, 8, 3, 16, 2, 26, 2, 175, 1, 32, 0, 40, 0, 48, 0, 56, 196, 93, 66, 36, 8, 3, 18, 32, 14, 112, 16, 50, 29, 176, 115, 77, 235, 99, 214, 61, 143, 198, 237, 176, 123, 34, 183, 203, 209, 236, 252, 234, 62, 106, 216, 241, 146, 51, 178, 154, 72, 0, 82};
uint32_t init_packet1_len = 65;
uint8_t init_packet2[] = {8, 4, 8, 1, 18, 0};
uint32_t init_packet2_len = 6;

Thanks a lot again!!

Regards,

Somesh

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Fri, 10 Jan 2020 08:54:48 GMT

Hi @Edvin,

As you said, by default this settings are enabled.

I have compiled the code in SES and flashed in DK board to check whether it is working or not.

I have opened RTT viewer and connected to board.

Now I want to start dfu using nrfutil. right? and I'll get backend logs on rtt viewer.

Please tell me how?

RE: OTA over serial failure| sdk 15.2

Edvin — Fri, 10 Jan 2020 08:23:23 GMT

In order to see the logs, you must download Segger RTT Viewer (link in an earlier reply). Then open up your bootloader project, open sdk_config.h, and change the define:

#define NRF_LOG_ENABLED 0
to
#define NRF_LOG_ENABLED 1

You can also change

#define NRF_LOG_DEFAULT_LOG_LEVEL 3
to
#define NRF_LOG_DEFAULT_LOG_LEVEL 4

to increase the amount of logging.

Now, if you don't change the default flash settings, the compiler will say something like there is not enough flash to fit the project in the chip, so change the flash start and size to ensure there is enough space for the logging module. Change it to something like the _debug bootloader project.

Then open RTT Viewer, and select the debugger that is connected to the nRF. You should see the log there.

If you still can't see the log, please let me know where you are stuck. Are you able to compile with NRF_LOG_ENABLED set to 1? Are you able to flash the bootloader? Are you able to open the Segger RTT VIewer?

RE: OTA over serial failure| sdk 15.2

Somesh Burkule — Fri, 10 Jan 2020 06:44:05 GMT

I tried with the delay's but still same issue.

I referred "DFU Master code" and implemented same.

please see follwing code to send app.

static void uart_send_application_image(uint8_t *data, uint32_t length)
{

	uint8_t CRC[] = {3};
	uint32_t CRC_len = 1;
	uint8_t execute[] = {4};
	uint32_t exe_len = 1;
	uint8_t create_obj[10];
	uint32_t create_obj_len= 6;
	uint32_t enc_data_len = 0;
	size_t read_len =0;
	uint8_t  RespData[100];
	uint8_t enc_data[100];

	//Create Object
	create_obj[0]=0x01;
	create_obj[1]=0x02;//Command Object
	create_obj[2]=length;
	create_obj[3]=length>>8;
	create_obj[4]=length>>16;
	create_obj[5]=length>>24;

	memset(enc_data,0,sizeof(enc_data));
	//CREATE COMMAND OBJECT
	encode_slip(enc_data,&enc_data_len,create_obj,create_obj_len);
	uart_flush(UART_NUM_1);
	uart_write_bytes(UART_NUM_1,(char*) enc_data, enc_data_len);
	uart_wait_tx_done(UART_NUM_1, 5);

	vTaskDelay(10);         //100ms
	ESP_ERROR_CHECK(uart_get_buffered_data_len(UART_NUM_1,&read_len));
	int readBytes = uart_read_bytes(UART_NUM_1, RespData,(uint32_t)read_len, 0);

    uint32_t encoded_slip_packet_length;

    while(length>0)
    {
        encoded_slip_packet[0]=0x08;//Write object opcode

        if (length>=MAX_ACTUAL_PAYLOAD)
        {
        	encode_slip( &encoded_slip_packet[1], &encoded_slip_packet_length, data, MAX_ACTUAL_PAYLOAD);
            length= length-MAX_ACTUAL_PAYLOAD;
            data = data+MAX_ACTUAL_PAYLOAD;
        }else
        {
        	encode_slip( &encoded_slip_packet[1], &encoded_slip_packet_length, data, length);
            length=0;
        }

        // send

        uart_flush(UART_NUM_1);
		uart_write_bytes(UART_NUM_1,(char*) encoded_slip_packet, encoded_slip_packet_length+1);
		uart_wait_tx_done(UART_NUM_1, 5);
    }

	vTaskDelay(1);              //10ms
	//CRC
	encode_slip(enc_data,&enc_data_len,CRC,CRC_len);
	uart_flush(UART_NUM_1);
	uart_write_bytes(UART_NUM_1,(char*) enc_data, enc_data_len);
	uart_wait_tx_done(UART_NUM_1, 5);

	vTaskDelay(10);             //100ms
	ESP_ERROR_CHECK(uart_get_buffered_data_len(UART_NUM_1,&read_len));
	readBytes = uart_read_bytes(UART_NUM_1, RespData,(uint32_t)read_len, 0);

	memset(enc_data,0,sizeof(enc_data));
	//EXECUTE
	encode_slip(enc_data,&enc_data_len,execute,exe_len);
	uart_flush(UART_NUM_1);
	uart_write_bytes(UART_NUM_1,(char*) enc_data, enc_data_len);
	uart_wait_tx_done(UART_NUM_1, 5);

	vTaskDelay(20);             //200ms
	ESP_ERROR_CHECK(uart_get_buffered_data_len(UART_NUM_1,&read_len));
	readBytes = uart_read_bytes(UART_NUM_1, RespData,(uint32_t)read_len, 0);
}

Can you please explain in brief how to see logs on RTT viewer. not getting logs yet.