Bootloader Logging for BLE Fails

[joer55]

Hello:

We are developing a DFU bootloader for an NRF52 product that supports USB and BLE upload methods (they are 2 separate bootloaders from a common source).  Both work as expected (able to boot the device and download firmware applications correctly). With the USB bootloader we can enable logging in the sdk_config.h file and see output logging on our serial debug port.  When logging is enabled with BLE  bootloader, we see logging but the BLE connection either disconnects or the Firmware update does load correctly (and never launches) or we get dropped log errors (and the firmware does not load correctly).  The BLE bootloader works fine if we disable logging but we cannot debug it without printouts.  What can we do to enable BLE logging in our bootloader and still have it upload our firmware correctly?

Thanks

[Hung Bui]

Hi Joe, 

I just want to clarify that you have 2 separate bootloaders and they are not running on the same device, correct ? You just want to compare the behavior between the two ? Could you give more information about the bootloaders ? Did you base the bootloader on our bootloader example ? which SDK was that ? 

When you mentioned "serial debug port" you meant UART ? 

We will need to look into the reason for disconnection and/or image failed to transfer/launch. Please provide more debug information bout any disconnect reason, DFU terminate reason, etc. We need to look into why printing log in UART affect DFU process. 
A sniffer trace of the DFU process would also be useful. 

[joer55]

Hi Hung:

Thanks for your quick reply.  Some more details about our setup:

- Yes these are 2 separate bootloaders and do not run on the device at the same time. We reflash the device to load one or the other.

- We are not comparing the behavior of the 2. The USB bootloader is for development, the BLE bootloader is our customer facing bootloader.  Both are needed.

- We did base these 2 bootloaders on the SDK bootloader example code in SDK  15.0.0.0

- Yes, the Serial Debug port is the UART we have connected to our device.

- I'll try to capture the UART output from the failures and get the information to you.

[Turbo J]

Enabling NRF logging substantially increases the flash memory footprint.

You will most likely need to lower the start address for the bootloader to be able to run.

[joer55]

Thanks Turbo 1 for the information.  Do you know how much I would need to lower the bootloader start address (or should I do this by trial and error)?  Also, I assume I do this thru the sdk_config.h file - is that true?

Thanks

[Hung Bui]

Hi Joe, 
If you configure the chip flash's size according to the actual flash size of the chip you should receive an error when trying to build the application if the memory exceed the actual flash size on the chip. 

The start address of the bootloader and the flash size is configured in the project configuration, depends on which IDE you use.