Application updated through BLE DFU (OTA) don't work properly

[LukaszW4]

Dear all,

I'm using NRF52832 with SDK 14.2.0 and SD 132 v5.0.0.

I have my own implemented application working properly when is flashed directly without bootloader, only SD and Application.

But when I update firmware through DFU BLE OTA as described in Getting started with bootloader my application code starts but works very strange. Code is dysfunctional, working in strange manner.

The same is when I create one package containing all in one (bootloader, bootloader settings, softdevice and own app) and flash it directly.

Have you got any idea what happens and how to resolve that problem? I think there is some conflict with memory when bootloader is flashed but I dont know where to search ;/

Best regards

[Hung Bui]

Hi Lukasz, 

 

Could you tell us how exactly your code behavior after using with the bootloader ? Have you managed to do DFU update with one of our SDK's example ? 

There could be a chance that it has to do with the LFCLK or RTC that has been used in our bootloader and then not initialized properly in your application. 

We need more debug information to give you advice. 

[LukaszW4]

Hung Bui I reviewed problem one more time with some changes in my application code. I resolved my problem in a portion. There was conflict with pin configuration between bootloader (button and 4 LEDs) and my application.

As in previous post, is there posibility to change in easy way bootloader code not to use button and 4 LEDs?

[LukaszW4]

Sorry I wasn't precise enough.

Now, when I do full initialization of pins and setting default state everything works in my app after bootloader update. (Previously, i don't set default state in my app on one pin which was used in bootloader as LED, so there was other behaviour as I expected ;) ).

I want to enter bootloader using buttonless ;)

Now, because of that I'm using my custom board i want to turn off LEDS. I worry about some pin conflict between nRF and other IC on my board when default configuration of bootloader is used. Driving pin in opposite states problem.

I tried to comment that two functions but leds are still driven in such states I observe that when testing on development board. So comment or uncomment lines leds_init(); and buttons_init(); is not a resolve of that

[Hung Bui]

Hi Lukasz, 

 

Sorry we have another leds_init() function inside nrf_ble_dfu.c please also comment it out. 

Also please search and comment out any call to nrf_gpio_pin_* in nrf_ble_dfu.c as well. 

 

 

[LukaszW4]

It helps, now leds are off and pins are not driven by bootloader. But after that changes when i upload my app code via BLE it isn't starting and remain in bootloader state (DfuTarg advertises).

Is there any posibility to debug or get logs from bootloader? 

[LukaszW4]

The reason why my app was not starting was caused by my custom board. Reading button pin value caused entering bootloader mode everytime because in my custom board that pin is used for other stuff.

Resolve of that problem is comment buttons_init(); function in main.c as well as changing nrf_dfu_button_enter_check() function to only return false;

My last request is: How to debug or get logs from bootloader code? Is there such a possibility? Hung BuiThanks for help until that moment! :) 

[Hung Bui]

Hi again Lukasz, 

I'm glad that it's working now. 

Yes you can have log with the bootloader. Please use the _debug version of the bootloader. The bootloader by default use Segger RTT as log's front end.