Project Journal for Brian

Table of Contents

=============== Week 15: =================

Entry 4: -----------------------------------------------------------------

Date: April 25, 2025

Start Time: 12:30 PM

Duration: 7.0 hours

When I came back to lab, we had both a CPU emulator program, as well as a bus transaction routine that was working, but we were having issues integrating the two systems together. This seemed to be related to a certain RAII ownership issue in the Rust Emassry SDK for the RP2350, where it would drop the configuration for a state machine, even if there was a state machine still loaded in memory.

1.

Seth had a test program loaded on this system that would pulse read and write transactions between the two cards and log their behavior which seemed to be working correctly, but that's all it did.

2.

Additionally, the older front panel started to flicker erratically, even though the data signal were very stable. I assumed that this was because the sink drivers had started to fail, so I replaced the sink driver chip. This seemed to resolve the issue, but I'll need to investigate later exactly why our sink drivers are failing.

3.

I also decided to complete the rework job on this front panel's sink driver from last time, such that we would have an additional working front panel to test code with.

After hitting our project presentation time, we were still unable to integrate the system together. The course staff gave us a chance to demonstrate our PSDRs again at a later time, so Seth and I hunkered together to debug the issue. One thing he mentioned is that while passing the state machine objects into a struct caused them to drop their configuration, keeping them inside of a closure would allow them to still work correctly. Theorhetically, passing in the closure into the struct should allow the system to work. I decided to try to implement this experiment on my own branch. Because our code was asynchronous, and more specifically, required passing asynchronous closures, I needed to switch to Rust Nightly. Specifically I switched to the April 25th, 2025 version of Rust Nightly, which was only released a couple hours prior. This allowed me to enabled the unboxed_closures, async_trait_bounds, async_fn_traits, and fn_traits nightly features, which allowed me to write a patchset that succesfully integrated the CPU with the RAM read and write transactions. Merging in this code allowed Seth to complete the integration with the RUN/STOP buttons, and we were able to pass all 5 of our PSDRs.

Entry 3: -----------------------------------------------------------------

Date: April 24, 2025

Start Time: 2:00 PM

Duration: 16.0 hours

First things first, I'kk focus on finding the short that Seth was complaining about between signal lines. I'll check every circuit on the backplane to see if there's an issue.

1.

I've narrowed down the short to be between two pins, which is a piece of metal that is stuck between pins, and has been embedded into the plastic body of the connector. I can't rework this, so I'll have to replace the connector.

2.

I heated up that section of the board using the MHP30 hot plate, and remove the connector.

3.

Then, I cleared out the existing soldering by adding flux and using copper braid.

4.

I then installed and soldered on a fresh flat flex receptacle onto the board.

5.

Additionally, this other front panel board does not have the fixes with the button bridges to ground yet, so I will modify it by removing the buttons that don't work, and snipping off the pin 1 of each button.

6.

In the process of cutting of the pin for this button, the pin popped loose with the pad, so there's no longer a pad connected to ground on this footprint. I'll need to bring the ground line in from a neighboring footprint.

7.

Here's the other (older) front panel board, also reworked with the new button ground signals.

8.

The front panel tests well, and the buttons show up correctly! Some lights dont light up, but we confirmed that the microcontroller was getting the correct signals, so it should just be a display issue with the sink drivers.

9.

For the other front panels that aren't fully assembled yet, I'd like to first do the flash chpi bodge on them, before we install any other parts to make it easier to do.

10.

For both front panels, I first removed the flash chip using the WX2 tweezers.

11.

Then, I looped 10 loops of wire around the nylon brush, cut it, and removed the insulation on the ends. I also bent the correct pins on the flash chip.

12.

Next, I soldered the bodge wires onto the PCB first.

13.

Then, I attached the chip, and looped the wires onto the correct bent pins on the chip.

14.

Here's the two front panels with that reworking done.

15.

I decided to check over all the sink drivers on the front panels, and I noticed that one of the sink drivers (U3) had all of its data pads missing. I asked Nathan about it, and it seems he had the heat on too high for this part.

16.

In order to try to fix this, I first removed the solder mask from the vias of the data lines.

17.

I then covered the area in flux.

18.

Then, I plated each via with a small ball of solder.

19.

Then I attached small copper speaker wire to both the pin and the ball on the via. This seems like it will be a good strategy to rework this board.

I spent a really long time in lab, so my body is telling me to rest. With our project demonstration in a handful of hours, I'll come back very soon. Seth seems confident that he can get the software for the whole system integrated with Caleb's emulator in time.

Entry 2: -----------------------------------------------------------------

Date: April 23, 2025

Start Time: 12:30 AM

Duration: 4.5 hours

A supplemental order of parts, where I ordered 10-100 more of each of the "jelly-beam" parts we had (like 0402 resistors and capacitors) arrived, to supplement the parts that we had lost.

1.

I brought the Mouser shipment over from my apartment to the lab.

2.

Seth was there, and I took the time to organize the debugging wires into wire groups so that they were easier to work with, and less likely to short each other.

3.

I worked with Seth on trying to finish the memory read transaction. In particular one issue is that the memory read line is located on the upper bank of GPIO signals (GPIO 16-47) instead of the lower bank (GPIO 0-31), where the data and address lines, and many other signals were. Because of this, we needed to launch a second state machine mapped to the upper bank to take care of this, and listen to a PIO IRQ supplied by the "main" state machine. However, what we didn't realize was that bank assignments were destermined by PIO block, not by state machine, so all four (4) state machines in a PIO block would actually have the same pin mapping. This is corroborated in the datasheet, as GPIOBASE is a PIO-level register, not a state-machine-level register. This means that we'll need to coordinate the sending and receiving of the MEMR signal inter-PIO not intra-PIO.

The software debugging took a really long time, and it being 5 in the morning, I needed to go to bed. There was more hardware I needed to get to, and Seth noted that there might be other shorts between signal lines that is causing erratic behavior, which I'll get to next time.

Entry 1: -----------------------------------------------------------------

Date: April 21, 2025

Start Time: 6:30 PM

Duration: 5.5 hours

Seth wanted to be able to more easily connect the osciloscope's logic analyzer to the backplane, in order to view the timing of signals.

1.

On the right side of our backplane design, there's a large number of vias that are meant to allow for the attachment of wires for debugging.

2.

However, even though we specified for our vias to be untented, because of a combination of the fact that they were designed with a very small annular ring, and because our solder mask clearance for tented vias was very small, they all ended up getting covered in solder mask anyway.

3.

I used a sharp needle scraper to first remove decent amount of solder mask off of each of the vias in order to expose the copper underneath.

4.

Then I filled the entire area of all the vias with flux.

5.

Then I applied solder across each of the exposed vias to plate them, repeating the process until the solder was properly flowed onto the vias.

6.

I prepared about 50 jumper wires in the same manner as before but this time, looping around the solder sucker tube, in order to get wires of longer length.

7.

I then straightened and removed the insulation at the ends using the WX2 tweezers.

8.

Then, one by one, I soldered on each of the wires onto the backplane PCB.

9.

The test setup works.

I needed to leave lab for a bit to rest, but Seth now has additional debug tools to work with to get bus transactions working.

=============== Week 14: =================

Entry 3: -----------------------------------------------------------------

Date: April 17, 2025

Start Time: 2:30 AM

Duration: 10.5 hours

I'm back after a break. First things first, Seth in lab, while debugging using the SWD ribbon cable that I put together before, needed to plug and replug the cable into different cards repeatedly. This eventually caused the connector the shear off of the wire. I decided to create a replacement using silicone insulated wire, which is more flexible.

1.

Here's the debug harness made from silicone wire. It has the same connectors as before, JST XT on one side, Dupont on the other. This time, since the wires are separate instead of part of a ribbon, I spaced out heat shrink along the cable, to make sure the wires dont splay out, and to reduce strain near the connector ends.

2.

And here's the harness connected to the front panel. It works. I think it also looks cleaner.

3.

Thee newly assembled front panel from yesterday seems so also have some LED issues. I'm guessing this has to do with not enough solder being on the LED sink driver pads, so I'll reflow those.

4.

I reflowed the board at the Weller station using the chisel tip, and then also assembled a second wire harness, so that we can build and debug two boards at the same time.

5.

Trying the board again, all the LEDs light up correctly from the front panel, but trying to light up the LEDs from the card shows the middle LEDs not lighting up. This I think is an issue with needing additional solder on the backplane flex connector again, so I went ad added and drag soldered it some more. After doing that, the issue was resolved.

6.

With all the LEDs on at the same time, after a while, our 3.3V power line started cutting out intermitently. Here's an image of the 3.3V line on the scope. Notice the gaps to 0V that show up every so often. After trying a few things, I found out that this was the thermal shutdown feature on the buck converter. Pushing ~2 amps through the regulator when we have all LEDs on meant that the device got very very hot to the touch, enough to burn. If i repeatedly blow on the regulator very quickly, the power dropouts actually dissapear! We decided not to pursue a fix for this, since we decided it was unlikely for all LEDs to be on for such an extended period of time during normal usage.

7.

With the front panel, backplane, and card supposedly working, I went back to assemble and finish the bodging of the rest of the 12 cards.

8.

In order to get all the wires I needed at the right length, I looped the wire wrapping wire around the handle of this nylon brush a little over 48 times, to get 48 loops of wire. I then use the iron to melt the insulation at one end together so the coil would come out in one piece.

9.

Then, with the coil out, I used a pair of wire cutters to snip the coil along the melted line, giving me over 50 equally-sized lengths of wire.

10.

I then straighted each length of wire, and using the WX2's tweezer tool, burnt the insulation off the ends of the straightened wire.

11.

Here's the pile of equal-length wire with exposed ends.

12.

Then, for each PCB, I soldered one end of the wire I prepared to the offending pads on each PCB.

13.

I then attached the chips to each PCB by soldering on all the non-bent pins of each chip back to the board.

14.

Then, to complete the process, I added a small bit of solder to the pins that were bend on, along with a bit of flux, and then soldered on the other end of the bodge wires to the correct pins on each flash chip.

15.

Everyone has left lab now, but I want to test a second card. I soldered on a second DIMM slot onto this backplane we're currently using, since from what I can tell, it currently has no issues.

16.

With both cards attached, the test program enumerating through every LED from the new card slot seems to work!

17.

However, I did encounter an issue where A2 and A3 seemed to be bridged signals, which was confirmed by a trip to the ECE shop's X-ray machine.

Now with two cards, a backplane, and a front panel, we should have enough hardware theorhetically, to fulfill all of our PSDRs, software notwithstanding (which is still a big line item).

Entry 2: -----------------------------------------------------------------

Date: April 16, 2025

Start Time: 2:45 AM

Duration: 8.5 hours

Nathan came over in lab and showed me the new backplane PCB he assembled, using our new method of stencilling in all the solder paste, but only placing the parts for the buck converter and the USB connector.

1.

Overall, the board looks good, and the connections on the USB port and buck convertor look solid.

2.

Nathan did however mention that he had deposited too much solder paste on a second pass with the scraper, so the solder on the DIMM slots and flat flex connector started to ball up together. I cleaned off the solder on all of these pads by adding flux and using copper braid.

3.

I then installed the flat flex connector by securing it using the two large solder pads on either end of the connector, and drag soldering the rest of the pins.

4.

Nathan said that he should be able to put together the DIMM slots on the backplane, so while he's doing that, and Seth is working on our first assembled front panel, I'm putting together a second front panel with all of my learning from assembling the first one. Because the front panel also suffers from the flash pin issue, I put together the same bodge fix on this front panel as the others.

5.

Then, I cut off and removed Pin 1 for each of the buttons on the PCB, leaving the ground circuit unconnected to the buttons.

6.

Then, in order to connect the ground circuit to the other side of the buttons, I used the same wire wrapping wire that I used for the chip bodge, but removed all of the insulation from the wire for convenience. I then bridge the ground circuit using the wire to the opposite side of the buttons to complete the bodge.

7.

With these changes the front panel PCB should now work correctly.

I did additional work in lab today, helping rework the backplane, and put together a front panel PCB thet should be fully functional. There's still a lot of rework to do, like fininshing up the rework for those 12 card PCBs.

Entry 1: -----------------------------------------------------------------

Date: April 15, 2025

Start Time: 8:01 PM

Duration: 7.0 hours

I'm going to try to finish the significant amount of rework we need to do get the NOR flash chips bodged to work on all of the card PCBs. With 1 board scrapped and 2 boards already reworked, I have 12 boards that I need to go through in a sort of assembly line to get all the chips redone. I'll do this by first removing all of the chips, bending the chip legs, cleaning the excess solder on the boards, cutting out all 48 bodge wires, straightening those bodge wires, attaching the wires to the PCBs, attaching the chips to the PCBs, and finally attaching the wires to the chips.

1.

Here is the stack of 12 cards that I'm working with.

2.

I'm using the Weller WX2's plier tool to heat up the legs on both sides of the chips.

3.

Using the WX2, I removed all 12 chips from the card PCBs.

4.

I then used the WX's chisel tip to clean up all the solder pads.

5.

I then bent the leads for each chip under the microscope, using the same needle-noce plier + tweezer method as before.

6.

Seth noted that there was some weird behavior with the bus connections between the card and the front panel, and after examining the flex connector on the backplane using a microscope, I found that two signal pins on the board were bridged together. Reworking the connector by adding a lot of flux and dragging the chisel tip across the board seemed to resolve the issue.

Gradual progress in reworking the boards so far. On the cards, I managed to get all the chips off and bend them, but I still need to attach the bodge wires and put the chips back on. I also found some additional issues with the backplanes and front panel that will also need rework later, but nothing seems impossible The current plane is to cut off pin 1 on each of the buttons, and manually bridge GND over to the opposite "3,4" circuit.

=============== Week 13: =================

Entry 4: -----------------------------------------------------------------

Date: April 10, 2025

Start Time: 12:44 AM

Duration: 3.0 hours

Seth complained about the fact that the probe-rs toolchain was unable to set up GDB in a way that we would know the current line number of the file, and the current location of the current breakpoint. This meant that we were essentially hitting breakpoints and single-stepping blindly, which isn't ideal for debugging. Instead of using the probe-rs debugger, I set up a new VS code build environment that used the generic Cortex M Debug extension with the generic ARM GCC/GDB Toolchain (specifically the latest gcc-arm-none-eabi toolchain), and a new build of the latest version of the Raspberry Pi fork of OpenOCD.

1.

With a launch configuration that configured OpenOCD to flash the firmware, then launch the ARM version of GDB, it seems that both line numbers and breakpoints were working correctly!

2.

In order for debug messages to work correctly, we needed to get the rust defmt library's binary messages to be decoded into ASCII, which required passing RTT messages through a filter. I wrote a program that used the Cortex debugger's advanced processor feature to pass the RTT data through the rust defmt-print binary to convert the data such taht it could be printed correctly.

With this new working debugger, it should now be easier for Seth to understand what's going on when we're configuring peripherals and working on asynchronous stuff in embassy. I'll communicate to him how this new tool I put together works the next time we're in lab together.

Entry 3: -----------------------------------------------------------------

Date: April 8, 2025

Start Time: 12:00 AM

Duration: 8.5 hours

I spent some time today to try to figure out why the firmware was not flashing. Since communication between our computer, the probe, and the MCU through SWD seemed to be working correctly, I decided a good point to debug would be the connection between the MCU and its QSPI NOR flash on the card.

1.

I connected the logic analyzer's pins up to the NOR flash chip, connecting GND, then Clock to probe 1, Data 0, 1, 2, 3, to probes 2, 3, 4, and 5, and CS to probe 6.

2.

I got a clean clock and chip select signal, but the readings from the data lines were very very noisy, which I can tell from the fact that the logic analyzer sees "switching" far faster than the actual QSPI clock frequency.

3.

After thinking through some of the possiblities, I decided to look through the card schematic, where I came to a terrible realization: the data lines between the MCU and chip were reversed, so the connection was garbled, and never able to upgrade from normal SPI to QSPI, explaning the shape of some of the logic analyzer signals. Since the schematic design of the front panel was copied from the card, this error was also on the front panel schematic.

4.

Using an MHP30 mini hot plate, I heated up the card PCB, and pulled off only the NOR flash chip. I decided to try to find a way to try to rework our boards to make the flash chips work, because otherwise we'd basically have no working boards at all.

5.

For the data pins that were affected, I straightened the pins using a pair of needle-node plies, and then too a pair to tweezers to bend the data pins upwards, such that all the other pins on the package were unaffected.

6.

I then took copper enameled speaker wire, and soldered the wire onto the pins that were bent up. After I soldered wire to all 4 affected pins, I tried to loop the wire around under the pins into their new locations. Unfortunately, the enameled wire was too thick and stiff, and trying to bend the wire into place snapped off one of the legs on the chip.

7.

I then repeasted the process with another NOR flash chip I'd taken off of another card PCB, bending its legs to be straight, and then bending the entire leg to be pointed slightly upwards.

8.

I then decided to swap out the wire I was using for an even thinner wire gauge (labelled wire wrapping wire) with plastic insulation that could be easily burnt off. This wire was significantly more flexible, and I didn't break off any pins this time.

9.

I then manually resoldered the new modified package onto the card PCB. taking care to swap the pins that the wire wrapping wire was connected to. I did this by first soldering down the other end of the wires, then placing the package down, and soldering the rest of the unaffected pins on the package to secure it.

10.

Probing the new configuration of the package, the logic analyzer waves look a lot more consistent, and the flash process with probe-rs shows a succesful verification!

11.

Seth put together an LED blinking program, and we were able to verify that the card could blink on LED on the front panel.

12.

Testing however revealed another series of problems. I modified the programm to light up all LEDs on the front panel from the card, and it turns out that a very significant number of signals were not making their way from the card to the front panel; their LEDs remained unlit.

13.

I decided to take this oppotunity to rework the front panel PCB. I again fired up the MHP30 hot plate and tried to remove the NOR flash chip.

14.

This time however, I was too eager to pull off the chip before the solder had fully started to flow, and in the process I'd ripped off the chip select pad on the board. I repaired the pad by setting down a piece of bodge wire where the pad once was, connected to the circuits on either side of where the pad was.

15.

I then performed the same bodge operation, but this time, I tried to put the wired onto the PCB first, then put the chip on top of it, looping the wires that were on the PCB up to the bent pins on the chip.

16.

This bodge was complete, and it actually went much faster than last time, so I'm going to continue to do these changes by placing the wire wrapping wire onto the PCB first, instead of starting on the chip.

17.

I also took the oppotunity to reflow all of the connections on the LED sink driver ICs on the front panel, and I modified the program to test if the offending LEDs could be lit. They were, which was good.

18.

Here's the program which light up all LEDs at the same time, showing that the card had no issue communicating to the front panel.

This time in lab, I uncovered a really big design issue that would've been absolutely devastating if I hadn't put together that bodge wire procedure. I'm going to have to reapply this bodge to the 3 other front panel PCBs, and 13 other repairable card PCBs later, but I'm going to focus on seeing if we can get bus software running when i recuperate my findings with Seth.

Entry 2: -----------------------------------------------------------------

Date: April 7, 2025

Start Time: 5:11 PM

Duration: 2.0 hours

Seth and I came together in lab to try to flash some test firmware onto the PCBs.

1.

I created a wire harness by crimping a ribbon cable to two 3-pin JST XT connectors I got from the ECE Shop, and crimping Dupont connectors onto the other side, such that we could plug the SWD connector from the card to the debug probe we were using for the stamp XLs, with SWD data and clock connected to the same GPIO 4 and 5 on the probe.

We could connect to the cards using both probe-rs and OpenOCD, but attemping to program the cards really did not work out. None of the times we programmed it did the verification of the written data work, on either probe-rs or OpenOCD. When we tried to run the MCU anyway and reset it, the program we flashed did not run. I'll need to investigate what's going on later.

Entry 1: -----------------------------------------------------------------

Date: April 6, 2025

Start Time: 4:15 AM

Duration: 7.0 hours

Another PCB that we need to bring online is the front panel PCB. The most annoying part of the PCB to assemble is the vertical USB connector in the middle of the board, so I'll go ahead and try to assemble that first.

1.

I spent over an hour trying to get the USB connector onto the board. USB4235-03-C is honestly a really poor choice of connector for manual soldering, since all the electrical pads are underneath the footprint, with no easy way to reach them with an iron. In the end, I relented, and only soldered in the shielding tabs, so the actual electrical pads are just pressed against the PCB pads without solder. Regardless, plugging in a USB-C connector shows that 3.3V shows up on the linear regulator.

2.

