Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]]

[Bernd Walter]

On Mon, Mar 25, 2019 at 06:05:35PM +0100, Bernd Walter wrote:
> On Mon, Mar 25, 2019 at 10:52:26AM -0600, Ian Lepore wrote:
> > On Mon, 2019-03-25 at 17:48 +0100, Bernd Walter wrote:
> > > On Mon, Mar 25, 2019 at 11:33:32AM -0500, Karl Denninger wrote:
> > > > 
> > > > > What do you mean by an insane rate?  It's normal for the usb
> > > > > controller
> > > > > to be showing around thousands of int/sec.  Despite what seems
> > > > > like a
> > > > > high rate, even on an on rpi-b it uses under 2% cpu to service
> > > > > that.
> > > > > 
> > > > > root at rpi:~ # vmstat -i
> > > > > interrupt                        total       rate
> > > > > intc0,2: vchiq0                      2          0
> > > > > intc0,11: systimer0           10103206       1110
> > > > > intc0,17:-x_dwcotg0          218596055      24007
> > > > > intc0,28: bcm_dma0                 834          0
> > > > > intc0,61: iichb0                  5778          1
> > > > > intc0,65: uart0                   1817          0
> > > > > intc0,70:-dhci_bcm0                172          0
> > > > > Total                        228707864      25118
> > > > > 
> > > > > -- Ian
> > > > 
> > > > The story gets more odd.
> > > > 
> > > > The same *physical* unit that I saw this on last night with no I2c
> > > > device connected I restarted this morning -- changing NOTHING --
> > > > and it
> > > > disappeared.
> > > > 
> > > > But -- on another unit it's still there (I haven't shut down,
> > > > pulled
> > > > power and restarted that one.)
> > > > 
> > > > vmstat -i on both doesn't show anything all that odd:
> > > > misbehaving that's not there, and neither are the missed interrupt
> > > > complaints.
> > > > 
> > > > But again, last night the one that this morning is NOT misbehaving
> > > > WAS,
> > > > and was showing the exact same thing.
> > > > 
> > > > So this looks like something that is not being initialized property
> > > > at
> > > > boot time, and sometimes however it comes up causes trouble, and
> > > > other
> > > > times it does not -- which is likely to make it a "lot" of fun to
> > > > find.
> > > 
> > > By causing trouble - do you mean it doesn't work?
> > > I noticed that my system has this message:
> > > nxprtc0: RTC clock not running
> > > Warning: bad time from time-of-day clock, system time will not be set
> > > accurately
> > > This shouldn't happen, but I wonder if the iic communication works at
> > > all.
> > > I likely wouldn't notice if the rtc failed.
> > > Maybe there was an initial problem at start as you said.
> > > Will reboot it and see what happens.
> > > After a reboot the message about the rtc is gone.
> > > Have to wait at least a day to see if the Spurious are gone too.
> > > 
> > 
> > That's not a symptom of i2c comms failure, it's a symptom of a dead rtc
> > battery.  The driver has to communicate with the rtc chip to determine
> > that the oscillator was stopped.  After a reboot all is well, because
> > the rtc oscillator gets started when the time is written to the chip,
> > and it keeps running through a reboot and only stops on a power cycle.
> 
> Agreed, but there is a story behind.
> The board had a design flaw in that it drained the battery over the
> pullups into the Pi when the Pi was powered down.
> I fixed that circuit and did power down tests as well.
> Don't know if the previous boot was after power down, but it is
> unlikely that the battery is dead again and if it was a power down then
> it was a rather short one.
> It is not a test system, I run it 24/7 as a local ntp server since about
> only 1-2 months.

Well - lets reveal another point.
I have removed the pull ups completely, in the assumption that the Pi itself
has propper pull ups for at least short wiring.
It did work, so I left it that way.
So it could indeed be transfer errors by inadequate pull ups causing it.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.