My bet is you haven’t connected the GNDs correctly. Good design practices dictates that you connect all the GNDS to a single common point so that it looks like a star configuration. Think of every supply line has to be matched with a return line that connects to a GND source. If the GND for your 120VAC relay connects across the BBB ground plane, then you will see all kinds of problems. You external circuitry should only connect to the GND of the 5V barrel pin and not any of the other connectors or on the other side of the 5V cable. The BBB layout is good so I don’t believe it will be a EMC/SI issue.
Regards, John > On Mar 9, 2016, at 4:17 PM, [email protected] wrote: > > > I am working on a project where I have made modifications to the > beaglebone_pru_adc package available on GitHub here: > https://github.com/pgmmpk/beaglebone_pru_adc > <https://github.com/pgmmpk/beaglebone_pru_adc> > > The code loads in firmware as a *.bin file to run on the pru. It is complied > PRU assembly from a *.p file. > > My modifications were to implement a circular buffer in DDR based on the > oscilloscope_data() function in the module. This code grabs samples from the > adc like in the original code and stick the samples in DDR, but it also > updates memory pointers to wrap around. It loops indefinitely and respects > the cap_delay attribute. > > The board is connected to provide fine grain analog data logging via current > transformer and voltage transformer on demand courtesy of the PRU. For > instance enabling RMS waveform calculation. I have also written a python > class that drives a latching relay. For test purposes I hooked a heavy ~10A > load to the relay. The PRU loop runs fine indefinitely using the analog log > to display RMS in the python code space. However, the PRU loop continues > running after the load is switched on or off but the PRU continues looping > only intermittently. The load is resistive, yet clearly the interruption is > correlated with switching the load on or off. Sometimes the PRU continues > running and sometimes it stops running but only during a switching event. > > I understand BeagleLogic.net may be a good lead to follow. In the meantime, I > watch for the PRU to stop loading new samples into the DDR. Then I restart > it. Very kludgy. My question is have you seen anyone with similar problems > switching heavy load and using the PRU? Is there maybe an interrupt you think > might be breaking the PRU out of its loop? I can post code if it helps. > > I really like these PRUs. Very slick to get real-time capabilities plus the > convenience of linux and speed of python prototyping. > > Thanks, > Cressel Anderson > > -- > For more options, visit http://beagleboard.org/discuss > <http://beagleboard.org/discuss> > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