I looked at the datasheet for the VLRK31Q1R2-GS08 which showed that the side of the package with the lens on it has a triangle cut-out which indicates the cathode. I'll line this up with the cathode dots that we have on the front panel PCB silkscreen.

3.

I then brought 36 LEDs over to the Weller WX2 lab bench, and soldered each LED on, solding on one pad, making sure the LED is centered, and then soldering on the other tab. Visually, it doesn't seem like any LEDs appear to be off-center.

4.

I noted that the RP2350 shows up as a USB bootdrive on my computer when I press my hand against the USB connector when I have it plugged in. This is a consequence of the UF2 bootloader on the RP2350's ROM, and the fact that we don't have firmware flashed on these devices yet.

5.

Removing the pick-and-place kapton tape from the front panel, the jumper cable seat well into the pre-assembled flat flex connector.

6.

Next, in order to power the front-panel normally from the backplane, I needed to attach the flat flex receptacle onto the newly soldered backplane. I'm going to try to re-use the connector I desoldered last-time, but that connector has a bunch of solder bridges on it, even after removal. I went and removed the solder bridges from the connector by using solder wick in combination with the Weller WX2's chisel tip.

7.

I then installed the cleaned up connector onto the backplane, and made sure that the front panel could also power itself up using the backplane power.

8.

I then installed three more DIMM slots onto the working backplane, completing it.

9.

I tried to put together the USB connector and the USB power section for the card PCB, to test if we could power the card PCBs from USB as well. It did not go as well as the front panel PCB. As you can see, the tantalum capacitor at the 5V side exploded, as in a little charred. Since it's not necesary, I'll refrain from assembling the USB section on these cards for now.

Once I get another card onto this setup, we should have all the electrical hardware necesary to put together the final product, which I'm really excited about. I still need to work with Seth later this week to figure out how to properly flash firmware to these devices.

=============== Week 12: =================

Entry 3: -----------------------------------------------------------------

Date: April 2, 2025

Start Time: 10:00 AM

Duration: 1.0 hours

After discussing with Shivam and showing him the various solder bridges we had on our current board, we came to the conclusion that it would be more time-effective to desolder all the connectors on the board we put together. He also mentioned that he purchased a finer pitch Chipquik solder paste for us to use, which we could set up inside of the senior design lab, instead of using the ECE shop materials.

1.

I turned on both pre-heaters on the hot plate, but we only needed to use the first heater at 280 degrees Celsius. We manipulated the boards using pliers. Firstly, I placed the board we had already assembled, and waited for the whole thing to heat up and for the solder to liquify, and then one by one pulled off each of the DIMM connectors and the flat flex connector, then slid it over to the cold plate. Next we also pasted and assembled a new board with the new refrigerated paste we had, and heated that board on the same plate.

2.

We still found some solder bridges on the second board we assembled that needed to be corrected, so it still wasn't usable, but for the board where we pulled all of the connectors off, all the solder bridges had been removed, so there were no longer shorts between ground and 3.3V. Plugging the device in showed a good and stable 3.3V on our buck convertor's output lines, fulfilling our power PSDR.

3.

We came to the conclusion that trying to put down all of the connectors on each backplane one-by-one was too risky, and that it would be better to install each DIMM connector by hand, one-by-one, verifying the solder connections as each one is installed. Here I installed the first DIMM by dabbing in a bit of solder with the soldering iron on each pad individually, and it tested well. The card is powered properly, and it enumerates on probe-rs using the probe-rs info command.

With the power supply working, we were able to show our 3.3V measurement to Setsuna, and got our prelimenary power PSDR checked off. Next steps that I want to get to is continue the assembly of the backplanes, and make sure that the cards are programmable. I really want to get two cards to be able to talk to each other on real hardware as soon as we can.

Entry 2: -----------------------------------------------------------------

Date: March 31, 2025

Start Time: 10:30 AM

Duration: 6.5 hours

As it's recommended to assemble PCBs in pair teams, Nathan and I agreed on this morning today to work together to put together a backplane PCB. We decided to do it in the morning because when the ECE shop would be available.

1.

I measured some of the scrap boards from the senior design lab using a pair a calipers, and picked the boards that had 1.6mm thick substrates. I then brought these boards and the SMD stencil over to the ECE shop, and set down the backplane PCB on the table. taping down scrap PCBs around it, such that the stencil can be taped on top of the scrap PCBs. In this way, I put together a makeshift stencil jig.

2.

The stencil is taped on one side such that we can install and remove backplane PCBs for solder paste printing.

3.

Using a spreader card, we used the ECE shop's solder paste on the stencil to print the solder paste pattern onto the backplane board.

4.

Then after pasting, I started the process of manually placing components onto the board. The DIMM slots came in a nicely packaged box, which I found out after I cut open the vacuum seal bag for it.

5.

Is it very difficult to see, but for a component like this 0402 diode, there is a very small lasered line on it that represents the cathode side (This can also be confirmed using the BAS16L datasheet).

6.

I placed components in the order of ascending size, so 0402-sized components went first. Here is an image of all the 0402 components placed.

7.

I tried to use the radiative preheater at the ECE shop to reflow the board, but I think it delivered too much power, and it started smoking the whole board and toasting the DIMM slots a little. Additionally, the heating was very uneven; while the middle got very very hot, the outer edges of the board still did not have reflowing solder paste. The reason I wanted to try using the radiative pre-heater was because the mechanical anchors on the slots extend below our PCB substrate, making it difficult to reflow on a hot plate.

8.

Because it was difficult to use the soldeing tools at the ECE shop, we went back to the senior design lab. I tried to use the reflow oven, choosing a profile based on the SMD291 series of ChipQuik that we used from the ECE shop. I wanted to try using the reflow oven because the oven tray had holes in it that I could use to poke the mechanical anchors of the slots through, instead of just resting on the base. After reflow, the slots came out even toastier, and I observed a lot of solder bridges between the connections on both the DIMM and flex connectors.

9.

Additionally, it also seemed like many of the solder joins on the board were either cold or overflowing with way too much flux. I decided to rework all of the components that did not look good. To rework an 0402 component, I first remove the component.

10.

I fill the area with flux, and tack one side of the part onto the board first, setting the part into the right position, then tack on the other side.

11.

I repeat this process with the other offending part, a current-limiting resistor for a heartbeat LED.

12.

Here's what the fully assembled board looks like, but it looks like we need significant amounts to rework to remove the solder bridges present on the connectors.

It's really nice seeing this backplane PCB come together, and it looks really nice! It's a shame though that there's so many solder bridges, and it can't really be tested right now, since even 3.3V and Ground are bridged together, so even the power supply wouldn't work.

Entry 1: -----------------------------------------------------------------

Date: March 29, 2025

Start Time: 10:10 PM

Duration: 0.5 hours

The package for the flat flex jumper cables arrived on time. I brought the packet from my apartment which I'm also going to unpack.

1.

Here's how Mouser packaed the extra few parts we needed. This baggie contains the jumpers, and both of the parts needed to assemble the jacket. It also comes with the packing slip.

2.

The flex connectors are a lot stiffer than I expected, it seems like they have some sort of relatively thick backer material, but it can still be bent. It seems like the 51mm size for the cable is suitable, as the bend radius it makes is not too intense.

3.

To assemble the cable correctly, I slid the cable into the large piece of the jacket, underneath the larger plastic piece's cable clips, and then snapped on the other side of the jacket, which holds the jacket in place. doing this same process for the other side assembles the whole cable.

4.

The cable seems like it would fit well on the front panel, but I'm not going to remove the tape on the connector yet.

Nathan and I will assemble the backplane PCBs tomorrow morning, so I will rest for now.

=============== Week 11: =================

Entry 3: -----------------------------------------------------------------

Date: March 27, 2025

Start Time: 12:29 AM

Duration: 1.0 hours

All the parts (excluding the jumper cables) we need have arrived! I'm going to entertain myself and unbox the packages we got in lab. I brought the DigiKey and Mouser packages from my apartment to the lab, and the two JLCPCB packages are on our lab table.

1.

Here's the three packages I brought. The packet is the DigiKey package, and the other two packages are from Mouser.

2.

JLCPCB shipped the stencil in its own envelope package, where the stencil itself is taped to a backer board.

3.

Our three types of PCBs are packaged in the other box. The non assembled backplane boards are vacuum-sealed, and the assembled boards are rolled up in bubble wrap.

4.

Here's what the card PCBs look like unrolled from their packaging, They're still attached to their V-Cut panels.

5.

And here are the 5 panels with pre-assembled components. JLCPCB needed to create a new assembly foorprint to install the flat flex connector, and I'm glad there were no issues with assembling that.

6.

The DigiKey packet came with all the parts we needed, matched against the packing sheet. We didn't order many parts from DigiKey, since most parts were cheaper at Mouser.

7.

The cube Mouser box contained our extruded enclosures.

8.

The other Mouser box contained the majority of our components.

I need to rest right now, but I'm happy to see all the PCB parts turn up and the PCBs in good condition, we'll start on assembly next week. The jumper cables should arrive on Saturday, but they won't really be needed while we're putting the boards together.

Entry 2: -----------------------------------------------------------------

Date: March 25, 2025

Start Time: 5:40 PM

Duration: 2.0 hours

I realized that I'd forgotten to order the proprietary flat flex cable and jacket pieces that are required to use the flat flex receptacle used to attach our front panel to the backplane.

1.

Currently the BOM specified the usage of the 15022-0450 jumper connector, which measures about 4 inches, since it was the smallest version of the cable that was in stock on DigiKey. However, Mouser stocks 15022-0280, which measures around 2 inches. A shorter cable seems preferable, but I needed to make sure that it would fit properly and be long enough in our mechanical assembly. I opened the CAD assembly of our project in FreeCAD and used the measure tool to get the linear distance between the bases of the two flat flex receptacles. The distance was less than 30mm, which should give enough slack for the the shorter 51mm cable to work. I called Mouser customer support to see if they could add 5 units of the cables and 10 units of jacket assemblies to our order currently being picked, but Mouser told us that I was too late and that the parts for the cable would need to be picked and shipped separately. They were nice enough to waive the shipping fees for the second shipment.

2.

While waiting for parts, I was curious about how easy it would be to create nicer ray-traced renderings of our PCBs in Blender. It turns out that KiCad has a very nice plugin called pcb2blender which allows for a workflow to import KiCad PCBs into Blender for very nice renders. However, when trying to use the plugin on our project, I ran into this specific bug that comes from the fact that the 3D viewer and VRML exporter implement searching for 3D models differently. This causes the VRML export required for the pcb2blender workflow to fail. Specifically, this comes from the fact that since we use a version-controlled shared library, we using footprint-relative 3D model paths, which aren't supported by the VRML exporter. A quick fix to make the export work is to replace instances of \(model "(?!\$) within the file to (model "${KIPRJMOD}/../Library.pretty/, which the exporter recognizes. With the imports working, the initial renderings I'm getting from Blender look very nice.

Addendum: I made a patch to KiCad that got merged. This bug should no longer be present in the KiCad 10 release.

I've also created a 17Track link containing the tracking numbers of all the packages we're expecting to receive. This includes the two shipments from JLCPCB, one package from DigiKey, and three packages from Mouser.

Entry 1: -----------------------------------------------------------------

Date: March 25, 2025

Start Time: 12:16 AM

Duration: 1.0 hours

We delayed the ordering of parts because there were so many last minute PCB design changes that we needed to go through. The the PCBs now ordered and under production however, it's time to order the parts we need to complete the assembly of the PCB.

1.

The backplane schematic and BOM list a couple of components specified by the MCP16331T regulator's datasheet. Specifically, the boost diode that the datasheet recommends is the Diodes Incorportared 1N4148WS-7-F, which has an SOD-323 footprint. However, the footprint currently assigned to the "1N4148WS-7-F" symbol is a generic 0402 diode component, which the part does not come packaged in. This means I will need to find an alternative diode with similar specifications. Specifically, the datasheet chooses 1N4148WS-7-F because of its fast response time, so I will ltry to find a diode part that first and foremost have a similar response time, then similar forward voltage, etc.

2.

After searching through the Digikey filtering system, BAS16L-G3-08 seems like a suitable substitute, as its major specifications are nearly identical.

3.

For the flyback diode, the datasheet recommends many different parts, but since the footprint on the backplane PCB is a DO-214BA (top), the closest recommended part is the B130L-13-F diode, which is a DO214AC package. I will choose this diode as the flyback diode.

4.

The currently parted inductor for the regulator is Eaton DR73-150-R, which is not on the list of recommended inductors on the regulator datasheet. The part with the same value which is on the recommended list that is closest in size to the footprint sent off to the board shop (top) is Wurth Elektronik 7447779115 (bottom).

These were the major contentious part selection decisions that I needed to make. Every other component has a well specified part that can purchased for a reasonable price on either DigiKey or Mouser. I compare prices I converted the BOM of the entire project into an Octopart BOM (downloaded and llinked here, this can be uploaded to OctoPart's new BOM tool to view current pricing), and used the Octopart buying tool to split the order into a DigiKey order and a Mouser order. The orders from both distributors should arrive in about 3 days

=============== Week 10: =================

Entry 3: -----------------------------------------------------------------

Date: March 18, 2025

Start Time: 6:07 PM

Duration: 3.0 hours

Our JLCPCB order did not continue smoothly as expected. The boards failed review, and JLCPCB sent us the following messages:

  • You need to pay additional 53.03 for your order. panel_Y23【4707014A_Y23】
  • You need to pay additional 59.35 for your order. card_Y22【4707014A_Y22】
  • You need to pay additional 73.65 for your order. backplane_Y24【4707014A_Y24】 The reason given was the following:

There are minimun hole size of 0.15 mm, with a diameter of 0.25mm in your file, to ensure the quality for your order, the 4-Wire Kelvin Test is mandatory, you have to pay for an extra cost for it. Or if you can modify the hole size/diameter as 0.2/0.45mm, we will no need such a test. For pure PCB ordes, you can ask us to activate the replace button for you by email or livechat.

I did not realize that JLCPCB had different costs for manufacturing the vias sizes described on their capabilities page. Their quoting system, however shows an option line that I did not notice, specifying the via hole/diameter prescision, of which "0.3mm/(0.4/0.45mm)" was the default. Because I had designed the board with via sizes at the edge of their capability, an additional charge was incurred. Because paying the testing fees would blow way way past our project budget. I decided to revise the designs of all 3 boards to use larger vias that required less precision.

1.

I tried to load the submitted gerber files into the JLCDFM analysis tool to see if it could help me with my via size issue, but it doesn't seem to have an option to set those constraints.

2.

In the card PCB design file, I modified the KiCad contraints to be more strict, setting the via hole diameter to 0.45mm.

3.

Making this constraint change meant that the current design should throw a lot of errors because of its use of smaller vias, which it does. A new DRC run shows 356 new DRC errors.

4.

After selecting all undersized vias and changing them to a 0.45mm diameter, it reduced the number of DRC errors by 225. The 131 remaining DRC errors are mostly clearance violations caused by the larger via size.

5.

The vias in this section (ADDR05, ADDR06, and ADDR07) were originally placed outside of the RP2350's courtyard, but with the larger via size, they cause many clearance violations. Starting the vias inside of the chip, and then routing out, removes the clearance violations.

6.

I shifted the vias for the I2C bus to the I/O expanders slightly to avoid creeping onto one of the expander signal lines.

7.

I lifted up some of the traces in the first control block to avoid the enlarged vias placed near it.

8.

I spaced apart vias on the board that were overlapping/too close together with their new size. For DATA06 and DATA07 this was easy, since the rest of the traces could be kept.

9.

I pushed many vias along the protection resistors closer to the resistors to give additional clearance to the traces running above them.

10.

I did a significant rework in the routing for the CTRL00, CTRL01, and CTRL05 signals in order to fit them into the corner of the MCU with the other signals.

11.

I spaced apart the block of jumper resistors slightly to make room for the enlarged vias to fit.

12.

I adjusted the position of the vias for the SWD connection to give clearance to other traces.

13.

I moved the vias for the QSPI signals very slightly outwards to be able to fit them all in with clearance, which still trying to keep the path as short as possible to make sure high frequency QSPI XIP signalling still works.

14.

I adjusted the vias around the 1.1V power delivery trace, even moving some of the vias to the other side of the trace, to give all traces the room they need to breath with the enlarged vias.

15.

I can't really fit power vias in the space between 0402 decoupling capacitor pads anymore, so for some cases, this is the geometry that I'm choosing to use, which should still allow for the net to "touch" the cap because the rest of the power delivery network to some extent.

16.

I then adjusted the silkscreen position to make sure it was tidy for the components that I had moved.

17.

With all of these little changes to fix clearance issues, the DRC now passes with 0 DRC errors.

18.

This same process of adjusting the via diameter constraints was applied to the backplane PCB design file.

19.

With the new contraints applied, the KiCad DRC checker reports 398+ errors.

20.

After increasing the sizes of the offending vias, the number of DRC errors reduced to 63, most of which are clearance errors in the section where the two connector types interface.

21.

I adjusted all of the traces coming out of the flex connected, shifting each trace such that it had enough clearance with the new enlarged vias.

22.

The DRC for the backplane now passes with 0 DRC errors.

23.

I again repeat this process with the front panel PCB design, setting the via constraints to have larger diameters.

24.

After this change, the DRC checker reports 597+ DRC errors on the front panel design.

25.

To conform to the new via diameter constraint, I enlarge all non-conforming vias to 0.45mm.

26.

This actually increases the number of DRC errors to 715+, presumably because the front panel design has very dense concentrations of vias.

27.

The largest offenders are the vias near the front panel flat flex connector, which are place right next to each other. With their enlarged size, they all violate clearance constraints with each other.

28.

I once again use the KiCad Via Patterns plugin to generate larger staggered vias to make it easier to fit all the larger vias into the save horizontal space. I then assign the correct nets to each of the generated vias.

29.

Because of the positions of each of these vias have changed, I need to mannually route the signals from the new vias to the sink drivers.

30.

Another major source of clearance violations are the vias placed near the central protection resistor block on the front panel, which is the protection resistor block with the highest density of resistors, vias, and traces.

31.

Spacing the resistors farther apart gives room for the larger vias to breath, eliminating the clearance violations.

32.

With these changes, the DRC now passes with 0 DRC errors on the front panel design.

I exported the new production files, and contacted the course staff about the JLCPCB review and fees, and my new modifications to the design. We canclled the old JLCPCB order, and created a new order with the revised design.

Entry 2: -----------------------------------------------------------------

Date: March 16, 2025

Start Time: 12:24 AM

Duration: 2.5 hours

I'm doing one final set of design reviews before sending off the final set of files to the course staff for PCB ordering. This involves cross-checking the schematic and PCB with the datasheet for every chip on the device, and trying to think of anything else that can go wrong.

1.

Because one entire side of the DDR4 connector was being unused, I decided to "double" up the signal connections to be on both sides of the board and connector, and revised the designs of the card and backplane accordingly.

2.

One thing I noticed while doing a review of pinouts was that the orientation of the flat flex receptacle actually mirrors, because on the cable, the contacts are on the same side of the cable. This was not reflected in the schematic, so we would've had to "twist" the cable 180 degrees to get the proper connection. I reversed the electrical order of the connector on the backplane by grouping all the signals together, using KiCad's mirror transform operation, then splitting and placing the signals back onto the connector symbol.

3.

With this schemtic change applied, the signals from the connector would need to be re-routed (also indicated by the re-appearance of the ratsnests). This is tedious, but not difficult, since the routing would be a similar operation of just plunging vias into the right signals.

4.

I then deleted all of those old traces coming from the flex connector, and placed down new ones with the correct signals in the same manner as before.

5.

As another opportunity to save costs, I found VLRK31Q1R2-GS08, which is a similar LED design to the KingBright reverse-mounted LED device we were using previously. I checked, and the part has the same symbol numbering for anode and cathode, and has a nearly identical 3D model to the KingBright. Since it also has similar electrical characteristics according to its datasheet, it should be a drop-in replacement for the KingBright LED. This component should save some money since it's both cheaper on a per-part basis, but also isn't subject to import tariffs.

6.

I also noticed another pinout error that was uncaught. When the front panel was being designed, the symbols for the MCP23017 I/O expanders was copied over from the card design. However, for space reasons, the footprint for the device was changed over the the QFN variant. What we didn't change however, was the symbol, so the package pin numbers on the symbol still corresponded to the SSOP package, which were incorrect. In this image you can see the differences in pin numbering between the "ML" version of the MCP23017 symbol (left), and the "SO" version (right).

7.

Importing this new fixed schematic definitions meant that the rats nests re-appeared, now pointing signals and power lines to the correct pins on the package.

8.

I routed in the power and I2C bus addressing signals, and then for each of the I/O signals, I routed them to the closest I/O pin. This meant that I would once again need to remap the net labels for each I/O expander, since the closest net on the package for each switch had changed.

9.

The specific changed that needed to be made were on the I/O expander dedicated to the push buttons, where the following changes were made:

PROTECT -> EXAMINE
AUX1 -> DEPOSIT
UNPROTECT -> RESET
CLR -> PROTECT
DEPOSIT -> AUX1
RESET -> UNPROTECT
DEPOSIT_NEXT -> CLR
EXAMINE -> DEPOSIT_NEXT
EXAMINE_NEXT -> SINGLE_STEP
SINGLE_STEP -> STOP
STOP -> RUN
RUN -> EXAMINE_NEXT

These changes were applied to the schematic (in the images you can see a before and after).

10.

This updated schematic was then imported into PCBNew once again, which allowed me to fully connect the button signals I partially routed. The DRC for the front panel passes.

11.

With these changes made, the designs should be ready for submission to JLCPCB. I uploaded the design files to JLC and emailed the course staff about our design updates.

For the order with all the PCBs and the assembly service, the combined merchandize total for 15 cards, 5 panels, and 5 backplanes was $309.57. The estimated shipping estimated was $51.87 (UPS Express). JLC offered a $15.00 coupon for using SMT assembly. This brought our estimated subtotal (before taxes) to $346.44. After contacting the course staff, Shivam ordered the PCBs on my JLCPCB account.

Entry 1: -----------------------------------------------------------------

Date: March 15, 2025

Start Time: 5:20 AM

Duration: 1.5 hours

I'm continuing my work on optimizing the cost of the PCBs by now working on the card PCB, using the same methods I used on the panel PCB. Many of the part replacements, like the AMS1117 button and the TS-1187A-B-A-B button, also apply on the Card PCB.

1.

I'm setting the jumper 0402 devices seen here to the part 0402WGF0000TCE, which are written as 0 Ohm devices, though the resistance isn't super important, as long as it's low.

2.

I also copied over the change to using AMS1117 over NCP1117 on the card schematic, from the panel schematic.

3.

I updated the PCB design to reflect the new schematic, notably moving around the power section to fit the larger 22uF tantalum capacitors, and updating the position of the differently sized BOOT and RESET buttons.

4.

With these changes the PCB cost for 15 cards dropped from $56.30 to $45.30, and the PCB Assembly cost from from $136.86 to $88.78. So the cost reduction for our subtotal for card PCBs was from $193.16 to $134.08, which is a 30.59% cost reduction.

5.

Using the KiCad Via Patterns plugin, I created a zig-zag pattern on the backplane for use with fly wiring, and copied and pasted it to each signal block. I assigned the correct nets to each via, and routed them in to the rest of the bus and refilled the zones.

This concludes my work spanning from yesterday to today. I'm going to rest before finalizing the production files to send to JLCPCB.

=============== Week 9: =================

Entry 9: -----------------------------------------------------------------

Date: March 14, 2025

Start Time: 4:16 PM

Duration: 3.0 hours

There's two things that I want to get done before the week ends before Spring Break. Incorporating the TA PCB design feedback, and reducing our JLCPCB order cost.

1.

Setsuna noted that we would prefereably have keep-out-zones for copper near the mounting holes on the front panel. I implemented this by drawing circle graphics on a user layer, and designating the circle as a keep-out for zone fills.

2.

For Setsuna's feedback on the oscillator keep-out I also did the same for regions of copper underneath the oscillators using a rectangle graphic.

3.

Examining the JLCPCB listing of PCBA capabilities, 4-layer boards must have green solder mask to be eligible for "Economic" vs "Standard" assembly, which reduces the order cost. I've decided to order the front panel with green solder mask, which is the only eligible board we have for Economic PCBA.

4.

Additionally, I realized that any part that is not in the JLCPCB "Basic" parts list incurs an addition $3 setup fee to the order cost. I decided to swap components in our design that were "Extended" over to components that were "Basic" to reduce the PCBA cost. The JLCPCB website contains a search tools that allows me to filter component categories by whether they are "Basic" or "Extended".

5.

The 68 Ohm resistors we're using for the status LEDs are an "Extended" part, with the closest value "Basic" part being a 49.9 Ohm resistor. We should be able to use these resistors with the LEDs.

6.

Using an LED calculator, using a 49.9 Ohm resistor should fall within the LED's current rating.

7.

I then reassign all the LED resistors over to 49.9 Ohms each.

8.

27 Ohm resistors are also not part of the "Basic" parts catalog. I think this is because normally, the termination resistor value for an STM32 is 22 Ohm, but Section 5.1 of the Hardware design with RP2350 manual notes that the RP2350B wants 27 Ohms for USB termination. I've elected to keep these resistors unpopulated, and to change their footprints to 0603s with hand-solderable pads.

9.

The current choice of decoupling capacitor for the sink drivers (30 picofarad) aren't "Basic", so I've changed them to 100 nanofarad, the same ones used to decouple the VDD on the MCU.

10.

I've also changed the resistance on the heartbeat LED from 150 to 200 Ohms, which is a "Basic" part.

11.

There's only one "Basic" tactile button, the TS-1187A-B-A-B, which has a native footprint in KiCAD. I've changed the chip RESET and USB boot SMD tactile buttons to this part.

12.

This tactile button has a slightly larger footprint, so I was only able to fit one (1) of them between the spaces created by the slide switch through holes.

13.

The LSM115JE3/TR13 is an "Extended" part, and the highest-performing "Basic" Schottky diode for the voltages I want is the "SS34", so I've elected to use this part for LDO and ESD protection. The SS34 has a slightly smaller courtyard, so routing only needed minor adjustments.

14.

The "Basic" AMS1117 seems to be a "Drop-in" replacement for the NCP1117/LM1117 type of voltage regulator.

15.

The KiCAD footprint and symbol for all the "1117" parts seem to be identical, but I swapped in the new symbol anyway.

16.

The Datasheet for the AMS1117 recommends using 22uF capacitors on the Vout and Vin lines, as opposed to the 10uF we're currently using.

17.

The smallest size of "Basic" 22 uF capacitor is a 1206-sized part, which is much larger than the capacitors we're currently using.

18.

In order to fit these larger 1206-sized capacitors, I moved the SS34 diode a little farther away from the LDO to make room.

19.

Running this new slightly more cost-optimized design through JLCPCB, the total comes out to $123.79, which is a reduction from the $196.10 that was previously quoted. I think the cost reductions comes from the fact that we're using green silkscreen, using Economic instead of Standard PCBA, and use fewer "Extended" components.

These cost optimizations gives us a 34.86% cost reduction on the quote for the front panel PCBs. I'm going to continue doing these cost optimizations to the card PCB (technically next week, since it's past midnight from Fri-Sat).

