MuxPi

From Tizen Wiki
Jump to: navigation, search

Compact, affordable and versatile device created to make testing easier.

image

Introduction

MuxPi is a small board designed to aid automated testing system of Tizen binary images. Despite that, it is a very versatile device which can be used for many other purposes. It is an open-hardware and open-software project. Both, the hardware and the software are fully documented and published, so anyone can build such device on their own. Name of the board relates to its main feature - "SD MUX (Mux)" and its brain - "NanoPi NEO (Pi)".

The main goal of this board was to separate user/developer/lab maintainer from a device being tested. The second goal was to reduce number of external connection to the necessary minimum. That's why it was equipped with so many interfaces. MuxPi is also equipped with tool for powering off and on the tested device. Thanks to that, DUT (Device Under Test) can be located anywhere on the planet, provided there is an active ethernet/internet connection. The "sandwich" made of MuxPi and a DUT is connected to the world only with two cables: ethernet and power supply.

DUT can be moved away from developer or tester thanks to its many interfaces. It provides ethernet, level shifted UART, USB HOST, USB OTG, USB with power and ID control, DyPers (Dynamic jumPers), power control, microSD card multiplexing, HMDI (DDC), I2C or SPI. All of that allows users to connect nearly all DUT's interface to MuxPi and access them remotely. Most of low level hardware features are controlled by onboard Cortex-M0 microcontroller. But to increase its power it was equipped with linux based SBC NanoPi NEO. It gives power of computing, connectivity, ease of use and even more interfaces. What's more, MuxPi is ready to handle add-ons that can extend its functionality even more. The board also supports a user or a lab engineer with User Interface based on a small 128x32 OLED display, two keys (microswitches), 6 one-color LEDs and two RGB LEDs. And all of that only for about 80$. The board is small, affordable and yet very powerful.

MuxPi might be considered as some kind of mother board for NanoPi NEO SBC but it can operate without NanoPi NEO. However in such scenario its functionality is heavily reduced.

It is powered from commonly used 5V power adapters with standard 5.5/2.1 DC power plug.

Real foto:

image

Board in this image has mounted NanoPi NEO with heatsink. It is not present on the above, rendered picture.

Who is this board for?

For developers, testers, test labs, makers... Anyone who has an idea about automating some tasks. Here MuxPi comes with help providing ease of use, distribution and connectivity. Don't think how to get your device accessed remotely, just do it with MuxPi.

Where to get it from?

Needs to be build on your own, at least for now. However it is not that easy to assemble this board without very specific tools, soldering skills and huge amount of patience. One obstacle is to collect all the components, second obstacle is to manufacture the PCB and finally the biggest obstacle is to assemble the board. To be honest, if you wonder whether you can assemble this board or not then most likely you can not. In such case make someone to make it for you.

Block Diagram

image

General description

MuxPi consists of two main parts:

  • Main board
  • NanoPi NEO

Main board is filled with all needed interfaces, user interface components and converters. Among them, lies a microcontroller to rule them all. The microcontroller is STM32F030C6T6 (Cortex-M0). Its main task is to help NanoPi NEO with low level tasks.

NanoPiNEO is a SBC (Single Board Coumputer) based on Allwinner H3 (Cortex-A7) microprocessor at 1.2GHz, quad core with 512MB of RAM. It's linux based microcomputer with ready to be used ubuntu-core distribution. It's MuxPi's brain. It allows to perform tasks on MuxPi almost like it were a regular PC.

NanoPi NEO uses Cortex-M0 microcontroller to control peripherals present on the main board. NanoPi NEO itself does not have enough GPIOs and local interfaces to handle all of the peripherals. It communicates with the microcontroller through UART (/dev/ttyS2) using simple text protocol. List of all supported commands is accessible directly from microcontroller through "help" command.

There is a small, third microcontroller located on the main board. It is AVR ATtiny10. It acts as a watchdog. Its reset input is connected to Cortex-M0 as there is no free GPIO on NanoPi. Using microcontroller for this task allows to freely choose time interval. The time has to be specified in its binary firmware.

