PCB Version 4V1

The latest version of the PCB is 4V1a. It was fabricated at JCLPCB in Jan of 2025. Everything works except that I have not tried out the new 4-bit mode for the SD card interface.

In truth, there were no problems on the 4V0 that forced a respin. It was more like everything seemed fine after all the 4V0 testing and resulting workarounds were in place, so I figured I would just sneak in a few new features and spin the PCB just for fun.

Full details on all the changes are located here. 

The highlights would be:

• All fixes and improvements discovered during 4V0 bringup as described in the Changelist.md file

• Rotated the Pi Pico W so a USB power cable could be left attached permanently. This will allow the umod4 to be powered via a USB power supply even while the bike is turned off. A umod4 that was powered by USB could do things like upload ride logs or download OTA firmware updates while parked with the ignition off.

• The GPS got rotated because its previous footprint was slightly too short. There was no more room in the vertical direction to move its mounting hole upward, so now the GPS module sits horizontally on the PCB.

• Added appropriate signals to allow the Pico W to perform 4-bit SD Card accesses. Assuming I can make the 4-bit driver work, this should increase the speed of log dumping from the SD Card via WiFi, whenever that actually becomes a thing.

One last thing, the 4V1 PCB design is now in a public github repository. If you are interested in poking around and looking at the design, have at it. There are 2 basic problems with the repository at the moment. The first is that the design uses Cadsoft Eagle version 7.6. I still like Eagle, but the product is reaching the end of its days. It would be nice to migrate the entire design to Kicad, but I would have to learn Kicad first. The second issue is more annoying: my Samsung SSD died last year. I was able to recover almost everything from backups except my Cadsoft library containing a number of parts on the umod4 PCB. So the current schematic references parts in a library that does not exist anymore. That is bad, but not a disaster: it's really only a problem if I need to modify one of the parts in the missing library. At this point, I should not have to do that, but who knows what the future brings. It's another reason to look at Kicad, I suppose. But either way, I will need to recreate some library parts either in Eagle, or Kicad. And either way, it will take a bunch of time. Oh well. If this board needs a major change in the future, it will probably happen in Kicad. If it's just minor changes, then Eagle will do fine.

One other thing: I've been working on the "Fake EPROM" code a bit more. You can see it in operation, below.

The upper trace is the 2 MHz HC11 E clock. The falling edge of the E clock indicates the start of an HC11 external memory bus cycle. The lower trace is controlled by firmware in the fake EPROM.  After waking due to the falling E signal, the firmware needs to do a bit of housekeeping like disabling bus drivers from the previous read cycle (if any), and then acknowledging the falling E interrupt. Once that is done, the firmware drives the lower trace high at the point in time where it reads the HC11 address and control signals from the EPROM bus. The firmware first examines the control signals to see if the memory transaction is for the fake EPROM, or some device on the HC11 bus.  If the bus cycle is targeting something other than the EPROM, the firmware has nothing to do so it drives the lower trace low again, and goes back to sleep waiting for the next falling E event.

If it turns out that the bus cycle is reading the fake EPROM, the firmware needs to fetch the proper byte that the HC11 wants to read. After getting the data byte, it drives the lower trace low just after putting the read data on the data bus. That's so I get a nice visual indication of when the read data is valid. 

If the bus cycle is an HC11 write cycle targeting the EPROM, the firmware needs to wait until the write data is guaranteed to be valid. The write data takes a while to get driven by the HC11, which is why you see the trace falling so far to the right. After reading the write data, the firmware still has a bit of work to get done before the E clock falls again, but it turns out there is enough time for that, so all is good.

Finally, you may have noticed that the lower traces look fuzzy. That's because the HC11's 2 MHz E clock is not synchronized to the RP2040's 125 MHz clock. As a result, there will be 8 nanoseconds of 'fuzziness' (one RP2040 clock period at 125 MHz) in the timing of how the RP2040 responds to the falling E event. The net result is that the bottom trace looks exactly the way it should! If you measure the width of the fuzziness, it comes out to exactly 8 nanoseconds, as expected.