TE0720 CPLD

Overview

A Lattice XO2-1200 CPLD (U19) is used as a System Management Controller. The SC is responsible for power sequencing, reset generation and zynq initial configuration (mode pin strapping). Moreover, some on-board ICs are connected to the SC that provides level shifting. The SC wakes up when the 3.3V input power rises above 2.1V (VIN voltage is not needed). The SC can turn on or off all of the other supplies on the module (except in no power sequencing mode when the 1.0V and 1.8 V supplies are forced to start immediately when power is applied to the module).

System Controller (SC)  was designed to allow ZYNQ PS system to access module special functions as early as possible without reducing the number of MIO pins that are fully user configurable.This early communication channel is done using MIO52 and MIO53 pins that are used also as ethernet PHY management interface for the on-board gigabit PHY. In order to simplify the boot process and reduce the number of time the PS peripherals need to be configured or re-initialized SC uses the same protocol on MIO52/MIO53 as the Gigabit PHY itself. This means that FSBL configures all peripherals to their final function, allocating MIO52 and MIO53 as ethernet MDIO interface. SC controller appears as "Virtual Ethernet PHY" on the MDIO bus of PS ethernet 0 interface. This interface is already available when Zynq PL Fabric is not configured. It would have been possible to use I2C protocol on MIO52/MIO53 but in such case some multiplexing would be needed to choose between two protocols, also it would be needed to change the peripheral mapping after first init by the FSBL. For use cases where ethernet PHY on TE0720 is not used at all, it is still possible to configure SC with design that implements I2C protocol on MIO52/MIO53 pins.For most use cases the only need to use this interface is access to MAC address info, this is normally done by u-boot loader that fetches the MAC address bytes and sets its environment variables accordingly. Linux image will then also be started so that the MAC address from EEPROM is used for ethernet 0 physical interface.

Feature Summary

• Power Management

• Reset Management

• JTAG Routing

• Boot Mode

• User IO

• LED

• MDIO Interface
• UNI/O MAC access
• Watchdog Timer
• I2C

Firmware Revision and supported PCB Revision

See Document Change History

Product Specification

Port Description

Functional Description

To access and control the following functions it must be accessed CR registers. For more information about how to access these registers refer to CR registers access methods

JTAG

JTAG signals routed directly through the CPLD to FPGA. Access between CPLD and FPGA can be multiplexed via JTAGENB pin of CPLD (B9) (logical one for CPLD, logical zero for FPGA). This pin is connected to B2B (JM1-pin 89) directly. On the carrier board can be this pin enabled or disabled with a dip switch.

Boot Mode

Boot mode can be set either by hardware (dip-switch) on the carrier board or by Linux console. Even after booting you can change the boot mode. After changing the boot mode FPGA is restarted automatically by CPLD. To change boot mode a state machine  continuously monitors the corresponding register (CR4[15:8]) that can be change via MDIO interface between CPLD and FPGA. After changing CR4[15:8] according to desired boot mode , CPLD will reset FPGA.

In the following table the corresponding commands are shown:

phytool write eth0/0x1A/12 0x9100

XEmacPs_PhyWrite(&Emac, 0x1A,  12, 0x9100)

phytool write eth0/0x1A/12 0x9300

XEmacPs_PhyWrite(&Emac, 0x1A,  12, 0x9300)

phytool write eth0/0x1A/12 0x9200

XEmacPs_PhyWrite(&Emac, 0x1A,  12, 0x9200)

Watchdog Timer

As of PCB revision 04 there is a watchdog timer chip (BD39040MUF-CE2) on the module. A state machine monitors register CR3[15:8]. If the value of the register is 0xA5, WDT is activated. First state machine assumes that WDT chip is assembled on the board, therefore it tries to activate hardware WDT at the beginning. If there is no WDT chip on the board, for example the module PCB is revision REV03 or older, software WDT will be  activated. In the following is shown WDT state machine diagram:

Hardware WDT

New PCB revision of TE0720 (Rev04) consists of watchdog timer chip (BD39040MUF-CE2). There are four pins between this chip and CPLD. 

