DFU via own protocol

RE: DFU via own protocol

JoEi — Thu, 26 Mar 2020 13:58:45 GMT

Hi Edvin,

I've tested it the way I wrote in my last post and it works great.

One problem I had was that when I flashed the firmware on the controller the start address of the bootloader got deleted. But this is now fixed.

Right now we consider to drop the init packet and instead add some TLVs at the end of the binary.

Thanks again for your responses because they pushed me in the right direction. =)

Best regards,
Johannes

RE: DFU via own protocol

Edvin — Tue, 24 Mar 2020 10:40:31 GMT

Have you tested?

I am not sure whether you need to validate and/or write the bootloader settings after the transfer is complete. This is what happens usually:

on_data_obj_execute_request() is called when a transfer is usually done. This calls:

m_observer(NRF_DFU_EVT_OBJECT_RECEIVED); -> dfu_observer() -> case NRF_DFU_EVT_OBJECT_RECEIVED -> inactivity_timeout-> bootloader_reset() -> nrf_dfu_settings_backup(do_reset) -> settings_backup() -> settings_write().

So maybe you need to do this if you have tranferred an image.

Try it first, and see how it behaves. If it doesn't work, try to call bootloader_reset() after entering the bootloader, and then see what happens.

We don't have the support for this out of the box, but you need to study the bootloader example to see what it usually does, and skip the transfer part.

BR,

Edvin

RE: DFU via own protocol

JoEi — Mon, 23 Mar 2020 16:43:59 GMT

Yeah I'm using a dual bank for that.
So you mean after I've done the validation, filled bank_1 with the corresponding size, crc and bank code and set bank_current to bank 1 in the dfu/bootloader settings, i don't need to execute sd_power_gpregret_set(0, BOOTLOADER_DFU_START); but instead just call nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_RESET);.
Then the bootloader should swap bank 0 with bank 1 and start the new firmware.

RE: DFU via own protocol

Edvin — Mon, 23 Mar 2020 15:32:53 GMT

I was thinking about the message sequence chart. I'm sorry. I forgot the link in the previous reply. Do you intend to use the serial bootloader as a starting point? In that case, I would check out this one:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v14.2.0/lib_dfu_transport_serial.html?cp=7_5_3_3_5_2_3_1#lib_dfu_transport_serial_msc

What the bootloader normally does after you set the gpregret register as you described here, is that it starts in DFU mode and initializes the DFU transports (serial). Then it just waits for the transfer to begin.

If you look at the transfer init packet sequence chart, you pretty much have already transferred this image, so find out what happens in the bootloader when you typically send the execute command. What does the bootloader do then?

It stores the new settings, and then gets ready to receive the rest of the image. Since this is already transferred, you need to check what the bootloader does when you send the execute command after the image is transferred.

Have you thought about what will happen if there is something wrong with the packet that you have transferred over BLE in the application? Do you intend to run a dual bank, so that you have a fallback if the CRC doesn't match for the application image?

RE: DFU via own protocol

JoEi — Mon, 23 Mar 2020 14:44:32 GMT

Hi Edvin,

thanks for your quick response.
Yes you are right it's the transport I'm referring to. And yes I'm using the nrfutil to generate the .bin and .dat files.
Do you mean this chart?
So I'd need to do the prevalidation of the init-file and the postvalidation of the new firmware. Then the settings for bank 1 are written to 0x7F000, if I'm not mistaken.
And after that I need to activate the bootloader via sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
Is there anything else I need to do?
Yeah it would have been nice if I could simply transfer these two files via BLE and save them in flash and the bootloader would do the rest.

Best regards,
Johannes

RE: DFU via own protocol

Edvin — Mon, 23 Mar 2020 12:53:28 GMT

Hello,

When you say "own protocol", is that just the transport layer? Are you still using nrfutil to generate the packets? I assume you are, since you are asking about the init packet.

Did you study the message sequence charts that the original bootloader use?

Use this, and study the bootloader examples to see what is done when the init packet is received. The bootloader will have to check the CRC and the signature of the packet to see that it is indeed a valid packet. Then study what happens when the entire image has been transferred.

You still need to do these jobs that the bootloader normally do. The only thing you want to separate out is the actual transfer of the image, right?

Best regards,

Edvin