Schematic reviews are a part of the hardware development cycle in many if not
most, hardware development companies. Typically led by the electrical
engineering team, it is easy to overlook design issues that will be important to
the firmware team. This post tells of a few stories of design misses that I have
made and puts some common lessons learned into a checklist for other firmware
engineers. It is not meant to be an exhaustive list, but rather a starting point
for a firmware engineer to build their own checklist with the goal of helping
teams catch software/hardware interaction bugs earlier in the design cycle when
they’re cheaper to fix.
That I2C reset issue, we also ran into it, but it was thankfully during development. Programming the MCU would of course reset it, and that sometimes happened during an I2C transaction.
Good call about those brownout loop.
One thing I started doing, working in a small company, is actually designing the pinouts myself. As a firmware engineer, I’m often much more familiar with the microcontrollers than the EE. I’ll of course discuss it, learn what are the directions a bus would go, but there’s a chance I’ll catch something the EE wouldn’t.
Also, re: debugger and logs. I’ve found that while a debugger is great for solving a bug, logs are preferable to find out where the bug happened in the first place.
As a hardware engineer in a small company, I also let my firmware engineer choose the pinouts. I figured that choice should be made by the one writing the fw. We do discuss the choices together though (and any external circuitry needed).