Watchdog Timer (WDT) monitors FPGA’s operation by detecting the time from both rise and fall edge of WDIN. BIST is a self-test of chip to see if comparators of the WDT chip work correctly. If BIST result is abnormality, WDT does not work and XRSTOUT is kept low.Once BIST ends without any errors, XRSTOUT becomes High. WDT is activated when WDOUT=High, and both WDEN and XRSTOUT have to be High in order to get WDOUT to be High.  As long as the duty of WDIN clock is kept within “Trigger open window”, WDT does not detect any errors and  XRSTOUT stays at High. WDIN input signal is ignored when WDOUT=Low. WDT is activated when WDOUT=High, and both WDEN and XRSTOUT have to be High in order to get WDOUT to be High.

Input clock of hardware WDT is generated in FPGA (pin K20) and forwarded by X6 ( CPLD pin) to WDIN pin of WDT chip. The hardware WDT will be activated , if WDT chip exists on the board and the following command in linux console be executed:

"phytool write eth0/0x1A/7 0xB600"

If WDT chip does not exist on the board by executing this command software WDT will be activated automatically. In this case input clock of WDT will be K20 pin of FPGA that connected to X6 pin of CPLD. The following table shows all cases for WDT:

Software WDT

Software WDT can be activated by executing the following instruction in linux console:

"phytool write eth0/0x1A/7 0xA500"

CR[14] bit is same as a clock input pin for software WDT. If this bit after enabling software WDT will not be toggled correctly, FPGA will be reseted. 

If the software WDT is activated and the generated clock is fed to WDT input clock , it will not be reset the board (WDT_RST signal low). But if the generation of this clock is stopped , the board will be reset (WDT_RST signal high) after a period of time depending on the WDT_time (CR4[7:0] register value).

To test Watchdog timer can be fed a clock signal to WDT clock input. The following shell script file generates a clock for WDT input clock. This file must be copied as init.sh to the SD card additionally. This shell script file will be executed by booting the board and generates the WDT input clock automatically. As long as 1 key and enter key is not pressed, the WDT clock will be generated and subsequently the board will not be reset.  But if generation of clock signal be stopped, the board will be reset after a period of time. Note that WDT must already be activated in FSBL code.

#WDT test
#!/bin/sh
echo "Starting the WDT Clock"
sleep 1
while :
do
    phytool read eth0/0x1A/5
    phytool write eth0/0x1A/5 0x4041
    sleep 0.5
    phytool read eth0/0x1A/5
    phytool write eth0/0x1A/5 0x0041
    sleep 0.5
	read -r -t 0.1 b
	echo "Press 1 to exit!"
    if (( b == 1 )) ; then
      break
    fi
done
printf "\Quit.......................\n\n"

WDT adjustment

Watchdog timer is an added option in the CPLD code. To control and to use watchdog timer correctly , it must be written correct values in the related CR registers.

For example to access these registers in FSBL code it can be used the following instruction:

• Status = XEmacPs_PhyWrite(&Emac, 0x1A, 7, 0xA500); if(Status != XST_SUCCESS){ return XST_FAILURE; } →  To enable software WDT

• Status = XEmacPs_PhyWrite(&Emac, 0x1A, 7, 0xB600); if(Status != XST_SUCCESS){ return XST_FAILURE; } →  To enable hardware WDT

• Status = XEmacPs_PhyWrite(&Emac, 0x1A, 7, 0x0000); if(Status != XST_SUCCESS){ return XST_FAILURE; } →  To disable hardware /software WDT  WDT

• Status = XEmacPs_PhyWrite(&Emac, 0x1A, 12, 0x001F); if(Status != XST_SUCCESS){ return XST_FAILURE; } → To adjust desired time for WDT  

Another way to access the related registers for WDT is to use phytool command. It must be added the ethtool package in Linux. To add this package it must be chosen in petalinux configuration for rootfs this option. The path in petalinux rootfs is: Filesystem packages/console/network/ethtool

The phytool instruntion format is :

• Phytool read device/addr/register

• Phytool write device/addr/register <value>

To write desired value in the related WDT registers for example can be written the following instructions in Linux console:

• phytool write eth0/0x1A/7 0xA500 → Software WDT enable

• phytool write eth0/0x1A/7 0xB600 → Hardware WDT enable

• phytool write eth0/0x1A/7 0x0000 → Software/ Hardware WDT disable

• phytool write eth0/0x1A/12 0x001F → Adjusted software WDT time. It depends on the period of the CPLD clock.

