PWM failed to work with SoftDevice 8.0 in nRF51822

[diode]

I may be missing something. I am trying to generate a square wave from a GPIO pin in a BLE application (SoftDevice 8.0). I tried libraries (nrf_pwm.c and nrf_pwm.h) in this post and also in this repo. I created two functions as follows:

#define V_CLK 5
static void pwm_init(void) 
{
	  nrf_pwm_config_t pwm_config = PWM_DEFAULT_CONFIG;
    
    pwm_config.mode             = PWM_MODE_LED_255;
    pwm_config.num_channels     = 1;
    pwm_config.gpio_num[0]      = V_CLK;
    
    // Initialize the PWM library
    nrf_pwm_init(&pwm_config);
}

static void v_clock_start(void)
{
	nrf_pwm_set_value(0, 127);
}

I have tested they worked without SoftDevice, as I could see a square wave between 0V and VCC in GPIO pin 5.

After that I went ahead with SoftDevice. I used "ble_app_beacon" from SDK 8.0.0 as the starting point, and removed BSP code since I was using a standalone nRF51822 module. I set USE_WITH_SOFTDEVICE to 1 in nrf_pwm.h. Also, I called pwm_init() before ble_stack_init() in main() function:

int main(void)
{

    pwm_init();
    ble_stack_init();
    advertising_init();

    advertising_start();
    v_clock_start(); 

    for (;; )
    {
        power_manage();
    }
}

While BLE started successfully as I could see the iBeacon in my Master Control Panel Android app, I saw a flat 0V output from GPIO pin 5 in my oscilloscope. I tried to do the same thing to other working BLE apps of mine and they showed the same behavior. What was I missing?

[JohnBrown]

I don't know why your code is not working, but if you are really only looking to produce a square wave, i.e constant 50% duty cycle(or any other constant duty cycle, which would more accurately be described as a rectangular wave), and at a constant frequency, I would write the thing myself, using a counter timer and GPIOTE.

If you are hoping to vary either the duty or the frequency on the fly, then good luck with that.

It is, in my humble opinion, a weakness of the nRF51822, in that the compare registers are not double buffered, and you can not have a SET and a CLEAR task directed to a single I/O pin, but have to rely on a TOGGLE instead. I say this as someone who has fought with this in a quest to reliably produce DTMF tones WITHOUT the SD running!

However, I suppose the designers have tough choices to make about the best use of silicon...