Hi
I want to use a mcu to update the firmware in the nrf52810 through uart,I look in the sample in the nRF5SDK1702d674dde\nRF5_SDK_17.0.2_d674dde\examples\dfu\secure_bootloader\pca10040e_uart.I can not find the start of writing firmware to bank1,could you show me call which APIs to write bank0 and the code working process?
Hello,
I am not sure I understand your question. Do you want to learn how to use the serial bootloader, or do you want to modify the bootloader?
In case you are not familiar with the bootloader, I suggest you check out this blog post. Although this explains how to use the OTA (Over The Air Bluetooth Low Energy) bootloader, the way that the bootloader works is the same when you are using the serial bootloader. The difference is that you use nrfutil to transfer the image over serial instead of using nRF Connect to transfer it over bluetooth.
To use nrfutil to transfer the image, please check out the command "nrfutil dfu serial --help".
Best regards,
Edvin
Hi
Sorry,I would like to know the process of bootloader.
1、Calling which api to get the sample into the dfu mode or into the application mode?
2、Which event start the writing of bank1?
3、Calling which api to write the new firmware to bank1 in this sample?
4、Where are the start address and the end address of bank1 .
5、Calling which api to get firmware from bank1 to bank0?
6、Calling which api to get the chip runing app when the firmware have been gotten from bank1 to bank0?
Sorry for the late reply.
helen said:1、Calling which api to get the sample into the dfu mode or into the application mode?
Do you mean on the DFU target itself? Or from the device that is connected to the DFU target?
The bootloader is only running on startup. If you want to put the device in DFU mode from the application, you can do so by using the GPREGRET register (please see the dfu_enter_check() function in nrf_bootloader.c in the bootloader application. Just like the GPREGRET register is read out in that function, you can set it from your application, and restart the device, and it should enter DFU mode.
helen said:2、Which event start the writing of bank1?
This is done from the DFU "Master". The bootloader is passive, meaning it only follows the commands from nrfutil. Of course, the writing to flash itself is done from the DFU target, but I am not familiar with the details on that level. Try to look at the nrf_dfu_data_req() handler in nrf_dfu_req_handler(). NRF_DFU_OP_OBJECT_CREATE will create an object, (init packet or DFU image), and NRF_DFU_OP_OBJECT_WRITE will write to these objects. Then when the object is transferred, the DFU master will trigger NRF_DFU_OP_OBJECT_EXECUTE, which will trigger the bootloader to verify the init_packet or the DFU application image, and then do the swap.
Whether or not you have single or dual bank is decided from your sdk_config.h file. I think it is usually dual bank if possible, but if the image is too large, then it will be single bank. On the nRF52810, I don't think it will be possible to have dual bank, due to the very limited flash size. Also, Softdevice updates or bootloader updates are not possible.
helen said:3、Calling which api to write the new firmware to bank1 in this sample?
See answer from 2)
helen said:4、Where are the start address and the end address of bank1 .
Dynamic. No strict address.
helen said:5、Calling which api to get firmware from bank1 to bank0?
NRF_DFU_OP_OBJECT_EXECUTE in nrf_dfu_data_req() in nrf_dfu_req_handler.c.
helen said:6、Calling which api to get the chip runing app when the firmware have been gotten from bank1 to bank0?
When everything is done, that would be app_start() from nrf_bootloader_app_start_final.c.
The bootloader is quite complex, handling transport, verification of signatures etc. Try it out and get familiar. Perhaps you can also enable logging in the bootloader (that would require a bigger chip) to see the flow of the DFU process.
Best regards,
Edvin
Sorry for the late reply.
helen said:1、Calling which api to get the sample into the dfu mode or into the application mode?
Do you mean on the DFU target itself? Or from the device that is connected to the DFU target?
The bootloader is only running on startup. If you want to put the device in DFU mode from the application, you can do so by using the GPREGRET register (please see the dfu_enter_check() function in nrf_bootloader.c in the bootloader application. Just like the GPREGRET register is read out in that function, you can set it from your application, and restart the device, and it should enter DFU mode.
helen said:2、Which event start the writing of bank1?
This is done from the DFU "Master". The bootloader is passive, meaning it only follows the commands from nrfutil. Of course, the writing to flash itself is done from the DFU target, but I am not familiar with the details on that level. Try to look at the nrf_dfu_data_req() handler in nrf_dfu_req_handler(). NRF_DFU_OP_OBJECT_CREATE will create an object, (init packet or DFU image), and NRF_DFU_OP_OBJECT_WRITE will write to these objects. Then when the object is transferred, the DFU master will trigger NRF_DFU_OP_OBJECT_EXECUTE, which will trigger the bootloader to verify the init_packet or the DFU application image, and then do the swap.
Whether or not you have single or dual bank is decided from your sdk_config.h file. I think it is usually dual bank if possible, but if the image is too large, then it will be single bank. On the nRF52810, I don't think it will be possible to have dual bank, due to the very limited flash size. Also, Softdevice updates or bootloader updates are not possible.
helen said:3、Calling which api to write the new firmware to bank1 in this sample?
See answer from 2)
helen said:4、Where are the start address and the end address of bank1 .
Dynamic. No strict address.
helen said:5、Calling which api to get firmware from bank1 to bank0?
NRF_DFU_OP_OBJECT_EXECUTE in nrf_dfu_data_req() in nrf_dfu_req_handler.c.
helen said:6、Calling which api to get the chip runing app when the firmware have been gotten from bank1 to bank0?
When everything is done, that would be app_start() from nrf_bootloader_app_start_final.c.
The bootloader is quite complex, handling transport, verification of signatures etc. Try it out and get familiar. Perhaps you can also enable logging in the bootloader (that would require a bigger chip) to see the flow of the DFU process.
Best regards,
Edvin