• phytool write eth0/0x1A/5 0x4000 → To set the WDT input clock of software WDT high

• phytool write eth0/0x1A/5 0x0000 → To set the WDT input clock of software WDT low

Reset

Zynq will be reset, when it occures one of the following conditions:

Extra Reset

The board can also be reset through software.

For example the following instructions can reset the board:

• phytool write eth0/0x1A/7 0xE500 → Extra reset enable

• phytool write eth0/0x1A/5 0x8000 → Reset the board

It can be activated this option in FSBL code too:

• Status = XEmacPs_PhyWrite(&Emac, 0x1A, 7, 0xE500); if(Status != XST_SUCCESS){ return XST_FAILURE; }

Serial EEPROM

The seial EEPROM (U17) is used to save  MAC addess.  The MAC_IO pin of EEPROM uses UNI/O interface to communicate with CPLD. The connection between EEPROM chip and CPLD depends on the value of XIO4.

CryptoAuthentication

The CryptoAuthentication chip (U10) is a high-security hardware authentication device that allows use in many application same as checking user password. This device can communicate with 1MHZ I2C interface,single-wire interface or UART.

UART

I2C to GPIO block

This subsystem provides 32-bit (4 x 8-bit) of general purpose parallel input and output (I/O) expansion for the I2C bus protocol.  Address of this module is 0x20. This module contains  four 8-bit registers for reading (GPIO_input[7:0] to GPIO_iput[31:24]) and four registers for writing (GPIO_output[7:0] to GPIO_output[31:24]) separately with 0x00 to 0x03 address. These registers can be accessed with I2C commands in linux console or with i2c functions in FSBL code. To access these registers the following commands in linux console can be used:

• To see the i2c bus addresses :                                     i2cdetect -y -r 1    

• To read register of i2c to GPIO module:                            i2cget -y 1 0x20 <register address>     

• To write data in a register of i2c to GPIO module:                 i2cset -y 1 0x20 <register address> <data>
  
  

The MIO7 pin is connected to third bit of GPIO input of the I2C to GPIO subsystem (GPIO_input(2)) .To test the I2C to GPIO  the MIO7 state  can be changed  and the value of the first register (register address 0x00) can be monitored. The initial value of this register depends on the CPLD firmware and can be variable. In the following example the initial value of this register is equal to 0x39. That means that initial value of MIO7 is zero. Now set MIO7 to one and read the value of the first register with address 0x00 again. It should be equal to 0x3D. LED1 (Green LED) glows, if MIO7 is set high:

• To read the first register of the subsystem:

  • i2cget -y 1 0x20 0x00                           → For example here is equal to 0x39. Here 0x20 is device address and 0x00 is register address.

• To set MIO7 to one: 

  • cd /sys/class/gpio/

  • echo 913 > export

  • echo out > gpio913/direction

  • echo 1 > gpio913/value

• To read the first register of the subsystem again:

  • i2cget -y 1 0x20 0x00                          → It should be equal to 0x3D.
    
    

The subsystem I2C to GPIO port mapping is according the following table:

GPIO input bit mapping:

UNI/O MAC read block

UNI/O bus is a low speed serial interface for embedded systems that requires only one logic signal SCIO (Serial Clock, Data Input/Output). By using Manchester encoding techniques, the clock and data are combined into a single, serial bit stream (SCIO),where the clock signal is extracted by the receiver to correctly decode the timing and value of each bit. The serial EEPROM (U17) interface is UNI/O. The UNI/O bus uses a master/slave configuration. In this system the serial EEPROM chip is slave and a UNI/O subsystem in CPLD works as master. Both master and slave can operate as transmitter or receiver, but the master device determines which mode is active.The UNI/O MAC read block in CPLD reads the MAC address from serial EEPROM chip during power-on.

Multiplexing uio data output between uio-id and uio-io:

SC Pins to B2B

SC Pins to FPGA

NOSEQ Pin

This is a dedicated input that forces the module's 1.0V and 1.8V supplies to be enabled if high. This pin has a weak pull-down on the module. If left open the module will power up in normal power sequencing enabled mode. This pin is 3.3V tolerant. This pin is also connected to the System Management Controller. The SC can read the status of this pin (it can be detected if the module is in power sequencing enabled mode). The SC can also use this pin as output after normal power on sequence.

