From 6a1bdb121b5689f5ccc8d759f20f9db2aa31b06a Mon Sep 17 00:00:00 2001 From: Matthew Eshleman Date: Sat, 26 Jul 2025 08:59:46 -0500 Subject: [PATCH 1/3] Additions to the schematic review checklist, GPIO section. --- _posts/2024-07-18-schematic-review-checklist.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/_posts/2024-07-18-schematic-review-checklist.md b/_posts/2024-07-18-schematic-review-checklist.md index f191f8c0..dffb2ea5 100644 --- a/_posts/2024-07-18-schematic-review-checklist.md +++ b/_posts/2024-07-18-schematic-review-checklist.md @@ -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? - [x] Are the debug GPIOs used _only_ for debug purposes? ### Busses From 107888a8a55e457b303c8bc06ad249737c47ce20 Mon Sep 17 00:00:00 2001 From: Matthew Eshleman Date: Mon, 18 Aug 2025 14:08:25 -0500 Subject: [PATCH 2/3] Update _posts/2024-07-18-schematic-review-checklist.md Co-authored-by: Mark Schulte --- _posts/2024-07-18-schematic-review-checklist.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/_posts/2024-07-18-schematic-review-checklist.md b/_posts/2024-07-18-schematic-review-checklist.md index dffb2ea5..3e697221 100644 --- a/_posts/2024-07-18-schematic-review-checklist.md +++ b/_posts/2024-07-18-schematic-review-checklist.md @@ -203,15 +203,11 @@ 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] Include configuration of peripherals -> GPIOs to ensure any MCU-specific + pin sharing constraints are met. + - [x] Include other associated MCU resources, such as DMA or timers, to ensure + that each of those resources are used only once. - [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 From 9a52b3df780b5a54bd1bf1381941ada299cee1e3 Mon Sep 17 00:00:00 2001 From: Matthew Eshleman Date: Mon, 18 Aug 2025 14:13:34 -0500 Subject: [PATCH 3/3] move debug GPIO portion to Debug/Test Infrastructure --- _posts/2024-07-18-schematic-review-checklist.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/_posts/2024-07-18-schematic-review-checklist.md b/_posts/2024-07-18-schematic-review-checklist.md index 3e697221..63ce9549 100644 --- a/_posts/2024-07-18-schematic-review-checklist.md +++ b/_posts/2024-07-18-schematic-review-checklist.md @@ -212,13 +212,6 @@ Given these experiences, I have compiled the following list: 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? -- [x] Are the debug GPIOs used _only_ for debug purposes? ### Busses @@ -253,6 +246,13 @@ Given these experiences, I have compiled the following list: - [x] Are non-essential, but helpful, GPIOs exposed for a debugger, such as SWO or ETM? - [x] Do test points exist for power rails, analog signals, and buses? +- [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? +- [x] Are the debug GPIOs used _only_ for debug purposes? ## Conclusion