Entry 8: -----------------------------------------------------------------

Date: March 14, 2025

Start Time: 8:25 AM

Duration: 5.0 hours

These PCB designs seem like they're near ready to manufacture. There's a bunch of checks I need to perform before sending them in to the course staff, however.

1.

One of the checklist items was to ensure that the team names and revision number/date were visible on the PCB. We didn't have this on all of the boards, so I made sure that they were all conformant by adding them.

2.

Because of the way that our PCBs need to work mechanically together in a pretty tight form factor, I decided to validate our mechanical assumptions using KiCAD StepUp, which allowed me to import my KiCAD boards into FreeCAD.

3.

I then imported the 3D STEP model from Hammond of the 1455T2202 and moved all the boards into place in a FreeCAD assembly. The edge cut on the backplane seems to look good, giving enough space for the components on the rear of the front panel. The alignment of the right-angle power switch on the backplane to the hole cut-out on the front panel also looks good. The card PCB seems to sit well on the DIMM slot, with enough room to spare for the second UART part rotate 90 degrees to face the back.

4.

Because I verified in 3D that I had enough room to do so, I went back into KiCAD and modified the second UART port to be rotated 90 degrees. This should enable easier access to that port event when the enclosure cover is closed.

5.

I generated Gerber archives using the JLCPCB Fabrication Toolkit plug-in for KiCAD, and viewed them all in the gerbv gerber viewer. All the gerber layers seemed to match what I expected.

6.

I then went to the JLCPCB website to set up a quote for the PCBs, taking care to add the BOM and position (CPL) files for the front panel and card, because of out usage of the RP2350B.

The total for the JLCPCB order came out to be $426.64. This is currently too high for my liking, but we'll send off the Gerbers for review for now.

Entry 7: -----------------------------------------------------------------

Date: March 13, 2025

Start Time: 8:32 PM

Duration: 10.5 hours

I'm going to work on the silkscreen for the front panel now. It's important that the silscreen of the front panel looks good, since it's going to be directly facing and interacting with end-users.

1.

I noticed that the reference designator silkscreen for many resistors was not showing, so I went into Edit > Edit Text and Graphic Properties of the KiCAD PCBNew editor, and set all Reference designators to be visible.

2.

I then sent all the existing silkscreen that was on the front silkscreen layer to the back, by selecting all text on the front silkscreen layer, setting the layer to the back silkscreen, and enabling the "Mirror" option.

3.

I then moved the silkscreen elements on the back of the PCB around so that they do not overlap with each other or with pads.

4.

To create the more aesthetic silkscreen visible to the end-user, I'm making reference to the silkscreen present on the front-panel of the original Altair 8800, using this image on WikiMedia Commons.

5.

I moved the tactile switches down slightly to make a bit of room for the front silkscreen intended for the slide switches.

6.

I then added line and text elements to the front silkscreen layer, matching up with the design of the 8800 as best as I could. For the dotted lines, I selected the "dotted" option on the line properties.

7.

I then took the silkscreen design that I made in Week 1 Entry 1, and pasted it into a new Affinity Designer project sized to the space I had available for a negative silkscreen (87.3 mm x 27.4 mm). I exported this file from Affinity Designer to an SVG file.

8.

I then imported the SVG file into inkscape, realigned the text to make way for the hole on the right, and the tactile buttons to the left, and exported the file again over to a DxF file.

9.

I then imported the DXF file as graphics into KiCAD, using the new geometry as a "Keep-out Zone" for a front silkscreen zone fill, so that the geometry acts as a negative.

10.

I increased the font size of as many text elements as I could on the front panel in order to increase readability.

11.

Reading an Electronics StackExchange post, I feel like my usage of a diode across Vout and Vin, is OK. I decided to choose a specific part, the LSM115JE3/TR13 (DigiKey), a very low forward-voltage drop Schottky diode, which should minimize the difference between Vout and Vin when Vout is higher than Vin. I imported the footprint for this component, and added a cathode marker to the silkscreen on the footprint.

12.

I then set up the 3D model path for the footprint to refer to the instance in our shared library.

13.

I decide to also use this diode for the ESD protection on the I/O expansion, and then place and route the connections for the LDO, the diodes, and the capacitors for the LDO.

14.

I then finish adding and routing the LED resistors, placing a via to tap into the 3.3V power plane.

15.

The front panel PCB is now fully routed.

16.

With the board fully routed, I ran the DRC, and got 50 DRC errors. All of these errors are related to tiny track artifacts, and some decoupling capacitors being rotated 180 degrees.

17.

Deleting the track artifacts, and rotating some of the decoupling capacitors (related to the fact that most of the tracks near the MCU were pasted in), we're left with 0 DRC errors.

18.

And after resizing the rear silkscreen text on the slide switches, we have 0 DRC warnings.

19.

Here's what the front panel looks like right now. We're pretty much done with the front panel I think.

20.

On the card PCB, I changed out the vertical JST XH connectors to 90 degree variants, so that it would be easier to attach cables into onto the cards when slotted into the enclosure.

21.

I then added a second UART port (1 for debug, 1 for communication) to the schematic, and also set that to a JST XH connector.

22.

I then inserted the same Schottky protection diode that we had on the front panel into the card PCB, and rearranged the LDO section of the board to fit the new diode footprint.

23.

With these changes, the card DRC still fully passes.

24.

Here's what the card looks like right now.

The PCB designs for the card and front panel are pretty much finalized. Next time I'll need to go through the final course PCB checklist, and run/check through any other issue I can think of.

Entry 6: -----------------------------------------------------------------

Date: March 13, 2025

Start Time: 4:36 PM

Duration: 3.0 hours

Because a right-angle USB connector doesn't work for the front-panel use-case, I've decided to use the GCT USB4235-03-C (DigiKey) on the front panel, which is a vertical variant of the GCT USB4105-GF-A connector we're already using on the card and backplane PCBs.

1.

GCT USB4235-03-C is a relatively new part, and DigiKey doesn't have the ECAD models for it indexed yet. Heading over to the GCT listing for the part, there's a link to "Download PCB Model", which redirects me to the SnapMagic entry for the part.

2.

I then downloaded the KiCAD v6 version of the ECAD file from SnapMagic, imported the symbol and footprint, and configured the footprint to load the 3D model correctly from our shared footprint library.

3.

I then replaced the USB4105-GF-A symbol with the USB4235-03-C symbol in the schematic, and edited the instance of the USB4235-03-C symbol to rearrange the pins to be in a similar layout as the old schematic.

4.

I then connected the new symbol up in the same manner as the old one; pulling down the CC lines using 5.1 kiloOhm resistors, and wiring in the paired D+ and D- signals.

5.

Here's what the new receptacle looks like in 3D.

6.

In order to make possibly routing signals onto the front of the board easier, I modified this section of traces that loops around the oscillator to be on the back copper as much as possible, as opposed to the interweaved layout they had previously.

7.

I then placed the USB connector on the side of the MCU where the USB signals are, and routed large 0.500mm traces up to the termination resistors.

8.

VBUS is another large signal, and I felt that I could route it within the 3.3V power plane for a short distance. I also set up a small rectangular zone to make routing the VBUS power easier in the connector area.

9.

There wasn't a USB BOOT signal in the panel schematic yet, so I went and added that, copied over from the card schematic.

10.

I then laid out and routed the chip RESET and USB BOOT SMD buttons.

11.

I wanted a 3D model of the QFN I/O expanders, so I referenced the MCP23017 data sheet to get the relevant package dimensions, and determined that the closest KiCAD 3D Library model to the part was ${KICAD8_3DMODEL_DIR}/Package_DFN_QFN.3dshapes/QFN-28-1EP_6x6mm_P0.65mm_EP4.25x4.25mm.step. Setting this in the footprint properties, the I/O expanders now display with 3D models.

12.

Here's the current state of the front panel board.

I think we're very very close to a final layout and route of the front panel board. I need to work on the silkscreen for the front panel later.

Entry 5: -----------------------------------------------------------------

Date: March 12, 2025

Start Time: 11:13 PM

Duration: 2.0 hours

I'm continuing on with the routing and reassignment of net labels that I was working on a little bit prior.

1.