No Sequencing mode

If the module is powered from a single 3.3V supply and power sequencing is disabled, then NOSEQ pin should be powered from the main 3.3V input. That is VIN, 3.3Vin and NOSEQ should all be tied together to the input 3.3V power rail. Sequencing mode should not be used if VIN is not 3.3V.

Normal mode

For normal operation leave NOSEQ open or pull down with a resistor.

Normal mode with user function on NOSEQ

NOSEQ can be used as an output after boot. NOSEQ must be low when 3.3V power is applied to the module. Common usage is an LED connected between NOSEQ and GND. The mapping of NOSEQ pin can be changed by CR1 register. The CR1 register is control register of MDIO slave interface that its content can be changed with  FSBL code, uboot command or in linux console directly.

SC MDIO Interface

Most registers and functions are available via ETH PHY Management interface (MIO pins 52 and 53).

Address

Register Overview

To adjust desired boot mode in linux console or in FSBL code are used registers CR3(register7), CR4(register12) , CR5 and register4.  These registers are used for communication  between user, CPLD and FPGA. The format of these registers is shown in the following tables:

CR3 can be written by user: 
phytool write eth0/0x1A/7 <desired valude>

CR4 can be written by user. For example:
phytool write eth0/0x1A/12 0x9300 → To change boot mode in linux console

Register CR1

Register CR2

Register CR3

Register CR4

Register SR1

Register Details

Register CR1

The mapping of LED1(Green) , LED2(Red) and NOSEQ pin depends on the value of CR1 register.

Register CR2

The mapping of CPLD IOs (XIO4,XIO5,XIO6 and XCLK) that are connected directly with FPGA, can be changed using CR2 register.  

Register CR3

Register CR4

Note that the time of WDT depends on WTD_time register and the CPLD internal oscillator clock frequency. Default value for CR4 is 0x0000.

Register SR1

On-board LEDs

There are 3 on-board LEDs, with two of them connected to the System Management Controller and one to the Zynq PL (Done pin).

LED Status Codes

LED1 Green

This LED is mapped to MIO7 after power up. After the Zynq PS has booted it can change the mapping of this LED. If SC can not enable power to the Zynq then this LED will remain under SC control. It is available to the user only after the power supplies have stabilized and the POR reset to the Zynq is released. If softwarte watch dog timer is activated this LED will be assigned to the 7th bit of the counter of watch dog timer. By activating hardware WDT this LED will assign input clock of FPGA (Pin K20- CPLD pin X6).

LED2 Red

This LED is used to show various signal or port states. The function of this LED can be changed by CR1 register.

LED3 Green (FPGA Done)

This green LED is connected to the FPGA Done pin which has an active low state. As soon as the Zynq is powered and the 3.3V I/O voltage is enabled, this LED will illuminate. This indicates that the Zynq PL is not configured. Once the Zynq PL has been configured the LED will go off.

During normal operation when the Zynq PL has been configured, the LED can be controlled from the FPGA fabric. Control of the LED in a user design requires the use of Xilinx startup primitive rather than a normal I/O primitive. If the startup primitive is not used then the LED will go off after configuration and remain off irrespectively of the user design.

This LED can not be controlled by the SC. If green LED3 does not light up at least for short time at power then there is major problem with power supplies, FPGA core and aux voltages may be missing.

CR registers access methods

System Controller can be accessed as PHY with address 0x1A on the ETH0 Management bus (MIO pins 52, 53). PHY at address 0x00 is the ETH0 onboard ethernet PHY Marvell 88E1512. PHY at address 0x1A is the System Controller. OUI 0x7201 should be decoded as Model TE0720-01. Model 0x01 is Assembly option. Rev 0x00 is the firmware major revision for the System Controller (Rev 0 is the initial version). The CR registers have individual number to be accessed in FSBL code or Linux console. These numbers are defined in mdio_slave_interface subsystem in CPLD VHDL code. Refer to SC registers to see the table of CR registers.

The CR registers can be accessed in three methods. It can be used u-boot functions , FSBL code or phytool command in linux console to access these registers.

FSBL code

It is possible to access the CR registers in FSBL code. The following functions are used to write or read these resgisters.

