Fix implementation of SPI CS multiplexing system

ethanjli commented 3 years ago

This PR modifies the PP-T41 and BP-Jmp boards, and the BT board template, for the Octopi Driver Stack. More information about these boards are available in the README.md files for these boards.

Modifications

Major breaking changes:

The DAC has been removed from BP-Jmp to free up space for other uses. This has caused BP-Jmp's working version number to be bumped from v0.1.1 to v0.2.0; v0.1.1 has been skipped and will not be released.
The pin assignments for the digital I/O expander header in BP-Jmp have been changed; 10 of the pins are now independent I/Os with pull-up resistors, instead of just being tied to the initial set of 10 I/Os, bringing the total number of independent expander I/O ports to 20.

Additions:

A new BOM variant named NoPufferfish has been defined for PP-T41. This BOM variant omits components related to using the Pufferfish Power Board as the 12 V supply.
A second MAX7317 has been added to the I/O Peripherals section of BP-Jmp. The first MAX7317 in this section is directly connected to the header, and it can be used either for open-drain outputs or high-impedance inputs. The second MAX7317 is connected to pull-up resistors, so it can be used either for push-pull logic outputs or pull-up inputs.

Changes:

The layout of the I/O Peripherals section of BP-Jmp has been adjusted to make room for a PWM driver (to be added in the future).
READMEs have been improved.
The repository's pull request templates have been improved and consolidated into one default.

Fixes:

