# Programmable Load # CPU Board The thing that runs the show # Peripheral Allocation - CAN0: Expansion - PA22 (TX), PA23 (RX) - SERCOM0: I2C, front panel/rear IO (through mux) - IOSET1 - PA8 (SDA, PAD0), PA9 (SCL, PAD1) - SERCOM2: I²C, analog board - PA12 (SDA, PAD0), PA13 (SCL, PAD1) - SERCOM3: SPI, analog board - IOSET1 - PA16 (SCK, PAD1), PA17 (MOSI, PAD0), PA18 (MISO, PAD2) - Chip select: PA19 (/EN) - Chip index: PB16, PB17 - SERCOM4: SPI, front panel display - IOSET1 - DIPO = 0x0 - DOPO = 0x2 - PB12 (MISO, PAD0), PB13 (SCK, PAD1), PB14 (/CS, PAD2), PB15 (MOSI, PAD3) - SERCOM5: SPI, NOR flash (bonus data) - IOSET6 - DIPO = 0x3 - DOPO = 0x0 - PB2 (MOSI, PAD0), PB3 (SCK, PAD1), PB0 (/CS, PAD2), PB1 (MISO, PAD3) - TC3: Fan PWM - PA14: WO\[0\] - TC5: Beeper - PB10: WO\[0\] - EIC: External interrupt controller - PA15: /TRIGGER - EXTINT15 - PA20: /ANALOG\_IRQ - EXTINT4 - PB08: ENCODER\_B - EXTINT8 - PB07: ENCODER\_A - EXTINT7 - PA10: /IO\_I2C\_IRQ - EXTINT10 - XOSC1: 12MHz oscillator - XIN (PB22), XOUT (PB23) - Debug - SWCLK (PA30), SWDIO (PA31), SWO (PB30)

If desired, the driver communication interface can use CAN0 instead. It uses the same IO pins as the I²C bus, and requires a CAN transceiver on the board.

# DMA Channel Allocations DMAC should operate with dynamic, round-robin priority arbitration within a DMA priority level. Priority levels listed are from 0 (highest) to 3 (lowest.) - Ch0: NOR flash SPI Tx empty (SERCOM5) - Priority: 2 - Operate in SPI 32 bit data mode - Burst transfers - Ch1: NOR flash SPI Rx complete (SERCOM5) - Priority: 2 - Operate in SPI 32 bit data mode - Burst transfers - Ch2: Display SPI Tx empty (SERCOM4) - Priority: 1 - Operate in SPI 32 bit data mode - Burst transfers # Clocking ### Clock Inputs All clocks on the system are derived from one of the following clock inputs (oscillators and internal generators:) #### Crystals - XOSC1: External 12MHz oscillator - Provides primary system clock reference - XOSC32K: External 32.768kHz oscillator - Runs in standby for RTC #### FLLs - DFLL48M: 48MHz - Used for USB reference clk - Uses external 32kHz osc for reference #### PLLs - DPLL0: 120MHz - CPU core clock ### Clock Sources The above clock inputs are then synthesized into multiple clock sources, each used by a different set of peripherals: - GCLK0: 120MHz - Sourced from DPLL0 / 1 - General high speed clock - GCLK1: 48MHz - Sourced from DFLL48M - Intended for USB use - GCLK3: 32.768kHz - Sourced from XOSC32K - SERCOM slow clock - GCLK4: 12MHz - Sourced from XOSC1 - General low speed clock - GCLK5: 32.768kHz - Sourced from ultra low power 32kHz osc ### Clock Consumers - CPU core: GCLK0 - Clock division factor: /1 - Low power clock: /4 - Backup domain: /8 - High-speed: /1 # Hardware Errata This page lists some issues with CPU board hardware, as they are discovered, and some workarounds. ## Rev 1 - /I2C\_IRQ's external IRQ line conflicts with ENCODER\_A - Move /I2C\_IRQ from PA7 to PA10 - Rework required: solder line from pin 11 (/IRQ) of U101 to middle of J302 (TXD) - Status LED (D302) footprint is wrong - The common (+) and red pins are swapped - Footprint for MMBT3904 transistors (Q101, Q301) are slightly too small - The two pads side is slightly too much spacing between pads - They are still solderable, it just looks ugly - NOR Flash (U303) is actually 4Mbit - This is the part I actually had lol - Power LED driver doesn't work - The weird trick with the two resistors doesn't seem to work… like, at all - We'll have to revisit how this is controlled (external logic? sacrificing another pin?) - Footprint notes - Copper size on the pads could be increased - For mechanical retention of the switch, nudge the outer (switch) pads in by a small amount - Switched front/rear I²C bus (from mux to MCU) is missing pull ups - Need to insert these between the mux (U101) and microcontroller - Rework required: Bodge in a pair of 2k2 resistors to +3V3[![image-1648709305027.jpeg](https://wiki.trist.network/uploads/images/gallery/2022-03/scaled-1680-/GvJv1sbX1ImjcXRK-image-1648709305027.jpeg)](https://wiki.trist.network/uploads/images/gallery/2022-03/GvJv1sbX1ImjcXRK-image-1648709305027.jpeg) # IO Front and rear panels # Front Panel The front panel features a few buttons, indicators, and a rotary encoder. ## Overview [![front-panel.png](https://wiki.trist.network/uploads/images/gallery/2022-04/rFK74kSHRoG9sCS6-front-panel.png)](https://wiki.trist.network/uploads/images/gallery/2022-03/EL93mLo1qQbhIc01-image-1647139758326.png) Note that the actual front panel board only covers the right third of the actual front panel: the area with the push buttons, indicators, and rotary encoder. It's mounted to the case via four 8mm standoffs with M2.5 thread, and should be screwed in with washers to distribute the force of button pushes more evenly across the board, rather than stressing the screw holes. ### Connectors There are two primary connections to the rest of the world on the front panel: the external voltage sense input, and the supply input.

