So, you are using the actual Beaglebone board in a production product? I kind of seen them as just prototyping platforms.
How are the sensors connected to the Beaglebone? Direct or do you have some sort of driver between the sensor and the BB GPIO pin? I would think the later is the best option. How is your software communicating with the sensors via the BB? Have you checked either 'dmesg' or '/var/log/syslog' on BB to see if any events were seen at the time the issue was seen? This may give a clue as to what is happening. Cheers, Jon On Wed, Oct 7, 2020 at 3:02 AM Gwen Stouthuysen <[email protected]> wrote: > You might start with hardening the solution by moving the application from > JS to a compiled C program. > I never had issues with locking up peripherals when using C. > > Traditionally a watchdog feature is used to reboot the system when lockups > are preventing the normal continuation of the program. > I think the TI processor has watchdog circuitry, not sure whether you can > access it from the Linux OS (it might already use it to ensure OS lockups > invoke reboots), quite sure JS will have no features with respect to this. > > just my 5c > > Gwen > > Op wo 7 okt. 2020 om 10:41 schreef [email protected] < > [email protected]>: > >> Hello beaglebone community, >> >> This is my first post. >> >> I used beaglebone to develop a prototype for for a self-cleaning >> smoothie machine that we plan to commercialize (see video below). It has >> multiple sensors and outputs to run motors/solenoids while ensuring user >> safety. >> >> https://www.youtube.com/watch?v=76XDJK5V0PA&feature=share&; >> ab_channel=PascalKriesche >> >> Right now we have. BBB running a linux OS and running a script we >> wrote in JS. One issue we have had was the 1.8V analog sensors losing >> signal which required us to reboot the system every tie that occurred. We >> also had an issue flashing 2 out of our 4 prototypes with an image that >> worked (seems to be a firmware version issue leasing to an incorrect >> hardware pin mapping). >> >> I know eventually we want to use a chip on board, but for the initial >> production run we were hoping on sticking to a prebuilt onboard computing >> module for the initial 1000 units in order to save time and costs. I was >> wondering if anyone in this forum had experience launching a product with >> beaglebone and if this instability can be resolved with the correct I/O >> filtering on our PCB and software functionality. >> >> Thanks in advance! >> >> -- >> 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]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/faf26e97-c403-4dac-adc8-7acede4832b9n%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/faf26e97-c403-4dac-adc8-7acede4832b9n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CAFfeaG_q4y_OjWOJyotqYe-ysABMxd3dzwag-hNp6ZpsAeCZqw%40mail.gmail.com > <https://groups.google.com/d/msgid/beagleboard/CAFfeaG_q4y_OjWOJyotqYe-ysABMxd3dzwag-hNp6ZpsAeCZqw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAG99bkpccSUpkEj3Q8xNKgDYpuL5xcD3ZnT4VbOL8%3DqYe7pFgQ%40mail.gmail.com.