While trying to route the FFC signals to the sink driver, I found that t`he labels on the FFC side leading up to the U4 sink driver are flipped for some reason.

2.

Unflipping these labels on the FFC side lets me complete the route to U4.

3.

I then routed the signal connections to the other four (4) sink drivers, which was relatively straightforward.

4.

I also went and finished the traces on the other side of the sink drivers, which lead up to the LEDs themselves.

5.

Now it's time to look at the MCU FFC mapping issues again. I decided to start again and reassign MCU GPIO pin numbers to the closest FFC pin.

6.

Here's the result of that labor. Hopefully these signals line up.

7.

I decided to swap the A6 and D6 signals here to improve ease of routing those signals.

8.

I then routed the signals between the resistors and the FFC, and the MCU up to the resistors. Looks like it's clean. Good.

9.

I then modified the schematics of the I/O expanders to match the remapping tables I made in entry 4.

10.

With the schematic changes done, I could now fully route the buttons and switches up to the I/O expanders.

11.

I also routed the current limiting resistors up to their respective LEDs.

12.

Here's what all of that work looks like put together so far. I think the front panel is coming together.

I'm really really tired right now, so I'm going to take a much longer break, but when I get back, I'm going to clean up all the other stuff I need to get done on the front panel, such as the USB connector, USB power (LDO), SWD, protection diodes, USB BOOT and chip RESET switchse, and designing the front layer silkscreen pattern.

Entry 4: -----------------------------------------------------------------

Date: March 12, 2025

Start Time: 8:28 AM

Duration: 11.5 hours

Good morning, I'm continuing off on the work I'm doing on the front panel PCB. I'm going to start off by laying out the decoupling capacitors for the sink drivers.

1.

The U4 sink driver is packed pretty tightly around other signals and holes, so it's not easy trying to place down a decoupling capacitor. I've opted to created a filled zone beneath the component, with the capacitor on the other side of it.

2.

The GPIO signals from the MCU need to be packed in-between these through-holes created by the slide switch footprints, so I'm packing together as many signals as I can between the through-holes as I can before them.

3.

I think the best way to try to fit in protection resistors is to try to arrange them into blocks in the area between the switches. I think a staggered arrangement like this should work.

4.

During ManLab, it was noted that I should consider a different design for the arrangement of protection diodes, as shown, with protection across 3.3V and VBUS between the LDO and the rest of the net, instead of between Vout and Vin. I should look into this more later.

5.

I continued trying this packed-in "resistor block" routing strategy for other sides of the chip.

6.

I wired in GPIOs 38 & 39 as the I2C bus that goes into both I/O expanders. One (1) I/O expander is configured to have a higher hardware address to the other by pulling one of its hardware address pins to 3.3V.

7.

I continued routing from the other side of the resistors, just up to the edge connector, like before. I'll reconfigure the pin functions (net names) on the MCU side later such that I can complete the route. The reason I'm doing it this way is because many of the pin functions on the FFC side are dictated by the sink drivers' connections to the status LEDs, which are fixed-function.

8.

Here's that initial routing being done for all the MCU connections.

9.

In order to complete the routes for all the components, I need to build out a remapping table for
  • all sink drivers (5 of them)
  • all I/O expanders (2 of them)
  • the FFC/RP2350B interface

10.

For the sink drivers, I looked at the function of the LEDs that the driver was connected to, and reassigned the net of the pin to that function. Here's the remappings for the sink driver on the very left (flipped view).
Show remapping table
Pin Old New
6 HLDA PROT
7 WAIT INTE
8 PROT WAIT
9 INTE HLDA
12 PROT_LED HLDA_LED
13 INTE_LED WAIT_LED
14 WAIT_LED INTE_LED
15 HLDA_LED PROT_LED

11.

Here's the remappings for the sink driver to the right of that one (flipped view).
Show remapping table
Pin Old New
2 INT A12
3 WO A13
4 STACK OUT
5 HLTA M1
6 OUT A14
7 M1 MEMR
8 INP INP
9 MEMR A15
12 MEMR_LED A15_LED
13 INP_LED INP_LED
14 M1_LED MEMR_LED
15 OUT_LED A14_LED
16 HLTA_LED M1_LED
17 STACK_LED OUT_LED
18 WO_LED A13_LED
19 INT_LED A12_LED

12.

Here's the remappings for the sink driver in the middle of the others (3 out of 5).
Show remapping table
Pin Old New
2 A8 A8
3 A9 A9
4 A10 INT
5 A11 A10
6 A12 WO
7 A13 A11
8 A14 STACK
9 A15 HLTA
12 A15_LED HLTA_LED
13 A14_LED STACK_LED
14 A13_LED A11_LED
15 A12_LED WO_LED
16 A11_LED A10_LED
17 A10_LED INT_LED
18 A9_LED A9_LED
19 A8_LED A8_LED

13.

Here's the remappings for the sink driver on the left of the FFC connector (flipped view).
Show remapping table
Pin Old New
2 D0 A4
3 D1 D4
4 D2 A5
5 D3 D5
6 D4 A7
7 D5 A6
8 D6 D6
9 D7 D7
12 D7_LED D7_LED
13 D6_LED D6_LED
14 D5_LED A6_LED
15 D4_LED A7_LED
16 D3_LED D5_LED
17 D2_LED A5_LED
18 D1_LED D4_LED
19 D0_LED A4_LED

14.

And here's the remappings for the sink driver all the way on the right of the board (flipped view).
Show remapping table
Pin Old New
2 A0 D0
3 A1 D1
4 A2 A1
5 A3 A0
6 A4 D2
7 A5 A2
8 A6 D3
9 A7 A3
12 A7_LED A3_LED
13 A6_LED D3_LED
14 A5_LED A2_LED
15 A4_LED D2_LED
16 A3_LED A0_LED
17 A2_LED A1_LED
18 A1_LED D1_LED
19 A0_LED D0_LED

15.

For the I/O expanders, I'm doing something similar. The function of each of the buttons and switches is pre-defined, so I need to reassign the nets on the I/O expander according to whatever switch they're connected to. Here's the remappings for the I/O expander connected to the 16 slide switches.
Show remapping table
Pin Old New
1 A7_SW A7_SW
2 A6_SW A6_SW
3 A5_SW A5_SW
4 A4_SW A4_SW
5 A3_SW A3_SW
6 A2_SW A2_SW
7 A1_SW A1_SW
8 A0_SW A0_SW
12 I2C1_SCK I2C1_SCK
13 I2C1_SDA I2C1_SDA
19 NC NC
20 NC NC
21 AUX2 A15_SW
22 AUX1 A14_SW
23 UNPROTECT A13_SW
24 PROTECT A12_SW
25 CLR A11_SW
26 RESET A10_SW
27 NC A9_SW
28 NC A8_SW

16.

And similarly, here's the table for the I/O expander assigned to all the tactile button switches.
Show remapping table
Pin Old New
1 A15_SW CLR
2 A14_SW UNPROTECT
3 A13_SW AUX1
4 A12_SW PROTECT
5 A11_SW AUX2
6 A10_SW NC
7 A9_SW NC
8 A8_SW NC
12 I2C0_SCK I2C1_SCK
13 I2C0_SDA I2C1_SDA
19 NC PUSH_INTB
20 NC PUSH_INTA
21 DEPOSIT RUN
22 DEPOSIT_NEXT STOP
23 EXAMINE SINGLE
24 EXAMINE_NEXT EXAMINE_NEXT
25 STEP EXAMINE
26 SINGLE DEPOSIT_NEXT
27 RUN RESET
28 STOP DEPOSIT

17.

For the table describing the FFC to MCU remappings, I first set up a table going through all the non-power pins on the FFC connector, and writing down their original net assignment.
Show "old mapping" table
Pin Old New
3 ???
4 ???
5 ???
6 ???
9 ???
10 ???
11 ???
12 ???
15 ???
16 A0
17 A1
18 A2
21 A3
22 A4
23 A5
24 A6
27 A7
28 D0
29 D1
30 D2
33 D3
34 D4
35 D5
36 D6
44 A8
45 A9
46 A10
47 A11
50 A12
51 A13
52 A14
53 A15
56 INT
57 WO
58 STACK
59 HLTA
62 OUT
63 M1
64 INP
65 MEMR
68 HLDA
69 WAIT
70 PROT
71 INTE
74 I2C1_SCK
75 I2C1_SDA
76 I2C0_SCK
77 I2C0_SDA

18.

I then extended this table, by cross referencing where the sink driver signals lines met with the FFC connector, to set the new function of that FFC connector line. I then also assigned the MCU GPIO signals based on where it was located physically (closest) relative to the FFC line.
Show remapping table
Pin Old New RP2350B Grp Con Driver
BUS03 ??? A3 44 GPIO35 A A U5 9
BUS04 ??? D3 43 GPIO34 A A U5 8
BUS05 ??? A2 42 GPIO33 A A U5 7
BUS06 ??? D2 40 GPIO32 A A U5 6
BUS09 ??? A0 39 GPIO31 B A U5 5
BUS10 ??? A1 52 GPIO41 B B U5 4
BUS11 ??? D1 38 GPIO30 B C U5 3
BUS12 ??? D0 49 GPIO40 B D U5 2
BUS15 ???
BUS16 A0
BUS17 A1
BUS18 A2
BUS21 A3 PANEL 37 GPIO29 B E
BUS22 A4 MWRT 57 GPIO46 B F
BUS23 A5 DBIN 58 GPIO47 B F
BUS24 A6 HOLD 36 GPIO28 B G
BUS27 A7 RESET 28 GPIO27 B G
BUS28 D0 PRDY 27 GPIO26 B G
BUS29 D1 XRDY 26 GPIO25 B G
BUS30 D2 INTA 25 GPIO24 B G
BUS33 D3 D7 16 GPIO16 C H U4 9
BUS34 D4 D6 17 GPIO17 C H U4 8
BUS35 D5 A6 18 GPIO18 C I U4 7
BUS36 D6 A7 19 GPIO19 C I U4 6
BUS44 A8 D5 20 GPIO20 C I U4 5
BUS45 A9 A5 22 GPIO22 C J U4 4
BUS46 A10 D4 21 GPIO21 C J U4 3
BUS47 A11 A4 23 GPIO23 C K U4 2
BUS50 A12 PROT 53 GPIO42 C L U1 6
BUS51 A13 INTE 54 GPIO43 C L U1 7
BUS52 A14 WAIT 55 GPIO44 C L U1 8
BUS53 A15 HLDA 56 GPIO45 C L U1 9
BUS56 INT A12 79 GPIO02 C M U2 2
BUS57 WO A13 80 GPIO03 C M U2 3
BUS58 STACK OUT 78 GPIO01 C N U2 4
BUS59 HLTA M1 77 GPIO00 C N U2 5
BUS62 OUT A14 1 GPIO04 D O U2 6
BUS63 M1 MEMR 2 GPIO05 D O U2 7
BUS64 INP INP 3 GPIO06 D O U2 8
BUS65 MEMR A15 4 GPIO07 D O U2 9
BUS68 HLDA HLTA 6 GPIO08 D O U3 9
BUS69 WAIT STACK 7 GPIO09 D O U3 8
BUS70 PROT A11 8 GPIO10 D O U3 7
BUS71 INTE WO 9 GPIO12 D P U3 6
BUS74 I2C1_SCK A10 11 GPIO11 D P U3 5
BUS75 I2C1_SDA INT 12 GPIO13 D Q U3 4
BUS76 I2C0_SCK A9 13 GPIO14 D Q U3 3
BUS77 I2C0_SDA A8 14 GPIO15 D Q U3 2

19.

I then adjusted the schematics of the sink drivers and the MCU to match the remapping tables I created.

20.

The signals near the sink drivers are now fully routable.

21.

It seems that I may have messed something up in the MCU-FFC connection however, I'll need to take a look at this later.

I made some more progress today with routing the front panel today. I think that once I get the mappings fixed between the FFC connector and the MCU, most of the final routing should fall into place. I'm going to take a dinner break before coming back into lab to finish that.

Entry 3: -----------------------------------------------------------------

Date: March 12, 2025

Start Time: 12:36 AM

Duration: 7.0 hours

I clarified with Shivam earlier that we really couldn't order components from Aliexpress/Alibaba, which is a bit of an issue with our current choice of enclosure, the LK-ALS43 (Aliexpress, Alibaba). We need to find another supplier for enclosures that we can acquire through domestic sources.

1.

The Hammond 1455 series of enclosures seems nice, especially since they're relatively affordable, and can be found on electronics distributors like DigiKey. We're specifically looking at the 1455T1602 model, which is 6.3" x 6.5" x 2.05" (160mm x 165mm x 52 mm). These are about $25 each on DigiKey.

2.

I drew up a 165mm x 52mm rectangle, and tried to move the components Nathan laid out to within the confines of this box in ways that felt about right. This confirmed that we should have enough real estate on a PCB that attaches to this enclosure. We'll need a more precise drawing of the enclosure to design the board around, however.

3.

On the Hammond website for the 1455 series, clicking on 1455T1602 allows us to download the "2D CAD" file for the part. This is a DWG file. I can load the DWG in LibreCAD, and export the file as a DXF, allowing KiCAD to read the drawing.

4.

I can import the DXF into the KiCAD PCB editor by going through File > Import > Graphics... and selecting the DXF file. KiCAD imports the DXF onto the User.Drawings layer.

5.

I delete all the geometry that I'm not concerned with. I then move the extrusion profile drawing to the back courtyard layer (as to allow for parts on the back of the PCB to not interfere mechanically with the aluminum extrusion itself), and the front plate drawing over to the edge cuts layer.

6.

I've added 4 mounting holes to the schematic, and assigned them the 3.5mm hole, which is about the same size as on the drawing. This hole size should be able to let the bolts through cleanly.

7.

The footprints for these holes are then placed on to the centers of the edge cut circles on the imported drawing.

8.

Moving in the approximiate layout I put together earlier, it's pretty clear that There's some additional squeezing that needs to be done to fit within the courtyards defined by the extrusion profile.

9.

I realized that it's not possible to use a 90 degree USB connector on the front panel PCB, because the board is surrounded by aluminum walls on four (4) sides. I'll need to switch the footprint for this part with a verticle USB receptacle later.

10.

I squeezed the LEDs, sink driver, and slide switch courtyards to be within the confines of the enclosure.

11.

And I also did so for the switches and I/O expanders. The I/O expander for the buttons needed to be un-rotated to fit within the vertical space available. I may do the same for the other I/O expander.

12.

I measured the length of the DIMM slot footprint on the backplane, which came out to 161mm. This exceeds the length of our current enclosure choice (1455T1602), which has a length of 160mm, so we'll need to get an enclosure that's slightly longer.

13.

If we switch over to the 1455T2201/1455T2202 model of the enclosure, we'll have 220mm to work with in length, with the same front profile. This should be more than enough length.

14.

And I confirmed that the part is also on DigiKey.

15.

I confirmed that the DWG front extrusion profile drawing is identical between 1455T2202 and 1455T1602, and flipped over the slot cover part of the drawing to be at the top of the PCB, since we want to be able to access the cards when the slot cover is removed.

16.

Here I setup the GND and power plane fills so that power vias can be routed correctly.

17.

I then add power vias to 3.3V an GND to the FFC connector.

18.

Due to the density of components relative to each other, I'm following a similar strategy with routing these signals as with the card, which means that I'll first route the traces first, then remap the net names to complete the traces. I'm doing this with the sink drivers first, because their connections to the status LEDs dictate what purpose signals further down the front panel serve. In this manner, I begin routing the sink lines to the 8 LEDs on the right of the PCB.

19.

I repeat this process with the sink driver on the other side of the FFC connector.

20.

The sink driver to the left of that is routed to a block of 8 additional LEDs.

21.

Even further left, two sink drivers need to drive 12 LEDs. For the right one here, I route it to a block of 8 LEDs.

22.

And the very leftmost sink driver gets routed to the last block of 4 LEDs.

23.

I pursue a similar strategy with the I/O expanders, but I make sure to separate the roles of the I/O expander dedicated to buttons, and the I/O expander dedicated to slide switches. This is the ensure that the two interrupt lines on the I/O expander dedicated to buttons can be reliably trusted to indicate that a button has been pressed. I first perform this routing with the button I/O expander.

24.

And do the same with the I/O expander responsible for the 16 data/address slide switches.

25.

The control lines for the sink drivers need to be routed sideways directly into the FFC connector, which I do on the front copper layer, in order to make room for those same signals to get routed to the MCU.

26.

Here's how the board looks so far on both sides.

27.

The 8 switches on the right side of the PCB are also currently routed on the back copper, so I noved these signals to the front copper layer, also to make room for the FFC to MCU signal routing.

28.

A significant amount of routing related to decoupling capacitors, QSPI flash, and the crystal oscillator should be identical between the card and the panel, so I copied over the vias and tracks from the card PCB design, and matched up the MCU footprint location with the pasted tracks.

29.

I then cleaned up and rotated the whole block of traces, vias, and footprints into place, with as many of the GPIO pads facing upwards as possible.

30.

I set up the GND zones for the top and bottom layers of copper, since we're finishing up on the routing between FFC and MCU.

31.

I noticed that the slot cover for the extrusion, since rotating the rear courtyard 180 degrees, now interferes with the courtyard for the LEDs. Ultra Librarian put a very aggressive courtyard on these LEDs, which I don't believe is necesary, so we can reduce the courtyard to fit.

32.

In the library footprint editor, I resize the courtyard for the LEDs such that they're not as wide, and reload the footprints from the library for all LED footprints on the PCB.

33.

With this change, the courtyards of all the LEDs fit. I also take the opportunity to fit in all the current limiting resistors next to the LEDs.

34.

I move the footprints for all the decoupling capacitors for the MCU over the appropriate pasted traces.

It's morning now, so I'm going to take a break to eat breakfast. I still need to finish up the MCU routing, and remember, all this routing is just 90% there, I still need to reassign all the net names to actually complete all of the traces.

Entry 2: -----------------------------------------------------------------

Date: March 11, 2025

Start Time: 12:40 PM

Duration: 3.0 hours

I'm continuing on from yesterday with the card PCB. First thing I want to get through are all of those DRC errors (230) that are remaining.

1.

A significant number of errors came from the fact that I did not route the 3.3V connections on the back side of the PCB. I went ahead and did this, which resulted in the board having 0 unrouted nets. This decreased the number of DRC errors from 230 to 192.

2.

Another significant source of DRC errors was the fact that the spacing between pads on the RP2350B's QFN package was 0.18mm, which was lower than the 0.20mm clearance defined in our board constraints. JLCPCB should be fine with manufacturing these QFN packages, so I entered the footprint properties by hitting "E" on the RP2350B footprint, went into the "Clearance Overrides and Settings" tab, and set the "Pad clearance" to 0.18mm. This decreased the number of DRC errors from 192 to 118.

3.

Nearly all of our warnings are silkscreen overlap warnings coming from the resistor blocks. I'm moving them out the way, spreading them out, since the silkscreen is slightly larger than the 0402 footprint courtyard.

4.

One of our DRC errors notes that the maskless part of the DIMM in the middle is bridging nets, which makes sense. That part of the DIMM is actually supposed to be completely bare FR4.

5.

To rectify this issue, I moved the boundaries of all of our copper zone pours for all 4 layers up and above the courtyard of the edge connector.

6.

Because the GND pour no longer reaches all the way to the bottom of the board, I need to route the GND power manually. I'm also adding GND power vias here while I'm at it.

7.

There's 58 DRC errors remaining, all of which are related to the edge cut clearance on the DIMM connector pads, and the alignment hole edge clearance on the USB connector. Since there's nothing really I can change about these; they need to be drawn this way to support the interface, I'm ignoring these DRC errors.

8.

Here's the current state of the board. Looks like things are coming together.

9.

According to section (1.2.3) of the RP2350B datasheet, GPIO pins 44 and 45 correspond to UART0 TX and RX respectively. I marked this functionality with another label on the schematic.

10.

To support print-debugging, we need a UART connector in addition to the SWD connector, so I've also added another JST XH connector to the schematic on the UART0 pins.

11.

Referring to the NCP1117 datasheet, if we really want reverse current protection on the LDO, we can add a diode between Vout and Vin of the LDO. I've decided to add a Schottky diode in my schematic in the same manner.

12.

I noticed that in certain locations, my power vias for 3.3V are currenty located in-between the MCU and the capacitor, which isn't ideal. I will need to move these vias over to the other side of the capacitors later.

13.

I imported and laid out the protection diode for the LDO on the PCB.

14.

I imported and routed the JST XH connector for the UART0 port on the PCB.

15.

Here's the current status of the PCB and the schematic. I think we're very very close the final layout now.

16.

I'm currently working on fixing up the via locations for the decoupling capacitors. For this IOVDD (pin 29 on the QFN package), it's a bit difficult to make a clean trace to the vias, so instead I've created a really small zone to fill the area containing the pads and the vias.

17.

In other locations, the solution is pretty simple: move the vias over to the other side of the capacitor's pad, and route.

18.

The decoupling capacitor for the QSPI flash wasn't routed correctly (it was placed near the MCU and not the flash). It's currently rotated at a 45 degree angle, but I can make it aligned to the normal grid again, just like the flash itself. I placed and routed this capacitor.

19.

The GND pad on the LDO only had one (1) thermal relief spoke going into the ground plane, which I felt wasn't enough, so I added a thick trace to explicitly create a second spoke.

20.

I then added a couple power vias near the GND pad to tap in to the inner GND plane.

21.

Here's what the board looks like now with the fixed-up routing, and new connectors and diodes.

I think this is close to the final layout we want for the card. There's still a couple more things that I'd like to do, such as add a second JST XH connector for a second UART port (such that we have one (1) UART for debugging, and another for communication for use in our stretch PSDR), and validation that my footprint choices map to real parts (in particular, I haven't chosen a specific Schottky diode yet, so I don't know whether the 0402 footprint I chose for the diode is correct).

Entry 1: -----------------------------------------------------------------

Date: March 10, 2025

Start Time: 10:13 AM

Duration: 6.5 hours

Continuing from last time, I'd like to finish up the card design as soon as I can. I really dislike how much the current design relies on installing parts on both sides of the board, especially since we have all that space on the other side of the DIMM that we can use. I'll work on rectifying this, and finishing up the routing for the PCB in general.

1.

I went and moved all the components that were on the backside copper to approximately where I wanted them to be. This basically meant that I moved the I/O expansion to the other side of the board, the relevant jumper along with them, and slightly relocating the QSPI flash memory. I then flipped over the QSPI memory, which sits at a 45-degree angle relative to the RP2350B chip itself (meaning that the flash is at a normal right angle), and wired it in.

2.

I'm trying to route all the GPIO signals from the RP2350B over to the closest area I can reach on the edge connector. Currently, I'm not connecting it directly to the pad on the edge connector, because I need to reassign the edge net labels based on my routing, not the other way around. I'm trying to alternate whether I'm routing from the front or the back of the board to the board edge.

3.

I realized the I wasn't really using that much board space to route the traces, and that I could definitely pack a lot more of them onto the front layer without any issue. I'm going to retry my edge connector routing, and start from pins 80 & 1 - pins 41 & 40 on the chip side and try to map all those to pins 5-72 on the edge connector. I think my new strategy definitely looks better and more compact.

4.

Moving over to the other size of the chip, I'm taking care to route my signals around the "shielding" GND zone I set up a-round the oscillator.

5.

All the remaining GPIO signals on the far end of the chip get routed to the father end of the edge card. It's a longer path but I think it should be fine.

6.

I flipped over all the 0 Ohm jumper "resistors" and I/O expander footprints over to the front copper, and positioned them a little closer to where I wanted them to be.

7.

I then wired in the last 4 GPIO signals into the jumpers. In this case they can act either directly as bus lines via a jumper, or be routed on the card as I2C signals to the I/O expanders via another jumper.

8.

With this done, all components are now on one side of the board, and the backside is completely unpopulated. This should make both PCBA at JLCPCB, and reflow soldering of components on the hot-plate for us easier.

9.

All the routing still stops right before the edge connector, because the net labels between the edge connector and the trace are still mismatched. I'm cross-referencing the net name of the trace and the net name of the edge connector, and changing the net name of the edge connector to match. I took notes on the differences between the old net names and the new net names in a table.
Show net mapping table
Edge Connnector Pin MCU Pin Label MCU Pin Number Current Usage
1. 3V3
2. 3V3
3. GND
4. GND
5. GPIO3 80 BUS20
6. GPIO2 79 BUS21
7. GPIO4 1 BUS19
8. GPIO5 2 BUS18
9. GPIO1 78 BUS22
10. GPIO6 3 BUS17
11. GPIO7 4 BUS16
12. GPIO0 77 BUS23
13. 3V3
14. 3V3
15. GND
16. GND
17. GPIO8 6 BUS15
18. GPIO9 7 BUS14
19: GPIO10 8 BUS13
20. GPIO11 9 BUS12
21. GPIO12 11 BUS11
22. GPIO13 12 BUS10
23. GPIO14 13 BUS09
24. GPIO15 14 BUS08
25. 3V3
26. 3V3
27. GND
28. GND
29. GPIO16 16 BUS07
30. GPIO17 17 BUS06
31. GPIO18 18 BUS05
32. GPIO19 19 BUS04
33. GPIO20 20 BUS03
34. GPIO21 21 BUS02
35. GPIO22 22 BUS01
36. GPIO23 23 BUS00
37. 3V3
38. 3V3
39. GND
40. GND
41. GPIO24 25 ADDR00
42. GPIO47 58 DATA07
43. GPIO25 26 ADDR01
44. GPIO46 57 DATA06
45. GPIO26 27 ADDR02
46. GPIO42 53 DATA02
47. GPIO27 28 ADDR03
48. GPIO41 52 DATA01
49. 3V3
50. 3V3
51. GND
52. GND
53. GPIO28 36 ADDR04
54. GPIO29 37 ADDR05
55. GPIO30 38 ADDR06
56. GPIO31 39 ADDR07
57. GPIO32 40 ADDR08
58. GPIO33 42 ADDR09
59. GPIO34 43 ADDR10
60. GPIO35 44 ADDR11
61. 3V3
62. 3V3
63. GND
64. GND
65. GPIO36 45 ADDR12
66. GPIO37 46 ADDR13
67. GPIO38 47 ADDR14
68. GPIO39 48 ADDR15
69. GPIO45 56 DATA05 (JP1)
70. GPIO44 55 DATA04 (JP3)
71. GPIO43 54 DATA03 (JP5)
72. GPIO40 49 DATA00 (JP7)
73. 3V3
74. 3V3
75. GND
76. GND
77. NC

10.

I decided the swap the functions on the MCU side of package pins 49 and 53 (logical pins GPIO40 and GPIO42), to allow for all jumper bus signals to be together in its own block (GPIOs 42-45)
Show net mapping table
Edge Connnector Pin MCU Pin Label MCU Pin Number Current Usage
1. 3V3
2. 3V3
3. GND
4. GND
5. GPIO3 80 BUS20
6. GPIO2 79 BUS21
7. GPIO4 1 BUS19
8. GPIO5 2 BUS18
9. GPIO1 78 BUS22
10. GPIO6 3 BUS17
11. GPIO7 4 BUS16
12. GPIO0 77 BUS23
13. 3V3
14. 3V3
15. GND
16. GND
17. GPIO8 6 BUS15
18. GPIO9 7 BUS14
19: GPIO10 8 BUS13
20. GPIO11 9 BUS12
21. GPIO12 11 BUS11
22. GPIO13 12 BUS10
23. GPIO14 13 BUS09
24. GPIO15 14 BUS08
25. 3V3
26. 3V3
27. GND
28. GND
29. GPIO16 16 BUS07
30. GPIO17 17 BUS06
31. GPIO18 18 BUS05
32. GPIO19 19 BUS04
33. GPIO20 20 BUS03
34. GPIO21 21 BUS02
35. GPIO22 22 BUS01
36. GPIO23 23 BUS00
37. 3V3
38. 3V3
39. GND
40. GND
41. GPIO24 25 ADDR00
42. GPIO47 58 DATA07
43. GPIO25 26 ADDR01
44. GPIO46 57 DATA06
45. GPIO26 27 ADDR02
46. GPIO40 49 DATA00
47. GPIO27 28 ADDR03
48. GPIO41 52 DATA01
49. 3V3
50. 3V3
51. GND
52. GND
53. GPIO28 36 ADDR04
54. GPIO29 37 ADDR05
55. GPIO30 38 ADDR06
56. GPIO31 39 ADDR07
57. GPIO32 40 ADDR08
58. GPIO33 42 ADDR09
59. GPIO34 43 ADDR10
60. GPIO35 44 ADDR11
61. 3V3
62. 3V3
63. GND
64. GND
65. GPIO36 45 ADDR12
66. GPIO37 46 ADDR13
67. GPIO38 47 ADDR14
68. GPIO39 48 ADDR15
69. GPIO45 56 DATA05 (JP1)
70. GPIO44 55 DATA04 (JP3)
71. GPIO43 54 DATA03 (JP5)
72. GPIO42 53 DATA02 (JP7)
73. 3V3
74. 3V3
75. GND
76. GND
77. NC

11.

I went and swapped the jumper over to pin 53 on the schematic, and made the necesary routing changes on the MCU side on the PCB.

12.

Additionally, since we moved the jumper block across over to a different set of pins, according to section (1.2.3) of the RP2350B datasheet, pins 42 and 43 correspond to I2C peripheral 1, and 44 and 45 correspond to I2C peripheral 0. I've changed the labels on the schematic appropriately.

13.

Following the recommendation to install protection resistors on all pins that are on the bus, as to reduce current flow into the MCU in situations where a GPIO pin is misconfigured, I went and added KiCAD's R_Small symbol in front of each label to the bus side. This separates the nets, so the new bus side labels simply refer to the edge card connector's pin number.

14.

I chose to use 330 Ohms as the protection resistor size, as it should be a small enough value within the Hi-Z and pull-up/pull-down resistor configurations of the I/O pin, and still be able to meet the voltage levels necesary to determine digital LOW vs HIGH (referring to section 14.9.4 on I/O characteristics in the RP2350 datasheet). I may want to recheck the value I'm using here later, but this feels pretty close to correct for now.

15.

I went and set up the net labels on the edge card side, with the labels describing pin numbers. Additionally, for the other end of the edge connector, I've designated them "BEX" for use in expansion. These "BEX" labels are added on to the other end of the I/O expanders, which also get protection resistors.

16.

The new protection resistors are set to 0402 sizing in the KiCAD footprint assignment UI. This is pretty much a necesary size due to the sheer quantity of I/O lines we have.

17.

Here's all the new 0402-sized resistors imported into the PCB. I tried to fit them in-between the current routing, but was unable to fit them.

18.

In order to fit everything, I decided to select all the other components and traces, and move them up slightly, to make room for the protection resistors.

19.

This also meant that some components and traces went past the top part of the DIMM. In particular, the USB connector's board edge annotation now goes past the top. It's really not easy to try to move this connector, since trying to move it down collides with power, flash, and the MCU below. The edge annotation goes past the end of the board almost exactly 1 mm.

20.

To resolve this issue, I decided to go and expand the edge cut of the board by 1 mm. The edge cut for the card PCB is a little weird; the edge cut is defined as a layer inside of our edge card connector footprint. So, to change this, I needed to go into the footprint editor for our edge connector, and used the positioning tools to move the edge cut line segment up exactly 1 mm.

21.

Viewing the whole board now, with the edited edge card footprint, it looks like everything lines up.

22.

I then moved all the protection resistors in place, which now fit between the chips and the edge connector.

23.

I aligned the 0402 courtyards to be as close to each other as possible, such that they can fit in-between the power vias that straddle them.

24.

I then routed all the connections to the protection resistors, and the resistors to the edge card. This process was repeated for each resistor "block".

25.

Here's how it looks with everything all put together, all MCU GPIOs and expander I/Os wired in.

26.

Since the PCB is finally in good enough condition to get useful output out of DRC, I ran DRC, and got 233 errors, that I'll need to resolve. Most of these are unconnected tracks (mostly tiny artifacts that I can just delete) and minor clearance violations that I think I can jiggle my way out of.

27.

Removing the small unconnected traces, I'm left with 230 other DRC errors, which are mostly clearance violations. I will need to correct these later.

28.

Here's what the PCB looks like right now.

There's still additional work left to do on the card. This includes cleaning up all those clearance violations, adding connectors for UART debugging, and adding a protection diode for the LDO.

=============== Week 8: =================

Entry 3: -----------------------------------------------------------------

Date: March 5, 2025

Start Time: 3:28 AM

Duration: 6.0 hours

Our Midterm Design Review presentation is today. I'd like to get some semblance of a PCB layout out to be able to present. I'll be working on the card, since that's where I have been paying the closest attention to.

1.

I've produced an initial layout with the parts placed and oriented about where I want them. In particular, the oscillator is near the XIN and OUT pins, and the USB port is the on correct side of the chip. Additionally, the chip is oriented at a 45 degree angle to help with signal fan-out.

2.

Here's what that looks like in the 3D view. Additionally, I've moved the QSPI chip closer to the QSPI side of the chip.

3.

I've moved the decoupling capacitors towards the power pins of the RP2350B, the QSPI, I/O expander, and LDO chips, based on the ordering shown in the schematic.

4.

In Section 2.1 of the Hardware Design with RP2350 guide, Raspberry Pi recommends using a very specific layout with respect to the discrete components (inductors, capacitors) surrounding the 1.1V regulator section of the chip, as seen above.

5.

I've opted to closely follow the guidance of the design guide, placing my components, zones, and vias, in a broadly similar manner.

6.

The USB termination resistors are next to this segment, so I decided to route those next. As soon as they exit the termination, I opt to run them through very thick traces for signal integrity, and then perform the necesary connector routing as close to the connector as I can.

7.

In order to distribute 1.1V regulated power to all 4 sides of the chip, I decide to plunge into the 3.3V power plane to draw a short 1.1V power zone and power trace. This cuts the 3.3V plane slightly, but not too much, and only within the confines of the microcontroller.

8.

The oscillator should nominally be jailed by ground on three (3) sides to limit the amount of noise that leaks out. I draw this ground zone ahead of time as a reminder.

9.

I perform additional routing between many components, like hooking up the chip USB BOOT and RESET switches, and the SWD connector.

10.

I set up low-priority zone fills for ground on the front and back copper. I define one internal zone as 3.3V, and another internal zone as GND.

11.

Here's what the board looks like right now. Notably, all the bus signals still need to be routed to the edge connector.

For the rest of my time, I worked on the block diagrams for the Midterm design presentation, and organized and practiced the slides with the rest of the team. The midterm design presentation immediately followed.

Entry 2: -----------------------------------------------------------------

Date: March 4, 2025

Start Time: 5:45 PM

Duration: 3.5 hours

I'm going to backport the work we did on the schematic in KiCAD v9 back to KiCAD v8. Checking with the Git version history, commit rev a4b30b7a518c92836565844396b936475d47d457 was the last version of the files we had which were saved using KiCAD v8. Consequently, I'll be basing my work off of ecad.kicad_sch, splitting its contents across three projects (card, panel, backplane), and incorporating changes from the KiCAD v9 version of the project.

  • I've created a Project_Library.kicad_sym as a common symbol library, the directory Library.pretty as a common footprints/3D models directory, and created 3 subfolders (card, panel, and backplane) which contain KiCAD v8 projects that reference the same libraries.
  • I'm keeping open 5 instances of KiCAD (4 instances of v8, to read the old v8 project, and write to the three (3) new v8 projects, and 1 instance of v9, to read from the v9 version of the project)
  • I noticed that the references between the projects and the common symbol/footprint libraries used absolute paths that were specific to my computer. For this to work properly across multiple computers, I basically need to manually prepend relative path with ${KIPRJMOD}/../
    So this would be ${KIPRJMOD}/../Library.pretty. Now repeat for all 3 symbol tables and footprint tables respectively.
  • As a comparison of the work that needs to be done to backport, here are:
    The KiCAD v9 version of the front panel
    The KiCAD v8 version of the front panel
  • Sadly data from KiCAD v9 cannot be copied back into KiCAD v9. I am performing the manual porting process of essentially redoing the work in KiCAD v8.
  • Here's the current USB connector symbol:
    I'm using the "Change Symbol" property option for the symbol to change it to be the symbol that came with the specific USB port we're using.

    I realized the USB connector we currently chose (USB4125 GF-A) does not have D+ and D- pins, which we need if we want to use the device over USB boot. I've chosen a new part (DigiKey: USB4105-GF-A) and imported its symbol and footprint to rectify this.
    This imported symbol and footprint now look to be correct. Now, in order to align the new symbol with the schematic, I place the symbol, edit the schematic version of the symbol, then wire it in.
    The placed symbol
    The reorganized schematic local version of the symbol
    How to modify a symbol
    Schematic local symbol wired up
    Because USB-C does not mechanically distinguish between device and host, it must do so electrically. In our case, we're a device, and in order to assert that (and allow the host to provide us with power) We pull CC1 and CC2 down to ground using 5.1 kiloOhm resistors as described in the USB-C specification. In this case, we're advertising that we're a device that wants to accept up to 3A of 5V power on VBUS.
  • Because I've significantly disambiguated our pin usage on the microcontroller, we can further reduce our jumper usage in the schematic.
    Reduced number of jumpers in the schematic
    Removing solder jumpers
    And introducing jumpers based on populate/no-popuation 0 Ohm resistor options.
  • While the RP2350's inverted reset line (RUN) is normally internally pulled up, the same nRESET line for the I/O expanders is not so. So we will need to introduce our own pull-up resistors for this circuit.
  • The old chip RESET button labelling
    The new chip RESET button labelling and layout
    I'm putting down a JST XH 2.54/2.50 mm pitch connector here for SWD, since it's a nicer connector to use than just pin headers.
  • I also boxed out the schematic, like in the KiCAD v9 version of the file.
  • I then added in the symbol for the DIMM slot, but in this case, using it to map to the pin numbers of the edge connector, since we don't have an edge connector symbol associated with the footprint.

Entry 1: -----------------------------------------------------------------

Date: March 3, 2025

Start Time: 12:33 AM

Duration: 1.5 hours

The card PCB has some fairly involved routing, since it requires branching out all 16+8+20 bus signals inside of a fairly compact footprint. I'm getting started on that design by first importing all the PCB footprints that are necesary for all the boards. I'm importing this in a KiCAD v8 environment because of the course's usage of KiCAD v8. This will roughly be a rehash of the library work that Nathan did on the KiCAD v9 environment, but I will share my notes on the process.

  • For each part that was not in the KiCAD standard library, I went into the DigiKey Part listing, and downloaded the symbol and foorprint for that part, preferring the SnapMagic verion of the model as opposed to Ultra Librarian, as I've found SnapMagic to be of higher quality.

  • For each of these parts, I also imported and aligned the relevant 3D model by using KiCAD's footprint properties menu. Because we place our STEP files in the Library.pretty directory, we can use relative pathnames (in this case just the STEP filename) instead of the full path to the 3D model.

    Source: DigiKey
    Source: DigiKey
    Source: DigiKey
    Source: DigiKey
    Source: Raspberry Pi Reference KiCAD Project
    Source: Github
    Source: DigiKey

  • For the part "5017868090", which is the Molex flat flec connection, you can directly go onto the Molex website for the part and download the symbol and footprint data for KiCAD.

    However, for this symbol specifically, the file provided to me by Molex for the footprint was malformed.

    Manually inspecting the footprint file, we can see that Molex quoted "" without escaping, causing a syntax error.

    Just going in and replacing the """" with "" repaired the footprint file.

    I can now also include the 3D model as normal

  • Some fields (like the datasheet URL) display on the KiCAD footprint. You can enter the properies menu for a specific footprint to prevent the unwanted fields from showing and clogging up the viewport.

  • The RP2350 requires an inductor with a polarization marking, specifically, the AOTA-B201610S3R3-101-T. The ECAD symbols and footprints for this part are currently only available on LCSC/JLCPCB, which only provides symbols/footprints in the form of EasyEDA IDs.

    To import a part into KiCAD from EasyEDA:

    • Log into EasyEDA
    • Hit the "Library" Button on the left sidebar, this should bring up a library browser pop-up.
    • Enter the LCSC part #... a list of results should show up. Click on the appropriate result.
    • Click on the rendered symbol preview to load the symbol into EasyEDA
    • While viewing the symbol... File > Expore > EasyEDA, which will download a JSON-based EasyEDA symbol file.
    • Do the same with the rendered footprint in the library broser, which will produce a JSON-based EasyEDA footprint file.
    • These EasyEDA files can be directly imported into KiCAD via the Symbol and Footprint Editors, as KiCAD supports the EasyEDA JSON file format.
    The JLCPCB listing for the EasyEDA symbol and footprint
    The EasyEDA symbol as viewed imported into KiCAD
    The footprint as viewed on EasyEDA
    The symbol as viewed on EasyEDA
    Modified by adding a dot polarity indicator onto the symbol
    The EasyEDA footprint as viewed imported into KiCAD

    While I cannot find a 3D model for this inductor on JLC/LCSC, Mouser has a 3D model (but no ECAD), so I downloaded the STEP, and imported it into the footprint entry.

  • I imported the MCP23017T-E/SS (from DigiKey)
    MCP23017 3D model and footprint
    MCP23017 Symbol
  • And also the reverse-mounted AA3528SECKT/J309 (from DigiKey)
    Reverse-mounted LED 3D model and footprint
    Reverse-mounted LED symbol

I will need to backport the schematic changes we made from KiCAD v9 back to KiCAD v8. From what I understand this is a manual process, so I'm prepared to redraw many parts of the schematic.

=============== Week 7: =================

Entry 4: -----------------------------------------------------------------

Date: Feburary 28, 2025

Start Time: 1:35 AM

Duration: 2.0 hours

I have some extra time to work on defining the software side of things. We need waveform descriptions of our bus transactions such that we understand the specific timings and arbitration required between the different cards.

  • I realized that in order for the Front Panel to drive the data signals into order to deliver a JMP instruction, there needs to be some arbitration line that ensures that the front panel has control of the data bus.
  • For reference, the original Altair was able to circumvent this by routing the front panel signals straight into the 8080 CPU, behind the input and output buffers.
  • For this reason, I've decided to drop the SS (single-step) line, which I've realized won't be used with our hardware, and created a new custom line called PANEL. I've updated our front page description with this information.
  • I'm doing a read-through of the Intel 8080 Datasheet to understand the timings of memory reads and write, and thinking about how to try to adapt that to our bus sustem, which is slightly modified.

  • I've found that the timing information is very similar, but I've found it useful to transpose the 8080 datasheet's information into signals that I could more easily understand in the data bus perspective. I wrote up some wavedrom files with my understanding of the timing, and organized those wavedroms as embedded within a draw.io document.

    timing document
  • I think this document may be the first page of many. Writing these specifications down more formally should help with clarifying the software implementation.

Entry 3: -----------------------------------------------------------------

Date: Feburary 26, 2025

Start Time: 3:01 AM

Duration: 6.5 hours

Final PCB designs are due soon, so I'm coming into lab to finish up work on the schematic for the Card design. With the release of KiCad v9.0, we've upgraded the project to take advantage of embedded datasheet support, and are hoping some of the PCB routing improvements can help us.

  • I'm organizing and taking notes on the parts of the schematic that I have already. I'm using the line tool to box in parts of the schematic that are logically separate, to make everything more clear. Here I've boxed in each I/O expander into it's own organized unit.

    boxing in the expanders

  • Additionally, I'm also taking design notes (utilizing the Hardware design with RP2350 manual) on the schematic for implementation details that we shouldn't forget.

    • Because the card boards, in normal operation, are powered via the card edge connector, and not via the USB bus, it's probably a good idea to have a reverse protection diode somewhere near the USB VBUS regulation circuit. I've added a note to do further research into this later.

      The L3 inductor in the 1.1V voltage regulator section of the schematic actually must be polarized, and Raspberry Pi has worked with a manufacturer to create a custom inductor to account for sensitivities in the internal voltage regulator (This is the AOTA-B201610S3R3-101-T). KiCad does not currently seem to have a default way to specify inductor polarization on their inductor symbol, so I will need to import or create a custom symbol for this in the future.

    notes on vbus reg notes on 1.1v inductor

  • In order to better draw the dividing lines for the parts of the schematic that are directly linked to the RP2350B symbol, I modified the symbol of the RP2350B (the veresion in the schematic, not the library version) to spread out the pins (primarily the left side) to make it more evently spaced.

    full view

  • Seth mentioned the the debug experience he was having with embassy and probe-rs was spotty. I looked into the issue and part of it was the issue mention in this Github Issue on Embassy mentioning an issue in probe-rs where it only resets one of the two CPU cores. For tracking, here's the draft PR for probe-rs looking to fix this issue. Additionally, he noted that probe-rs doesn't pick up on certain debug behaviors of the RP2350B.

    Part of the reason we're using probe-rs is because we did not get OpenOCD to function with our build environment. I noted that the Raspberry Pi work on OpenOCD had not been upstreamed yet, so the stable versions of openOCD that we were testing against produced incorrect behavior against our chips. I need to get a working version of OpenOCD based on the sdk-2.0.0 branch of the Raspberry Pi OpenOCD fork.

  • I am working on building a version of the downstream OpenOCD version on Windows. OpenOCD has a README.Windows that mentions some tools that I can start with to try to perform the build. I've decided to go along the MSYS2 route, so I'm installing MSYS2 on my computer. I also followed the MSYS2 guide on adding the profiles to my Windows Terminal.
  • MSYS2 provides the pacman package manager, which I'm using to install build dependancies onto the MSYS2 root. I'm referring to the Espressif documentation on building OpenOCD for dependancies that I need, which include autoconf, automake, git, make,mingw-w64-i686-gcc,mingw-w64-i686-toolchain,mingw-w64-i686-libtool,mingw-w64-i686-pkg-config, andmingw-w64-cross-winpthreads-git.
  • I realized that the generated GNU Autotools ./configure script was failing to find the mingw-w64-i686-gcc target gcc, because I was running the UCRT64/MSYS2 shell, which loads the wrong environment. Swithing to the MINGW32/MSYS2 shell, the proper alternative of gcc is detected and used.

    I also added a MINGW32/MSYS2 profile to my Windows Terminal, by adding the following profile listing to my configuration:

    {
  "guid": "{9f11d647-922f-4d52-8d58-7deac692ec2b}",
  "name": "MINGW32 / MSYS2",
  "commandline": "C:/msys64/msys2_shell.cmd -defterm -here -no-start -mingw32",
  "startingDirectory": "C:/msys64/home/%USERNAME%",
  "icon": "C:/msys64/mingw32.ico",
  "font": 
  {
    "face": "Lucida Console",
    "size": 9
  }
}

  • For some reason, there's a build error trying to compile src/flash/nor/rp2040.c, because it uses uint as a type, which isn't recognized. After running sed -i -e 's/uint /unsigned int /g' ./src/flash/nor/rp2040.c on the repository to replace the type usage, the project now builds correctly.

  • The build is working to build a version of OpenOCD that supports no interfaces. OpenOCD configures build features via flags in the `./configure` script, which can be found when running `./configure --help`. Because on the Getting started with Raspberry Pi Pico-series manual, Raspberry Pi notes that RP chips can be debugged through a generic CMSIS-DAP interface, I've opted to enable the --enable-cmsis-dap configure flag and regenerate the Makefile.

  • The configuration failed, because the inclusion of CMSIS-DAP support requires the hidapi library.
  • Looking through the MSYS2 package listing, I found a good candidate: mingw-w64-hidapi. I then ran pacman -S mingw-w64-i686-hidapi to install the MINGW32 version of the package.
  • The configure script now passes, but running the Makefile fails, because sometime later, some parts of the CMSIS-DAP implementation try to reference libusb-1.0.h, which I have not provided. I will need to provide the libusb 1.0 DLLs and header files somehow
  • Unfortunately, while the MSYS2 base package for libusb exists (mingw-w64-libusb), there's no MINGW32 version of the package available.
  • I've also tried to include the library in the same way that the previous Espressif guide did, but for some reason the configure script does not pick up libusb, and it still does not build.
  • I've decided to package a MINGW32/MSYS2 package myself. I took a look at the existing MINGW64 package for libusb. Basically, it provides the following files:
    • /mingw64/bin/libusb-1.0.dll
    • /mingw64/include/libusb-1.0/libusb.h
    • /mingw64/lib/libusb-1.0.a
    • /mingw64/lib/libusb-1.0.dll.a
    • /mingw64/lib/pkgconfig/libusb-1.0.pc
    • /mingw64/share/licenses/libusb/COPYING
    Taking reference of this structure, I created a new archive based on the MINGw32 build of libusb 1.0.27, moving the files into an archive to fill out these files:
    • /mingw32/bin/libusb-1.0.dll
    • /mingw32/include/libusb-1.0/libusb.h
    • /mingw32/lib/libusb-1.0.a
    • /mingw32/lib/libusb-1.0.dll.a

    I then copied over the pkgconfig configuration from the MINGW64 package, and modified to reference MINGW32 paths, and placed it in /mingw32/lib/pkgconfig/libusb-1.0.pc. I also copied over the COPYING file as-is.

    Here's a link to my MINGW32/MSYS2 packaging of libusb-1.0.

  • OpenOCD now properly builds with CMSIS-DAP support and the new RP2350B support. I've shared the binary (which requires you to bundle the hidapi and libusb DLL files), and it works on his computer. We have a more battle-tested debug tool that also has written support by Raspberry Pi.

  • Nathan noted that instead of having all our schematics and PCBs in one KiCad Project, per submission guidelines, we needed to split each board out into a separate project. We decided that it would be best to have a single KiCad .lib file that all the projects could reference.

    I thought this would be a good time to part out some of the core connector choices we needed, so I found the following parts to add to the library:

    • 10145226-0241N13LF as a DDR4 DIMM slot, which I chose over 2308107-9 because of footprint availability, and 10145891-0320J13LF because the latter is a very hard to solder SMD part with 288 contacts.
    • 2171750001 as our USB-C connector, because it's very popular, and I'm not expecting too many issues from it, since it's a Molex part.

  • Additionally, I've decided to use the same schematic symbol for DDR4 DIMM connections between the edge card and the slot, but we lack a footprint in the edge card case. I found an edge card footprint online that I'm importing to use with the slot symbol.

  • I also took the liberty of selecting the slide switches and buttons we will use:

    • OS102011MS2QN1 as a slide switch because of its fairly hefty casing that extends through hole into the PCB, which makes be believe that it will be less likely to rip off of a PCB.
    • FSM103 as a tactile momentary switch, as it allows the attachment of caps onto the stem, allowing for aesthetic customization.

Entry 2: -----------------------------------------------------------------

Date: Feburary 24, 2025

Start Time: 1:04 PM

Duration: 1.0 hour

reel of picos
At my apartment, I found a reel of Raspberry Pi Picos that still had two spare boards on them. Seth is using the spare UART port on our current debug probe in order to receive debug messages, but it's inconvients to have only one probe to do this while having to test two devices (the stamps). I'm going to assemble and install an additional probe, such that we no longer need to fo the SWD wire switching, and can debug and receive messages from both stamps simultaneously.

  • I picked out a Pico board from the strip of the reel that I brought to lab.

    single pico
    I'm going to add header pins to this Pico such that I can be installed onto a breadboard.

  • I mounted the Pico with header pins onto a breadboard to provide alignment for soldering.

    unsoldered pico on breadboard

  • I tacked the 4 corners of the board with 4 connections each to make sure sthat the header pins were attached mechanically secure to the pico. I could now remove the Pico from the board, and complete the job on the helping hands.

    tacked pico on breadboard tacked pico removed

  • I mounted the Pico onto the helping hands, and finished soldering on the header pin rows to finish the electrical connection.

    tacked pico on helping hands header rows complete

  • I then removed the Pico from the helping hands and flipped it over to add the SWD header. I tacked solder onto the two ends of the header row to support it, and then finished the last pin.

    flipped over pico SWD tacked pico

  • Here is the assembled Pico with the header pins on it.

    assembled pico

  • Now it's time to wire the new Pico into the breadboard. The SWD signals on the bottom end of the breadboard will remain connected to the lower debug probe. I've disconnected the top SWD signals. These signals will be connected to the new Pico.

    removed signals

  • I've gone and removed the slide switches we used to switch the target board for the single debug probe, and directly connected the lower SWD signals to the lower debug probe.

    connected lower SWD signals

  • I then connected the upper >SWCLK to the new Pico's GPIO 2, and the upper SWDIO to the new Pico's GPIO 3, as specified in Appendix A of the Getting started with Raspberry Pi Pico-series manual.

    new pico mounted

  • I've now connected the gound and 3.3V out signals to the power columns on the breadboard, according to the Pico's pinout diagram.

    Raspberry Pi Pico-series manual.
    power columns connected
This should make deubgging smoother, since now we can connect both probes to a development computer, and program/test both stamps at the same time without needing to toggle switches back and forth.

Entry 1: -----------------------------------------------------------------

Date: February 22, 2025

Start Time: 3:38 PM

Duration: 8.0 hours

I'm working on completing and verifying all of the cable harnesses (ribbon cables) that we need for communication between two boards. Currently, a pair of cables is complete, each of which has 24 conductors. These represent the 16 address lines, plus the 8 data lines of the bus. Today, I'll try to verify that the circuit for these two 24 conductor cables in good, and also work on the 20 conductor cable, which connects the clock and bus control signals.

  • ribbon cables installed on breadboard

    First, I installed both ribbon cables to the breadboard setup using the notes I had taken yesterday, the carrier board diagram, and my schematic.

  • Next, I decided to probe for continuity using the benchtop multimeter, between the pad contacts directly on each Stamp XL. This tests that the connection between the GPIO pins that I'm interested in (GPIO24 thhrough GPIO47), is good.
    • To figure out which pins to test, I used the Stamp XL's leaflet diagram, and probed GPIOs 24-47.
    • Pins 24-29, which are on the bottom on the leaflet diagram, pass continuity
    • Pin 30 does not pass continuity. Pins 31-39 pass continuity. These pins are on the right side of the leaflet diagram.
    • Pins 40-47, which are on the top on the leaflet diagram, pass continuity

  • I will need to investigate which part is causing the connection between the Pin 30s to misbehave. This connection fault could be in the FlexyPin, the header pins, the crimp in the ribbon cable, the cable itself, or the breadboard. I'll eliminate these potential faults one-by-one.

    • I've eliminated the possibility of it being a FlexyPin issue by probing between the carrier board and the Stamp XL
    • I've eliminated the possibility of it being a header pin issue by probing between the Stamp XL, and a jumper cable connected to the suspected header pin
    • I've eliminated the possibility of it being a breadboard issue by moving the connections to a different part of the breadboard, and reprobing the entire bevy of pins.
    • the probing process

      I've found that the continuity issue is a fault with a cable. In particular the cable harness used on the left stamp carrier board. This was found by placing a spring probe on the breadboard side of the ribbon cable, and probing Pin 30 of the Stamp XL on the other side. While the right setup passes the continuity test, the left setup does not.

    • a broken crimp connection

      I've identified the specific fault, which is a broken connection on the ribbon cable's board side. I've gone and recrimped this connection.

    • Reassembling everything, all connections, GPIOs 24-47, pass continuity
  • I now need to assemble the 20 conductor harness for the clock and bus control signals

  • Similarly to the 24 conductor cable, I've also split them out to a board side and breadboard side. I've done so in the following arrangement.

    ribbon cable split out into multiple sections

    From top left to top right:

    • 10 (male) pin block (for CLK and 9 bus signals)
    • 10 (male) pin block (for 10 other bus signals)

    From bottom left to bottom right:

    • 2 (male) pin block (for GPIO 4-5, right hand side headers)
    • 4 (male) pin block (for GPIO 6-9, right hand side headers)
    • 2 (male) pin block (for GPIO 10-11, right hand side headers)
    • 8 (male) pin block (for GPIO 12-19, left hand side headers)
    • 1 (male) pin block (for GPIO 20, right hand side headers)
    • 1 (male) pin block (for GPIO 21, right hand side headers)
    • 1 (male) pin block (for GPIO 22, right hand side headers)
    • 1 (male) pin block (for GPIO 23, right hand side headers)

  • In assembling so many Dupont crimp connectors, I've learned some techniques to make the process smoother. Rounding out the cable hold using the round hole grippers at the end of this stripper makes the insertion of the crimp connector into its housing a lot easier.

    my technique for rounding out the wire holds

  • As a result, the newer ribbon cables I made look a lot cleaner than my older ones.

    an assembled 20 conductor ribbon cable

  • I've fully assembled the board with all the ribbon cables (2x 24 conductor cables, 2x 20 conductor cables)!

    the fully assembled breadboard with all ribbon cables

    I've also made sure that continuity passes between the two Stamp XLs for all GPIO pins from 4 to 47.

  • Now that this whole harness is done, there are no critical hardware blockers for software prototyping and testing. Software prototyping and continue at full speed now.

=============== Week 6: =================

Entry 6: -----------------------------------------------------------------

Date: February 21st, 2025

Start Time: 5:46 PM

Duration: 6.5 hours

What did you work on?

I'm hunkering down and working on crimping and wiring in the prototype wiring harnesses. These are required so that we can get on with testing the bus signal communication. I'm expecting this work to continue into tommorrow.

Additionally, on a meta note, I've reformatted my journal such that the entries are in the correct order, and have made some internal changes such that it's easier to make journal entires. Hopefully this process is smoother from here on out.

How did you work on it?

  • In the lab, there's this reel of ribbon cable that I plan to use. It's got the DigiKey Part Number 3M157956-10-ND
  • In particular, this reel was an AWG of 26, which is appropriate for crimping Dupont connectors, and has 40 conductors that I can split into smaller segments.
  • ribbon cable split out into multiple sections

    I've split out 24 conductors from the 40 conductor ribbon and have split it apart in the following arrangement.

    From top left to top right:

    • 8 (male) pin block (for A0-A7)
    • 8 (male) pin block (for A8-A15)
    • 8 (male) pin block (for D0-D7)

    From bottom left to bottom right:

    • 2 (male) pin block (for GPIO 24-25, right hand side headers)
    • 4 (male) pin block (for GPIO 26-29, left hand side headers)
    • 2 (male) pin block (for GPIO 30-31, right hand side headers)
    • 4 (male) pin block (for GPIO 32-35, right hand side headers, reverse)
    • 4 (female) pin block (for GPIO 36-39, bottom header block, top row)
    • 4 (female) pin block (for GPIO 40-43, bottom header block, bottom row)
    • 4 (male) pin block (for GPIO 44-47, left hand side headers)
  • The decisions that went into splitting up the cable like this were made based on the carrier board diagram, and my schematic diagram with bus labels.
  • Seth found a SN-28B crimper in the lab, so I no longer need to go to the ECE shop to crimp my connectors. I'm working on doing that right now.

What was the result and what did you learn from it?

I'm still continuing to work on this, but I've crimped up the data and address ribbon cables. I learned how to properly use a Dupont crimping tool from this tutorial.

How did this contribute to the project progress?

Since this project requires the prototyping of our bus interface, the ribbon cable is a good way to jump all those signals onto a breadboard that we can connect and probe. In that way, it contributes to the project that facilitating the prototyping process.

What are the next steps that must be taken?

  • I need to create the ribbon cable for the twenty (20) bus control signals.
  • I still need to find the schematic symbols and layout footprints for the connectors we need for the card PCB in KiCAD.

Entry 5: -----------------------------------------------------------------

Date: February 20th, 2025

Start Time: 2:49 AM

Duration: 0 hours

box of crimp connectors

I dropped off a box of Dupont crimp connectors that I had at my apartment. I went earlier to the ECE Shop, where they had an SN-28B ratcheting crimper that is compatible. I can't take that tool out of the ECE Shop however. The crimper on the table is not compatible.

These crimp connectors are necessary to put together the communication ribbon cables for prototyping, and I will be assembling the ribbon cables soon.

Entry 4: -----------------------------------------------------------------

Date: February 18th, 2025

Start Time: 2:58 AM

Duration: 2 hours

What did you work on?

Today, I brought my old ECE 362 breadboard in from my apartment, and will work on transferring the setup currently on the other breadboard to the new one.

How did you work on it?

  • breadboard with ECE 362 lab on it

    Here's the state of my breadboard before I did any work on it. It still has my ECE 362 lab work on it.

  • I removed all the components from this breadboard, organized the parts back into my Mini Kit, and set up new jumpers between all the power rails.
  • Then, at the top of the breadboard, I laid down foam tape and double-sided scotch tape to act as a mounting surface for the carrier boards.
  • Finally, I placed the carrier boards on the tape layers, and secured them with a couple tacks of hot glue near the mounting holes.
  • I then wired up the SWD setup that we had previously. I also included 2 slide switches to be able to switch the SWCLK and SWDIO signals between the two carrier boards, such that we can use one Pico debug probe to debug both stamps.

What was the result and what did you learn from it?

the newly assembled breadboard

Here's the newly assembled breadboard. I'm confident that the spring connectors in my own breadboard are a lot more reliable, so this should be more usable for prototyping and wiring all those signals.

How did this contribute to the project progress?

Now that we have a reliable breadboard, I won't second guess whether a jumper cable on the breadboard is actually making a good connection/circuit. With better peace of mind during prototyping, the rest of prototyping should be faster.

What are the next steps that must be taken?

  • I need to put together the ribbon cable wiring harness.
  • I need to also remember to get the connector symbols and footprints (DDR4 DIMM, JST, USB-C) we need to complete the card schematic and layout.
  • At the end of this session, I discovered that Raspberry Pi had announced today that RP2350A/B would be available for consignment at JLCPCB! I need to figure out how to consign these parts.

Entry 3: -----------------------------------------------------------------

Date: February 17th, 2025

Start Time: 11:22 PM

Duration: 2 hours

What did you work on?

I decided to continue work on my own, and investigate the issue with the carrier board with vertical pins.

How did you work on it?

  • side view of a carrier board, showing vertical-looking FlexyPins

    First, I verified that I had the right carrier board (the one with the issue). Yep, this is the one with the vertical-looking FlexyPins. Mounting stamps on this is difficult, and some pins don't make proper contact.

  • view of a board showing correct FlexyPins

    Here's what it looks like on the other carrier board, which I think is more correct. I also took the opportunity to modify the stamp so that it had 2 header pins on it, such that I could use normal jumper wires, instead of having to use the custom probing cables I made last time.

  • view of a carrier board with all of its FlexyPins removed

    I went ahead and desoldered each FlexyPin individually, so here is the board with all of the pins removed.

  • view of a Stamp XL directly soldered onto a carrier board

    I tried to reinstall FlexyPins that did not have this issue, but the solder from the previous job had filled the vias, and I couldn't effectively extract the solder from the holes. Therefore, I decided to solder this stamp directly to the carrier board using the castellated pad edges.

What was the result and what did you learn from it?

alternate view of the soldered carrier board

I tested the newly amended carrier board, and it now works against the Serial Wire Debug (SWD) setup. After some reworking of the other solder connections, I think the board is ready to use. I learned about a lot of desoldering techniques, and also other techniques to try to remove solder from vias, though the latter was ultimately unsuccessful.

How did this contribute to the project progress?

Now that the second carrier board is ready for action, we can now use both boards for prototyping, which is important, since so much of our project hinges on the communication between boards.

What are the next steps that must be taken?

  • I still need to get my own breadboard to the lab, because I still think the current breadboard we're trying to use isn't sufficiently reliable.
  • I need to set up the wiring harness between the boards, which I've decided will be done with a ribbon cable, and Dupont connectors.

Entry 2: -----------------------------------------------------------------

Date: February 17th, 2025

Start Time: 7:34 PM

Duration: 2.5 hours

What did you work on?

Seth asked me to come into lab today to help with an issue that he was having; namely, he was trying to get Serial Wire Debug (SWD) working on the stamps, such that each stamp could be programmed without needing to press the board's reset button, and also allow for setting breakpoints and line stepping debugging commands.

How did you work on it?

I did two main things:

  • Acting as a "rubber ducky" debugging assistant for Seth.
  • Did some hardware work to build out Seth's testing setup onto a breadboard; into something that could be further expanded into a larger prototype.

More specifically:

  • Seth explained that any Raspberry Pi Pico could be turned into an SWD debugging probe, by loading the debugprobe firmware onto it. This Pico probe can then be wired into the target board's SWD port, where it would supposedly "just work"
  • In particular, the instructions we were following were "Appendix A: Debugprobe" of the Getting Started with Raspberry Pi Pico-series manual
  • We tried to connect the bench oscilloscope to the SWCLK and SWDIO lines on the board, but when attemping to communicate with the board using both of the tools that we tried (the Raspberry Pi fork of openocd, and probe-rs), the probe was unable to communicate, and the oscilloscope signals remained steady.
  • I suspected that one potential issue with the setup was that the setup wasn't stable enough for SWD (the current test setup were two boards on the table, with two jumpers from the Pico jammed into the SWD holes on the carrier board. The reason we did not use a connector is because the carrier board only exposes SWD via a small JST connector, which we did not have on hand).
  • To try to rectify this, I tried to do two things:
    • two cables, which have clamping probes on one end, and male Dupont connectors on the other side

      I dug through the spare table box to find a pair of Dupont cables, and a pair of probes, which I then spliced together into a pair of single cables. Instead of jamming the male Duponts directly into the header vias, I instead used these new cables to to hook onto the FlexyPins, hopefully providing a more secure connection.

    • a prototype breadboard with two stamp carriers and a pico mounted on it

      I dug through the breadboard box, and found a breadboard, where I added foam tape as a base layer, double sided table on top of that, and added hot glue in small spots to attach each dev board into the breadboard, so we can move every dev board together all as one. Then, I replicated the debug circuit on this new setup.

    This new setup did not work either. We ran into the same no communication errors, and the same flatline on the oscilloscope as we did earlier.

  • After some more time debugging, and reading the Getting Started manual, Seth realized that we had been connecting the SWD of the Pico with the SWD of the stamp, where in reality on a closer reading, we should be connecting GP2 and GP3. Upon some fiddling, the debugger started to work, and we could flash programs via SWD.

What was the result and what did you learn from it?

We got Serial Wire Debug (SWD) working by using a Raspberry Pi Pico as a debug probe, and were able to program a Stamp XL using it. I learned about specifics of SWD, debugging with a "Pico Probe", and to pay attention to the manual.

How did this contribute to the project progress?

By getting SWD working, we can more quickly iterate on programs for the RP2350, because we don't need to reach over and press the reset button to program each Stamp. This also allows for us to program in automated testing suites.

What are the next steps that must be taken?

  • I'd like to bring over my own breadboard from ECE 362 to replace this breadboard, since the contacts appear to have been worn out (continuity did not pass on certain lines on the breadboard, so we had to switch to different parts of it)
  • I'd like to set up a wiring harness between the two breadboards, so that the two Stamp XLs can directly communicate.
  • I still need to investigate the issue with the vertical looking pins on one of the stamp carriers. When testing som of its pins of continuity, they did not pass. So, we could not use this carrier for SWD, and had to use the other one.

Entry 1: -----------------------------------------------------------------

Date: February 15th, 2025

Start Time: 12:00 AM

Duration: 4.5 hours

What did you work on?

Two of our RP2350B Stamp XLs and their respective carrier boards arrived yesterday, but they're not assembled. The header pins, and mounting method are not soldered on. I will be working on putting these boards together, since they're crucial for communication bus prototyping.

How did you work on it?

In addition to the stamps and their carrier boards, we also ordered two (2) bags of one hundred (100) FlexyPins, which should allow us to place or remove the stamps on the board. Seth was also in the lab that day, so I worked with him to install the FlexyPins onto the board, which need to be inserted one-by-one.

I then went ahead and soldered down the FlexyPins for each carrier board. Then the "Arduino Mega" style female pin headers, then the extra pin headers, then the DC barrel plug. Nathan was also there, and he helped to solder the header pins on one of the boards.

Finally, I did a test fit of the Stamp XL boards on their carrier boards.

What was the result and what did you learn from it?

two assembled stamp carrier boards with stamp XLs on them

The two boards are fully assembled!

One of the stamp carriers had a greater angle to its FlexyPins, while the other's FlexyPins appeared to stand straight up. For the one with the pins that appeared to have an angle (about 45 degrees), the Stamp XL fit easily and snugly in the carrier. It was more difficult to attach the Stamp XL to the other carrier board.

How did this contribute to the project progress?

Because the Stamp XLs are the only dev boards that expose all 48 GPIO pins on the RP2350B, being able to use them is crucial if we want to be able to create a prototype of our (fairly wide bus). Putting the dev boards (carrier boards) together is another step towards that.

What are the next steps that must be taken?

  • We need to put these boards together into a development setup, such that their GPIO pins are connected together so they can communicate.
  • I'd like to check up the carrier board that has the vertical-ish pins, to see if there are any continuity issues.

=============== Week 5: =================

Entry 6: -----------------------------------------------------------------

Date: February 14th, 2025

Start Time: 7:32 PM

Duration: 4 hours

  • our RP2350 Stamp XLs and Stamp carrier boards arrived! they look to all be in good condition
  • working on transposing my journal from Discord over to the team website
  • i talked a bit with seth, and we agreed that to reduce the amount of time that journals take to transpose (hours sometimes), we want to switch over to using Notion for our journals.
  • this journal transition will happen next week
  • i am also iterating through the more specific PSDR descriptions. I'm following the recommendation to create a PSDR for each card implementation.
  • please refer to the team website for the PSDR changes

==== Mini-summary ====

What did you work on?

I worked on transposing my journal from Discord over to the journal website. I also started writing functional descriptions for our boards (to be used in PSDRs).

How did you work on it?

I mostly copy over my Discord notes with their relevant timestamps, and then add/modify an additional mini summary of what happened in that entry to be more clear.

What was the result and what did you learn from it?

That this journal transposing process takes way too long, we need to find some other way of publishing project journals.

How did this contribute to the project progress?

Now that my journals are up on the website, me and my team can now reference them on the site, instead of having to go to the Discord server.

What are the next steps that must be taken?

Seth and I came up with a plan to transition all of our team journals over to Notion, this plan will be enacted during next week, where we'll migrate all of our journals.

Quick Remark: -----------------------------------------------------------------

Date: February 13th, 2025

9:50 AM

remark: ugh the pullup resistors for the two different MCP23017's nReset are duped

they're different nets but they could be the same one

Entry 5: -----------------------------------------------------------------

Date: February 12th, 2025

Start Time: 10:14 AM (during ManLab)

Duration: 1 hour

hi, good morning

  • after some discussion in ManLab, looks like we should get all of our PSDR ducks in a row.
  • since i'm the one who is most familiar with our design requirements, i'll start to work on iterating the different design requirements of our system
  • hopefully we can pluck out some descriptions to use as better and more complete PSDRs

here's some of my notes about what i think is some functionality not currently described in PSDRs we can use.

  • this computer is something that requires a lot of different boards to talk to each other
  • we want design 3 boards: the front panel, the backplane, and the generic card
  • the backplane is responsible for converting some unregulated voltage source into 3.3V power, which can then be distributed to the rest of the system
  • let's lock this in, let's take 5V 3A power from a USB-C port on the back of the backplane board, which we then need to distribute throughout the backplane
  • remark: we may need multiple voltage regulator blocks throughout the backplane, because of the distance that power and signals will need to traverse (we'd like to step 5V to 3.3V as close to the module connector as possible, but this is mutually exclusive from having multiple module connectors. the solution? multiple voltage regulators across the backplane)

our bus is inspired by the Altair 8800's original 8080-based bus, but with some changes for ease of implementation

on the bus, we map:

  • 8 data signals DATA{0-7}
  • 16 address signals ADDR{00-15}
  • 36 bus control signals BUS{00-25} (bus control signals {04-07, 20-23} are always mapped to the same PIOs, the others can be swapped depending on the use case) remark: elaborate
  • 32 non-real time signals (16 managed by 1 I/O expander, 16 managed by another I/O expander)

there's a couple of non-trivial interfaces that we care about:

  • since we have so many UI elements (more than 20 switches and LEDs each), the front panel should use expanders to address LEDs, and matrices to detect switch presses.
  • the front panel must be able to throw the correct instruction onto the bus in sequence to both jump and modify the 8080 CPU's program counter
  • the front panel must be able to perform both glitchless clock activation/deactivation, and be able to assert signals for single-stepping mode. the CPU and memory boards must be able to understand these signals
  • when the CPU talks to memory, the CPU must be able to understand memory ready, I/O ready, and memory WAIT signals with memory strobes to allow for I/O operations to complete
10:23 AM

remark, i did mention to the course staff about possible supply issues with the RP2350B chips. we may need to consider a backup plan

writing down here that setsuna did recommend possibly using multiple time steps of some lines to assert bus control signals, essentially serializing the bus control, something we can do with the RP2040's pin count.

if it comes to that, that's an avenue we can pursue, since ripping chips off of evaluation boards in undesireable.

10:01 AM

Logical connections (for PSDRs):

  • CPU <-> RAM (memory strobe messages, memory ready messages, memory WAIT messages)
  • Panel <-> CPU (assert bus control [via interrupt acknowledge message], set jmp instruction, set program counter)
  • Panel <-> CPU (drive clock signal, receive clock signal, receive single-step mode, drive single-step mode)
  • Panel <-> LEDs (LEDs driven via I/O expansion [I2C])
  • Panel <-> Switches (Switches polled via matrix)

these can all be validated regardless of if the other feature works

I ended up talking to Dr. Walter, and he made a very good point about the fact that we are basically designing 3 different boards.

if we create detailed enough functional specifications for each board, then they could all constitute a PSDR. I will work on this.

==== Mini-summary ====

What did you work on?

I worked on coming up with ideas for our PSDRs, and also coming up with an initial backup plan for if RP2350 supply doesn't work out.

How did you work on it?

I talked with course staff (primarily Setsuna, and Dr. Walter) about what changes we should make to our PSDRs, and ideas of what to do if we only have RP2040s available.

What was the result and what did you learn from it?

I think we have a stronger plan of what to do for the PSDR changes, and a good idea for our backup plan.

How did this contribute to the project progress?

Our PSDRs need to be revamped, since they're too simple right now. I've taken charge of rewriting them, and this is a good brainstorming session towards that.

What are the next steps that must be taken?

I need to formalize our PSDRs and write detailed functional descriptions of each of our cards that we can use as PSDRs.

Entry 4: -----------------------------------------------------------------

Date: February 12th, 2025

Start Time: 5:00 AM

Duration: 4.5 hours

good morning

going to start laying out the RP2350 (card DIMM board schematic), based on the info from previous sessions

i'm most interested in seeing how this validates my priors, and also this should pave the way to PCB design, where we can validate the height of the DIMM

5:30 AM
schematic symbol of RP2350B
  • rp2350 QFN 80 is not in the base kicad std lib
  • imported the symbol from the reference design
5:52 AM

on the topic of decoupling:

decoupling capacitor schematic
  • section 2.2.1 of the hardware design guide recommends 11 100 nF decoupling caps for each VDD
  • they say 53,54 and 68,69 can be doubled up to use the same cap in case of space constraints on single sided population boards, so i've done that
  • i've also added a 10 uF bulk cap to the schematic (not in guidance) to be place close, but slightly farther away from the chip
  • we do not use the ADC so i will not be making specific consideration to a filtered power plane a la 3V3A filtered w/ ferrite bead etc.
6:09 AM

misc internal voltage regulation design (referenced)

vreg support discretes schematic
6:40 AM
vreg support discretes schematic

misc wiring for the W25Q128JVS QSPI chip

the reference board allows for 2 QSPI chips, with the chip select determined by GPIO0

we dont need this, so while reference has a lot of optionality w/ DNF (do not fit) jumpers, this design can be simpler is this case

6:57 AM

external oscillator (referenced)

external oscillator schematic
7:16 AM
usb-c spec screenshot

USB C CC line passive Rd resistor specification (see 4.5.1.2.1 on usb-c specification

usb connector schematic

USB CC 5.1k pulldown (NOTE: do not short CCs prior to pulldown! was an issue on rpi4 launch to great publicity)

8:18 AM
gpio jumpers schematic
  • working on GPIO mapping
  • 4 pins can jumper to either exposed signals (2 I2C buses, or 1 I2C bus and 1 UART tx/rx), or straight to bus
  • 12 other pins can be configured between bus lines
8:33 AM
schematic overview

initial schematic without external connectors

things to review:

  • check NCP1117 handling in the case where the 3V3 side isnt passive (situation where USB is plugged in while entire device is under external [other] power source..)
  • check edge board substrate thickness, pitch, etc.... is it easy to route? can we fit the jumper vias with the current pitch? swap from DDR4?
  • find proper JST connector for GPIO pins 0-3

remarks:

  • check errata... do we need bias on GPIO40-GPIO47 due to weak/faulty internal tri-state?
  • reel supply of RP2350A/B not reliable, look for options
  • 4.7u guidance assumes pin 32 is far away from voltage regulation... check this assertion later
  • consider making the 12 latter jumpers have copper trace defaults
  • cutting/scoring as an exception may be less annoying than jumping always
9:14 AM
  • digi key doesnt have footprint for the ZTE connector we were looking at
  • might switch over to this connector b/c i really really cannot find these symbols and footprints
9:22 AM
  • DIMMs have a weird outline (for insertion/rocking reasons, whatever), but will need to create the outline for this
  • likely easier to make a sketch in a CAD tool and import the generated DXF solve into KiCAD for the final board outline later
  • remark: i thought there would ne 288 available signals on a DIMM, but it seems only 77 are available? i guess some are doubled up
  • i've done the schematic generously (36 bus signals, 32 extended signals, 16 address signals, 8 data signals, totaling 92 signals). this might be too much for the current connector choice
  • i really like DIMMs because they're locking connectors, if this isnt possible we'll need to find another locking connector form factor
9:32 AM
  • yeah like... i cant find documentation supporting the "77 pins" idea
  • maybe the symbol is just weird?
  • remark: i need to find a symbol from another DDR4 DIMM connector to compare. maybe molex's makes more sense

i'm really happy with the work i've done so far with the schematic.

in terms of further work on this, i need to connect all the I/O nets to the appropriate edge board connector (i may need to make a custom symbol for this)

i also need to figure out parts for our other connectors like the USB-C connector and the JST connector for our UART functionality

==== Mini-summary ====

What did you work on?

I made a good first pass on the schematic, setting up all the decoupling caps, the voltage regulator support circuits, the QSPI flash, the I/O expanders, the USB-C port, the development voltage regulator, and followed all their design requirements.

How did you work on it?

For working on the RP2350B, I referenced the Hardware design with RP2350 manual, and the RP2350 datasheet. I also heavily referenced the reference KiCAD design.

For setting up the pull-down CC lines on the USB port, I referenced the USB-C specification.

For writing up of the MCP23017 I/O expanders, I referenced its datasheet.

What was the result and what did you learn from it?

The core of the schematic is done! I learned a lot about the specifics of designing with the RP2350B, since I've only designed boards for the STM32F0 series previously.

How did this contribute to the project progress?

This is a big step to getting the schematic completely finished! A good stepping stone to that juicy PCB layout.

What are the next steps that must be taken?

I need to recheck all the remarks I made, the voltage regulators handling if the other side isn't passive, recheck edge board constraints, find proper connectors (for UART), check the GPIO40-47 errata, check the chip supply, check the 4.7u capacitor placement guidance, try making the solder jumpers have defaults. I also need to add connectors to the schematic, and I may need to make a custom symbol for our edge connector.

Entry 3: -----------------------------------------------------------------

Date: February 10th, 2025

Start Time: 4:30 PM

Duration: 1.5 hours

hi all, good evening

im working on a schematic for our Card Board

this is because i want to confirm my priors that we actually have all of the parts/pins we need

this should also allow us to make a PCB layout, which can help confirm sizing (height) of the DIMMs

i dont want us to commit to buying an enclosure if it wouldnt be able to fit the height of our DIMMs.

5:09 PM
sketch of a DDR4 DIMM
  • ABM8-272-T3 (reference oscillator) and W25Q128JVS (reference QSPI flash) are chosen
screenshot of GPIO function table
  • GPIO pins 0 and 1 are reserved for board specific functionality
  • (above screenshot from Table 3 (Section 1.2.3) of the RP2350 datasheet)
  • notionally, if an MCP23017 (I2C) is populated on the board, then the 16 I/O expander signals on the board are active
  • otherwise if a JST connector is populated, those two pins are connected to the JST connector
  • this can determine of a board will use those pins for additional lanes (F3 on 0 and 1), or as a UART transceiver (F2 on 0 and 1)
  • providing this flexibility will reduce the total number of boards that will need to be designed
  • we are intending on keeping this number at 3 (front, backplane, card)
5:23 PM
  • according to JEDEC MO-309E, the nominal board thickness is 1.2 milimeters. it also has a bevy of other details about the board outline. i'll use this when setting up the board outline during PCB layout
  • for convenience, I've obtained a copy of the standard using my JEDEC account, and shared it with my team members
5:41 PM
  • for the 22 other pins im consider routing 20 of them into vias
  • where you can either jumper them to the front or rear contact of the board
  • and for the last 2 pins to also have the design optionality to jumper those two into a 2nd I/O expander for... reasons (let's call it prototype flexibility)
  • shouldnt be an issue with signalling but ill need to do some minimal modelling at least
5:56 PM
  • remark: how mountable are ddr4 dimm connectors?
  • would choosing a connector with a higher pitch be nicer? we dont need 200+ connections

did some research on the part selection and some other additional design decisions id need for the schematic. next step is to actually start putting the art down

==== Mini-summary ====

What did you work on?

I made a sketch to get a rough idea of what size and layout I want the card PCB DIMM to have. I made some part selections for our schematic, based on the RP2350B's reference hardware design. Additionally, I also made some design decisions, such as including solder jumpers, and allowing for a second I/O expander to be populated, to increase our I/O flexibility, and allow for the same board design to be used for different purposes.

How did you work on it?

I referenced the Hardware design with RP2350 manual, the RP2350 datasheet itself, and JEDEC MO-309E for details on DDR4 DIMMs.

What was the result and what did you learn from it?

I finalized some additional design decisions related to part selection and solder jumpers, and learned about some specifics to hardware design with the RP2350B, since I've only designed boards for the STM32F0 series previously.

How did this contribute to the project progress?

With this done, I pretty much have all the information I need to start laying out the schematic uninterrupted.

What are the next steps that must be taken?

The very next step? Work on the schematic! finally! and i would love to get the PCB layout, and at least some of the routing done soon.

Entry 2: -----------------------------------------------------------------

Date: February 10th, 2025

Start Time: 1:39 PM

Duration: 0.5 hours

hi all, good afternoon

real quickly going to finish mapping out the pin allocations based on the work already done

since we'd like to get the card schematics etc. done as soon as we can, i need to finish this mapping as soon as possible

i'm laying out the final strategy ill be using to determine the pin count: 16 address pins, 8 data pins, up to 20 pins for timing critical bus control, and 4 pins for SPI control of a MCP23S17 I/O expander for U/I and non timing critical pins

1:58 PM
  • switch to MCP23017 for SCL/SDA 2 pin
  • A0-A15 (16 pins)
  • D0-D7 (8 pins)
  • XRDY (memory ready) (1 pin)
  • PWAIT (mem/IO wait) (1 pin)
  • PRDY (IO ready) (1 pin)
  • PINTE (interrupt enable) (1 pin)
  • ~PINT (interrupt request) (1 pin)
  • SINTA (interrupt acknowledge) (1 pin)
  • ~CLOCK (bus clock) (1 pin)
  • ~PRESET (reset) (1 pin)
  • ~PHOLD ("hold" bus control) (1 pin)
  • UNPROT (memory protection unprotect) (1 pin)
  • SM1 (first machine cycle of instruction flag) (1 pin)
  • SOUT (ouput IO cycle) (1 pin)
  • SINP (input IO cycle) (1 pin)
  • SMEMR (memory read strobe) (1 pin)
  • SHLTA (halt) (1 pin)
  • MWRT (memory write strobe) (1 pin)
  • ~PWR (write strobe) (1 pin)
  • PDBIN (data bus in) (1 pin)
  • SWO (write-out) (1 pin)
  • SSTACK (stack operation) (1 pin)
  • ~POC (clear state) (1 pin)

(I/O expander)

  • SCL (1 pin)
  • SDA (1 pin)

this looks good. at least, it's flexible enough that i think we have the means to go forward.

looks like I can start to work on schematic and layout soon.

==== Mini-summary ====

What did you work on?

I finalized work on our initial pin mappings (what specific function we assign to each of the RP2350's 48 GPIO pins).

How did you work on it?

I cross-referenced against older notes I made, and continued to make use of the 8800's Theory of Operation Manual.

What was the result and what did you learn from it?

All of our initial pin mappings are done, and now I have a clearer idea about which processor status lines are critical for real time operation, and which status lines are really only useful for the front panel.

How did this contribute to the project progress?

Now that the pin mapping are done, I can go forward and set up the schematic for the card, which is the hardware design that I'd like to start with. Making the schematic for the card will also help with the schematics of the front panel board, which also needs a RP2350B chip.

What are the next steps that must be taken?

The very next step is to work on the schematic and PCB layout for the card board

Entry 1: -----------------------------------------------------------------

Date: February 8th, 2025

Start Time: 5:30 PM

Duration: 1.5 hours

hi all, good evening

just checking in for a short bit...

i'd like to get some additional work done on the pin mapping, for which pins we'd actually want taking up PIO pins

6:26 PM
  • i went ahread and dropped all of the VI (vectored interrupt) lines
  • it wasn't entirely clear to me whether these lines are ever actually used by the CPU in the original Altair
  • cross referencing the original Theory of Operation Manual, I genuinely cannot find any mention of VI0 through VI7 in any of the schematics, so I can only assume that it's the role of some sort of programmable interrupt controller like the 8259A series
6:49 PM
  • remark: the 8259A is mentioned in the Manual for MCS-80/MCS-85, which, from what I understand was a new branding scheme that intel used to group all their existing microcomputer component portfolios together.
  • the MCS-80 descriptions on that manual are genuinely quite useful for timing/bus information, and may serve as a good future reference.

goodbye all, going to set finish some final bus pin research work next time, and then i can go forward on getting a bus layout done.

==== Mini-summary ====

What did you work on?

I did additional research on the pins that we need for the bus.

How did you work on it?

I consulted with the Altair 8800's Theory of Operation Manual and the intel Manual for MCS-80/MCS-85.

What was the result and what did you learn from it?

We made some additional changes (like dropping the VI lines), and I learned about the role of the 8259 in a more general MCS-80 system.

How did this contribute to the project progress?

In order to progress on creating the schematic for any of the boards, we need to get our communication bus defined. This pin research helps finalize some of that.

What are the next steps that must be taken?

We need to finish up the initial bus pin mapping, such that we can get to the schematic, and eventually PCB design.

=============== Week 4: =================

Entry 1: -----------------------------------------------------------------

Date: February 7th, 2025

Start Time: 11:00 PM

Duration: 1 hour

  • Due to travel to IEEE ICSC 2025 starting on February 2nd to today at 10 PM, I did not have time to work on the lab project, as I was preoccupied with the conference
  • Checked with team on the specific things worked on this week. Specifically interested in the hardware work with getting the Pico flashed

=============== Week 3: =================

Entry 6: -----------------------------------------------------------------

Date: January 31st, 2025

Start Time: 10:16 AM

Duration: 0.5 hours

  • Checked with a TA to see the status of our stamp XL orders
  • Realized that we did not order the other two stamp XLs+carrier boards + flexypins
  • new ticket link here
  • Total for the additional parts 61.52 Euros

Entry 5: -----------------------------------------------------------------

Date: January 29th, 2025

Start Time: 9:56 AM

Duration: 4 hours

  • going to also mark whether a board requires a signal or not
  • (this is mostly just for the sake of the front panel, I/O expander i realized we definitely need for UI I/O)
  • also while looking into the front panel schematic, I realized that the front panel did not have input lines to the address bus pins
  • instead, the altair panel dynamicall forces the 8080 to JMP to the correct pins
  • relevant stackexchange article

Continued work on pinmap, required for "tram" (our bus library)

  • P: processor command/control signal
  • S: processor status signal
  • ~: active low
Original Pin Name Action 8080 Pin CPU? RAM? UI? PIO? Note
I/O Expander NEW 2
1 +8v +8 volts DROP 3.3V unified
2 +16V +6 volts DROP 3.3V unified
3 XRDY External Ready KEEP 23 READY 1 Memory RDY
4 VI0 Vectored Interrupt Line #0 KEEP 14 INT 1/8 OR logic to 14
5 VI1 Vectored Interrupt Line #1 KEEP 14 INT 1/8 OR logic to 14
6 VI2 Vectored Interrupt Line #2 KEEP 14 INT 1/8 OR logic to 14
7 VI3 Vectored Interrupt Line #3 KEEP 14 INT 1/8 OR logic to 14
8 VI4 Vectored Interrupt Line #4 KEEP 14 INT 1/8 OR logic to 14
9 VI5 Vectored Interrupt Line #5 KEEP 14 INT 1/8 OR logic to 14
10 VI6 Vectored Interrupt Line #6 KEEP 14 INT 1/8 OR logic to 14
11 VI7 Vectored Interrupt Line #7 KEEP 14 INT 1/8 OR logic to 14
...
18 ~STA DSB ~STATUS DISABLE DROP? Multi-master
19 ~C/C DSB ~COMMAND/CONTROL DISABLE DROP? Multi-master
20 UNPROT UNPROTECT KEEP
21 SS SINGLE STEP KEEP I/_
22 ~ADD DSB ~ADDRESS DISABLE DROP? Multi-master
23 ~DO DSB ~DATA OUT DISABLE DROP? Multi-master
24 Φ2 Phase 2 Clock DROP 15 Φ2 Not NMOS
25 Φ1 Phase 1 Clock DROP 22 Φ1 Not NMOS
26 PHLDA Hold Acknowledge KEEP 21 HLDA _/O 1
27 PWAIT WAIT KEEP 24 WAIT _/O 1
28 PINTE INTERRUPT ENABLE KEEP 16 INTE _/O 1
29 A5 Address Line #5 KEEP 31 A5 _/O 1 UI Passive
29 A4 Address Line #4 KEEP 30 A4 _/O 1 UI Passive
31 A3 Address Line #3 KEEP 29 A3 _/O 1 UI Passive
32 A15 Address Line #15 KEEP 36 A15 _/O 1 UI Passive
33 A12 Address Line #12 KEEP 37 A12 _/O 1 UI Passive
34 A9 Address Line #9 KEEP 35 A9 _/O 1 UI Passive
35 DO1 Data Out Line #1 KEEP 9 D1 I/O 1 Bi-directional
36 DO0 Data Out Line #0 KEEP 10 D0 I/O 1 Bi-directional
37 A10 Address Line #10 KEEP 1 D10 _/O 1 UI Passive
38 DO4 Data Out Line #4 KEEP 3 D4 I/O 1 Bi-directional
39 DO5 Data Out Line #5 KEEP 4 D5 I/O 1 Bi-directional
40 DO6 Data Out Line #6 KEEP 5 D6 I/O 1 Bi-directional
41 DI2 Data In Line #2 DROP 8 D2 Force tri-state
42 DI3 Data In Line #3 DROP 7 D3 Force tri-state
43 DI7 Data In Line #7 DROP 6 D7 Force tri-state
44 SM1 M1 _/O
45 SOUT OUT _/O
46 SINP INP _/O
47 SMEMR MEMR _/O
48 SHLTA HLTA _/O
49 ~CLOCK ~CLOCK KEEP 1 Alternate clock
50 GND GROUND KEEP 2 GND
51 +8V +8 volts DROP
52 -16V -16 volts DROP
53 ~SSW DSB ~SENSE SWITCH DISABLE I/_
54 ~EXT CLR ~EXTERNAL CLEAR
...
68 MWRT MEMORY WRITE I/_
69 ~PS ~PROTECT STATUS _/O
70 PROT PROTECT
71 RUN RUN I/_
72 PRDY READY KEEP 23 READY I/_ 1 I/O RDY
73 ~PINT ~INTERRUPT REQUEST KEEP TODO, Check electrical config with VI lines
74 ~PHOLD ~HOLD KEEP 13 HOLD 1
75 ~PRESET ~RESET KEEP 12 RESET 1
76 PSYNC SYNC DROP 19 SYNC 1 No dual phase
77 ~PWR ~WRITE KEEP 18 ~WR 1
78 PDBIN DATA BUS IN KEEP 17 DBIN 1
79 A0 Address Line #0 KEEP 25 A0 _/O 1 UI Passive
80 A1 Address Line #1 KEEP 26 A1 _/O 1 UI Passive
81 A2 Address Line #2 KEEP 27 A2 _/O 1 UI Passive
82 A6 Address Line #6 KEEP 32 A6 _/O 1 UI Passive
83 A7 Address Line #7 KEEP 33 A7 _/O 1 UI Passive
84 A8 Address Line #8 KEEP 34 A8 _/O 1 UI Passive
85 A13 Address Line #13 KEEP 38 A13 _/O 1 UI Passive
86 A14 Address Line #14 KEEP 39 A14 _/O 1 UI Passive
87 A11 Address Line #11 KEEP 40 A11 _/O 1 UI Passive
88 DO2 Data out Line #2 KEEP 8 D2 I/O 1 Bi-directional
89 DO3 Data out Line #3 KEEP 7 D3 I/O 1 Bi-directional
90 DO7 Data out Line #7 KEEP 6 D7 I/O 1 Bi-directional
91 DI4 Data In Line #4 DROP 3 D3 Force tri-state
92 DI5 Data In Line #5 DROP 4 D5 Force tri-state
93 DI6 Data In Line #6 DROP 5 D6 Force tri-state
94 DI1 Data In Line #1 DROP 9 D1 Force tri-state
95 DI0 Data In Line #0 DROP 10 D0 Force tri-state
96 SINTA INTA KEEP _/O
97 SWO WO KEEP _/O
98 SSTACK STACK KEEP _/O
99 ~POC Power-On Clear KEEP
100 GND GROUND KEEP 2 GND

Entry 4: -----------------------------------------------------------------

Date: January 28nd, 2025

Start Time: 3:02 PM

Duration: 2 hours

  • Setsuna recommended looking into tri-state buffers or GPIO expanders to offload the functionality of certain pins
  • Maybe can fulfill some 8212 logic? Or add back multimaster support
  • GPIO expanders might be useful for less time critical signals... check those (RESET?? certain S lines? P lines?)
  • MCP23017/MCP23S17 for I2C line config?
  • I think most front panel signals have the fewest issues with this
  • Just need to make sure that those lines will not be used by e.g. memory
  • Remark: Need to figure out the bus timing information + reset control timing information (this will also be useful during A3, we need a state machine diagram for different parts of the timing cycle [each different piece of software])
  • Alternative, use the SPI flavor, and use two of these to free up address/data lines
  • Notably... 10 MHz 1-bit SPI cannot keep up with 2 MHz 16-bit parallel bus I don't think... timing information investigation should help determine good fit

Entry 3: -----------------------------------------------------------------

Date: January 27nd, 2025

Start Time: 9:05 PM

Duration: 0.5 hours

  • Notes for Wednesday: Figure out the last features to cut (protection lines?) then set up notional 2350B package pin mappings (we want some sort of remaining serial support + USB for programming... are we at a limit?)
  • Two options: Drop more lines, explore physical jumper setting of modes, or delegate some derived signals to external circuitry
  • Random musing: WordStar I think has a version that ran on CP/M before getting DOS support
  • Might be worth seeing, if we ever get CP/M running, if WordStar would be executable

Entry 2: -----------------------------------------------------------------

Date: January 27nd, 2025

Start Time: 3:03 PM

Duration: 3 hours

Big fan on how MITS defines 8 separate "Vectored Interrupt Control Lines" and then proceeds to OR them all together into the 8080's one interrupt control pin

Remark: The real vectored interrupt priority was the DIP switches we put on the peripherals along the way

I've been putting together a table of "Altair bus" pins referenced from the Theory of Operation Manual

Cross referenced signals against the 8080 Chip's pinout

Current state of the document:

                    - `P`: processor command/control signal
                    - `S`: processor status signal
                    - `~`: active low
                    ```
                    | Original Pin   | Name                       | Action    | 8080 Pin | PIO? | Note
                    |----------------|----------------------------|-----------|----------|------|
                    | 1   +8v        | +8 volts                   | DROP      |          |      | 3.3V unified
                    | 2   +16V       | +6 volts                   | DROP      |          |      | 3.3V unified
                    | 3   XRDY       | External Ready             | KEEP      | 23 READY | 1    | Memory RDY
                    | 4   VI0        | Vectored Interrupt Line #0 | KEEP      | 14 INT   | 1/8  | OR logic to 14
                    | 5   VI1        | Vectored Interrupt Line #1 | KEEP      | 14 INT   | 1/8  | OR logic to 14
                    | 6   VI2        | Vectored Interrupt Line #2 | KEEP      | 14 INT   | 1/8  | OR logic to 14
                    | 7   VI3        | Vectored Interrupt Line #3 | KEEP      | 14 INT   | 1/8  | OR logic to 14
                    | 8   VI4        | Vectored Interrupt Line #4 | KEEP      | 14 INT   | 1/8  | OR logic to 14
                    | 9   VI5        | Vectored Interrupt Line #5 | KEEP      | 14 INT   | 1/8  | OR logic to 14
                    | 10  VI6        | Vectored Interrupt Line #6 | KEEP      | 14 INT   | 1/8  | OR logic to 14
                    | 11  VI7        | Vectored Interrupt Line #7 | KEEP      | 14 INT   | 1/8  | OR logic to 14
                    | ...            |                            |           |          |      |
                    | 18  ~STA DSB   | ~STATUS DISABLE            | DROP?     |          |      | Multi-master
                    | 19  ~C/C DSB   | ~COMMAND/CONTROL DISABLE   | DROP?     |          |      | Multi-master
                    | 20  UNPROT     | UNPROTECT                  | KEEP
                    | 21  SS         | SINGLE STEP                | KEEP
                    | 22  ~ADD DSB   | ~ADDRESS DISABLE           | DROP?     |          |      | Multi-master
                    | 23  ~DO DSB    | ~DATA OUT DISABLE          | DROP?     |          |      | Multi-master
                    | 24  Φ2         | Phase 2 Clock              | DROP      | 15 Φ2    |      | Not NMOS
                    | 25  Φ1         | Phase 1 Clock              | DROP      | 22 Φ1    |      | Not NMOS
                    | 26  PHLDA      | Hold Acknowledge           | KEEP      | 21 HLDA  | 1    |
                    | 27  PWAIT      | WAIT                       | KEEP      | 24 WAIT  | 1    |
                    | 28  PINTE      | INTERRUPT ENABLE           | KEEP      | 16 INTE  | 1    |
                    | 29  A5         | Address Line #5            | KEEP      | 31 A5    | 1    |
                    | 29  A4         | Address Line #4            | KEEP      | 30 A4    | 1    |
                    | 31  A3         | Address Line #3            | KEEP      | 29 A3    | 1    |
                    | 32  A15        | Address Line #15           | KEEP      | 36 A15   | 1    |
                    | 33  A12        | Address Line #12           | KEEP      | 37 A12   | 1    |
                    | 34  A9         | Address Line #9            | KEEP      | 35 A9    | 1    |
                    | 35  DO1        | Data Out Line #1           | KEEP      |  9 D1    | 1    | Bi-directional
                    | 36  DO0        | Data Out Line #0           | KEEP      | 10 D0    | 1    | Bi-directional
                    | 37  A10        | Address Line #10           | KEEP      |  1 D10   | 1    |
                    | 38  DO4        | Data Out Line #4           | KEEP      |  3 D4    | 1    | Bi-directional
                    | 39  DO5        | Data Out Line #5           | KEEP      |  4 D5    | 1    | Bi-directional
                    | 40  DO6        | Data Out Line #6           | KEEP      |  5 D6    | 1    | Bi-directional
                    | 41  DI2        | Data In Line #2            | DROP      |  8 D2    |      | Force tri-state
                    | 42  DI3        | Data In Line #3            | DROP      |  7 D3    |      | Force tri-state
                    | 43  DI7        | Data In Line #7            | DROP      |  6 D7    |      | Force tri-state
                    | 44  SM1        | M1                         | 
                    | 45  SOUT       | OUT                        | 
                    | 46  SINP       | INP                        | 
                    | 47  SMEMR      | MEMR                       | 
                    | 48  SHLTA      | HLTA                       | 
                    | 49  ~CLOCK     | ~CLOCK                     | KEEP      |          | 1    | Alternate clock
                    | 50  GND        | GROUND                     | KEEP      | 2 GND    |      |
                    | 51  +8V        | +8 volts                   | DROP
                    | 52  -16V       | -16 volts                  | DROP
                    | 53  ~SSW DSB   | ~SENSE SWITCH DISABLE      | 
                    | 54  ~EXT CLR   | ~EXTERNAL CLEAR            | 
                    | ...            |                            | 
                    | 68  MWRT       | MEMORY WRITE               | 
                    | 69  ~PS        | ~PROTECT STATUS            | 
                    | 70  PROT       | PROTECT                    | 
                    | 71  RUN        | RUN                        | 
                    | 72  PRDY       | READY                      | KEEP      | 23 READY | 1    | I/O RDY
                    | 73  ~PINT      | ~INTERRUPT REQUEST         | KEEP # TODO, Check electrical config with VI lines
                    | 74  ~PHOLD     | ~HOLD                      | KEEP      | 13 HOLD  | 1    |
                    | 75  ~PRESET    | ~RESET                     | KEEP      | 12 RESET | 1    |
                    | 76  PSYNC      | SYNC                       | KEEP      | 19 SYNC  | 1    |
                    | 77  ~PWR       | ~WRITE                     | KEEP      | 18 ~WR   | 1    |
                    | 78  PDBIN      | DATA BUS IN                | KEEP      | 17 DBIN  | 1    |
                    | 79  A0         | Address Line #0            | KEEP      | 25 A0    | 1    |
                    | 80  A1         | Address Line #1            | KEEP      | 26 A1    | 1    |
                    | 81  A2         | Address Line #2            | KEEP      | 27 A2    | 1    |
                    | 82  A6         | Address Line #6            | KEEP      | 32 A6    | 1    |
                    | 83  A7         | Address Line #7            | KEEP      | 33 A7    | 1    |
                    | 84  A8         | Address Line #8            | KEEP      | 34 A8    | 1    |
                    | 85  A13        | Address Line #13           | KEEP      | 38 A13   | 1    |
                    | 86  A14        | Address Line #14           | KEEP      | 39 A14   | 1    |
                    | 87  A11        | Address Line #11           | KEEP      | 40 A11   | 1    |
                    | 88  DO2        | Data out Line #2           | KEEP      |  8 D2    | 1    | Bi-directional
                    | 89  DO3        | Data out Line #3           | KEEP      |  7 D3    | 1    | Bi-directional
                    | 90  DO7        | Data out Line #7           | KEEP      |  6 D7    | 1    | Bi-directional
                    | 91  DI4        | Data In Line #4            | DROP      |  3 D3    |      | Force tri-state
                    | 92  DI5        | Data In Line #5            | DROP      |  4 D5    |      | Force tri-state
                    | 93  DI6        | Data In Line #6            | DROP      |  5 D6    |      | Force tri-state
                    | 94  DI1        | Data In Line #1            | DROP      |  9 D1    |      | Force tri-state
                    | 95  DI0        | Data In Line #0            | DROP      | 10 D0    |      | Force tri-state
                    | 96  SINTA      | INTA                       | KEEP
                    | 97  SWO        | WO                         | KEEP
                    | 98  SSTACK     | STACK                      | KEEP
                    | 99  ~POC       | Power-On Clear             | KEEP
                    | 100 GND        | GROUND                     | KEEP      | 2 GND    |      |
