Call bootloader_start implicitly trough a event handler call

[LiyouZhou]

work around for bootloader_start not being public in sdk 8.1. Backwards compatible.

@andresag01 Please review.

[rgrover]

looks good. I'll review the changes to ble-nrf51822 before merging this.

[LiyouZhou]

@rgrover This is independent of ble-nrf51822, this change does not depend on any change to ble-nrf51822.

[rgrover]

this isn't needed, is it?

[LiyouZhou]

@rgrover A handle need to be passed to bootloader_start in sdk 8.0.1 hence ble_dfu_t need to be populated with a connHandle.

[rgrover]

the first parameter isn't actually used in the path which calls bootloader_start(). I'll be fine if you still feel we should initialize a local variable for this. But I would also like to eliminate anything that's un-necessary.

[rgrover]

it seems future versions of dfu_app_on_dfu_evt might need that parameter to be non-null.

[rgrover]

published ble-2.1.3

[apalmieriGH]

Hi guys,
it seems the latest version is not fully supporting ble-examples which do not comile any more

No such file or directory
#include "dfu_app_handler.h"

Am I missing something?
Thanks

[andresag01]

@apalmieriGH: could you please provide additional information, i.e. Which example are you trying to compile? Could you post the output of yotta ls and yotta target?
Thanks

[LiyouZhou]

@apalmieriGH
Also may I also suggest removing yotta_module directory and build directory and rebuilding again?

[apalmieriGH]

@andresag01 @LiyouZhou : I'm building ble_examples/BLE_HeartRate

$ yt ls
ble-heartrate 0.0.1
┗─ ble 2.1.3
┣─ x-nucleo-idb0xa1 1.1.3 yotta_modules/x-nucleo-idb0xa1
┗─ mbed-drivers 0.11.3 yotta_modules/mbed-drivers
┣─ mbed-hal 1.2.0 yotta_modules/mbed-hal
┃ ┗─ mbed-hal-st 1.0.0 yotta_modules/mbed-hal-st
┃ ┗─ mbed-hal-st-stm32f4 1.1.0 yotta_modules/mbed-hal-st-stm32f4
┃ ┣─ uvisor-lib 1.0.6 yotta_modules/uvisor-lib
┃ ┣─ mbed-hal-st-stm32cubef4 1.0.2 yotta_modules/mbed-hal-st-stm32cubef4
┃ ┗─ mbed-hal-st-stm32f401re 0.1.1 yotta_modules/mbed-hal-st-stm32f401re
┣─ cmsis-core 1.1.0 yotta_modules/cmsis-core
┃ ┗─ cmsis-core-st 1.0.0 yotta_modules/cmsis-core-st
┃ ┗─ cmsis-core-stm32f4 1.0.4 yotta_modules/cmsis-core-stm32f4
┃ ┗─ cmsis-core-stm32f401xe 0.1.0 yotta_modules/cmsis-core-stm32f401xe
┣─ ualloc 1.0.2 yotta_modules/ualloc
┃ ┗─ dlmalloc 1.0.0 yotta_modules/dlmalloc
┣─ minar 1.0.1 yotta_modules/minar
┃ ┗─ minar-platform 1.0.0 yotta_modules/minar-platform
┃ ┗─ minar-platform-mbed 1.0.0 yotta_modules/minar-platform-mbed
┣─ core-util 1.0.1 yotta_modules/core-util
┗─ compiler-polyfill 1.1.1 yotta_modules/compiler-polyfill

$ yt target
st-nucleo-f401re-st-ble-gcc 0.1.2
st-nucleo-f401re-gcc 0.2.0
mbed-gcc 0.1.3

[andresag01]

@apalmieriGH: Thanks for reporting this issue. We will be pushing a patch shortly to fix this change. The problem is that all of DFU service is only Nordic-specific and only works with targets like nrf51dk and mkit. When you compile for and ST target clearly the nordic modules are not included in the dependency tree by yotta and the header in #include "dfu_app_handler.h" is obviously not found by the preprocessor, so you get that error.

Actually, if you are not using DFU you will find that removing yotta_modules/ble/services/DFUService.h and yotta_modules/ble/source/services/DFUService.cpp will fix the problem. However, we will be addressing this problem shortly with a proper fix.

[apalmieriGH]

@andresag01 : Thank you for fixing. I guess the ble APIs should be agnostic about the lower layer driver. And the ble-examples should not include dependencies of services that are not relevant. Besides, the same issue has been propagated in mbed classic, as well.