BusAnalyzer

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

Goal(s)

Development of an open-source and (hopefully) lightweight USB-CAN / USB-LIN interface that allows to analyze, test and debug applications using one of these interfaces.

  • General
    • Bus data logging and replay
    • Bus data generation
    • Bus data filtering
    • Timestamp resolution 1 us (accuracy 10 us)
    • No data losses under maximum bus load in worst case scenarios
  • CAN
    • Support for all common CAN baud rates (20 kBit up to 1 MBit)
    • Support of silent mode (listen only), single-shot mode and automatic bus-off recovery
  • LIN
    • Support for all common LIN baud rates (1 kBit up to 20 kBit)

Project state

The project is still in its prototyping state.

Used Hardware

Why STM32? - Out of curiosity and because of the low cost DevKit and its good tool support (e.g. free tools, Standard Peripheral Library, CMSIS compliancy).

Why FT2232H? - For performance reasons and to avoid struggling with the USB peculiarities on the Host).

Both devices are probably oversized for the given task.

Used Software for STM32F103

Why this combination? - Because its free and works like a charm (once you got it running).

Used Software for Host

Why .NET? - Just out of personal interest and because it comes with a good IDE and is supported by a large community. Cross platform support (Linux, Mac) is not a primary concern. A first GUI prototype has shown that the performance could be better. Maybe Qt should be considered as alternative.

Hardware (Prototype)

Interfacing FT2232H and STM32F103

Both devices are connected using their USART interfaces. A partly handshake is required because otherwise the FT2232H sporadically seems to loose some bytes. The STM32F103 provides 3 USARTs. The STM_USART1 cannot be used out of the box because its handshake pins are used by the CAN interface. The CAN interface can be remapped to other pins. The STM_USART2 is connected, too. It allows a maximum bitrate of 2.25 MBit/s. STM_USART1 can be configured with 4.5 MBit/s.

  • FTDI_USART1 (Tx and Rx): Pins 16 and 17 / ADBUS0 and ADBUS1 / CN2-7 and CN2-10
  • FTDI_USART1 (RTS and CTS): Pins 18 and 19 / ADBUS2 and ADBUS3 / CN2-9 and CN2-12
  • FTDI_USART2 (Tx and Rx): Pins 38 and 39 / BDBUS0 and BDBUS1 / CN3-26 and CN3-25 (not used)
  • FTDI_USART2 (RTS and CTS): Pins 40 and 41 / BDBUS2 and BDBUS3 / CN3-24 and CN3-23 (not used)
  • STM_USART1 (Tx and Rx): PA9 and PA10 / EXT1-4 and EXT1-7
  • STM_USART1 (RTS and CTS): PA12 and PA11 / EXT1-3 and EXT1-1
  • STM_USART2 (Tx and Rx): PA2 and PA3 / EXT2-7 and EXT2-10
  • STM_USART2 (RTS and CTS): PA1 and PA0 / EXT2-8 and EXT2-4

The USB bus voltage (5 V) and GND are available on the FT2232H Mini Module connector (CN3-1, CN3-2) and are provided to the STM32-H103 Header Board as power supply (EXT2-23, EXT2-25).

The Tx and Rx lines need to be crossed between both devices. The CTS line (input) of STM_USART2 has to be connected to the RTS line (output) of FTDI_USART1 and vice versa.

Open problem: The FT2232H is prone to loose data even at a data rate of 2.25 MBit (specified up to 12 MBit). The handshake lines do only help to detect this problem (software instead of hardware buffer overflow) but it cannot be avoided this way. Tuning the FTDIs parameters (SetLatency(), InTransferSize) as well as highly frequent polling for received data reduces the probability of data losses.

Why USART? - The USART is expected to be the easiest way (regarding wiring, debugging and software) and thus favoured over SPI, CPU-style FIFO and all the other possibly supported modes.