• LONG XEmacPs_PhyWrite(XEmacPs *InstancePtr, u32 PhyAddress, u32 RegisterNum, u16 PhyData) → To write in CR registers

• LONG XEmacPs_PhyRead(XEmacPs *InstancePtr, u32 PhyAddress, u32 RegisterNum, u16 *PhyDataPtr) → To read CR registers

Note that to access this registers in FSBL code it must be written the following instruction before above commands: 

• Mac_Config = XEmacPs_LookupConfig(XPAR_PS7_ETHERNET_0_DEVICE_ID); if(Mac_Config == NULL) { return XST_FAILURE; }

• Status = XEmacPs_CfgInitialize(&Emac, Mac_Config, Mac_Config->BaseAddress); if(Status != XST_SUCCESS){ return XST_FAILURE; }

For example to write 0x0077 in CR1 register the following instruction is used: 

• XEmacPs_PhyWrite(&Emac, 0x1A, 5, 0x0077);

Note that the CR register names are CR1, CR2 , CR3 and CR4. But these registers are named in FSBL code register5, register6, register7 and register12 subsequently. CPLD revision,Boot mode,watchdog timer status and other features of the board will be shown by FSBL code  while booting.The format of these information are shown in the following:

U-boot

Communication between Zynq and CPLD chip in mdio bus can be established anytime when ETH0 and management interface are enabled also before FPGA PL Fabric is configured too. 

To write a value into CR registers or to read one of them the following instructions can be used:

• mii read <addr> <reg>

• mii write <addr> <reg> <data>

Module identification code can be read with the following  u-boot command in  u-boot :

• zynq-uboot> mii read 0x1a 0x02   → For TE0720 =  0x01C8

For example to read CR4 register the following instruction can be written in U-Boot command console:

• zynq-uboot> mii read 0x1A 0x0C

For example to write 0x0077 in CR1 can be written:

• zynq-uboot> mii write 0x1A 5 0x0077

LED1 and LED2 will be switched on.

Linux

It is possible to write into CR registers and to read these registers  in Linux console directly. To access the CR registers it must be added ethtool package , while linux image file is generated. To activate this option in petalinux this package must be chosen in configuration of rootfs in petalinux. The path for this package is:   Filesystem packages/console/network/ethtool
If this package is installed , phytool command can be used to access the CR registers. Phytool command format is: 

• phytool read device/addr/register

• phytool write device/addr/register <value>

For example to switch on LED1 and LED2 it must be written 0x0077 value in the register CR1:

• phytool eth0/0x1A/5 0x0077

To switch off these LEDs execute this instruction: 

• phytool eth0/0x1A/5 0x0066

Reading MAC address

It can be read MAC-address automatically. Customized u-boot reads MAC address and stores it in environment variables as required. Setting up MAC Address for Linux involves dynamic rewrite of FDT, this is done with u-boot script that starts Linux.
To read MAC address automatically, the following steps must be implemented:

In the FSBL code it must be written the following code additionally. This c file can be found in the following path: \test_board\sw_lib\sw_apps\zynq_fsbl\src\te_fsbl_hooks_te0720.c
For more information refer to TE0720 test board

u32 TE_FsblHookBeforeHandoff_Custom(void)
{
...
Mac_Config = XEmacPs_LookupConfig(XPAR_PS7_ETHERNET_0_DEVICE_ID); if(Mac_Config == NULL) { return XST_FAILURE; }
Status = XEmacPs_CfgInitialize(&Emac, Mac_Config, Mac_Config->BaseAddress); if(Status != XST_SUCCESS){ return XST_FAILURE; }
/*
* Read out MAC Address bytes
*/
Status = XEmacPs_PhyRead(&Emac, 0x1A, 9, &rval16); if(Status != XST_SUCCESS){ return XST_FAILURE; }
mac_addr[0] = (unsigned char)(rval16 >> 8); 
mac_addr[1] = (unsigned char)(rval16 & 0xFF);
Status = XEmacPs_PhyRead(&Emac, 0x1A, 10, &rval16); if(Status != XST_SUCCESS){ return XST_FAILURE; }
mac_addr[2] = (unsigned char)(rval16 >> 8); 
mac_addr[3] = (unsigned char)(rval16 & 0xFF);
Status = XEmacPs_PhyRead(&Emac, 0x1A, 11, &rval16); if(Status != XST_SUCCESS){ return XST_FAILURE; }
mac_addr[4] = (unsigned char)(rval16 >> 8); 
mac_addr[5] = (unsigned char)(rval16 & 0xFF);
...

/*
* Write MAC Address to OCM memory for u-boot to import!
*
*/

//strcpy(0xFFFFFC04, "ethaddr=00:0a:35:00:00:05\n" );
#ifdef UBOOT_ENV_MAGIC
Xil_Out32(UBOOT_ENV_MAGIC_ADDR, UBOOT_ENV_MAGIC); // Magic!
MacToUbootEnvironment((char*)UBOOT_ENV_ADDR, mac_addr);

/*
* Set MAC Address in PS7 IP Core registers
*/
Status = XEmacPs_SetMacAddress(&Emac, mac_addr, 1); if(Status != XST_SUCCESS){ return XST_FAILURE; }
...
}

