<zmatt> Siegurd: can't you use a different pin? it would be best to avoid using any of the critical sysboot pins (the ones marked bright yellow in https://goo.gl/Jkcg0w#gid=1847985463 ) as inputs if possible. using them as outputs is fine although it may be wise to reinforce their (very weak) on-board pull-up/down resistor with an external one
<zmatt> I don't see how a diode would help here...
<zmatt> to safely use those pins as inputs you either need to ensure their level at power-on matches the on-board pull direction, or somehow keep them from being driven using power-up
<Siegurd> can you sugest what pin can be used
<Siegurd> ?
<zmatt> I was checking the AD7771 to reminder myself what it needs exactly
<zmatt> Siegurd: was your current plan to use PRU direct I/O (R31) or to use McASP ? I happen to have recently gained experience with using McASP from PRU so I can advise on that if needed
<Siegurd> I want to switch from P9 to P8 cuz of noise DCLK is making to BBB analog channels
<zmatt> ah right I remember now, you need all four data lines because the AD7771 didn't support the sample rate you desired if fewer DOUTs are used or something like that
<zmatt> lemme see what the options are here
<Siegurd> McASP from PRU sounds great. maybe it is worth to try.
<zmatt> there's definitely more pinmux options available than just the ones I listed there, let me tabulate them to see if there's any that would suit your needs better
vagrantc has quit [Quit: leaving]
vagrantc has joined #beagle
shoragan has quit [Quit: quit]
shoragan has joined #beagle
<zmatt> Siegurd: sorry for the delay, table of all mcasp pinmux options for receive-only slave: https://docs.google.com/spreadsheets/d/1VZTrNGzmg51MXX5ElYYMsJwjOpe6JghDgerHbiMFd4M/edit?usp=sharing
<zmatt> (by signal and by pin)
<zmatt> using mcasp0 in async mode would avoid using P9.31 as clock
<zmatt> while still using the P9 header
<Siegurd> As far as I understand, there is no option to use P8 without 31 pin?
<zmatt> indeed... however I'm still trying to figure out what the initial state of the DOUT pins is at reset when using SPI control mode. given that it supports some modes where DOUT2/3 are inputs, presumably those are high-Z at reset so you could probably still use one of the P8 pinouts if the data lines are reordered
<Siegurd> Data lines DOUT1-4 completely surround the analog channels and influence them. Now I soldered the diode to pin 8.31 and everything works. The board is loading and the data is coming.
<zmatt> uhh, diode to/from what?
<Siegurd> I turn on AD7771 power by relay from BBB user space. The diode is soldered in series between DOUT1 and P8.31
<zmatt> I have trouble imagining what exactly you could have done with a diode here
<zmatt> hmmmm
<Siegurd> 1N4007
<zmatt> ew wait, you're configuring P8_31 as PIN_PULLDN rather than PIN_NOPULL ?
<zmatt> and rely on that to pull the pin low when the AD7771 is not driving the pin high via the diode?
<Siegurd> https://pastebin.com/W2jEWLzY that's may config
<zmatt> yeah... the sysboot pins should normally always be configure as PIN_NOPULL since they have external resistors and creating a conflict between the internal pull-down and external pull-up (or vice versa) results in an indeterminate level somewhere in between logic-low and logic-high
<zmatt> also, leaving the AD7771 off while the BBB is powered on is risky since you'd need to be really careful not to drive any of the signals from the BBB to the AD7771 high
<zmatt> and some SPI signals are high by default
<zmatt> which means you're probably injecting current via AD7771 spi pins which may damage the AD7771 (and possibly the AM335x depending on how much current is flowing)
<Siegurd> there are no input pins in AD7771 in my config. Its is a master device that starts send data on power on.
<zmatt> you're using the AD7771 in pin config mode rather than SPI config mode?
<Siegurd> Yes
<zmatt> hmm
<Siegurd> and those pins are soldered on evaluation board itself, so there is no need to configure anything
<zmatt> can you measure the voltage on the P8.31 pin when the AD7771 is off?
<zmatt> I'm still a bit concerned about the pull-up/down conflict
<Siegurd> its 0V, with no diode, DOUT1 connected
<zmatt> I meant with diode (or with the AD7771 not connected at all)
<Siegurd> 2.83V with diode, ad7771 power off
<zmatt> that's with the DT config as you showed?
<Siegurd> yes
<Siegurd> oh
<zmatt> i.e. show-pins is showing "down" as pull direction for that pin?
<zmatt> oh?
<Siegurd> its 0.6 after boot process ends
<Siegurd> so when bootloader does its things the P8.31 pin viltage is 2.83, and after kernel (DT) shows up the voltage is 0.6V
<zmatt> yeah so that's kinda marginal, given that an AM335x digital input is considered "low" when below 0.8V and "high" when above 2V
<zmatt> and undefined/indeterminate in between
<zmatt> so, I guess if it works it works, but you'll want to actually double-check your data on that line isn't getting corrupted
<Siegurd> Since the AD7771 and BBB boot are now working properly, (with a little diode black magic), the main problem that remains is PRU ADC freezing.
<zmatt> (and probably try to minimize wire length between diode and BBB)
<zmatt> didn't you say that occurred when you tried to probe it to do a measurement?
<zmatt> so would it be an acceptable solution to just... not do that? :P
<Siegurd> Sometimes freezes occur spontaneously (for example, after half an hour or an hour of operation), or when the relay is turned on. :)
<zmatt> i.e. environmental noise is somehow hitting the ADC in a way that causes it to lock up. I think the AM335x ADC is indeed known to be sensitive to such things
<zmatt> what are you measuring on the ADC inputs and how is that hooked up?
<Siegurd> I measure several resistive temperature sensors and pressure sensors with analog output. All sensors are connected to the AGND polygon. The AGND polygon is connected to the DGND via a ferrite bead.
<zmatt> hmm, I've heard very mixed opinions about using isolated ground planes... seems the common advice has converged to using a single solid ground plane
<zmatt> due to the risk of just creating opportunity for the isolated ground plane to act as an antenna or otherwise pick up noise
<zmatt> *picking
<Siegurd> here are the polygons. Upper - AGND polygon. Lower DGND polygon.
<Siegurd> I still have big doubts about this polygons layout.
<Siegurd> You're probably right, and AGND now works as a receiving antenna and catches interference. It would probably be correct to designate AGND not as a polygon, but as a star with separate paths to each component.
<Siegurd> Center connector is for AD7771.
starblue has quit [Ping timeout: 256 seconds]
<zmatt> I just checked all 8 of our devices running at the office, with a combined uptime of more than 1.5 years, and the ADC is happily running on all of them
<zmatt> Siegurd: yeah this immediately feels hazardous to me
starblue has joined #beagle
<zmatt> like, I'm not sure if I can put into words why it feels like that to me, but that pcb layout makes me go "I hope you know what you're doing..."
<zmatt> I certainly wouldn't be able to tell whether this avoids picking up noise or creates a nice antenna for picking up noise
<Siegurd> Do you think that if installing a 100K resistor instead of a ferite bead and/or short AGND and DGND in several places, this will improve the situation?
<zmatt> I really don't know, I'd have a lot more faith in a single continuous ground plane
<zmatt> I'm assuming there's a ground layer somewhere below this? since I see ground-stitching vias scattered around
<Siegurd> The ground layers are identical on both the bottom and top layers of the board.
<zmatt> also, what's the path taken for the power ground corresponding to the big 5V trace at the top right?
vagrantc has quit [Quit: leaving]
<zmatt> ah, two layer pcb? so no actual uninterrupted ground plane?
<zmatt> anyway, I'm not a hw designer and this sort of stuff is definitely kind of outside my domain of expertise, I've just absorbed bits of pieces over the years
<zmatt> but evidently something about this design is subjecting the ADC to problematic spikes
<Siegurd> I don’t quite understand "no actual uninterrupted ground plane?" and "what's the path taken for the power ground"
<zmatt> well, the image your showed contains a lot of ground, but it's a patchwork of small pieces of ground plane connected to each other via narrow paths and ground stitching vias
<zmatt> due to being interrupted by other traces
<zmatt> with a 2-layer pcb you don't really have much choice usually
<zmatt> but that can make it rather tricky to reason where exactly return currents will flow, and increases the probability that the best path it may find is not through the parts of the pcb labeled "GND" but by capacitively coupling to something else
<zmatt> it's also making it non-obvious (especially without seeing the other layer) where the power supply return current is flowing in your design (from the bbb to the power connector/header at the topright)
<zmatt> there's probably better resources out there than my attempts to explain something I don't understand all that well myself
<zmatt> TI has some stuff about split ground planes: https://www.ti.com/lit/an/slyt499/slyt499.pdf (part 2: https://www.ti.com/lit/an/slyt512/slyt512.pdf )
<zmatt> but they're putting the data converter on the analog island or straddling the analog and digital islands, neither of which is possible in your case since the converter is inside the AM335x
<zmatt> oh actually it seems the article I just linked is also quite cautious about split ground planes: "Although the split-plane approach can be made to work, it has many problems"
<Siegurd> Thanks for the help! In any case, I played it safe and added another ads1256 ADC for slow sensors, in case there were problems with the BBB ADC. Which arose :)
<zmatt> I know our hw designer used a single ground and just tried to keep analog stuff physically separated from digital stuff or anything involving fast switching signals
<zmatt> to try to keep the corresponding ground currents away from the sensitive analog parts
<Siegurd> Thanks for the information
<zmatt> but we do have an actual ground plane with no slots other than small circular cutouts for vias
<zmatt> two ground planes actually it seems in our current pcb (the older one was 4-layer, but we eventually switched to 6-layer)
weevoy has quit [Ping timeout: 264 seconds]
weevoy has joined #beagle
<Siegurd> I'll go to bed because I can barely stand on my feet. Thanks again for the info! I would also be very interested in implementing McASP on the PRU to relieve the processor and manage the data independently and abandon ALSA. I would appreciate any help with this.
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Posterdati has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
Posterdati has joined #beagle
hnv has quit [Ping timeout: 250 seconds]
KREYREN has joined #beagle
set_ has quit [Remote host closed the connection]
Posterdati has quit [Ping timeout: 268 seconds]
Posterdati has joined #beagle
set_ has joined #beagle
weevoy has quit [Ping timeout: 264 seconds]
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #beagle
bradfa has quit [Read error: Connection reset by peer]
bradfa has joined #beagle
Stat_headcrabed has joined #beagle
xet7 has quit [Quit: Leaving]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #beagle
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #beagle
KREYREN has quit [Ping timeout: 240 seconds]
KREYREN has joined #beagle
Posterdati has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
Posterdati has joined #beagle
KREYREN_ has joined #beagle
brook has quit [Remote host closed the connection]
vagrantc has joined #beagle
KREYREN has quit [Ping timeout: 240 seconds]
vagrantc has quit [Client Quit]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
set_ has quit [Remote host closed the connection]
vagrantc has joined #beagle
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #beagle
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #beagle
vagrantc has quit [Quit: leaving]
set_ has joined #beagle
xet7 has joined #beagle
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #beagle
Siegurd has quit [Read error: Connection reset by peer]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #beagle
KREYREN_ has quit [Remote host closed the connection]
ikarso has quit [Quit: Connection closed for inactivity]