Beaglebone Black Industrial External Supply decoupling

Hi there folks!

I have a custom board (Cape) which my beaglebone black industrial (BBBI) attaches to through headers.
I am supplying the BBBI through the headers on P9_05, P9_06.

I have the BBBI eMMC programmed with the Debian Buster IoT Image,
The issue I am facing is that, when I perform a power cycle (interruption of power to the Cape the BBBI is attached to, and therefore the BBBI also), the there is a probability of the BBBI not finding the OS on the eMMC and checking on the Console UART.
This results in the “CCCC…” appearing on the UART output.

I have tried a few things here, and what really reduced the possibility of the issue was reducing the decoupling on the Cape. However, the problem is still happens occasionally.

It seems to be that the power-on sequencing on the AM335X TI processor or the eMMC chip on the BBBI is being affected by too much decoupling external to the BBBI.

I would like to ask if there is a recommended circuit for my method of powering the BBBI and how much decoupling is recommended.
Is there a recommended method of conducting power cycles on the BBBI and a method to prevent this issue from happening irregardless of the amount of bypass capacitance on the Cape.

Are you able to post of pic of the board mounted in the cabinet so I can see how it is in relationship to other power conductors.

I am assuming you have the board mounted or is this on the bench?

Hi @foxsquirrel !

Thanks for the response.
I’m not really able to post pictures.

The tests are being done with the Cape already mounted on the BBBI, and this setup is on a benchtop being powered through a power supply running at 24V.
My final environment may supply me with up to 24V power source, so there is power conditioning on the Cape to step-down the input DC voltage to 5V, before feeding this to the BBBI through the header pins P9_05 and P9_06.

Hope this clarifies things?

Edit: (Power-Cycle Implementation)
The Cape has a RESET_N input pin which is used to perform the power-cycle, by using a PNP to short the Source and Gate of a PMOS in series on the 5V power rail, when the PNP’s Base (RESET_N) is pulled-down.
RESET_N is weakly pulled-up normally, to 5V before the series PMOS.

The option I am looking into at the moment is to actively drive the RESET_N net instead of relying on a weak pull-up to reduce possible delay effects on the PMOS turn-ON and so effect the power sequencing on the BBBI.

Not really, since you have it on the bench stuff like that is to be expected.

Your best tool would be to use a scope with an isolated differential probe or put an EMC probe on the spectrum analyzer and start looking around. If you can find the source of the noise you can fix it.

We do have good grounding across the boards.
EMC can also be a difficult issue to pin point and in my limited experience with EMC, its usually something else…

This issue is also only during power-cycle boot.
We don’t experience usual power interruption during operation which would mean a consistent EMC issue?

Does the fact that reducing the amount of decoupling capacitance on the Input Voltage reduces the probability of the issue occurring strongly point to EMC issues on the power cycle reset net?

My thoughts would be your power supply is the issue. BBB is single core and does not have the burden of a demanding HDMI chip. So during boot it should not be that demanding on the power supply.

Probe your power input in the frequency domain (FFT mode) in stead of time domain and look for peak frequencies and adjust your decoupling capacitance to focus on those specific frequencies. Adding capacitance in the wrong value or when its not needed can create more issues, its best to know exactly where you stand then chose values appropriately if you need them.

If you can measure the issue you will be able to find and resolve it, but where to look…