Date: Thu, 26 Jan 2017 21:17:36 -0700 From: Ian Lepore <ian@freebsd.org> To: Tony Hain <tony@tndh.net>, freebsd-arm@freebsd.org Subject: Re: BBB uarts & pps dts definitions Message-ID: <1485490656.30533.111.camel@freebsd.org> In-Reply-To: <041a01d2782d$bee11850$3ca348f0$@tndh.net> References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> <1485400906.30533.54.camel@freebsd.org> <03bb01d2779d$45d6edd0$d184c970$@tndh.net> <03c101d277ae$70f142c0$52d3c840$@tndh.net> <1485445768.30533.68.camel@freebsd.org> <040101d27816$3f7547b0$be5fd710$@tndh.net> <1485466405.30533.96.camel@freebsd.org> <041a01d2782d$bee11850$3ca348f0$@tndh.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2017-01-26 at 15:41 -0800, Tony Hain wrote: > > > > > -----Original Message----- > > From: Ian Lepore [mailto:ian@freebsd.org] > > Sent: Thursday, January 26, 2017 1:33 PM > > To: Tony Hain; freebsd-arm@freebsd.org > > Subject: Re: BBB uarts & pps dts definitions > > > > On Thu, 2017-01-26 at 12:53 -0800, Tony Hain wrote: > > > > > > Ian Lepore wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > snip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Even when it gets built though, the scope shows that the > > > > > > signal > > > > > > is being pulled to ground as soon as the wire is connected > > > > > > to > > > > > > P8- 7, so I don't > > > > > expect it > > > > > > > > > > > > > > > > > > > > > > > > to work. Is there a way to check the state of the gpio? I > > > > > > would > > > > > > expect something like # gpioctl -N gpio_66 Can't find pin > > > > > > named > > > > > > "gpio_66" > > > > > > > > > > > > # gpioctl -l > > > > > > pin 00: 0 gpio_0<> > > > > > > pin 01: 0 gpio_1<> > > > > > > ... > > > > > > pin 30: 1 gpio_30<IN,PU> > > > > > > pin 31: 1 gpio_31<IN,PU> > > > > > > # > > > > > > > > > > > > How do the 3 additional pinmux controllers get enabled? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ./ppsapitest /dev/dmtpps > > > > > > > > > > > > > > You should get something like: > > > > > > > > > > > > > > 1485400775 .009578536 204 0 .000000000 0 > > > > > > > 1485400776 .009621995 205 0 .000000000 0 > > > > > > > 1485400777 .009665453 206 0 .000000000 0 > > > > > > > 1485400778 .009708869 207 0 .000000000 0 > > > > > > > > > > > > > > -- Ian > > > > Everything I'm doing is with 12-current, but things shouldn't > > > > be > > > > very > > > different > > > > > > > > > > > > in 11-stable. > > > > > > > > Pin P8-7 is pin 2 on controller 2, so > > > > > > > > gpioctl -f /dev/gpcio2 -l > > > > > > > > when it's configured correctly it should look like: > > > > > > > > pin 02: 0 gpio_2<> > > > # gpioctl -lv -f /dev/gpioc2 > > > pin 00: 1 gpio_0<IN,PU>, > > > > > caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKN > > OWN> > > > > > > pin 01: 0 gpio_1<IN,PD>, > > > > > caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKN > > OWN> > > > > > > pin 02: 0 gpio_2<>, > > > > > caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKN > > OWN> > > > > > > ... > > > > > > So it looks like gpioctl defaults to the first controller if none > > > are > > > listed, since gpioctl -lv only shows the first 32. Nothing in > > > gpioctl > > > -h indicates that would be the case, though the framework wiki > > > does > > > mention a restriction at 32 in the hint files discussion. Nothing > > > in > > > -h, the man page, or the wiki indicates what -t -c or -n do, so I > > > am > > > reluctant to try them. I would guess toggle, capabilities, and > > > name, > > > but the help and documentation should really be clear about that, > > > and > > > how to set direction. > > > > > All good points, but really, gpio has nothing to do with this > > stuff. > Simply trying to figure out how to diagnose the gpio pin, and the ctl > tool > is not clear about how to use it. > > > > > > > > > > > > > > > > > > > > > > > > If you do a verbose boot (in loader, at the prompt do boot -v) > > > > do > > > > you see > > > > these two lines right before the am335x_dmtimer0: line? > > > > > > > > ti_pinmux0: setting internal 2a for timer4 > > > > am335x_dmtpps: configured pin P8-7 as input for timer4 > > > Booting from disk0s2a: > > > /boot/kernel/kernel data=0x6d6564+0x145a9c > > > syms=[0x4+0x7eb30+0x4+0x922fa] > > > /boot/kernel/am335x_dmtpps.ko text=0x1c60 data=0x224+0x8 > > > syms=[0x4+0x820+0x4+0x742] > > > > > > loader> boot -v > > > > > > # dmesg | grep er4 > > > ti_pinmux0: setting internal 2a for timer4 > > > am335x_dmtpps: configured pin P8-7 as input for timer4 > > Yep, this indicates the config is right, so the problem must be > > electrical. > > > > > > > > am335x_dmtpps0: <AM335x PPS-Capture DMTimer4> mem 0x48044000- > > > 0x480443ff irq > > > 30 on simplebus0 > > > Timecounter "DMTimer4" frequency 24000000 Hz quality 1000 > > > am335x_dmtpps0: Using DMTimer4 for PPS device /dev/dmtpps > > > > > > So all that looks as you indicated it should, though I am > > > troubled > > > that pin > > > 2 is not restricted to IN on the gpioctl listing. It does say > > > configured as > > > input in dmesg, so it should be doing the right thing. > > > > > Pin 2 is not listed as <IN> because it's not a gpio pin anymore > > after > > being reconfigured as TIMER4 input. The empty brackets indicate > > that > > it has been configured as a device pin, not gpio. > Ok. That is another point that would be helpful if it were on the > wiki. > > > > > > > > > > > The only thing that comes to mind at this point is some > > > electrical > > > restriction about the BBB input, where a 5/3 resistive divider > > > (2.2k/3.3k) > > > is inadequate, but the fact that the uart is working would tend > > > to > > > rule that > > > out. Electrically it is acting as though the pin is set to Output > > > at > > > 0. > > > ...... As I typed that it occurred to me I should really check > > > that > > > it is 0, > > > and found that there actually is a correct pulse at 60mv. This > > > would > > > imply > > > that the input impedance of the pin is 26 ohms. The system > > > reference > > > manual > > > doesn't discuss input impedance that I can find, and search isn't > > > turning up > > > anything either. Why would the timer pin be different than the > > > uart > > > pin on > > > the same soc? What are you using to drive your pps? > > > > > > This is so close, there must be something really trivial that I > > > am > > > overlooking... > > > > > > Tony > > I'm using a 5v->3.3v level shifter right now, but I have in the > > past > > succesfully used resistive dividers. My PPS output device is > > designed > > to drive 5v into a 50 ohm load, so when using a divider I just try > > various values I have handy until my scope says the voltage high > > level > > is somewhere in the 2.8-3.3v range. Usually I use resistance that > > adds > > up to somewhere between 40-100 ohms when I do that (depends on what > > resistors pop out first when I reach into the bag of loosies). > > > > -- Ian > That makes some degree of sense based on what I am seeing, though > that is a > very low input impedance on the BBB. I was expecting ~100k. My source > is a > 555 on an ancient ttl/RS232 board I built because the 20 us pulse > from the > GPS was too fast (between the slew rate of the 3232 and the DCD > detection > window on the com port) to go with a simple level conversion. Sounds > like it > might be best to do an active 3.3v driver at this point. > > Tony > Well you were right, it all boiled down to electrical trouble, but it was caused by software, and I just committed a fix as r312859. I'll MFC the fix to 11 in a few days (you could just grab the patch/source from -current and build a new kernel now). Even though the code was asking the pinmux driver to configure the pin as an input, there is also a bit in the timer control register that configures the pin as input or output for capture vs. pulse mode. That setting apparently overrides the pinmux choice, so the timer block was driving a signal onto that pad. (The code had a comment next to one bit in the control register defines "no description in datasheet". That goes back to the original timer driver from years ago. A newer copy of the manual is where I discovered that the bit is now described as input/output config.) I think my testing was working because my level-shifter was able to out-muscle the weaker drive in the TI chip. As soon as I switched to a passive voltage divider it stopped working. Now with the pin configured correctly it works fine for me, and probably will for you too. I find that it captures pulses as narrow as 100nS perfectly now. A 10nS pulse it captures maybe 35% of the time. (My timing hardware has no choices between 10nS and 100nS to try.) -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1485490656.30533.111.camel>