MCU startup failure: why does the board only boot with the debugger?
AI-generated illustration: The Electronics Brief
Fictional case study; measurements and outcomes are illustrative.
Last week’s answer: qualification evidence and lot traceability
Last week’s supplier change left the team with six weeks of approved stock while qualification coverage and lot identification remained unresolved. Before releasing material made by the new process, they needed to know whether the qualification evidence covered this interface IC in its intended application, particularly the humidity exposure, and whether the distributor could identify which production lots it would deliver.
Engineering asked the supplier to connect the qualification results for the component family to the affected device, package, assembly site and mould compound. They asked which test vehicles had been used, why those results covered this device and whether any results were outstanding. Without that connection, a statement that the family had passed would not tell them enough about the material they were being asked to approve.
TI’s published PCN process gives a useful example of the information a supplier provides: affected products, expected impact, qualification information, sample availability and projected shipment dates. It provides a useful basis for the questions, although the response still has to come from the supplier responsible for the change. [1]
The team also required a documented way to distinguish old and new production on the actual deliveries. Purchasing could then segregate stock by approval status, with the distributor’s lot information carried through receiving and production records. That made approval status available when the material arrived, before it could be issued to a build.
The application review focused on the existing requirements for humidity exposure and analogue accuracy. It defined which supplier evidence could be accepted, what additional application testing was justified and the release criteria for the new material. The supply plan included chamber access and test duration as well as the two weeks needed to obtain samples, making the likely release timing clearer.
Production could therefore continue with approved stock from the original process while the new material remained on hold. The release conditions were tied to the missing evidence and the application’s requirements, with the work and timing reflected in the supply plan.
This week’s challenge: it only works with the debugger
A 3.3 V controller passes its development tests whenever the debugger launches the application, but disconnect the debugger and a cold start leaves the status LED dark. A manual reset about a tenth of a second after applying power usually restores operation, suggesting that the difference may lie somewhere in the startup sequence.
The MCU shares its regulated rail with an analogue front end connected by SPI. During startup, firmware reads the front end’s identity and stops initialisation if the response is wrong.
For this case, a capture at the actual devices shows the rail settling before the first SPI transaction. The standalone application sends that transaction about 1.5 ms after power on and receives all ones. When launched through the debugger, its first transaction occurs around 120 ms after power on and returns the expected identity. Loading the same firmware image into flash again makes no difference.
A READY signal from the front end changes state at about 14 ms. The team has not yet established whether that signal governs the first legal register access. It has also not separated the debugger’s electrical connections from the timing effects of its launch sequence.
Which experiment would distinguish the two?
A test with the debugger attached but no active session could help separate its electrical connections from the effect of its launch timing. A standalone test with controlled reset timing offers another comparison, with the MCU reset, supply, chip select and READY captured together.
What would you look for in the front end’s startup specification? If a delayed reset restores operation, what further evidence would distinguish a firmware timing fault from a supply, reset or boot configuration issue?
The answer follows on 12 November. Send your reasoning, or a problem of your own, through the Troubleshooter page.
