Typically first thing I do is get the UART up and running.
From there write routines to unpack the peripheral registers of interest. This typically includes all of the PLL clocks, and the AHB/APB clocks are the MCU perceives them. Especially with the more complex clock routing on newer parts, associating PLL and Peripheral Clock muxes.
Get Hard Fault and Error handlers to quickly identify points of a failure.
I tend to limit myself to things of interest, and critical to the specific board, not looking to validate the entire IC.
I build out the functionality I'm using incrementally, checking things work, stressing the things I suspect are most fragile or problematic.
From a power side you turn everything on and drive it as hard as possible.
Run any oddness to ground, problems that look like random/unexplained anomalies might not be when in the hands of 100,000 customers.
>>Is there a known User Guide for MCU BringUp procedure? For both Hardware and Software aspects?
I come from a place where the bosses expected me to "Figure it Out", because I have degree in "That Stuff"
Having worked IC, SW and HW design, QA and support roles, you tend to know were the fabric of the universe is weakest, and where the application of pressure has the highest payoff.
With third-party hardware the documentation tends to be more opaque than it would if you had gate level information, net lists, and critical-path/design-rule-check reports.
Hire people who understand what they are doing, identify skills/abilities and involve in processes they excel at. These might not be their day-to-day roles, but know who to pick for special-teams, and get help to members that encounter difficulties.
Have bosses or colleagues who can break anything they touch, and give them test articles to work with.
Involve QA early, Involve Support early.
Reduce friction in the feed-back loop allowing customers and support to get frequent problems fixed quickly so you can focus on real problems/issues.