Blocks

  • NanoPi NEO - not a function itself but allows to create and perform almost any function that can be performed in a software
  • 4-wire UART level shifter - simple block of voltage level shifters for connecting to DUT's UART;
  • UART voltage generator - not present in the block diagram as it is part of UART. It allows to generate voltage in range from 0 to 5V.
  • Watchdog Timer - a simple timer that allows to restart of NanoPi board; timeout can be configured in a very wide range: milliseconds, seconds, minutes, hours...
  • Power Control & Current Measurement - a circuitry which allows to:

    • control power of a DUT using electromagnetic relay - measure DUTs current consumption using HAL effect current sensor which gives galvanic isolation from control logic
  • uC - Cortex-M0 based module which supports NanoPi board with functions it can't realize; The module takes care of:

    • controlling SD-MUX module
    • controlling DyPers
    • handling User Interface
    • writing EDID to DUT's HDMI
    • measuring DUT's current consumption
    • handling NanoPi's watchdog
    • cooperating with add-ons:

      • measuring analog signals
      • handling GPIOs
      • handling LEDs Display and keys
    • Power Supply - simple circuitry giving two functionalities:

      • generate 3.3V for internal need
      • enable/disable power supply for the main board, controlled by NanoPi (power supply for NanoPi is not controlled by this circuit)
    • UI - User Interface, comprises of:

      • power presence LED
      • UART VCC presence LED
      • SD card reader activity LED
      • NanoPi NEO keepalive LED
      • two monochrome LEDs driven by NanoPi for grnereal purpose
      • two RGB LEDs driven by uC for general purpose
      • 128x32 OLED display for general purpose
      • 2 push buttons to allow a user to interact with the board
    • USB-ETH - USB to Ethernet converter, connected to NanoPi over onboard USB hub, used to connect MuxPi to DUT in order to eliminate need of external ethernet switch
    • 2 port USB HUB - USB hub with integrated microSD card reader; downstream ports are distributed to:

      • 2xUSB-A connector
      • add-ons connector
      • USB-ETH converter
    • SD-READER - microSD card reader (part of HUB IC) connected to SD-MUX and NanoPi NEO in order to eliminate need of external one
    • SD-MUX - fundamental functionality of the whole device, multiplexer of SD-MUX card which allows to connect the card either to microSD card reader or a DUT
    • 2x 2-channel DyPers (Dynamic jumPer) - a simple switch intended to programmatically connect jumpers or push buttons on a DUT;
    • USB/UART SWITCH & ID - a block of componnets with dedicated USB connector; the block allows to control USB Vbus and ID, and allows to redirect USB data lines either to NanoPi's USB or UART

    Essential functions

    • Switching a microSD card between a DUT's microSD card slot and an onboard USB card reader
    • Flashing a microSD card using an onboard USB card reader
    • Flashing and controlling state of Samsung mobile devices over fully controlled, dedicated USB interface
    • Switching power supply for a DUT
    • Switching jumpers/buttons of a DUT in order to (re)boot/(re)configure it
    • Measuring current consumption of a DUT
    • Handling serial connection (UART) of a DUT
    • Writing EDID to a DUT over HDMI connection
    • Providing a DUT connection (UART, USB, ETH, microSD car) to remote location over ethernet
    • Interacting with a user/maintainer over a simple, bidirectional interface

    Connectivity

    • MuxPi <-> DUT:

      • Ethernet - onboard USB ETH converter
      • USB OTG - NanoPi built-in port
      • USB host - up to 3 on board USB host connectors
      • Serial (UART) interface - onboard UART controller with voltage level shifters and voltage generation
    • User <-> MuxPi:
      • Ethernet - NanoPi built-in port
      • USB OTG - NanoPi built-in port - mainly for on desk usage
      • 2-wire Serial (UART) - NanoPi built-in port - mainly for on desk usage

    MuxPi vs SD-MUX

    Although MuxPi is a successor of SD-MUX, it is a totally different kind of beast. Its main task is still the same: to help automated testing of OS binary images. However there are only three common functions of these two boards:

    • SD card multiplexing
    • controlling power of a DUT
    • USB switch (not a HUB) - switch is the same but in MuxPi it does totally differnt thing. It is used to redirect USB-M data lines either to NanoPi's USB or NanoPi's UART.

    And one function which was not present on SD-MUX board natively but would be added to them as external circuit:

    • DyPer

    The whole rest of functionalities makes MuxPi far more powerful and versatile device than SD-MUX.

    Besides the huge difference in hardware there are also two unquestionable advantages over SD-MUX:

    • user interface - SD-MUX was totally blind device. User couldn't tell in what state the device was. Hou couldn't even tell whether the devices is turned on or off. MuxPi has several LEDs, graphic OLED display and two buttons. It may look a little bit to much for such device but experience in using SD-MUX showed that operator needs information that can't be passed using just LEDs.
    • independency - SD-MUX was not a standalone device. It had to be connected to some powered USB host - usually a PC or server. MuxPi is a completely standalone device with its own microcomputer and linux operating system. It needs only an ethernet connection and a power supply.

    Hardware

    This section describes all parts of MuxPi that are a subject of interaction with a user. It describes every part that a regular user has to deal with. e.g. power supply, buttons, USB, etc.

    Connectors

    These are standard connectors of witch pins are not a subject of this description.

    image

    • POWER - 5V Power supply connector. Typical barrel receptacle 5.5/2.1 ensures that widely used, typical power adapters can be used to power the board. Power consumption of MuxPi should be less then 1A assuming no addons connected.
    • HDMI - Full-sized HDMI connector with connected only DDC channel wires, hot plug pin and GND/VCC pins. It is meant to be EDID injector into a DUT's HDMI output. It is connected to Cortex-M0 microcontroller.
    • ETH - standard RJ45 with built in LEDs and transformer. It is a connector for LAN9500A ETH<->USB converter which is connected to NanoPi through onboard USB HUB USB2640.
    • 1x USB-A - USB-A Host interface connected directly to NanoPi NEO. Power supply of this connector is not controllable by NanoPi. It is always present.
    • 2x USB-A - USB-A Host interfaces connected to NanoPi NEO through onboard USB HUB USB2640.

    NOTE: ETH and upper USB of double USB socket share the same USB channel from USB HUB. Jumpers located at the rear side of double USB connector allow to disconnect this USB from ETH and connect to add-on connector. Details on this topic are covered in jumpers section.

    image

    Pin connectors

    These connectors are custom ones so each of them are described in detail including pinout definition. Bellow image shows layout of all of these connectors. Note that connectors marked with blue colors are only for development purpose and that's why they are not described here. People interested in their pinout may find it in schematics. Also connectors for NanoPi NEO are not described in this document. You can find it here: NanoPiNEO

    image

    UART

    This is smart UART for connecting NanoPi NEO to a DUT. There is no need to use dedicated converters for particular boards because MuxPi has special level shifter which takes care for adjusting voltages of UART lines for both sides: NanoPi and the DUT. To take advantage of this shifter, pin VCC must be connected to power pin on DUT's board. This is 4-wire UART which means that it can communicate using hardware flow control.

    image

    • GND - digital ground of MuxPi board
    • N.C. - not connected
    • Vloc - local voltage - voltage may be generated internally on MuxPi if the DUT, or anything else we are connecting to, has not power pin. Nn such case voltage generator must be set to desired value and activated. Command "uart 3300" must be sent to Cortex-M0, where 3300 is desired voltage given in millivolts. The voltage range is from 0 to 5000mv. Pins Vloc an VCC must be connected eachother. Typical jumper is a perfect connector for this purpose. Vloc may be also used to power up additional converter RS232C. For example if converter to RS232C (+/-12v) must be used then it may be pwered from Vloc pin.
    • VCC - power of DUT. If dut has no such power pin then it must be connected to Vloc and vloc must be cinfgure properly as stated above.
    • DUT RX - receiver data line in the DUT - through this line MuxPi sends data to the DUT
    • DUT TX - transmitter data line in the DUT - from this line MuxPi reads data form the DUT
    • DUT CTS - Clear To Send - hardware handshake
    • DUT RTS - Ready To Send - hardware handshake

    NOTE: RX, TX, XTS, RTS are crossed on the board so you don't need to cross the wires by yourself.

    NOTE: A device powered from Vloc mustn't draw more than 50mA of current.

    EXAMPLE CONNECTION TO CONVERTER

    Below image shows how to connect UART of MuxPi to some device. In this particular case it is 4-wire RS232C converter which must be powered from external (from converter's point of view) power source. As stated above, wire cross is done on MuxPi board so cable should not be crossed. However in this image you can see cross because of strange labeling pins on the converter.

    image

    You can see in the image that Vloc and VCC are connected. In this example Vloc is used to power up the converter and bias the level shifters (VCC).

    USB-M

    This is USB connector dedicated to mobile devices from Samsung company. This connector has controllable Vbus line and also controllable ID line.

    image

    • USB D- - USB data line
    • USB D+ - USB data line
    • ID - pin controllable by MuxPi - resistor with specified value can bo connected to this pin or it may by left unconnected
    • VBUS - +5V power line. It can be switched on and off
    • GND - ground line

    This connector is an endpoint of larger entity which is dedictaed to connect to mobile devices. Thanks to its controllable Vbus and ID lines it is possible to control connected devices. It comprises of:

    • ID switch with connected 1M multi-turn potentiometer - ID can be connected to ground through potentiometer or left open. The potentiometer has 11 turns. its value can be easily set using dedicated add-on
    • Vbus switch thanks to which power can be switched on and off. This functionality is necessary to control connected device (power off, power on, download mode, etc.)
    • UART/USB switch which allows to redirect mobile's USB data lines either to NanoPi's USB or to MuxPi's DUT UART.

    All of those components are independently controlled by Cortex-M0 microcontroller. For example if there is a need to reflash smartphone the following steps needs to be taken:

    • switch off VBus
    • disconnect the battery of the mobile device - power switch of MuxPi can be used to accomplish this task
    • connect resistor (potentiometer) to ID pin - potentiometer should be set to the correct value before the whole procedure is started. The value should be valid for UART mode.
    • connect USB data lines of the mobile device to NanoPi by setting UART/USB switch to UART mode
    • connect the battery to the mobile device
    • switch on the VBus power
    • send enter key code to the serial to stop u-boot
    • send 'thordown' command to u-boot through serial connection (UART) - after this command the mobile device will switch USB data lines to USB automatically
    • connect data lines of the mobile device to USB of NanoPi by setting UART/USB switch to USB mode
    • start lthor/heimdall software to flash the device
    • after flashing is finished switch off VBus
    • disconnect the battery
    • disconnect resistor from ID pin
    • connect the battery
    • switch on the VBus
    • now the device should boot with the new binary image and USB connection can be used to run tests.

    This is an example which perfectly works with Samsung mobile devices. However it might be possible to execute similar procedure with products of other brands if they support such functions.

    NOTE: Special USB cable needs to be used as commonly available cables do not have ID pin connected. So special cable needs to be made. I do not attach schematic cable because there is nothing special about that. Micro USB connector pinout can be found on the internet and pinout of MuxPi connector is shown above. All what needs to be done is to connect pins of both connectors.

    SD Adapter

    This connector is used to connect microSD card, put into MuxPi, to a DUT. It is exactly the same connector as in SD_MUX which accepts exactly the same cables that were used for SD_MUX.

    image

    Pinout is not described here because it is a standard SD pinout and can be found easily on the internet

    Add-ons

    MuxPi can be easily extended by connecting to it add-on boards. There is one, reference add-on designed as universal board which can be good start for designing custom add-ons.

    image

    • 5V - power supply - not switchable - always present
    • 3V3 - switchable (controlled by NanoPi) 3.3V power supply
    • I2C0 SDA - I2C0 SDA line connected to NanoPi
    • I2C0 SCL - I2C0 SCL line connected to NanoPi
    • DBG UART TX - UART0 (debug) of NanoPi
    • DBG UART RX - UART0 (debug) of NanoPi
    • USB B+/-, USB A+/- USB host lines connected to NanoPi through USB HUB
    • GND - ground lines
    • N.C. - not connected

    image

    • SPI0 CLK - SPI0 clock line connected to NanoPi
    • SPI0 MOSI - SPI0 "master output slave input" line connected to NanoPi
    • SPI0 CS - SPI0 "chip select" line connected to NanoPi
    • SPI0 MISO - SPI0 "master input slave output" line connected to NanoPi
    • PI GPIO 1,2,3 - GPIO (General Purpose Input/Output) connected to NanoPi NEO. Ports PG11, PL11, PA17 respectively.
    • ST GPIO 1,2,3 - GPIO connected to Cortex-M0 microcontroller. Ports PB3, PB4, PB5 of STM32F03C6T6 respectively.
    • ADC1,2 - analog inputs connected to analog to digital converter of Cortex-M0 microcontroller. Ports PA1, PA2 respectively. Voltage range of this input is 0 to 3.3V. This lines are not buffered in any way so attention must paid when dealing with them.
    • GND - ground lines

    NOTE: PI GPIO 1 has additional special function. It is connected to Cortex-M0 Boot0 pin which enables firmware download mode during microcontroller boot. 1 - enables this mode while 0 disables it. So it is useless as GPIO when the microcontroller is being booted.

    DyPers

    Dynamic jumPers, so called DyPers, are simple switches that can act as a regular jumper or switch. It is meant to help automatization when jumpers or push buttons are used on a DUT. Excellent example are ARTIK boards. They can't be booted just by powering them on. After applying power, the user must press "Power on" button. Such requirement rules out automated testing because the device can't be booted. And that's what DyPer does. Two-wire cable needs to be soldered to pins of the button and connected to one of DyPers. Using software it can be switched on and off what simulates pressing the button. Dyper is a small, electromagnetic relay which is controllable by software. There are 2 dypers on MuxPi board. Each of them has two channels. Both channels are switched at the same time with the same command. So both of them can be on and both can be off but there is no way to turn one on and one off. At the first sight it looks like a bug but it is not. It is useful for jumpers. If for example some board needs to have 2 jumpers linked for flashing mode and 0 jumpers linked for normal operation then only one DyPer with two channels may be used. These two channels are separated galvanically so there is no worry that there will be some kind of influence.

    image

    Why electromagnetic realys instead of silicon switches? Because we don't wan't to deal with some relation of steering and operating signals.

    NOTE: DyPers can be used for other purposes e.g. power switch - it can switch 0.5A signals.

    DUT Power

    This circuitry is meant to be a hardware resetter for a DUT. This is cruel reset but sometimes it is the only way to reset some device. It is based on electromagnetic relay controlled by Cortex-M0 microcontroller. Why electromagnetic relay instead of some kind of silicon switch? Because almost all silicon switches have some influence and relation between steering and operating signals. We could use SSR relays but it is not cost effective solution.

    image

    This block does two things:

    • power switching on/off
    • current measurement

    Power switching - it can switch switch power supply up to 5A and 250VAC. One line is connected directly and one is connected through realy. SD-MUX has the same feature, however with different realy and both lines switchable. Relay on SD-MUX is bistable so quite expensive. It was important to use such relay because SD-MUX is powered only from USB port. MuxPi is powered from external power supply so this condition is no longer valid and we can use much cheaper monostable relay.

    Current measurement - It is able to measure up to -/+5A and is galvanically isolated from the rest of components thanks to use of Hall effect current sensor ACS712ELCTR-05B-T. It is connected to unswitchable power line. The current sensor is bypassed with 3 0R resistors tha can be populated if current sensor is not needed. These resistors must not be populated if current measurement is required. Current measurement was not present in SD-MUX.

    Thanks to electromagnetic realy and Hall effect current sensor, power line is galvanically separated so MuxPi can control power of any kind. It may be DC or AC, low or high voltage or polarized in any way. Of course nothing forbids connecting MuxPi's circuitry with this power line but user must be aware of such connection.

    Jumper configuration

    There are only 4 jumper on MuxPi board. Two of them were already explained.

    image

    • UART - pins Vloc & VCC - if jumped then internal voltage generator is used as voltage reference for data lines and powers up target device. If open then voltage reference for data lines comes from target device and internal voltage generator is unused.
    • USB/ETH - determines what USB data lines of one USB HUB are connected to. One downstream channel, outgoing from onboard USB HUB, is always connected to upper socket of double USB-A connector. It can be also connected to either add-on connector or onboard USB<->ETH converter. If first two pins are jumped then USB lines are connected to add-on connector. If last two pins are jumped then these lines are connected tu USB<->ETH converter. If none of the pins are jumped then the only connection is the upper socket of double connector.

      • NOTE: The upper socket of double USB-A connector must be lefty empty if USB<->ETH is selected or add-on connector is selected and something is connected to these data lines on the addon!
      • NOTE: Both jumpers must be placed in the same position!
    • VDD - if this pins are jumped then the VDD and 3V3 are always on. If this is left open then VDD and 3V3 are controlled by NanoPi. Having the voltage always one may be helpful when MuxPi is to be used without NanoPi NEO board. The best example is setting value of USB ID potentiometer. The potentiometer is located underneath NanoPi NEO so it must be removed in order to do the adjustment. But when NanoPi NEO is removed there is no way to turn on power for microcontroller. And that is the moment when VDD jumper comes into the action. Just simply connect pins with jumper and power is on. Don't forget to take of the jumper after the work is done.

      • NOTE: If there is no particular need then leave this jumper open.

    User interface

    MuxPi, in contrast to SD MUX, has quite reach user interface. It is bidirectional which means it can give some information to an operator as well as it can receive it from them.

    image

    • POWER LED - red LED indicates presence of power supply
    • SD READER LED - blue LED indicating internal SD card reader activity
    • UART VCC LED - red LED indicating presence of UART target voltage
    • LED 1 - general purpose, green LED connected directly to NanoPi NEO GPIO
    • LED 2 - general purpose, red LED connected directly to NanoPi NEO GPIO
    • RGB1, RGB2 - two general purpose, RGB LEDs connected to Cortex-M0 microcontroller. Fully controllable by NanoPi NEO. These are WS2812B LEDs with builtin controller.
    • 128x32 OLED Display - general purpose 0.96" yellow, graphic display. Connected to Cortex-M0 and fully controllable by NanoPi NEO.
    • BUTTON 1/2 - two general purpose buttons connected to Cortex-M0 microcontroller. Fully accessible in NanoPi NEO.
    • NanoPi NEO - not shown in the above picture. Keep-alive blue LED, mounted on NanoPi NEO board.

    With this UI an operator can be informed about current status of MuxPi and the operator can gently disturb MuxPi in order to perform some actions. Functions of UI are fully customizable. Everything can be controlled from NanoPi NEO. Currently there is only one specific press combination of buttons reserved for specific add-on. This add-on is designed to ease setting of USB ID potentiometer. It must be done with NanoPi NEO taken off the board because the potentiometer is located underneath. To access functionality of this add-on user has to press both buttons and keep them pressed for at least 5 seconds. And this is the only hard coded UI currently exists.

    ADD-ONs

    Add-ons are meant to:

    • add functionality in the future, which was unknown during design process of MuxPi
    • add functionalities very rarely used (e.g. addon for USB ID potentiometer adjusting) - placing them on the board would be a waste of place.

    A sample add-on was designed to provide board template for users specific boards.

    image

    This add-on contains:

    • LEDs connected to:
      • 5V and VDD indicating power presence
      • PI GPIO 1-3 indicating state of 3 NanoPi NEO GPIOs
      • ST GPIO 1-3 indicating state of 3 Cortex-M0 GPIOs
    • UART0 (NanoPi NEO) to USB converter
    • lots of THT pads to ease soldering new circuits

    Its dimensions are as big as possible with special cutouts for power plugs.

    Software

    Muxpi contains 3 programmable units:

    • NanoPi NEO - the most advanced one. It is Linux based microprocessor.
    • Cortex-M0 microcontroller - this one is responsible for low level actions and is only a slave for NanoPi NEO.
    • ATtiny10 - a small AVR microcontroller which is used only a watchdog for NanoPi NEO.

    All of the above units need software.

    NanoPi NEO needs some distribution of linux, burned on micro SD card. There are ready to use distributions like ubuntu core. There is also a small distribution dedicated to MuxPi. This distribution is provided by the same team which designed MuxPi. <TODO: here should be a link to this distribution but there is no public place to store it and make it available to everyone>.

    Cortex-M0 needs a firmware which is available in repo <TODO: link to repo>. There is the whole source code that can be built according to instructions that can be found in INSTALL file. There are also ready to flash binaries that are useful when a user does not wan't to build one on their own. There are two ways to flash the microcontroller:

    • flash it using some kind of SWD interface
    • flash it from NanoPi NEO

    Second solution is preferred as there is no single hardware nor software tool required. All what needs to be done is to download the binary and execute flash_firmware script with the file name as an argument. It is true only if distribution of NanoPi NEO contains proper software. To be sure just use MuxPi dedicated distribution.

    ATtiny10 microcontroller also needs firmware. Unfortunately this one needs special interface e.g. like this: http://www.fischl.de/usbasp/ or any other interface which is able to flash this microcontroller over TPI interface. Also for this microcontroller there is a full source code and ready to flash binaries. If watchdog functionality is not desired then instead of flashing firmware into ATTiny, R21 can be removed form MuxPi board. In such situation NanoPi NEO will always be powered on.

    image

    Controlling MuxPi

    All MuxPi's features are accessible on NanoPi NEO. Most of them are accessible through Cortex-M0 microcontroller.

    Features accessible directly on NanoPi:

    • switch on/off MuxPi power supply (except power supply for itself)
    • turn on/off 2 one-color LEDs
    • set working mode of Cortex-M0 microcontroller

    Features accessible through Cortex-M0:

    • switch on/off power supply for DUT
    • measure current consumption of DUT
    • switch on/off DyPers
    • switch SD-MUX to DUT or onboard card reader
    • set voltage for external (DUT) UART
    • switch on/off Vbus for USB-M
    • switch on/off resistor for USB-M ID pin
    • redirect USB-M data lines either to UART or USB of NanoPi
    • serve EDID data through HDMI connector
    • set colors of 2 RGB LEDs
    • set OLED display data
    • read keys
    • reset watchdog

    Direct NanoPi features

    Features accessible directly on NanoPi are handled by toggling proper GPIOs of NanoPi. These GPIOs can be handled in several ways but the simplest one is by using 'matrix' tools/library from Friendly Arm. 'matrix-gpio_out' binary is present on os image dedicated to MuxPi. It takes two arguments:

    • GPIO number - it is a number of physical pin (look at NanoPi NEO pinout
    • GPIO state:
      • 0 - low voltage - near 0V
      • 1 - high voltage - near 3.3V

    Set '1' to:

    • turn on power supply for MuxPi
    • turn on LEDs
    • enable flashing mode in Cortex-M0 microcontroller

    Set '0' to:

    • turn off power supply for MuxPi
    • turn off LEDs
    • enable firmware execution mode in Cortex-M0 microcontroller

    examples:

    matrix-gpio_out 15 1 # This command turns on power for MuxPi.
    matrix-gpio_out 15 0 # This command turns it off.
    matrix-gpio_out 7  1 # This command sets Cortex-M0 microcontroller to flashing mode.
    matrix-gpio_out 15 1 # This command turns on power for MuxPi and and powers up the microcontroller

    Now the microcontroller is ready to accept firmware through serial port. This port is connected to /dev/ttyS2 serial port on NanoPi. The microcontroller can be flashed using stm32flash utility. Its binary can be found on dedicated OS image for MuxPi. After flashing is done the microcontroller must by turned off and turned on with boot mode set to '1'.

    matrix-gpio_out 15 0 # This command turns off power for the microcontroller
    matrix-gpio_out 7  0 # This command sets Cortex-M0 microcontroller to execution mode.
    matrix-gpio_out 15 1 # This command powers up MuxPi.

    A script performing the whole process is located on MuxPi's dedicated OS image.

    Pin <-> function mapping table:

    Pin number (for cmd) Function Note
    1 GPIO 2 Pin no. 6 of single-row connector
    2 GPIO 3 Pin no. 7 of single-row connector
    7 GPIO 1 / CM-0 BOOT
    12 LED 1
    13 LED 2
    15 Power

    NOTE Pin 1 and 2 are not the real pins of NanoPi NEO. These pins represents pin 6 and 7 of the second, single row, connector. It is because of limitations of matrix library which does not handle the connector.

    Features accessible thorugh Cortex-M0

    The microcontroller is connected to NanoPi NEO with UART. This UART is connected to third UART of NanoPi - /dev/ttyS2. The port is configured to 115200,8,N1 and cannot be changed without modification of the firmware. The protocol is text based, simple and human readable. Each command has to be ended with 'n' or 'r' character. Each command is confirmed with 'OK' string or error string. Commands can be sent in several ways, e.g. echo or printf to /dev/ttyS2 Human can do it in some terminal program like screen or minicom. Just simply write a command and hit 'Enter'. Example:

    version
    MuxPi firmware v0.1
    OK

    Above example shows execution of command 'version' and returned response.

    To get this semi console running:

    • power up Cortex-M0: 'power.sh on'
    • start screen: screen /dev/ttyS2 115200,cs8,ixon,ixoff

    Now you can enter commands and get their results. There is 'help' command which displays all accessible commands with short description. Bellow list contains current set of commands:

    help
          help --- This help
       version --- Display version of the firmware
          echo --- Get (no arguments) or set ('on' or 'off') echo on serial "console": echo [on|off]. The default value is on.
         power --- Get (no arguments) or set ('on' or 'off') or switch off and on ('tick') power supply for DUT: power [on|off|tick]
          hdmi --- Get (no arguments) or set ('on' or 'off') HDMI HOTPLUG pin: hdmi [on|off]
         dyper --- Get (no second argument) or set ('on' or 'off') DyPer state: DYPER 1|2 [on|off]
           mux --- Connect microSD card to external connector (DUT) or card reader (TS): mux [DUT|TS]
           dut --- Connect microSD card and power to DUT: dut
            ts --- Connect microSD card and power to TS: ts
           led --- Get (no second or third argument) or set ('R G B') color of led (1 | 2), ex: led 1 255 0 255
           clr --- Clear the OLED display
          text --- Print text on the OLED display: text x y color content
          draw --- Draw an object on the OLED display: draw object x1 y1 [x2 y2], objects are:
                   - point x y color - draws one point at given coordinates
                   - line x1 y1 x2 y2 color - draws line between given coordinates
                   - rectangle left top width height color - draws line between given coordinates
                   - circle x y radius color - draws line between given coordinates
                   color must be 'on', 'off' or 'inv'
           adc --- Print current adc value of all (if no arguments are given) or one specified channel, ex: adc 1
       voltage --- Print current voltage [mV] of all (if no arguments are given) or one specified channel, ex: voltage 1
       current --- Print current current [mA] being consumed by DUT
         lthor --- Get (no second argument) or set state of lthor control signals:
                   - lthor switch [usb|uart] - redirect DUT's USB wires to NanoPi's 'usb' or 'uart'
                   - lthor id [usb|uart] - switch DUT's USB to 'usb' or 'uart' mode
                   - lthor vbus [on|off] - switch DUT's VBUS 'on' or 'off'
                   - lthor combo [usb|uart] - make DUT and MuxPi USB work in 'usb' or 'uart' mode - no get function
           key --- Get current state of given key or both if no key number is given: key [1|2]
          uart --- Get current value of UART voltage or set if new value is given [in millivolts]
    OK
    

    Connecting tested devices

    This section describes methods of connecting to a device which is to be tested using MuxPi. There are several methods of such connection. All depends on DUT's features and interfaces. DUT (Device Under Test) can booted from:

    • Ethernet - MuxPi can act as remote file system server
    • SD - MuxPi acts as a SD card thanks to its SD-MUX capability
    • USB - here two scenarios are possible:
      • NanoPi NEO implements Mass Storage on its USB OTG port which is connected to DUT's USB port
      • SD adapter is put into USB SD card reader which is put into DUT's USB port. This one is much easier to do and doesn't wear NanoPi's SD card.
    MuxPi can be even used to flash/boot and test microcontrollers. Flashing can be done via GPIOs, some external (probably USB) interface, UART or any other interface. It depends on microcontroller's flash/boot capabilities. Thanks to open hardware and open source, microcontroller's firmware and NanoPi's software can be modified to adjust MuxPi to particular needs.