Interfacing Status-LEDs with FT2232H

  • FTDI_USART1: Pins 29 and 30 / ACBUS3 and ACBUS4 / CN2-19 and CN2-22
  • FTDI_USART2: Pins 54 and 55 / BCBUS3 and BCBUS4 / CN3-14 and CN3-13

The LEDs can be connected to VIO (3.3 V). The size of the series resistors depends on the LED type being used. Further details for the bus powered configuration can be found in the FT2232H Mini Module datasheet.

Interfacing STM32F103 and a CAN Transceiver

The CAN interface of the STM32F103 consists of CANRX and CANTX.

  • Default pin configuration: PA11/EXT1-1, PA12/EXT1-3
  • Remapped pin configuration: PB8/EXT1-16, PB9/EXT1-17

A PCA82C250 (http://www.nxp.com/documents/data_sheet/PCA82C250.pdf) is currently being used. Depending on the application a termination resistor (120Ω) between CANH and CANL might be required. The transceiver is powered by the USB bus. The GND signal is not connected to the SUBD 9-pin connector (http://www.interfacebus.com/Design_Connector_CAN.html) as long as no galvanic isolation is being used.

Interfacing STM32F103 and a LIN Transceiver

Software

Performance Considerations

The CAN interface puts the main burden on the software design. The worst-case scenario consists of a CAN bus operating at 1 MBit/s using full bus load with a minimum frame length (DLC = 0) and zero stuffing bits. This results in an event frequency of approximately 1 / 50 us = 20 kHz. Both the host (non-real-time) as well as the hardware (real-time) need to be able to process events with that frequency. Data exchanged between host and hardware must be packed well enough to fit the available gross data rate of 2.25 MBit of the serial interface (or 4.5 MBit in case of USART1).

Communication Protocol

Host and hardware communicate using a light-weight serial protocol. All protocol data units (PDUs) consist of one or more bytes.

Basic PDU structure:

  • The first byte contains preamble bits and the PDU length in bytes.
  • The second byte contains the packet type
  • Any further bytes contain the payload.
  • The last byte contains an 8 bit checksum (CCITT8).

The payload bytes depend on the actual data being transferred (i.e. the packet type).

Timestamp information is exchanged using 40 bit (5 bytes) integers with a resolution of 1 us per bit. This results in a timestamp overflow after roughly 12 days.

STM32 Software Design

The automotive bus peripherals (CAN, LIN) are used completely interrupt driven to ensure a sufficient timestamp accuracy as well as to avoid data losses.

The host communication via USART2 is handled completely by DMA which allows using most of the available bandwidth and reducing the interrupt load.

The background (infinite loop in non-interrupt context) is used to process incoming commands, trigger bus communication and so on. Data reception is thus always favoured over data transmission.

The STM32 Standard Peripheral Driver Library has been used wherever the performance impact was expected not be to severe.

A preliminary firmware which is still lacking LIN support can be downloaded here: Datei:BusAnalyzer.zip.

Host Software Design

Non-Prototype Hardware

Basis

The ideas provided by http://klk64.com/stm32/ seem to be a good basis. Required modifications:

  • Galvanic isolation for CAN
  • LIN transceiver
  • FT2232H needs to be added, the internal USB interface overlaps with the CAN interface which is why it can't be used
  • Remove headers not required by application

Parts

Eagle libraries

Schematic

Open Issues

  • How to realize galvanic isolation for all transceivers?
  • Alternatively do galvanic isolation between FTDI and STM32
    • ADUM5402ARWZ / ADUM5402CRWZ (2 MBit / 25 MBit max.), quad channel isolator with integrated DC-DC converter
  • Termination selection via jumper or electronic switch / relais
    • 120 ohms for TJA1040
    • 10k in parallel with 1k (switchable) for TJA1054 (specification states 500 to 16k)
    • 30k in parallel with 1k (switchable) for TJA1020
Abgerufen von „https://www.mikrocontroller.net/index.php?title=BusAnalyzer&oldid=61798“