Closed jpbrucker closed 8 years ago
May be use a different name, otherwise we'd take the ability for the user to override the bootloader image that is used.
The following code from targets.py might help understand this better:
# Look for bootloader file that matches this soft device or bootloader override image
blf = None
if t_self.target.MERGE_BOOTLOADER is True:
for hexf in resources.hex_files:
if hexf.find(t_self.target.OVERRIDE_BOOTLOADER_FILENAME) != -1:
t_self.debug("Bootloader file found %s." % t_self.target.OVERRIDE_BOOTLOADER_FILENAME)
blf = hexf
break
elif hexf.find(softdeviceAndOffsetEntry['boot']) != -1:
t_self.debug("Bootloader file found %s." % softdeviceAndOffsetEntry['boot'])
blf = hexf
break
could you please resubmit against 'develop'? otherwise if I merge this into develop manually the dependency tree looks confusing. thanks.
This file was previously stored in the mbed SDK, but it was decided that putting it inside the nRF library would make more sense.
The exact location isn't too important, since mbed SDK is already looking for a file named 'nrf51822_bootloader.hex' in all scanned resource files, when building a BOOT image.
It was built from the current ARMmbed dfu-bootloader repository. It uses the internal LF clock source only, so it is compatible with all nRF51822 devices. In addition, it doesn't rely on a specific SoftDevice: the SoftDevice information struct is inspected at a fixed address, to find out the application entry point.
In order to ease development, this bootloader pretends to use DFU version 0.4, so recent DFU applications won't mandate an init packet.