Glitches issue with LED PWM and Gazell

[eugenePi]

Dear all,

I'm using and nRF51822 chip for implementing a wireless HID device with dongle.

The device has an RGB LED, and indication scenarios for different modes are played using software PWM

(because nRF51 doesn't have hardware PWM, I use TIMER HW with 3 channels for each color).

And, I encounter the glitches in color scenarios when the Gazell stack is being used. I don't see any glitches when the Gazell is OFF. It's also OK when using BLE.

I suppose that it's a matter of configuring priorities for IRQs, and I've tried different configs for this, however, with no success.

Is this issue really solvable on nRF51 or it can only work smoothly on nRF52 with HW PWM?

Regards, Eugene

-------------------------------------------------------------------------------------------------------------------------------------------------

The TIMER IRQ handler which makes the PWM

void led_event_handler(nrf_timer_event_t event_type, void* p_context)
{
    switch (event_type)
    {
        case NRF_TIMER_EVENT_COMPARE0:
        	nrf_drv_gpiote_out_clear(GPIO_NRF_R_PIN_NUMBER);
        	nrf_drv_gpiote_out_clear(GPIO_NRF_G_PIN_NUMBER);
        	nrf_drv_gpiote_out_clear(GPIO_NRF_B_PIN_NUMBER);
            break;

        case NRF_TIMER_EVENT_COMPARE1:
        	nrf_drv_gpiote_out_set(GPIO_NRF_R_PIN_NUMBER);
            break;

        case NRF_TIMER_EVENT_COMPARE2:
        	nrf_drv_gpiote_out_set(GPIO_NRF_G_PIN_NUMBER);
            break;

        case NRF_TIMER_EVENT_COMPARE3:
        	nrf_drv_gpiote_out_set(GPIO_NRF_B_PIN_NUMBER);
            break;

        default:
             break;
    }
}

The color is being set using nrf_drv_timer_extended_compare function for each RGB component (TIMER channel)

[Kenneth]

I believe that the latest pwm example for nRF51-series in nrf5 sdk v12.3 should be pretty stable, however as you write, it is a software implementation, so it will not be as good as the nRF52-series with hardware pwm module.

[eugenePi]

Hi Kenneth, thanks, I understood. However, it is strange that glitches are present only when Gazelle stack is enabled. So I guess that not only SW PWM is a problem. Are there any recommendations how to minimize the impact of Gazelle on the software PWM indication?

[Kenneth]

The Gazell protocol is rather high intensive on the nRF51-series (ARM Cortex-M0), so I am not terrible surprised that other lower level interrupts/processing may be delayed/interrupted (thereby causing glitches). The nRF52-series (ARM Cortex-M4) is faster due to CPU, improved peripherals, but also faster clock.