JTAG and I 2 C on ELMB

Transcription

1 JTAG and I 2 C on ELMB Henk Boterenbrood NIKHEF, Amsterdam Nov 2000 Version 0.3 ABSTRACT The ELMB is designed as a general-purpose plug-on module for distributed monitoring and control applications in the ATLAS detector. This document descibes some proposals for implementation and addition of objects to the Object Dictionary of the ELMB CANopen application and PDO mappings of these objects in order to provide (basic) access to JTAG- and I2C-bus(es). (based on author's (limited) experiences with these buses ) Contents 1 JTAG INTRODUCTION JTAG BY ELMB I 2 C INTRODUCTION I 2 C BY ELMB...7 1

2 1 JTAG 1.1 Introduction JTAG is a bus that connects devices (usually ICs) together. Every device contains a kind of bus interface called test access port (TAP), referring to JTAG's initial purpose which is to provide chip- and boardlevel test facilities. JTAG is a 4-wire bus (there is a 5 th optional wire TRST, Test Reset) with the following lines: TMS Mode select. Directs the device through its test access port (TAP) interface states, shown in Figure 1. TCK Clock. Operations are synchronous to this clock; data is captured on the rising edge of TCK and outputs change on the falling edge of TCK. TDI Data input. Is the serial input for shifting data through the instruction register or selected data register. TDO Data output. Is the serial output for shifting data through the instruction register or selected data register. Figure 1. JTAG state transition diagram: transitions from state to state triggered by a rising edge of TCK, the numbers 1 or 0 signifying the value of TMS during the transition. 2

3 The 'JTAG bus controller' controls the chain of JTAG devices; it controls TMS and TCK and its TDI is connected to the TDI of the first device on the JTAG-bus. In case of multiple devices on the JTAG-bus the TDO of the first device is connected to the TDI of the second device, the TDO of the second device to the third device and so on. The TDO of the last device in the chain is the TDO of the interface of the 'JTAG bus controller'. By controlling the TAPs a device's socalled instruction register or a device's data register can be 'inserted' between TDI and TDO as a serial shift register. From the JTAG bus controller's point of view the registers of all devices connected to the JTAG-bus form one long serial shift register, where bits are shifted in on TDI and bits are shifted out on TDO. 1.2 JTAG by ELMB On the ELMB with 4 digital I/O pins may constitute a 'JTAG bus controller', with the JTAG protocol implemented entirely in software. The basic functionality for remote JTAG operation to be provided by the ELMB CANopen application might consist of: 1. the ability to steer the TAP state machine from any state to any state, in case a user wants to cycle his TAPs through a particular sequence of states 2. the ability to directly shift any number of bits out of (read) or into (write) the instruction register (TAP state is Shift-IR) 3. the ability to directly shift any number of bits out of (read) or into (write) a data register (TAP state is Shift-DR) Other JTAG functionality that can be made part of the ELMB application's functionality (depending on user/application requirements) could be: Storage of bit sequences: the ability to permanently store in on-chip EEPROM a number of bit sequences (e.g. up to 4), each containing up to e.g. 500*8=4000 bits (limited only by the on-chip EEPROM size of 4 kbyte; the storage capacity could be increased by adding an external (serial) FLASH or EEPROM on the ELMB carrier board (for example: ATMEL has 8-pins devices with upto 512 kbytes of FLASH (AT45DB041) with an SPI interface). a complete sequence is downloaded to JTAG by writing a single CAN-message to the appropriate object in the Object Dictionary, triggering the ELMB application to do this (if a PDO is used for this a broadcast could be sent to all nodes configured to receive this PDO, triggering all of them to download a particular sequence at the same time). before any download to JTAG each sequence as stored in EEPROM is of course checked first by the ELMB application using a CRC checksum. apart from an Object Dictionary entry to trigger a download operation there need to be extra entries to make storage of the bit sequences in the EEPROM possible. locally stored bit sequences are written to JTAG at an estimated maximum rate of about 1 Mbit/s. 3

4 Single bit changes: the ability to change a single or a few bits in a long JTAG bit chain, which requires all bits of the chain to be read out and shifted back into the chain, changing the requested bit or bits to the required value(s) on the fly. the Object Dictionary (write-only) entry could be a single 32-bit integer, in which one byte denotes the number of bits to change (up to 8), a 2-byte 'bit-address' within a chain (enabling addressing within a chain of bits maximum), and one byte with the new bit sequence (of up to 8 bits) to replace the old sequence. Or better(?): 3 objects, one for the bit-address, one for the number of bits, and one for the bits itself; in this case an SDO read of selected bits in the chain is also possible, using a sequence of 3 SDOs: an SDO to write to bit-address, an SDO to write to number of bits, an SDO to read the actual bits from the JTAG-bus. 4

5 The objects in the CANopen Object Dictionary to implement the three functions described above (numbered 1 to 3) are listed in the table below (for one JTAG-interface). Manufacturer-specific Profile Area (ELMB Master) Index (hex) Sub Index Name Data/ Object 5 Attr Default Comment JTAG state U8 RW 1 default stands for state Test-Logic-Reset Shift IR (Instruction Register) Domain RW Go to state Shift-IR. R: shift out 32 (SDO Expedited Transfer) or 56 (SDO Domain Download) bits per SDO access (shifting them back in at the same time?). W: shift in 32 or 56 bits. Remain in state Shift-IR Final IR shift Record 0 Number of bits U8 RW 1 Final IR bit shift U32 RW Go to state Shift-IR. R: shift out up to 32 bits, (shifting them back in?). W: shift in up to 32 bit. Number of bits to shift in Object 4011, 0. Go to state Test-Logic-Reset Last total number of bits shifted 4020 Shift DR (Data Register) Domain U32 RO 0 Can be used by host application to check if all downloaded bits have been received by ELMB RW Go to state Shift-DR. R: shift out 32 (SDO Expedited Transfer) or 56 (SDO Domain Download) bits per SDO access (shifting them back in at the same time?). W: shift in 32 or 56 bits. Remain in state Shift-DR Final DR shift Record 0 Number of bits U8 RW 1 Final DR bit shift U32 RW Go to state Shift-DR. R: shift out up to 32 bits, (shifting them back in?). W: shift in up to 32 bit. Number of bits to shift in Object 4021, 0. Go to state Test-Logic-Reset Last total number of bits shifted U32 RO 0 Can be used by host application to check if all downloaded bits have been received by ELMB Object 4000 implements function 1, objects 4010, 4011, 4012 implement function 2 and objects 4020, 4021 and 4022 implement function 3. Note that it is necessary to have separate objects for the final bit shift operation because the JTAG standard defines that the last bit is shifted in/out while leaving the Shift-XX state, mak-

6 ing the last bit a special case So if there are 32 or less bits to shift in only the 'final XX bit shift' object should be written to (read from)! Using Object Dictionary accesses (socalled SDO CANopen messages) the JTAG download bit rates that can be achieved are limited by the protocol overhead of CAN and/or SDO messages. An SDO CAN client message always contains 8 data bytes, and must be followed by a reply from the SDO server, also containing 8 data bytes, so that one SDO message + reply consists of = 222 bits (111 = 47 bits protocol + 64 bits data). Using a CAN-bus bit rate of 125 kbit/s the following JTAG bit rates can be achieved for different CANopen SDO transfer mechanisms: SDO Expedited Transfer: 32 bits relevant data rate (32/222)*125 = ca. 18 kbit/s SDO Segmented Transfer: 56 bits relevant data rate (56/222)*125 = ca. 30 kbit/s SDO Block Transfer: 56 bits relevant data rate (56/111)*125 = ca. 60 kbit/s Example: if 199 bits have to be downloaded 6 SDO writes carrying 32 bits each can be sent (write Object 4020), then one SDO write to set Object 4021,0 to 7, and finally one SDO to write these last 7 bits (write Object 4021,1) (assuming all SDOs using Expedited Transfer). If the main purpose of the JTAG interface is to download data in the Shift-DR state (e.g. configuration bits), the use of PDOs could be considered. For a download of an unlimited number of bits in the Shift-DR state 2 PDOs can be defined: one receive-pdo to contain the standard Shift-DR download and one receive-pdo to contain the final Shift-DR bit shift operation. The first PDO mapping looks like this: Byte 0-3 Object 4020: 32 bits to download The second PDO mapping looks like this: Byte 0 Byte 1-4 Object 4021,0: number of bits Object 4021,1: 1 up to 32 bits to download A download sequence thus consists of any number of the first PDO message and must end with exactly one PDO message of the second type. For larger downloads the download rate is determined by the first PDO, so the JTAG bit rate that can be achieved is about (32/(32+47))*125 = (32/79)*125 = 50 kbit/s maximum. The advantage of using PDOs is that they can be broadcast to any number of nodes on the CAN bus (if they have been configured to receive the PDO), possibly saving a lot of time if the same JTAG bit sequence is to be downloaded to multiple nodes. Because PDO messages are unconfirmed it is wise to check if all bits have indeed been received after a download operation, by checking the value of Object 4022 (the CAN-bus controller in the ELMB does not detect messages that get overwritten before read-out by the onboard microprocessor). 6

7 2 I 2 C 2.1 Introduction The I2C-bus uses two wires (SDA and SCL) to transfer information between devices connected to the bus. The main features of the bus are: bidirectional data transfer between masters and slaves multimaster bus (no central master) arbitration between simultaneously transmitting masters without corruption of serial data on the bus Two types of data transfer are possible on the I2C bus: 1. Data transfer from a master transmitter to a slave receiver. The first byte transmitted by the master is the slave address. Next follows a number of data bytes. The slave returns an anknowledge bit after each received byte. 2. Data transfer from a slave transmitter to a master receiver. The first byte (the slave address) is transmitted by the master. The slave then returns an acknowledge bit. Next follow the data bytes transmitted by the slave to the master. The master returns an acknowledge bit after all received bytes other than the last byte. At the end of the last received byte, a "not acknowledge" is returned. 2.2 I 2 C by ELMB On the ELMB 2 digital I/O pins together can provide I2C-bus functionality, with the I2C protocol implemented entirely in software. We assume the ELMB is used as the I2C bus Master to control an I2C-bus in a single-master situation which simplifies the software implementation. Additions to the ELMB Object Dictionary for one I2C-bus might look like this: Manufacturer-specific Profile Area (ELMB Master) Index (hex) Sub Index Name Data/ Object Attr Default Comment 4100 I2C-bus Record 0 I2C address U8 RW 1 I2C number of bytes U8 RW 2 I2C data bytes U32 RW Accessing this object means physically reading or writing from or to the I2C bus, using the parameters from Objects 4100,0 and 4100, I2C-bus status U8 RW 0 Bitmask denoting certain errors occurred during I2C bus operation when certain bits are set 7

8 Because we limit the 'I2C data bytes' object to one 32-bit integer value up to 4 data bytes can be read and written using a single SDO Expedited Transfer CAN-message. The objects can be mapped to either a receive-pdo (to write to I2C-bus) or a transmit-pdo (to read from I2C-bus) as follows: Byte 0 Byte 1 Byte 2-5 I 2 C address I 2 C number of bytes I 2 C data bytes If required the number of data bytes (Object 4100,2) could be increased to 6 bytes, exactly filling up one PDO completely. The above CANopen objects and proposed PDO assume that the user at the CANopen level wants detailed control over the I2C buses and devices, but it could equally be true that the user wants the interface to the I2C-bus completely hidden by the ELMB. For instance, when a bunch of I2C devices with DACs are connected to the ELMB from the CANopen point of view these can be viewed as a number of analog output objects and treated as such in the CANopen defined way, leaving the low-level access (setting up, reading/writing) to the actual analog output devices (via I2C-bus) for the ELMB to handle. Multiple I2C buses can easily be accommodated by reserving more I/O pins for connection to I2C-buses and defining extra I2C-bus objects in the Object Dictionary and PDOs. A set-up as shown below in Figure 2 with an ELMB and an I2C-bus with two slave devices has been successfully tested. +5V 10k 10k Px.y Px.z ELMB SDA SCL SDA SCL SDA SCL I 2 C-bus PCF8591 ADC / DAC PCF8574 Digital I/O 4 8 Figure 2. An I 2 C-bus with 2 slave devices, connected to the ELMB. 8