Add the following definition in petalinux-configuration platform-top header file:

#define CONFIG_PREBOOT    "echo U-BOOT for petalinux;echo importing env from FSBL shared area at 0xFFFFFC00; if itest *0xFFFFFC00 == 0xCAFEBABE; then echo Found valid magic; env import -t 0xFFFFFC04; fi;setenv preboot; echo; dhcp"

• The platform-top.h file can be found in the following path: \petalinux\project-spec\meta-user\recipes-bsp\u-boot\files

• The Zynq SoC reads the MAC address from EEPROM by CPLD during power-on and copies this data in OCM (On-chip Memory). After that either in Linux or Uboot console MAC address can be accessed.

Appx. A: Change History and Legal Notices

Revision Changes

• changes REV06 to REV07
  • Added matched functions for WDT Chip BD39040MUF-CE2

  •  PG_ALL pin pulled up.                       

  • User can activate WDT as before.

  • If no WDT chip on the board, hardware WDT will be switched automatically on software WDT with PL clock input (X6 pin of CPLD and K20 of FPGA).

  • If no WDT chip on the board, software WDT will work with CR1(14) clock input as before.

  • If WDT chip on the board, hardware and software WDT work separately with PL input clock (X6 pin) for hardware WDT and CR1(14) as input clock for software WDT.

  • For software WDT : phytool write eth0/0x1A/7 0xA500

  • For hardware WDT : phytool write eth0/0x1A/7 0xB600

  • Using CR5[15:14] to save the WDT status ("00" WDT deactive, "01" Hardware WDT, "10" Software WDT, "11" No WDT chip on the board, software WDT with PL clock input)

  • Using Register4 of mdio_slave_interface to see WDT status via FSBL code (first test in vivado 20.2 and vivado 21.2) or following instruction in linux: phytool read eth0/0x1A/4 

  • Boot mode configuration via MDIO interface (phytool)

  • PGOOD pin is used as boot mode selector pin. 

  • NOSEQ pin is used as tristate via i2c interface.

  • Reseting the FPGA after boot mode configuration

  • Matched to FSBL code to show all informations while booting in linux console. For example Boot mode, pudc state ...

  • Monitoring CR4[15:8] and CR5[10] continuously, to implement a state machine for boot mode configuration correctly.

  • Using CR4[15:12] as control bit to reset FPGA

  • Using CR4[9:8] as boot mode configuration , if the FPGA is not restarted still via soft reset.

  • Defining a new input register for mdio_slave_interface (CR5)

  • Using CR5[9:8] as boot mode configuration, if the FPGA is restarted already via soft reset.

  • Using CR5[10] to monitor , if the FPGA is restarted already via soft reset.

  • Using Register4 to read the generic parameters and other parameters via FSBl code or phytool command in linux : Phytool read eth0/0x1A/4

  • Using i2c_slave.vhd instead of I2C_to_GPIO.v   

  • Changing Firmware Register MDIO_SL_REGISTER_4_CONTENT to CPLD_REVISION register.  

• changes REV05 to REV06

  • Generic options: PUDC and Boot Mode

  • MIO7 Pullnone

  • Adding internal en_3v3_int

  • JTAG C_* high impedance until 3.3VOUT can be high

  • Boot mode pins are GND or high impedance until en_3v3_int are high

  • MIO14,15 high impedance until en_3v3_int are high

  • JTAG time constraint correction

  • JTAG drive line adjustment

  • Bugfix I2C to GPIO module (I2C_to_GPIO.v)

  • Changed Firmware Identifier to REV06

