PWM Interrupts / Interrupt Priority Levels

Zephyr 3.2.99 - nRF Connect 2.2.0

We have a 4 digit 7 segment display that we use on one of our products. Instead of using something like timers to keep the display updated we designed it to use PWM interrupts instead. So every time an interrupt happens we increment the current digit and set the PWM pulse cycles / brightness. The PWM is inverted and it's set to use a 4ms period. So, each segment can have a min brightness of 4ms - 100us (3,999,900ns) and a max brightness of 160us (160,000ns). We never use full brightness (0ns) or no brightness (4,000,000ns) because the interrupts would get disabled and cause the display to no longer work. This has been working great, but we noticed there was a "bleed" on the display (some of the segments are partially lit when they shouldn't be). After looking into it we found that the interrupt callback timing was not consistent. The callback gets fired usually around 130us to a little over 200us (normally around 150us). This is causing the digit switch to be delayed, which partially lights a segment up. This all goes back to the max brightness; the lower the value the more it bleeds and the higher the value the more stable it is (but at the sacrifice of a dimmer display). Here is a visual example of what we are seeing:

"Set Digit" (the top reading) happens as soon as the interrupt callback is fired. The "Display Seg A" is a wire hooked to the capacitor that the segment A LED uses.

Here is what it should look like and has no bleeding (you can see it fires before the period starts giving it enough time to switch digits properly):

I guess I have three questions.

1) Is there any way to make the callback a little more consistent, or can the variable 130us - 200us be expected? I know there's always going to be variable timings, but it would be nice to minimize the range if possible. My goal is to find the optimal max brightness value that causes the least bleeding.

2) Is there any way to shorten the time it takes for the callback to be fired? The quicker it gets called the brighter we can make the display. I don't think it will make a drastic difference, but every little bit helps.

3) One thing we tried was to increase the priority of PWM1 and PWM2. By default everything has a priority of 1 (NRF_DEFAULT_IRQ_PRIORITY), so we change this to 3 and made the PWM1 and PWM2 have a priority of 2. This didn't help. However, it does bring up a question about the interrupt priorities. According to the documentation (https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsds_s140%2FSDS%2Fs1xx%2Fprocessor_avail_interrupt_latency%2Fexception_mgmt_sd.html) it states that priority level 1 is reserved by the SoftDevice. So, is it OK to use priority level 1 (like NRF_DEFAULT_IRQ_PRIORITY) or should we stick to using 2 & 3? We want the display to have the highest priority over the other devices.

Here is a quick mock-up of something similar to what we're doing (see configure_pwm and pwm_callback):

Appreciate any help.

Parents
  • Are you sure you cannot do this in hardware instead of software?

    The PWM peripheral is pretty advanced (https://infocenter.nordicsemi.com/topic/ps_nrf52840/pwm.html?cp=5_0_0_5_16).

    You can set up sequences in RAM that it follows. To synchronise timings, you can use PPI for starting all PWMs at the exact correct time, maybe in a combination with a TIMER peripheral.

  • Thank you for the response, Emil.

    I looked into this and the NRFX PWM driver, in Zephyr, is already doing this behind the scenes. When you call pwm_set_pulse_dt, pwm_set_dt, pwm_set, etc. it will setup the period and pulse cycles and then call pwm_set_cycles, which in turn calls Nordics NRFX driver's pwm_nrfx_set_cycles function. In there it updates the sequence value stored in RAM for that channel and then calls nrfx_pwm_simple_playback to play the sequence back once.

    I also looked into the GPIOTE in order to do the digit switching. One thing I found out is that it would be required to disable the Zephyr GPIO implementation since you can't have Zephyr's GPIO and NRFX's GPIOTE enabled at the same time. That would mean I would have to change all my code that uses the Zephyr GPIO implementation over to use NRF GPIO implementation. This would also mean that I would have to rewrite any Zephyr drivers that use the Zephyr GPIO, like the EEPROM driver as an example. I don't feel like rewriting those, nor do I think the company wants me to rewrite a lot of things I have already written.

    Going back to the NRFX PWM, I noticed that when pwm_set_cycles gets called it's updating the sequence value and calling nrfx_pwm_simple_playback for every channel... In our case, for the 4-digit 7-segment display, that's 8 times per update. That's highly inefficient and was causing the slowdown we were seeing. I turned off Zephyr's implementation of PWM and rewrote the driver to update all 8 values in ram at once and then only call the nrfx_pwm_simple_playback once. So, to answer your question, I'm sure it can be done in hardware if we disable a lot of Zephyr's functionality. 

    Do you see any problems with this or know a better way that will work with Zephyr?

     

       

  • Not had time to do any test code,  but here are notes on using a dead band to avoid ghosting (Edited to show active-low digit selects)

    The digit time T_DIGIT is constant, unless using the digit "on" time to control brightness in which case it would be changed each time the brightness is changed, typically using a logarithmic look-up table. Using both PWM Sequence 0 and 1 allows much longer to change segment values and digit brightness, but it can be done with a single sequence.

    If I get time I'll put together some test code to verify this, but meanwhile maybe it will help

  • Hi

    I believe the issue with offset between the channels occur because you are not starting the channels at exactly the same time. I would recommend changing the EGU setup a little to remedy this. 

    Essentially you can use two PPI channels to connect one of the EGU events to all three PWM start tasks, and then you just have to activate the corresponding EGU task to have all three PWM modules start in perfect sync. 

    It might be you have to follow Hugh's advice about a dead band as well. There is no simple mechanism in the PWM module to implement this unfortunately, but a couple of solutions exist:

    a) You can increase the size of the PWM buffers by a factor of X, and increase the playback speed by the same amount. Then you can use the last value of each group to implement a dead band. The drawback of this method is that you need quite large buffers if you want a small dead band. As an example if you want a dead band of 2% you would need to select an X value of 50, leading to higher memory consumption and a bit more CPU time to update the buffers. 

    b) To avoid having to increase the buffers significantly you can use a timer to step the PWM modules manually, in an uneven manner. Now you just need to double the size of the buffers (adding an additional 'dead band' value for each LED on value), and set a timer to generate first a long interval, which is the LED on value, and then a short interval for the dead band. 

    The drawback of this method is that you need to use an additional hardware timer. 

    Best regards
    Torbjørn

  • The dead band is actually free, just adjust the active time "on" for the digit selects slightly shorter than you were doing. Brightness control works exactly the same way; constant refresh frequency with less active digit time gives lower brightness. Here is a working example for the 4 digits; I just do a burst so the levels are easy to see on a 'scope

    The digit and segment sequence is as noted before; not sure if the segment is active low or active high so this sequence shows digit select active low and segment select active high; the example code uses active-low digit drives

  • I edited the waveform notes to show active-low digit  selects which the sample code uses; the dead band prefixes the digit select. Making dead band wider is a useful way of dimming the display

  • Thank you all for the help and thank you hmolesworth for really explaining it and providing example code. Between you and Torbjørn I'm sure I'll have enough to get it working properly. Kudos on the nice ascii art too, that looks like and must have taken a while. I appreciate it.

Reply
  • Thank you all for the help and thank you hmolesworth for really explaining it and providing example code. Between you and Torbjørn I'm sure I'll have enough to get it working properly. Kudos on the nice ascii art too, that looks like and must have taken a while. I appreciate it.

Children
  • My hat of to you Hugh, that is a much better solution. I will make sure to keep it in mind it for future reference Slight smile

    Best of luck James, hope you get this working nicely!

    Regards
    Torbjørn