begriffs open source - cmsis/blob - CMSIS/DoxyGen/Driver/src/General.txt

   1 /**
   2 \mainpage Overview
   3
   4 The CMSIS-Driver specification is a software API that describes peripheral driver interfaces for middleware stacks and user
   5 applications. The CMSIS-Driver API is designed to be generic and independent of a specific RTOS making it reusable across a
   6 wide range of supported microcontroller devices. The CMSIS-Driver API covers a wide range of use cases for the supported
   7 peripheral types, but can not take every potential use-case into account. Over time, it is indented to extend the
   8 CMSIS-Driver API with further groups to cover new use-cases.
   9
  10 The CMSIS Software Pack publishes the API Interface under the Component Class \b CMSIS \b Driver with header files and a
  11 documentation. These header files are the reference for the implementation of the standardized peripheral driver interfaces.
  12 These implementations are published typically in the Device Family Pack of a related microcontroller family under the
  13 Component Class \b CMSIS \b Driver. A Device Family Pack may contain additional interfaces in the Component Class \b Device
  14 to extend the standard Peripheral Drivers covered by this CMSIS-Driver specification with additional device specific
  15 interfaces for example for Memory BUS, GPIO, or DMA.
  16
  17 The standard peripheral driver interfaces connect microcontroller peripherals for example with middleware that implements
  18 communication stacks, file systems, or graphic user interfaces. Each peripheral driver interface may provide multiple
  19 instances reflecting the multiple physical interfaces of the same type in a device. For example the two physical SPI
  20 interfaces are reflected with a separate \ref AccessStruct for SPI1 and SPI2. The \ref AccessStruct is the interface of a
  21 driver to the middleware component or the user application.
  22
  23 \image html Driver.png  "Peripheral Driver Interfaces and Middleware"
  24
  25 The following CMSIS-Driver API groups are defined:
  26   - \ref can_interface_gr "CAN": Interface to CAN bus peripheral.
  27   - \ref eth_interface_gr "Ethernet": Interface to Ethernet MAC and PHY peripheral.
  28   - \ref i2c_interface_gr "I2C": Multi-master Serial Single-Ended Bus interface driver.
  29   - \ref mci_interface_gr "MCI": Memory Card Interface for SD/MMC memory.
  30   - \ref nand_interface_gr "NAND": NAND Flash Memory interface driver.
  31   - \ref flash_interface_gr "Flash": Flash Memory interface driver.
  32   - \ref sai_interface_gr "SAI": Serial audio interface driver (I2s, PCM, AC'97, TDM, MSB/LSB Justified).
  33   - \ref spi_interface_gr "SPI": Serial Peripheral Interface Bus driver.
  34   - \ref storage_interface_gr "Storage": Storage device interface driver.
  35   - \ref usart_interface_gr "USART": Universal Synchronous and Asynchronous Receiver/Transmitter interface driver.
  36   - \ref usb_interface_gr "USB": Interface driver for USB Host and USB Device communication.
  37
  38 <hr>
  39
  40 CMSIS-Driver in ARM::CMSIS Pack
  41 -------------------------------
  42
  43 The following files relevant to CMSIS-Driver are present in the <b>ARM::CMSIS</b> Pack directories:
  44 | Directory                      | Content                                                                 |
  45 |--------------------------------|------------------------------------------------------------------------|
  46 |\b CMSIS/Documentation/Driver   | This documentation                                                     |
  47 |\b CMSIS/Driver/Include         | Driver header files (Driver_<i>interface</i>.h, Driver_Common.h)       |
  48 |\b CMSIS/Driver/DriverTemplates | Driver implementation template files (Driver_<i>interface</i>.c)       |
  49
  50 <hr>
  51 */
  52
  53 /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
  54 /**
  55 \page driver_revisionHistory Revision History of CMSIS-Driver
  56
  57
  58 <table class="cmtable" summary="Revision History">
  59     <tr>
  60       <th>Version</th>
  61       <th>Description</th>
  62     </tr>
  63     <tr>
  64       <td>2.04</td>
  65       <td>Modifications compared to Version 2.03:
  66  - Added: template files for CAN interface driver.
  67       </td>
  68     <tr>
  69       <td>2.03</td>
  70       <td>Modifications compared to Version 2.02:
  71  - Added: CAN API for an interface to CAN peripherals
  72  - Added: Overview of the \ref DriverValidation "CMSIS-Driver Validation" Software Pack.
  73  - Enhanced: documentation and clarified behavior of the \ref CallSequence.
  74       </td>
  75     </tr>
  76     <tr>
  77       <td>2.02</td>
  78       <td>Modifications compared to Version 2.00:
  79  - Minor API changes, for exact details refer to the header file of each driver.
  80  - Added: Flash Interface, NAND interface.
  81       </td>
  82     </tr>
  83     <tr>
  84       <td>2.00</td>
  85       <td>API with non-blocking data transfer, independent of CMSIS-RTOS.</td>
  86     </tr>
  87     <tr>
  88       <td>1.10</td>
  89       <td>Initial release</td>
  90     </tr>
  91 </table>
  92 */
  93
  94 /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
  95 /**
  96 \page TheoryOperation Theory of Operation
  97
  98 [TOC]
  99
 100 This section gives an overview of the general operation of CMSIS-Drivers. It explains the \ref DriverFunctions that are
 101 common in all CMSIS-Drivers along with the \ref CallSequence. The topic \ref Data_Xfer_Functions describes how data
 102 read/write operations to the peripheral are implemented.
 103
 104 Each CMSIS-Driver defines an \ref AccessStruct for calling the various driver functions and each peripheral (that is accessed
 105 via a CMSIS-Driver) has one \ref DriverInstances "Driver Instance".
 106
 107
 108 \section DriverFunctions Common Driver Functions
 109
 110 Each CMSIS-Driver contains these functions:
 111
 112  - \b GetVersion: can be called at any time to obtain version information of the driver interface.
 113
 114  - \b GetCapabilities: can be called at any time to obtain capabilities of the driver interface.
 115
 116  - \b Initialize: must be called before powering the peripheral using \b PowerControl. This function performs the following:
 117      - allocate I/O resources.
 118          - register an optional \b SignalEvent callback function.
 119
 120  - \b SignalEvent: is an optional callback function that is registered with the \b Initialize function. This callback
 121    function is initiated from interrupt service routines and indicates hardware events or the completion of a data block
 122    transfer operation.
 123
 124  - \b PowerControl: Controls the power profile of the peripheral and needs to be called after \b Initialize. Typically, three
 125    power options are available:
 126      - \c ARM_POWER_FULL: Peripheral is turned on and fully operational. The driver initializes the peripheral registers, interrupts, and (optionally) DMA.
 127      - \c ARM_POWER_LOW: (optional) Peripheral is in low power mode and partially operational; usually, it can detect
 128        external events and wake-up.
 129      - \c ARM_POWER_OFF: Peripheral is turned off and not operational (pending operations are terminated). This is the state
 130        after device reset.
 131
 132  - \b Uninitialize: Complementary function to Initialize. Releases the I/O pin resources used by the interface.
 133
 134  - \b Control: Several drivers provide a control function to configure communication parameters or execute miscellaneous
 135    control functions.
 136
 137 The section \ref CallSequence contains more information on the operation of each function. Additional functions are specific
 138 to each driver interface and are described in the individual sections of each driver.
 139
 140 \subsection ProcessorMode Cortex-M Processor Mode
 141
 142 The CMSIS-Driver functions access peripherals and interrupts and are designed to execute in \b Privileged mode.
 143 When calling CMSIS-Driver functions from RTOS threads, it should be ensure that these threads execute in \b Privileged mode.
 144
 145
 146 \section CallSequence Function Call Sequence
 147
 148 For normal operation of the driver, the API functions \b GetVersion, \b GetCapabilities, \b Initialize, \b PowerControl, \b Uninitialize are
 149 called in the following order:
 150
 151 \msc
 152  a [label="", textcolor="indigo", linecolor="indigo", arclinecolor="indigo"],
 153  b [label="", textcolor="blue", linecolor="blue", arclinecolor="blue"];
 154
 155  a rbox a [label="Middleware", linecolor="indigo"],
 156  b rbox b [label="Driver", linecolor="blue"];
 157  --- [label="Verify API version"];
 158  a=>b [label="GetVersion ()", textcolor="gray", linecolor="gray"];
 159  --- [label="Obtain driver features"];
 160  a=>b [label="GetCapabilities (...)", textcolor="gray", linecolor="gray"];
 161  ---  [label="Setup software resources"];
 162  a=>b [label="Initialize (...)", textcolor="red", linecolor="red"];
 163  --- [label="Setup the peripheral"];
 164  a=>b  [label="PowerControl (ARM_POWER_FULL)", textcolor="red", linecolor="red"];
 165  --- [label="Operate with the peripheral"];
 166  a=>b [label="Data Transfer Functions"];
 167  a<=b  [label="SignalEvent (...)"];
 168  --- [label="Wait for external hardware events"];
 169  a=>b  [label="PowerControl (ARM_POWER_LOW)"];
 170  a<=b  [label="SignalEvent (...)"];
 171  --- [label="Stop working with peripheral"];
 172  a=>b [label="PowerControl (ARM_POWER_OFF)", textcolor="red", linecolor="red"];
 173  a=>b [label="Uninitialize (...)", textcolor="red", linecolor="red"];
 174 \endmsc
 175
 176 The functions \b GetVersion and \b GetCapabilities can be called any time to obtain the required information from the driver.
 177 These functions return always the same information.
 178
 179
 180 \subsection CS_start Start Sequence
 181
 182 To start working with a peripheral the functions \b Initialize and \b PowerControl need to be called in this order:
 183 \code
 184   drv->Initialize (...);                 // Allocate I/O pins
 185   drv->PowerControl (ARM_POWER_FULL);    // Power up peripheral, setup IRQ/DMA
 186 \endcode
 187
 188 - \b Initialize typically allocates the I/O resources (pins) for the peripheral. The function can be called multiple times;
 189   if the I/O resources are already initialized it performs no operation and just returns with \ref ARM_DRIVER_OK.
 190 - \b PowerControl (\c ARM_POWER_FULL) sets the peripheral registers including interrupt (NVIC) and optionally DMA.
 191   The function can be called multiple times; if the registers are already set it performs no operation and just returns with \ref ARM_DRIVER_OK.
 192
 193 \subsection CS_stop Stop Sequence
 194
 195 To stop working with a peripheral the functions \b PowerControl and \b Uninitialize need to be called in this order:
 196 \code
 197   drv->PowerControl (ARM_POWER_OFF);     // Terminate any pending transfers, reset IRQ/DMA, power off peripheral
 198   drv->Uninitialize (...);               // Release I/O pins
 199 \endcode
 200 The functions \b PowerControl and \b Uninitialize always execute and can be used to put the peripheral into a <b>Safe State</b>,
 201 for example after any data transmission errors.  To restart the peripheral in a error condition, you should first execute
 202 the \ref CS_stop and then the \ref CS_start.
 203
 204 - \b PowerControl (\c ARM_POWER_OFF) terminates any pending data transfers with the peripheral, disables the peripheral and
 205   leaves it in a defined mode (typically the reset state).
 206     - when DMA is used it is disabled (including the interrupts)
 207     - peripheral interrupts are disabled on NVIC level
 208     - the peripheral is reset using a dedicated reset mechanism (if available) or by clearing the peripheral registers
 209     - pending peripheral interrupts are cleared on NVIC level
 210     - driver variables are cleared
 211 - \b Uninitialize always releases I/O pin resources.
 212
 213 \section Share_IO Shared I/O Pins
 214
 215 All CMSIS-Driver provide a \ref CS_start and \ref CS_stop. Therefore two different drivers can share the same I/O pins,
 216 for example UART1 and SPI1 can have overlapping I/O pins. In this case the communication channels can be used as shown below:
 217
 218 \code
 219   SPI1drv->Initialize (...);                // Start SPI1
 220   SPI1drv->PowerControl (ARM_POWER_FULL);
 221    ...                                      // Do operations with SPI1
 222   SPI1drv->PowerControl (ARM_POWER_OFF);    // Stop SPI1
 223   SPI1drv->Uninitialize ();
 224    ...
 225   USART1drv->Initialize (...);              // Start USART1
 226   USART1drv->PowerControl (ARM_POWER_FULL);
 227    ...                                      // Do operations with USART1
 228   USART1drv->PowerControl (ARM_POWER_OFF);  // Stop USART1
 229   USART1drv->Uninitialize ();
 230 \endcode
 231
 232 \section Data_Xfer_Functions Data Transfer Functions
 233
 234 A CMSIS-Driver implements non-blocking functions to transfer data to a peripheral. This means that the driver configures the
 235 read or write access to the peripheral and instantly returns to the calling application.  The function names for data
 236 transfer end with:
 237  - \b Send to write data to a peripheral.
 238  - \b Receive to read data from a peripheral.
 239  - \b Transfer to indicate combined read/write operations to a peripheral.
 240
 241 During a data transfer, the application can query the number of transferred data items using functions named
 242 <b>Get<i>xxx</i>Count</b>. On completion of a data transfer, the driver calls a callback function with a specific event code.
 243
 244 During the data exchange with the peripheral, the application can decide to:
 245  - Wait (using an RTOS scheduler) for the callback completion event. The RTOS is controlled by the application code which
 246    makes the driver itself RTOS independent.
 247  - Use polling functions that return the number of transferred data items to show progress information or partly read or fill
 248    data transfer buffers.
 249  - Prepare another data transfer buffer for the next data transfer.
 250
 251 The following diagram shows the basic communication flow when using the \b _Send function in an application.
 252
 253 \image html Non_blocking_transmit_small.png  "Non-blocking Send Function"
 254
 255 \section AccessStruct Access Struct
 256
 257 A CMSIS-Driver publishes an \ref AccessStruct with the data type name ARM_DRIVER_xxxx that gives to access the driver
 258 functions.
 259
 260 \b Code \b Example: \b Function \b Access \b of \b the \b SPI \b driver
 261 \code
 262 typedef struct _ARM_DRIVER_SPI {
 263   ARM_DRIVER_VERSION   (*GetVersion)      (void);
 264   ARM_SPI_CAPABILITIES (*GetCapabilities) (void);
 265   int32_t              (*Initialize)      (ARM_SPI_SignalEvent_t cb_event);
 266   int32_t              (*Uninitialize)    (void);
 267   int32_t              (*PowerControl)    (ARM_POWER_STATE state);
 268   int32_t              (*Send)            (const void *data, uint32_t num);
 269   int32_t              (*Receive)         (      void *data, uint32_t num);
 270   int32_t              (*Transfer)        (const void *data_out, void *data_in, uint32_t num);
 271   uint32_t             (*GetDataCount)    (void);
 272   int32_t              (*Control)         (uint32_t control, uint32_t arg);
 273   ARM_SPI_STATUS       (*GetStatus)       (void);
 274 } const ARM_DRIVER_SPI;
 275 \endcode
 276
 277 \subsection DriverInstances Driver Instances
 278
 279 A device may offer several peripherals of the same type. For such devices, the CMSIS-Driver publishes multiple instances
 280 of the \ref AccessStruct. The name of each driver instance reflects the names of the peripheral available in the device.
 281
 282 \b Code \b Example: \ref AccessStruct \b for \b three \b SPIs \b in \b a \b microcontroller \b device.
 283 \code
 284 ARM_DRIVER_SPI Driver_SPI1;     // access functions for SPI1 interface
 285 ARM_DRIVER_SPI Driver_SPI2;     // access functions for SPI2 interface
 286 ARM_DRIVER_SPI Driver_SPI3;     // access functions for SPI3 interface
 287 \endcode
 288
 289 The access functions can be passed to middleware to specify the driver instance that the middleware should use for communication.
 290
 291 \b Example:
 292 \code
 293 void init_middleware (ARM_DRIVER_SPI *Drv_spi) ...
 294 \\ inside the middleware the SPI driver functions are called with:
 295 \\   Drv_spi->function (...);
 296 \endcode
 297
 298 \code
 299 \\ setup middleware
 300 init_middleware (&Driver_SPI1);      // connect middleware to SPI1 interface
 301   :
 302 init_middleware (&Driver_SPI2);      // connect middleware to SPI2 interface
 303 \endcode
 304
 305
 306 \section DriverConfiguration Driver Configuration
 307
 308 For a device family, the drivers may be configurable. The \ref ReferenceImplementation stores configuration options in a
 309 central file with the name \b RTE_Device.h. However, the configuration of the drivers itself is not part of the CMSIS-Driver
 310 specification.
 311
 312 \section CodeExample Code Example
 313
 314 The following example code shows the usage of the SPI interface.
 315
 316 \include SPI_Demo.c
 317 */
 318
 319 /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
 320 /**
 321 \page ReferenceImplementation Reference Implementation
 322
 323 The API of the CMSIS-Drivers is published in the \ref DriverHeaderFiles.
 324
 325 To simplify the development of a CMSIS-Driver both \ref DriverTemplates and \ref DriverExamples are provided.
 326
 327 ARM offers also a Software Pack for CMSIS-Driver Validation as described in \ref DriverValidation.
 328
 329 \section DriverHeaderFiles Driver Header Files
 330
 331 The API of each CMSIS-Driver is published in a header file. It is recommended to include the header file that is part of the
 332 CMSIS specification in the implementation file of the CMSIS-Driver.
 333
 334 The following header files are available in the directory <b>.\\CMSIS\\Driver\\Include</b>.
 335
 336 | Header File          | Description
 337 |----------------------|-------------------------
 338 | %Driver_Common.h     | \ref common_drv_gr
 339 | %Driver_CAN.h        | \ref can_interface_gr
 340 | %Driver_ETH.h        | \ref eth_interface_gr
 341 | %Driver_ETH_MAC.h    | \ref eth_mac_interface_gr
 342 | %Driver_ETH_PHY.h    | \ref eth_phy_interface_gr
 343 | %Driver_Flash.h      | \ref flash_interface_gr
 344 | %Driver_I2C.h        | \ref i2c_interface_gr
 345 | %Driver_MCI.h        | \ref mci_interface_gr
 346 | %Driver_NAND.h       | \ref nand_interface_gr
 347 | %Driver_SPI.h        | \ref spi_interface_gr
 348 | %Driver_Storage.h    | \ref storage_interface_gr
 349 | %Driver_SAI.h        | \ref sai_interface_gr
 350 | %Driver_USART.h      | \ref usart_interface_gr
 351 | %Driver_USB.h        | \ref usb_interface_gr
 352 | %Driver_USBD.h       | \ref usbd_interface_gr
 353 | %Driver_USBH.h       | \ref usbh_interface_gr
 354
 355
 356 \section DriverTemplates Driver Template Files
 357
 358 Driver template files are code skeletons that provide the structure of a CMSIS-Driver.  The following templates are
 359 available in the directory <b>.\\CMSIS\\Driver\\DriverTemplates</b>.
 360
 361 | Source File       | Description
 362 |-------------------|------------------------------------
 363 | %Driver_CAN.c     | \ref can_interface_gr
 364 | %Driver_ETH_MAC.c | \ref eth_mac_interface_gr
 365 | %Driver_ETH_PHY.c | \ref eth_mac_interface_gr
 366 | %Driver_Flash.c   | \ref flash_interface_gr
 367 | %Driver_I2C.c     | \ref i2c_interface_gr
 368 | %Driver_MCI.c     | \ref mci_interface_gr
 369 | %Driver_SAI.c     | \ref sai_interface_gr
 370 | %Driver_SPI.c     | \ref spi_interface_gr
 371 | %Driver_Storage.c | \ref storage_interface_gr
 372 | %Driver_USART.c   | \ref usart_interface_gr
 373 | %Driver_USBD.c    | \ref usbd_interface_gr
 374 | %Driver_USBH.c    | \ref usbh_interface_gr
 375
 376
 377 \section DriverExamples Driver Examples
 378
 379 The driver examples are full working CMSIS-Drivers that may be adapted to a different hardware. Examples are currently
 380 available for the NXP LPC1800 series and provide the implementation of a complete CMSIS-Driver. The following examples are
 381 available in the directory <b>.\\CMSIS\\Pack\\Example\\CMSIS_Driver</b>.
 382
 383 | Source File       | Header File       | Description
 384 |-------------------|-------------------|-------------------------------
 385 | %EMAC_LPC18xx.c   | %EMAC_LPC18xx.h   | \ref eth_mac_interface_gr
 386 | %SSP_LPC18xx.c    | %SSP_LPC18xx.h    | \ref spi_interface_gr
 387 | %I2C_LPC18xx.c    | %I2C_LPC18xx.h    | \ref i2c_interface_gr
 388 | %I2S_LPC18xx.c    | %I2S_LPC18xx.h    | \ref sai_interface_gr
 389 | %MCI_LPC18xx.c    | %MCI_LPC18xx.h    | \ref mci_interface_gr
 390 | %USART_LPC18xx.c  | %USART_LPC18xx.h  | \ref usart_interface_gr
 391 | %USBn_LPC18xx.c   | %USB_LPC18xx.h    | common files for \ref usbd_interface_gr and \ref usbh_interface_gr
 392 | %USBDn_LPC18xx.c  | <i>none</i>       | \ref usbd_interface_gr
 393 | %USBHn_LPC18xx.c  | <i>none</i>       | \ref usbh_interface_gr
 394
 395
 396 These CMSIS-Drivers use additional modules for GPIO and DMA control:
 397
 398 | Source File       | Header File      | Description
 399 |-------------------|------------------|---------------------------------------
 400 | %GPIO_LPC18xx.c   | %GPIO_LPC18xx.h  | GPIO Interface for LPC1800 series
 401 | %GPDMA_LPC18xx.c  | <i>none</i>      | DMA Interface for LPC1800 series
 402 | %SCU_LPC18xx.c    | %SCU_LPC18xx.h   | SCU Interface for LPC1800 series
 403
 404 The CMSIS-Drivers for the LPC1800 device have also many configuration options that are controls using \#define statements in
 405 the file <b>.\\CMSIS\\Pack\\Example\\CMSIS_Driver\\Config\\RTE_Device.h</b>. Using this file, the I/O pin and DMA assignment
 406 can be set among other parameters such as USB speed and PHY interfaces.
 407
 408 Further driver reference implementations are available in Device Family Packs (DFP) labeled with version 2.0.0 or higher.
 409 */
 410
 411 /*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
 412 /**
 413 \page DriverValidation Driver Validation
 414
 415 ARM offers a <a href="http://www.keil.com/pack/doc/CMSIS/DV/html/index.html" target=_blank>CMSIS-Driver Validation</a>
 416 Software Pack. The <b>ARM::CMSIS-Driver_Validation</b> Pack contains the following:
 417
 418  - Source code of a CMSIS-Driver Validation Suite along with configuration file.
 419  - Documentation of the CMSIS-Driver Validation Suite.
 420  - Examples that shows the usage of the CMSIS-Driver Validation Suite on various target platforms.
 421
 422 The CMSIS-Driver Validation Suite performs the following tests:
 423  - Generic Validation of API function calls
 424  - Validation of Configuration Parameters
 425  - Validation of Communication with loopback tests
 426  - Validation of Communication Parameters such as baudrate
 427  - Validation of Event functions
 428
 429 The following CMSIS-Drivers can be tested with the current release:
 430  - \ref can_interface_gr : with loop back test of communication.
 431  - \ref eth_interface_gr : MAC and PHY with loop back test of communication.
 432  - \ref i2c_interface_gr : only API and setup; does not test data transfer.
 433  - \ref mci_interface_gr : only API and setup; does not test data transfer.
 434  - \ref spi_interface_gr : with loop back test of communication.
 435  - \ref usart_interface_gr : with loop back test of communication.
 436  - \ref usbd_interface_gr : only API and setup; does not test data transfer.
 437  - \ref usbh_interface_gr : only API and setup; does not test data transfer.
 438
 439 The Driver Validation output can printed to a console, output via ITM printf, or output to a memory buffer.
 440
 441 \section test_output Sample Test Output
 442 \verbatim
 443 CMSIS-Driver Test      Aug 24 2015 15:15:14
 444
 445 TEST 01: SPI_GetCapabilities          PASSED
 446 TEST 02: SPI_Initialization
 447   DV_SPI.c(142) - Failed
 448 TEST 03: SPI_PowerControl             NOT EXECUTED
 449   :
 450   :
 451 TEST 23: USART_Send
 452   DV_USART.c(335) - Fail to send 1024 bytes
 453   DV_USART.c(335) - Fail to send 2048 bytes
 454   DV_USART.c(341) - Fail to send without callback 2048 bytes
 455   :
 456   :
 457 Test Summary: 52 Tests: 42 Executed, 22 Failed.
 458   653 Test Cases: 56 Errors(s), 12 Warning(s).
 459 \endverbatim
 460
 461 \section loop_back_setup Setup for Loop Back Communication
 462
 463 To perform loop back communication tests it is required to connect the input and the output of the peripherals as shown in this table:
 464
 465 Peripheral       | Loop Back Configuration
 466 :----------------|:----------------------------
 467 Ethernet         | Connect TX+ (Pin 1) with RX+ (Pin 3), TX- (Pin 2) with RX- (Pin 6)
 468 SPI              | Connect MISO to MOSI
 469 USART            | Connect TX with RX
 470
 471 The following picture shows the necessary external loop back connections for the Keil MCBSTM32F400 evaluation board:
 472  - SPI: PB14 (SPI2_MISO) and PB15 (SPI2_MOSI)
 473  - USART: PB6 (USART1_TX) and PB7 (USART1_RX)
 474  - Ethernet: Pin 1 (TX+) and Pin 3 (RX+), Pin 2 (TX-) and Pin 6 (RX-)
 475
 476 \image html image006.png  "Connections for Loop Back Communication Tests on Keil MCBSTM32F400"
 477
 478
 479 */