GPIOTE + bootloader_secure + SoftDevice

RE: GPIOTE + bootloader_secure + SoftDevice

Timur Beganovic — Fri, 14 Sep 2018 09:52:34 GMT

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

RE: GPIOTE + bootloader_secure + SoftDevice

Einar Thorsrud — Wed, 12 Sep 2018 08:19:44 GMT

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).

RE: GPIOTE + bootloader_secure + SoftDevice

Timur Beganovic — Tue, 11 Sep 2018 13:56:36 GMT

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.

RE: GPIOTE + bootloader_secure + SoftDevice

Einar Thorsrud — Tue, 11 Sep 2018 13:23:48 GMT

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.