Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
5 years, 7 months ago.
BLE wierd behavior on nRF52840
Hi,
I have a nRF52840, which I implemented a basic scanner test on.
The implementation is an adaption from https://github.com/ARMmbed/mbed-os-example-ble/tree/master/BLE_PeriodicAdvertising where I have removed the PeriodicAdvertising and just do a scan of other BLE devices around me.
I did notice that the LED stopped working when it was scanning. That is, it is just flashing very briefly, and not lit for 500 ms and turned off for 500ms as expected.
I changed the code so that the scanning did not continue after the time out, and then the LED started to flash normally again.
I suspected that it was the event queue which was starved due to many BLE events to handle, so in the ::blink() function, I blinked all 4 LEDs on the board, expecting to see these random flashes on all 4 LEDs. I did not.
LED2 and LED4 blinks as expected when scanning. LED1 and LED3 hardly lits up. When scanning times out, all LEDs are blinking in rythm as expected.
Is the BLE stack messing with GPIO pins when active? Why?
I tried to switch from Cordio to SoftDevice, but it seems the mbed API does not want to talk with SoftDevice, as even the most basic command (startScan) was rejected with 'not implemented'.
In the final hardware we will be using the GPIOs used by nrf52840-DK LEDs for other things, so having them reset randomly when BLE is activated is troubling.
1 Answer
5 years, 7 months ago.
Hi Fredrik,
You guess is right, Cordio stack is in charge of two LEDs for showing the controller alive/advertising state, so the behavior of LEDs would be strange if two masters want to control it.
We will prioritise this requirement and hopefully provide an option for choosing whether GPIO is controlled by Cordio or user application.
Thanks for reporting this, please let me know for any questions!
- Desmond, team Mbed