nRF52 PWM Glitch Error

RE: nRF52 PWM Glitch Error

Alex@harmoniumLED — Thu, 30 Jun 2022 10:54:19 GMT

Didrik,

I have solved the issue with the help and hints of the old ticket, so, may be, it does not worth to make new? Your advice?

I have edited my reply, added this note - "solved".

Alex.

RE: nRF52 PWM Glitch Error

Didrik Rokhaug — Thu, 30 Jun 2022 10:41:06 GMT

Hi Alex,

Please open a new ticket, rather than replying to one that is old.

That way, it is easier for us to help you with your problem.

Best regards,

Didrik

RE: nRF52 PWM Glitch Error

Alex@harmoniumLED — Thu, 30 Jun 2022 10:26:36 GMT

I have same issue.

I use one PWM module, two channels of it.
I tried two chips from different lots. NRF52832 QFAA E0 2041 NU & NRF52832 QFAA E0 2132 UU.
It glitches unpredictably and in two ways. The simplest way is as described above, just the running frequency of my PWN is higher.
Yes, looks like DMA reads 0 instead of the value, needed.

The other case is not so easy, because whole sequence is almost totally destroyed.

And this moment, zoomed:

Interesting, that it happens 100%, when you do not use DEBUG tool, and does not happen, if you are running DEBUG session.

Alex.

P.S. I've switched this on in sdk_config.h:

And both types of issue are gone.

RE: nRF52 PWM Glitch Error

Marc — Wed, 15 Feb 2017 16:32:21 GMT

Following the suggestion of nRF52832 Errata Attachment, Anomaly 109 Addendum, DMA access transfers might be corrupted (infocenter.nordicsemi.com/.../nRF52_PAN_109_add_v1.1.pdf) section 3.5.1 ONLY USE 3 CHANNELS, So I split my leds on 2 PWM instead of one and it solved my problem.

RE: nRF52 PWM Glitch Error

MartinBL — Wed, 15 Feb 2017 08:18:52 GMT

@Marc: This might be related to this product anomaly: [109] DMA: DMA access transfers might be corrupted. The case in Ole's link turned out to be a simple oscilloscope aliasing issue. The measurements shown in the images were done at a low sampling rate which happened to produce a visible waveform when the clock was running on the RC oscillator with poor accuracy. When the clock switched to the HF external crystal with high accuracy the scope produced an aliased signal. Notice user 'grow mane's comment from June 4th 2016.

RE: nRF52 PWM Glitch Error

MartinBL — Wed, 15 Feb 2017 08:05:12 GMT

Hi.

We have seen some similar cases which so far have had one of two solutions:

This particular case is probably caused by this product anomaly: [109] DMA: DMA access transfers might be corrupted. In general, if you e.g. are using PWM to fade an LED and you see noticeable flickering then this might be the cause.
It can be a simple issue of measurement error. In the case linked to by Ole June 7th 2016, nRF52 PWM Glitch Error, I believe the issue turned out to be an oscilloscope aliasing issue. The measurements shown in the images were done at a low sampling rate which happened to produce a visible waveform when the clock was running on the RC oscillator with poor accuracy. When the clock switched to the HF external crystal with high accuracy the scope produced an aliased signal. If this is the issue, you should not see any visible flickering when fading an LED. It is only visible on a poorly configured oscilloscope.

RE: nRF52 PWM Glitch Error

Marc — Tue, 14 Feb 2017 16:26:34 GMT

I have the same problem. sd_clock_hfclk_request().didn't work for me. I have 4 leds connected to PWM0 (nrf52) and it is only when I change (fade in/out 1 sec) NRF_PWM->OUT[2] (connected to P0.27) that I see glitches at NRF_PWM->OUT[0] (P0.3)

As a workaround, I set bit 31 of NRF_PWM0->PSEL.OUT[0] to disconnect it while I'm not using it.

RE: nRF52 PWM Glitch Error

WestCoastDaz — Wed, 06 Jul 2016 17:53:42 GMT

Daniel,

We have seen the same thing here but this only works on the DK board. When we do this in our custom application on our hardware it doesn't work.

RE: nRF52 PWM Glitch Error

Daniel Veilleux — Wed, 06 Jul 2016 17:32:58 GMT

And if I comment out the call to sd_app_evt_wait in the firmware that I have been using to test for the glitch then the glitch goes away. Not calling sd_app_evt_wait is the only workaround that I have seen so far that works.

RE: nRF52 PWM Glitch Error

Daniel Veilleux — Tue, 05 Jul 2016 16:40:41 GMT

I have also seen it while using the synthesized LFCLK source and on an nRF52 Rev 1 DK.

RE: nRF52 PWM Glitch Error

Daniel Veilleux — Fri, 01 Jul 2016 23:06:00 GMT

Furthermore, the glitch happens when using constant latency mode.

RE: nRF52 PWM Glitch Error

Daniel Veilleux — Fri, 01 Jul 2016 19:55:07 GMT

I can confirm that the glitch still happens even if sd_clock_hfclk_request() is used. I am able to reproduce the glitch consistently on my nRF52 Rev C DK.

RE: nRF52 PWM Glitch Error

WestCoastDaz — Wed, 08 Jun 2016 03:28:01 GMT

Ole, we don't have the option of using the high frequency clock since it consumes to much current.

RE: nRF52 PWM Glitch Error

Michael Dierks — Tue, 07 Jun 2016 18:23:03 GMT

Ole, have you seen the updated comments from grow mane on the linked case, from 06 June? They relate to possible phase shift issues between the 32kHz and the high freq clock.

RE: nRF52 PWM Glitch Error

Michael Dierks — Tue, 07 Jun 2016 17:43:32 GMT

The chip is the nRF52832, variant QFAA BB. I will update the question with the code.

RE: nRF52 PWM Glitch Error

Ole Bauck — Tue, 07 Jun 2016 09:38:25 GMT

Could you also attach the code you use to set up the pwm?

RE: nRF52 PWM Glitch Error

Ole Bauck — Tue, 07 Jun 2016 08:51:48 GMT

Which chip revision do you have? infocenter.nordicsemi.com/.../ic_revision_overview.html

RE: nRF52 PWM Glitch Error

Ole Bauck — Tue, 07 Jun 2016 08:51:09 GMT

We have seen similar issues, but I have not been able to reproduce it here. It looks like the problem is related to the HFCLK switching from RC to XTAL, which happens every time the SoftDevice uses the radio. Try to use XTAL all the time by calling sd_clock_hfclk_request().

Here is the link for the other case.

I will investigate this further here. Hopefully I will be able to reproduce it (I believe it only happens on some chips, and that is why I have not been able to reproduce it yet).