Skip to content

Additions to the schematic review checklist, GPIO section. #594

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Sep 5, 2025
Merged

Additions to the schematic review checklist, GPIO section. #594

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6a1bdb1
Additions to the schematic review checklist, GPIO section.
mattheweshleman Jul 26, 2025
107888a
Update _posts/2024-07-18-schematic-review-checklist.md
mattheweshleman Aug 18, 2025
9a52b3d
move debug GPIO portion to Debug/Test Infrastructure
mattheweshleman Aug 18, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions _posts/2024-07-18-schematic-review-checklist.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -204,10 +204,24 @@ Given these experiences, I have compiled the following list:
- [x] Provide a GPIO map in a spreadsheet, with main function after reset,
intended function, and any additional notes.
- [x] Are all MCU peripherals used only once?
- [x] Are all MCU peripherals mapped in manner to avoid any MCU-specific pin
sharing constraints?
- [x] Are all MCU peripherals requiring other MCU resources, such as DMA
or timers, mapped in a manner that avoids internal MCU sharing conflicts?
Example: a particular SPI bus may require exacting transaction timing,
which requires an MCU timer to initiate a DMA transaction on the particular
SPI bus. Is that device's SPI bus mapped in manner that avoids internal MCU
resource sharing constraints?
- [x] If the MCU is held in reset, are the peripheral devices held in their
proper state? (Pull-up/pull-downs where needed)
- [x] Does the reset line have a proper pull-up or pull-down? (This is a common
failure, so worth noting).
- [x] If the target microcontroller constraints allow for it, are some GPIO pins
assigned for arbitrary firmware development, measurements and debug
purposes? [6](https://covemountainsoftware.com/2016/12/27/brother-can-you-spare-a-gpio/)
- [x] Subject to board layout constraints, are the debug GPIOs routed to
test points that may be connected to an o-scope or other common
tools with minimal risk to the PCB or personnel?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great addition. What do you think about moving this to the Debug/Test infrastructure section? (And maybe leave a one-line note here?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

- [x] Are the debug GPIOs used _only_ for debug purposes?

### Busses
Expand Down