SYN-39 - Complete the pin maps of 22 parts that cannot be exported for fabrication by JeffMboya · Pull Request #195 · absmach/synth

JeffMboya · 2026-10-15T05:34:07Z

What type of PR is this?

This is a bug fix.

What does this do?

Completes the pin maps of 22 parts, so registry qualify reports a structural finding on 3 rather than 24.

Which issue(s) does this PR fix/relate to?

Related Issue #39 and #43. Carved out of #102.

Have you included tests for your changes?

No. registry qualify and the footprint pin cross-check already check every part.

Did you document any new/modified features?

No new features. Each corrected file records what was wrong in a comment.

Notes

w5500_ethernet went from 8 declared pins to 48; xtal_8mhz's second terminal was a case pad.

rodneyosodo

One blocker inline (the PR is also CONFLICTING, so rebase).

… carries absmach#195 completes `mcp23017_gpio` from 4 pins to all 28 of the SOIC-28W, and in doing so takes the stock symbol's names: `gnd` becomes `v_ss`, `scl` becomes `sck`. This board connected the old two, so the moment that pin map lands its five `U7.gnd` / `U7.sck` statements are undefined pins (E-SYNTH-COMP-002) and the board stops compiling. The completed map arrives with the board that needs it, byte-identical to absmach#195's copy, so whichever of the two merges first the other converges without a conflict. Nothing else on this branch uses the part. Measured against a clean `main` build: main reports no undefined pin on this part, main plus absmach#195 reports five, and this commit takes it back to none. `vdd` and `sda` are the only pins the completed map marks required, and the board wires both, so no connectivity requirement arrives with it. Component and net counts are unchanged at 48 and 25. The outline does move with the pad set — 89.07 x 71.02 mm before and 95.07 x 76.02 mm after, both measured here — so the README's 109.68 x 90.79 mm is stale either way. Left as it stands rather than replaced with a figure this machine cannot verify: board outlines here depend on which KiCad library is installed.

Both this branch and absmach#195 completed these two parts independently, from the same symbols and the same footprints, and arrived at the same pin numbers. The files still differed: the comments told the story two ways, and this branch left the EEPROM's `scl` as `bidirectional` where absmach#195 made it `input`. `input` is the right type. SCL on an I2C slave is driven by the master; the 24LC256 does not stretch the clock, so the pin never leaves its input state. Nothing enforces this -- `i2c_scl` declares no required electrical type, so either value loads -- which is why the two branches could disagree silently. Both files are now byte-identical to absmach#195's, so whichever of the two merges first the other applies without a conflict, and the pin maps have one owner.

rodneyosodo

Prior blocker is fixed (required_decoupling now says vdd), but the pin rename left stale fixtures.

… carries absmach#195 completes `mcp23017_gpio` from 4 pins to all 28 of the SOIC-28W, and in doing so takes the stock symbol's names: `gnd` becomes `v_ss`, `scl` becomes `sck`. This board connected the old two, so the moment that pin map lands its five `U7.gnd` / `U7.sck` statements are undefined pins (E-SYNTH-COMP-002) and the board stops compiling. The completed map arrives with the board that needs it, byte-identical to absmach#195's copy, so whichever of the two merges first the other converges without a conflict. Nothing else on this branch uses the part. Measured against a clean `main` build: main reports no undefined pin on this part, main plus absmach#195 reports five, and this commit takes it back to none. `vdd` and `sda` are the only pins the completed map marks required, and the board wires both, so no connectivity requirement arrives with it. Component and net counts are unchanged at 48 and 25. The outline does move with the pad set — 89.07 x 71.02 mm before and 95.07 x 76.02 mm after, both measured here — so the README's 109.68 x 90.79 mm is stale either way. Left as it stands rather than replaced with a figure this machine cannot verify: board outlines here depend on which KiCad library is installed.

Both this branch and absmach#195 completed these two parts independently, from the same symbols and the same footprints, and arrived at the same pin numbers. The files still differed: the comments told the story two ways, and this branch left the EEPROM's `scl` as `bidirectional` where absmach#195 made it `input`. `input` is the right type. SCL on an I2C slave is driven by the master; the 24LC256 does not stretch the clock, so the pin never leaves its input state. Nothing enforces this -- `i2c_scl` declares no required electrical type, so either value loads -- which is why the two branches could disagree silently. Both files are now byte-identical to absmach#195's, so whichever of the two merges first the other applies without a conflict, and the pin maps have one owner.

