Random PWM dutycycle inversion in SoftDevice 8.0

RE: Random PWM dutycycle inversion in SoftDevice 8.0

Stefan Birnir Sverrisson — Thu, 03 Sep 2015 10:54:53 GMT

You are correct, there is no direct call to PWM_IRQHandler() from nrf_pwm_set_value(). The nrf_pwm_set_value() only sets the new duty cycle value into a variable. The actual duty cycle is updated when a timeslot starts, and that is where it is safe to update the duty cycle.

However, by implementing the new nrf_pwm_set_value_directly() function, we will not have to wait for the timeslot to call the PWM_IRQHandler() and update the PWM duty cycle, we will just call the PWM_IRQHandler() function directly. That should be safe since we did not start the PWM yet.

RE: Random PWM dutycycle inversion in SoftDevice 8.0

diode — Wed, 02 Sep 2015 23:50:07 GMT

Hi Stefan, in the code nrf_pwm.c, there is a function called PWM_IRQHandler(). May I know under what circumstances is it called? I will assume if I set a new PWM parameter such as calling nrf_pwm_set_value() to set PWM duty cycle, it will be called to update the PWM configuration. But I do not see a direct function call of PWM_IRQHandler() in nrf_pwm_set_value().

RE: Random PWM dutycycle inversion in SoftDevice 8.0

diode — Tue, 07 Jul 2015 16:43:55 GMT

Thanks for your detailed explanation!

RE: Random PWM dutycycle inversion in SoftDevice 8.0

diode — Sat, 04 Jul 2015 00:07:30 GMT

Hi Stefan, your advice works. Thanks. Just curious, could you please explain the "extra stuff" in nrf_pwm.c, such as using two timers when channel number>2, function apply_pan73_workaround(), safe_margins_present() and the part containing nrf_radio_signal_callback when SoftDevice is enabled?

RE: Random PWM dutycycle inversion in SoftDevice 8.0

Stefan Birnir Sverrisson — Wed, 01 Jul 2015 09:54:44 GMT

In theory, we have estimated 62.5kHz to be the safe boundary of the PWM frequency. We have not tested with higher frequencies. The library has worked fine in the tests that we have performed so far, which are within the PWM frequency limit mentioned above. I expect that the PWM occasionally flips when you set the duty cycle with after configuring, am I correct?

I have a suggestion. In your code you call nrf_pwm_init which configures and starts the PWM, and then you set the duty cycle with nrf_pwm_set_value after it has started, which is not recommended with >62.5kHz. Since you intend to use a fixed PWM, you can set the duty cycle before starting the PWM which should be safe. Then you can avoid updating the duty cycle after the PWM is started. For this purpose add the following function in nrf_pwm.c

void nrf_pwm_set_value_directly(uint32_t pwm_channel, uint32_t pwm_value)
{
		pwm_next_value[pwm_channel] = pwm_value;
		pwm_modified[pwm_channel] = true;
		PWM_IRQHandler();
}

Then call this function just before you start the PWM in the nrf_pwm_init function, i.e.

...    
#if(USE_WITH_SOFTDEVICE == 1)
		sd_radio_session_open(nrf_radio_signal_callback);
#else
		NVIC_SetPriority(PWM_IRQn, 0);
		NVIC_EnableIRQ(PWM_IRQn);
#endif
		
		nrf_pwm_set_value_directly(0, 10);
		
		apply_pan73_workaround(PWM_TIMER, true);
		PWM_TIMER->TASKS_START = 1;
...

Then remove your call to your nrf_pwm_set_value function in v_clock_start

Let me know if that solves the issue

Update 6.7.2015 A little bit about how the PWM library works.

Each TIMER peripheral has 4 CC capture/compare registers. One of those register (I think CC[2]) is used to toggle the PWM in one direction (low to high), and one CC register (e.g. CC[0]) is used to toggle in the other direction (high to low). The value of CC[0] is changed in order to change the duty cycle of the PWM channel. If you need another PWM channel, CC[2] is also used for that one to toggle from low to high (the value of CC[2] is fixed), but e.g. CC[1] is used to toggle from high to low. The conclusion is that you can use one TIMER peripheral for 3 PWM channels. If you want more channels, you will have to use another timer peripheral as well.

The apply_pan73_workaround() is implementation for the anomaly #73 workaround stated in the nRF51822-PAN v3.0 document.

When updating the PWM duty cycle, it is critical, for safe operation, that it is updated in the correct moment, i.e. not close to the moments when the signal is to be toggled from high to low, or from low to high. If the duty cycle is updated when the signal is about to be toggled, the PWM signal might flip, as you have found out by experience. There are defined safe margins, which is the minimum time from the instant that you are updating the duty cycle until the signal will toggle. If updating the PWM duty cycle inside a safe margin, then the strategy is simply to wait a few us until we are outside the safe margin, and then do the PWM duty cycle update. When the PWM frequency is too high however, there is not enough time outside the safe margins to perform the PWM duty cycle update, and the duty cycle update might result in a PWM signal flip.