The schematic symbol for the MAX7317 IC has been corrected so that the DOUT pin is marked as an output pin rather than a tri-state pin, so that ERC will catch erroneous direct connection of DOUT to CIPO.
3-state buffers (NC7SZ125) have been placed between the DOUT pins of MAX7317 ICs and CIPO, in PP-T41, BT, and BP-Jmp. The active-low enable pins of these buffers are tied to the active-low CS pins of the MAX7317, so that MAX7317 doesn't pull CIPO high when its CS pin is inactive (fixes #16).
Pull-up resistors have been added to open-drain outputs of the MAX7317 IC where those outputs are meant to be used as logic inputs, so that the inputs can reach 3.3V (fixes #17). Specifically, 2 kOhm pull-up resistors were added to the 5 signal lines (active-low enable, active-high address pins 0-3) between the MAX7317 and the 74HC4067 analog switch, for PP-T41, BT, and BP-Jmp.
Pull-up resistors have been added to the tri-state outputs of the CS pin demultiplexers for DSCS (device switcher chip select) on PP-T41 and for DCS (device chip select) on BP-Jmp (fixes #17). Specifically, 2 kOhm pull-up resistors were added to DSCS0-15 on PP-T41 and DCS0-15 on BP-Jmp.

Release

PRs for Release

Previous PRs since the last release of each board:

9 fixed some silkscreens on PP-T41
11 fixed some schematic pin types, updated some SMT footprints, made various small changes to trace widths and layout of decoupling capacitors in BT and PP-T41; improved thermal spokes for power pads and fixed some 3D models in PP-T41; and updated READMEs
20 added some test points and fixed some 3D models on PP-T41
21 made changes to the indicator LEDs on PP-T41, BT, and BP-Jmp

Merging & Tagging

After this PR is merged, the PP-T41 board will be released with the ODSv1.0.0-PP-T41v0.1.1 tag; the BT board template will be released with the ODSv1.0.0-BTv0.1.1 tag; and the BP-Jmp board will be released with the ODSv1.0.0-BP-Jmpv0.2.0. All of these tags will be made on the develop branch. This PR will be used to keep track of previews and manufacturing files prior to a freeze on the tag. The PR will be merged once the prototype-stage manufacturing order (red PCBs) is placed. Afterwards, additional comments should be added to document any errata or testing results from assembled prototypes, or required changes for the next version can be recorded directly in Github Issues.

Open-Source Records-Keeping

After final changes are made on this PR and it is approved for merging, I will answer the following questions as a new comment on this PR, for records-keeping:

This project is licensed under Apache License v2.0 for any software, and Solderpad Hardware License v2.1 for any hardware - do you agree that your contributions to this project will be under these licenses, too? {CHOOSE YES OR NO}
Were any of these contributions also part of work you did for an employer or a client? If so, do you have their permission to release it? {CHOOSE YES OR NO FOR THE FIRST QUESTION, AND CHOOSE YES, N/A, OR PROVIDE AN EXPLANATION TO THE SECOND QUESTION}
Does this work include, or is it based on, any third-party work which you did not create? If so, what is it licensed under, and what modifications, if any, did you make to it? {CHOOSE YES OR NO, AND EXPLAIN. FOR EXAMPLE, A GOOD EXPLANATION FOR INCLUSION OF THIRD-PARTY PARTS WOULD BE: third-party documentation, CAD models, PCB footprints of parts have been included in the Parts directory. I have added appropriate notices for these files in the README.md files in the corresponding directories.}

ethanjli commented 3 years ago

I will merge this PR after reviewing proofreading its build exports and updating the Kicad preview renders and the stack ray tracing renders.

ethanjli commented 3 years ago

For records-keeping:

This project is licensed under Apache License v2.0 for any software, and Solderpad Hardware License v2.1 for any hardware - do you agree that your contributions to this project will be under these licenses, too? Yes
Were any of these contributions also part of work you did for an employer or a client? If so, do you have their permission to release it? No, N/A
Does this work include, or is it based on, any third-party work which you did not create? If so, what is it licensed under, and what modifications, if any, did you make to it? Yes: third-party documentation and schematic symbols of parts have been included in the Parts directory. I have added appropriate notices for these files in the README.md files in the corresponding directories.

ethanjli commented 3 years ago

Here are the build outputs for the three variants of PP-T41:

Here are the build outputs for BT:

ODSv1.0.0-BTv0.1.1-docs-rev20210312.zip

Here are the build outputs for the three variants of BP-Jmp:

ethanjli commented 3 years ago

I've submitted an order on PCBWay for turnkey assembly of BP-Jmpv0.2.0 and PP-T41v0.1.1-NoPufferfish, 5 boards each. I will update with the pricing for this order, but in the meantime I will merge this PR.

ethanjli commented 3 years ago

As reported in #24, PCBWay is going to use green soldermask rather than red soldermask for this order, due to insufficient distance between the pads of the Hirose FunctionMAX FX20 connectors.

ethanjli commented 3 years ago

PCBWay reports the following costs at a production size of 5 units:

PP-T41, NoPufferfish BOM variant: $77 for PCB fab; $270 for parts; and $30 for SMT assembly. This adds up to $75 total per board (+$30 per board for a Teensy 4.1)
BP-Jmp, Default BOM variant: $77 for PCB fab; $440 for parts; and $88 for SMT assembly. This adds up to $120 total per board.

ethanjli commented 3 years ago

I've received the boards. Here are test results:

Indicator LEDs

When I plug in a 12 V power supply, the green power indicator LEDs are too bright. The brightness of the 12 V indicator LED should be roughly the brightness of the blue status indicator LED.
The PP-T41_Status_Indicators sketch works fine out-of-the-box. The brightnesses of the status indicator LEDs seem fine to me. Blue is noticeable without being annoying, while yellow is brighter, and red is attention-grabbing (quite bright).

Teensy_Pins Test

When I have just the PP-T41 board with the Teensy_Pins sketch, everything works as expected except: pin 12's square wave goes between 0 V and 1.25 V; pin 12 corresponds to SPI0_CIPO, which would suggest that something else is pulling this pin low. This pin is only connected to the Hirose stacking connector, and to the 3-state buffer controlled by active-low SPI_MSCS. On the connector, SPI0_CIPO is surrounded by GND pins. If I drive SPI_MSCS (Teensy pin 30) high in the Teensy_Pins sketch when I'm not outputting the 1 kHz square wave on it, then pin 12's square wave looks normal - it goes between 0 V and 3.3 V. Then this was a problem with the Teensy_Pins sketch.

T41_DSCS_Demux Test

When I have just the PP-T41 board with the T41_DSCS_Demux sketch, I don't get the trace I expect on SPI_DSCS0 with the PP-T41_DSCS_Demux sketch. Specifically, the square wave on the SPI_DSCS0 pin is measurable when the sketch tells me that it's generating a square wave on SPI_DSCS15, not when the sketch tells me that it's generating a square wave on SPI_DSCS0. At this time, the MUX_S0-3 pins are all at HIGH (and indeed, the datasheet shows that when all of those pins are HIGH, then Y15 is connected to Z). When the sketch tells me it's outputting on SPI_DSCS0, then it's actually outputting on SPI_DSCS15; and the same flip occurs with SPI_DSCS1/SPI_DSCS14, SPI_DSCS2/SPI_DSCS13, etc. So my test code was treating the MUX_S0-3 pins as active-low rather than active-high. After fixing this, the demultiplexed DSCS addressing worked! When I measured the voltage levels on the MUX_S0-3 pins, I found that at the low levels they were at 0.25 V. So we could increase their pull-up resistances.
When I have just the PP-T41 board with the T41_DSCS_Demux sketch (or also with the BP-Jmp board), I don't get the trace I expect on SPI_DSCS with the PP-T41_DSCS_Demux sketch. Specifically, the square wave on SPI_DSCS ranges between 3.2 V and 3.3 V, rather than 0 V and 3.3 V. However, the square wave on SPI_DSCS (Teensy pin 31) behaved normally in the Teensy_Pins sketch - this suggests that there's an issue related to pull-up resistors or something. Consistent with this, when I set the sketch to output on SPI_DSCS0 and I also connect SPI_DSCS to SPI_DSCS1, then the low value of the square wave changes from 3.2 V to 3.25 V. Essentially we halved the resistance of the pull-up resistors, and as a result the amplitude of the wave was halved. Based on this, it would appear that the Teensy is only able to sink 50 uA of current when the pin is driven LOW, or else it has a high level of internal resistance - ~64 kOhm! If I instead drive PP-T41 from an Arduino Due, when SPI_DSCS is connected to SPI_DSCS0 then the square wave becomes flat at 3.3 V! We should try increasing the pull-up resistor strength. When I tried adding 20k of resistance on a separate breadboard between the connection with SPI_DSCS and SPI_DSCS0 (for a total resistance of 22k), the square wave changed to going between 2.67 V and 3.3V - then the current through the resistors is 30 uA, and in a voltage divider circuit the internal resistance of the Teensy would then be 93k (which are different values from what we saw previously). With a pull-up resistance of 100k, the square wave is between 1.6 V and 3.3 V. With a pull-up resistance of 470k, the square wave is between 0.55 V and 3.3 V, and it's still very square; with 570k, it's 0.45 V. I don't get the same results when I put 570k between SPI_DSCS and 3.3 V or SPI_DSCS0 in the Teensy_Pins sketch, only in the DSCS_Demux sketch!
After I removed the pull-up resistors R1 for SPI_DSCS0, then SPI_DSCS and SPI_DSCS0 had a full 0 V to 3.3V square wave. But after switching to output on SPO_DSCS1, SPI_DSCS0 was at 0 V, indicating the need for pull-up resistors. So I switched all pull-up resistors to 576k. Then SPI_DSCS0, when selected looked just like SPI_DSCS: a square wave between 0.45 V and 3.3 V. When a different demuxed SPI_DSCS pin was selected, however, then SPI_DSCS0 became a flat line at 2.15 V! The same was true of the other demuxed SPI_DSCS pins when they weren't selected! This only occurred after I swapped the 2k pull-up resistors for 570k pull-up resistors. There's probably a problem with the leakage current spec. I'm also able to reproduce these readings on SPI_DSCS0 when I drive SPI_DSCS from a jumper wire connected to GND or 3.3 V, rather than driving it from the Teensy running the DSCS_Demux sketch.

In order to have a robust solution to this issue with the 74HC4067 16:1 analog switch which is directly related to this issue with the pull-up resistors and HIGH/LOW levels, we have a few options:

We might be able to find pull-up resistors which just barely work with the HIGH & LOW threshold voltages. This doesn't feel robust. We'd probably want to find a different 4067 chip which gives lower leakage currents, or has whatever different specifications to be better for our purpose (see this discussion, which may or may not be directly relevant).
We could find some way to use the 74HC4067 without using pull-up/pull-down resistors directly connected to its outputs. This would require some other component which can map pin inputs to outputs as H -> H, L -> L, and high-Z -> H while not drawing currents into the input pin. I'm not sure if such a component exists, as usually this would be done just by a pull-up resistor.
We could find a different chip which isn't an analog switch. For example, for 4:16 decoders, the 74HC4514 basically does what we need except we'd need to invert all its outputs in order to have active-low outputs for CS pins, while the 74HC4515 provides the inverted outputs but end-of-life; and both IC types are only produced as DIP and SOIC packages. We may instead be able to use two 3:8 decoders (e.g. the 74HC138), possibly without even requiring more pins from the MAX7317. This may be the most promising approach.

prakashlab / octopi-driver-board