JeffMboya · 2026-10-21T09:02:12Z

Three fixtures now connect U1.vdd/U2.vdd; E-SYNTH-COMP-002 gone, named codes intact. eebf10e.

… carries absmach#195 completes `mcp23017_gpio` from 4 pins to all 28 of the SOIC-28W, and in doing so takes the stock symbol's names: `gnd` becomes `v_ss`, `scl` becomes `sck`. This board connected the old two, so the moment that pin map lands its five `U7.gnd` / `U7.sck` statements are undefined pins (E-SYNTH-COMP-002) and the board stops compiling. The completed map arrives with the board that needs it, byte-identical to absmach#195's copy, so whichever of the two merges first the other converges without a conflict. Nothing else on this branch uses the part. Measured against a clean `main` build: main reports no undefined pin on this part, main plus absmach#195 reports five, and this commit takes it back to none. `vdd` and `sda` are the only pins the completed map marks required, and the board wires both, so no connectivity requirement arrives with it. Component and net counts are unchanged at 48 and 25. The outline does move with the pad set — 89.07 x 71.02 mm before and 95.07 x 76.02 mm after, both measured here — so the README's 109.68 x 90.79 mm is stale either way. Left as it stands rather than replaced with a figure this machine cannot verify: board outlines here depend on which KiCad library is installed.

Both this branch and absmach#195 completed these two parts independently, from the same symbols and the same footprints, and arrived at the same pin numbers. The files still differed: the comments told the story two ways, and this branch left the EEPROM's `scl` as `bidirectional` where absmach#195 made it `input`. `input` is the right type. SCL on an I2C slave is driven by the master; the 24LC256 does not stretch the clock, so the pin never leaves its input state. Nothing enforces this -- `i2c_scl` declares no required electrical type, so either value loads -- which is why the two branches could disagree silently. Both files are now byte-identical to absmach#195's, so whichever of the two merges first the other applies without a conflict, and the pin maps have one owner.

… carries absmach#195 completes `mcp23017_gpio` from 4 pins to all 28 of the SOIC-28W, and in doing so takes the stock symbol's names: `gnd` becomes `v_ss`, `scl` becomes `sck`. This board connected the old two, so the moment that pin map lands its five `U7.gnd` / `U7.sck` statements are undefined pins (E-SYNTH-COMP-002) and the board stops compiling. The completed map arrives with the board that needs it, byte-identical to absmach#195's copy, so whichever of the two merges first the other converges without a conflict. Nothing else on this branch uses the part. Measured against a clean `main` build: main reports no undefined pin on this part, main plus absmach#195 reports five, and this commit takes it back to none. `vdd` and `sda` are the only pins the completed map marks required, and the board wires both, so no connectivity requirement arrives with it. Component and net counts are unchanged at 48 and 25. The outline does move with the pad set — 89.07 x 71.02 mm before and 95.07 x 76.02 mm after, both measured here — so the README's 109.68 x 90.79 mm is stale either way. Left as it stands rather than replaced with a figure this machine cannot verify: board outlines here depend on which KiCad library is installed.

Both this branch and absmach#195 completed these two parts independently, from the same symbols and the same footprints, and arrived at the same pin numbers. The files still differed: the comments told the story two ways, and this branch left the EEPROM's `scl` as `bidirectional` where absmach#195 made it `input`. `input` is the right type. SCL on an I2C slave is driven by the master; the 24LC256 does not stretch the clock, so the pin never leaves its input state. Nothing enforces this -- `i2c_scl` declares no required electrical type, so either value loads -- which is why the two branches could disagree silently. Both files are now byte-identical to absmach#195's, so whichever of the two merges first the other applies without a conflict, and the pin maps have one owner.

… carries absmach#195 completes `mcp23017_gpio` from 4 pins to all 28 of the SOIC-28W, and in doing so takes the stock symbol's names: `gnd` becomes `v_ss`, `scl` becomes `sck`. This board connected the old two, so the moment that pin map lands its five `U7.gnd` / `U7.sck` statements are undefined pins (E-SYNTH-COMP-002) and the board stops compiling. The completed map arrives with the board that needs it, byte-identical to absmach#195's copy, so whichever of the two merges first the other converges without a conflict. Nothing else on this branch uses the part. Measured against a clean `main` build: main reports no undefined pin on this part, main plus absmach#195 reports five, and this commit takes it back to none. `vdd` and `sda` are the only pins the completed map marks required, and the board wires both, so no connectivity requirement arrives with it. Component and net counts are unchanged at 48 and 25. The outline does move with the pad set — 89.07 x 71.02 mm before and 95.07 x 76.02 mm after, both measured here — so the README's 109.68 x 90.79 mm is stale either way. Left as it stands rather than replaced with a figure this machine cannot verify: board outlines here depend on which KiCad library is installed.

