diff --git a/_posts/2024-07-18-schematic-review-checklist.md b/_posts/2024-07-18-schematic-review-checklist.md
index f191f8c0..63ce9549 100644
--- a/_posts/2024-07-18-schematic-review-checklist.md
+++ b/_posts/2024-07-18-schematic-review-checklist.md
@@ -203,12 +203,15 @@ 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] 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] Are the debug GPIOs used _only_ for debug purposes?
 
 ### Busses
 
@@ -243,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