External voltage sense may or may not be used for measurement, depending on software control.

Supply input is made through a pair of binding posts ([Cal Test CT4231](https://app.caltestelectronics.com/product-list/product-page/view/CT4231/)) supporting up to 36A per post. The positive and negative terminals follow the standard red/black convention, and are internally connected to the driver board via thick wiring. The binding posts should use some sort of screw mount for the wire, which itself should have crimped ferrules or other terminals on the end to attach conveniently to the wire. External sense voltage is delivered through a pair of banana jacks ([Cal Test CT2240](https://app.caltestelectronics.com/product-list/product-page/view/CT2240/).) These do not need to carry much current (if any) and are on a yellow and black connector (for positive and negative, respectively) there. These jacks are solder mount, which should be soldered to a (possibly shielded) twisted pair wire, which in turn connects to the driver board's external voltage sense input. ### Buttons The bulk of the buttons on the front panel consists of illuminated tactile switches ([Omron B3W-9](https://components.omron.com/us-en/products/switches/B3W-9) type), which are further subdivided into the mode selectors (column of four switches, each with a single yellow LED) and the input on/off button (one switch, with dual red/green LEDs.) Additionally, the button inside the rotary encoder (triggered when the knob is depressed) is available as a switch for selecting items in menu. It works in conjunction with the circular menu button ([C&K D6R](https://www.ckswitches.com/products/switches/product-details/Keyswitch/D6/D6RLGN%20F1%20LFS/) type) to browse menus. On the front panel, all buttons are connected to a [XRA1203](https://www.maxlinear.com/product/interface/bridges/gpio-expanders/i2c-gpio-expanders/xra1203) I²C IO expander. It features an interrupt output, which is connected to the controller board so buttons needn't be polled in software. Lastly, there is a power button in the lower left corner; this switch actually exists on the controller board, rather than the front panel. It's an illuminated, right angle tactile switch ([CTS 228A](https://www.ctscorp.com/wp-content/uploads/228A.pdf) type) with the appropriate power icon (the little circle with the dash on it) printed on its cap. The board is set up to support bi-color illuminated switches so that there can be a standby/active type lighting situation. ### Indicators Indicators are LEDs, which are brought out to the front panel via light pipes. These indicators consist of one RGB LED (status,) one amber LED (trigger,) and three red LEDs (overheat, overcurrent, error.) Each LED can be individually controlled, and its brightness (current) adjusted. Each of the buttons, with the exception of the rotary encoder itself, contains at least one LED. These LEDs are available to drive the same way indicators are, via the LED controller. All LEDs are connected to a [PCA9955B](https://www.nxp.com/products/power-management/lighting-driver-and-controller-ics/ic-led-controllers/16-channel-fm-plus-ic-bus-57-ma-20-v-constant-current-led-driver:PCA9955BTW) constant current LED driver. ### Display Any SPI display is compatible with the front panel, though it is specifically designed for the [ER-OLEDM032-1Y](https://www.buydisplay.com/yellow-3-2-inch-arduino-raspberry-pi-oled-display-module-256x64-spi) module (or any other compatible modules with other colors; do note that the display may need to be modified for 4 wire SPI operation, by soldering some resistors and jumpers) and its pinout.

Regardless of the type of display, it should not consume more than roughly 350mA of current. The main board has a 500mA polyfuse for the display.

The display mounts on 6mm long M2.5 studs, with nylon stand-offs to get the correct distance between the front panel and the display surface. Then, a washer and nut are attached to the end, to fasten the display securely. ### Miscellaneous On the front panel board, there is also an I2C EEPROM (AT24CS32 type) that contains the front panel’s exact configuration, including the switches available, mapping of switch inputs and LED outputs, and LED drive characteristics such as maximum current. ## Revisions Currently, there’s just one revision of front panel, pictured above. It works, but it needs some minor rework: - Menu button too small: needs +.4mm to diameter - Edge machining on display cutout: A bevel would be more attractive # Rear Panel On the rear of the device are a few auxiliary connections, including AC power input, communications (Ethernet, USB) and an external trigger input. [![rear-panel.png](https://wiki.trist.network/uploads/images/gallery/2022-04/n7PzQeXY3kXJANUw-rear-panel.png)](https://wiki.trist.network/uploads/images/gallery/2022-03/oUjVicTsUHWcX8G9-image-1647200673543.png) *Rear panel, as viewed from front (inside)* ### Power A cutout is provided for an IEC mains filter/input module with switch and fuse – in this case, the cutout is sized to fit the Astrodyne TDI 084 series, specifically the [084.00301.00](https://store.astrodynetdi.com/filtered-power-entry-modules-with-double-fuse-holder-and-switch084-00301-00.html) with a 3A fuse.

It's very important that the IEC input module has a fuse built in; the only protection, if using the driver board's AC/DC module is a varistor to arrest surges.

Output from the filter (usually provided on spade terminals, or directly on wires) should then go via (sufficiently insulated) wires to a connector ([CUI Devices TBP02P1W-381](https://www.cuidevices.com/product/interconnect/connectors/terminal-blocks/tbp02p1w-381-series)-03 or similar 3.81mm pluggable terminal block) to the driver board, which has a power module ([CUI PSK-20D-12](https://www.cui.com/product/internal-ac-dc-power-supplies/board-mount/psk-20d-series/psk-20d-12), [Meanwell IRM-20-12](https://www.meanwellusa.com/webapp/product/search.aspx?prod=IRM-20), or similar) to produce the 12V from mains input. Alternatively, this power module can be skipped in favor of an externally mounted power supply, in which case the mains input can be directly wired there; though take care to ensure that the case is still grounded. (The driver board has a 3.96mm JST-VH B2P-VH connector as a +12V input to accommodate external power supplies in place of a soldered power module, if that is desired instead.) If an external supply is used, it should be capable of providing at least 1.6A at 12V with reasonably low noise. ### IO Board Ethernet and USB connectors are mounted on a small auxiliary circuit board, which mounts by means of screws on two 12mm M2.5 standoffs, and assumes a panel thickness of ~1.5mm. It serves as not much more than a simple breakout, converting from the 20 pin, 1.27mm ribbon cable coming from the controller board to these connectors. On the USB connector, there exists basic transient filtering (via a TVS) and an I²C ADC to sense the VBus voltage. (There's no reason for a full blown ADC, but it was cheaper than an IO expander for just a single line.) The Ethernet connector ([Abracon ARJC07-111071A](https://abracon.com/Magnetics/lan/ARJC07-111071A.pdf)) is a vertical MagJack type, with the required magnetics integrated into the connector; therefore, the Ethernet side is not much more than a straight through connection, with some current limiting resistors for the connector's activity indicator LEDs. Lastly, the board features an EEPROM (AT24CS32 type) for identification by software. ### External Trigger The last connector, near the bottom of the panel, is a cutout for a board mount BNC connector ([TE 1-1634624-0](https://www.te.com/usa-en/product-1-1634624-0.html)) on the driver board. This connector is used as an external trigger for various custom modes; it is relatively low impedance and drives directly an optoisolator. No special treatment is required for the connector beyond the cutout, though it may feature a nut or other retention mechanism on the other side of the panel. ### Miscellaneous For cooling purposes, the remaining area on the right side of the panel has a cutout for a 60mm fan. This fan is automatically controlled by the processor board. It should be set up to suck air out of the chassis, to encourage more intake of fresh air at the front. This works in conjunction with the smaller fan on the driver board's heatsink. # Front Panel Errata ### Rev 1 - Mode/load switches footprints need soldermask pulled back from pads - The pads are covered by soldermask. This is bad # Rear IO Errata ### Rev 1 - Copper rings around USB connector pads should be larger - Retention holes for Ethernet jack should be slightly smaller (to accommodate push-in expansion action for mechanical stability) # Load Driver Separate board to actually do the load operations, with MOSFETs or whatever else # Hardware Errata This page lists some issues with the hardware. ### Rev 2 - Holes for current sense resistors should be slightly larger - Datasheet specifies 1.5mm ±0.12mm - Increase spacing between heatsink and MOSFET/resistor slightly - Right now, the legs need to be bent at a bit of an angle, which makes fitting everything a huge pain in the ass - Zero offset resistor (R307, ???) is too large - 4M7 is too large and doesn’t let us trim out the entire DC offset (~4.5mV) - 1M was also too large (~3.5mV) - 200k works (able to trim to ~1µV remaining offset) - This is probably too low, maybe something like 330k or 500k is better - The trimming range is quite small ### Rev 1 - MOSFET gate drive voltage too low - VGs, with the current configuration can only drive to max +3V3. This is not sufficient to turn on the MOSFETs selected (IXTH80N075L2) with a VGs(th) of 4.5V max - May be salvageable by rework (op-amp powered from 5V instead) and selecting a different MOSFET - Future work - Select a MOSFET driver opamp that can be powered from ±12V - Update power section to generate isolated 12V (replace PS201 with PDSE1-S12-S12-S) - Generate 5V locally (switching supply off 12V) - I²C isolator (U203, ADuM1250) has the output SCL/SDA swapped - The I²C bus is swapped for all devices downstream of the EEPROM # Adjustments The driver boards need to have done to work. ### Rev 1 #### Current driver zero offset **Trimmers:** RV301, RV302 This adjustment controls the zero offset of the current sense amps. Connect the load to a (current limited) power supply, with a current meter in line. Ensure the current DACs are outputting an all zeros code, then adjust each of the trimmers so that the load is not drawing any current. #### External trigger pulse shaper **Trimmers:** RV501 Changes the length of external trigger pulses. Connect a signal generator to the external trigger input, and an oscilloscope to TP501. Adjust until the pulse is approximately 50ms in length. #### Voltage sense offset **Trimmers:** RV601 Controls directly the input voltage offset differential amp, and is used to trim any residual offset in the voltage. Select external voltage sense input with the relay, then short the input sense terminals to each other. Adjust until the voltage ADC reads an all zeros code. # Remote Control Information about the remote control interface of the load, including the underlying protocol, and differences between supported transports. # Protocol This page describes the native communications protocol with the device. It is binary based, with a small header, and no other requirements on the data. By convention, most (if not all) endpoints accept and provide data that is [CBOR](https://cbor.io "Concise Binary Object Representation") encoded. ### Header All packets have a simple four byte header that precedes the payload, regardless of the underlying transport: - 1 byte: Message type - Indicates the "endpoint" inside the protocol handler that should receive this message - 1 byte: Tag - Can be used to differentiate multiple outstanding requests and their replies - 2 bytes: Length - Indicates the number of bytes of payload data that follow Note that all multi-byte values in the header are sent in big endian (network) byte order. #### Message Types Below are all currently implemented message types/endpoints:
**Number****Name****Description**
`0x01`Property RequestGet/set various properties on the device. See [Properties](https://wiki.trist.network/books/programmable-load/page/properties "Properties") for more info.
### Transports This same protocol can be carried over a variety of physical transports. The format of messages, including the packet header, are the same; however, the transport may add additional headers and padding, if needed. At this time, the following transports are supported: #### USB The first interface exposed by the device is a vendor specific interface, which consists of two bulk endpoints (one in and one out) used to transmit and receive the packets and their responses; as well as an interrupt endpoint, used to notify the host that the state of the device changed. In this case, the device does not send unsolicited data. No additional headers are added to payloads sent over the endpoints, beyond the above packet headers. # Properties This page describes the "property request" mechanism, as well as the message format used to interact with it. ### Message Format All messages on this endpoint are CBOR encoded. #### Requests Requests are maps, with one or more of the following keys: - get: An array of property IDs to read - set: A map containing properties to set. Keys in the map correspond to property IDs. #### Replies The device responds with a map, which contains the following keys. Which keys are included in the response depends on the request: - get: A map (keyed by property IDs) containing the value of all requested properties. Unsupported/unknown properties are returned as `undefined`. - set: An array containing the property IDs of all properties that were set. Any properties that were requested to be set, but are not supported (or read-only) will not be included. ### Supported Properties Below are all currently supported properties, including their IDs and value types:
**ID****Name****R/W****Type****Description**
`0x01`HwSerialRstringSerial number of the hardware
`0x02`HwVersionRstringVersion information (such as revision) for the device
`0x03`HwInventoryRarrayInformation about all peripherals connected to the load. The array contains maps, which will have the following keys: - type: Peripheral type; may be one of \["load", "hmi" or "io"\] - sn: Serial number (string; optional) - driver: Driver id (blob; optional)
`0x04`SwVersionRstringCurrent software version (including build number)
`0x05`MaxVoltageRintMaximum allowable input voltage (mV)
`0x06`MaxCurrentRintMaximum allowable input current (mA)
`0x07`DefaultVSenseRWintVoltage sense source on power-on: - -1 = state at last power off - 0 = internal - 1 = external This setting is persistent.
`0x08`DefaultModeRWintOperation mode on power-on: - -1 = mode at last power off - 0 = Constant current - 1 = Constant voltage - 2 = Constant wattage This setting is persistent.
`0x09`DefaultCurrentRWintCurrent limit value (for constant current mode) to apply on power on, in mA. -1 = last user specified value at power off
`0x0A`DefaultVoltageRWintVoltage limit value (for constant voltage mode) to apply at power on, in mV. -1 = last user specified value at power off
`0x0B`DefaultWattageRWintWattage (for constant wattage mode) to apply at power on, in mW. -1 = last user specified value at power off
# Controller (New) A new and improved controller for the programmable load, based around an STM32MP1 dual Cortex A7/M4F. # Overview This is a new controller board for the programmable load, designed around the [STM32MP1 microprocessor,](https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html) which contains a Cortex A7 core (suitable for running a full-blown operating system) as well as a Cortex M4 core (suited to running real time sensitive tasks with an RTOS) on the same package. To avoid needing to deal with BGA packages, high speed DDR routing, and a bunch of power rails, a [MYIR MYC-YA15X SoM](http://www.myirtech.com/list.asp?id=658) is used. ### Connectivity As with the previous designs of the load, it will feature an USB device mode connection, as well as standard 100Mbps Ethernet with a standard IPv4 and IPv6 stack. Additionally, a CAN expansion bus is provided to connect multiple units together, and possibly to other, larger loads down the road. Internally, the controller provides both a high-speed SPI for the analog interface (to allow fast control of ADCs and DACs by software) as well as a low-speed I²C interface, which is primarily intended for identification of the analog board, and some auxiliary control tasks like thermal management and input selection. ### User Interface Most of the user interface remains the same from the previous iteration, including the button and indicator layout on the front panel, barring some minor spacing changes. However, the small greyscale OLED is replaced by a 800x480 4” capacitive touch LCD. This is driven directly by the LCD interface controller in the Cortex A7 side of the microcontroller, and provides an user interface that allows interaction by a hybrid means of the front panel buttons and touch controls. ### Power The switching AC/DC supply in earlier versions is replaced by a regular mains transformer, a standard rectifier and smoothing capacitors, followed by several DC/DC modules to generate the required voltages. Eliminating the AC/DC switching supply reduces the noise in the system, and provides greater isolation from mains. # Peripherals Below are listed the general peripherals used by the controller. These are selected so that they consist of the peripherals that are available on pins broken out by the MYIR STM32MP1 SoM. ### Cortex A7 These peripherals are reserved for the exclusive use of the Cortex A7 side. This runs a full OS, handles networking, expansion connectivity, the user interface, and so forth. #### Communications - I2C2: Front panel / local I²C bus - Through PCA9543A bus mux - SPI3: Front panel display, CAN controller (through /CS-based mux) - Front panel display controller - On-board CAN controller - UART4: Kernel TTY - ETH: Ethernet MAC, in 100Mbps mode - PHY connected via RMII - STM32 generates 50MHz refclk for PHY - USBH/USBOTG: Support for one USB host, one OTG device - Device exposes standard load interface - Support for boot over USB #### GPIOs - PB9: Front panel reset - PC0: Ethernet PHY reset - PC12: I2C2 mux reset - PF6: Expansion connector power enable - PF7: Expansion CAN termination - PF9: Expansion CAN controller reset - PZ6: Status LED (bicolor, 0/1/Z mode) #### External IRQs - PD2: I2C2 mux irq - PA5: Ethernet PHY irq - PC12: SPI3 irq ### Cortex M4 These peripherals are reserved for the exclusive use of the Cortex M4 core, which runs the real-time control loop and a few other tasks better suited to an RTOS environment. #### Communications - I2C1: Analog interface (low speed) - Used for IDPROM, fan controller, temperature sensing, etc. - Runs at ~400kbps - SPI5: Analog interface (high speed) - Runs at up to 20MHz - Up to 7 devices (3-bit select code) - UART5: Debug console #### Timers - TIM2: Magnetic transducer (beeper) - PA3, Ch4 PWM output - TIM4: Front LCD backlight - PB7, Ch2 PWM output #### GPIOs - PA12: SPI select bit 1 - PD8: Analog interface reset - PD13: Status LED (green) - PE11: SPI select bit 2 - PF8: Status LED (blue) - PG5: Status LED (red) #### External IRQs - PG3: Analog interface - PA4: Front panel encoder “A” - PA5: Front panel encoder “B” - PG8: External trigger - PF10: Zero crossing detect # Hardware Errata This page documents some issues with the hardware. ### Rev 3 - Footprint for RTC backup battery (BT301) is backwards - The + terminal of the battery connects to the GND node, and vice versa. - Resolution: Populate battery in reverse - RTC charger should be powered by system +3V3 rail - It's powered by the SoC's own 3V3 rail now, which toggles off during reboot - Use instead the system +3V3 rail - Incorrect power-on reset behavior - There is no reset pulse generated on boot-up (by an external reset generator… which we don't have. lol) which causes spurious boot failures - So, we should add a supervisor for the reset line - Generate a power on reset pulse of ~1 sec with the +5V rail - We may need to shorten the reset delay on the +3V3 voltage supervisor line - Alternatively – directly use the +3V3 input to switch it - This was caused by the RTC charger coming off the +3V3 SoM rail. Using the system +3V3 rail resolves this - Pulse shaper stuff - Adjusting it sucks as TP501 is on the *analog* side of the filter, rather than the nice, pristine digital from U507 - Fix: Add another test point at the output - Alternatively, we can probably work around this in software (with a special calibration UI?) - Possibly expand the adjustment headroom - Front panel connection - The pinout of the connector is mirrored (left to right) with respect to the front panel when assembled - We can probably leave this (using a longer flex to compensate) or fix it on either the front panel or controller board revision (probably the controller board) - Rear case fan (M501) connector sucks - The location is awful (it will be right underneath the analog board) - Relocate it elsewhere - but where? - Where VBUS LED is chilling - In the back by the expansion connector - We'd need to relocate some of the expansion IO stuff, like the termination and so forth - Power supply section sucks to assemble - Is there anything we can do to make this less awful - Also, add an easier way to power the board off DC - Spring/screw terminal near power supply area