BBB uarts & pps dts definitions

[Tony Hain]

> -----Original Message-----
> From: Ian Lepore [mailto:ian at freebsd.org]
> Sent: Thursday, January 26, 2017 1:33 PM
> To: Tony Hain; freebsd-arm at 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