…0 ep, xtal description)

rodneyosodo · 2026-11-02T07:57:38Z

Addressed review: renamed W5500 1v2o to core_1v2, reserved pads 23/38-42 to do_not_connect; added i2c_scl to MCP23017 pin 12 (renamed scl); added MPU6050 exposed pad 25 as footprint_only; updated xtal_generic description to 4-pad.

SammyOina

Approved conditionally. The latest commit addresses the remaining W5500, MCP23017, MPU6050, and crystal metadata issues. Please merge only after all required CI checks pass successfully on the latest head.

`jst_ph_3pin`, `jst_ph_4pin`, `jst_xh_2pin` and `jst_xh_4pin` all declared `footprint_dimensions` of 1.0 x 1.6 mm — the size of one contact, not the connector. `jst_ph_3pin`'s real courtyard is 8.9 x 8.6 mm. `synth registry qualify` reports this as `E-SYNTH-QUAL-006`, a declared package size that disagrees with the footprint's own pad extent, on all four. The exporter consults these values when it has to synthesize a footprint, and a 1 mm courtyard where an 8.9 mm connector goes is a part that places into its neighbour. Measured from the stock footprints rather than estimated.

`xtal_8mhz` and `xtal_generic` both name `Crystal:Crystal_SMD_3225-4Pin_3.2x2.5mm`, a four-pad package, and both declared two pins: `p1` on pad 1 and `p2` on pad **2**. On an SMD3225 the two crystal terminals are pads 1 and 3, diagonally opposite each other. Pads 2 and 4 are the grounded case. So `p2` named the case tab, and every board that drove `p2` drove the can rather than the crystal. `p2` now carries pad 3 and keeps its name, so no board source changes. The two case tabs are declared as `case_1` and `case_2`, which also clears the `E-SYNTH-QUAL-002` both parts reported: two copper pads no pin declared. The symbol follows. `Device:Crystal` is the two-pin symbol; the four-pad part is `Device:Crystal_GND24`, which is the one that says the case pads exist.

`synth registry qualify` reports `E-SYNTH-QUAL-002` — "footprint has copper pads no pin declares" — on twenty of the 124 shipped parts. It is on the structural allow-list, so `E-SYNTH-QUAL-000` refuses a fab export over it with no override: those parts cannot be submitted for manufacture at all. The pads are not cosmetic. `w5500_ethernet` declared 8 pins of a 48-pad LQFP-48; `esp32_wroom_32` left 39 pads undeclared; `mpu6050_imu` declared 3 of 25. A pad nothing declares is copper the router does not know about and the netlist cannot reach, which is what the finding's own text calls a short waiting to happen. Sixteen parts here, with their pin maps completed against the stock KiCad symbol and footprint each one names: w5500_ethernet esp32_wroom_32 nrf52840 stm32g030 txs0108e mcp23017_gpio pca9685_pwm micro_usb_b 24lc256_eeprom at24c512_eeprom m24m02_eeprom bq24074 tps22918_loadswitch ant_helical_433mhz mpu6050_imu tmp117_temperature Carried from the SYN-39 branch, but re-derived rather than copied: a three-way merge against the common ancestor, because `main` has since added `max_power_mw` and `thermal_resistance_c_per_w` to `bq24074`, `esp32_wroom_32`, `nrf52840` and `tps22918_loadswitch`, and taking the branch's files wholesale would have reverted all four. After this, `registry qualify` reports a structural or geometry finding on **3** parts rather than 24. The three that remain are out of scope here and each has a reason: `tvs_array_5v` is corrected in absmach#157's branch; `bg95` needs 94 pads declared and the branch never did it; and `mpu6050_imu` stops at one undeclared pad, the QFN's exposed pad, which cannot be declared while `Sensor_Motion:MPU-6050` has 24 pins and its footprint has 25 pads.

… renamed Completing this part's pin map renamed `vcc` to `vdd`, but the `[[required_decoupling]]` block still keyed on `vcc`. E-SYNTH-POWER-001 resolves that key by pin name and silently `continue`s when no pin matches, so the W5500's two 100 nF caps stopped being checked rather than being reported as missing. A requirement that names a pin the part does not have is indistinguishable from a satisfied one.

