GPIOTE + bootloader_secure + SoftDevice

[Timur Beganovic]

hello,

I faced interesting problem which I fortunately solved and would like to share with others because I hadn't found any information on this.

I am using nRF51822 on my custom board. The SoftDevice, secure_bootloader and my custom BLE application are flashed on my flash. I succeeded to configure GPIOTE tasks which control LEDs (PWM) using NRF_TIMER1 and NRF_TIMER2. It all worked well when I was testing my application without the bootloader  But when I installed the bootloader and ran the application  the LED lights started to change the intensity.

It turned out that it has something to do with the initialization functions called in ble_dfu_transport_init() in the bootloader. I didn't have time to find outt which initialisation exactly caused the problem but the problem was solved calling ble_dfu_transport_close() before entering the main application nrf_bootloader_app_start() in nrf_dfu.c.

I hope this will be useful and maybe inspire someone to find the exact cause of the problem.

best regards

[Einar Thorsrud]

Hi,

The only thing I can think of is that the PWM signal might be reverted. This is a known issue on the nRF51 series, as GPIOTE only has a toggle task. If you lose an event for some reason, so that a single toggle does not occur, the result is that the output PWM signal is reverted, giving you a different LED intensity.

Which SDK version are you using? And do you handle the PWM generation yourself, or do you use the PWM library? The PWM library in SDK 12.3 has been designed to mitigate the risk for actually triggering this issue.

[Timur Beganovic]

Well, it really  seems like some events get lost but I am wondering why it happens. I am using GPIOTE channels and NRF_TIMERs which are open when SoftDevice enabled.

I am using SDK 12.3 secure_bootloader.  I handle the PWM myself using GPIOTE channels.

[Einar Thorsrud]

Hi,

This is quite complex, and there has been a lot of DevZone treads about it earlier. I suggest you use the PWM library from the SDK as it has been designed to avoid this issue. It essentially does the same thing as you, using a TIMER and GPIOTE.

(Note that this is not an issue on the nRF52, as there the GPIOTE peripheral has a set and clear task in addition to a toggle task. There is also a separate PWM peripheral in the nRF52).

[Timur Beganovic]

It seems that I solved this issue applying the le_dfu_transport_close() function in the Bootloader, as I described in the first post. I published this thread in order to help other people who might face the same problem.

Thank you for your response and your suggestion regarding the PWM library.

regards

Timur