Pin mapping table for Altair bus implementation

  • the RP2350B has 48 GPIO pins available, with the current layout, we're using 37/48 GPIO pin allocations
  • have about 11 more signals to allocation (really iffy on whether we'll have enough signals on the CPU card)
  • most likely that we will not have mutli-master support, this is fine
  • NOTE, need an additional column of Intel 8212 I/O peripheral support pins
  • i think the 8212 is mostly there to latch I/O signals (provided by from #D pins, once) when starting I/O operations

Entry 1: -----------------------------------------------------------------

Date: January 27nd, 2025

Start Time: 10:00 AM

Duration: 1 hour

Going to create a Github repo containing both a rust workspace and kicad project

Starting work on "tram" (our bus library) using the pio library in rust

The library provides some macros like pio! that let us write inline PIO assembler

=============== Week 2: =================

Entry 2: -----------------------------------------------------------------

Date: January 24th, 2025

Start Time: 10:29 AM

Duration: 1 hour

Revised PSDRs for A1 based on feedback

Removed power design PSDR and enclosure hw interface PSDR

Entry 1: -----------------------------------------------------------------

Date: January 22nd, 2025

Start Time: 9:57 AM

Duration: 3 hours

Finalized component acquisition list

Created functional block diagram for system architecture

Worked on A2 documentation

functional block diagram

=============== Week 1: =================

Entry 4: -----------------------------------------------------------------

Date: January 17th, 2025

Start Time: 10:13 AM

Duration: 2 hours

Reviewed enclosure design options

Worked on A1 document draft

Entry 3: -----------------------------------------------------------------

Date: January 16th, 2025

Start Time: 3:13 PM

Duration: 1 hour

Evaluated Takachi Electronics Enclosure options (AWA, AWN, AWP series)

Considered Misumi's 5-day shipping option for enclosures

Entry 2: -----------------------------------------------------------------

Date: January 16th, 2025

Start Time: 1:06 PM

Duration: 2 hours

  • Evaluated RP2350 package options (QFN-60 vs QFN-80)
  • Identified RP2350 Stamp XL as potential dev board solution
  • Reviewed Stamp XL documentation and specifications
  • Reviewed Stamp XL carrier board specifications
  • Determined carrier board compatibility with various shields
  • Recommended purchasing Stamp XL carrier boards for development
  • Planned bench top hardware and prototyping board setup

Entry 1: -----------------------------------------------------------------

Date: January 15th, 2025

Start Time: 9:30 AM

Duration: 4 hours

  • Discussed 8080 bus implementation requirements:
    • Front panel needs to support single-stepping and clock attachment
    • CPU card needs to handle program counter, instructions, and bus access
    • RAM card needs proper address space handling
  • Researched RP2350 microcontroller capabilities for 8080 emulation
  • Verified PIO peripheral support for 8080 parallel bus (section 1.11 of the datasheet)
  • Confirmed RP2350 PIO block can interface with 48 GPIO pins
  • Reviewed PIO examples for clocked input and parallel bus implementation
  • Designed front panel aesthetics using black solder mask and white silkscreen
  • Created custom "α" mark using exposed mask technique
black pcb with design

=============== PRIOR: =================

Entry 2: -----------------------------------------------------------------

Date: November 12th, 2024

Start Time: 2:11 PM

Duration: 1 hour

  • Created design doodles for front panel layout
  • Re-evaluated front-mounted switches as viable alternative
doodle

Entry 1: -----------------------------------------------------------------

Date: November 11th, 2024

Start Time: 6:57 PM

Duration: 4.5 hours

  • Researched aluminum enclosures for electronic components on Alibaba
  • Found 83*120*155mm Aluminum Electronic Enclosures Case suitable for project
  • Discussed reverse-mounted SMT LED devices and tactile switches for front panel design
  • Explored options for reverse-mounted slide switches, considering custom SLA printed switch caps as alternative