Since TIMER, PPI, GPIOTE is used to produce the PWM signal, no CPU is needed. However, when updating the PWM duty cycle (the value of e.g. CC[0] register), the CPU is needed. But there might also be other peripherals that need the CPU at the same time. Since the PWM duty cycle update is very time critical operation in order to work correctly, we must ensure that the PWM duty cycle update operation is not interrupted once it is started. This is why the PWM library uses timeslots API to do the PWM duty cycle update. The nrf_radio_signal_callback event is received when the radio finishes its scheduled BLE radio activity and grants the CPU to the application for a certain period of time. This ensures that the BLE softdevice will not interrupt the PWM duty cycle update procedure.

RE: Random PWM dutycycle inversion in SoftDevice 8.0

diode — Tue, 30 Jun 2015 17:49:56 GMT

@stefanbirnir Yes, I am using a higher PWM frequency (500kHz) than 62.5kHz. Unfortunately, 62.5 kHz is a little low for my application right now. I actually don't need to change the PWM duty cycle. The reason I constantly turn on (using nrf_pwm_set_value) and off (using nrf_pwm_enabled) PWM is to save power since I only need those PWM signals once every few minutes. And I only use 1 channel for this particular case. Given those conditions, is there a workaround?

RE: Random PWM dutycycle inversion in SoftDevice 8.0

Stefan Birnir Sverrisson — Tue, 30 Jun 2015 15:06:31 GMT

We have seen this problem before and there are several possible causes. We think however that the problem is related to the update of the PWM duty cycle when PWM frequency is high, i.e. when nrf_pwm_set_value is called. Are you calling this method, or are you maintaining a fixed duty cycle PWM?

If the frequency of the PWM is too high, the PWM might flip when the duty cycle is updated. I think the library implements the PWM_MODE_BUZZER_255 mode which is 62.5kHz and that is max frequency in order to do this safely. Is that frequency too low for your scenario? Can you try to lower the frequency in order to see if that is the actual issue.

RE: Random PWM dutycycle inversion in SoftDevice 8.0

JohnBrown — Fri, 26 Jun 2015 08:34:34 GMT

Does it work properly if you don't have the SD running?
What is the range of duty cycle you wish to produce?

If you are only using one channel, and you don't need to change duty cycle on the fly, I still believe you'd be better off writing your own PWM functions. If you don't need to use the IRQs, then since it's all hardware(timer compare events, GPIOTE tasks) it should work perfectly fine even with the SD running.

On the other hand, I don't know what exactly you are trying to achieve.

RE: Random PWM dutycycle inversion in SoftDevice 8.0

diode — Thu, 25 Jun 2015 23:13:46 GMT

I had similar feeling but I saw a line in nrf_pwm.c in that repository:

 nrf_gpiote_task_config(pwm_gpiote_channel[i], pwm_io_ch[i], NRF_GPIOTE_POLARITY_TOGGLE, NRF_GPIOTE_INITIAL_VALUE_HIGH);

when it started GPIOTE task with setting initial pin state high. If that was the case, the PWM waveform shouldn't change in a bistate manner. I don't know what I am missing here...

RE: Random PWM dutycycle inversion in SoftDevice 8.0

JohnBrown — Thu, 25 Jun 2015 22:43:09 GMT

Well my guess would be that you are stopping the PWM in an entirely unsychronized fashion, and not dismantling the PPI/GPIOTE stuff, and since the PWM has to use the toggle function, anything can happen. In my opinion, the PWM capability of the nRF51 is flawed, but if you are not using ISRs you should be able to write something using PPI and GPIOTE that works. If I were you I would ignore the PWM library and write my own functions. A quick search on PWM might persuade you...

RE: Random PWM dutycycle inversion in SoftDevice 8.0

diode — Thu, 25 Jun 2015 17:02:50 GMT

I used the v_clock_start() function in my question description to re-enable PWM.

RE: Random PWM dutycycle inversion in SoftDevice 8.0

JohnBrown — Thu, 25 Jun 2015 16:54:13 GMT

You say that you're using

nrf_pwm_set_enabled(false);

to disable the PWM, what are you using to re-enable it?

RE: Random PWM dutycycle inversion in SoftDevice 8.0

diode — Thu, 25 Jun 2015 16:32:49 GMT

When PWM is active, the duty cycle doesn't change. But the duty cycle can be different if I enable PWM at different time. Yes, I am running PWM with SoftDevice. By saying "regularly", I mean the I can see the duty cycle inversion from time to time. By saying "randomly", I mean I don't see a periodic pattern of such behavior --- I can not predict its appearance.

RE: Random PWM dutycycle inversion in SoftDevice 8.0

JohnBrown — Thu, 25 Jun 2015 11:00:45 GMT

If you start the PWM and leave it running, i.e. DON'T enable and disable periodically, is the PWM stable? Also, are you running a soft device while making these observations?

BTW, what do you mean by "regularly and randomly".