how to Switch between over-the-air and uart bootloader mode?

[balaji]

Hi, How to integrate both over-the-air and uart bootloader application for an device? We have a custom board with nrf51822 chipset, and we need to implement the firmware update process, which can support both over-the-air and usb to uart type firmware update. Since we not yet tested the uart bootloader application, we dont have clear idea on it (like, how to make it enter into the bootloader mode). Can anyone suggest us how to handle this?

our requirement as follows, If the device is connected through the usb, and if the user want to update the firmware, the device should enter into dfu_dual_bank_hci (uart) bootloader mode, and do the firmware update.

And if the device is connected through ble, user should make it enter into the dfu_dual_bank_ble (over the air) bootloader mode by writing some value through the special characteristics created for it, and should do the firmware update.

Regards, Balaji

[Hung Bui]

@Balaji: The current bootloader example wasn't made for both BLE and UART be exist at the same time. You can, however, modify the bootloader example to do so. The transport layers need to be modified so that they can compiled in a same project and will be selected in run time.

To chose which type of bootloader will be selected, you can use a switch on a GPIO pin that automatically switch on when the device is plugged into USB port. Other solution is to start with one bootloader type (BLE or UART) for a period of time before switching to the other one.

We currently don't have an example of doing so, but I don't see any reason this shouldn't work.

[balaji]

Thanks for the reply Hung BUi,

How to modify the transport layer in the exiting bootloader example? Do i need to enable Include in Target Build option for both the transport layer source codes?

When i try to compile both the transport layers in the same project it is giving error as below,

._build\bootloader.axf: Error: L6407E: Sections of aggregate size 0x540 bytes could not fit into .ANY selector(s).

Sounds like memory issue.

Am i doing it in a wrong way, which is not recommended by you?

Simple example of your own will help me a lot.

Regards, Balaji.

[Hung Bui]

Hi Balaji,

You will need to compile both transport layer in one project (include in Target build).

• Since BLE and HCI transport layer share some same function, there will be "multiply defined" for those functions. You would need to modify the function name, and branch out two options when calling them depend on which protocol is running.

• The size of the bootloader will be bigger than 13KB as it is now, you would need to modify the code memory size and start address (IROM1). BOOTLOADER_REGION_START also need to modified accordingly.

I afraid that I don't have the example ready for now. I will try to make one in the next few days, if there is some spare time.

[balaji]

Thanks for the reply Hung Bui, I modified the code memory size and start address to 0x5400 and 0x3C000 respectively, and also modified the code to avoid "multiply defined" error. Now the error facing is ._build\bootloader.axf: Error: L6985E: Unable to automatically place AT section bootloader_util_arm.o(.ARM.__AT_0x0003FC00) with required base address 0x0003fc00. Please manually place in the scatter file using the --no_autoat option. What does it mean, and to overcome this? Looking forward for your example code.

After setting the Start address = 0x3C400, memory size = 0x5000, and the bootloader setting address = 0x3C000, i can able to build and flash the hexfile with both the bootloaders. When i enable the ble-bootloader manually, i can able to do the over the air firmware update (followed readme file procedure), but the application i have flashed is not at all working (not giving advertisement), but without the bootloader application it is working fine. I have attached the command window log file please refer it and give me your suggestion.

Regards, Balaji

[Hung Bui]

Hi Balaji,

After you update firmware, did you have the bootloader advertising or the chip just didn't response ?

I suspect that the DFU_REGION_TOTAL_SIZE wasn't updated accordingly to the change of the size of bootloader. Could you try to run the bootloader in debug mode (after updated app firmware) to find what goes wrong ?

If possible, please attach your bootloader project.