…using it Completing the W5500's pin map renamed its digital supply from `vcc` to `vdd`, pin 28, and three fixtures kept connecting `vcc`. The pin no longer exists, so each of them reported `E-SYNTH-COMP-002` for an undefined pin and `E-SYNTH-CONNECT-002` for the supply that never arrived. CI stayed green throughout, which is the part worth noting. The ERC fixture harness asserts that a `<CODE>__name.synth` file emits the code it is named for and allows any others, so `E-SYNTH-RESET-001` and `E-SYNTH-SPI-002` kept firing and nothing failed -- while the boards they fire on had become different boards, with an unpowered Ethernet controller and two extra errors each. A fixture that no longer isolates its own case stops being evidence for it. Both codes are gone now and the named ones remain. The two `U1.vcc` left in the SPI fixture are a `ch340g`, which does declare `vcc`. The harness weakness is the same one the qualification matrix had on absmach#75, where `expect_source_codes` was a subset check: a declared list that is a floor rather than a set lets a case decay quietly. Worth fixing there too, and out of scope here.

…obsolete one contradicting itself `at24c512_eeprom` and `m24m02_eeprom` were given the 24LC256's comment verbatim: "Pin names and numbers come from the stock symbol the part names, which extends `24LC16`". Neither symbol exists -- KiCad 10 ships no `Memory_EEPROM:AT24C512` and no `Memory_EEPROM:M24M02-DR` -- so the comment claimed a cross-check that could not have happened. The pin numbers are the SOIC-8 pinout these parts share with the 24LC256, and the comment now says that, and that the symbol name resolves to nothing. Main marked `24lc256_eeprom` obsolete with a description saying it numbers VDD, GND, SDA and SCL as pins 1 to 4. This branch moves those pins, so the description now says what was wrong and that it is corrected; the text is the same as absmach#235's change to the same line, so the two branches merge cleanly.

The re-records this branch carried were taken against an older main, and the commits that made them could not be replayed: at the first one the registry did not load yet (the W5500 decoupling key is fixed two commits later). Recorded once at the tip instead, with this machine's libraries, which reproduce main's own snapshot unchanged.

…the rebase ref_battery_charger and secure_tracker are the two references this branch's part data moves, as before the rebase; main has since refreshed every fingerprint, so the values carried from the old base were stale. Both values are CI's: this machine renders the stock symbols differently (main's own goldens fail locally), so a local regeneration would record the wrong fingerprint.

A footprint's exposed pad is copper, and copper no pin accounts for is what `E-SYNTH-QUAL-002` exists to report. But the loader also requires every declared pin number to exist on the KiCad symbol, and a thermal pad is precisely the pad a symbol does not draw. Those two rules met on `tmp117_temperature` and left no legal answer: name the real WSON-6 footprint and fail to account for pad 7, or declare pad 7 and make the whole registry refuse to load. `footprint_only = true` on a pin says "this pad exists in copper and has no symbol pin". The loader skips the symbol cross-check for those pins, and so does `symbol_pin_coverage`; the pad checks do not, so the pad still has to be real and still has to be covered. Deliberately narrow. The flag suppresses one check for one pin, and the control test proves it: the same part with the same pad and no flag is still rejected with `KicadPinMismatch`. It is a way to describe a pad, not a way to silence the check. `ina3221_power_monitor` needs no flag, because the `INA3221` symbol happens to carry pin 17. That it works there and not on the TMP117 was an accident of which symbol an author drew, not a property of the package. The field is not serialised when false, so no IR snapshot moved. `registry qualify` now reports no `E-SYNTH-QUAL-002` for the TMP117. What remains is `E-SYNTH-QUAL-008`, which every part in this registry reports because none records a reviewer -- that is absmach#51.

…0 ep, xtal description)

rodneyosodo · 2026-11-02T08:24:52Z

Rebased onto main and resolved conflicts (golden fingerprints); force-pushed.

rodneyosodo · 2026-11-02T08:36:56Z

Refreshed golden schematic fingerprints to the CI renderer; tests now pass.

rodneyosodo · 2026-11-02T09:18:59Z

All tests and lint pass after rebase and golden fingerprint refresh.

rodneyosodo · 2026-11-02T09:26:22Z

Updated golden fingerprints to CI renderer values (live +29 paths). Force-pushed.