• changes REV04 to REV05:

  •  0.05 watchdog

• changes REV03 to REV04:

  • NA

• changes REV02 to REV03:

  • NA

• changes REV01 to REV02:

  • added deglicht for EN1 and RESIN inputs

  • added VCORE ON when 3.3 OK signalled

Document Change History

To get content of older revision  got to "Change History"  of this page and select older document revision number.

Legal Notices

Data Privacy

Please also note our data protection declaration at https://www.trenz-electronic.de/en/Data-protection-Privacy

Document Warranty

The material contained in this document is provided “as is” and is subject to being changed at any time without notice. Trenz Electronic does not warrant the accuracy and completeness of the materials in this document. Further, to the maximum extent permitted by applicable law, Trenz Electronic disclaims all warranties, either express or implied, with regard to this document and any information contained herein, including but not limited to the implied warranties of merchantability, fitness for a particular purpose or non infringement of intellectual property. Trenz Electronic shall not be liable for errors or for incidental or consequential damages in connection with the furnishing, use, or performance of this document or of any information contained herein.

Limitation of Liability

In no event will Trenz Electronic, its suppliers, or other third parties mentioned in this document be liable for any damages whatsoever (including, without limitation, those resulting from lost profits, lost data or business interruption) arising out of the use, inability to use, or the results of use of this document, any documents linked to this document, or the materials or information contained at any or all such documents. If your use of the materials or information from this document results in the need for servicing, repair or correction of equipment or data, you assume all costs thereof.

Copyright Notice

No part of this manual may be reproduced in any form or by any means (including electronic storage and retrieval or translation into a foreign language) without prior agreement and written consent from Trenz Electronic.

Technology Licenses

The hardware / firmware / software described in this document are furnished under a license and may be used /modified / copied only in accordance with the terms of such license.

Environmental Protection

To confront directly with the responsibility toward the environment, the global community and eventually also oneself. Such a resolution should be integral part not only of everybody's life. Also enterprises shall be conscious of their social responsibility and contribute to the preservation of our common living space. That is why Trenz Electronic invests in the protection of our Environment.

REACH, RoHS and WEEE

REACH

Trenz Electronic is a manufacturer and a distributor of electronic products. It is therefore a so called downstream user in the sense of REACH. The products we supply to you are solely non-chemical products (goods). Moreover and under normal and reasonably foreseeable circumstances of application, the goods supplied to you shall not release any substance. For that, Trenz Electronic is obliged to neither register nor to provide safety data sheet. According to present knowledge and to best of our knowledge, no SVHC (Substances of Very High Concern) on the Candidate List are contained in our products. Furthermore, we will immediately and unsolicited inform our customers in compliance with REACH - Article 33 if any substance present in our goods (above a concentration of 0,1 % weight by weight) will be classified as SVHC by the European Chemicals Agency (ECHA).

RoHS

Trenz Electronic GmbH herewith declares that all its products are developed, manufactured and distributed RoHS compliant.

WEEE

Information for users within the European Union in accordance with Directive 2002/96/EC of the European Parliament and of the Council of 27 January 2003 on waste electrical and electronic equipment (WEEE).

Users of electrical and electronic equipment in private households are required not to dispose of waste electrical and electronic equipment as unsorted municipal waste and to collect such waste electrical and electronic equipment separately. By the 13 August 2005, Member States shall have ensured that systems are set up allowing final holders and distributors to return waste electrical and electronic equipment at least free of charge. Member States shall ensure the availability and accessibility of the necessary collection facilities. Separate collection is the precondition to ensure specific treatment and recycling of waste electrical and electronic equipment and is necessary to achieve the chosen level of protection of human health and the environment in the European Union. Consumers have to actively contribute to the success of such collection and the return of waste electrical and electronic equipment. Presence of hazardous substances in electrical and electronic equipment results in potential effects on the environment and human health. The symbol consisting of the crossed-out wheeled bin indicates separate collection for waste electrical and electronic equipment.

Trenz Electronic is registered under WEEE-Reg.-Nr. DE97922676.

2019-06-07