Boot Failure Root-Caused to a SYSBOOT Pin Conflict
Description
A network cable tester built around a Sitara AM4379 application processor would not boot. The board powered up, rails were correct, and there was no visible fault — it simply never started.
The client had already spent time on firmware and power before bringing the board in for diagnosis.
The Fault
The AM4379 samples a group of SYSBOOT pins at reset to decide where to boot from. Those pins are dual-purpose: after reset they become ordinary I/O, so it is easy to assign them a peripheral function during design and never notice the conflict.
One of the SYSBOOT lines had been given a second function whose idle state changed the sampled boot value. The processor was reading a boot mode that did not correspond to any device present on the board, so it never began execution.
Nothing was broken. The board was doing exactly what it had been told to do.
Why It Was Hard To Find
This class of fault presents as a dead board with healthy rails, which sends most debugging toward power and firmware — the two places it is not. The evidence is in the boot-mode strap table in the datasheet, cross-referenced against the idle state of every net attached to those pins.
Finding it is a matter of knowing where to look, not of instrumentation.
Deliverables
- Root cause identified with the responsible net named
- Boot-strap table cross-referenced against the schematic
- Rework path for existing hardware, and the schematic fix for the next revision
Published without client, project name, or location under NDA. Silicon and findings are unchanged.