Date: Thu, 26 Jan 2017 14:33:25 -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: <1485466405.30533.96.camel@freebsd.org> In-Reply-To: <040101d27816$3f7547b0$be5fd710$@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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,UNKNOWN> > pin 01: 0 gpio_1<IN,PD>, > caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN> > pin 02: 0 gpio_2<>, > caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN> > ... > > 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. > > > > > > 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. > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1485466405.30533.96.camel>