Something is interfering with PWM timing causing non-0/1 values to result in blinking #67
Comments
|
It's almost like there's some timing work done at startup which runs slowly due to fighting with other work, which then results in not enough data being fed to the PWM controller which leaves the pin high when it runs out of data on each cycle? |
|
Or could some other software I'm running be changing the rate of the PWM device, and re-running pi-blaster runs init_hardware to set it back? |
|
Do you have 2 instances running ? |
|
Yeah, that was my first thought as well - just the one (confirmed by ps aux) I probably should mention though - I do have one of the official 7" touchscreens hooked up to this device as well. I'm wondering if it's doing something with PWM config during X startup maybe? I intend to tinker a bit further with this software image + no screen to see if there's a connection there. Am I correct in assuming from reading init_hardware that if another process came along and changed the PWMCLK_DIV to another value, it could lead to this situation? I'm going to switch to a debug build and see what the debug_regs command gives in the broken situation and after restarting the service. |
|
Which Raspberry Pi do you have? I have read elsewhere that the pi3 does dynamic frequency scaling. That might affect the dma frequency and thus the pwm. |
|
I know at least one of the devices is a 3 (I broke one of the 2s during assembly and had to update the version of pi-blaster on my image to support it), but I most of them are 2s (though they'd be pretty recent 2s). I have 6 of these (I think 5x 2s and a 3) running a screen + pi-blaster-controlled light setup around the office, so at least I have repro cases :) I'll poke around further on the devices, just figured I should get some intel before stumbling around blindly. |
|
Sounds cool - any chance you could share a picture? |
|
It's an evolution of http://community.rightpoint.com/blogs/viewpoint/archive/2015/08/03/making-room-ninja-my-journey-to-improve-rightpoint-39-s-conference-room-status-display.aspx. Basically, we discovered the official R Pi touchscreens and moved the prototype in that direction. However, I'm a little behind on the blog series I was supposed to write on it's construction... I really only need red/green status indicators, but I've been playing around with trying to make them fade between colors and blink/fade to indicate certain things, hence using this library. When it works right, it looks really nice. When it doesn't, it looks like the color is being controlled by a two-year-old playing whac-a-mole :) |
|
A quick test for the pi3 frequency scaling is to set core_freq=250 and see if the issues persist. This should fix the GPU core frequency at it's lowest value, so it never has to scale. I've been using pi-blaster on a pi3 with no issues, basically since it was supported on the pi3. But, I've also had this setting configured so that I can properly use the /dev/ttyS0 UART, which is also impacted by the dynamic frequency scaling. |
|
Bleh... I start messing with this, and all the sudden I can't reproduce it.... One interesting note - I built with DEBUG and added clk_reg[PWMCLK_DIV] to the dump_regs output. I get this when launched at boot:
But this when launched from the command prompt afterwards:
If I'm reading the bits on DIV right, that's a frequency of 453 (1C5) from the command prompt and 494 (1EE) from the service, neither of which is 500, which makes me think I'm not understanding this. |
|
...and I go around the office - each one appears to have the blinking bug. So I reboot it to confirm before applying to core_freq fix, and each one works fine after the reboot. Maybe this isn't as reproducible as I thought. |
|
...and I left my original device alone for a few hours, and it's showing the issue, so changing core_freq doesn't help. I modified pi-blaster.c to dump some more info for debug_regs (namely the actual values at _DIV and _CTL that I now realize I wasn't looking at before), and this is what I get after startup when it's working:
Now to let it break and see if those values change... |
|
Now that I look at init_ctrl_data in more detail, if I'm understanding it right, it basically sets up a series of DMA instructions, alternating between "set value" and "wait for clock", and connects the end of the series back to the beginning. So it's not like something has to run every Xms to tell it to start the sequence over again - even if the clock was sped up or slowed down for some reason, that'd just stretch out the 'wave' being generated - it wouldn't cause it's duty cycle to change. |
|
@jorupp You are understanding the code right. The problem could be that something else is messing up the area in memory where we store the DMA instructions. Or something is messing up with the DMA controller configuration. |
|
Well, I have a non-debug build running on that machine with 'debug_regs' enabled, so now I just have to wait for it to go crazy again and I can compare that to what it was before and see if I can decode anything. |
|
If you have an oscilloscope or a Salae Logic Analyzer (strongly recommended btw), you could look at the shape of that signal. We might learn something from that. If the memory was just being corrupted, I am not even sure you would see the LEDs changing because the write address in the DMA instructions would be corrupted too. It's a weird problem. |
|
Checked today, and it's blinky again, with this config:
This is the big change - from:
Well, that's wrong... Now to find a culprit... |
|
What if you use the pcm clock instead of PWM ? Do you have HDMI attached ? There is a weird issue with the rpi_281x library on some platforms - OSMC in particular works only if the pi is started with HDMI attached on boot |
|
@jorupp try running pi-blaster with This part of the source might help you understand the difference. |
|
@penfold42 beat me to it! |
|
No HDMI attached - will give the PCM mode a try. Also took a few readings with a Salae Logic with different values substituted in for PWMCLK_DIV's value of 500 and got this when asking for a 50% duty cycle: http://i.imgur.com/Q1xM9TH.png. Values of 1 and 2 showed blinking (cycle was ~12Hz), but the others cycled far to fast to see, even 4 and 5 (5 being the value I got from the register in my earlier test). As would be expected, as the divider gets too small, it's not able to execute the instructions fast enough to have the desired effect. At least I think that's what's happening.... |
jorupp
changed the title
|
Thinking some more about the rpi_281x issue I wonder if there's a difference in how the hardware is initialized by the firmware with vs without HDMI attached |
|
Sure enough, switching to the PCM mode seems to have done the trick (6 devices, no blinking today). No idea what was resetting the PWM config, but it hasn't gone after PCM yet, so it seems like we're good, until I come up with a need for that for something else :) Thanks for the debugging help. |
|
@sarfata - should we consider pcb as the default ? |
|
@penfold42 sounds reasonable yes. I wish we had more data to make a decision though. |
|
Would the PCM mode interfere with the default audio? Or does this PCM not have anything to do with that. |
When I run pi-blaster as a service at startup, 0 and 1 values work fine, but other values result in that LED blinking pretty rapidly.
If I then restart pi-blaster, I get beautifully-consistent values all along the spectrum.
The text was updated successfully, but these errors were encountered: