Infineon XMC4500 RM

XMC4500
Microcontroller Series
for Industrial Applications
XMC4000 Family
ARM Cortex-M4
32-bit processor core
Reference Manual
V1.0 2012-02
Microcontrollers
Edition 2012-02
Published by
Infineon Technologies AG
81726 Munich, Germany
2012 Infineon Technologies AG
All Rights Reserved.
Legal Disclaimer
The information given in this document shall in no event be regarded as a guarantee of conditions or
characteristics. With respect to any examples or hints given herein, any typical values stated herein and/or any
information regarding the application of the device, Infineon Technologies hereby disclaims any and all warranties
and liabilities of any kind, including without limitation, warranties of non-infringement of intellectual property rights
of any third party.
Information
For further information on technology, delivery terms and conditions and prices, please contact the nearest
Infineon Technologies Office (www.infineon.com).
Warnings
Due to technical requirements, components may contain dangerous substances. For information on the types in
question, please contact the nearest Infineon Technologies Office.
Infineon Technologies components may be used in life-support devices or systems only with the express written
approval of Infineon Technologies, if a failure of such components can reasonably be expected to cause the failure
of that life-support device or system or to affect the safety or effectiveness of that device or system. Life support
devices or systems are intended to be implanted in the human body or to support and/or maintain and sustain
and/or protect human life. If they fail, it is reasonable to assume that the health of the user or other persons may
be endangered.
XMC4500
Microcontroller Series
for Industrial Applications
XMC4000 Family
ARM Cortex-M4
32-bit processor core
Reference Manual
V1.0 2012-02
Microcontrollers
XMC4500
XMC4000 Family
XMC4500 Reference Manual
Revision History: V1.0 2012-02

Previous Versions:
Page Subjects
Trademarks
C166, TriCore and DAVE are trademarks of Infineon Technologies AG.
ARM, ARM Powered, Cortex and AMBA are registered trademarks of ARM, Limited.
CoreSight, ETM, Embedded Trace Macrocell and Embedded Trace Buffer are
trademarks of ARM, Limited.
Synopsys is a trademark of Synopsys, Inc.
We Listen to Your Comments

Is there any information in this document that you feel is wrong, unclear or missing?
Your feedback will help us to continuously improve the quality of this document.
Please send your proposal (including a reference to this document) to:
mcdocu.comments@infineon.com
Reference Manual V1.0, 2012-02

Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Table of Contents
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.1.1 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
1.2 CPU Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
1.3 On-Chip Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
1.4 Communication Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
1.5 Analog Frontend Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
1.6 Industrial Control Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
1.7 On-Chip Debug Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
2 Central Processing Unit (CPU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.2 Programmers Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
2.2.1 Processor Mode and Privilege Levels for Software Execution . . . . . . 2-4
2.2.2 Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
2.2.3 Core Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.2.4 Exceptions and Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
2.2.5 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
2.2.6 The Cortex Microcontroller Software Interface Standard . . . . . . . . . . 2-17
2.2.7 CMSIS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
2.3 Memory Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
2.3.1 Memory Regions, Types and Attributes . . . . . . . . . . . . . . . . . . . . . . . 2-20
2.3.2 Memory System Ordering of Memory Accesses . . . . . . . . . . . . . . . . 2-21
2.3.3 Behavior of Memory Accesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
2.3.4 Software Ordering of Memory Accesses . . . . . . . . . . . . . . . . . . . . . . 2-23
2.3.5 Memory Endianness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
2.3.6 Synchronization Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
2.3.7 Programming Hints for the Synchronization Primitives . . . . . . . . . . . 2-26
2.4 Instruction Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
2.5 Exception Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
2.5.1 Exception States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
2.5.2 Exception Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
2.5.3 Exception Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
2.5.4 Vector Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
2.5.5 Exception Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31
2.5.6 Interrupt Priority Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31
2.5.7 Exception Entry and Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32
2.6 Fault Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-36
2.6.1 Fault Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
Reference Manual L-1 V1.0, 2012-02

XMC4500
XMC4000 Family
Table of Contents
2.6.2 Fault Escalation and Hard Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-38

2.6.3 Fault Status Registers and Fault Address Registers . . . . . . . . . . . . . 2-39
2.6.4 Lockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
2.7 Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
2.7.1 Entering Sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
2.7.2 Wakeup from Sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
2.7.3 The External Event Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
2.7.4 Power Management Programming Hints . . . . . . . . . . . . . . . . . . . . . . 2-42
2.8 Private Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
2.8.1 About the Private Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
2.8.2 System control block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
2.8.2.1 System control block design hints and tips . . . . . . . . . . . . . . . . . . 2-43
2.8.3 System timer, SysTick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-43
2.8.3.1 SysTick design hints and tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-43
2.8.4 Nested Vectored Interrupt Controller (NVIC) . . . . . . . . . . . . . . . . . . . 2-43
2.8.4.1 Level-sensitive and pulse interrupts . . . . . . . . . . . . . . . . . . . . . . . 2-44
2.8.4.2 NVIC design hints and tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-45
2.8.4.3 Using CMSIS functions to access NVIC . . . . . . . . . . . . . . . . . . . . 2-45
2.8.5 Memory Protection Unit (MPU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
2.8.5.1 MPU Access Permission Attributes . . . . . . . . . . . . . . . . . . . . . . . . 2-48
2.8.5.2 MPU Mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50
2.8.5.3 Updating an MPU Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50
2.8.5.4 MPU Design Hints and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-53
2.8.6 Floating Point Unit (FPU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-53
2.8.6.1 Enabling the FPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54
2.9 PPB Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54
2.9.1 SCS Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-57
2.9.2 SysTick Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-83
2.9.3 NVIC Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-86
2.9.4 MPU Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-92
2.9.5 FPU Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-100
3 Bus System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.1 Bus Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.2 Bus Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
4 Service Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.1.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
4.1.3 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
4.2 Service Request Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.3 Interrupt Service Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
4.4 DMA Line Router (DLR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

XMC4500
XMC4000 Family
Table of Contents
4.4.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

4.4.2 DMA Service Request Source Selection . . . . . . . . . . . . . . . . . . . . . . 4-10
4.5 Event Request Unit (ERU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
4.5.1 Event Request Select Unit (ERS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
4.5.2 Event Trigger Logic (ETLx) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
4.5.3 Cross Connect Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
4.5.4 Output Gating Unit (OGUy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
4.6 Service Request Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
4.7 Debug Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
4.8 Power, Reset and Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
4.9 Initialization and System Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 4-23
4.10 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
4.10.1 DLR Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
4.10.2 ERU Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
4.11 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
4.11.1 ERU0 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
4.11.2 ERU1 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38
5 General Purpose DMA (GPDMA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
5.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
5.1.2 GPDMA Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
5.2 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
5.2.1 Basic Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
5.2.2 Block Flow Controller and Transfer Type . . . . . . . . . . . . . . . . . . . . . . 5-7
5.2.3 Handshaking Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
5.2.4 Basic Interface Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
5.2.5 Memory Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
5.2.6 Software Handshaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
5.2.7 Handshaking Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
5.2.7.1 Single Transaction Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
5.2.7.2 Early-Terminated Burst Transaction . . . . . . . . . . . . . . . . . . . . . . . 5-11
5.2.7.3 Hardware Handshaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
5.2.7.4 Software Handshaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
5.2.8 Single Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
5.2.9 Setting Up Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
5.2.9.1 Transfer Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
5.2.10 Flow Control Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
5.2.11 Generating Requests for the AHB Master Bus Interface . . . . . . . . . . 5-30
5.2.11.1 Locked DMA Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32
5.2.12 Arbitration for AHB Master Interface . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
5.2.13 Scatter/Gather . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36
5.3 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39

XMC4500
XMC4000 Family
Table of Contents
5.3.1 Illegal Register Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39

5.3.2 GPDMA Transfer Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39
5.3.2.1 Multi-Block Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40
5.3.2.2 Auto-Reloading of Channel Registers . . . . . . . . . . . . . . . . . . . . . . 5-44
5.3.2.3 Contiguous Address Between Blocks . . . . . . . . . . . . . . . . . . . . . . 5-44
5.3.2.4 Suspension of Transfers Between Blocks . . . . . . . . . . . . . . . . . . . 5-45
5.3.2.5 Ending Multi-Block Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-46
5.3.3 Programing Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-46
5.3.3.1 Single-block Transfer (Row 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-47
5.3.3.2 Multi-Block Transfer with Linked List for Source and Linked List for
Destination (Row 10) 5-48
5.3.3.3 Multi-Block Transfer with Source Address Auto-Reloaded and
Destination Address Auto-Reloaded (Row 4) 5-54
5.3.3.4 Multi-Block Transfer with Source Address Auto-Reloaded and Linked List
Destination Address (Row 7) 5-58
Contiguous Destination Address (Row 3) 5-64
5.3.3.6 Multi-Block DMA Transfer with Linked List for Source and Contiguous
Destination Address (Row 8) 5-67
5.3.3.7 Programming Example for Linked List Multi-Block Transfer . . . . . 5-70
5.3.4 Abnormal Transfer Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-74
5.6 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-76
5.6.1 Configuration and Channel Enable Registers . . . . . . . . . . . . . . . . . . 5-80
5.6.2 Channel Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-82
5.6.3 Interrupt Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-115
5.6.4 Software Handshaking Registers . . . . . . . . . . . . . . . . . . . . . . . . . . 5-128
5.6.5 Miscellaneous GPDMA Registers . . . . . . . . . . . . . . . . . . . . . . . . . . 5-138
6 Flexible CRC Engine (FCE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
6.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
6.1.2 Application Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
6.1.3 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
6.2 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
6.2.1 Basic Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
6.2.2 Automatic Signature Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
6.2.3 Register protection and monitoring methods . . . . . . . . . . . . . . . . . . . . 6-6
6.3 Service Request Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
6.4 Debug Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
6.5 Power, Reset and Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
6.6 Initialization and System Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . 6-9

XMC4500
XMC4000 Family
Table of Contents
6.7 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11

6.7.1 System Registers description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
6.7.2 CRC Kernel Control/Status Registers . . . . . . . . . . . . . . . . . . . . . . . . 6-14
6.8 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
6.9 Properties of CRC code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
7 Memory Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
7.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
7.1.2 Cortex-M4 Address Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
7.2 Memory Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.3 Memory Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.4 Service Request Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
7.5 Debug Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
7.7 Initialization and System Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
7.8 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
8 Flash and Program Memory Unit (PMU) . . . . . . . . . . . . . . . . . . . . . . . 8-1
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
8.1.1 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
8.2 Boot ROM (BROM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
8.2.1 BROM Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
8.3 Prefetch Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
8.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
8.3.2 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
8.3.2.1 Instruction Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
8.3.2.2 Data Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
8.3.2.3 PMU Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
8.4 Program Flash (PFLASH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
8.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
8.4.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
8.4.2 Definition of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
8.4.3 Flash Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7
8.4.4 Flash Read Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
8.4.5 Flash Write and Erase Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
8.4.6 Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
8.4.7 Command Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
8.4.7.1 Command Sequence Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
8.4.8 Flash Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
8.4.8.1 Configuring Flash Protection in the UCB . . . . . . . . . . . . . . . . . . . . 8-15
8.4.8.2 Flash Read Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
8.4.8.3 Flash Write and OTP Protection . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18
8.4.8.4 System Wide Effects of Flash Protection . . . . . . . . . . . . . . . . . . . . 8-20

XMC4500
XMC4000 Family
Table of Contents
8.4.9 Data Integrity and Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20

8.4.9.1 Error-Correcting Code (ECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
8.4.9.2 Margin Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
8.5 Service Request Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
8.5.1 Interrupt Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
8.5.2 Trap Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22
8.5.3 Handling Errors During Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22
8.5.3.1 SQER Sequence Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23
8.5.3.2 PFOPER Operation Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23
8.5.3.3 PROER Protection Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24
8.5.3.4 VER Verification Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25
8.5.3.5 PFSBER/DFSBER Single-Bit Error . . . . . . . . . . . . . . . . . . . . . . . 8-25
8.5.3.6 Handling Flash Errors During Startup . . . . . . . . . . . . . . . . . . . . . . 8-26
8.6.1 Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-27
8.6.2 Power Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-27
8.6.3 Reset Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28
8.6.3.1 Resets During Flash Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28
8.6.4 Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
8.7 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
8.7.1 PMU Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
8.7.1.1 PMU ID Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31
8.7.2 Prefetch Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
8.7.2.1 Prefetch Configuration Register . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
8.7.3 Flash Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33
8.7.3.1 Flash Status Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-34
8.7.3.2 Flash Configuration Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
8.7.3.3 Flash Identification Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-44
8.7.3.4 Margin Check Control Register . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-45
8.7.3.5 Protection Configuration Indication . . . . . . . . . . . . . . . . . . . . . . . . 8-46
9 Window Watchdog Timer (WDT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
9.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
9.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
9.2 Time-Out Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
9.3 Pre-warning Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
9.4 Bad Service Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
9.5 Service Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
9.6 Debug Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
9.8 Initialization and Control Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
9.8.1 Initialization & Start of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8

XMC4500
XMC4000 Family
Table of Contents
9.8.2 Reconfiguration & Restart of Operation . . . . . . . . . . . . . . . . . . . . . . . . 9-8

9.8.3 Software Stop & Resume Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
9.8.4 Enter Sleep/Deep Sleep & Resume Operation . . . . . . . . . . . . . . . . . . 9-9
9.8.5 Prewarning Alarm Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
9.9 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
9.9.1 Registers Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
9.10 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
10 Real Time Clock (RTC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
10.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
10.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
10.2 RTC Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
10.3 Register Access Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
10.4 Service Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
10.4.1 Periodic Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
10.4.2 Timer Alarm Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
10.5 Debug behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
10.7 Initialization and Control Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
10.7.1 Initialization & Start of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
10.7.2 Re-configuration & Re-start of Operation . . . . . . . . . . . . . . . . . . . . . 10-5
10.7.3 Configure and Enable Periodic Alarm . . . . . . . . . . . . . . . . . . . . . . . . 10-6
10.7.4 Configure and Enable Timer Alarm . . . . . . . . . . . . . . . . . . . . . . . . . 10-6
10.8 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
10.8.1 Registers Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
10.9 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19
11 System Control Unit (SCU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
11.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
11.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
11.2 Miscellaneous control functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
11.2.1 Startup Software Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
11.2.2 Service Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
11.2.2.1 Service Request Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
11.2.3 Memory Content Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
11.2.3.1 Parity Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
11.2.4 Trap Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10
11.2.4.1 Trap Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10
11.2.5 Die Temperature Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
11.2.6 Retention Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
11.2.7 Out of Range Comparator Control . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12
11.3 Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12

XMC4500
XMC4000 Family
Table of Contents
11.3.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12

11.3.2 System States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13
11.3.3 Hibernate Domain Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . 11-15
11.3.4 Embedded Voltage Regulator (EVR) . . . . . . . . . . . . . . . . . . . . . . . . 11-17
11.3.5 Supply Watchdog (SWD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17
11.3.6 Power Validation (PV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18
11.3.7 Supply Voltage Brown-out Detection . . . . . . . . . . . . . . . . . . . . . . . . 11-18
11.3.8 Hibernate Domain Power Management . . . . . . . . . . . . . . . . . . . . . . 11-19
11.3.9 Flash Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19
11.4 Hibernate Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19
11.5 Reset Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22
11.5.1 Supported Reset types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22
11.5.2 Peripheral Reset Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-23
11.5.3 Reset Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-23
11.6 Clock Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-24
11.6.1 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-24
11.6.2 Clock Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-25
11.6.3 Clock System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-26
11.6.3.1 Clock System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-28
11.6.4 High Precision Oscillator Circuit (OSCHP) . . . . . . . . . . . . . . . . . . . 11-32
11.6.5 Backup Clock Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-33
11.6.6 Main PLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-34
11.6.6.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-34
11.6.6.2 System PLL Functional Description . . . . . . . . . . . . . . . . . . . . . . . 11-34
11.6.6.3 Configuration and Operation of the Prescaler Mode . . . . . . . . . . 11-38
11.6.6.4 Bypass Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-39
11.6.6.5 System Oscillator Watchdog (OSC_WDG) . . . . . . . . . . . . . . . . . 11-39
11.6.6.6 VCO Power Down Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-40
11.6.6.7 PLL Power Down Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-40
11.6.7 USB PLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-40
11.6.8 Ultra Low Power Oscillator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-41
11.6.9 Slow Internal Clock Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-42
11.6.9.1 OSCULP Oscillator Watchdog (ULPWDG) . . . . . . . . . . . . . . . . . 11-42
11.6.10 Clock Gating Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-42
11.7 Debug Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-42
11.8 Power, Reset and Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-42
11.9 Initialization and System Dependencies . . . . . . . . . . . . . . . . . . . . . . . 11-43
11.10 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-45
11.10.1 GCU Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-50
11.10.2 PCU Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-96
11.10.3 HCU Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-101
11.10.4 RCU Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-109
11.10.5 CCU Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-127

XMC4500
XMC4000 Family
Table of Contents
11.11 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-150

12 LED and Touch-Sense (LEDTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1
12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1
12.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1
12.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
12.2 Functional Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
12.3 LED Drive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7
12.3.1 LED Pin Assignment and Current Capability . . . . . . . . . . . . . . . . . . . 12-9
12.4 Touchpad Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9
12.4.1 Finger Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13
12.5 Operating both LED Drive and Touch-Sense Modes . . . . . . . . . . . . . 12-13
12.6 Service Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14
12.7 Debug Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15
12.9 Initialisation and System Dependencies . . . . . . . . . . . . . . . . . . . . . . . 12-15
12.9.1 Function Enabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15
12.9.2 Interpretation of Bit Field FNCOL . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
12.9.3 LEDTS Timing Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17
12.9.4 Time-Multiplexed LED and Touch-Sense Functions on Pin . . . . . . 12-18
12.9.5 LEDTS Pin Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-18
12.9.6 Software Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20
12.9.7 Hardware Design Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-21
12.10 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-22
12.10.1 Registers Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23
12.11 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-36
13 SD/MMC Interface (SDMMC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
13.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
13.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
13.2 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4
13.3 Card Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6
13.4 Data Transfer Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6
13.5 Read/ Write Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7
13.5.1 Write Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7
13.5.2 Read Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7
13.5.3 Abort Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7
13.6 Special Command Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
13.7 Error Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10
13.8 Service Request Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10
13.9 Debug Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10
13.10 Power, Reset and Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10
13.11 Initialisation and System Dependencies . . . . . . . . . . . . . . . . . . . . . . . 13-12

XMC4500
XMC4000 Family
Table of Contents
13.11.1 Setup SDMMC Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-12

13.11.2 Read Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-14
13.11.3 Write Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-14
13.11.4 Abort Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-15
13.12 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-16
13.12.1 Registers Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-20
13.13 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-82
14 External Bus Unit (EBU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
14.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
14.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
14.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2
14.2 Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
14.2.1 Address/Data Bus, AD[31:0] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
14.2.2 Address Bus, A[24:16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
14.2.3 Chip Selects, CS[3:0] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
14.2.4 Read/Write Control Lines, RD, RD/WR . . . . . . . . . . . . . . . . . . . . . . . 14-4
14.2.5 Address Valid, ADV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
14.2.6 Byte Controls, BC[3:0] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
14.2.7 Burst Flash Clock Output/Input, BFCLKO/BFCLKI . . . . . . . . . . . . . . 14-5
14.2.8 Wait Input, WAIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
14.2.9 SDRAM Clock Output/Input SDCLKO/SDCLKI . . . . . . . . . . . . . . . . . 14-6
14.2.10 SDRAM Control Signals, CKE, CAS and RAS . . . . . . . . . . . . . . . . . 14-6
14.2.11 Bus Arbitration Signals, HOLD, HLDA, and BREQ . . . . . . . . . . . . . . 14-6
14.2.12 EBU Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
14.2.12.1 Allocation of Unused Signals as GPIO . . . . . . . . . . . . . . . . . . . . . 14-6
14.3 External Bus States when EBU inactive . . . . . . . . . . . . . . . . . . . . . . . . 14-8
14.4 Memory Controller Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
14.5 Memory Controller AHBIF Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10
14.5.1 AHB Error Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12
14.5.2 Read Data Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12
14.5.3 Write Data Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13
14.6 Clocking Strategy and Local Clock Generation . . . . . . . . . . . . . . . . . . 14-13
14.6.1 Clocking Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13
14.6.1.1 Clock Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-15
14.6.2 Standby Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-15
14.7 External Bus Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-15
14.7.1 External Memory Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-16
14.7.2 Chip Select Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-17
14.7.3 Programmable Device Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-17
14.7.4 Support for Multiplexed Device Configurations . . . . . . . . . . . . . . . . 14-18
14.7.5 Support for Non-Multiplexed Device Configurations . . . . . . . . . . . . 14-21
14.7.6 AHB Bus Width Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-22

XMC4500
XMC4000 Family
Table of Contents
14.7.7 Address Alignment During Bus Accesses . . . . . . . . . . . . . . . . . . . . 14-23

14.8 External Bus Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23
14.8.1 External Bus Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-24
14.8.2 Arbitration Signals and Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 14-24
14.8.3 Arbitration Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26
14.8.3.1 No Bus Arbitration Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26
14.8.3.2 Sole Master Arbitration Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26
14.8.3.3 Arbiter Mode Arbitration Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26
14.8.3.4 Participant Mode Arbitration Mode . . . . . . . . . . . . . . . . . . . . . . 14-30
14.8.4 Arbitration Input Signal Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . 14-32
14.8.5 Locking the External Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-33
14.8.6 Reaction to an AHB Access to the External Bus . . . . . . . . . . . . . . . 14-34
14.8.7 Pending Access Time-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35
14.8.8 Arbitrating SDRAM control signals . . . . . . . . . . . . . . . . . . . . . . . . . 14-35
14.9 Start-Up/Boot Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35
14.10 Standard Access Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35
14.10.1 Address Phase (AP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-36
14.10.2 Address Hold Phase (AH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-36
14.10.3 Command Delay Phase (CD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37
14.10.4 Command Phase (CP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37
14.10.5 Data Hold Phase (DH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-38
14.10.6 Burst Phase (BP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-38
14.10.7 Recovery Phase (RP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-39
14.11 Asynchronous Read/Write Accesses . . . . . . . . . . . . . . . . . . . . . . . . . . 14-40
14.11.1 Signal List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-41
14.11.2 Standard Asynchronous Access Phases . . . . . . . . . . . . . . . . . . . . . 14-41
14.11.3 Control of ADV & CS Delays During Asynchronous Accesses . . . . 14-41
14.11.4 Programmable Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-42
14.11.5 Accesses to Multiplexed Devices . . . . . . . . . . . . . . . . . . . . . . . . . . 14-44
14.11.6 Dynamic Command Delay and Wait State Insertion . . . . . . . . . . . . 14-45
14.11.6.1 External Extension of the Command Phase by WAIT . . . . . . . . . 14-45
14.11.7 Interfacing to Nand Flash Devices . . . . . . . . . . . . . . . . . . . . . . . . . . 14-47
14.11.7.1 NAND flash page mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-49
14.12 Synchronous Read/Write Accesses . . . . . . . . . . . . . . . . . . . . . . . . . . 14-51
14.12.1 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-52
14.12.2 Support for four Burst FLASH device types . . . . . . . . . . . . . . . . . . . 14-53
14.12.3 Typical Burst Flash Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-53
14.12.4 Burst Flash Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-54
14.12.5 Standard Access Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-55
14.12.6 Burst Length Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-55
14.12.7 Control of ADV & CS Delays During Burst FLASH Access . . . . . . . 14-55
14.12.8 Burst Flash Clock Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-56
14.12.9 Asynchronous Address Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-57

XMC4500
XMC4000 Family
Table of Contents
14.12.10 Page Mode Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-58

14.12.11 Critical Word First Read Accesses . . . . . . . . . . . . . . . . . . . . . . . . . 14-58
14.12.12 Example Burst Flash Access Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 14-59
14.12.13 External Cycle Control via the WAIT Input . . . . . . . . . . . . . . . . . . . 14-60
14.12.14 Flash Non-Array Access Support . . . . . . . . . . . . . . . . . . . . . . . . . . 14-61
14.12.15 Termination of a Burst Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-61
14.12.16 Burst Flash Device Programming Sequences . . . . . . . . . . . . . . . . . 14-62
14.12.17 Cellular RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-62
14.13 SDRAM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-66
14.13.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-66
14.13.2 Signal List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-67
14.13.3 External Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-67
14.13.4 External Bus Clock Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-68
14.13.5 SDRAM Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-69
14.13.6 Supported SDRAM commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-69
14.13.7 SDRAM device size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-71
14.13.8 Power Up Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-71
14.13.9 Initialization sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-72
14.13.10 Mobile SDRAM Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-75
14.13.11 Burst Accesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-75
14.13.12 Short Burst Accesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-76
14.13.13 Multibanking Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-76
14.13.14 Bank Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-77
14.13.15 Row Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-78
14.13.16 Banks Precharge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-80
14.13.17 Refresh Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-80
14.13.18 Self-Refresh Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-82
14.13.19 SDRAM Addressing Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-83
14.13.20 Power Down Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-89
14.13.21 SDRAM Recovery Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-91
14.14 Debug Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-93
14.15.1 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-93
14.15.2 Module Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-94
14.15.3 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-94
14.16 System Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-94
14.17 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-95
14.17.1 Clock Control Register, CLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-97
14.17.2 Configuration Register, MODCON . . . . . . . . . . . . . . . . . . . . . . . . . . 14-99
14.17.3 Address Select Register, ADDRSELx . . . . . . . . . . . . . . . . . . . . . . 14-101
14.17.4 Bus Configuration Register, BUSRCONx . . . . . . . . . . . . . . . . . . . 14-102

XMC4500
XMC4000 Family
Table of Contents
14.17.5 Bus Write Configuration Register, BUSWCONx . . . . . . . . . . . . . . 14-106

14.17.6 Bus Read Access Parameter Register, BUSRAPx . . . . . . . . . . . . 14-109
14.17.7 Bus Write Access Parameter Register, BUSWAPx . . . . . . . . . . . . 14-111
14.17.8 SDRAM Control Register, SDRMCON . . . . . . . . . . . . . . . . . . . . . 14-114
14.17.9 SDRAM Mode Register, SDRMOD . . . . . . . . . . . . . . . . . . . . . . . . 14-117
14.17.10 SDRAM Refresh Control Register, SDRMREF . . . . . . . . . . . . . . . 14-119
14.17.11 SDRAM Status Register, SDRSTAT . . . . . . . . . . . . . . . . . . . . . . . 14-121
14.17.12 Test/Control Configuration Register, USERCON . . . . . . . . . . . . . 14-122
15 Ethernet MAC (ETH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1
15.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1
15.1.1 ETH Core Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
15.1.2 DMA Block Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3
15.1.3 Transaction Layer (MTL) Features . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3
15.1.4 Monitoring, Test, and Debugging Support Features . . . . . . . . . . . . . 15-5
15.1.5 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5
15.2.1 ETH Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-6
15.2.1.1 Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-6
15.2.1.2 MAC Transmit Interface Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 15-10
15.2.1.3 Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-10
15.2.2 MAC Transaction Layer (MTL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-18
15.2.2.1 Transmit Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-18
15.2.2.2 Receive Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-24
15.2.3 DMA Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-26
15.2.3.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-27
15.2.3.2 Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-30
15.2.3.3 Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-35
15.2.3.4 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-39
15.2.4 DMA Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-41
15.2.4.1 Descriptor Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-41
15.2.5 MAC Management Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-57
15.2.6 Power Management Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-58
15.2.6.1 PMT Block Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-58
15.2.6.2 Remote Wake-Up Frame Detection . . . . . . . . . . . . . . . . . . . . . . . 15-60
15.2.6.3 Magic Packet Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-60
15.2.6.4 System Considerations During Power-Down . . . . . . . . . . . . . . . . 15-61
15.2.7 PHY Interconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-62
15.2.7.1 PHY Interconnect selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-62
15.2.8 Station Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-62
15.2.8.1 Station Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 15-63
15.2.8.2 Station Management Write Operation . . . . . . . . . . . . . . . . . . . . . 15-64
15.2.8.3 Station Management Read Operation . . . . . . . . . . . . . . . . . . . . . 15-64

XMC4500
XMC4000 Family
Table of Contents
15.2.9 Media Independent interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-65

15.2.10 Reduced Media Independent Interface . . . . . . . . . . . . . . . . . . . . . . 15-66
15.2.10.1 RMII Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-67
15.2.10.2 RMII Block Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-67
15.2.10.3 Transmit Bit Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-68
15.2.10.4 RMII Transmit Timing Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . 15-69
15.2.11 IEEE 1588-2002 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-72
15.2.11.1 Reference Timing Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-74
15.2.11.2 Transmit Path Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-74
15.2.11.3 Receive Path Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-74
15.2.11.4 Time Stamp Error Margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-75
15.2.11.5 Frequency Range of Reference Timing Clock . . . . . . . . . . . . . . . 15-75
15.2.11.6 Advanced Time Stamp Feature Support . . . . . . . . . . . . . . . . . . . 15-76
15.2.11.7 Peer-to-Peer PTP (Pdelay) Transparent Clock (P2P TC) Message
Support 15-76
15.2.11.8 Clock Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-78
15.2.11.9 PTP Processing and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-79
15.2.11.10 Reference Timing Source (for Advance Timestamp Feature) . . . 15-83
15.2.11.11 Transmit Path Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-84
15.2.11.12 Receive Path Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-84
15.2.12 System Time Register Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-85
15.2.13 Application BUS Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-87
15.3.1 DMA Service Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-90
15.3.2 Power Management Service Requests . . . . . . . . . . . . . . . . . . . . . . 15-90
15.3.3 System Time Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-90
15.3.4 MAC Management Counter Service Requests . . . . . . . . . . . . . . . . 15-90
15.4 Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-91
15.5 Power Reset and Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-91
15.6 ETH Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-92
15.6.1 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-92
15.6.2 Registers Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-93
15.6.2.1 Registers Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-110
15.7 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-321
15.7.1 ETH Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-322
16 Universal Serial Bus (USB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1
16.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1
16.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1
16.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2
16.2.1 OTG Dual-Role Device (DRD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3
16.2.2 USB Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3

XMC4500
XMC4000 Family
Table of Contents
16.2.3 USB Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4

16.2.4 FIFO Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5
16.2.4.1 Host FIFO Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5
16.2.4.2 Device FIFO Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6
16.3 Programming Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-7
16.3.1 Core Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-7
16.3.2 Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-7
16.3.2.1 Overview: DMA/Slave modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8
16.3.2.2 DMA Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8
16.3.2.3 Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8
16.4 Host Programming Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12
16.4.1 Host Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13
16.4.2 Channel Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13
16.4.3 Halting a Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14
16.4.4 Selecting the Queue Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-15
16.4.5 Handling Babble Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-16
16.4.6 Handling Disconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-16
16.4.7 Host Programming Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-16
16.4.7.1 Writing the Transmit FIFO in Slave Mode . . . . . . . . . . . . . . . . . . 16-18
16.4.7.2 Reading the Receive FIFO in Slave Mode . . . . . . . . . . . . . . . . . 16-19
16.4.7.3 Control Transactions in Host Slave Mode . . . . . . . . . . . . . . . . . . 16-20
16.4.7.4 Bulk and Control OUT/SETUP Transactions in Host Slave Mode 16-20
16.4.7.5 Bulk and Control IN Transactions in Host Slave Mode . . . . . . . . 16-23
16.4.7.6 Control Transactions in Host DMA Mode . . . . . . . . . . . . . . . . . . 16-25
16.4.7.7 Bulk and Control OUT/SETUP Transactions in Host DMA Mode 16-25
16.4.7.8 Bulk and Control IN Transactions in DMA Mode . . . . . . . . . . . . . 16-31
16.4.7.9 Interrupt OUT Transactions in Slave Mode . . . . . . . . . . . . . . . . . 16-33
16.4.7.10 Interrupt IN Transactions in Slave Mode . . . . . . . . . . . . . . . . . . . 16-36
16.4.7.11 Interrupt OUT Transactions in DMA Mode . . . . . . . . . . . . . . . . . 16-38
16.4.7.12 Interrupt IN Transactions in DMA Mode . . . . . . . . . . . . . . . . . . . 16-41
16.4.7.13 Isochronous OUT Transactions in Slave Mode . . . . . . . . . . . . . . 16-43
16.4.7.14 Isochronous IN Transactions in Slave Mode . . . . . . . . . . . . . . . . 16-46
16.4.7.15 Isochronous OUT Transactions in DMA Mode . . . . . . . . . . . . . . 16-48
16.4.7.16 Isochronous IN Transactions in Host DMA Mode . . . . . . . . . . . . 16-50
16.5 Host Scatter-Gather DMA Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-52
16.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-52
16.5.2 SPRAM Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-52
16.5.3 Descriptor Memory Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-52
16.5.4 IN Memory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-56
16.5.5 OUT Memory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-59
16.5.6 Host Scatter-Gather DMA Mode Programming Model . . . . . . . . . . 16-62
16.5.6.1 Channel Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-62
16.5.6.2 Asynchronous Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-62

XMC4500
XMC4000 Family
Table of Contents
16.5.6.3 Periodic Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-64

16.6 Device Programming Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-69
16.6.1 Device Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-69
16.6.2 Endpoint Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-69
16.6.2.1 Initialization on USB Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-69
16.6.2.2 Initialization on Enumeration Completion . . . . . . . . . . . . . . . . . . 16-70
16.6.2.3 Initialization on SetAddress Command . . . . . . . . . . . . . . . . . . . . 16-70
16.6.2.4 Initialization on SetConfiguration/SetInterface Command . . . . . . 16-71
16.6.2.5 Endpoint Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-71
16.6.2.6 Endpoint Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-72
16.6.2.7 Device DMA/Slave Mode Initialization . . . . . . . . . . . . . . . . . . . . . 16-72
16.6.3 Device Programming Operations (Non-Descriptor DMA Mode) . . . 16-73
16.6.3.1 OUT Data Transfers in Device Slave and Buffer DMA Modes . . 16-76
16.6.3.2 Control Transfers in Device Mode . . . . . . . . . . . . . . . . . . . . . . . . 16-81
16.6.3.3 IN Data Transfers in Device Slave and Buffer DMA Modes . . . 16-102
16.7 Device Scatter-Gather DMA Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 16-126
16.7.1 Scatter/Gather DMA Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-126
16.7.2 SPRAM Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-127
16.7.3 Descriptor Memory Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-127
16.7.3.1 OUT Data Memory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-128
16.7.3.2 Isochronous OUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-135
16.7.3.3 Non-Isochronous OUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-135
16.7.3.4 IN Data Memory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-135
16.7.3.5 Descriptor Update Interrupt Enable Modes . . . . . . . . . . . . . . . . 16-141
16.7.3.6 DMA Arbitration in Scatter/Gather DMA Mode . . . . . . . . . . . . . 16-141
16.7.3.7 Buffer Data Access on AHB in Scatter/Gather DMA Mode . . . . 16-141
16.7.4 Control Transfer Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-142
16.7.5 Interrupt Usage for Control Transfers . . . . . . . . . . . . . . . . . . . . . . 16-142
16.7.6 Application Programming Sequence . . . . . . . . . . . . . . . . . . . . . . . 16-143
16.7.7 Internal Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-150
16.7.7.1 Three-Stage Control Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-150
16.7.7.2 Three-Stage Control Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-153
16.7.7.3 Two-Stage Control Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-155
16.7.7.4 Back to Back SETUP During Control Write . . . . . . . . . . . . . . . . 16-156
16.7.7.5 Back-to-Back SETUPs During Control Read . . . . . . . . . . . . . . . 16-159
16.7.7.6 Extra Tokens During Control Write Data Phase . . . . . . . . . . . . 16-161
16.7.7.7 Extra Tokens During Control Read Data Phase . . . . . . . . . . . . 16-163
16.7.7.8 Premature SETUP During Control Write Data Phase . . . . . . . . 16-165
16.7.7.9 Premature SETUP During Control Read Data Phase . . . . . . . . 16-168
16.7.7.10 Premature Status During Control Write . . . . . . . . . . . . . . . . . . . 16-170
16.7.7.11 Premature Status During Control Read . . . . . . . . . . . . . . . . . . . 16-172
16.7.7.12 Lost ACK During Last Packet of Control Read . . . . . . . . . . . . . 16-174
16.7.8 Bulk IN Transfer Data Transaction in Scatter-Gather DMA Mode . 16-174

XMC4500
XMC4000 Family
Table of Contents
16.7.8.1 Interrupt usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-175

16.7.8.2 Application Programming Sequence . . . . . . . . . . . . . . . . . . . . . 16-175
16.7.8.3 Internal Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-177
16.7.9 Bulk OUT Data Transaction in Scatter-Gather Mode . . . . . . . . . . 16-180
16.7.9.1 Interrupt Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-180
16.7.9.2 Application Programming Sequence . . . . . . . . . . . . . . . . . . . . . 16-181
16.7.9.3 Internal Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-182
16.7.10 Interrupt IN Data Transaction in Scatter/Gather DMA Mode . . . . . 16-184
16.7.11 Interrupt OUT Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-184
16.7.12 Isochronous IN Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-185
16.7.12.1 Isochronous Transfers in Scatter/Gather (Descriptor DMA) Mode . . . . .
16-185
16.7.12.2 Internal Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-187
16.7.13 Isochronous OUT Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-190
16.8 OTG Revision 1.3 Programming Model . . . . . . . . . . . . . . . . . . . . . . . 16-192
16.8.1 A-Device Session Request Protocol . . . . . . . . . . . . . . . . . . . . . . . 16-192
16.8.2 B-Device Session Request Protocol . . . . . . . . . . . . . . . . . . . . . . . 16-193
16.8.3 A-Device Host Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . . . 16-195
16.8.4 B-Device Host Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . . . 16-196
16.9 Clock Gating Programming Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-197
16.9.1 Host Mode Suspend and Resume With Clock Gating . . . . . . . . . . 16-197
16.9.2 Host Mode Suspend and Remote Wakeup With Clock Gating . . . 16-198
16.9.3 Host Mode Session End and Start With Clock Gating . . . . . . . . . . 16-199
16.9.4 Host Mode Session End and SRP With Clock Gating . . . . . . . . . . 16-199
16.9.5 Device Mode Suspend and Resume With Clock Gating . . . . . . . . 16-200
16.9.6 Device Mode Suspend and Remote Wakeup With Clock Gating . 16-200
16.9.7 Device Mode Session End and Start With Clock Gating . . . . . . . . 16-201
16.9.8 Device Mode Session End and SRP With Clock Gating . . . . . . . . 16-201
16.10 FIFO RAM Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-201
16.10.1 Data FIFO RAM Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-201
16.10.1.1 Device Mode RAM Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . 16-203
16.10.1.2 Host Mode RAM Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-205
16.10.2 Dynamic FIFO Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-206
16.10.2.1 Host Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-206
16.10.2.2 Device Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-207
16.11 Service Request Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-209
16.12 Debug Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-210
16.13 Power, Reset and Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-210
16.14 Initialization and System Dependencies . . . . . . . . . . . . . . . . . . . . . . 16-210
16.15 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-211
16.15.1 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-218
16.16 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-340

XMC4500
XMC4000 Family
Table of Contents
17 Universal Serial Interface Channel (USIC) . . . . . . . . . . . . . . . . . . . . . 17-1

17.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1
17.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1
17.2 Operating the USIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-5
17.2.1 USIC Structure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-5
17.2.1.1 Channel Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-5
17.2.1.2 Input Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-5
17.2.1.3 Output Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-7
17.2.1.4 Baud Rate Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-8
17.2.1.5 Channel Events and Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-9
17.2.1.6 Data Shifting and Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-9
17.2.2 Operating the USIC Communication Channel . . . . . . . . . . . . . . . . . 17-13
17.2.2.1 Protocol Control and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14
17.2.2.2 Mode Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-15
17.2.2.3 General Channel Events and Interrupts . . . . . . . . . . . . . . . . . . . 17-16
17.2.2.4 Data Transfer Events and Interrupts . . . . . . . . . . . . . . . . . . . . . . 17-17
17.2.2.5 Baud Rate Generator Event and Interrupt . . . . . . . . . . . . . . . . . . 17-19
17.2.2.6 Protocol-specific Events and Interrupts . . . . . . . . . . . . . . . . . . . . 17-21
17.2.3 Operating the Input Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-21
17.2.3.1 General Input Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-22
17.2.3.2 Digital Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-24
17.2.3.3 Edge Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-24
17.2.3.4 Selected Input Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-25
17.2.3.5 Loop Back Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-25
17.2.4 Operating the Baud Rate Generator . . . . . . . . . . . . . . . . . . . . . . . . 17-25
17.2.4.1 Fractional Divider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-25
17.2.4.2 External Frequency Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-26
17.2.4.3 Divider Mode Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-26
17.2.4.4 Capture Mode Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-27
17.2.4.5 Time Quanta Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-28
17.2.4.6 Master and Shift Clock Output Configuration . . . . . . . . . . . . . . . 17-29
17.2.5 Operating the Transmit Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . 17-30
17.2.5.1 Transmit Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-30
17.2.5.2 Transmit Data Shift Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-31
17.2.5.3 Transmit Control Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-32
17.2.5.4 Transmit Data Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-33
17.2.6 Operating the Receive Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . 17-35
17.2.6.1 Receive Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-35
17.2.6.2 Receive Data Shift Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-36
17.2.6.3 Baud Rate Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-37
17.2.7 Hardware Port Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-37
17.2.8 Operating the FIFO Data Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-38
17.2.8.1 FIFO Buffer Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-39

XMC4500
XMC4000 Family
Table of Contents
17.2.8.2 Transmit Buffer Events and Interrupts . . . . . . . . . . . . . . . . . . . . . 17-40

17.2.8.3 Receive Buffer Events and Interrupts . . . . . . . . . . . . . . . . . . . . . 17-44
17.2.8.4 FIFO Buffer Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-49
17.2.8.5 FIFO Access Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-50
17.2.8.6 Handling of FIFO Transmit Control Information . . . . . . . . . . . . . . 17-51
17.3 Asynchronous Serial Channel (ASC = UART) . . . . . . . . . . . . . . . . . . . 17-53
17.3.1 Signal Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-53
17.3.2 Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-54
17.3.2.1 Idle Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-55
17.3.2.2 Start Bit Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-56
17.3.2.3 Data Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-56
17.3.2.4 Parity Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-56
17.3.2.5 Stop Bit(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-56
17.3.3 Operating the ASC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-57
17.3.3.1 Bit Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-57
17.3.3.2 Baud Rate Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-58
17.3.3.3 Noise Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-59
17.3.3.4 Collision Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-59
17.3.3.5 Pulse Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-59
17.3.3.6 Automatic Shadow Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 17-61
17.3.3.7 End of Frame Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-61
17.3.3.8 Mode Control Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-61
17.3.3.9 Disabling ASC Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-62
17.3.3.10 Protocol Interrupt Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-62
17.3.3.11 Data Transfer Interrupt Handling . . . . . . . . . . . . . . . . . . . . . . . . . 17-62
17.3.3.12 Baud Rate Generator Interrupt Handling . . . . . . . . . . . . . . . . . . . 17-63
17.3.3.13 Protocol-Related Argument and Error . . . . . . . . . . . . . . . . . . . . . 17-63
17.3.3.14 Receive Buffer Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-63
17.3.3.15 Sync-Break Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-64
17.3.3.16 Transfer Status Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-64
17.3.4 ASC Protocol Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-64
17.3.4.1 ASC Protocol Control Register . . . . . . . . . . . . . . . . . . . . . . . . . . 17-64
17.3.4.2 ASC Protocol Status Register . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-68
17.3.5 Hardware LIN Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-71
17.4 Synchronous Serial Channel (SSC) . . . . . . . . . . . . . . . . . . . . . . . . . . 17-73
17.4.1 Signal Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-73
17.4.1.1 Transmit and Receive Data Signals . . . . . . . . . . . . . . . . . . . . . . 17-75
17.4.1.2 Shift Clock Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-76
17.4.1.3 Slave Select Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-78
17.4.2 Operating the SSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-80
17.4.2.1 Automatic Shadow Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 17-80
17.4.2.2 Mode Control Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-80
17.4.2.3 Disabling SSC Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-81

XMC4500
XMC4000 Family
Table of Contents
17.4.2.4 Data Frame Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-81

17.4.2.5 Parity Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-81
17.4.2.6 Transfer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-83
17.4.2.7 Data Transfer Interrupt Handling . . . . . . . . . . . . . . . . . . . . . . . . . 17-83
17.4.2.8 Baud Rate Generator Interrupt Handling . . . . . . . . . . . . . . . . . . . 17-84
17.4.2.9 Protocol-Related Argument and Error . . . . . . . . . . . . . . . . . . . . . 17-84
17.4.2.10 Receive Buffer Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-84
17.4.2.11 Multi-IO SSC Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-84
17.4.3 Operating the SSC in Master Mode . . . . . . . . . . . . . . . . . . . . . . . . . 17-86
17.4.3.1 Baud Rate Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-87
17.4.3.2 MSLS Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-87
17.4.3.3 Automatic Slave Select Update . . . . . . . . . . . . . . . . . . . . . . . . . . 17-89
17.4.3.4 Slave Select Delay Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 17-90
17.4.3.5 Protocol Interrupt Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-91
17.4.3.6 End-of-Frame Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-92
17.4.4 Operating the SSC in Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 17-94
17.4.4.1 Protocol Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-94
17.4.4.2 End-of-Frame Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-95
17.4.5 SSC Protocol Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-96
17.4.5.1 SSC Protocol Control Registers . . . . . . . . . . . . . . . . . . . . . . . . . 17-96
17.4.5.2 SSC Protocol Status Register . . . . . . . . . . . . . . . . . . . . . . . . . . 17-100
17.4.6 SSC Timing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-102
17.4.6.1 Closed-loop Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-102
17.4.6.2 Delay Compensation in Master Mode . . . . . . . . . . . . . . . . . . . . 17-105
17.4.6.3 Complete Closed-loop Delay Compensation . . . . . . . . . . . . . . . 17-106
17.5 Inter-IC Bus Protocol (IIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-107
17.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-107
17.5.1.1 Signal Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-107
17.5.1.2 Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-108
17.5.1.3 Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-109
17.5.2 Operating the IIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-110
17.5.2.1 Transmission Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-111
17.5.2.2 Byte Stretching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-111
17.5.2.3 Master Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-111
17.5.2.4 Release of TBUF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-112
17.5.2.5 Mode Control Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-112
17.5.2.6 Data Transfer Interrupt Handling . . . . . . . . . . . . . . . . . . . . . . . . 17-112
17.5.2.7 IIC Protocol Interrupt Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-113
17.5.2.8 Baud Rate Generator Interrupt Handling . . . . . . . . . . . . . . . . . . 17-114
17.5.2.9 Receiver Address Acknowledge . . . . . . . . . . . . . . . . . . . . . . . . 17-114
17.5.2.10 Receiver Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-115
17.5.2.11 Receiver Status Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-115
17.5.3 Symbol Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-116

XMC4500
XMC4000 Family
Table of Contents
17.5.3.1 Start Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-117

17.5.3.2 Repeated Start Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-117
17.5.3.3 Stop Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-118
17.5.3.4 Data Bit Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-118
17.5.4 Data Flow Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-119
17.5.4.1 Transmit Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-119
17.5.4.2 Valid Master Transmit Data Formats . . . . . . . . . . . . . . . . . . . . . 17-121
17.5.4.3 Master Transmit/Receive Modes . . . . . . . . . . . . . . . . . . . . . . . . 17-124
17.5.4.4 Slave Transmit/Receive Modes . . . . . . . . . . . . . . . . . . . . . . . . . 17-126
17.5.5 IIC Protocol Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-127
17.5.5.1 IIC Protocol Control Registers . . . . . . . . . . . . . . . . . . . . . . . . . . 17-127
17.5.5.2 IIC Protocol Status Register . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-130
17.6 Inter-IC Sound Bus Protocol (IIS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-133
17.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-133
17.6.1.1 Signal Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-133
17.6.1.2 Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-134
17.6.1.3 Transfer Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-135
17.6.1.4 Connection of External Audio Components . . . . . . . . . . . . . . . . 17-135
17.6.2 Operating the IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-136
17.6.2.1 Frame Length and Word Length Configuration . . . . . . . . . . . . . 17-136
17.6.2.2 Automatic Shadow Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 17-137
17.6.2.3 Mode Control Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-137
17.6.2.4 Transfer Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-137
17.6.2.5 Parity Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-139
17.6.2.6 Transfer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-139
17.6.2.7 Data Transfer Interrupt Handling . . . . . . . . . . . . . . . . . . . . . . . . 17-139
17.6.2.8 Baud Rate Generator Interrupt Handling . . . . . . . . . . . . . . . . . . 17-140
17.6.2.9 Protocol-Related Argument and Error . . . . . . . . . . . . . . . . . . . . 17-140
17.6.2.10 Transmit Data Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-140
17.6.2.11 Receive Buffer Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-141
17.6.2.12 Loop-Delay Compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-141
17.6.3 Operating the IIS in Master Mode . . . . . . . . . . . . . . . . . . . . . . . . . 17-141
17.6.3.1 Baud Rate Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-142
17.6.3.2 WA Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-143
17.6.3.3 Master Clock Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-143
17.6.3.4 Protocol Interrupt Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-144
17.6.4 Operating the IIS in Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 17-144
17.6.4.1 Protocol Events and Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . 17-145
17.6.5 IIS Protocol Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-145
17.6.5.1 IIS Protocol Control Registers . . . . . . . . . . . . . . . . . . . . . . . . . . 17-145
17.6.5.2 IIS Protocol Status Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-147
17.7 Service Request Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-151
17.8 Debug Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-151

XMC4500
XMC4000 Family
Table of Contents
17.9 Power, Reset and Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-151

17.10 Initialization and System Dependencies . . . . . . . . . . . . . . . . . . . . . . 17-151
17.11 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-151
17.11.1 Address Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-155
17.11.2 Module Identification Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-156
17.11.3 Channel Control and Configuration Registers . . . . . . . . . . . . . . . . 17-157
17.11.3.1 Channel Control Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-157
17.11.3.2 Channel Configuration Register . . . . . . . . . . . . . . . . . . . . . . . . . 17-162
17.11.3.3 Kernel State Configuration Register . . . . . . . . . . . . . . . . . . . . . 17-163
17.11.3.4 Interrupt Node Pointer Register . . . . . . . . . . . . . . . . . . . . . . . . . 17-166
17.11.4 Protocol Related Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-167
17.11.4.1 Protocol Control Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-167
17.11.4.2 Protocol Status Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-168
17.11.4.3 Protocol Status Clear Register . . . . . . . . . . . . . . . . . . . . . . . . . 17-169
17.11.5 Input Stage Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-171
17.11.5.1 Input Control Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-171
17.11.6 Baud Rate Generator Registers . . . . . . . . . . . . . . . . . . . . . . . . . . 17-176
17.11.6.1 Fractional Divider Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-176
17.11.6.2 Baud Rate Generator Register . . . . . . . . . . . . . . . . . . . . . . . . . 17-177
17.11.6.3 Capture Mode Timer Register . . . . . . . . . . . . . . . . . . . . . . . . . . 17-180
17.11.7 Transfer Control and Status Registers . . . . . . . . . . . . . . . . . . . . . 17-180
17.11.7.1 Shift Control Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-180
17.11.7.2 Transmission Control and Status Register . . . . . . . . . . . . . . . . 17-184
17.11.7.3 Flag Modification Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-190
17.11.8 Data Buffer Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-192
17.11.8.1 Transmit Buffer Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-192
17.11.8.2 Receive Buffer Registers RBUF0, RBUF1 . . . . . . . . . . . . . . . . 17-193
17.11.8.3 Receive Buffer Registers RBUF, RBUFD, RBUFSR . . . . . . . . . 17-199
17.11.9 FIFO Buffer and Bypass Registers . . . . . . . . . . . . . . . . . . . . . . . . 17-203
17.11.9.1 Bypass Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-203
17.11.9.2 General FIFO Buffer Control Registers . . . . . . . . . . . . . . . . . . . 17-206
17.11.9.3 Transmit FIFO Buffer Control Registers . . . . . . . . . . . . . . . . . . 17-212
17.11.9.4 Receive FIFO Buffer Control Registers . . . . . . . . . . . . . . . . . . . 17-216
17.11.9.5 FIFO Buffer Data Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-221
17.11.9.6 FIFO Buffer Pointer Registers . . . . . . . . . . . . . . . . . . . . . . . . . . 17-224
17.12 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-225
17.12.1 USIC Module 0 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-226
18 Controller Area Network Controller (MultiCAN) . . . . . . . . . . . . . . . . 18-1
18.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2
18.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2

XMC4500
XMC4000 Family
Table of Contents
18.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-4

18.2 CAN Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-5
18.2.1 Addressing and Bus Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-5
18.2.2 CAN Frame Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-6
18.2.2.1 Data Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-6
18.2.2.2 Remote Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-8
18.2.2.3 Error Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-10
18.2.3 The Nominal Bit Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-11
18.2.4 Error Detection and Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 18-12
18.3 MultiCAN Kernel Functional Description . . . . . . . . . . . . . . . . . . . . . . . 18-14
18.3.1 Module Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-14
18.3.2 Port Input Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-16
18.3.3 CAN Node Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-17
18.3.3.1 Bit Timing Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-18
18.3.3.2 Bitstream Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-19
18.3.3.3 Error Handling Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-20
18.3.3.4 CAN Frame Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-21
18.3.3.5 CAN Node Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-21
18.3.4 Message Object List Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-23
18.3.4.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-23
18.3.4.2 List of Unallocated Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-24
18.3.4.3 Connection to the CAN Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-24
18.3.4.4 List Command Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-25
18.3.5 CAN Node Analysis Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-28
18.3.5.1 Analyzer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-28
18.3.5.2 Loop-Back Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-28
18.3.5.3 Bit Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-29
18.3.6 Message Acceptance Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-32
18.3.6.1 Receive Acceptance Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-32
18.3.6.2 Transmit Acceptance Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-33
18.3.7 Message Postprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-35
18.3.7.1 Message Object Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-35
18.3.7.2 Pending Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-37
18.3.8 Message Object Data Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-39
18.3.8.1 Frame Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-39
18.3.8.2 Frame Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-42
18.3.9 Message Object Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-45
18.3.9.1 Standard Message Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-45
18.3.9.2 Single Data Transfer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-45
18.3.9.3 Single Transmit Trial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-45
18.3.9.4 Message Object FIFO Structure . . . . . . . . . . . . . . . . . . . . . . . . . 18-46
18.3.9.5 Receive FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-48
18.3.9.6 Transmit FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-49

XMC4500
XMC4000 Family
Table of Contents
18.3.9.7 Gateway Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-50

18.3.9.8 Foreign Remote Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-52
18.5 Debug behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-55
18.6.1 Clock Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-56
18.6.2 Module Clock Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-58
18.7 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-59
18.7.1 Global Module Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-61
18.7.2 CAN Node Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-74
18.7.3 Message Object Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-93
18.7.4 MultiCAN Module External Registers . . . . . . . . . . . . . . . . . . . . . . 18-114
18.8 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-120
18.8.1 Interfaces of the MultiCAN Module . . . . . . . . . . . . . . . . . . . . . . . . 18-120
18.8.2 Port and I/O Line Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-121
18.8.2.1 Input/Output Function Selection in Ports . . . . . . . . . . . . . . . . . . 18-121
18.8.2.2 MultiCAN Interrupt Output Connections . . . . . . . . . . . . . . . . . . 18-123
18.8.2.3 Connections to USIC Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-123
19 Versatile Analog-to-Digital Converter (VADC) . . . . . . . . . . . . . . . . . 19-1
19.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-1
19.2 Introduction and Basic Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-4
19.3 Configuration of General Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-9
19.3.1 General Clocking Scheme and Control . . . . . . . . . . . . . . . . . . . . . . . 19-9
19.3.2 Priority Channel Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-10
19.4 Module Activation and Power Saving . . . . . . . . . . . . . . . . . . . . . . . . . 19-10
19.5 Conversion Request Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-11
19.5.1 Queued Request Source Handling . . . . . . . . . . . . . . . . . . . . . . . . . 19-13
19.5.2 Channel Scan Request Source Handling . . . . . . . . . . . . . . . . . . . . 19-16
19.6 Request Source Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-20
19.6.1 Arbiter Operation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . 19-21
19.6.2 Conversion Start Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-22
19.7 Analog Input Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 19-24
19.7.1 Channel Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-24
19.7.2 Conversion Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-26
19.7.3 Alias Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-27
19.7.4 Conversion Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-28
19.7.5 Compare with Standard Conversions (Limit Checking) . . . . . . . . . . 19-29
19.7.6 Utilizing Fast Compare Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-31
19.7.7 Boundary Flag Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-32
19.8 Conversion Result Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-33
19.8.1 Storage of Conversion Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-33
19.8.2 Data Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-35

XMC4500
XMC4000 Family
Table of Contents
19.8.3 Wait-for-Read Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-36

19.8.4 Result FIFO Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-37
19.8.5 Result Event Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-38
19.8.6 Data Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-39
19.9 Synchronization of Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-46
19.9.1 Synchronized Conversions for Parallel Sampling . . . . . . . . . . . . . . 19-46
19.9.2 Equidistant Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-49
19.10 Safety Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-50
19.10.1 Broken Wire Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-50
19.10.2 Signal Path Test Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-51
19.10.3 Configuration of Test Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-52
19.11 External Multiplexer Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-53
19.13 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-57
19.13.1 Module Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-60
19.13.2 System Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-61
19.13.3 General Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-64
19.13.4 Arbitration and Source Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-66
19.13.5 Channel Control Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-94
19.13.6 Result Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-99
19.13.7 Miscellaneous Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-107
19.13.8 Service Request Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-115
19.14 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-127
19.14.1 Product-Specific Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-127
19.14.2 Analog Module Connections in the XMC4500 . . . . . . . . . . . . . . . . 19-129
19.14.3 Digital Module Connections in the XMC4500 . . . . . . . . . . . . . . . . 19-131
20 Delta-Sigma Demodulator (DSD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-1
20.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-1
20.2 Introduction and Basic Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-4
20.3 Configuration of General Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-5
20.4 Input Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-5
20.4.1 Modulator Clock Selection and Generation . . . . . . . . . . . . . . . . . . . . 20-7
20.4.2 Input Data Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9
20.4.3 External Modulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-10
20.4.4 Input Path Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-10
20.5 Main Filter Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-11
20.5.1 Comb Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-11
20.5.2 Integrator Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-12
20.6 Auxiliary Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-13
20.7 Conversion Result Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-15
20.9 Resolver Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-16

XMC4500
XMC4000 Family
Table of Contents
20.9.1 Carrier Signal Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-16

20.9.2 Return Signal Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-17
20.10 Time-Stamp Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-19
20.11 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-19
20.11.1 Module Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-20
20.11.2 System Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-21
20.11.3 General Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-23
20.11.4 Input Path Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-24
20.11.5 Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-28
20.11.6 Conversion Result Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-32
20.11.7 Service Request Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-34
20.11.8 Miscellaneous Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-35
20.12 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-39
20.12.1 Product-Specific Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-39
20.12.2 Digital Module Connections in the XMC4500 . . . . . . . . . . . . . . . . . 20-40
21 Digital to Analog Converter (DAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-1
21.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-1
21.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-1
21.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-2
21.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-3
21.2.1 Hardware features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-3
21.2.1.1 Trigger Generators (TG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-3
21.2.1.2 Data FIFO buffer (FIFO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-4
21.2.1.3 Data output stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-5
21.2.1.4 Pattern Generators (PG) - Waveform Generator . . . . . . . . . . . . . . 21-6
21.2.1.5 Noise Generators (NG) - Pseudo Random Number Generator . . . 21-7
21.2.1.6 Ramp Generators (RG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-7
21.2.2 Entering any Operating Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-8
21.2.3 Single Value Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-8
21.2.4 Data Processing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-9
21.2.4.1 FIFO Data Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-9
21.2.5 Pattern Generation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-10
21.2.6 Noise Generation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-11
21.2.7 Ramp Generation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-12
21.5 Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-13
21.6 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-15
21.6.1 Address Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-15
21.6.2 Register Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-15
21.6.3 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-16
21.6.3.1 DAC_ID Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-16

XMC4500
XMC4000 Family
Table of Contents
21.6.3.2 DAC Configuration Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-17

21.6.3.3 DAC Data Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-24
21.6.3.4 DAC Pattern Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-25
21.7 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-28
21.7.1 Analog Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-28
21.7.2 Digital Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-28
21.7.2.1 Service Request Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-29
21.7.2.2 Trigger Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-29
21.7.2.3 Synchronization Interface of the Pattern Generator . . . . . . . . . . 21-29
22 Capture/Compare Unit 4 (CCU4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-1
22.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-1
22.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-2
22.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-4
22.2.1 CC4y Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-6
22.2.2 Input Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-8
22.2.3 Connection Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-10
22.2.4 Starting/Stopping the Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-12
22.2.5 Counting Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-13
22.2.5.1 Calculating the PWM Period and Duty Cycle . . . . . . . . . . . . . . . 22-13
22.2.5.2 Updating the Period and Duty Cycle . . . . . . . . . . . . . . . . . . . . . . 22-14
22.2.5.3 Edge Aligned Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-18
22.2.5.4 Center Aligned Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-19
22.2.5.5 Single Shot Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-20
22.2.6 Active/Passive Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-21
22.2.7 External Events Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-21
22.2.7.1 External Start/Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-22
22.2.7.2 External Counting Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-24
22.2.7.3 External Gating Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-26
22.2.7.4 External Count Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-26
22.2.7.5 External Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-27
22.2.7.6 External Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-28
22.2.7.7 External Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-34
22.2.7.8 TRAP Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-36
22.2.7.9 Status Bit Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-38
22.2.8 Multi-Channel Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-39
22.2.9 Timer Concatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-42
22.2.10 PWM Dithering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-47
22.2.11 Prescaler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-52
22.2.11.1 Normal Prescaler Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-53
22.2.11.2 Floating Prescaler Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-53
22.2.12 CCU4 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-55

XMC4500
XMC4000 Family
Table of Contents
22.2.12.1 PWM Signal Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-55

22.2.12.2 Prescaler Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-57
22.2.12.3 PWM Dither . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-59
22.2.12.4 Capture Mode Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-62
22.4 Debug Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-70
22.5.1 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-70
22.5.2 Module Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-71
22.5.3 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-72
22.6.1 Initialization Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-72
22.6.2 System Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-72
22.7 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-74
22.7.1 Global Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-80
22.7.2 Slice (CC4y) Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-97
22.8 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-130
22.8.1 CCU40 Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-130
22.8.2 CCU41 Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-135
22.8.3 CCU42 pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-141
22.8.4 CCU43 pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-145
23 Capture/Compare Unit 8 (CCU8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-1
23.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-1
23.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-2
23.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-5
23.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-7
23.2.2 Input Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-9
23.2.3 Connection Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-11
23.2.4 Start/Stop Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-13
23.2.5 Counting Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-14
23.2.5.1 Calculating the PWM Period and Duty Cycle . . . . . . . . . . . . . . . 23-15
23.2.5.2 Updating the Period and Duty Cycle . . . . . . . . . . . . . . . . . . . . . . 23-15
23.2.5.3 Edge Aligned Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-19
23.2.5.4 Center Aligned Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-20
23.2.5.5 Single Shot Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-21
23.2.6 Active/Passive Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-22
23.2.7 Compare Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-22
23.2.7.1 Edge Aligned Compare Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 23-27
23.2.7.2 Center Aligned Compare Modes . . . . . . . . . . . . . . . . . . . . . . . . . 23-31
23.2.8 External Events Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-34
23.2.8.1 External Start/Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-34

XMC4500
XMC4000 Family
Table of Contents
23.2.8.2 External Counting Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-37

23.2.8.3 External Gating Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-38
23.2.8.4 External Count Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-39
23.2.8.5 External Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-40
23.2.8.6 External Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-41
23.2.8.7 External Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-46
23.2.8.8 Trap Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-48
23.2.8.9 Status Bit Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-51
23.2.9 Multi-Channel Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-52
23.2.10 Timer Concatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-57
23.2.11 Output Parity Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-62
23.2.12 PWM Dithering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-66
23.2.13 Prescaler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-70
23.2.13.1 Normal Prescaler Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-71
23.2.13.2 Floating Prescaler Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-71
23.2.14 CCU8 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-73
23.2.14.1 PWM Signal Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-73
23.2.14.2 Prescaler Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-75
23.2.14.3 PWM Dither . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-78
23.2.14.4 Capture Mode Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-80
23.2.14.5 Parity Checker Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-85
23.4 Debug Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-91
23.5.1 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-92
23.5.2 Module Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-92
23.5.3 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-93
23.6.1 Initialization Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-93
23.7 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-95
23.7.1 Global Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-103
23.7.2 Slice (CC8y) Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-123
23.8 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-167
23.8.1 CCU80 Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-167
23.8.2 CCU81 Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-175
24 Position Interface Unit (POSIF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-1
24.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-1
24.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-2
24.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-3
24.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-4

XMC4500
XMC4000 Family
Table of Contents
24.2.2 Function Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-6

24.2.3 Hall Sensor Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-7
24.2.4 Quadrature Decoder Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-13
24.2.4.1 Quadrature Clock and Direction decoding . . . . . . . . . . . . . . . . . . 24-16
24.2.4.2 Index Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-17
24.2.5 Stand-Alone Multi-Channel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 24-18
24.2.6 Synchronous Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-18
24.2.7 Using the POSIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-19
24.2.7.1 Hall Sensor Mode Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-19
24.2.7.2 Quadrature Decoder Mode usage . . . . . . . . . . . . . . . . . . . . . . . . 24-21
24.2.7.3 Stand-alone Multi-Channel Mode . . . . . . . . . . . . . . . . . . . . . . . . 24-27
24.3.1 Hall Sensor Mode flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-28
24.3.2 Quadrature Decoder Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-30
24.4 Debug Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-32
24.5.1 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-33
24.5.2 Module Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-33
24.5.3 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-34
24.6.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-34
24.7 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-36
24.7.1 Global registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-38
24.7.2 Hall Sensor Mode Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-45
24.7.3 Multi-Channel Mode Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-47
24.7.4 Quadrature Decoder Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-52
24.7.5 Interrupt Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-53
24.8 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-60
24.8.1 POSIF0 Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-61
24.8.2 POSIF1 Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-65
25 General Purpose I/O Ports (PORTS) . . . . . . . . . . . . . . . . . . . . . . . . . 25-1
25.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-1
25.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-2
25.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-2
25.1.3 Definition of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-3
25.2 GPIO and Alternate Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-4
25.2.1 Input Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-4
25.2.2 Output Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-5
25.3 Hardware Controlled I/Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-6
25.4 Power Saving Mode Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-7
25.5 Analog Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-8

XMC4500
XMC4000 Family
Table of Contents

25.8 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-11
25.8.1 Port Input/Output Control Registers . . . . . . . . . . . . . . . . . . . . . . . . . 25-14
25.8.2 Pad Driver Mode Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-18
25.8.3 Pin Function Decision Control Register . . . . . . . . . . . . . . . . . . . . . . 25-22
25.8.4 Port Output Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-30
25.8.5 Port Output Modification Register . . . . . . . . . . . . . . . . . . . . . . . . . . 25-31
25.8.6 Port Input Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-32
25.8.7 Port Pin Power Save Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-33
25.8.8 Port Pin Hardware Select Register . . . . . . . . . . . . . . . . . . . . . . . . . 25-34
25.9 Package Pin Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-36
25.10 Port I/O Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-42
25.10.1 Port I/O Function Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-43
26 Startup modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-1
26.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-1
26.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-1
26.2 Startup modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-3
26.2.1 Reset types and corresponding boot modes . . . . . . . . . . . . . . . . . . . 26-3
26.2.2 Initial boot sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-4
26.2.3 Boot mode selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-5
26.2.4 Normal boot mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-6
26.2.5 Boot from PSRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-11
26.2.6 Alternative boot mode - Address0 (ABM-0) . . . . . . . . . . . . . . . . . . . 26-12
26.2.7 Alternative boot mode - Address1 (ABM-1) . . . . . . . . . . . . . . . . . . . 26-15
26.2.8 Fallback ABM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-15
26.2.9 ASC BSL mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-15
26.2.10 CAN BSL mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-18
26.2.11 Boot Mode Index (BMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-21
26.3 Debug behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-24
26.3.1 Boot modes and hardware debugger support . . . . . . . . . . . . . . . . . 26-24
26.3.2 Failures and handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-25
27 Debug and Trace System (DBG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-1
27.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-1
27.2 Debug System Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-3
27.2.1 Flash Patch Breakpoint (FPB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-4
27.2.2 Data Watchpoint and Trace (DWT) . . . . . . . . . . . . . . . . . . . . . . . . . . 27-4
27.2.3 Instrumentation Trace Macrocell (ITM) . . . . . . . . . . . . . . . . . . . . . . . 27-4
27.2.4 Embedded Trace Macrocell (ETM) . . . . . . . . . . . . . . . . . . . . . . . . . . 27-4
27.2.5 Trace Port Interface Unit (TPIU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-5

XMC4500
XMC4000 Family
Table of Contents
27.3.1 Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-5

27.3.1.1 CoreSightTM resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-5
27.3.1.2 Serial Wire interface driven system reset . . . . . . . . . . . . . . . . . . . 27-6
27.4.1 Debug accesses and Flash protection . . . . . . . . . . . . . . . . . . . . . . . . 27-6
27.4.2 Halt after reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-6
27.4.3 Halting Debug and Peripheral Suspend . . . . . . . . . . . . . . . . . . . . . . 27-9
27.4.4 Timestamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-11
27.4.5 Debug tool interface access (SWJ-DP) . . . . . . . . . . . . . . . . . . . . . . 27-11
27.4.5.1 Switch from JTAG to SWD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-11
27.4.5.2 Switch from SWD to JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-11
27.4.6 ID Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-11
27.4.7 ROM Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-12
27.4.8 JTAG debug port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-12
27.5 Debug System Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-14
27.6 Debug and Trace Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-14
27.6.1 Internal pull-up and pull-down on JTAG pins . . . . . . . . . . . . . . . . . . 27-15
27.6.2 Debug Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-16

XMC4500
XMC4000 Family
About this Document
About this Document

This Reference Manual is addressed to embedded hardware and software developers.
It provides the reader with detailed descriptions about the behavior of the XMC4500
series functional units and their interaction.
The manual describes the functionality of the superset device of the XMC4500
microcontroller series. For the available functionality (features) of a specific XMC4500
derivative (derivative device), please refer to the respective Data Sheet. For simplicity,
the various device types are referenced by the collective term XMC4500 throughout this
manual.
XMC4000 Family User Documentation

The set of user documentation includes:
Reference Manual
decribes the functionality of the superset device.
Data Sheets
list the complete ordering information, available features and electrical
characteristics of derivative devices.
Errata Sheets
list deviations from the specifications given in the related Reference Manual or
Data Sheets. Errata Sheets are provided for the superset of devices.
Attention: Please consult all parts of the documentation set to attain consolidated
knowledge about your device.
Application related guidance is provided by Users Guides and Application Notes.
Please refer to http://www.infineon.com/xmc4000 to get access to the latest versions
of those documents.
Related Documentation
The following documents are referenced:
ARM Cortex-M4
Technical Reference Manual
User Guide, Reference Material
ARMv7-M Architecture Reference Manual
AMBA 3 AHB-Lite Protocol Specification
Copyright Notice
Portions of SDMMC chapter Copyright 2010 by Arasan Chip Systems, Inc. All
rights reserved. Used with permission.
Portions of CPU chapter Copyright 2009, 2010 by ARM, Ltd. All rights reserved.
Used with permission.
Reference Manual P-1 V1.0, 2012-02

Preface, V1.2 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
About this Document
Portions of ETH, USB and GPDMA chapter Copyright 2009, 2010 by Synopsys,
Inc. All rights reserved. Used with permission.
Text Conventions
This document uses the following naming conventions:
Functional units of the device are given in plain UPPER CASE. For example: The
USIC0 unit supports.
Pins using negative logic are indicated by an overline. For example: The WAIT input
has.
Bit fields and bits in registers are generally referenced as
Module_RegisterName.BitField or Module_RegisterName.Bit. For example: The
USIC0_PCR.MCLK bit enables the. Most of the register names contain a module
name prefix, separated by an underscore character _ from the actual register name
(for example, USIC0_PCR, where USIC0 is the module name prefix, and PCR
is the kernel register name). In chapters describing the kernels of the peripheral
modules, the registers are mainly referenced with their kernel register names. The
peripheral module implementation sections mainly refer to the actual register names
with module prefixes.
Variables used to describe sets of processing units or registers appear in mixed
upper and lower cases. For example, register name MOFCRn refers to multiple
MOFCR registers with variable n. The bounds of the variables are always given
where the register expression is first used (for example, n = 0-31), and are repeated
as needed in the rest of the text.
The default radix is decimal. Hexadecimal constants are suffixed with a subscript
letter H, as in 100H. Binary constants are suffixed with a subscript letter B, as in:
111B.
When the extent of register fields, groups register bits, or groups of pins are
collectively named in the body of the document, they are represented as
NAME[A:B], which defines a range for the named group from B to A. Individual bits,
signals, or pins are given as NAME[C] where the range of the variable C is given in
the text. For example: CFG[2:0] and SRPN[0].
Units are abbreviated as follows:
MHz = Megahertz
s = Microseconds
kBaud, kbit/s = 1000 characters/bits per second
MBaud, Mbit/s, Mbps = 1,000,000 characters/bits per second
Kbyte, KB = 1024 bytes of memory
Mbyte, MB = 1048576 bytes of memory
In general, the k prefix scales a unit by 1000 whereas the K prefix scales a unit by
1024. Hence, the Kbyte unit scales the expression preceding it by 1024. The
kBaud unit scales the expression preceding it by 1000. The M prefix scales by
1,000,000 or 1048576. For example, 1 Kbyte is 1024 bytes, 1 Mbyte is

XMC4500
XMC4000 Family
About this Document
1024 1024 bytes, 1 kBaud/kbit are 1000 characters/bits per second,

1 MBaud/Mbit are 1000000 characters/bits per second, and 1 MHz is 1,000,000
Hz.
Data format quantities are defined as follows:
Byte = 8-bit quantity
Half-word = 16-bit quantity
Word = 32-bit quantity
Double-word = 64-bit quantity
Bit Function Terminology

In tables where register bits or bit fields are defined, the following conventions are used
to indicate the access types.
Table 1 Bit Function Terminology

Bit Function Description
rw The bit or bit field can be read and written.
rwh As rw, but bit or bit field can be also set or reset by hardware. If
not otherwise documented the software takes priority in case of
a write conflict between software and hardware.
r The bit or bit field can only be read (read-only).
w The bit or bit field can only be written (write-only). A read to this
register will always give a default value back.
rh This bit or bit field can be modified by hardware (read-hardware,
typical example: status flags). A read of this bit or bit field give
the actual status of this bit or bit field back. Writing to this bit or
bit field has no effect to the setting of this bit or bit field.
Register Access Modes

Read and write access to registers and memory locations are sometimes restricted. In
memory and register access tables, the following terms are used.
Table 2 Register Access Modes

Symbol Description
U Access permitted when software executes on Unprivileged level.
PV Access permitted when software executes on Privileged level.
32 Only 32-bit word accesses are permitted to this register/address range.
NC No change, indicated register is not changed.

XMC4500
XMC4000 Family
About this Document
Table 2 Register Access Modes (contd)

Symbol Description
BE Indicates that an access to this address range generates a Bus Error.
nBE Indicates that no Bus Error is generated when accessing this address
range.
Reserved Bits
Register bit fields named Reserved or 0 indicate unimplemented functions with the
following behavior:
Reading these bit fields returns 0.
These bit fields should be written with 0 if the bit field is defined as r or rh.
These bit fields must to be written with 0 if the bit field is defined as rw.
Abbreviations and Acronyms

The following acronyms and terms are used in this document:
ADC Analog-to-Digital Converter

AHB Advanced High-performance Bus
AMBA Advanced Microcontroller Bus Architecture
ASC Asynchronous Serial Channel
BMI Boot Mode Index
BROM Boot ROM
CAN Controller Area Network
CMSIS Cortex Microcontroller Software Interface Standard
CPU Central Processing Unit
CRC Cyclic Redundancy Code
CCU4 Capture Compare Unit 4
CCU8 Capture Compare Unit 8
DAC Digital to Analog Converter
DSD Delta Sigma Demodulator
DSRAM Data SRAM
DMA Direct Memory Access
EBU External Bus Interface
ECC Error Correction Code

XMC4500
XMC4000 Family
About this Document
ERU Event Request Unit

ETH Ethernet Unit
FCE Flexible CRC Engine
FCS Flash Command State Machine
FIM Flash Interface and Control Module
FPU Floating Point Unit
GPDMA General Purpose Direct Memory Access
GPIO General Purpose Input/Output
HMI Human-Machine Interface
IIC Inter Integrated Circuit (also known as I2C)
IIS Inter-IC Sound Interface
I/O Input / Output
JTAG Joint Test Action Group = IEEE1149.1
LED Light Emitting Diode
LEDTS LED and Touch Sense (Control Unit)
LIN Local Interconnect Network
MPU Memory Protection Unit
MSB Most Significant Bit
NC Not Connected
NMI Non-Maskable Interrupt
NVIC Nested Vectored Interrupt Controller
OCDS On-Chip Debug System
OTP One Time Programmable
PBA Peripheral Bridge AHB to AHB
PFLASH Program Flash Memory
PLL Phase Locked Loop
PMU Program Memory Unit
POSIF Position Interface
PSRAM Program SRAM
RAM Random Access Memory
RTC Real Time Clock
SCU System Control Unit

XMC4500
XMC4000 Family
About this Document
SDMMC Secure Digital / Multi Media Card (Interface)

SDRAM Synchronous Dynamic Random Access Memory
SFR Special Function Register
SPI Serial Peripheral Interface
SRAM Static RAM
SR Service Request
SSC Synchronous Serial Channel
SSW Startup Software
UART Universal Asynchronous Receiver Transmitter
UCB User Configuration Block
USB Universal Serial Bus
USIC Universal Serial Interface Channel
WDT Watchdog Timer

XMC4500
XMC4000 Family
Introduction
Introduction

XMC4500
XMC4000 Family
Introduction
1 Introduction
The XMC4500 series belongs to the XMC4000 family of industrial microcontrollers
based on the ARM Cortex-M4 processor core. The XMC4500 series devices are
optimized for electrical motor control, power conversion, industrial connectivity and
sense & control applications.
The growing complexity of today's energy efficient embedded control applications are
demanding microcontroller solutions with higher performance CPU cores featuring DSP
(Digital Signal Processing) and FPU (Floating Point Unit) capabilities as well as
integrated peripherals that are optimized for performance. Complemented with a
development environment designed to shorten product development time and increase
productivity, the XMC4500 series of microcontrollers take advantage of Infineon's
decades of experience in microcontroller design, providing an optimized solution to meet
the performance challenges of today's embedded control applications.
1.1 Overview
The XMC4500 series devices combine the extended functionality and performance of
the ARM Cortex-M4 core with powerful on-chip peripheral subsystems and on-chip
memory units. The following key features are available in the XMC4500 series devices:
CPU Subsystem
CPU Core
High Performance 32-bit ARM Cortex-M4 CPU
16-bit and 32-bit Thumb2 instruction set
DSP/MAC instructions
System timer (SysTick) for Operating System support
Floating Point Unit
Memory Protection Unit
Nested Vectored Interrupt Controller
Two General Purpose DMA with up to 12 channels
Event Request Unit (ERU) for programmable processing of external and internal
service requests
Flexible CRC Engine (FCE) for multiple bit error detection
On-Chip Memories
16 KB on-chip boot ROM
64 KB on-chip high-speed program memory
64 KB on-chip high speed data memory
32 KB on-chip high-speed communication
1024 KB on-chip Flash Memory with 4 KB instruction cache
Reference Manual 1-1 V1.0, 2012-02

Architectural Overview, V1.1 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Introduction
Communication Peripherals
Ethernet MAC module capable of 10/100 Mbit/s transfer rates
Universal Serial Bus, USB 2.0 host, Full-Speed OTG, with integrated PHY
Controller Area Network interface (MultiCAN), Full-CAN/Basic-CAN with 3 nodes, 64
message objects, data rate up to 1 Mbit/s
Six Universal Serial Interface Channels (USIC), usable as UART, double-SPI,
quadSPI, IIC, IIS and LIN interfaces
LED and Touch-Sense Controller (LEDTS) for Human-Machine interface
SD and Multi-Media Card interface (SDMMC) for data storage memory cards
External Bus Interface Unit (EBU) enabling communication with external memories
and off-chip peripherals like SRAM, SDRAM, NOR, NAND and Burst Flash.
Analog Frontend Peripherals

Four Analog-Digital Converters (VADC) of 12-bit resolution, 8 channels each with
input out-of-range comparators for overvoltage detection
Delta Sigma Demodulator with four channels, digital input stage for A/D signal
conversion as digital filter input stage for direct sigma-delta modulator usage
Digital-Analogue Converter (DAC) with two channels of 12-bit resolution
Industrial Control Peripherals

Two Capture/Compare Units 8 (CCU8) for motor control and power conversion
Four Capture/Compare Units 4 (CCU4) for use as general purpose timers
Two Position Interfaces (POSIF) for hall and quadratur encoders and motor
positioning
Window Watchdog Timer (WDT) for safety sensitive applications
Die Temperature Sensor (DTS)
Real Time Clock module with alarm support
System Control Unit (SCU) for system configuration and control
Input/Output Lines
Programmable port driver control module (PORTS)
Individual bit addressability
Tri-stated in input mode
Push/pull or open drain output mode
Boundary scan test support over JTAG interface
On-Chip Debug Support

Full support for debug features: 8 breakpoints, CoreSight, trace
Various interfaces: ARM-JTAG, SWD, single wire trace

XMC4500
XMC4000 Family
Introduction
Packages
PG-LQFP-144
PG-LQFP-100
PG-LFBGA-144
Note: For details about package availability for a particular derivative please check the
datasheet. For information on available delivery options for assembly support and
general package see http://www.infineon.com/packages
1.1.1 Block Diagram

The diagram below shows the functional blocks and their basic connectivity within the
XMC4500 System.
System System SCU

Masters Slaves
CPU RTC
TM
ARM Cortex -M4 ERU0
USB WDT
GPDMA0 GPDMA1 Ethernet
OTG
System DCode ICode FCE
Bus Matrix
Data Code
PMU PSRAM DSRAM1 DSRAM2 EBU
ROM & Flash
USIC0 DSD POSIF1 CCU80 CCU81 LEDTS0 CCU43 PORTS DAC
PBA0 Peripherals 0 Peripherals 1 PBA1
ERU1 VADC POSIF0 CCU40 CCU41 CCU42 SDMMC USIC2 USIC1 CAN
Figure 1-1 XMC4500 System

XMC4500
XMC4000 Family
Introduction
1.2 CPU Subsystem

The XMC4500 system core consists of the CPU (including FPU and MPU) and the
memory interface blocks for program and data memories - PMU and EBU.
Central Processing Unit (CPU)

The Cortex-M4 processor is built on a high-performance processor core with a 3-stage
pipelined Harvard architecture, making it ideal for demanding embedded applications.
The processor delivers exceptional power efficiency through an efficient instruction set
and a design optimized for energy efficient control applications. To address the growing
complexity of embedded control it also includes a IEEE754-compliant single-precision
floating-point computation and a range of single-cycle/SIMD multiplication and multiply-
and-accumulate capabilities, saturating arithmetic and dedicated hardware division.
To facilitate the design of cost-sensitive devices, the Cortex-M4 processor implements
tightly-coupled system components that reduce processor area while significantly
improving interrupt handling and system debug capabilities.
To ensure high code density and reduced program memory requirements the processor
also implements a version of the Thumb instruction set based on Thumb-2 technology.
The instruction set provides the exceptional performance expected of a modern 32-bit
architecture with the high code density of 8-bit and 16-bit microcontrollers.
Floating Point Unit (FPU)

The Floating-point unit (FPU) provides IEEE754-compliant operations on single
precision, 32-bit, floating-point values.
Memory Protection Unit (MPU)

The MPU improves system reliability by defining the memory attributes for different
memory regions. It provides fine grain memory control, enabling applications to utilize
multiple privilege levels, separating and protecting code, data and stack on a task-by-
task basis. Up to eight different regions are supported as well as an optional predefined
background region. These features are becoming critical to support safety requirements
in many embedded applications.
Programmable Multiple Priority Interrupt System (NVIC)

The XMC4500 implements the ARM NVIC with 112 interrupt nodes and 64 priority levels.
Most interrupt sources are connected to a dedicated interrupt node. In addition the
XMC4500 allows to route service request directly to dedicated units like DMA, Timer and
ADC. In some cases, multi-source interrupt nodes are incorporated for efficient use of
system resources. These nodes can be activated by several source requests and are
controlled via interrupt sub node control registers.

XMC4500
XMC4000 Family
Introduction
Direct Memory Access (GPDMA)

The GPDMA is a highly configurable DMA controller that allows high-speed data
transfers between peripherals and memories. Complex data transfers can be done with
minimal intervention of the processor, keeping the CPU resources free for other
operations. Provides multi block, scatter/gather and linked list transfers.
Flexible CRC Engine (FCE)

The FCE provides a parallel implementation of Cyclic Redundancy Code (CRC)
algorithms. It implements the IEEE 802.3 CRC32, the CCITT CRC16 and the SAE J1850
CRC8 polynomials. The primary target of FCE is to be used as a hardware acceleration
engine for software applications or operating systems services using CRC signatures.
1.3 On-Chip Memories

The on-chip memories provide zero-waitstate accesses to code and data. The memories
can also be accessed concurrently from various system masters.
Various types of dedicated memories are available on-chip. The suggested use of the
memories aims to improve performance and system stability in most typical application
cases. However, the user has the flexibility to use the memories in any other way in order
to fulfill application specific requirements.
In order to meet the needs of applications where more peripherals are required the
External Bus Unit (EBU) also provides means to optionally attach a broad variety of
external memories.
Boot ROM (BROM)

The Boot ROM memory contains the boot code and the exception vector table. The basic
system initialization sequence code, also referred to as firmware, is executed
immediately after reset release.
Flash memory
The Flash is for nonvolatile code or constant data storage. The single supply Flash
module is programmable at production line end and in application via built-in erase and
program commands. Read and write protection mechanism are offered. A hardware
error correction ensures data consistency over the whole life time under rugged
industrial environment and temperatures.
The integrated cache provides an average performance boost factor of 3 in code
execution compared to uncached execution.

XMC4500
XMC4000 Family
Introduction
Code RAM (PSRAM)

The Code RAM is intended for user code or Operating System data storage. The
memory is accessed via the Bus Matrix and provides zero-wait-state access for the CPU
for code execution or data access.
System RAM (DSRAM1)

The System RAM is intended for general user data storage. The System RAM is
accessed via the Bus Matrix and provides zero-wait-state access for data.
Communication RAM (DSRAM2)

The Communication RAM is intended for use by communication interface units like the
USB and Ethernet modules.
1.4 Communication Peripherals

Communication features are key requirements in todays industrial systems. The
XMC4500 offers a set of peripherals supporting advanced communication protocols.
Besides Ethernet, USB, CAN and the USIC the XMC4500 provides interfaces to various
memories as well as a unit to realize a human-machine interface via LED and Touch
Sense.
LED and Touch Sense (LEDTS)

The LEDTS module drives LEDs and controls touch pads used in human-machine
interface (HMI) applications. The LEDTS can measure the capacitance of up to 8 touch
pads using the relaxation oscillator (RO) topology. The module can also drive up to 64
LEDs in an LED matrix. Touch pads and LEDs can share pins to minimize the number
of pins needed for such applications.
SD/MMC interface (SDMMC)

The Secure Digital/ MultiMediaCard interface (SDMMC) provides an interface between
SD/SDIO/MMC cards and the system bus. It supports SD, SDIO, SDHC and MMC cards,
and can operate up to 48 MHz. The SDMMC module is able to transfer a maximum of
24 MB/s for SD cards and 48 MB/s for MMC cards.
The SDMMC Host Controller handles SDIO/SD protocol at transmission level, packing
data, adding cyclic redundancy check (CRC), start/end bit, and checking for transaction
format correctness. Useful applications of the SDMMC interface include memory
extension, data logging, and firmware update.
External Bus Unit (EBU)

The EBU supports accesses to asynchronous and synchronous external memories:

XMC4500
XMC4000 Family
Introduction
ROMs, EPROMs
NOR and NAND flash devices
Static RAMs and PSRAMs
PC133/100 compatible SDRAM
Burst FLASH
Ethernet MAC (ETH)

The Ethernet MAC (ETH) is a major communication peripheral that supports
10/100 Mbit/s data transfer rates in compliance with the IEEE 802.3-2002 standard.
The ETH may be used to implement Internet connected applications using IPv4 and
IPv6. The ETH also includes support for IEEE1588 time synchronisation to allow
implimentation of Real Time Ethernet protocols.
Universal Serial Bus (USB)

The USB module is a Dual-Role Device (DRD) controller that supports both device and
host functions and complies fully with the On-The-Go supplement to the USB 2.0
Specification, Revision 1.3. It can also be configured as a host-only or device-only
controller, fully compliant with the USB 2.0 Specification.
The USB core's USB 2.0 configurations support full-speed (12 Mbit/s) transfers.
The USB core is optimized for the following applications and systems:
Portable electronic devices
Point-to-point applications (direct connection to FS device)
Universal Serial Interface Channel (USIC)

The USIC is a flexible interface module covering several serial communication protocols
such as ASC, LIN, SSC, I2C, I2S. A USIC module contains two independent
communication channels. Three USIC modules are implemented, hence six channels
can be used in parallel. A FIFO allows transmit and result buffering for relaxing realtime
conditions. Mulitple chip select signals are available for communication with mulitple
devices on the same channel.
Controller Area Network (CAN)

The MultiCAN module contains three independently operating CAN nodes with Full-CAN
functionality that are able to exchange Data and Remote Frames via a gateway function.
Transmission and reception of CAN frames is handled in accordance with CAN
specification V2.0 B (active). Each CAN node can receive and transmit standard frames
with 11-bit identifiers as well as extended frames with 29-bit identifiers. Transmission
rate is up to 1 Mbit/s
All CAN nodes share a common set of message objects. Each message object can be
individually allocated to one of the CAN nodes. Besides serving as a storage container

XMC4500
XMC4000 Family
Introduction
for incoming and outgoing frames, message objects can be combined to build gateways
between the CAN nodes or to setup a FIFO buffer.
1.5 Analog Frontend Peripherals

The XMC4500 hosts a number of interfaces to connect to the analog world.
Analog to Digital Converter (VADC)

The Versatile Analog-to-Digital Converter module consists of four independent kernels
which operate according to the successive approximation principle (SAR). The
resolution is programmable from 8 to 12bit with a total conversion time of less then 500ns
@12bit.
Each kernel provides a versatile state machine allowing complex measurement
sequences. The kernels can be synchronized and conversions may run completely in
background. Multiple trigger events can be prioritized and allow the exact measurement
of time critical signals. The result buffering and handling avoids data loss and ensures
consistency. Selftest mechanisms can be used for plausability checks.
The basic structure supports a clean software architecture where tasks may only read
valid results and do not need to care for starting conversions.
A number of out-of-range on-chip comparators serve the purpose of overvoltage
monitoring for analog input pins of the VADC.
Delta- Sigma Demodulator (DSD)

The Delta-Sigma Demodulator module allows the direct usage of external Delta-Sigma
Modulators for analog signal measurement.
The four input channels convert the incoming bit streams into discrete values. Each
demodulator channel exists of two programmable digital filter chains (SINC/COMB type).
A fast filter can be used for limit checking and a slower filter for signal measurement. An
integrator stage supports carrier frequency cancellation. A special mechanism can
compensate a phase delay between two channels. A built in pattern generator
generates a digitized sine bitstream. This can be used for exitation of a resolver coil in
motor position applications.
Digital to Analog Convertor (DAC)

The module consists of two separate 12-bit Digital-to-Analog Converters (DACs). It
converts two digital input signals into two analog voltage signal outputs at a maximum
conversion rate of 5 MHz.
A built-in wave generator mode allows stand alone generation of a selectable choice of
wave forms. Alternatively values can be fed via CPU or DMA directly to one or both DAC

XMC4500
XMC4000 Family
Introduction
channels. Additionally an offset can be added and the amplitude can be scaled. Several
time trigger sources are possible.
1.6 Industrial Control Peripherals

Core components needed for motion and motor control, power conversion and other
time based applications.
Capture/Compare Unit 4 (CCU4)

The CCU4 peripheral is a major component for systems that need general purpose
timers for signal monitoring/conditioning and Pulse Width Modulation (PWM) signal
generation. Power electronic control systems like switched mode power supplies or
uninterruptible power supplies can easily be implemented with the functions inside the
CCU4 peripheral.
The internal modularity of CCU4 translates into a software friendly system for fast code
development and portability between applications.
Capture/Compare Unit 8 (CCU8)

The CCU8 peripheral functions play a major role in applications that need complex Pulse
Width Modulation (PWM) signal generation, with complementary high side and low side
switches, multi phase control or output parity checking. The CCU8 is optimized for state
of the art motor control, multi phase and multi level power electronics systems.
The internal modularity of CCU8 translates into a software friendly system for fast code
development and portability between applications.
Position Interface Unit (POSIF)

The POSIF unit is a flexible and powerful component for motor control systems that use
Rotary Encoders or Hall Sensors as feedback loop. The configuration schemes of the
module target a very large number of motor control application requirements.
This enables the build of simple and complex control feedback loops for industrial and
automotive motor applications, targeting high performance motion and position
monitoring.
1.7 On-Chip Debug Support

The On-Chip Debug Support system based on the ARM CoreSight provides a broad
range of debug and emulation features built into the XMC4500. The user software can
therefore be debugged within the target system environment.
The On-Chip Debug Support is controlled by an external debugging device via the debug
interface and an optional break interface. The debugger controls the On-Chip Debug
Support via a set of dedicated registers accessible via the debug interface. Additionally,

XMC4500
XMC4000 Family
Introduction
the On-Chip Debug Support system can be controlled by the CPU, e.g. by a monitor
program.

XMC4500
XMC4000 Family
CPU Subsystem
CPU Subsystem

XMC4500
XMC4000 Family
2 Central Processing Unit (CPU)

The XMC4500 features the ARM Cortex-M4 processor. A high performance 32-bit
processor designed for the microcontroller market. This CPU offers significant benefits
to users, including:
outstanding processing performance combined with fast interrupt handling
enhanced system debug with extensive breakpoint and trace capabilities
platform security robustness, with integrated memory protection unit (MPU).
ultra-low power consumption with integrated sleep modes
References to ARM Documentation

The following documents can be found through http://infocenter.arm.com
[1] Cortex-M4 Devices, Generic User Guide (ARM DUI 0553A)
[2] Cortex Microcontroller Software Interface Standard (CMSIS)
References to ARM Figures

[3] http://www.arm.com
References to IEEE Documentation

[4] IEEE Standard IEEE Standard for Binary Floating-Point Arithmetic 754-2008.
2.1 Overview
The Cortex-M4 processor is built on a high-performance processor core, with a 3-stage
pipeline Harvard architecture, making it ideal for demanding embedded applications.
The processor delivers exceptional power efficiency through an efficient instruction set
and extensively optimized design, providing high-end processing hardware including
IEEE754-compliant single-precision floating-point computation, a range of single-cycle
and SIMD multiplication and multiply-with-accumulate capabilities, saturating arithmetic
and dedicated hardware division.
To facilitate the design of cost-sensitive devices, the Cortex-M4 processor implements
tightly-coupled system components that reduce processor area while significantly
improving interrupt handling and system debug capabilities. The Cortex-M4 processor
implements a version of the Thumb instruction set based on Thumb-2 technology,
ensuring high code density and reduced program memory requirements. The Cortex-M4
instruction set provides the exceptional performance expected of a modern 32-bit
architecture, with the high code density of 8-bit and 16-bit microcontrollers.
The Cortex-M4 processor closely integrates a configurable NVIC, to deliver industry-
leading interrupt performance. The NVIC includes a non-maskable interrupt (NMI), and
provides up to 64 interrupt priority levels. The tight integration of the processor core and

CPU, V1.1 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
NVIC provides fast execution of interrupt service routines (ISRs), dramatically reducing
the interrupt latency. This is achieved through the hardware stacking of registers, and
the ability to suspend load-multiple and store-multiple operations. Interrupt handlers do
not require wrapping in assembler code, removing any code overhead from the ISRs. A
tail-chain optimization also significantly reduces the overhead when switching from one
ISR to another.
To optimize low-power designs, the NVIC integrates with the sleep modes, that include
a deep sleep function that enables the entire device to be rapidly powered down while
still retaining program state.
2.1.1 Features
The XMC4500 CPU features comprise
Thumb2 instruction set combines high code density with 32-bit performance
IEEE754-compliant single-precision FPU
power control optimization of system components
integrated sleep modes for low power consumption
fast code execution permits slower processor clock or increases sleep mode time
hardware division and fast digital-signal-processing orientated multiply accumulate
saturating arithmetic for signal processing
deterministic, high-performance interrupt handling for time-critical applications
memory protection unit (MPU) for safety-critical applications
extensive debug and trace capabilities:
Serial Wire Debug and Serial Wire Trace reduce the number of pins required for
debugging, tracing, and code profiling.
2.1.2 Block Diagram

The Cortex-M4 core components comprise:
Processor Core
The CPU provides 16-bit and 32-bit Thumb2 instruction set and DSP/MAC instructions.
Floating-point unit
The FPU provides IEEE754-compliant operations on single-precision, 32-bit, floating-
point values.
Nested Vectored Interrupt Controller

The NVIC is an embedded interrupt controller that supports low latency interrupt
processing.

XMC4500
XMC4000 Family
Memory Protection Unit

The MPU improves system reliability by defining the memory attributes for different
memory regions. It provides up to eight different regions, and an optional predefined
background region.
Debug Solution
The XMC4500 implements a complete hardware debug solution.
Embedded Trace Macrocell
Traditional JTAG port or a 2-pin Serial Wire Debug Access Port
Trace port or Serial Wire Viewer
Flash breakpoints and Data watchpoints
This provides high system control and visibility of the processor and memory even in
small package devices.
Cortex-M4
processor FPU
Embedded
NVIC Trace
Processor
Macrocell
core
Debug Serial
Memory
Access Wire
protection unit
Port Viewer
Flash Data
breakpoints watchpoints
Bus matrix
Code Data
System interface
interface interface
Figure 2-1 Cortex-M4 Block Diagram

XMC4500
XMC4000 Family
System Level Interfaces

The Cortex-M4 processor provides a code, data and system interface using AMBA
technology to provide high speed, low latency accesses.
2.2 Programmers Model

This section describes the Cortex-M4 programmers model. In addition to the individual
core register descriptions, it contains information about the processor modes and
privilege levels for software execution and stacks.
2.2.1 Processor Mode and Privilege Levels for Software Execution

The processor modes are:
Thread mode
Used to execute application software. The processor enters Thread mode when it
comes out of reset.
Handler mode
Used to handle exceptions. The processor returns to Thread mode when it has
finished all exception processing.
The privilege levels for software execution are:
Unprivileged
Unprivileged software executes at the unprivileged level.
The software:
has limited access to the MSR and MRS instructions, and cannot use the CPS
instruction
cannot access the system timer, NVIC, or system control block
might have restricted access to memory or peripherals.
Privileged
Privileged software executes at the privileged level.
The software can use all the instructions and has access to all resources.
In Thread mode, the CONTROL register controls whether software execution is
privileged or unprivileged, see CONTROL register on Page 2-15. In Handler mode,
software execution is always privileged.
Only privileged software can write to the CONTROL register to change the privilege level
for software execution in Thread mode. Unprivileged software can use the SVC
instruction to make a supervisor call to transfer control to privileged software.
2.2.2 Stacks
The processor uses a full descending stack. This means the stack pointer holds the
address of the last stacked item in memory. When the processor pushes a new item onto
the stack, it decrements the stack pointer and then writes the item to the new memory

XMC4500
XMC4000 Family
location. The processor implements two stacks, the main stack and the process stack,
with a pointer for each held in independent registers, see Stack Pointer on Page 2-8.
In Thread mode, the CONTROL register controls whether the processor uses the main
stack or the process stack, see CONTROL register on Page 2-15. In Handler mode, the
processor always uses the main stack. The options for processor operations are:
Table 2-1 Summary of processor mode, execution privilege level, and stack
use options
Processor Used to Privilege level for Stack used
mode execute software execution
Thread Applications Privileged or Main stack or process stack1)
unprivileged1)
Handler Exception Always privileged Main stack
handlers
1) See CONTROL register on Page 2-15.

XMC4500
XMC4000 Family
2.2.3 Core Registers
R0
R1
R2
R3
Low registers
R4
R5
R6 General-purpose registers
R7
R8
R9
High registers R10
R11
R12
Stack Pointer SP (R13) PSP MSP
Banked version of SP
Link Register LR (R14)
Program Counter PC (R15)
PSR Program status register

PRIMASK
FAULTMASK Exception mask registers Special registers
BASEPRI
CONTROL CONTROL register
Figure 2-2 Core registers

The processor core registers are:
Table 2-2 Core register set summary

Name Type 1) Required Reset value Description
privilege 2)
R0-R12 rw Either Unknown General-purpose registers on
Page 2-7
MSP rw Privileged See Stack Pointer on Page 2-8
description
PSP rw Either Unknown Stack Pointer on Page 2-8
LR rw Either FFFFFFFFH Link Register on Page 2-8
PC rw Either See Program Counter on Page 2-8
description

XMC4500
XMC4000 Family
Table 2-2 Core register set summary (contd)

Name Type 1) Required Reset value Description
privilege 2)
PSR rw Privileged 01000000H Program Status Register on
Page 2-9
ASPR rw Either Unknown Application Program Status
Register on Page 2-9
IPSR r Privileged 00000000H Interrupt Program Status
EPSR r Privileged 01000000H Execution Program Status
PRIMASK rw Privileged 00000000H Priority Mask Register on
Page 2-13
FAULTMASK rw Privileged 00000000H Fault Mask Register on
Page 2-14
BASEPRI rw Privileged 00000000H Base Priority Mask Register on
Page 2-14
CONTROL rw Privileged 00000000H CONTROL register on
Page 2-15
1) Describes access type during program execution in thread mode and Handler mode. Debug access can differ.
2) An entry of Either means privileged and unprivileged software can access the register.
General-purpose registers
R0-R12 are 32-bit general-purpose registers for data operations
Rx (x=0-12)
General Purpose Register Rx Reset Value: XXXX XXXXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VALUE
rw
Field Bits Type Description

VALUE [31:0] rw Content of Register

XMC4500
XMC4000 Family
Stack Pointer
The Stack Pointer (SP) is register R13. In Thread mode, bit[1] of the CONTROL register
indicates the stack pointer to use:
0 = Main Stack Pointer (MSP). This is the reset value.
1 = Process Stack Pointer (PSP).
On reset, the processor loads the MSP with the value from address 00000000H.
SP
Stack Pointer Reset Value: 2000 FF3CH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VALUE
rw

Link Register
The Link Register (LR) is register R14. It stores the return information for subroutines,
function calls, and exceptions. On reset, the processor sets the LR value to FFFFFFFFH.
LR
Link Register Reset Value: FFFF FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VALUE
rw

Program Counter
The Program Counter (PC) is register R15. It contains the current program address. On
reset, the processor loads the PC with the value of the reset vector, which is at address
00000004H. Bit[0] of the value is loaded into the EPSR T-bit at reset and must be 1.

XMC4500
XMC4000 Family
PC
Program Counter Reset Value: 0000 0004H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VALUE
rw

Program Status Register

The Program Status Register (PSR) combines:
Application Program Status Register (APSR)
Interrupt Program Status Register (IPSR)
Execution Program Status Register (EPSR)
These registers are mutually exclusive bit fields in the 32-bit PSR.
Access these registers individually or as a combination of any two or all three registers,
using the register name as an argument to the MSR or MRS instructions. For example:
read all of the registers using PSR with the MRS instruction
write to the APSR N, Z, C, V, and Q bits using APSR_nzcvq with the MSR instruction.
The PSR combinations and attributes are:
Table 2-3 PSR register combinations

Register Type Combination
PSR rw1)2) APSR, EPSR, and IPSR
IEPSR r EPSR and IPSR
1)
IAPSR rw APSR and IPSR
EAPSR rw2) APSR and EPSR
1) The processor ignores writes to the IPSR bits.
2) Reads of the EPSR bits return zero, and the processor ignores writes to the these bits
Application Program Status Register

The APSR contains the current state of the condition flags from previous instruction
executions. See the register summary in Table 2-2 on Page 2-6 for its attributes.

XMC4500
XMC4000 Family
APSR
Application Program Status Register Reset Value: XXXX XXXXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
N Z C V Q 0 GE[3:0] 0
rw rw rw rw rw r rw r

GE[3:0] [19:16] rw Greater than or Equal flags
Please refer also to SEL instruction.
Q 27 rw DSP overflow and saturation flag
V 28 rw Overflow flag
C 29 rw Carry or borrow flag
Z 30 rw Zero flag
N 31 rw Negative flag
0 [26:20], r Reserved
[15:0] Read as 0; should be written with 0.
Interrupt Program Status Register

The IPSR contains the exception type number of the current Interrupt Service Routine
(ISR). See the register summary in Table 2-2 on Page 2-6 for its attributes.
IPSR
Interrupt Program Status Register Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 ISR_NUMBER
r r

XMC4500
XMC4000 Family

ISR_NUMBER [8:0] r Number of the current exception
0D Thread mode
1D Reserved
2D NMI
3D HardFault
4D MemManage
5D BusFault
6D UsageFault
7D Reserved
8D Reserved
9D Reserved
10D Reserved
11D SVCall
12D Reserved for Debug
13D Reserved
14D PendSV
15D SysTick
16D IRQ0
...
127D IRQ111
Values > 127D undefined.
See Exception types on Page 2-26 for more
information.
0 [31:9] r Reserved
Read as 0; should be written with 0.
Execution Program Status Register

The EPSR contains the Thumb state bit, and the execution state bits for either the:
If-Then (IT) instruction
Interruptible-Continuable Instruction (ICI) field for an interrupted load multiple or store
multiple instruction.
See the register summary in Table 2-2 on Page 2-6 for the EPSR attributes.
Attempts to read the EPSR directly through application software using the MSR
instruction always return zero. Attempts to write the EPSR using the MSR instruction in
application software are ignored.

XMC4500
XMC4000 Family
EPSR
Execution Program Status Register Reset Value: 0100 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 ICI/IT T 0 ICI/IT 0
r r r r r r

ICI/IT [26:25], r Interruptible-continuable instruction bits/Execution
[15:10] state bits of the IT instruction
Please refer also to IT instruction.
T 24 r Thumb state bit
Thumb state.
[23:16], Read as 0; should be written with 0.
[9:0]
Interruptible-continuable instructions
When an interrupt occurs during the execution of an LDM, STM, PUSH, POP, VLDM,
VSTM, VPUSH, or VPOP instruction, the processor:
stops the load multiple or store multiple instruction operation temporarily
stores the next register operand in the multiple operation to EPSR bits[15:12]
After servicing the interrupt, the processor:
returns to the register pointed to by bits[15:12]
resumes execution of the multiple load or store instruction.
When the EPSR holds ICI execution state, bits[26:25,11:10] are zero.
If-Then block
The If-Then block contains up to four instructions following an IT instruction. Each
instruction in the block is conditional. The conditions for the instructions are either all the
same, or some can be the inverse of others. See IT on page 3-122 for more information.
Thumb state
The Cortex-M4 processor only supports execution of instructions in Thumb state. The
following can clear the T bit to 0:
instructions BLX, BX and POP{PC}

XMC4500
XMC4000 Family
restoration from the stacked xPSR value on an exception return

bit[0] of the vector value on an exception entry or reset.
Attempting to execute instructions when the T bit is 0 results in a fault or lockup. See
Lockup on Page 2-39 for more information.
Exception mask registers

The exception mask registers disable the handling of exceptions by the processor.
Disable exceptions where they might impact on timing critical tasks.
To access the exception mask registers use the MSR and MRS instructions, or the CPS
instruction to change the value of PRIMASK or FAULTMASK.
Priority Mask Register

The PRIMASK register prevents activation of all exceptions with configurable priority.
See the register summary in Table 2-2 on Page 2-6 for its attributes.
PRIMASK
Priority Mask Register Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRI
0 MAS
K
r rw

PRIMASK 0 rw Priority Mask
0B No effect
1B Prevents the activation of all exceptions with
configurable priority.
0 [31:1] r Reserved

XMC4500
XMC4000 Family
Fault Mask Register

The FAULTMASK register prevents activation of all exceptions except for Non-Maskable
Interrupt (NMI). See the register summary in Table 2-2 on Page 2-6 for its attributes.
FAULTMASK
Fault Mask Register Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FAU
0 LTM
ASK
r rw

FAULTMASK 0 rw Fault Mask
0B no effect
1B prevents the activation of all exceptions except
for NMI.
0 [31:1] r Reserved
The processor clears the FAULTMASK bit to 0 on exit from any exception handler except
the NMI handler.
Base Priority Mask Register

The BASEPRI register defines the minimum priority for exception processing. When
BASEPRI is set to a nonzero value, it prevents the activation of all exceptions with the
same or lower priority level as the BASEPRI value. See the register summary in
Table 2-2 on Page 2-6 for its attributes.

XMC4500
XMC4000 Family
BASEPRI
Base Priority Mask Register Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 BASEPRI
r rw

BASEPRI1) [7:0] rw Priority mask bits
0H no effect
others, defines the base priority for exception
processing.
The processor does not process any exception with
a priority value greater than or equal to BASEPRI.
0 [31:8] r Reserved
1) This field is similar to the priority fields in the interrupt priority registers. The XMC4500 implements only
bits[7:2] of this field, bits[1:0] read as zero and ignore writes. See Interrupt Priority Registers on Page 2-89
for more information. Remember that higher priority field values correspond to lower exception priorities.
CONTROL register
The CONTROL register controls the stack used and the privilege level for software
execution when the processor is in Thread mode and indicates whether the FPU state is
active. See the register summary in Table 2-2 on Page 2-6 for its attributes.

XMC4500
XMC4000 Family
CONTROL
CONTROL register Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FPC SPS nPRI
0
A EL V
r rh rh rh

nPRIV 0 rh Thread mode privilege level
0B Privileged
1B Unprivileged
SPSEL 1 rh Currently active stack pointer
In Handler mode this bit reads as zero and ignores
writes. The Cortex-M4 updates this bit automatically
on exception return.
0B MSP is the current stack pointer
1B PSP is the current stack pointer
FPCA 2 rh Floating-point context currently active
0B No floating-point context active
1B Floating-point context active
The Cortex-M4 uses this bit to determine whether to
preserve floating-point state when processing an
exception.
0 [31:3] r Reserved
Handler mode always uses the MSP, so the processor ignores explicit writes to the
active stack pointer bit of the CONTROL register when in Handler mode. The exception
entry and return mechanisms automatically update the CONTROL register based on the
EXC_RETURN value, see Table 2-9 on Page 2-36.
In an OS environment, ARM recommends that threads running in Thread mode use the
process stack and the kernel and exception handlers use the main stack.

XMC4500
XMC4000 Family
By default, Thread mode uses the MSP. To switch the stack pointer used in Thread
mode to the PSP, either:
use the MSR instruction to set the Active stack pointer bit to 1.
perform an exception return to Thread mode with the appropriate EXC_RETURN
value, see Table 2-9 on Page 2-36.
Note: When changing the stack pointer, software must use an ISB instruction
immediately after the MSR instruction. This ensures that instructions after the ISB
instruction execute using the new stack pointer.
2.2.4 Exceptions and Interrupts

The Cortex-M4 processor supports interrupts and system exceptions. The processor
and the NVIC prioritize and handle all exceptions. An exception changes the normal flow
of software control. The processor uses Handler mode to handle all exceptions except
for reset. See Exception entry on Page 2-33 and Exception return on Page 2-36 for more
information.
The NVIC registers control interrupt handling. See Page 2-43 for more information.
2.2.5 Data Types

The processor:
supports the following data types:
32-bit words
16-bit halfwords
8-bit bytes
manages all data memory accesses as little-endian. See Memory regions, types and
attributes on Page 2-20 for more information.
2.2.6 The Cortex Microcontroller Software Interface Standard

For a Cortex-M4 microcontroller system, the Cortex Microcontroller Software Interface
Standard (CMSIS) [2] defines:
a common way to:
access peripheral registers
define exception vectors
the names of:
the registers of the core peripherals
the core exception vectors
a device-independent interface for RTOS kernels, including a debug channel.
The CMSIS includes address definitions and data structures for the core peripherals in
the Cortex-M4 processor.

XMC4500
XMC4000 Family
CMSIS simplifies software development by enabling the reuse of template code and the
combination of CMSIS-compliant software components from various middleware
vendors. Software vendors can expand the CMSIS to include their peripheral definitions
and access functions for those peripherals.
This document includes the register names defined by the CMSIS, and gives short
descriptions of the CMSIS functions that address the processor core and the core
peripherals.
Note: This document uses the register short names defined by the CMSIS. In a few
cases these differ from the architectural short names that might be used in other
documents.
The following sections give more information about the CMSIS:
Power management programming hints on Page 2-42
CMSIS functions on Page 2-18
Using CMSIS functions to access NVIC on Page 2-45
For additional information please refer to http://www.onarm.com/cmsis
2.2.7 CMSIS functions

ISO/IEC C code cannot directly access some Cortex-M4 instructions. This section
describes intrinsic functions that can generate these instructions, provided by the CMSIS
and that might be provided by a C compiler. If a C compiler does not support an
appropriate intrinsic function, you might have to use inline assembler to access some
instructions.
The CMSIS provides the following intrinsic functions to generate instructions that
ISO/IEC C code cannot directly access:
Table 2-4 CMSIS functions to generate some Cortex-M4 instructions

Instruction CMSIS function
CPSIE I void __enable_irq(void)
CPSID I void __disable_irq(void)
CPSIE F void __enable_fault_irq(void)
CPSID F void __disable_fault_irq(void)
ISB void __ISB(void)
DSB void __DSB(void)
DMB void __DMB(void)
REV uint32_t __REV(uint32_t int value)
REV16 uint32_t __REV16(uint32_t int value)

XMC4500
XMC4000 Family
Table 2-4 CMSIS functions to generate some Cortex-M4 instructions (contd)

REVSH uint32_t __REVSH(uint32_t int value)
RBIT uint32_t __RBIT(uint32_t int value)
SEV void __SEV(void)
WFE void __WFE(void)
WFI void __WFI(void)
The CMSIS also provides a number of functions for accessing the special registers using
MRS and MSR instructions:
Table 2-5 CMSIS functions to access the special registers

Special Access CMSIS function
register
PRIMASK Read uint32_t __get_PRIMASK (void)
Write void __set_PRIMASK (uint32_t value)
FAULTMASK Read uint32_t __get_FAULTMASK (void)
Write void __set_FAULTMASK (uint32_t value)
BASEPRI Read uint32_t __get_BASEPRI (void)
Write void __set_BASEPRI (uint32_t value)
CONTROL Read uint32_t __get_CONTROL (void)
Write void __set_CONTROL (uint32_t value)
MSP Read uint32_t __get_MSP (void)
Write void __set_MSP (uint32_t TopOfMainStack)
PSP Read uint32_t __get_PSP (void)
Write void __set_PSP (uint32_t TopOfProcStack)

XMC4500
XMC4000 Family
2.3 Memory Model

This section describes the processor memory map and the behavior of memory
accesses. The processor has a fixed default memory map that provides up to 4GB of
addressable memory. The memory map is:
0xFFFFFFFF
Vendor-specific
511MB
memory
0xE0100000
Private peripheral 0xE00FFFFF
1.0MB
bus
0xE0000000
0xDFFFFFFF
External device 1.0GB
0xA0000000
0x9FFFFFFF
External RAM 1.0GB
0x60000000
0x5FFFFFFF
Peripheral 0.5GB
0x40000000
0x3FFFFFFF
SRAM 0.5GB
0x20000000
0x1FFFFFFF
Code 0.5GB
0x00000000
Figure 2-3 Memory map

The processor reserves regions of the Private peripheral bus (PPB) address range for
core peripheral registers, see About the Private Peripherals on Page 2-42.
2.3.1 Memory Regions, Types and Attributes

The memory map and the programming of the MPU splits the memory map into regions.
Each region has a defined memory type, and some regions have additional memory

XMC4500
XMC4000 Family
attributes. The memory type and attributes determine the behavior of accesses to the
region.
The memory types are:
Normal The processor can re-order transactions for efficiency, or

perform speculative reads.
Device The processor preserves transaction order relative to other
transactions to Device or Strongly-ordered memory.
Strongly-ordered The processor preserves transaction order relative to all other
transactions.
The different ordering requirements for Device and Strongly-ordered memory mean that
the memory system can buffer a write to Device memory, but must not buffer a write to
Strongly-ordered memory.
The additional memory attributes include:
Execute Never (XN) Means the processor prevents instruction accesses. A fault
exception is generated only on execution of an instruction
executed from an XN region.
2.3.2 Memory System Ordering of Memory Accesses

For most memory accesses caused by explicit memory access instructions, the memory
system does not guarantee that the order in which the accesses complete matches the
program order of the instructions, providing this does not affect the behavior of the
instruction sequence. Normally, if correct program execution depends on two memory
accesses completing in program order, software must insert a memory barrier instruction
between the memory access instructions. See Software ordering of memory accesses
on Page 2-23.
However, the memory system does guarantee some ordering of accesses to Device and
Strongly-ordered memory. For two memory access instructions A1 and A2, if A1 occurs
before A2 in program order, the ordering of the memory accesses caused by two
instructions is:

XMC4500
XMC4000 Family
Strongly-
A2 Normal Device
ordered
A1 access access
access
Normal access - - -
Device access - < <
Strongly-ordered access - <- <
Figure 2-4 Ordering of Memory Accesses

Where:
- Means that the memory system does not guarantee the ordering of the accesses.
< Means that accesses are observed in program order, that is, A1 is always
observed before A2.
2.3.3 Behavior of Memory Accesses

The behavior of accesses to each region in the memory map is:
Table 2-6 Memory access behavior

Address Memory Memory XN1) Description
range region type1)
0x00000000- Code Normal - Executable region for program
0x1FFFFFFF code. You can also put data here.
0x20000000- SRAM Normal - Executable region for data. You
0x3FFFFFFF can also put code here.
0x40000000- Peripheral Device XN Peripherals region.
0x5FFFFFFF
0x60000000- External RAM Normal - Executable region for data.
0x9FFFFFFF
0xA0000000- External Device XN External Device memory.
0xDFFFFFFF device
0xE0000000- Private Strongly- XN This region includes the NVIC,
0xE00FFFFF Peripheral ordered System timer, and system control
Bus block.
0xE0100000- Vendor- Device XN Accesses to this region are to
0xFFFFFFFF specific vendor-specific peripherals.
device

XMC4500
XMC4000 Family
1) See Memory regions, types and attributes on Page 2-20 for more information.
The Code, SRAM, and external RAM regions can hold programs. However, it is
recommended that programs always use the Code region. This is because the processor
has separate buses that enable instruction fetches and data accesses to occur
simultaneously.
The MPU can override the default memory access behavior described in this section. For
more information, see Memory protection unit on Page 2-46.
Instruction prefetch and branch prediction

The Cortex-M4 processor:
prefetches instructions ahead of execution
speculatively prefetches from branch target addresses.
2.3.4 Software Ordering of Memory Accesses

The order of instructions in the program flow does not always guarantee the order of the
corresponding memory transactions. This is because:
the processor can reorder some memory accesses to improve efficiency, providing
this does not affect the behavior of the instruction sequence.
The processor has multiple bus interfaces
memory or devices in the memory map have different wait states
some memory accesses are buffered or speculative.
Memory system ordering of memory accesses on Page 2-21 describes the cases where
the memory system guarantees the order of memory accesses. Otherwise, if the order
of memory accesses is critical, software must include memory barrier instructions to
force that ordering. The processor provides the following memory barrier instructions:
DMB The Data Memory Barrier (DMB) instruction ensures that outstanding
memory transactions complete before subsequent memory
transactions.
DSB The Data Synchronization Barrier (DSB) instruction ensures that
outstanding memory transactions complete before subsequent
instructions execute.
ISB The Instruction Synchronization Barrier (ISB) ensures that the effect of
all completed memory transactions is recognizable by subsequent
instructions.

XMC4500
XMC4000 Family
MPU programming
Use a DSB followed by an ISB instruction or exception return to ensure that the new
MPU configuration is used by subsequent instructions.
2.3.5 Memory Endianness

The processor views memory as a linear collection of bytes numbered in ascending
order from zero. For example, bytes 0-3 hold the first stored word, and bytes 4-7 hold the
second stored word. The XMC4500 stores information Little-endian format.
Little-endian format
In little-endian format, the processor stores the least significant byte of a word at the
lowest-numbered byte, and the most significant byte at the highest-numbered byte. For
example:
Memory Register
7 0
31 24 23 16 15 8 7 0
Address A B0 lsbyte B3 B2 B1 B0
A+1 B1
A+2 B2
A+3 B3 msbyte
Figure 2-5 Little-endian format
2.3.6 Synchronization Primitives

The Cortex-M4 instruction set includes pairs of synchronization primitives. These
provide a non-blocking mechanism that a thread or process can use to obtain exclusive
access to a memory location. Software can use them to perform a guaranteed read-
modify-write memory update sequence, or for a semaphore mechanism.
A pair of synchronization primitives comprises:
A Load-Exclusive instruction
Used to read the value of a memory location, requesting exclusive access to that
location.

XMC4500
XMC4000 Family
A Store-Exclusive instruction
Used to attempt to write to the same memory location, returning a status bit to a register.
If this bit is:
0 it indicates that the thread or process gained exclusive access to the memory, and
the write succeeds,
1 it indicates that the thread or process did not gain exclusive access to the memory,
and no write was performed.
The pairs of Load-Exclusive and Store-Exclusive instructions are:
the word instructions LDREX and STREX
the halfword instructions LDREXH and STREXH
the byte instructions LDREXB and STREXB.
Software must use a Load-Exclusive instruction with the corresponding Store-Exclusive
instruction.
To perform an exclusive read-modify-write of a memory location, software must:
1. Use a Load-Exclusive instruction to read the value of the location.
2. Modify the value, as required.
3. Use a Store-Exclusive instruction to attempt to write the new value back to the
memory location.
4. Test the returned status bit. If this bit is:
0 The read-modify-write completed successfully.
1 No write was performed. This indicates that the value returned at step 1 might be
out of date. The software must retry the entire read-modify-write sequence.
Software can use the synchronization primitives to implement a semaphores as follows:
1. Use a Load-Exclusive instruction to read from the semaphore address to check
whether the semaphore is free.
2. If the semaphore is free, use a Store-Exclusive to write the claim value to the
semaphore address.
3. If the returned status bit from step 2 indicates that the Store-Exclusive succeeded
then the software has claimed the semaphore. However, if the Store-Exclusive failed,
another process might have claimed the semaphore after the software performed
step 1.
The Cortex-M4 includes an exclusive access monitor, that tags the fact that the
processor has executed a Load-Exclusive instruction.
The processor removes its exclusive access tag if:
It executes a CLREX instruction.
It executes a Store-Exclusive instruction, regardless of whether the write succeeds.
An exception occurs. This means the processor can resolve semaphore conflicts
between different threads.

XMC4500
XMC4000 Family
2.3.7 Programming Hints for the Synchronization Primitives

ISO/IEC C cannot directly generate the exclusive access instructions. CMSIS provides
intrinsic functions for generation of these instructions:
Table 2-7 CMSIS functions for exclusive access instructions

LDREX uint32_t __LDREXW (uint32_t *addr)
LDREXH uint16_t __LDREXH (uint16_t *addr)
LDREXB uint8_t __LDREXB (uint8_t *addr)
STREX uint32_t __STREXW (uint32_t value, uint32_t *addr)
STREXH uint32_t __STREXH (uint16_t value, uint16_t *addr)
STREXB uint32_t __STREXB (uint8_t value, uint8_t *addr)
CLREX void __CLREX (void)
For example:
uint16_t value;
uint16_t *address = 0x20001002;
value = __LDREXH (address); // load 16-bit value from memory
address 0x20001002
2.4 Instruction Set

The Cortex-M4 instruction set reference is available through [1]
2.5 Exception Model

This section describes the exception model. It describes:
Exception states
Exception types
Exception handlers on Page 2-27
Vector table on Page 2-30
Exception priorities on Page 2-31
Interrupt priority grouping on Page 2-31
Exception entry and return on Page 2-32
2.5.1 Exception States

Each exception is in one of the following states:

XMC4500
XMC4000 Family
Inactive The exception is not active and not pending.

Pending The exception is waiting to be serviced by the processor.
An interrupt request from a peripheral or from software can
change the state of the corresponding interrupt to pending.
Active An exception that is being serviced by the processor but has not
completed.
Note: An exception handler can interrupt the execution of
another exception handler. In this case both exceptions
are in the active state.
Active and pending The exception is being serviced by the processor and there is a
pending exception from the same source.
2.5.2 Exception Types

The exception types are:
Reset Reset is invoked on power up or a warm reset. The exception

model treats reset as a special form of exception. When reset is
asserted, the operation of the processor stops, potentially at any
point in an instruction. When reset is deasserted, execution
restarts from the address provided by the reset entry in the
vector table. Execution restarts as privileged execution in
Thread mode.
NMI A NonMaskable Interrupt (NMI) can be signalled by a peripheral
or triggered by software. This is the highest priority exception
other than reset. It is permanently enabled and has a fixed
priority of -2. NMIs cannot be:
masked or prevented from activation by any other exception
preempted by any exception other than Reset.
HardFault A HardFault is an exception that occurs because of an error
during exception processing, or because an exception cannot be
managed by any other exception mechanism. HardFaults have
a fixed priority of -1, meaning they have higher priority than any
exception with configurable priority.
MemManage A MemManage fault is an exception that occurs because of a
memory protection related fault. The MPU or the fixed memory
protection constraints determines this fault, for both instruction
and data memory transactions. This fault is always used to abort
instruction accesses to Execute Never (XN) memory regions.

XMC4500
XMC4000 Family
BusFault A BusFault is an exception that occurs because of a memory

related fault for an instruction or data memory transaction. This
might be from an error detected on a bus in the memory system.
UsageFault A UsageFault is an exception that occurs because of a fault
related to instruction execution. This includes:
an undefined instruction
an illegal unaligned access
invalid state on instruction execution
an error on exception return.
The following can cause a UsageFault when the core is
configured to report them:
an unaligned address on word and halfword memory access
division by zero.
SVCall A supervisor call (SVC) is an exception that is triggered by the
SVC instruction. In an OS environment, applications can use
SVC instructions to access OS kernel functions and device
drivers.
PendSV PendSV is an interrupt-driven request for system-level service.
In an OS environment, use PendSV for context switching when
no other exception is active.
SysTick A SysTick exception is an exception the system timer generates
when it reaches zero. Software can also generate a SysTick
exception. In an OS environment, the processor can use this
exception as system tick.
Interrupt (IRQ) A interrupt, or IRQ, is an exception signalled by a peripheral, or
generated by a software request. All interrupts are
asynchronous to instruction execution. In the system,
peripherals use interrupts to communicate with the processor.
Table 2-8 Properties of the different exception types

Exception IRQ Exception Priority Vector Activation
number1) number1) type address
or offset2)
1 - Reset -3, the highest 0x00000004 Asynchronous
2 -14 NMI -2 0x00000008 Asynchronous
3 -13 HardFault -1 0x0000000C -
4 -12 MemManage Configurable3) 0x00000010 Synchronous

XMC4500
XMC4000 Family
Table 2-8 Properties of the different exception types (contd)

Exception IRQ Exception Priority Vector Activation
number1) number1) type address
or offset2)
5 -11 BusFault Configurable3) 0x00000014 Synchronous
when precise,
asynchronous
when
imprecise
6 -10 UsageFault Configurable3) 0x00000018 Synchronous
7-10 - Reserved - - -
3)
11 -5 SVCall Configurable 0x0000002C Synchronous
12-13 - Reserved - - -
14 -2 PendSV Configurable3) 0x00000038 Asynchronous
15 -1 SysTick Configurable3) 0x0000003C Asynchronous
4)
16 and 0 and Interrupt Configurable 0x00000040 Asynchronous
above above (IRQ) and above5)
1) To simplify the software layer, the CMSIS only uses IRQ numbers and therefore uses negative values for
exceptions other than interrupts. The IPSR returns the Exception number, see Interrupt Program Status
Register on Page 2-10.
2) See Vector table for more information.
3) See System Handler Priority Registers on Page 2-69
4) See Interrupt Priority Registers on Page 2-89.
5) Increasing in steps of 4.
For an asynchronous exception, other than reset, the processor can execute another
instruction between when the exception is triggered and when the processor enters the
exception handler.
Privileged software can disable the exceptions that Table 2-8 on Page 2-28 shows as
having configurable priority, see:
System Handler Control and State Register on Page 2-71
Interrupt Clear-enable Registers on Page 2-87.
For more information about HardFaults, MemManage faults, BusFaults, and
UsageFaults, see Fault handling on Page 2-36.
2.5.3 Exception Handlers

The processor handles exceptions using:

XMC4500
XMC4000 Family
Interrupt Service Interrupts IRQ0 to IRQ111 are the exceptions handled by ISRs.
Routines (ISRs)
Fault handlers HardFault, MemManage fault, UsageFault, and BusFault are
fault exceptions handled by the fault handlers.
System handlers NMI, PendSV, SVCall SysTick, and the fault exceptions are all
system exceptions that are handled by system handlers.
2.5.4 Vector Table

The vector table contains the reset value of the stack pointer, and the start addresses,
also called exception vectors, for all exception handlers. Figure 2-6 on Page 2-30 shows
the order of the exception vectors in the vector table. The least-significant bit of each
vector must be 1, indicating that the exception handler is Thumb code, see Thumb state
on Page 2-12.
Exception number IRQ number Offset Vector
127 111 IRQ111

0x01FC
. . .
. . .
. . .
0x004C
18 2 IRQ2
0x0048
17 1 IRQ1
0x0044
16 0 IRQ0
0x0040
15 -1 Systick
0x003C
14 -2 PendSV
0x0038
13 Reserved
12 Reserved for Debug
11 -5 SVCall
0x002C
10
9
Reserved
8
7
6 -10 Usage fault
0x0018
5 -11 Bus fault
0x0014
4 -12 Memory management fault
0x0010
3 -13 Hard fault
0x000C
2 -14 NMI
0x0008
1 Reset
0x0004
Initial SP value
0x0000
Figure 2-6 Vector table

XMC4500
XMC4000 Family
On system reset, the vector table is fixed at address 0x00000000. Privileged software
can write to the VTOR to relocate the vector table start address to a different memory
location, in the range 0x00000400 to 0x3FFFFC00, see Vector Table Offset Register on
Page 2-63.
2.5.5 Exception Priorities

As Table 2-8 on Page 2-28 shows, all exceptions have an associated priority, with:
a lower priority value indicating a higher priority
configurable priorities for all exceptions except Reset, HardFault, and NMI.
If software does not configure any priorities, then all exceptions with a configurable
priority have a priority of 0. For information about configuring exception priorities see
System Handler Priority Registers on Page 2-69
Interrupt Priority Registers on Page 2-89.
Note: Configurable priority values are in the range 0-63. This means that the Reset,
HardFault, and NMI exceptions, with fixed negative priority values, always have
higher priority than any other exception.
For example, assigning a higher priority value to IRQ[0] and a lower priority value to
IRQ[1] means that IRQ[1] has higher priority than IRQ[0]. If both IRQ[1] and IRQ[0] are
asserted, IRQ[1] is processed before IRQ[0].
If multiple pending exceptions have the same priority, the pending exception with the
lowest exception number takes precedence. For example, if both IRQ[0] and IRQ[1] are
pending and have the same priority, then IRQ[0] is processed before IRQ[1].
When the processor is executing an exception handler, the exception handler is
preempted if a higher priority exception occurs. If an exception occurs with the same
priority as the exception being handled, the handler is not preempted, irrespective of the
exception number. However, the status of the new interrupt changes to pending.
2.5.6 Interrupt Priority Grouping

To increase priority control in systems with interrupts, the NVIC supports priority
grouping. This divides each interrupt priority register entry into two fields:
an upper field that defines the group priority
a lower field that defines a subpriority within the group.
Only the group priority determines preemption of interrupt exceptions. When the
processor is executing an interrupt exception handler, another interrupt with the same
group priority as the interrupt being handled does not preempt the handler,
If multiple pending interrupts have the same group priority, the subpriority field
determines the order in which they are processed. If multiple pending interrupts have the
same group priority and subpriority, the interrupt with the lowest IRQ number is
processed first.

XMC4500
XMC4000 Family
For information about splitting the interrupt priority fields into group priority and
subpriority, see Application Interrupt and Reset Control Register on Page 2-63.
2.5.7 Exception Entry and Return

Descriptions of exception handling use the following terms:
Preemption When the processor is executing an exception handler, an exception

can preempt the exception handler if its priority is higher than the priority
of the exception being handled. See Interrupt priority grouping for more
information about preemption by an interrupt.
When one exception preempts another, the exceptions are called
nested exceptions. See Exception entry on Page 2-33 more
information.
Source of figure [3].

Return This occurs when the exception handler is completed, and:
there is no pending exception with sufficient priority to be serviced
the completed exception handler was not handling a late-arriving
exception.
The processor pops the stack and restores the processor state to the
state it had before the interrupt occurred. See Exception return on
Page 2-36 for more information.

XMC4500
XMC4000 Family
Tail-chaining This mechanism speeds up exception servicing. On completion of an

exception handler, if there is a pending exception that meets the
requirements for exception entry, the stack pop is skipped and control
transfers to the new exception handler.

Late-arriving This mechanism speeds up preemption. If a higher priority exception
occurs during state saving for a previous exception, the processor
switches to handle the higher priority exception and initiates the vector
fetch for that exception. State saving is not affected by late arrival
because the state saved is the same for both exceptions. Therefore the
state saving continues uninterrupted. The processor can accept a late
arriving exception until the first instruction of the exception handler of
the original exception enters the execute stage of the processor. On
return from the exception handler of the late-arriving exception, the
normal tail-chaining rules apply.
Exception entry
Exception entry occurs when there is a pending exception with sufficient priority and
either:

XMC4500
XMC4000 Family
the processor is in Thread mode

the new exception is of higher priority than the exception being handled, in which
case the new exception preempts the original exception.
When one exception preempts another, the exceptions are nested.
Sufficient priority means the exception has more priority than any limits set by the mask
registers, see Exception mask registers on Page 2-13. An exception with less priority
than this is pending but is not handled by the processor.
When the processor takes an exception, unless the exception is a tail-chained or a late-
arriving exception, the processor pushes information onto the current stack. This
operation is referred to as stacking and the structure of eight data words is referred as
the stack frame.
When using floating-point routines, the Cortex-M4 processor automatically stacks the
architected floating-point state on exception entry. Figure 2-7 on Page 2-35 shows the
Cortex-M4 stack frame layout when floating-point state is preserved on the stack as the
result of an interrupt or an exception.
Note: Where stack space for floating-point state is not allocated, the stack frame is the
same as that of ARMv7-M implementations without an FPU. Figure 2-7 on
Page 2-35 shows this stack frame also.

XMC4500
XMC4000 Family
...
Pre-IRQ top of stack
{aligner}
FPSCR
S15
S14
S13
S12
S11
S10
S9
S8
S7
S6
S5
S4
S3
S2
S1 ...
Pre-IRQ top of stack
S0 {aligner}
xPSR Decreasing xPSR
PC memory PC
address
LR LR
R12 R12
R3 R3
R2 R2
R1 R1
R0 IRQ top of stack R0 IRQ top of stack
Exception frame with Exception frame without

floating-point storage floating-point storage
Figure 2-7 Exception stack frame

Immediately after stacking, the stack pointer indicates the lowest address in the stack
frame. The alignment of the stack frame is controlled via the STKALIGN bit of the
Configuration Control Register (CCR).
The stack frame includes the return address. This is the address of the next instruction
in the interrupted program. This value is restored to the PC at exception return so that
the interrupted program resumes.
In parallel to the stacking operation, the processor performs a vector fetch that reads the
exception handler start address from the vector table. When stacking is complete, the
processor starts executing the exception handler. At the same time, the processor writes
an EXC_RETURN value to the LR. This indicates which stack pointer corresponds to the
stack frame and what operation mode the processor was in before the entry occurred.
If no higher priority exception occurs during exception entry, the processor starts
executing the exception handler and automatically changes the status of the
corresponding pending interrupt to active.

XMC4500
XMC4000 Family
If another higher priority exception occurs during exception entry, the processor starts
executing the exception handler for this exception and does not change the pending
status of the earlier exception. This is the late arrival case.
Exception return
Exception return occurs when the processor is in Handler mode and executes one of the
following instructions to load the EXC_RETURN value into the PC:
an LDM or POP instruction that loads the PC
an LDR instruction with PC as the destination
a BX instruction using any register.
EXC_RETURN is the value loaded into the LR on exception entry. The exception
mechanism relies on this value to detect when the processor has completed an
exception handler. The lowest five bits of this value provide information on the return
stack and processor mode. Table 2-9 shows the EXC_RETURN values with a
description of the exception return behavior.
All EXC_RETURN values have bits[31:5] set to one. When this value is loaded into the
PC it indicates to the processor that the exception is complete, and the processor
initiates the appropriate exception return sequence.
Table 2-9 Exception return behavior

EXC_RETURN[31:0] Description
0xFFFFFFF1 Return to Handler mode, exception return uses non-floating-
point state from the MSP and execution uses MSP after return.
0xFFFFFFF9 Return to Thread mode, exception return uses non-floating-
point state from MSP and execution uses MSP after return.
0xFFFFFFFD Return to Thread mode, exception return uses non-floating-
point state from the PSP and execution uses PSP after return.
0xFFFFFFE1 Return to Handler mode, exception return uses floating-point-
state from MSP and execution uses MSP after return.
0xFFFFFFE9 Return to Thread mode, exception return uses floating-point
state from MSP and execution uses MSP after return.
0xFFFFFFED Return to Thread mode, exception return uses floating-point
state from PSP and execution uses PSP after return.
2.6 Fault Handling

Faults are a subset of the exceptions, see Exception model on Page 2-26. Faults are
generated by:
a bus error on:

XMC4500
XMC4000 Family
an instruction fetch or vector table load

a data access.
an internally-detected error such as an undefined instruction
attempting to execute an instruction from a memory region marked as Non-
Executable (XN).
a privilege violation or an attempt to access an unmanaged region causing an MPU
fault
2.6.1 Fault Types

Table 2-10 shows the types of fault, the handler used for the fault, the corresponding
fault status register, and the register bit that indicates that the fault has occurred. See
Configurable Fault Status Register on page 4-24 for more information about the fault
status registers.
Table 2-10 Faults

Fault Handler Bit name Fault status
register
Bus error on a vector read HardFault VECTTBL HardFault Status
Fault escalated to a hard FORCED Register on
fault Page 2-80
MPU or default memory map MemManage - -

mismatch:
on instruction access IACCVIOL1) MemManage Fault
on data access DACCVIOL Address Register on
Page 2-81
during exception MSTKERR
stacking
during exception MUNSKERR
unstacking
during lazy floating-point MLSPERR
state preservation

XMC4500
XMC4000 Family
Table 2-10 Faults (contd)

Fault Handler Bit name Fault status
register
Bus error: BusFault - -
during exception STKERR BusFault Status
stacking Register on
during exception UNSTKERR Page 2-73
unstacking
during instruction IBUSERR
prefetch
during lazy floating-point LSPERR
state preservation
Precise data bus error PRECISERR
Imprecise data bus error IMPRECISERR
Attempt to access a UsageFault NOCP UsageFault Status
coprocessor Register on
Undefined instruction UNDEFINSTR Page 2-73
Attempt to enter an invalid INVSTATE

instruction set state2)
Invalid EXC_RETURN value INVPC
Illegal unaligned load or UNALIGNED
store
Divide By 0 DIVBYZERO
1) Occurs on an access to an XN region even if the processor does not include an MPU or the MPU is disabled.
2) Attempting to use an instruction set other than the Thumb instruction set or returns to a non load/store-multiple
instruction with ICI continuation.
2.6.2 Fault Escalation and Hard Faults

All faults exceptions except for HardFault have configurable exception priority, see
System Handler Priority Registers on page 4-21. Software can disable execution of the
handlers for these faults, see System Handler Control and State Register on page 4-23.
Usually, the exception priority, together with the values of the exception mask registers,
determines whether the processor enters the fault handler, and whether a fault handler
can preempt another fault handler. as described in Exception model on Page 2-26.
In some situations, a fault with configurable priority is treated as a HardFault. This is
called priority escalation, and the fault is described as escalated to HardFault. Escalation
to HardFault occurs when:

XMC4500
XMC4000 Family
A fault handler causes the same kind of fault as the one it is servicing. This escalation
to HardFault occurs because a fault handler cannot preempt itself because it must
have the same priority as the current priority level.
A fault handler causes a fault with the same or lower priority as the fault it is servicing.
This is because the handler for the new fault cannot preempt the currently executing
fault handler.
An exception handler causes a fault for which the priority is the same as or lower than
the currently executing exception.
A fault occurs and the handler for that fault is not enabled.
If a BusFault occurs during a stack push when entering a BusFault handler, the BusFault
does not escalate to a HardFault. This means that if a corrupted stack causes a fault, the
fault handler executes even though the stack push for the handler failed. The fault
handler operates but the stack contents are corrupted.
Note: Only Reset and NMI can preempt the fixed priority HardFault. A HardFault can
preempt any exception other than Reset, NMI, or another HardFault.
2.6.3 Fault Status Registers and Fault Address Registers

The fault status registers indicate the cause of a fault. For BusFaults and MemManage
faults, the fault address register indicates the address accessed by the operation that
caused the fault, as shown in Table 2-11.
Table 2-11 Fault status and fault address registers

Handler Status Address Register description
register register
name name
HardFault HFSR - HardFault Status Register on Page 2-80
MemManage MMFSR MMFAR MemManage Fault Status Register
Page 2-73
MemManage Fault Address Register
Page 2-81
BusFault BFSR BFAR BusFault Status Register on Page 2-73
BusFault Address Register on Page 2-82
UsageFault UFSR - UsageFault Status Register on Page 2-73
2.6.4 Lockup
The processor enters a lockup state if a fault occurs when executing the NMI or
HardFault handlers. When the processor is in lockup state it does not execute any
instructions. The processor remains in lockup state until either:
it is reset

XMC4500
XMC4000 Family
an NMI occurs
it is halted by a debugger
Note: If lockup state occurs from the NMI handler a subsequent NMI does not cause the
processor to leave lockup state.
2.7 Power Management

The Cortex-M4 processor sleep modes reduce power consumption:
Sleep mode stops the processor clock.
Deep sleep mode stops the system clock and switches off the PLL and flash memory.
The SLEEPDEEP bit of the SCR selects which sleep mode is used, see System Control
Register on Page 2-66. For more information about the behavior of the sleep modes see
section Power Management in SCU chapter.
The following section describes the mechanisms for entering sleep mode, and the
conditions for waking up from sleep mode.
2.7.1 Entering Sleep Mode

This section describes the mechanisms software can use to put the processor into sleep
mode
The system can generate spurious wakeup events, for example a debug operation
wakes up the processor. Therefore software must be able to put the processor back into
sleep mode after such an event. A program might have an idle loop to put the processor
back to sleep mode.
Wait for interrupt

The wait for interrupt instruction, WFI, causes immediate entry to sleep mode unless the
wake-up condition is true, see Wakeup from WFI or sleep-on-exit on Page 2-41. When
the processor executes a WFI instruction it stops executing instructions and enters sleep
mode.
Wait for event

The wait for event instruction, WFE, causes entry to sleep mode depending on the value
of a one-bit event register. When the processor executes a WFE instruction, it checks
the value of the event register:
0 The processor stops executing instructions and enters sleep mode.
1 The processor clears the register to 0 and continues executing instructions without
entering sleep mode.
If the event register is 1, this indicate that the processor must not enter sleep mode on
execution of a WFE instruction. Typically, this is because an external event signal is

XMC4500
XMC4000 Family
asserted, or a processor in the system has executed an SEV instruction, see SEV on
page 3-166. Software cannot access this register directly.
Sleep-on-exit
If the SLEEPONEXIT bit of the SCR is set to 1, when the processor completes the
execution of all exception handlers it returns to Thread mode and immediately enters
sleep mode. Use this mechanism in applications that only require the processor to run
when an exception occurs.
2.7.2 Wakeup from Sleep Mode

The conditions for the processor to wakeup depend on the mechanism that cause it to
enter sleep mode.
Wakeup from WFI or sleep-on-exit

Normally, the processor wakes up only when it detects an exception with sufficient
priority to cause exception entry. Some embedded systems might have to execute
system restore tasks after the processor wakes up, and before it executes an interrupt
handler. To achieve this set the PRIMASK bit to 1 and the FAULTMASK bit to 0. If an
interrupt arrives that is enabled and has a higher priority than current exception priority,
the processor wakes up but does not execute the interrupt handler until the processor
sets PRIMASK to zero. For more information about PRIMASK and FAULTMASK see
Exception mask registers on Page 2-13.
Wakeup from WFE

The processor wakes up if:
it detects an exception with sufficient priority to cause exception entry
it detects an external event signal, see The external event input
In addition, if the SEVONPEND bit in the SCR is set to 1, any new pending interrupt
triggers an event and wakes up the processor, even if the interrupt is disabled or has
insufficient priority to cause exception entry. For more information about the SCR see
System Control Register on Page 2-66.
2.7.3 The External Event Input

The processor provides an external event input signal. Peripherals can drive this signal,
either to wake the processor from WFE, or to set the internal WFE event register to one
to indicate that the processor must not enter sleep mode on a later WFE instruction. See
Wait for event on Page 2-40 for more information.

XMC4500
XMC4000 Family
2.7.4 Power Management Programming Hints

ISO/IEC C cannot directly generate the WFI and WFE instructions. The CMSIS provides
the following functions for these instructions:
void __WFE(void) // Wait for Event
void __WFI(void) // Wait for Interrupt
2.8 Private Peripherals

The following sections are the reference material for the ARM Cortex-M4 core
peripherals.
2.8.1 About the Private Peripherals

The address map of the Private Peripheral Bus (PPB) is:
Table 2-12 Core peripheral register regions

Address Core peripheral Description
0xE000E008- System control block Section 2.8.2 and Section 2.9.1
0xE000E00F
0xE000E010- System timer Section 2.8.3 and Section 2.9.2
0xE000E01F
0xE000E100- Nested Vectored Interrupt Section 2.8.4 and Section 2.9.3
0xE000E4EF Controller
0xE000ED00- System control block Section 2.8.2 and Section 2.9.1
0xE000ED3F
0xE000ED90- Memory protection unit Section 2.8.5 and Section 2.9.4
0xE000EDB8
0xE000EF00- Nested Vectored Interrupt Section 2.8.4 and Section 2.9.3
0xE000EF03 Controller
0xE000EF30- Floating Point Unit Section 2.8.6 and Section 2.9.5
0xE000EF44
2.8.2 System control block

The System control block (SCB) provides system implementation information, and
system control. This includes configuration, control, and reporting of the system
exceptions. The system control block registers are:

XMC4500
XMC4000 Family
2.8.2.1 System control block design hints and tips

Ensure software uses aligned accesses of the correct size to access the system control
block registers:
except for the CFSR and SHPR1-SHPR3, it must use aligned word accesses
for the CFSR and SHPR1-SHPR3 it can use byte or aligned halfword or word
accesses.
The processor does not support unaligned accesses to system control block registers.
In a fault handler, to determine the true faulting address:
1. Read and save the MMFAR or BFAR value.
2. Read the MMARVALID bit in the MMFSR, or the BFARVALID bit in the BFSR. The
MMFAR or BFAR address is valid only if this bit is 1.
Software must follow this sequence because another higher priority exception might
change the MMFAR or BFAR value. For example, if a higher priority handler preempts
the current fault handler, the other fault might change the MMFAR or BFAR value.
2.8.3 System timer, SysTick

The processor has a 24-bit system timer, SysTick, that counts down from the reload
value to zero, reloads, that is wraps to, the value in the SYST_RVR register on the next
clock edge, then counts down on subsequent clocks.
Note: When the processor is halted for debugging the counter does not decrement.
2.8.3.1 SysTick design hints and tips

The SysTick counter runs on the clock selected by SYST_CSR.CLKSOURCE. If the
selected clock signal is stopped, the SysTick counter stops.
Ensure software uses aligned word accesses to access the SysTick registers.
The SysTick counter reload and current value are undefined at reset, the correct
initialization sequence for the SysTick counter is:
1. Program reload value.
2. Clear current value.
3. Program Control and Status register.
2.8.4 Nested Vectored Interrupt Controller (NVIC)

This section describes the NVIC and the registers it uses. The XMC4500 NVIC supports:
112 interrupts.
A programmable priority level of 0-63 for each interrupt. A higher level corresponds
to a lower priority, so level 0 is the highest interrupt priority.
Level and pulse detection of interrupt signals.
Dynamic reprioritization of interrupts.

XMC4500
XMC4000 Family
Grouping of priority values into group priority and subpriority fields.

Interrupt tail-chaining.
An external Non-maskable interrupt (NMI)
The processor automatically stacks its state on exception entry and unstacks this state
on exception exit, with no instruction overhead. This provides low latency exception
handling. The hardware implementation of the NVIC registers is:
2.8.4.1 Level-sensitive and pulse interrupts

The processor supports both level-sensitive and pulse interrupts. Pulse interrupts are
also described as edge-triggered interrupts.
A level-sensitive interrupt is held asserted until the peripheral deasserts the interrupt
signal. Typically this happens because the ISR accesses the peripheral, causing it to
clear the interrupt request. A pulse interrupt is an interrupt signal sampled synchronously
on the rising edge of the processor clock. To ensure the NVIC detects the interrupt, the
peripheral must assert the interrupt signal for at least one clock cycle, during which the
NVIC detects the pulse and latches the interrupt.
When the processor enters the ISR, it automatically removes the pending state from the
interrupt, see next section. For a level-sensitive interrupt, if the signal is not deasserted
before the processor returns from the ISR, the interrupt becomes pending again, and the
processor must execute its ISR again. This means that the peripheral can hold the
interrupt signal asserted until it no longer requires servicing.
See section Service Request Distribution in the Service Request Processing chapter
for details about which interrupts are level-based and which are pulsed.
Hardware and software control of interrupts

The Cortex-M4 latches all interrupts. A peripheral interrupt becomes pending for one of
the following reasons:
the NVIC detects that the interrupt signal is HIGH and the interrupt is not active
the NVIC detects a rising edge on the interrupt signal
software writes to the corresponding interrupt set-pending register bit, see Interrupt
Set-pending Registers on Page 2-88 or to the STIR to make an interrupt pending,
see Software Trigger Interrupt Register on Page 2-91.
A pending interrupt remains pending until one of the following:
The processor enters the ISR for the interrupt. This changes the state of the interrupt
from pending to active. Then:
For a level-sensitive interrupt, when the processor returns from the ISR, the NVIC
samples the interrupt signal. If the signal is asserted, the state of the interrupt
changes to pending, which might cause the processor to immediately re-enter the
ISR. Otherwise, the state of the interrupt changes to inactive.

XMC4500
XMC4000 Family
For a pulse interrupt, the NVIC continues to monitor the interrupt signal, and if this
is pulsed the state of the interrupt changes to pending and active. In this case,
when the processor returns from the ISR the state of the interrupt changes to
pending, which might cause the processor to immediately re-enter the ISR.
If the interrupt signal is not pulsed while the processor is in the ISR, when the
processor returns from the ISR the state of the interrupt changes to inactive.
Software writes to the corresponding interrupt clear-pending register bit.
For a level-sensitive interrupt, if the interrupt signal is still asserted, the state of the
interrupt does not change. Otherwise, the state of the interrupt changes to inactive.
For a pulse interrupt, state of the interrupt changes to:
inactive, if the state was pending
active, if the state was active and pending.
2.8.4.2 NVIC design hints and tips

Ensure software uses correctly aligned register accesses. The processor does not
support unaligned accesses to NVIC registers. See the individual register descriptions
for the supported access sizes.
A interrupt can enter pending state even if it is disabled. Disabling an interrupt only
prevents the processor from taking that interrupt.
Before programming VTOR to relocate the vector table, ensure the vector table entries
of the new vector table are setup for fault handlers, NMI and all enabled exception like
interrupts. For more information see Vector Table Offset Register on Page 2-63.
2.8.4.3 Using CMSIS functions to access NVIC

CMSIS functions enable software portability between different Cortex-M profile
processors. To ensure Cortex-M portability, use the functions marked for Cortex-M
portability in the table below.
CMSIS provides a number of functions for NVIC control, including:
Table 2-13 CMSIS functions for NVIC control

CMSIS interrupt control function Description Cortex-M
Portable
void NVIC_SetPriorityGrouping( Set the priority grouping. No
uint32_t priority_grouping)
uint32_t Get the priority grouping. No
NVIC_GetPriorityGrouping(
void)
void NVIC_EnableIRQ( Enables IRQn. Yes
IRQn_t IRQn)

XMC4500
XMC4000 Family
Table 2-13 CMSIS functions for NVIC control (contd)

CMSIS interrupt control function Description Cortex-M
Portable
void NVIC_DisableIRQ( Disables IRQn. Yes
IRQn_t IRQn)
uint32_t NVIC_GetPendingIRQ( Return IRQ-Number (true) if Yes
IRQn_t IRQn) IRQn is pending.
void NVIC_SetPendingIRQ( Set IRQn pending. Yes
IRQn_t IRQn)
void NVIC_ClearPendingIRQ( Clear IRQn pending. Yes
IRQn_t IRQn)
uint32_t NVIC_GetActive( Return the IRQ number of the No
IRQn_t IRQn) active interrupt.
void NVIC_SetPriority( Set priority for IRQn. Yes
IRQn_t IRQn,
uint32_t priority)
uint32_t NVIC_GetPriority( Read priority of IRQn. Yes
IRQn_t IRQn)
uint32_t NVIC_EncodePriority( Encodes the priority for an No
uint32_t PriorityGroup, interrupt with the given priority
uint32_t PreemptPriority, group, preemptive priority
uint32_t SubPriority) value and sub priority value.
void NVIC_DecodePriority( Decodes an interrupt priority No
uint32_t Priority, value with the given priority
uint32_t PriorityGroup, group to preemptive priority
uint32_t* pPreemptPriority, value and sub priority value.
uint32_t* pSubPriority)
void NVIC_SystemReset(void) Reset the system Yes
The parameter IRQn is the IRQ number, see Table 2-8 on Page 2-28. For more
information about these functions see the CMSIS documentation [4].
2.8.5 Memory Protection Unit (MPU)

The MPU divides the memory map into a number of regions, and defines the location,
size, access permissions, and memory attributes of each region. It supports:
independent attribute settings for each region
overlapping regions
export of memory attributes to the system

XMC4500
XMC4000 Family
The memory attributes affect the behavior of memory accesses to the region. The
Cortex-M4 MPU defines:
eight separate memory regions, 0-7
a background region
When memory regions overlap, a memory access is affected by the attributes of the
region with the highest number. For example, the attributes for region 7 take precedence
over the attributes of any region that overlaps region 7.
The background region has the same memory access attributes as the default memory
map, but is accessible from privileged software only.
The Cortex-M4 MPU memory map is unified. This means instruction accesses and data
accesses have same region settings.
If a program accesses a memory location that is prohibited by the MPU, the processor
generates a MemManage fault. This causes a fault exception, and might cause
termination of the process in an OS environment.
In an OS environment, the kernel can update the MPU region setting dynamically based
on the process to be executed. Typically, an embedded OS uses the MPU for memory
protection.
Configuration of MPU regions is based on memory types, see Memory regions, types
and attributes on Page 2-20.
Table 2-14 shows the possible MPU region attributes.
Note: The shareability and cache attributes are not relevant to the XMC4500.
Table 2-14 Memory attributes summary

Address Shareability Other attributes Description
Strongly- - - All accesses to Strongly-ordered
ordered memory occur in program order.
All Strongly-ordered regions are
assumed to be shared.
Device Shared - Memory-mapped peripherals that
several processors share.
Non-shared - Memory-mapped peripherals that
only a single processor uses.
Normal Shared Non-cacheable Normal memory that is shared
Write-through or between several processors.
Write-back Cacheable
Non-shared Non-cacheable Normal memory that only a single
Write-through or processor uses.
Write-back Cacheable

XMC4500
XMC4000 Family
2.8.5.1 MPU Access Permission Attributes

This section describes the MPU access permission attributes. The access permission
bits, TEX, C, B, S, AP, and XN, of the RASR, control access to the corresponding
memory region. If an access is made to an area of memory without the required
permissions, then the MPU generates a permission fault. Table 2-15 shows encodings
for the TEX, C, B, and S access permission bits.
Table 2-15 TEX, C, B, and S encoding

TEX C B S Memory type Shareability Other attributes
0b000 0 0 x Strongly-ordered Shareable -
1 x Device Shareable -
1 0 0 Normal Not shareable Outer and inner write-
1 Shareable through. No write allocate.
1 0 Normal Not shareable Outer and inner write-

1 Shareable back. No write allocate.
0b001 0 0 0 Normal Not shareable Outer and inner
1 Shareable noncacheable.
1 x1) Reserved encoding -

1)
1 0 x Implementation defined attributes.
1 0 Normal Not shareable Outer and inner write-
1 Shareable back. Write and read
allocate.
0b010 0 0 x1) Device Not shareable Nonshared Device.
1)
1 x Reserved encoding -
1)
1 x x Reserved encoding -
0b1BB A 0 Normal Not shareable Cached memory, BB =
A 1 Shareable outer policy, AA = inner
policy. See Table 2-16 on
Page 2-49 for the
encoding of the AA and
BB bits.
1) The MPU ignores the value of this bit.

XMC4500
XMC4000 Family
Table 2-16 shows the cache policy for memory attribute encodings with a TEX value is
in the range 4-7.
Table 2-16 Cache policy for memory attribute encoding

Encoding, AA or BB Corresponding cache policy
00 Non-cacheable
01 Write back, write and read allocate
10 Write through, no write allocate
11 Write back, no write allocate
MPU configuration for the XMC4500

The XMC4500 has only a single processor and no caches. However to enable portability
it is recommended to program the MPU as follows:
Table 2-17 Memory region attributes for a microcontroller

Memory region TEX C B S Memory type and attributes
Internal Flash 0b000 1 0 0 Normal memory, Non-shareable, write-
memory through
Internal SRAM 0b000 1 0 1 Normal memory, Shareable, write-through
memories
External 0b000 1 1 1 Normal memory, Shareable, write-back,
memories write-allocate
Peripherals 0b000 0 1 1 Device memory, Shareable
Table 2-18 shows the AP encodings that define the access permissions for privileged
and unprivileged software.
Table 2-18 AP encoding

AP[2:0] Privileged Unprivileged Description
permissions permissions
000 No access No access All accesses generate a
permission fault
001 rw No access Access from privileged software
only
010 rw r Writes by unprivileged software
generate a permission fault
011 rw rw Full access

XMC4500
XMC4000 Family
Table 2-18 AP encoding (contd)

AP[2:0] Privileged Unprivileged Description
permissions permissions
100 Unpredictable Unpredictable Reserved
101 r No access Reads by privileged software only
110 r r Read only, by privileged or
unprivileged software
111 r r Read only, by privileged or
unprivileged software
2.8.5.2 MPU Mismatch

When an access violates the MPU permissions, the processor generates a MemManage
fault, see Exceptions and interrupts on Page 2-17. The MMFSR indicates the cause of
the fault. See MemManage Fault Status Register on Page 2-73 for more information.
2.8.5.3 Updating an MPU Region

To update the attributes for an MPU region, update the MPU_RNR, MPU_RBAR and
MPU_RASR registers. You can program each register separately, or use a multiple-word
write to program all of these registers. You can use the MPU_RBAR and MPU_RASR
aliases to program up to four regions simultaneously using an STM instruction.
Updating an MPU region using separate words

Simple code to configure one region:
; R1 = region number
; R2 = size/enable
; R3 = attributes
; R4 = address
LDR R0,=MPU_RNR ; 0xE000ED98, MPU region number register
STR R1, [R0, #0x0] ; Region Number
STR R4, [R0, #0x4] ; Region Base Address
STRH R2, [R0, #0x8] ; Region Size and Enable
STRH R3, [R0, #0xA] ; Region Attribute
Disable a region before writing new region settings to the MPU if you have previously
enabled the region being changed. For example:
; R2 = size/enable
; R3 = attributes
; R4 = address

XMC4500
XMC4000 Family
LDR R0,=MPU_RNR ; 0xE000ED98, MPU region number

register
BIC R2, R2, #1 ; Disable
STRH R3, [R0, #0xA] ; Region Attribute
ORR R2, #1 ; Enable
Software must use memory barrier instructions:
before MPU setup if there might be outstanding memory transfers, such as buffered
writes, that might be affected by the change in MPU settings
after MPU setup if it includes memory transfers that must use the new MPU settings.
However, memory barrier instructions are not required if the MPU setup process starts
by entering an exception handler, or is followed by an exception return, because the
exception entry and exception return mechanism cause memory barrier behavior.
Software does not require any memory barrier instructions during MPU setup, because
it accesses the MPU through the PPB, which is a Strongly-Ordered memory region.
For example, if you want all of the memory access behavior to take effect immediately
after the programming sequence, use a DSB instruction and an ISB instruction. A DSB
is required after changing MPU settings, such as at the end of context switch. An ISB is
required if the code that programs the MPU region or regions is entered using a branch
or call. If the programming sequence is entered using a return from exception, or by
taking an exception, then you do not require an ISB.
Updating an MPU region using multi-word writes

You can program directly using multi-word writes, depending on how the information is
divided. Consider the following reprogramming:
; R2 = address
; R3 = size, attributes in one
LDR R0, =MPU_RNR ; 0xE000ED98, MPU region number register
STR R3, [R0, #0x8] ; Region Attribute, Size and Enable
Use an STM instruction to optimize this:
; R2 = address
; R3 = size, attributes in one
LDR R0, =MPU_RNR ; 0xE000ED98, MPU region number register

XMC4500
XMC4000 Family
STM R0, {R1-R3} ; Region Number, address, attribute, size and

enable
You can do this in two words for pre-packed information. This means that the
MPU_RBAR contains the required region number and had the VALID bit set to 1, see
MPU Region Base Address Register on Page 2-95. Use this when the data is statically
packed, for example in a boot loader:
; R1 = address and region number in one
; R2 = size and attributes in one
LDR R0, =MPU_RBAR ; 0xE000ED9C, MPU Region Base register
STR R1, [R0, #0x0] ; Region base address and
; region number combined with VALID (bit 4)
set to 1
STR R2, [R0, #0x4] ; Region Attribute, Size and Enable
Subregions
Regions of 256 bytes or more are divided into eight equal-sized subregions. Set the
corresponding bit in the SRD field of the MPU_RASR to disable a subregion, see MPU
Region Attribute and Size Register on Page 2-97. The least significant bit of SRD
controls the first subregion, and the most significant bit controls the last subregion.
Disabling a subregion means another region overlapping the disabled range matches
instead. If no other enabled region overlaps the disabled subregion the MPU issues a
fault.
Regions of 32, 64, and 128 bytes do not support subregions, With regions of these sizes,
you must set the SRD field to 0x00, otherwise the MPU behavior is Unpredictable.
Example of SRD use

Two regions with the same base address overlap. Region one is 128KB, and region two
is 512KB. To ensure the attributes from region one apply to the first 128KB region, set
the SRD field for region two to 0b00000011 to disable the first two subregions, as the
figure shows.

XMC4500
XMC4000 Family
Region 2, with Offset from

subregions base address
512KB
448KB
384KB
320KB
256KB
Region 1 192KB
128KB
Disabled subregion
64KB
Disabled subregion
Base address of both regions 0
Figure 2-8 Example of SRD use
2.8.5.4 MPU Design Hints and Tips

To avoid unexpected behavior, disable the interrupts before updating the attributes of a
region that the interrupt handlers might access.
Ensure software uses aligned accesses of the correct size to access MPU registers:
except for the MPU_RASR, it must use aligned word accesses
for the MPU_RASR it can use byte or aligned halfword or word accesses.
The processor does not support unaligned accesses to MPU registers.
When setting up the MPU, and if the MPU has previously been programmed, disable
unused regions to prevent any previous region settings from affecting the new MPU
setup.
In the XMC4500 the shareability and cache policy attributes do not affect the system
behavior. However, using these settings for the MPU regions can make the application
code more portable.
2.8.6 Floating Point Unit (FPU)

The Cortex-M4 FPU implements the FPv4-SP floating-point extension.
The FPU fully supports single-precision add, subtract, multiply, divide, multiply and
accumulate, and square root operations. It also provides conversions between fixed-
point and floating-point data formats, and floating-point constant instructions.
The FPU provides floating-point computation functionality that is compliant with the
ANSI/IEEE Std 754-2008, IEEE Standard for Binary Floating-Point Arithmetic, referred
to as the IEEE 754 standard [4].
The FPU contains 32 single-precision extension registers, which you can also access as
16 doubleword registers for load, store, and move operations.

XMC4500
XMC4000 Family
2.8.6.1 Enabling the FPU

The FPU is disabled from reset. You must enable it before you can use any floating-point
instructions. The Example shows an example code sequence for enabling the FPU in
both privileged and user modes. The processor must be in privileged mode to read from
and write to the CPACR.
Example: Enabling the FPU

; CPACR is located at address 0xE000ED88
LDR.W R0, =0xE000ED88
; Read CPACR
LDR R1, [R0]
; Set bits 20-23 to enable CP10 and CP11 coprocessors
ORR R1, R1, #(0xF << 20)
; Write back the modified value to the CPACR
STR R1, [R0]; wait for store to complete
DSB
;reset pipeline now the FPU is enabled
ISB
2.9 PPB Registers

The CPU private peripherals registers base address is E000E000H.
Table 2-19 Registers Overview

Register Register Long Name Offset Access Mode Description
Short Name Address Read Write see
SCS
ACTLR Auxiliary Control 008H PV, 32 PV, 32 Page 2-57
Register
CPUID CPUID Base Register D00H PV, 32 PV, 32 Page 2-59
ICSR Interrupt Control and D04H PV, 32 PV, 32 Page 2-60
State Register
VTOR Vector Table Offset D08H PV, 32 PV, 32 Page 2-63
Register
AIRCR Application Interrupt D0CH PV, 32 PV, 32 Page 2-63
and Reset Control
Register
SCR System Control D10H PV, 32 PV, 32 Page 2-66
Register

XMC4500
XMC4000 Family
Table 2-19 Registers Overview (contd)

CCR Configuration and D14H PV, 32 PV, 32 Page 2-67
Control Register
SHPR1 System Handler Priority D18H PV, 32 PV, 32 Page 2-70
Register 1
SHPR2 System Handler Priority D1CH PV, 32 PV, 32 Page 2-70
Register 2
SHPR3 System Handler Priority D20H PV, 32 PV, 32 Page 2-71
Register 3
SHCRS System Handler Control D24H PV, 32 PV, 32 Page 2-71
and State Register
CFSR Configurable Fault D28H PV, 32 PV, 32 Page 2-73
Status Register
MMSR1) MemManage Fault D28H PV, 32 PV, 32 Page 2-73
Status Register
BFSR1) BusFault Status D29H PV, 32 PV, 32 Page 2-73
Register
UFSR1) UsageFault Status D2AH PV, 32 PV, 32 Page 2-73
Register
HFSR HardFault Status D2CH PV, 32 PV, 32 Page 2-80
Register
MMAR MemManage Fault D34H PV, 32 PV, 32 Page 2-81
Address Register
BFAR BusFault Address D38H PV, 32 PV, 32 Page 2-82
Register
AFSR Auxiliary Fault Status D3CH PV, 32 PV, 32 Page 2-82
Register
SysTick
SYST_CSR SysTick Control and 010H PV, 32 PV, 32 Page 2-83
Status Register
SYST_RVR SysTick Reload Value 014H PV, 32 PV, 32 Page 2-84
Register
SYST_CVR SysTick Current Value 018H PV, 32 PV, 32 Page 2-85
Register

XMC4500
XMC4000 Family

SYST_CALIB SysTick Calibration 01CH PV, 32 - Page 2-85
Value Register
NVIC
NVIC_ISER0- Interrupt Set-enable 100H PV, 32 PV, 32 Page 2-86
NVIC_ISER3 Registers
NVIC_ICER0- Interrupt Clear-enable 180H PV, 32 PV, 32 Page 2-87
NVIC_ICER3 Registers
NVIC_ISPR0- Interrupt Set-pending 200H PV, 32 PV, 32 Page 2-88
NVIC_ISPR3 Registers
NVIC_ICPR0- Interrupt Clear-pending 280H PV, 32 PV, 32 Page 2-88
NVIC_ICPR3 Registers
NVIC_IABR0- Interrupt Active Bit 300H PV, 32 PV, 32 Page 2-89
NVIC_IABR3 Registers
NVIC_IPR0- Interrupt Priority 400H PV, 32 PV, 32 Page 2-89
NVIC_IPR27 Registers
STIR Software Trigger F00H Configurable2) Page 2-91
Interrupt Register
MPU
MPU_TYPE MPU Type Register D90H PV, 32 PV, 32 Page 2-92
MPU_CTRL MPU Control Register D94H PV, 32 PV, 32 Page 2-92
MPU_RNR MPU Region Number D98H PV, 32 PV, 32 Page 2-95
Register
MPU_RBAR MPU Region Base D9CH PV, 32 PV, 32 Page 2-95
Address Register
MPU_RASR MPU Region Attribute DA0H PV, 32 PV, 32 Page 2-97
and Size Register
MPU_RBAR_A1 Alias of RBAR, see DA4H PV, 32 PV, 32 Page 2-95
MPU Region Base
Address Register
MPU_RASR_A1 Alias of RASR, see DA8H PV, 32 PV, 32 Page 2-97
MPU Region Attribute
and Size Register

XMC4500
XMC4000 Family

MPU_RBAR_A2 Alias of RBAR, see DACH PV, 32 PV, 32 Page 2-95
MPU Region Base
Address Register
MPU_RASR_A2 Alias of RASR, see DB0H PV, 32 PV, 32 Page 2-97
and Size Register
MPU_RBAR_A3 Alias of RBAR, see DB4H PV, 32 PV, 32 Page 2-95
MPU Region Base
Address Register
MPU_RASR_A3 Alias of RASR, see DB8H PV, 32 PV, 32 Page 2-97
and Size Register
FPU
CPACR Coprocessor Access D88H PV, 32 PV, 32 Page 2-100
Control Register
FPCCR Floating-point Context F34H U, PV, U, PV, Page 2-101
Control Register 32 32
FPCAR Floating-point Context F38H U, PV, U, PV, Page 2-103
Address Register 32 32
FPSCR Floating-point Status - U, PV, U, PV, Page 2-104
FPDSCR Floating-point Default F3CH U, PV, U, PV, Page 2-106
Status Control Register 32 32
Reserved Unused address space All gaps nBE nBE
1) A subregister of the CFSR.
2) See the register description for more information.
2.9.1 SCS Registers
Auxiliary Control Register

The ACTLR provides disable bits for the following processor functions:
IT folding
write buffer use for accesses to the default memory map
interruption of multi-cycle instructions.

XMC4500
XMC4000 Family
By default this register is set to provide optimum performance from the Cortex-M4
processor, and does not normally require modification.
ACTLR
Auxiliary Control Register (E000 E008H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DISD DIS
DISO DISF DISF
0 0 EFW MCY
OFP PCA OLD
BUF CINT
r rw rw r rw rw rw

DISMCYCINT 0 rw Disable load/store multiple
When set to 1, disables interruption of load multiple
and store multiple instructions. This increases the
interrupt latency of the processor because any LDM
or STM must complete before the processor can
stack the current state and enter the interrupt
handler.
DISDEFWBUF 1 rw Disable write buffer
When set to 1, disables write buffer use during
default memory map accesses. This causes all
BusFaults to be precise BusFaults but decreases
performance because any store to memory must
complete before the processor can execute the next
instruction.
Note: This bit only affects write buffers implemented
in the Cortex-M4 processor.
DISFOLD 2 rw Disable IT folding
When set to 1, disables IT folding.
DISFPCA 8 rw Disable FPCA update
Disable automatic update of CONTROL.FPCA.

XMC4500
XMC4000 Family

DISOOFP 9 rw Disable out of order FP execution
Disables floating point instructions completing out of
order with respect to integer instructions.
About IT folding
In some situations, the processor can start executing the first instruction in an IT block
while it is still executing the IT instruction. This behavior is called IT folding, and improves
performance, However, IT folding can cause jitter in looping. If a task must avoid jitter,
set the DISFOLD bit to 1 before executing the task, to disable IT folding.
CPUID Base Register

The CPUID register contains the processor part number, version, and implementation
information.
CPUID
CPUID Base Register (E000 ED00H) Reset Value: 410F C241H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Implementer Variant Constant PartNo Revision
r r r r r

Revision [3:0] r Revision number
the y value in the rxpy product revision identifier
1H Patch 1
PartNo [15:4] r Part number of the processor
C24H Cortex-M4
Constant [19:16] r Reads as 0xF
Variant [23:20] r Variant number
the x value in the rxpy product revision identifier
0H Revision 0
Implementer [31:24] r Implementer code
41H ARM

XMC4500
XMC4000 Family
Interrupt Control and State Register

The ICSR:
provides:
a set-pending bit for the Non-Maskable Interrupt (NMI) exception
set-pending and clear-pending bits for the PendSV and SysTick exceptions
indicates:
the exception number of the exception being processed
whether there are preempted active exceptions
the exception number of the highest priority pending exception
whether any interrupts are pending.
ICSR
Interrupt Control and State Register
(E000 ED04H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
NMI
PEN PEN PEN PEN ISRP
PEN VECTPEN
0 DSV DSV DST DST 0 Res ENDI 0
DSE DING
SET CLR SET CLR NG
T
rw r rw w rw w r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RET
VECTPENDING TOB 0 VECTACTIVE
ASE
r r r r

1)
VECTACTIVE [8:0] r Active exception number
00H Thread mode
Nonzero = The exception number of the currently
active exception.
Note: Subtract 16 from this value to obtain the
CMSIS IRQ number required to index into the
Interrupt Clear-Enable, Set-Enable, Clear-
Pending, Set-Pending, or Priority Registers.

XMC4500
XMC4000 Family

RETTOBASE 11 r Return to Base
Indicates whether there are preempted active
exceptions:
0B there are preempted active exceptions to
execute
1B there are no active exceptions, or the
currently-executing exception is the only active
exception.
VECTPENDING [17:12] r Vector Pending
Indicates the exception number of the highest priority
pending enabled exception:
0H no pending exceptions
Nonzero = the exception number of the highest
priority pending enabled exception.
The value indicated by this field includes the effect of
the BASEPRI and FAULTMASK registers, but not
any effect of the PRIMASK register.
ISRPENDING 22 r Interrupt pending flag
excluding NMI and Faults:
0B interrupt not pending
1B interrupt pending.
Res 23 r Reserved
This bit is reserved for Debug use and reads-as-zero
when the processor is not in Debug.
PENDSTCLR 25 w SysTick exception clear-pending bit
Write:
0B no effect
1B removes the pending state from the SysTick
exception.
This bit is w. On a register read its value is Unknown.
PENDSTSET 26 rw SysTick exception set-pending bit
Write
0B no effect
1B changes SysTick exception state to pending.
Read:
0D SysTick exception is not pending
1D SysTick exception is pending.

XMC4500
XMC4000 Family

PENDSVCLR 27 w PendSV clear-pending bit
Write:
0B no effect
1B removes the pending state from the PendSV
exception.
PENDSVSET 28 rw PendSV set-pending bit
Write:
0B no effect
1B changes PendSV exception state to pending.
Read:
0B PendSV exception is not pending
1B PendSV exception is pending.
Writing 1 to this bit is the only way to set the PendSV
exception state to pending.
NMIPENDSET 31 rw NMI set-pending bit
Write:
0B no effect
1B changes NMI exception state to pending.
Read:
0B NMI exception is not pending
1B NMI exception is pending.
Because NMI is the highest-priority exception,
normally the processor enter the NMI exception
handler as soon as it registers a write of 1 to this bit,
and entering the handler clears this bit to 0. A read of
this bit by the NMI exception handler returns 1 only if
the NMI signal is reasserted while the processor is
executing that handler.
24, Read as 0; should be written with 0.
[21:18],
[10:9]
1) This is the same value as IPSR bits[8:0], see Interrupt Program Status Register on page 2-6.
When you write to the ICSR, the effect is Unpredictable if you:

Note: write 1 to the PENDSVSET bit and write 1 to the PENDSVCLR bit
write 1 to the PENDSTSET bit and write 1 to the PENDSTCLR bit.

XMC4500
XMC4000 Family
Vector Table Offset Register

The VTOR indicates the offset of the vector table base address from memory address
0x00000000.
VTOR
Vector Table Offset Register (E000 ED08H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TBLOFF 0
rw r

TBLOFF [31:10] rw Vector table base offset field
It contains bits[29:10] of the offset of the table base
from the bottom of the memory map.
Note: Bit[29] determines whether the vector table is
in the code or SRAM memory region:
0 = code
1 = SRAM
Bit[29] is sometimes called the TBLBASE bit.
0 [9:0] r Reserved
When setting TBLOFF, you must align the offset to the number of exception entries in
the vector table. The XMC4500 provides 112 interrupt nodes - minimum alignment is
therefore 256 words, enough for up to 128 interrupts.
Notes
1. XMC4500 implements 112 interrupts, the remaining nodes to 128 are not used.
2. Table alignment requirements mean that bits[9:0] of the table offset must always be
zero.
Application Interrupt and Reset Control Register

The AIRCR provides priority grouping control for the exception model, endian status for
data accesses, and reset control of the system.
To write to this register, you must write 0x5FA to the VECTKEY field, otherwise the
processor ignores the write.

XMC4500
XMC4000 Family
AIRCR
Application Interrupt and Reset Control Register
(E000 ED0CH) Reset Value: FA05 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
VECTKEY
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SYS VEC
ENDI VEC
RES TCL
ANN 0 PRIGROUP 0 TRE
ETR RAC
ESS SET
EQ TIVE
r r rw r w w w

VECTRESET 0 w Reserved for Debug use.
This bit reads as 0. When writing to the register
you must write 0 to this bit, otherwise behavior is
Unpredictable
VECTCLRACTIVE 1 w Reserved for Debug use.
This bit reads as 0. When writing to the register
you must write 0 to this bit, otherwise behavior is
Unpredictable.
SYSRESETREQ 2 w System reset request
0B no system reset request
1B asserts a signal to the outer system that
requests a reset.
This is intended to force a large system reset of all
major components except for debug.
This bit reads as 0.
PRIGROUP [10:8] rw Interrupt priority grouping field
This field determines the split of group priority
from subpriority, see Binary point on Page 2-65.
ENDIANNESS 15 r Data endianness bit
0B Little-endian
1B Big-endian.

XMC4500
XMC4000 Family

VECTKEY [31:16] rw Register key
Read:
= VECTKEY, reads as 0xFA05
Write:
= VECTKEYSTAT, On writes, write 0x5FA to
VECTKEY, otherwise the write is ignored.
Binary point
The PRIGROUP field indicates the position of the binary point that splits the PRI_n fields
in the Interrupt Priority Registers into separate group priority and subpriority fields.
Table 2-20 shows how the PRIGROUP value controls this split.
Table 2-20 Priority grouping

Interrupt priority level value, PRI_N[7:0] Number of
1)
PRIGROUP Binary point Group Subpriority Group Sub-
priority bits bits priorities priorities
0b001 bxxxxxx.00 [7:2] None 64 1
0b010 bxxxxx.y00 [7:3] [2] 32 2
0b011 bxxxx.yy00 [7:4] [3:2] 16 4
0b100 bxxx.yyy00 [7:5] [4:2] 8 8
0b101 bxx.yyyy00 [7:6] [5:2] 4 16
0b110 bx.yyyyy00 7 [6:2] 2 32
0b111 b.yyyyyy00 None [7:2] 1 64
1) PRI_n[7:0] field showing the binary point. x denotes a group priority field bit, and y denotes a subpriority field
bit.
Note: Determining preemption of an exception uses only the group priority field, see
Interrupt Priority Grouping on Page 2-31.

XMC4500
XMC4000 Family
System Control Register

The SCR controls features of entry to and exit from low power state.
SCR
System Control Register (E000 ED10H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SLE
SEV SLE
EPO
0 ONP 0 EPD 0
NEXI
END EEP
T
r rw r rw rw r

SLEEPONEXIT 1 rw Sleep on Exit
Indicates sleep-on-exit when returning from Handler
mode to Thread mode:
0B sleep
1B deep sleep
Setting this bit to 1 enables an interrupt driven
application to avoid returning to an empty main
application.
SLEEPDEEP 2 rw Sleep or Deep Sleep
Controls whether the processor uses sleep or deep
sleep as its low power mode:
0B sleep
1B deep sleep

XMC4500
XMC4000 Family

SEVONPEND 4 rw Send Event on Pending bit:
0B only enabled interrupts or events can wakeup
the processor, disabled interrupts are
excluded
1B enabled events and all interrupts, including
disabled interrupts, can wakeup the processor.
When an event or interrupt enters pending state, the
event signal wakes up the processor from WFE. If
the processor is not waiting for an event, the event is
registered and affects the next WFE.
The processor also wakes up on execution of an
SEV instruction or an external event.
3, 0 Read as 0; should be written with 0.
Configuration and Control Register

The CCR controls entry to Thread mode and enables:
the handlers for NMI, hard fault and faults escalated by FAULTMASK to ignore
BusFaults
trapping of divide by zero and unaligned accesses
access to the STIR by unprivileged software, see Software Trigger Interrupt
CCR
Configuration and Control Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
NON
UNA USE
STK BFH DIV_ BAS
LIGN RSE
0 ALIG FNMI 0 0_TR 0 ETH
_TR TMP
N GN P RDE
P END
NA
r rw rw r rw rw r rw rw

XMC4500
XMC4000 Family

NONBASETHR 0 rw Non Base Thread Mode Enable
DENA Indicates how the processor enters Thread mode:
0B processor can enter Thread mode only when
no exception is active.
1B processor can enter Thread mode from any
level under the control of an EXC_RETURN
value, see Exception return.
USERSETMPE 1 rw User Set Pending Enable
ND Enables unprivileged software access to the STIR,
see Software Trigger Interrupt Register.
0B disable
1B enable
UNALIGN_TRP 3 rw Unaligned Access Trap Enable
Enables unaligned access traps:
0B do not trap unaligned halfword and word
accesses
1B trap unaligned halfword and word accesses.
If this bit is set to 1, an unaligned access generates
a UsageFault.
Unaligned LDM, STM, LDRD, and STRD instructions
always fault irrespective of whether UNALIGN_TRP
is set to 1.
DIV_0_TRP 4 rw Divide by Zero Trap Enable
Enables faulting or halting when the processor
executes an SDIV or UDIV instruction with a divisor
of 0:
0B do not trap divide by 0
1B trap divide by 0.
When this bit is set to 0,a divide by zero returns a
quotient of 0.

XMC4500
XMC4000 Family

BFHFNMIGN 8 rw Bus Fault Hard Fault and NMI Ignore
Enables handlers with priority -1 or -2 to ignore data
BusFaults caused by load and store instructions.
This applies to the hard fault, NMI, and FAULTMASK
escalated handlers:
0B data bus faults caused by load and store
instructions cause a lock-up
1B handlers running at priority -1 and -2 ignore
data bus faults caused by load and store
instructions.
Set this bit to 1 only when the handler and its data
are in absolutely safe memory. The normal use of
this bit is to probe system devices and bridges to
detect control path problems and fix them.
STKALIGN 9 rw Stack Alignment
Indicates stack alignment on exception entry:
0B 4-byte aligned
1B 8-byte aligned.
On exception entry, the processor uses bit[9] of the
stacked PSR to indicate the stack alignment. On
return from the exception it uses this stacked bit to
restore the correct stack alignment.
[7:5], 2 Read as 0; should be written with 0.
System Handler Priority Registers

The SHPR1-SHPR3 registers set the priority level, 0 to 63 of the exception handlers that
have configurable priority.
SHPR1-SHPR3 are byte accessible.
The system fault handlers and the priority field and register for each handler are:
Table 2-21 System fault handler priority fields

Handler Field Register description
MemManage PRI_4 System Handler Priority Register 1 on Page 2-70
BusFault PRI_5
UsageFault PRI_6
SVCall PRI_11 System Handler Priority Register 2 on Page 2-70

XMC4500
XMC4000 Family
Table 2-21 System fault handler priority fields (contd)

Handler Field Register description
PendSV PRI_14 System Handler Priority Register 3 on Page 2-71
SysTick PRI_15
Each PRI_N field is 8 bits wide, but the XMC4500 implements only bits[7:2] of each field,
and bits[1:0] read as zero and ignore writes.
System Handler Priority Register 1
SHPR1
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 PRI_6 PRI_5 PRI_4
r rw rw rw

PRI_4 [7:0] rw Priority of system handler 4, MemManage
PRI_5 [15:8] rw Priority of system handler 5, BusFault
PRI_6 [23:16] rw Priority of system handler 6, UsageFault
0 [31:24] r Reserved
SHPR2
(E000 ED1CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRI_11 0
rw r

XMC4500
XMC4000 Family

PRI_11 [31:24] rw Priority of system handler 11, SVCall
0 [23:0] r Reserved
SHPR3
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRI_15 PRI_14 0
rw rw r

PRI_14 [23:16] rw Priority of system handler 14
PendSV
PRI_15 [31:24] rw Priority of system handler 15
SysTick exception
0 [15:0] r Reserved
System Handler Control and State Register

The SHCSR enables the system handlers, and indicates:
the pending status of the BusFault, MemManage fault, and SVC exceptions
the active status of the system handlers.

XMC4500
XMC4000 Family
SHCSR
System Handler Control and State Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
USG BUS MEM
FAU FAU FAU
0
LTE LTE LTE
NA NA NA
r rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BUS MEM USG
SVC USG BUS MEM
FAU FAU FAU SYS PEN MON SVC
ALL FAU FAU FAU
LTP LTP LTP TICK DSV 0 ITOR ALL 0 0
PEN LTA LTA LTA
END END END ACT ACT ACT ACT
DED CT CT CT
ED ED ED
rw rw rw rw rw rw r rw rw r rw r rw rw

MEMFAULTACT 0 rw MemManage exception active bit
Reads as 1 if exception is active.
BUSFAULTACT 1 rw BusFault exception active bit
USGFAULTACT 3 rw UsageFault exception active bit
SVCALLACT 7 rw SVCall active bit
Reads as 1 if SVC call is active.
MONITORACT 8 rw Debug monitor active bit
Reads as 1 if Debug monitor is active.
PENDSVACT 10 rw PendSV exception active bit
SYSTICKACT 11 rw SysTick exception active bit
USGFAULTPENDED 12 rw UsageFault exception pending bit
Reads as 1 if exception is pending.
MEMFAULTPENDED 13 rw MemManage exception pending bit

XMC4500
XMC4000 Family

BUSFAULTPENDED 14 rw BusFault exception pending bit
SVCALLPENDED 15 rw SVCall pending bit
MEMFAULTENA 16 rw MemManage enable bit
Set to 1 to enable.
BUSFAULTENA 17 rw BusFault enable bit
Set to 1 to enable.
USGFAULTENA 18 rw UsageFault enable bit
Set to 1 to enable.
9, [6:4], Read as 0; should be written with 0.
2
Notes
1. Active bits, read as 1 if the exception is active, or as 0 if it is not active. You can write
to these bits to change the active status of the exceptions, but see the Caution in this
section.
2. Pending bits, read as 1 if the exception is pending, or as 0 if it is not pending. You
can write to these bits to change the pending status of the exceptions.
3. Enable bits, set to 1 to enable the exception, or set to 0 to disable the exception.
If you disable a system handler and the corresponding fault occurs, the processor treats
the fault as a hard fault.
You can write to this register to change the pending or active status of system
exceptions. An OS kernel can write to the active bits to perform a context switch that
changes the current exception type.
Note: Software that changes the value of an active bit in this register without correct
adjustment to the stacked content can cause the processor to generate a fault
exception. Ensure software that writes to this register retains and subsequently
restores the current active status.
Note: After you have enabled the system handlers, if you have to change the value of a
bit in this register you must use a read-modify-write procedure to ensure that you
change only the required bit.
Configurable Fault Status Register

The CFSR indicates the cause of a MemManage fault, BusFault, or UsageFault.
The flags in the MMFSR indicate the cause of memory access faults.

XMC4500
XMC4000 Family
The flags in the BFSR indicate the cause of a bus access fault.
The UFSR indicates the cause of a UsageFault.
31 16 15 8 7 0
Bus Fault Status Memory Management
Usage Fault Status Register
Register Fault Status Register
UFSR BFSR MMFSR
Figure 2-9 CFSR

The CFSR is byte accessible. You can access the CFSR or its subregisters as follows:
access the complete CFSR with a word access to 0xE000ED28
access the MMFSR with a byte access to 0xE000ED28
access the MMFSR with a byte access to 0xE000ED28
access the MMFSR and BFSR with a halfword access to 0xE000ED28
access the BFSR with a byte access to 0xE000ED29
access the UFSR with a halfword access to 0xE000ED2A
Note: The UFSR bits are sticky. This means as one or more fault occurs, the associated
bits are set to 1. A bit that is set to 1 is cleared to 0 only by writing 1 to that bit, or
by a reset.
CFSR
Configurable Fault Status Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DIVB UNA INVS UND
NOC INVP
0 YZE LIGN 0 TAT EFIN
P C
RO ED E STR
r rw rw r rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
IMP
BFA UNS PRE MMA MLS MST MUN DAC
LSP STK RECI IBUS IACC
RVA 0 TKE CISE RVA 0 PER KER STK 0 CVIO
ERR ERR SER ERR VIOL
LID RR RR LID R R ERR L
R
rw r rw rw rw rw rw rw rw r rw rw rw r rw rw

XMC4500
XMC4000 Family

IACCVIOL 0 rw Instruction access violation flag
0B no instruction access violation fault
1B the processor attempted an instruction fetch
from a location that does not permit execution.
This fault occurs on any access to an XN region,
even when the MPU is disabled or not present.
When this bit is 1, the PC value stacked for the
exception return points to the faulting instruction.
The processor has not written a fault address to the
MMAR.
DACCVIOL 1 rw Data access violation flag
0B no data access violation fault
1B the processor attempted a load or store at a
location that does not permit the operation.
When this bit is 1, the PC value stacked for the
exception return points to the faulting instruction.
The processor has loaded the MMAR with the
address of the attempted access.
MUNSTKERR 3 rw MemManage fault on unstacking for a return
from exception
0B no unstacking fault
1B unstack for an exception return has caused
one or more access violations.
This fault is chained to the handler. This means that
when this bit is 1, the original return stack is still
present. The processor has not adjusted the SP from
the failing return, and has not performed a new save.
The processor has not written a fault address to the
MMAR.
MSTKERR 4 rw MemManage fault on stacking for exception
entry
0B no stacking fault
1B stacking for an exception entry has caused
one or more access violations.
When this bit is 1, the SP is still adjusted but the
values in the context area on the stack might be
incorrect. The processor has not written a fault
address to the MMAR.

XMC4500
XMC4000 Family

MLSPERR 5 rw MemManage fault during floating point lazy state
preservation
0B No MemManage fault occurred during floating-
point lazy state preservation
1B A MemManage fault occurred during floating-
point lazy state preservation
MMARVALID 7 rw MemManage Fault Address Register (MMFAR)
valid flag
0B value in MMAR is not a valid fault address
1B MMAR holds a valid fault address.
If a MemManage fault occurs and is escalated to a
HardFault because of priority, the HardFault handler
must set this bit to 0. This prevents problems on
return to a stacked active MemManage fault handler
whose MMAR value has been overwritten.
IBUSERR 8 rw Instruction bus error
0B no instruction bus error
1B instruction bus error.
The processor detects the instruction bus error on
prefetching an instruction, but it sets the IBUSERR
flag to 1 only if it attempts to issue the faulting
instruction.
When the processor sets this bit is 1, it does not write
a fault address to the BFAR.
PRECISERR 9 rw Precise data bus error
0B no precise data bus error
1B a data bus error has occurred, and the PC
value stacked for the exception return points to
the instruction that caused the fault.
When the processor sets this bit is 1, it writes the
faulting address to the BFAR.

XMC4500
XMC4000 Family

IMPRECISERR 10 rw Imprecise data bus error
0B no imprecise data bus error
1B a data bus error has occurred, but the return
address in the stack frame is not related to the
instruction that caused the error.
When the processor sets this bit to 1, it does not write
a fault address to the BFAR.
This is an asynchronous fault. Therefore, if it is
detected when the priority of the current process is
higher than the BusFault priority, the BusFault
becomes pending and becomes active only when
the processor returns from all higher priority
processes. If a precise fault occurs before the
processor enters the handler for the imprecise
BusFault, the handler detects both IMPRECISERR
set to 1 and one of the precise fault status bits set to
1.
UNSTKERR 11 rw BusFault on unstacking for a return from
exception
0B no unstacking fault
one or more BusFaults.
This fault is chained to the handler. This means that
when the processor sets this bit to 1, the original
return stack is still present. The processor does not
adjust the SP from the failing return, does not
performed a new save, and does not write a fault
address to the BFAR.
STKERR 12 rw BusFault on stacking for exception entry
0B no stacking fault
one or more BusFaults.
When the processor sets this bit to 1, the SP is still
adjusted but the values in the context area on the
stack might be incorrect. The processor does not
write a fault address to the BFAR.

XMC4500
XMC4000 Family

LSPERR 13 rw BusFault during floating point lazy state
preservation
0B No bus fault occurred during floating-point lazy
state preservation.
1B A bus fault occurred during floating-point lazy
state preservation
BFARVALID 15 rw BusFault Address Register (BFAR) valid flag
0B value in BFAR is not a valid fault address
1B BFAR holds a valid fault address.
The processor sets this bit to 1 after a BusFault
where the address is known. Other faults can set this
bit to 0, such as a MemManage fault occurring later.
If a BusFault occurs and is escalated to a hard fault
because of priority, the hard fault handler must set
this bit to 0. This prevents problems if returning to a
stacked active BusFault handler whose BFAR value
has been overwritten.
UNDEFINSTR 16 rw Undefined instruction UsageFault
0B no undefined instruction UsageFault
1B the processor has attempted to execute an
undefined instruction.
When this bit is set to 1, the PC value stacked for the
exception return points to the undefined instruction.
An undefined instruction is an instruction that the
processor cannot decode.
INVSTATE 17 rw Invalid state UsageFault
0B no invalid state UsageFault
1B the processor has attempted to execute an
instruction that makes illegal use of the EPSR.
exception return points to the instruction that
attempted the illegal use of the EPSR.
This bit is not set to 1 if an undefined instruction uses
the EPSR.

XMC4500
XMC4000 Family

INVPC 18 rw Invalid PC load UsageFault
caused by an invalid PC load by EXC_RETURN:
0B no invalid PC load UsageFault
1B the processor has attempted an illegal load of
EXC_RETURN to the PC, as a result of an
invalid context, or an invalid EXC_RETURN
value.
exception return points to the instruction that tried to
perform the illegal load of the PC.
NOCP 19 rw No coprocessor UsageFault
0B no UsageFault caused by attempting to
access a coprocessor
1B the processor has attempted to access a
coprocessor.
UNALIGNED 24 rw Unaligned access UsageFault
0B no unaligned access fault, or unaligned access
trapping not enabled
1B the processor has made an unaligned memory
access.
Enable trapping of unaligned accesses by setting the
UNALIGN_TRP bit in the CCR to 1, see
Configuration and Control Register on Page 2-67.
Unaligned LDM, STM, LDRD, and STRD instructions
always fault irrespective of the setting of
UNALIGN_TRP.
DIVBYZERO 25 rw Divide by zero UsageFault
0B no divide by zero fault, or divide by zero
trapping not enabled
1B the processor has executed an SDIV or UDIV
instruction with a divisor of 0
When the processor sets this bit to 1, the PC value
stacked for the exception return points to the
instruction that performed the divide by zero.
Enable trapping of divide by zero by setting the
DIV_0_TRP bit in the CCR to 1, see Configuration
and Control Register on Page 2-67.
14, 6, 2

XMC4500
XMC4000 Family
HardFault Status Register

The HFSR gives information about events that activate the HardFault handler.
This register is read, write to clear. This means that bits in the register read normally, but
writing 1 to any bit clears that bit to 0. The bit assignments are:
HFSR
HardFault Status Register (E000 ED2CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DEB
FOR
UGE 0
CED
VT
rw rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VEC
0 TTB 0
L
r rw r

VECTTBL 1 rw BusFault on vector table read
Indicates a BusFault on a vector table read during
exception processing:
0B no BusFault on vector table read
1B BusFault on vector table read
This error is always handled by the hard fault
handler.
exception return points to the instruction that was
preempted by the exception.
FORCED 30 rw Forced HardFault
Indicates a forced hard fault, generated by
escalation of a fault with configurable priority that
cannot be handles, either because of priority or
because it is disabled:
0B no forced HardFault
1B forced HardFault.
When this bit is set to 1, the HardFault handler must
read the other fault status registers to find the cause
of the fault.

XMC4500
XMC4000 Family

DEBUGEVT 31 rw Reserved for Debug use
When writing to the register you must write 0 to this
bit, otherwise behavior is Unpredictable
0 Read as 0; should be written with 0.
Note: The HFSR bits are sticky. This means as one or more fault occurs, the associated
bits are set to 1. A bit that is set to 1 is cleared to 0 only by writing 1 to that bit, or
by a reset.

The MMFAR contains the address of the location that generated a MemManage fault.
MMFAR
(E000 ED34H) Reset Value: XXXX XXXXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADDRESS
rw

ADDRESS [31:0] rw Address causing the fault
When the MMARVALID bit of the MMFSR is set to 1,
this field holds the address of the location that
generated the MemManage fault
When an unaligned access faults, the address is the actual address that faulted.
Because a single read or write instruction can be split into multiple aligned accesses, the
fault address can be any address in the range of the requested access size.
Flags in the MMFSR indicate the cause of the fault, and whether the value in the MMFAR
is valid. See MemManage Fault Status Register on Page 2-73.

XMC4500
XMC4000 Family
BusFault Address Register

The BFAR contains the address of the location that generated a BusFault.
BFAR
BusFault Address Register (E000 ED38H) Reset Value: XXXX XXXXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADDRESS
rw

ADDRESS [31:0] rw Address causing the fault
When the BFARVALID bit of the BFSR is set to 1,
this field holds the address of the location that
generated the BusFault
When an unaligned access faults the address in the BFAR is the one requested by the
instruction, even if it is not the address of the fault.
Flags in the BFSR indicate the cause of the fault, and whether the value in the BFAR is
valid. See BusFault Status Register on Page 2-73.
Auxiliary Fault Status Register

The AFSR contains additional system fault information.
This register is read, write to clear. This means that bits in the register read normally, but
writing 1 to any bit clears that bit to 0.
AFSR
Auxiliary Fault Status Register (E000 ED3CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
rw

0 [31:0] rw Reserved

XMC4500
XMC4000 Family
Each AFSR bit maps directly to an AUXFAULT input of the processor, and a single-cycle
HIGH signal on the input sets the corresponding AFSR bit to one. It remains set to 1 until
you write 1 to the bit to clear it to zero.
When an AFSR bit is latched as one, an exception does not occur. Use an interrupt if an
exception is required.
2.9.2 SysTick Registers
SysTick Control and Status Register

The SysTick SYST_CSR register enables the SysTick features.
SYST_CSR
SysTick Control and Status Register
(E000 E010H) Reset Value: 0000 0004H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
COU
0 NTF
LAG
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CLK
TICK ENA
0 SOU
INT BLE
RCE
r rw rw rw

ENABLE 0 rw Enable
Enables the counter:
0B counter disabled
1B counter enabled.
TICKINT 1 rw Tick Interrupt Enable
Enables SysTick exception request:
0B counting down to zero does not assert the
SysTick exception request
1B counting down to zero to asserts the SysTick
exception request.
Software can use COUNTFLAG to determine if
SysTick has ever counted to zero.

XMC4500
XMC4000 Family

CLKSOURCE 2 rw Clock source
0B fSTDBY / 2
1B fCPU
COUNTFLAG 16 rw Counter Flag
Returns 1 if timer counted to 0 since last time this
was read.
When ENABLE is set to 1, the counter loads the RELOAD value from the SYST_RVR
register and then counts down. On reaching 0, it sets the COUNTFLAG to 1 and
optionally asserts the SysTick depending on the value of TICKINT. It then loads the
RELOAD value again, and begins counting.
SysTick Reload Value Register

The SYST_RVR register specifies the start value to load into the SYST_CVR register.
SYST_RVR
SysTick Reload Value Register (E000 E014H) Reset Value: XXXX XXXXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 RELOAD
r rw

RELOAD [23:0] rw Reload Value
Value to load into the SYST_CVR register when the
counter is enabled and when it reaches 0, see
Calculating the RELOAD value.
Notes on calculating the RELOAD value

1. The RELOAD value can be any value in the range 0x00000001-0x00FFFFFF. A start
value of 0 is possible, but has no effect because the SysTick exception request and
COUNTFLAG are activated when counting from 1 to 0.

XMC4500
XMC4000 Family
2. The RELOAD value is calculated according to its use. For example, to generate a
multi-shot timer with a period of N processor clock cycles, use a RELOAD value of
N-1. If the SysTick interrupt is required every 100 clock pulses, set RELOAD to 99.
SysTick Current Value Register

The SYST_CVR register contains the current value of the SysTick counter.
SYST_CVR
SysTick Current Value Register (E000 E018H) Reset Value: XXXX XXXXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 CURRENT
r rw

CURRENT [23:0] rw Current Value
Reads return the current value of the SysTick
counter.
A write of any value clears the field to 0, and also
clears the SYST_CSR COUNTFLAG bit to 0.
SysTick Calibration Value Register

The SYST_CALIB register indicates the SysTick calibration properties.
SYST_CALIB
SysTick Calibration Value Register
r (E000 E01CH) Reset Value: C000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
N
S
O
K
R 0 TENMS
E
E
W
F
rw rw r rw

XMC4500
XMC4000 Family

TENMS [23:0] rw Ten Milliseconds Reload Value
Reload value for 10ms (100Hz) timing, subject to
system clock skew errors. If the value reads as zero,
the calibration value is not known.
SKEW 30 rw Ten Milliseconds Skewed
Indicates whether the TENMS value is exact:
0B TENMS value is exact
1B TENMS value is inexact, or not given.
An inexact TENMS value can affect the suitability of
SysTick as a software real time clock.
NOREF 31 rw No Reference Clock
Indicates whether the device provides a reference
clock to the processor:
0B reference clock provided
1B no reference clock provided.
If your device does not provide a reference clock, the
SYST_CSR.CLKSOURCE bit reads-as-one and
ignores writes.
2.9.3 NVIC Registers
Interrupt Set-enable Registers

The NVIC_ISERx (x=0-3) registers enable interrupts, and show which interrupts are
enabled.
NVIC_ISERx (x=0-3)
Interrupt Set-enable Register x
(E000 E100H + 4*x) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SETENA
rw

XMC4500
XMC4000 Family

SETENA [31:0] rw Interrupt set-enable bits
Write:
0B no effect
1B enable interrupt.
Read:
0B interrupt disabled
1B interrupt enabled.
If a pending interrupt is enabled, the NVIC activates the interrupt based on its priority. If
an interrupt is not enabled, asserting its interrupt signal changes the interrupt state to
pending, but the NVIC never activates the interrupt, regardless of its priority.
Interrupt Clear-enable Registers

The NVIC_ICERx (x=0-7) registers disable interrupts, and show which interrupts are
enabled.
NVIC_ISCERx (x=0-3)
Interrupt Clear-enable Register x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CLRENA
rw

CLRENA [31:0] rw Interrupt clear-enable bits.
Write:
0B no effect
1B enable interrupt.
Read:
0B interrupt disabled
1B interrupt enabled.

XMC4500
XMC4000 Family
Interrupt Set-pending Registers

The NVIC_ISPRx (x=0-7) registers force interrupts into the pending state, and show
which interrupts are pending.
NVIC_ISSPRx (x=0-3)
Interrupt Set-pending Register x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SETPEND
rw

SETPEND [31:0] rw Interrupt set-pending bits.
Write:
0B no effect
1B changes interrupt state to pending.
Read:
0B interrupt is not pending
1B interrupt is pending.
Writing 1 to the ISPR bit corresponding to:

- an interrupt that is pending has no effect
- a disabled interrupt sets the state of that interrupt to pending
Interrupt Clear-pending Registers

The NVIC_ICPRx (x=0-7) registers remove the pending state from interrupts, and show
which interrupts are pending.
NVIC_ICPRx (x=0-3)
Interrupt Clear-pending Register x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CLRPEND
rw

XMC4500
XMC4000 Family

CLRPEND [31:0] rw Interrupt set-pending bits.
Write:
0B no effect
1B removes pending state an interrupt.
Read:
0B interrupt is not pending
1B interrupt is pending.
Note: Writing 1 to an ICPR bit does not affect the active state of the corresponding
interrupt.
Interrupt Active Bit Registers

The NVIC_IABRx (x=0-7) registers indicate which interrupts are active.
NVIC_IABRx (x=0-3)
Interrupt Active Bit Register x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ACTIVE
rw

ACTIVE [31:0] rw Interrupt active flags:
0B interrupt not active
1B interrupt active
A bit reads as one if the status of the corresponding interrupt is active or active and
pending.
Interrupt Priority Registers

The NVIC_IPRx (x=0-27) registers provide an 8-bit priority field for each interrupt. These
registers are byte-accessible. Each register holds four priority fields as shown:

XMC4500
XMC4000 Family
31 24 23 16 15 8 7 0
IPR27 PRI_111 PRI_110 PRI_109 PRI_108

...
...
IPRn PRI_4n+3 PRI_4n+2 PRI_4n+1 PRI_4n
...
...
IPR0 PRI_3 PRI_2 PRI_1 PRI_0
Figure 2-10 Interrupt Priority Register
NVIC_IPRx (x=0-27)
Interrupt Priority Register x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRI_3 PRI_2 PRI_1 PRI_0
rw rw rw rw

PRI_0 [7:0] rw Priority value 0
The lower the value, the greater the priority of the
corresponding interrupt. The processor implements
only bits[7:n] of each field, bits[n-1:0] read as zero
and ignore writes.
See Using CMSIS functions to access NVIC on Page 2-45 for more information about
the access to the interrupt priority array, which provides the software view of the interrupt
priorities.
Find the IPR number and byte offset for interrupt m as follows:

XMC4500
XMC4000 Family
the corresponding IPR number n, see Figure 2-10 on Page 2-907, is given by
n = m DIV 4
the byte offset of the required Priority field in this register is m MOD 4, where:
byte offset 0 refers to register bits[7:0]
byte offset 3 refers to register bits[31:24].
Software Trigger Interrupt Register

Write to the STIR to generate an interrupt from software.
When the USERSETMPEND bit in the SCR is set to 1, unprivileged software can access
the STIR, see System Control Register on Page 2-66.
Note: Only privileged software can enable unprivileged access to the STIR.
STIR
Software Trigger Interrupt Register
(E000 EF00H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 INTID
r w

INTID [8:0] w Interrupt ID of the interrupt to trigger
in the range 0-111. For example, a value of 0x03
specifies interrupt IRQ3.
0 [31:9] r Reserved

XMC4500
XMC4000 Family
2.9.4 MPU Registers
MPU Type Register

The MPU_TYPE register indicates whether the MPU is present, and if so, how many
regions it supports.
MPU_TYPE
MPU Type Register (E000 ED90H) Reset Value: 0000 0800H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 IREGION
r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SEP
DREGION 0 ARA
TE
r r r

SEPARATE 0 r Support for unified or separate instruction and
date memory maps
0B unified
DREGION [15:8] r Number of supported MPU data regions
08H Eight MPU regions
IREGION [23:16] r Number of supported MPU instruction regions
Always contains 0x00. The MPU memory map is
unified and is described by the DREGION field.
MPU Control Register

The MPU_CTRL register:
enables the MPU
enables the default memory map background region
enables use of the MPU when in the hard fault, Non-maskable Interrupt (NMI), and
FAULTMASK escalated handlers.

XMC4500
XMC4000 Family
MPU_CTRL
MPU Control Register (E000 ED94H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRIV HFN
ENA
0 DEF MIE
BLE
ENA NA
r rw rw rw

ENABLE 0 rw Enable MPU
0B MPU disabled
1B MPU enabled.
HFNMIENA 1 rw Enable the operation of MPU during hard fault,
NMI, and FAULTMASK handlers
When the MPU is enabled:
0B MPU is disabled during hard fault, NMI, and
FAULTMASK handlers, regardless of the
value of the ENABLE bit
1B the MPU is enabled during hard fault, NMI, and
FAULTMASK handlers.
When the MPU is disabled, if this bit is set to 1 the
behavior is Unpredictable.

XMC4500
XMC4000 Family

PRIVDEFENA 2 rw Enables privileged software access to the default
memory map
0B If the MPU is enabled, disables use of the
default memory map. Any memory access to a
location not covered by any enabled region
causes a fault.
1B If the MPU is enabled, enables use of the
default memory map as a background region
for privileged software accesses.
When enabled, the background region acts as if it is
region number -1. Any region that is defined and
enabled has priority over this default map.
f the MPU is disabled, the processor ignores this bit.
0 [31:3] r Reserved
When ENABLE and PRIVDEFENA are both set to 1:

For privileged accesses, the default memory map is as described in Memory model
on Page 2-20. Any access by privileged software that does not address an enabled
memory region behaves as defined by the default memory map.
Any access by unprivileged software that does not address an enabled memory
region causes a MemManage fault.
XN and Strongly-ordered rules always apply to the System Control Space regardless of
the value of the ENABLE bit.
When the ENABLE bit is set to 1, at least one region of the memory map must be
enabled for the system to function unless the PRIVDEFENA bit is set to 1. If the
PRIVDEFENA bit is set to 1 and no regions are enabled, then only privileged software
can operate.
When the ENABLE bit is set to 0, the system uses the default memory map. This has the
same memory attributes as if the MPU is not implemented, see Table 2-6 on Page 2-22.
The default memory map applies to accesses from both privileged and unprivileged
software.
When the MPU is enabled, accesses to the System Control Space and vector table are
always permitted. Other areas are accessible based on regions and whether
PRIVDEFENA is set to 1.
Unless HFNMIENA is set to 1, the MPU is not enabled when the processor is executing
the handler for an exception with priority 1 or 2. These priorities are only possible when
handling a hard fault or NMI exception, or when FAULTMASK is enabled. Setting the
HFNMIENA bit to 1 enables the MPU when operating with these two priorities.

XMC4500
XMC4000 Family
MPU Region Number Register

The MPU_RNR selects which memory region is referenced by the MPU_RBAR and
MPU_RASR registers.
MPU_RNR
MPU Region Number Register (E000 ED98H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 REGION
r rw

REGION [7:0] rw Region
Indicates the MPU region referenced by the
MPU_RBAR and MPU_RASR registers.
The MPU supports 8 memory regions, so the
permitted values of this field are 0-7.
0 [31:8] r Reserved
Normally, you write the required region number to this register before accessing the
MPU_RBAR or MPU_RASR. However you can change the region number by writing to
the MPU RBAR with the VALID bit set to 1, see MPU Region Base Address Register.
This write updates the value of the REGION field.
MPU Region Base Address Register

The MPU_RBAR defines the base address of the MPU region selected by the
MPU_RNR, and can update the value of the MPU_RNR.

XMC4500
XMC4000 Family
MPU_RBAR
MPU Region Base Address Register
(E000 ED9CH) Reset Value: 0000 0000H
MPU_RBAR_A1
MPU Region Base Address Register A1
(E000 EDA4H) Reset Value: 0000 0000H
MPU_RBAR_A2
(E000 EDACH) Reset Value: 0000 0000H
MPU_RBAR_A3
(E000 EDB4H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ADDR
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VALI
ADDR 0 REGION
D
rw r rw rw

REGION [3:0] rw MPU region field
For the behavior on writes, see the description of
the VALID field.
On reads, returns the current region number, as
specified by the RNR.

XMC4500
XMC4000 Family

VALID 4 rw MPU Region Number valid bit
Write:
0B MPU_RNR not changed, and the processor:
- updates the base address for the region
specified in the MPU_RNR
- ignores the value of the REGION field
1B the processor:
- updates the value of the MPU_RNR to the
value of the REGION field
- updates the base address for the region
specified in the REGION field.
Always reads as zero.
ADDR [31:9] rw Region base address field
The value of N (N = 9 for bit definition) depends on
the region size. For more information see The
ADDR field.
0 [8:5] r Reserved
The ADDR field

The ADDR field is bits[31:N] of the MPU_RBAR. The region size, as specified by the
SIZE field in the MPU_RASR, defines the value of N:
N = Log2(Region size in bytes),
If the region size is configured to 4GB, in the MPU_RASR, there is no valid ADDR field.
In this case, the region occupies the complete memory map, and the base address is
0x00000000.
The base address is aligned to the size of the region. For example, a 64KB region must
be aligned on a multiple of 64KB, for example, at 0x00010000 or 0x00020000.
MPU Region Attribute and Size Register

The MPU_RASR defines the region size and memory attributes of the MPU region
specified by the MPU_RNR, and enables that region and any subregions.
MPU_RASR is accessible using word or halfword accesses:
the most significant halfword holds the region attributes
the least significant halfword holds the region size and the region and subregion
enable bits.

XMC4500
XMC4000 Family
MPU_RASR
MPU Region Attribute and Size Register
MPU_RASR_A1
MPU Region Attribute and Size Register A1
MPU_RASR_A2
MPU_RASR_A3
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 XN 0 AP 0 TEX S C B
r rw r rw r rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ENA
SRD 0 SIZE
BLE
rw r rw rw

ENABLE 0 rw Region enable bit.
SIZE [5:1] rw MPU protection region size
The minimum permitted value is 3 (0b00010), see
See SIZE field values for more information.
SRD [15:8] rw Subregion disable bits
For each bit in this field:
0B corresponding sub-region is enabled
1B corresponding sub-region is disabled
See Subregionson Page 2-52 for more information.
Region sizes of 128 bytes and less do not support
subregions. When writing the attributes for such a
region, write the SRD field as 0x00.
B 16 rw Memory access attribute
see Table 2-15 onPage 2-48.

XMC4500
XMC4000 Family

C 17 rw Memory access attribute
S 18 rw Shareable bit
TEX [21:19] rw Memory access attribute
AP [26:24] rw Access permission field
see Table 2-18 on Page 2-49.
XN 28 rw Instruction access disable bit
0B instruction fetches enabled
1B instruction fetches disabled.
0 [31:29, r Reserved
[23:22],
[7:6]
For information about access permission, see MPU Access Permission Attributes on
Page 2-48.
SIZE field values

The SIZE field defines the size of the MPU memory region specified by the RNR. as
follows:
(Region size in bytes) = 2(SIZE+1)
The smallest permitted region size is 32B, corresponding to a SIZE value of 4.
Table 2-22 gives example SIZE values, with the corresponding region size and value of
N in the MPU_RBAR.
Table 2-22 Example SIZE field values

SIZE value Region size Value of N1) Note
0b00100 (4) 32B 5 Minimum permitted size
0b01001 (9) 1KB 10 -
0b10011 (19) 1MB 20 -
0b11101 (29) 1GB 30 -
0b11111 (31) 4GB 32 Maximum possible size
1) In the MPU_RBAR, see MPU Region Base Address Register on Page 2-95.

XMC4500
XMC4000 Family
2.9.5 FPU Registers
Coprocessor Access Control Register

The CPACR register specifies the access privileges for coprocessors.
CPACR
Coprocessor Access Control Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 CP11 CP10 0
r rw rw r

CP10 [21:20] rw Access privileges for coprocessor 10
The possible values of each field are:
00B Access denied. Any attempted access
generates a NOCP UsageFault.
01B Privileged access only. An unprivileged
access generates a NOCP fault.
10B Reserved. The result of any access is
Unpredictable.
11B Full access.
CP11 [23:22] rw Access privileges for coprocessor 11
The possible values of each field are:
00B Access denied. Any attempted access
generates a NOCP UsageFault.
01B Privileged access only. An unprivileged
access generates a NOCP fault.
10B Reserved. The result of any access is
Unpredictable.
11B Full access.

XMC4500
XMC4000 Family
Floating-point Context Control Register

The FPCCR register sets or returns FPU control data.
FPCCR
Floating-point Context Control Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ASP LSP
0
EN EN
rw rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MON BFR MMR HFR THR USE LSP
0 0 0
RDY DY DY DY EAD R ACT
r rw r rw rw rw rw r rw rw

LSPACT 0 rw Lazy State Preservation Active
0B Lazy state preservation is not active.
1B Lazy state preservation is active. floating-point
stack frame has been allocated but saving
state to it has been deferred.
USER 1 rw User allocated Stack Frame
0B Privilege level was not user when the floating-
point stack frame was allocated.
1B Privilege level was user when the floating-
THREAD 3 rw Thread Mode allocated Stack Frame
0B Mode was not Thread Mode when the floating-
1B Mode was Thread Mode when the floating-
HFRDY 4 rw HardFault Ready
0B Priority did not permit setting the HardFault
handler to the pending state when the floating-
1B Priority permitted setting the HardFault
handler to the pending state when the floating-

XMC4500
XMC4000 Family

MMRDY 5 rw MemManage Ready
0B MemManage is disabled or priority did not
permit setting the MemManage handler to the
pending state when the floating-point stack
frame was allocated.
1B MemManage is enabled and priority permitted
setting the MemManage handler to the
pending state when the floating-point stack
frame was allocated.
BFRDY 6 rw BusFault Ready
0B BusFault is disabled or priority did not permit
setting the BusFault handler to the pending
state when the floating-point stack frame was
allocated.
1B BusFault is enabled and priority permitted
setting the BusFault handler to the pending
state when the floating-point stack frame was
allocated.
MONRDY 8 rw Monitor Ready
0B Debug Monitor is disabled or priority did not
permit setting MON_PEND when the floating-
1B Debug Monitor is enabled and priority permits
setting MON_PEND when the floating-point
stack frame was allocated.
LSPEN 30 rw Lazy State Preservation Enabled
0B Disable automatic lazy state preservation for
floating-point context.
1B Enable automatic lazy state preservation for
floating-point context.
ASPEN 31 rw Automatic State Preservation
Enables CONTROL setting on execution of a
floating-point instruction. This results in automatic
hardware state preservation and restoration, for
floating-point context, on exception entry and exit.
0B Disable CONTROL setting on execution of a
floating-point instruction.
1B Enable CONTROL setting on execution of a
floating-point instruction.

XMC4500
XMC4000 Family

7, 2 Read as 0; should be written with 0.
Floating-point Context Address Register

The FPCAR register holds the location of the unpopulated floating-point register space
allocated on an exception stack frame.
FPCAR
Floating-point Context Address Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADDRESS 0
rw r

ADDRESS [31:3] rw Address
The location of the unpopulated floating-point
register space allocated on an exception stack
frame.
0 [2:0] r Reserved

XMC4500
XMC4000 Family
Floating-point Status Control Register

The FPSCR register provides all necessary User level control of the floating-point
system.
FPSCR
Floating-point Status Control Register
Reset Value: XXXX XXXXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
N Z C V 0 AHP DN FZ RMode 0
rw rw rw rw r rw rw rw rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 IDC 0 IXC UFC OFC DZC IOC
r rw r rw rw rw rw rw

IOC 0 rw Invalid Operation cumulative exception bit
IOC set to 1 indicates that the Invalid Operation
cumulative exception has occurred since 0 was last
written to IOC.
DZC 1 rw Division by Zero cumulative exception bit
DZC set to 1 indicates that the Division by Zero
cumulative exception has occurred since 0 was last
written to DZC.
OFC 2 rw Overflow cumulative exception bit
OFC set to 1 indicates that the Overflow cumulative
exception has occurred since 0 was last written to OFC.
UFC 3 rw Underflow cumulative exception bit
UFC set to 1 indicates that the Underflow cumulative
exception has occurred since 0 was last written to UFC.
IXC 4 rw Inexact cumulative exception bit
IXC set to 1 indicates that the Inexact cumulative
exception has occurred since 0 was last written to IXC.
IDC 7 rw Input Denormal cumulative exception bit
see bits [4:0].

XMC4500
XMC4000 Family

RMode [23:22] rw Rounding Mode control field
00B Round to Nearest (RN) mode
01B Round towards Plus Infinity (RP) mode
10B Round towards Minus Infinity (RM) mode
11B Round towards Zero (RZ) mode.
The specified rounding mode is used by almost all
floating-point instructions.
FZ 24 rw Flush-to-zero mode control bit
0B Flush-to-zero mode disabled. Behavior of the
floating-point system is fully compliant with the
IEEE 754 standard.
1B Flush-to-zero mode enabled.
DN 25 rw Default NaN mode control bit
0B NaN operands propagate through to the output of
a floating-point operation.
1B Any operation involving one or more NaNs
returns the Default NaN.
AHP 26 rw Alternative half-precision control bit
0B IEEE half-precision format selected.
1B Alternative half-precision format selected.
V 28 rw Overflow condition code flag
Floating-point comparison operations update this flag.
C 29 rw Carry condition code flag
Z 30 rw Zero condition code flag
N 31 rw Negative condition code flag
0 27, r Reserved
[6:5]

XMC4500
XMC4000 Family
Floating-point Default Status Control Register

The FPDSCR register holds the default values for the floating-point status control data.
FPDSCR
Floating-point Default Status Control Register
(E000 EF3CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 AHP DN FZ RMode 0
r rw rw rw rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

RMode [23:22] rw Default value for FPSCR.RMode
FZ 24 rw Default value for FPSCR.FZ
DN 25 rw Default value for FPSCR.DN
AHP 26 rw Default value for FPSCR.AHP

XMC4500
XMC4000 Family
Bus System
3 Bus System
The XMC4500 is targeted for use in embedded systems. Therefore the key features are
timing determinism and low latency on real time events. Bus bandwidth is required
particularly for communication peripherals.
The bus system will therefore provide:
Timing Determinism
Low Latency
Performance
Throughput
3.1 Bus Interfaces

This chapter describes the features for the two kinds of interfaces.
Memory Interface
Peripheral Interface
All on-chip peripherals and memories are attached to the Bus Matrix, in some cases via
peripheral bridges. All on-chip modules implement Little Endian data organization. The
following types of transfer are supported:
Locked Transfers
Burst Operation
Protection Control
Pipelining is also supported for bandwidth critical transfers.
Memory Interface
The on-chip memories capable to accept a transfer request with each bus clock cycle.
The memory interface data bus width is 32-bit. Each memory slave support 32-bit, 16-
bit and 8-bit access types.
Peripheral Interface
Each slave supports 32-bit accesses. Some slaves also support 8-bit and/or 16-bit
accesses.
3.2 Bus Matrix

The central part of the bus system is built up around a multilayer AHB-lite compliant
matrix. By means of this technique the bus masters and bus slaves can be connected in
a flexible way while maintaining high bus performance.
The Bus Martix depicted in Figure 3-1 implements an optimized topology enabling zero
wait state data accesses between the Masters and Slaves connected to it. Dedicated

Bus System, V1.1 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Bus System
arbitration scheme enables optimal access conflicts resolution resulting in improved

system stability and real time behavior.
Masters
System System
CPU Ethernet USB
DMA0 DMA1
D-Code
System
I-Code
Flash
&
BROM
PSRAM
DSRAM 1
Slaves
DSRAM 2
EBU
Peripherals 0
(PBA0)
Peripherals 1
(PBA1)
Peripherals 2
(PBA2)
Figure 3-1 Multilayer Bus Matrix
Arbitration Priorities
In case of concurring access to the same slave the master with the highest priority is
granted the bus.

XMC4500
XMC4000 Family
Bus System
Table 3-1 Access Priorities per Slave1)

CPU GPDMA0 GPDMA1 ETH USB
PMU/FLASH 1 2 3 - -
PSRAM 1 2 3 - -
DSRAM1 1 2 3 4 5
DSRAM2 1 4 5 2 3
EBU 1 2 3 - -
PBA0 1 2 3 - -
PBA1 1 2 3 - -
PBA2 1 2 3 - -
1) Lower number means higher priority
The DSRAM priorities are choosen to support the application dependance of the data
memories:
DSRAM1: general purpose data storage
DSRAM2: Ethernet and USB data storage

XMC4500
XMC4000 Family
Service Request Processing
4 Service Request Processing

A hardware pulse or level change is called Service Request (SR) in an XMC4500
system. Service Requests are the fastest way to send trigger messages between
connected on-chip resources.
An SR can generate any of the following requests
Interrupt
DMA
Peripheral action
This chapter describes the available Service Requests and the different ways to select
and process them.
Notes
1. The CPU exception model and interrupt processing (by NVIC unit) are described in
the CPU chapter.
2. General Purpose DMA request processing is described in the GPDMA chapter
Table 4-1 Abbreviations

DLR DMA Line Router
ERU Event Request Unit
NVIC Nested Vectored Interrupt Controller
SR Service Request
4.1 Overview
Efficient Service Request Processing is based on the interconnect between the request
sources and the request processing units. XMC4500 provides both fixed and
programmable interconnect.
4.1.1 Features
The following features are provided for Service Request processing:
Connectivity matrix between Service Requests and request processing units
Fixed connections
Programmable connections using ERU
Event Request Unit (ERU)
Flexible processing of external and internal service requests
Programmable for edge and/or level triggering
Multiple inputs per channel
Triggers combinable from multiple inputs
Input and output gating

Service Request Processing, V1.1 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
DMA Line Router (DLR)

Routing and processing of DMA requests
4.1.2 Applications
The following table lists features of the Service Request Processing unit mapped to
selected applications.
Table 4-2 Feature to Application Mappings

Feature Application
TBD TBD
4.1.3 Block Diagram

The shaded components shown in Figure 4-1 are described in this chapter.
On-Chip Unit
PORTS
Outputs
Interconnections
ERU
On-Chip Unit
DLR NVIC PORTS
Inputs
Req Ack Req
GPDMA CPU
Figure 4-1 Block Diagram on Service Request Processing

XMC4500
XMC4000 Family
4.2 Service Request Distribution

The following figure shown an example of how a service request can be distributed
concurrently. To support the concurrent distribution to multiple receivers, the receiving
modules are capable to enable/disable incoming requests.
NVIC
(Interrupt)
DLR
(DMA Request)
VADC.SR0
CCU4.<input_x>
ERU1.<input_x>
Figure 4-2 Example for Service Request Distribution

The units involved in Service Request distribution can be subdivided into
Embedded real time services
Interrupt and DMA services
Embedded real time services

Connectivity between On-Chip Units and PORTS is real time application and also chip
package dependant. Related connectivity and availability of pins can be looked up in the
Interconnects Section of the respective module(s) chapters
Parallel Ports chapter and Data Sheet for PORTS
Event Request Unit (Section 4.5)
Interrupt and DMA services

The following table gives an overview on the number of service requests per module and
how the service requests are assigned to NVIC Interrupt and DLR/GPDMA service
providers.
Service Requests can be of type Level or Pulse. The DLR/GPDMA can only process
Pulse type of requests while the NVIC can process both. The type of Service Requests
generated is listed in column Type in Table 4-3.

XMC4500
XMC4000 Family
Table 4-3 Interrupt and DMA services per Module

Modules Request NVIC DLR/GPDMA Type
Sources
VADC 20 20 20 Pulse
DSD 8 8 4 Pulse
DAC 2 2 2 Pulse
CCU40-3 16 16 8 Pulse
CCU80-1 8 8 4 Pulse
POSIF0-1 4 4 - Pulse
CAN 8 8 4 Pulse
USIC0-2 18 18 12 Pulse
LEDTS0 1 1 - Pulse
FCE 1 1 - Pulse
PMU0/Flash 1 1 - Pulse
GPDMA0-1 2 2 - Level
SCU 1 1 - Pulse
ERU0-1 8 8 4 Pulse & Level
SDMMC 1 1 - Level
USB0 1 1 - Level
ETH0 1 1 - Level
Totals 102 102 58 -
4.3 Interrupt Service Requests

The NVIC is an integral part of the Cortex M4 processor unit. Due to a tight coupling with
the CPU it allows to achieve lowest interrupt latency and efficient processing of late
arriving interrupts.
NVIC Features
112 interrupt nodes
Programmable priority level of 0-63 for each interrupt node. A higher level
corresponds to a lower priority, so level 0 is the highest interrupt priority
Request source can be level or edge signal type
Dynamic reprioritization of interrupts.
Grouping of priority values into group priority and subpriority fields.
Interrupt tail-chaining.

XMC4500
XMC4000 Family
One external Non-maskable interrupt (NMI)

Relocatable vector table
Software interrupt generation
Level-sensitive and pulse interrupts

The NVIC is capable to capture both level-sensitive and pulse interrupts.
A level-sensitive interrupt is held asserted until the peripheral deasserts the interrupt
signal. Deassertion is typically triggered by the interrupt service routine (ISR). It is
used for less frequent requests and
the ISR is often more complex and longer.
A pulse interrupt is asserted and after a fixed period of time automatically deasserted.
The period of time depends on the peripheral, please refer to the Service Request
Generation section of the respective peripheral. It is
used for more frequent requests and
the ISR is often more simple and shorter.
The way to process both types of requests differs and is described in section Level-
sensitive and pulse interrupts in the CPU chapter.
Service Request to IRQ Number Assignment

Table 4-4 lists the service request sources per on-chip unit and their assignment to NVIC
IRQ numbers. The resulting exception number is calculated by adding 16 to the IRQ
Number. The first 16 exception numbers are used by the Cortex M4 CPU. For calculation
of the resulting exception routine address please refer to the CPU chapter.
Table 4-4 Interrupt Node assignment

Service Request IRQ Number Description
SCU.SR0 0 System Control
ERU0.SR0 1...4 External Request Unit 0
ERU0.SR3
ERU1.SR0 5...8 External Request Unit 1
ERU1.SR3
NC 9, 10, 11 Reserved
PMU0.SR0 12 Program Management Unit
NC 13 Reserved
VADC.C0SR0 - 14...17 Analog to Digital Converter Common Block 0
VADC.C0SR3
VADC.G0SR0 - 18...21 Analog to Digital Converter Group 0
VADC.G0SR3

XMC4500
XMC4000 Family
Table 4-4 Interrupt Node assignment (contd)

VADC.G1SR3
VADC.G2SR3
VADC.G3SR3
DSD.SRM0 - 34...37 Delta Sigma Demodulator Main
DSD.SRM3
DSD.SRA0 - 38...41 Delta Sigma Demodulator Auxiliary
DSD.SRA3
DAC.SR0 - 42, 43 Digital to Analog Converter
DAC.SR1
CCU40.SR0 - 44...47 Capture Compare Unit 4 (Module 0)
CCU40.SR3
CCU41.SR3
CCU42.SR3
CCU43.SR3
CCU80.SR3
CCU81.SR3
POSIF0.SR0 - 68...69 Position Interface (Module 0)
POSIF0.SR1
POSIF1.SR0 - 70...71 Position Interface (Module 1)
POSIF1.SR1
NC 72...75 Reserved
CAN.SR0 - 76...83 MultiCAN
CAN.SR7
USIC0.SR0 - 84...89 Universal Serial Interface Channel (Module 0)
USIC0.SR5

XMC4500
XMC4000 Family
Table 4-4 Interrupt Node assignment (contd)

USIC1.SR5
USIC2.SR5
LEDTS0.SR0 102 LED and Touch Sense Control Unit (Module 0)
NC 103 Reserved
FCE.SR0 104 Flexible CRC Engine
GPDMA0.SR0 105 General Purpose DMA unit 0
SDMMC.SR0 106 Multi Media Card Interface
USB0.SR0 107 Universal Serial Bus
ETH0.SR0 108 Ethernet (Module 0)
NC 109 Reserved
GPDMA1.SR0 110 General Purpose DMA unit 1
NC 111 Reserved
4.4 DMA Line Router (DLR)

The DMA line router provides the following functionality:
Selection of DMA request sources
Handling of the DMA request and acknowledge handshake
Detection of service request overruns
4.4.1 Functional Description

This unit enables the user to select 12 DMA service requests out of the set of DMA
capable service request sources. It handles the Request and Acknowledge handshake
to the GPDMA. Furthermore it detects service request overruns.

XMC4500
XMC4000 Family
Service
Request
Subset of DMA capable SR
SRSELx.RSy DEMUX
Selected SR
DMA
LNEN.LNy Transfer
Req
DMA
GPDMA
Handler
Ack
OVRCLR.LNy OVRSTAT.LNy RAWSR.DLROVR
SCU
Figure 4-3 DMA Line Handler

For each DMA line the user can assign one service request source from the subset of
DMA capable XMC4500 service request sources. The assignment is done by
programming the SRSx bit field of register DLR_SRSELx.
If the selected service request pulse occurs and if the according line is enabled by the
DLR_LNEN register, then the DMA handler forwards the request and stores it until the
GPDMA responds with an acknowledge. A request pulse occurring while another
transfer is ongoing is ignored and the according overrun status bit is set in the
DLR_OVRSTAT register.
Once the overrun condition is entered the user can clear the overrun status bits by writing
to the DLR_OVRCLR register. Additionally the pending request must be reset by
successively disabling and enabling the respective line.

XMC4500
XMC4000 Family
If any bit within the DLR_OVRSTAT register is set, a service request is flagged by setting
the SCU_RAWSR.DLROVR bit.
The DLR unit has the following inputs:
Table 4-5 DMA Handler Service Request inputs

Service Request # of Inputs Description
ERU1.SR1 - 4 ERU1 (System Control) requests
ERU1.SR4
VADC.C0SR0 - 4 Analog to Digital Converter Common Block 0
VADC.C0SR3
VADC.G0SR0 - 4 Analog to Digital Converter Group 0
VADC.G0SR3
VADC.G1SR3
VADC.G2SR3
VADC.G3SR3
DSD.SR0 - 4 Delta Sigma Demodulator
DSD.SR3
DAC.SR0 - 2 Digital to Analog Converter
DAC.SR1
CCU40.SR0 - 2 Capture Compare Unit 4 (Module 0)
CCU40.SR1
CCU41.SR1
CCU42.SR1
CCU43.SR1
CCU80.SR1
CCU81.SR1
CAN.SR0 - 4 MultiCAN
CAN.SR3

XMC4500
XMC4000 Family
Table 4-5 DMA Handler Service Request inputs (contd)

Service Request # of Inputs Description
USIC0.SR0 - 4 Universal Serial Interface Channel (Module 0)
USIC0.SR3
USIC1.SR3
USIC2.SR3
4.4.2 DMA Service Request Source Selection

The selection of the request sources is done according to the following table by
programming the DLR_SRSELx register. Please note that each service request source
can be assigned to 2 different lines to provide maximum flexibility. For example
VADC.SR0 can be assigned to line 0 and 4.
Table 4-6 DMA Request Source Selection

DMA Line DMA Request Line Selected by DLR_SRSEL bit field
0 ERU0.SR0 RS0 = 0000B
VADC.C0SR0 RS0 = 0001B
VADC.G0SR3 RS0 = 0010B
DSD.SRM0 RS0 = 0101B
CCU40.SR0 RS0 = 0110B
CCU80.SR0 RS0 = 0111B
1)
Reserved RS0 = 1000B
CAN.SR0 RS0 = 1001B
USIC0.SR0 RS0 = 1010B
Reserved1) RS0 = 1100B
CCU42.SR0 RS0 = 1110B
1 ERU0.SR3 RS1 = 0000B

XMC4500
XMC4000 Family
Table 4-6 DMA Request Source Selection (contd)

DAC.SR0 RS1 = 0101B
CCU40.SR0 RS1 = 0110B
CCU80.SR0 RS1 = 0111B
1)
CAN.SR0 RS1 = 1001B
1)
CCU42.SR0 RS1 = 1110B
2 ERU0.SR1 RS2 = 0000B
CCU40.SR1 RS2 = 0111B
CCU80.SR1 RS2 = 1000B
CAN.SR1 RS2 = 1010B
CCU42.SR1 RS2 = 1110B

XMC4500
XMC4000 Family

3 ERU0.SR2 RS3 = 0000B
DAC.SR1 RS3 = 0110B
CCU40.SR1 RS3 = 0111B
CCU80.SR1 RS3 = 1000B
CAN.SR1 RS3 = 1010B
CCU42.SR1 RS3 = 1110B
4 ERU0.SR2 RS4 = 0000B
DAC.SR1 RS4 = 0110B
CCU41.SR0 RS4 = 0111B
CCU81.SR0 RS4 = 1000B
CAN.SR2 RS4 = 1010B

XMC4500
XMC4000 Family

CCU43.SR0 RS4 = 1110B
5 ERU0.SR1 RS5 = 0000B
DAC.SR0 RS5 = 0101B
CCU41.SR0 RS5 = 0110B
CCU81.SR0 RS5 = 0111B
1)
CAN.SR2 RS5 = 1001B
1)
CCU43.SR0 RS5 = 1110B
6 ERU0.SR3 RS6 = 0000B
CCU41.SR1 RS6 = 0111B
CCU81.SR1 RS6 = 1000B
1)
CAN.SR3 RS6 = 1010B

XMC4500
XMC4000 Family

CCU43.SR1 RS6 = 1110B
1)
7 ERU0.SR0 RS7 = 0000B
CCU41.SR1 RS7 = 0110B
CCU81.SR1 RS7 = 0111B
CAN.SR3 RS7 = 1001B
1)
CCU43.SR1 RS7 = 1110B
1)
8 ERU0.SR0 RS8 = 0000B
DAC.SR0 RS8 = 0100B
CCU42.SR0 RS8 = 0101B
Reserved1) RS8 = 1XXXB

XMC4500
XMC4000 Family

9 ERU0.SR1 RS9 = 0000B
DAC.SR1 RS9 = 0100B
CCU42.SR1 RS9 = 0101B
10 ERU0.SR2 RS10 = 0000B
DAC.SR0 RS10 = 0100B
CCU43.SR0 RS10 = 0101B
1)
Reserved RS10 = 1XXXB
11 ERU0.SR3 RS11 = 0000B
DAC.SR1 RS11 = 0100B
CCU43.SR1 RS11 = 0101B
1) Reserved combinations do not result in DMA requests. The reserved multiplexer inputs should be hard wired
to inactive.

XMC4500
XMC4000 Family
4.5 Event Request Unit (ERU)

The Event Request Unit (ERU) is a versatile multiple input event detection and
processing unit. The XMC4500 provides two units - ERU0 and ERU1.
Service Requests ERU Event Service by

by Event Sources Event Request Unit Action Providers
3
3
Source Inputs Channel 3
2
1
ADC ADC
0
CAPCOM CAPCOM
>1 &
&
GPIO IRQ
EVENTS TRIGGERS
Trigger Cross Connect
Event Input Selectors
Output Gating Unit 0

Event Combinations
Event Trigger Logic

/ Event Status Flag
DAC DSD
POSIF POSIF
Figure 4-4 Event Request Unit Overview

Each ERU unit consists of the following blocks:
An Event Request Select (ERS) unit.
Event Input Selectors allow the selection of one out of two inputs. For each of
these two inputs, an vector of 4 possible signals is available.
Event Combinations allow a logical combination of two input signals to a common
trigger.
An Event Trigger Logic (ETL) per Input Channel allows the definition of the
transition (edge selection, or by software) that lead to a trigger event and can also
store this status. Here, the input levels of the selected signals are translated into
events.
The Trigger Cross Connect Matrix distributes the events and status flags to the
Output Channels. Additionally, trigger signals from other modules are made available
and can be combined with the local triggers.
An Output Gating Unit (OGU) combines the trigger events and status information
and gates the Output depending on a gating signal.
Note: An event of one Input can lead to reactions on several Outputs, or also events on
several Inputs can be combined to a reaction on one Output.
4.5.1 Event Request Select Unit (ERS)

For each Input Channel x (x = 0-3), an ERSx unit handles the input selection for the
associated ETLx unit. Each ERSx performs a logical combination of two signals (Ax, Bx)

XMC4500
XMC4000 Family
to provide one combined output signal ERSxO to the associated ETLx. Input Ax can be
selected from 4 options of the input vector ERU_xA[3:0] and can be optionally inverted.
A similar structure exists for input Bx (selection from ERU_xB[3:0]).
In addition to the direct choice of either input Ax or Bx or their inverted values, the
possible logical combinations for two selected inputs are a logical AND or a logical OR.
EXISEL. EXICONx. EXICONx.

EXSxA NA SS
ERU_xA0
ERU_xA1
Select Select Ax
Input Polarity
ERU_xA2 Bx
Ax Ax
ERU_xA3 Select
Ax OR Bx Source ERSxO
1 ETLx
for
ERU_xB0
ERSxO
ERU_xB1
Select Select &
Ax AND Bx
Input Polarity
ERU_xB2
Bx Bx
ERU_xB3
EXISEL. EXICONx.
EXSxB NB ERSx
Figure 4-5 Event Request Select Unit Overview

The ERS units are controlled via register ERU0_EXISEL (one register for all four ERSx
units) and registers EXICONx (one register for each ERSx and associated ETLx unit,
e.g. ERU0_EXICONx (x=0-3) for Input Channel 0).
4.5.2 Event Trigger Logic (ETLx)

For each Input Channel x (x = 0-3), an event trigger logic ETLx derives a trigger event
and related status information from the input ERSxO. Each ETLx is based on an edge
detection block, where the detection of a rising or a falling edge can be individually
enabled. Both edges lead to a trigger event if both enable bits are set (e.g. to handle a
toggling input).
Each of the four ETLx units has an associated EXICONx register, that controls all options
of an ETLx (the register also holds control bits for the associated ERSx unit, e.g.
ERU0_EXICONx (x=0-3) to control ERS0 and ETL0).

XMC4500
XMC4000 Family
EXICONx. EXICONx.
FE LD ETLx
Modify
set Status Flag EXICONx.FL
Status to all OGUy
clear FL
Flag
ERSxO
Detect
edge event
ERSx Event TRx0 to
(edge) OGU0
Enable Select TRx1 to

trigger pulse OGU1
Trigger Trigger
TRx2 to
Pulse Output OGU2
TRx3 to
OGU3
EXICONx. EXICONx. EXICONx.

RE PE OCS
Figure 4-6 Event Trigger Logic Overview

When the selected event (edge) is detected, the status flag EXICONx.FL becomes set.
This flag can also be modified by software. Two different operating modes are supported
by this status flag.
It can be used as sticky flag, which is set by hardware when the desired event has been
detected and has to be cleared by software. In this operating mode, it indicates that the
event has taken place, but without indicating the actual status of the input.
In the second operating mode, it is cleared automatically if the opposite event is
detected. For example, if only the falling edge detection is enabled to set the status flag,
it is cleared when the rising edge is detected. In this mode, it can be used for pattern
detection where the actual status of the input is important (enabling both edge detections
is not useful in this mode).
The output of the status flag is connected to all following Output Gating Units (OGUy) in
parallel (see Figure 4-7) to provide pattern detection capability of all OGUy units
based on different or the same status flags.
In addition to the modification of the status flag, a trigger pulse output TRxy of ETLx can
be enabled (by bit EXICONx.PE) and selected to trigger actions in one of the OGUy
units. The target OGUy for the trigger is selected by bit field EXICON.OCS.
The trigger becomes active when the selected edge event is detected, independently
from the status flag EXICONx.FL.

XMC4500
XMC4000 Family
4.5.3 Cross Connect Matrix

The matrix shown in Figure 4-7 distributes the trigger signals (TRxy) and status signals
(EXICONx.FL) from the different ETLx units between the OGUy units. In addition, it
receives peripheral trigger signals that can be OR-combined with the ETLx trigger
signals in the OGUy units.
EXICON0.FL
Pattern
Detection ERU_PDOUT0
TR00 Inputs ERU_GOUT0
TR01
ERU_IOUT0
ETL0 TR02
OGU0
ERU_TOUT0
TR03 Trigger
Inputs Peripheral
TRx0 Triggers
EXICON1.FL
Pattern
TR11
ERU_IOUT1
ETL1 TR12
OGU1
ERU_TOUT1
TR13 Trigger
Inputs Peripheral
TRx1 Triggers
EXICON2.FL
Pattern
TR21
ERU_IOUT2
ETL2 TR22
OGU2
ERU_TOUT2
TR23 Trigger
Inputs Peripheral
TRx2 Triggers
EXICON3.FL
Pattern
TR31
ERU_IOUT3
ETL3 TR32
OGU3
ERU_TOUT3
TR33 Trigger
Inputs Peripheral
TRx3 Triggers
Figure 4-7 ERU Cross Connect Matrix

XMC4500
XMC4000 Family
4.5.4 Output Gating Unit (OGUy)

Each OGUy (y = 0-3) unit combines the available trigger events and status flags from the
Input Channels and distributes the results to the system. Figure 4-8 illustrates the logic
blocks within an OGUy unit. All functions of an OGUy unit are controlled by its associated
EXOCONy register, e.g. ERU0_EXOCONx (x=0-3) for OGU0. The function of an OGUy
unit can be split into two parts:
Trigger Combination:
All trigger signals TRxy from the Input Channels that are enabled and directed to
OGUy, a selected peripheral-related trigger event, and a pattern change event (if
enabled) are logically OR-combined.
Pattern Detection:
The status flags EXICONx.FL of the Input Channels can be enabled to take part in
the pattern detection. A pattern match is detected while all enabled status flags are
set.
Status Flags
EXICON0.FL
EXOCONy. EXOCONy.
IPEN0 GEEN
EXICON1.FL
ERU_PDOUTy
EXOCONy.
IPEN1 Detect EXOCONy.
EXICON2.FL Pattern PDR
EXOCONy.
IPEN2 Select
EXOCONy.
Gating
EXICON3.FL GP
Scheme
EXOCONy.
Triggers IPEN3
from Input ERU_GOUTy
Channels
TR0y
Combine
TR1y
Interrupt
OGU
Gating ERU_IOUTy
TR2y Triggers
(AND)
TR3y (OR)
ERU_TOUTy
ERU_OGUy1
ERU_OGUy2
Select
Peripheral EXOCONy.
Triggers Periph.
ERU_OGUy3 ISS
Triggers
OGUy
Figure 4-8 Output Gating Unit for Output Channel y

XMC4500
XMC4000 Family
Each OGUy unit generates 4 output signals that are distributed to the system (not all of
them are necessarily used):
ERU_PDOUTy to directly output the pattern match information for gating purposes
in other modules (pattern match = 1).
ERU_GOUTy to output the pattern match or pattern miss information (inverted
pattern match), or a permanent 0 or 1 under software control for gating purposes in
other modules.
ERU_TOUTy as combination of a peripheral trigger, a pattern detection result
change event, or the ETLx trigger outputs TRxy to trigger actions in other modules.
ERU_IOUTy as gated trigger output (ERU_GOUTy logical AND-combined with
ERU_TOUTy) to trigger service requests (e.g. the service request generation can be
gated to allow service request activation during a certain time window).
Trigger Combination
The trigger combination logically OR-combines different trigger inputs to form a common
trigger ERU_TOUTy. Possible trigger inputs are:
In each ETLx unit of the Input Channels, the trigger output TRxy can be enabled and
the trigger event can be directed to one of the OGUy units.
One out of three peripheral trigger signals per OGUy can be selected as additional
trigger source. These peripheral triggers are generated by on-chip peripheral
modules, such as capture/compare or timer units. The selection is done by bit field
EXOCONy.ISS.
In the case that at least one pattern detection input is enabled (EXOCONy.IPENx)
and a change of the pattern detection result from pattern match to pattern miss (or
vice-versa) is detected, a trigger event is generated to indicate a pattern detection
result event (if enabled by ECOCONy.GEEN).
The trigger combination offers the possibility to program different trigger criteria for
several input signals (independently for each Input Channel) or peripheral signals, and
to combine their effects to a single output, e.g. to generate an service request or to start
an ADC conversion. This combination capability allows the generation of a service
request per OGU that can be triggered by several inputs (multitude of request sources
results in one reaction).
The selection is defined by the bit fields ISS in registers ERU0_EXOCONx (x=0-3) (for
ERU0.OGUx) and ERU1_EXOCONy (y=0-3) (for ERU1.OGUy).
Pattern Detection
The pattern detection logic allows the combination of the status flags of all ETLx units.
Each status flag can be individually included or excluded from the pattern detection for
each OGUy, via control bits EXOCONy.IPENx. The pattern detection block outputs the
following pattern detection results:

XMC4500
XMC4000 Family
Pattern match (EXOCONy.PDR = 1 and ERU_PDOUTy = 1):

A pattern match is indicated while all status flags FL that are included in the pattern
detection are 1.
Pattern miss (EXOCONy.PDR = 0 and ERU_PDOUTy = 0):
A pattern miss is indicated while at least one of the status flags FL that are included
in the pattern detection is 0.
In addition, the pattern detection can deliver a trigger event if the pattern detection result
changes from match to miss or vice-versa (if enabled by EXOCONy.GEEN = 1). The
pattern result change event is logically OR-combined with the other enabled trigger
events to support service request generation or to trigger other module functions (e.g. in
the ADC). The event is indicated when the pattern detection result changes and
EXOCONy.PDR becomes updated.
The service request generation in the OGUy is based on the trigger ERU_TOUTy that
can be gated (masked) with the pattern detection result ERU_PDOUTy. This allows an
automatic and reproducible generation of service requests during a certain time window,
where the request event is elaborated by the trigger combination block and the time
window information (gating) is given by the pattern detection. For example, service
requests can be issued on a regular time base (peripheral trigger input from
capture/compare unit is selected) while a combination of input signals occurs (pattern
detection based on ETLx status bits).
A programmable gating scheme introduces flexibility to adapt to application
requirements and allows the generation of service requests ERU_IOUTy under different
conditions:
Pattern match (EXOCONy.GP = 10B):
A service request is issued when a trigger event occurs while the pattern detection
shows a pattern match.
Pattern miss (EXOCONy.GP = 11B):
A service request is issued when the trigger event occurs while the pattern detection
shows a pattern miss.
Independent of pattern detection (EXOCONy.GP = 01B):
In this mode, each occurring trigger event leads to a service request. The pattern
detection output can be used independently from the trigger combination for gating
purposes of other peripherals (independent use of ERU_TOUTy and ERU_PDOUTy
with service requests on trigger events).
No service requests (EXOCONy.GP = 00B, default setting)
In this mode, an occurring trigger event does not lead to a service request. The
pattern detection output can be used independently from the trigger combination for
gating purposes of other peripherals (independent use of ERU_TOUTy and
ERU_PDOUTy without service requests on trigger events).

XMC4500
XMC4000 Family
4.6 Service Request Generation

If any bit within the DLR.DLR_OVRSTAT register is set, a service request is flagged by
setting the SCU_RAWSR.DLROVR bit.
errors
reaching buffer limits
Service requests can be disabled by....
A direct connection to the ADC enables the ASC to trigger an ADC conversion upon
reception of a programmable data pattern.
4.7 Debug Behavior

Service request processing behavior is unchanged in debug mode.
4.8 Power, Reset and Clock

Service request processing is
consuming power in all operating modes.
running on fCPU.
asynchronously initialized by the system reset.
4.9 Initialization and System Dependencies

Service Requests must always be enabled at the source and at the destination.
Additionally it must be checked whether it is necessary to program the ERU process and
route a request.
Enabling Peripheral SRx Outputs

Peripherals SRx outputs must be selectively enabled. This procedure depends on
the individual peripheral. Please look up the section Service Request Generation
within a peripherals chapter for details.
Optionally ERUx must be programmed to process and route the request
Enabling External Requests

Selected PORTS must be programmed for input
ERUx must be programmed to process and route the external request
Note: The number of external service request inputs may be limited by the package
used.
Enabling NVIC and GPDMA

Interrupt and DMA service request processing must be enabled. Please refer to the CPU
and GPDMA chapters for details.

XMC4500
XMC4000 Family
4.10 Registers
Registers Overview
The absolute register address is calculated by adding:
Module Base Address + Offset Address
Table 4-7 Registers Address Space

Module Base Address End Address Note
DLR 5000 4900H 5000 49FFH
ERU0 5000 4800H 5000 48FFH
ERU1 4004 4000H 4004 7FFFH
Table 4-8
Short Name Description Offset Access Mode Description
Addr. Read Write See
DLR Registers
OVRSTAT Status of DMA Service 000H U, PV PV Page 4-25
Request Overruns
OVRCLR Clear Status of DMA 004H U, PV PV Page 4-26
Service Request
Overruns
SRSEL0 DLR Service Request 008H U, PV PV Page 4-27
Selection 0
LNEN Enable DLR Line 010H U, PV PV Page 4-26
SRSEL1 DLR Service Request 00CH U, PV PV Page 4-28
Selection 1
ERU Registers
EXISEL ERU External Input 0000H U, PV PV Page 4-29
Control Selection
EXICON0 ERU External Input 0010H U, PV PV Page 4-31
Control Selection
Control Selection
Control Selection

XMC4500
XMC4000 Family
Table 4-8 (contd)

EXICON3 ERU External Input 001CH U, PV PV Page 4-31
Control Selection
EXOCON0 ERU Output Control 0020H U, PV PV Page 4-33
Register
Register
Register
EXOCON3 ERU Output Control 002CH U, PV PV Page 4-33
Register
4.10.1 DLR Registers
DLR_OVRSTAT
The DLR_OVRSTAT register is used to track status of GPDMA service request
overruns. Upon overrun detection, additionally a service request flag is set in the
SCU_RAWSR.DLROVR bit.
DLR_OVRSTAT
Overrun Status (00H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 LN11 LN10 LN9 LN8 LN7 LN6 LN5 LN4 LN3 LN2 LN1 LN0
r rh rh rh rh rh rh rh rh rh rh rh rh

LNx x rh Line x Overrun Status
(x = 0-11) Set if an overrun occurred on this line.

XMC4500
XMC4000 Family

DLR_OVRCLR
The DLR_OVRCLR register is used to clear the DLR_OVRSTAT register bits.
DLR_OVRCLR
Overrun Clear (04H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
r w w w w w w w w w w w w

LNx x w Line x Overrun Status Clear
(x = 0-11) Clears the corresponding bit in the DLR_OVRSTAT
register when set to 1.
DLR_LNEN
The DLR_LNEN register is used to enable each individual DLR line and to reset a
previously stored and pending service request.

XMC4500
XMC4000 Family
DLR_LNEN
Line Enable (10H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
r rw rw rw rw rw rw rw rw rw rw rw rw

LNx x rw Line x Enable
(x = 0-11) 0B Disables the line
1B Enables the line and resets a pending request
DLR_SRSELx
The DLR_SRSELx registers are used to select the service request source used to
trigger a DMA transfer.
DLR_SRSEL0
Service Request Selection 0
(08H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RS7 RS6 RS5 RS4
rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RS3 RS2 RS1 RS0
rw rw rw rw

XMC4500
XMC4000 Family

RSx [x*4+3: rw Request Source for Line x
(x = 0-7) x*4] The request source according to Table 4-6 is
selected for DMA line x.
DLR_SRSEL1
Service Request Selection 1
(0CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RS11 RS10 RS9 RS8
rw rw rw rw

RS8 [3:0] rw Request Source for Line 8
The request source according to Table 4-6 is

XMC4500
XMC4000 Family
4.10.2 ERU Registers
ERU0_EXISEL
Event Input Select (00H) Reset Value: 0000 0000H
ERU1_EXISEL
Event Input Select (0000H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EXS3B EXS3A EXS2B EXS2A EXS1B EXS1A EXS0B EXS0A
rw rw rw rw rw rw rw rw

EXS0A [1:0] rw Event Source Select for A0 (ERS0)
This bit field defines which input is selected for A0.
00B Input ERU_0A0 is selected
EXS0B [3:2] rw Event Source Select for B0 (ERS0)
This bit field defines which input is selected for B0.
00B Input ERU_0B0 is selected

XMC4500
XMC4000 Family


XMC4500
XMC4000 Family
ERU0_EXICONx (x=0-3)
Event Input Control x
(10H + 4*x) Reset Value: 0000 0000H
ERU1_EXICONy (y=0-3)
Event Input Control y
(0010H + 4*y) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 NB NA SS FL OCS FE RE LD PE
r rw rw rw rwh rw rw rw rw rw

PE 0 rw Output Trigger Pulse Enable for ETLx
This bit enables the generation of an output trigger
pulse at TRxy when the selected edge is detected
(set condition for the status flag FL).
0B The trigger pulse generation is disabled
1B The trigger pulse generation is enabled
LD 1 rw Rebuild Level Detection for Status Flag for ETLx
This bit selects if the status flag FL is used as sticky
bit or if it rebuilds the result of a level detection.
0B The status flag FL is not cleared by hardware
and is used as sticky bit. Once set, it is not
influenced by any edge until it becomes
cleared by software.
1B The status flag FL rebuilds a level detection of
the desired event. It becomes automatically set
with a rising edge if RE = 1 or with a falling
edge if FE = 1. It becomes automatically
cleared with a rising edge if RE = 0 or with a
falling edge if FE = 0.

XMC4500
XMC4000 Family

RE 2 rw Rising Edge Detection Enable ETLx
This bit enables/disables the rising edge event as
edge event as set condition for the status flag FL or
as possible trigger pulse for TRxy.
0B A rising edge is not considered as edge event
1B A rising edge is considered as edge event
FE 3 rw Falling Edge Detection Enable ETLx
This bit enables/disables the falling edge event as
edge event as set condition for the status flag FL or
as possible trigger pulse for TRxy.
0B A falling edge is not considered as edge event
1B A falling edge is considered as edge event
OCS [6:4] rw Output Channel Select for ETLx Output Trigger
Pulse
This bit field defines which Output Channel OGUy is
targeted by an enabled trigger pulse TRxy.
000B Trigger pulses are sent to OGU0
Others: Reserved, do not use this combination
FL 7 rwh Status Flag for ETLx
This bit represents the status flag that becomes set
or cleared by the edge detection.
0B The enabled edge event has not been
detected
1B The enabled edge event has been detected
SS [9:8] rw Input Source Select for ERSx
This bit field defines which logical combination is
taken into account as ERSxO.
00B Input A without additional combination
01B Input B without additional combination
10B Input A OR input B
11B Input A AND input B
NA 10 rw Input A Negation Select for ERSx
This bit selects the polarity for the input A.
0B Input A is used directly
1B Input A is inverted

XMC4500
XMC4000 Family

NB 11 rw Input B Negation Select for ERSx
This bit selects the polarity for the input B.
0B Input B is used directly
1B Input B is inverted
ERU0_EXOCONx (x=0-3)
Event Output Trigger Control x
(20H + 4*x) Reset Value: 0000 0008H
ERU1_EXOCONy (y=0-3)
Event Output Trigger Control y
(0020H + 4*y) Reset Value: 0000 0008H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
IPEN IPEN IPEN IPEN GEE
0 GP PDR ISS
3 2 1 0 N
rw rw rw rw r rw rh rw rw

ISS [1:0] rw Internal Trigger Source Selection
This bit field defines which input is selected as
peripheral trigger input for OGUy.
00B The peripheral trigger function is disabled
01B Input ERU_OGUy1 is selected
GEEN 2 rw Gating Event Enable
Bit GEEN enables the generation of a trigger event
when the result of the pattern detection changes from
match to miss or vice-versa.
0B The event detection is disabled
1B The event detection is enabled

XMC4500
XMC4000 Family

PDR 3 rh Pattern Detection Result Flag
This bit represents the pattern detection result.
0B A pattern miss is detected
1B A pattern match is detected
GP [5:4] rw Gating Selection for Pattern Detection Result
This bit field defines the gating scheme for the service
request generation (relation between the OGU output
ERU_PDOUTy and ERU_GOUTy).
00B ERU_GOUTy is always disabled and
ERU_IOUTy can not be activated
01B ERU_GOUTy is always enabled and ERU_IOUTy
becomes activated with each activation of
ERU_TOUTy
10B ERU_GOUTy is equal to ERU_PDOUTy and
ERU_IOUTy becomes activated with an activation
of ERU_TOUTy while the desired pattern is
detected (pattern match PDR = 1)
11B ERU_GOUTy is inverted to ERU_PDOUTy and
ERU_IOUTy becomes activated with an activation
of ERU_TOUTy while the desired pattern is not
detected (pattern miss PDR = 0)
IPENx 12+x rw Pattern Detection Enable for ETLx
(x = 0-3) Bit IPENx defines whether the trigger event status flag
EXICONx.FL of ETLx takes part in the pattern detection
of OGUy.
0B Flag EXICONx.FL is excluded from the pattern
detection
1B Flag EXICONx.FL is included in the pattern
detection
, [11:6] Read as 0; should be written with 0.
4.11 Interconnects
This section describes how the ERU0 and ERU1 modules are connected within the
XMC4500 system.

XMC4500
XMC4000 Family
ERU0
- Select
xA[3:0] - Combine
x - Detect y
IOUTy TRIGGER
EXTERNAL EVENTS
- Cross-
Connect
xB[3:0] - Gate
GPDMA
SR1-4
PORTS Req Ack
PORTS
DLR
PORTS NVIC.SRn
SR5-8
PORTS
ERU1
- Select
xA[3:0] - Combine IOUTy TRIGGER
x - Detect y
- Cross-
Connect
xB[3:0] - Gate PDOUTy LEVEL
INTERNAL EVENTS
PERIPH
PERIPH
PERIPH
Top-Level
Cross
Inter-
connect
x=0-3 y=0-3
Figure 4-9 ERU Interconnects Overview
4.11.1 ERU0 Connections

The following table shows the ERU0 connections. Please refer to the ports chapter for
details about PORTS connections.
Table 4-9 ERU0 Pin Connections

Global Connected To I/O Description
Inputs/Outputs
ERU0.0A0 PORTS I
ERU0.0A1 PORTS I
ERU0.0A2 PORTS I
ERU0.0A3 SCU.G0ORCOUT6 I

XMC4500
XMC4000 Family
Table 4-9 ERU0 Pin Connections (contd)

Inputs/Outputs
ERU0.0B0 PORTS I
ERU0.0B1 PORTS I
ERU0.0B2 PORTS I
ERU0.0B3 PORTS I
ERU0.1A0 PORTS I
ERU0.1A1 SCU.HIB_SR0 I
ERU0.1A2 PORTS I
ERU0.1B0 PORTS I
ERU0.1B1 SCU.HIB_SR1 I
ERU0.1B2 PORTS I
ERU0.1B3 PORTS I
ERU0.2A0 PORTS I
ERU0.2A1 PORTS I
ERU0.2A2 PORTS I
ERU0.2B0 PORTS I
ERU0.2B1 PORTS I
ERU0.2B2 PORTS I
ERU0.2B3 PORTS I
ERU0.3A0 PORTS I
ERU0.3A1 PORTS I
ERU0.3A2 PORTS I
ERU0.3B0 PORTS I
ERU0.3B1 PORTS I
ERU0.3B2 PORTS I
ERU0.3B3 PORTS I
ERU0.OGU01 0 I
ERU0.OGU02 0 I

XMC4500
XMC4000 Family

Inputs/Outputs
ERU0.OGU03 1 I
ERU0.OGU11 0 I
ERU0.OGU12 0 I
ERU0.OGU13 1 I
ERU0.OGU21 0 I
ERU0.OGU22 0 I
ERU0.OGU23 1 I
ERU0.OGU31 0 I
ERU0.OGU32 0 I
ERU0.OGU33 1 I
ERU0.PDOUT0 not connected O
ERU0.GOUT0 not connected O
ERU0.TOUT0 not connected O
ERU0.IOUT0 NVIC.ERU0.SR0 O
DLR
DLR
DLR
DLR

XMC4500
XMC4000 Family
4.11.2 ERU1 Connections

The following table shows the ERU1 connections. Please refer to the ports chapter for
details about PORTS connections.
Table 4-10 ERU1 Pin Connections

Inputs/Outputs
ERU1.0A0 PORTS I
ERU1.0A1 POSIF0.SR1 I
ERU1.0A2 CCU40.ST0 I
ERU1.0A3 DAC.SIGN_0 I
ERU1.0B0 PORTS I
ERU1.0B1 CCU80.ST0 I
ERU1.0B2 VADC.G0BFL3 I
ERU1.0B3 ERU1.IOUT3 I
ERU1.1A0 PORTS I
ERU1.1A3 ERU1.IOUT2 I
ERU1.1B0 PORTS I
ERU1.1B3 ERU1.IOUT2 I
ERU1.2A0 PORTS I
ERU1.2A3 DAC.SIGN_1 I
ERU1.2B0 PORTS I
ERU1.2B3 not connected I
ERU1.3A0 PORTS I

XMC4500
XMC4000 Family

Inputs/Outputs
ERU1.3A3 not connected I
ERU1.3B0 PORTS I
ERU1.3B3 not connected I
ERU1.OGU01 VADC.C0SR0 I
ERU1.OGU02 CCU40.ST0 I
ERU1.OGU03 1 I
ERU1.OGU12 CCU41.ST0 I
ERU1.OGU13 1 I
ERU1.OGU22 CCU81.ST3A I
ERU1.OGU23 1 I
ERU1.OGU32 CCU81.ST3B I
ERU1.OGU33 1 I

XMC4500
XMC4000 Family

Inputs/Outputs
ERU1.PDOUT0 CCU40.IN0J O
CCU41.IN0J
CCU42.IN0J
CCU43.IN0J
CCU40.IN1D
CCU40.IN2D
CCU40.IN3D
CCU41.IN1D
CCU41.IN2D
CCU41.IN3D
CCU42.IN1D
CCU42.IN2D
CCU42.IN3D
CCU43.IN1D
CCU43.IN2D
CCU43.IN3D
CCU80.IN0J
CCU80.IN1J
CCU80.IN2J
CCU80.IN3J
VADC.G0REQGTO
VADC.G1REQGTO
VADC.G2REQGTO
VADC.G3REQGTO
VADC.BGREQGTO
DSD.ITR0A
DSD.ITR1A
DSD.ITR2A
DSD.ITR3A
POSIF0.IN0D
POSIF1.IN0D

XMC4500
XMC4000 Family

Inputs/Outputs
ERU1.IOUT0 CCU4x.IN0K O
CCU8x.IN0G
VADC.G0REQTRM
VADC.G1REQTRM
VADC.G2REQTRM
VADC.G3REQTRM
VADC.BGREQTRM
CCU40.MCLKA
CCU41.MCLKA
CCU42.MCLKA
CCU43.MCLKA
CCU80.MCLKA
CCU81.MCLKA
NVIC.ERU1.SR0
POSIF0.EWHEB
POSIF1.EWHEB
CCU41.IN1J
CCU42.IN1J
CCU43.IN1J
CCU81.IN0I
CCU81.IN1I
CCU81.IN2I
CCU81.IN3I
CCU40.IN0D
CCU41.IN0D
CCU42.IN0D
CCU43.IN0D
VADC.G0REQGTP
VADC.G1REQGTP
VADC.BGREQGTP
DSD.ITR0B
DSD.ITR1B
DSD.ITR2B
DSD.ITR3B
POSIF0.IN1D
POSIF1.IN1D

XMC4500
XMC4000 Family

Inputs/Outputs
ERU1.IOUT1 CCU40.IN1K O
CCU41.IN1K
CCU42.IN1K
CCU43.IN1K
CCU80.IN1G
CCU81.IN1G
VADC.G0REQTRN
VADC.G1REQTRN
VADC.BGREQTRN
CCU40.MCLKB
CCU41.MCLKB
CCU42.MCLKB
CCU43.MCLKB
CCU80.MCLKB
CCU81.MCLKB
NVIC.ERU1.SR1
POSIF0.EWHEC
POSIF1.EWHEC
CCU41.IN2J
CCU42.IN2J
CCU43.IN2J
CCU80.IN2F
CCU81.IN2F
DSD.ITR0C
DSD.ITR1C
DSD.ITR2C
DSD.ITR3C
DSD.SGNA
VADC.G2REQGTP
VADC.G3REQGTP
POSIF0.IN2D
POSIF1.IN2D

XMC4500
XMC4000 Family

Inputs/Outputs
CCU41.IN2K
CCU42.IN2K
CCU43.IN2K
CCU80.IN2G
CCU81.IN2G
VADC.G2REQTRN
VADC.G3REQTRN
ERU1.1A3
ERU1.1B3
NVIC.ERU1.SR2
POSIF0.MSETF
POSIF1.MSETF
CCU41.IN3J
CCU42.IN3J
CCU43.IN3J
CCU80.IN3F
CCU81.IN3F
DSD.ITR0D
DSD.ITR1D
DSD.ITR2D
DSD.ITR3D
DSD.SGNB
CCU41.IN3K
CCU42.IN3K
CCU43.IN3K
CCU80.IN3G
CCU81.IN3G
ERU1.0B3
NVIC.ERU1.SR3

XMC4500
XMC4000 Family
General Purpose DMA (GPDMA)
5 General Purpose DMA (GPDMA)

The GPDMA is a highly configurable DMA controller, that allows high-speed data
transfers between peripherals and memories. Complex data transfers can be done with
minimal intervention of the processor, keeping this way the CPU resources free for other
operations.
Extensive support for the microcontroller peripherals, like A/D and D/A converters,
Timers, Communication Interfaces (USIC) via the GPDMA, unload the CPU and
increase the efficiency and parallelism, for a high arrangement of real-time applications.
Table 5-1 Abbreviations table

GPDMAx General Purpose DMA instance x
SCU System Control Unit
DLR DMA Line Router
fDMA GPDMA clock frequency
5.1 Overview
The GPDMA module enables hardware or software controlled data transfers between all
microcontroller modules with the exclusion of those modules which provide built-in DMA
functionality (USB and Ethernet).
Each GPDMA module contains a dedicated set of highly programmable channels, that
can accommodate several type of peripheral-to-peripheral, peripheral-to-memory and
memory-to-memory transfers.
The link between a highly programmable channel allocation and channel priority, gives
a high benefit for applications that need high efficiency and parallelism.
The built-in fast DMA request handling together with the flexible peripheral configuration,
enables the implementation of very demanding application software loops.
5.1.1 Features
The GPDMA component includes the following features.
General
Bus interfaces
1 Bus master interface per each DMA unit
1 Bus slave interface per each DMA unit
Channels
One GPDMA0 unit with 8 channels
One GPDMA1 unit with 4 channels
Programmable channel priority

GPDMA, V1.1 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Transfers
Support for memory-to-memory, memory-to-peripheral, peripheral-to-memory,
and peripheral-to-peripheral DMA transfers
Channels
All channels can be programmed for the following transfer modes
DMA triggered by software or selectable from hardware service request sources
Programmable source and destination addresses
Address increment, decrement, or no change
Channels 0 and 1 of GPDMA0 can be programmed for the following transfer modes
Multi-block transfers achieved through:
Linked Lists (block chaining)
Auto-reloading of channel registers
Contiguous address between blocks
Independent source and destination selection of multi-block transfer type
Scatter/Gather - source and destination areas do not need to be in a contiguous
memory space
The GPDMA0 channels 0 and 1 provide a FIFO of 32 Bytes (eight 32-bit entries). These
channels can be used to execute burst transfers up to a fixed length burst size of 8. The
remaining channels FIFO size is 8 Bytes.
Channel Control
Programmable source and destination for each channel
Programmable burst transaction size for each channel
Programmable enable and disable of DMA channel
Support for disabling channel without data loss
Support for suspension of DMA operation
Support for ERROR response
Bus locking - programmable over transaction, block, or DMA transfer level
Channel locking - programmable over transaction, block, or DMA transfer level
Optional writeback of the Channel Control register at the end of every block transfer
Interrupts
Combined and separate interrupt requests
Interrupt generation on:
DMA transfer (multi-block) completion
Block transfer completion
Single and burst transaction completion
Error condition
Support of interrupt enabling and masking

XMC4500
XMC4000 Family
5.1.2 GPDMA Block Diagram

Figure 5-1 shows the following functional groupings of the main interfaces to the
GPDMA block:
DMA hardware request interface (DLR)
Up to twelve channels
Arbiter
Bus Master and Slave interfaces
One channel of the GPDMA is required for each source/destination pair. The master
interface reads the data from a source peripheral and writes it to a destination peripheral.
Two transfers are required for each DMA data transfer; this is also known as a dual-
access transfer.
The Ethernet and USB peripherals have an internal DMA controller, that enables the
peripheral to act as a Master on the system.
GPDMA0
GPDMA Channels
Slave I/F
Channel 7
...
Channel 1 Arbiter
Master I/F
Channel 0 Cortex uC
Ethernet USB
HW handshaking
HW I/F n
...
HW I/F 1
HW I/F 0 SRAM
Bus Matrix
Peripherals
(Bridge 1)
Bridge 1
GPDMA1
Bridge 2
GPDMA Channels Peripherals
Slave I/F
(Bridge 2)
Channel 3
...
Channel 1 Arbiter
Master I/F
Channel 0
DLR
(DMA Line Router)
DMA requests
HW handshaking
DMA requests
HW I/F n
...
HW I/F 1
HW I/F 0
Figure 5-1 GPDMA Block Diagram

XMC4500
XMC4000 Family
5.2 Functional Description

This chapter describes the functional details of the GPDMA component. On
Section 5.2.1 a description of used terms throughout the chapters is given.
5.2.1 Basic Definitions

The following terms are concise definitions of the DMA concepts used throughout this
chapter:
Source peripheral - Device on a AHB layer from which the GPDMA reads data; the
GPDMA then stores the data in the channel FIFO. The source peripheral teams up
with a destination peripheral to form a channel.
Destination peripheral - Device to which the GPDMA writes the stored data from
the FIFO (previously read from the source peripheral).
Memory - Source or destination that is always "ready" for a DMA transfer and does
not require a handshaking interface to interact with the GPDMA.
Channel - Read/write data path between a source peripheral and a destination
peripheral, that occurs through the channel FIFO. If the source peripheral is not
memory, then a source handshaking interface is assigned to the channel. If the
destination peripheral is not memory, then a destination handshaking interface is
assigned to the channel. Source and destination handshaking interfaces can be
assigned dynamically by programming the channel registers.
Master interface - GPDMA is a master on the AHB, reading data from the source
and writing it to the destination over the bus. Each channel has to arbitrate for the
master interface.
Slave interface - The AHB interface over which the GPDMA is programmed.
Handshaking interface - A set of signals or software registers that conform to a
protocol and handshake between the GPDMA and source or destination peripheral
in order to control transferring a single or burst transaction between them. This
interface is used to request, acknowledge, and control a GPDMA transaction. A
channel can receive a request through one of two types of handshaking interface:
software, or peripheral interrupt.
Software handshaking interface- Uses software registers to control transferring
a single or burst transaction between the GPDMA and the source or destination
peripheral. This mode is useful for interfacing an existing peripheral to the GPDMA
without modifying it. For more information about this interface, refer to
Section 5.2.6.
Peripheral interrupt handshaking interface - Simple use of the hardware
handshaking interface. In this mode, the interrupt line from the peripheral is tied to
the dma request input of the hardware handshaking interface;
Flow controller - Device that determines the length of a DMA block transfer and
terminates it.

XMC4500
XMC4000 Family
Transfer hierarchy - Figure 5-2 illustrates the hierarchy between GPDMA transfers,
block transfers, transactions (single or burst), and AHB transfers (single or burst) for
non-memory peripherals. Figure 5-3 shows the transfer hierarchy for memory.
Note: Note that for memory peripherals, there is no DMA Transaction Level.
GPDMA
Transfer DMA Transfer Level
Block Block ... Block Block Transfer Level
Burst Burst Burst Single DMA Transaction

Transaction Transaction
... Transaction Transaction Level
Burst Burst Burst Single Single Transfer

...
Transfer Transfer Transfer Transfer Transfer Level
Figure 5-2 GPDMA Transfer Hierarchy for Non-Memory Peripherals
GPDMA
Transfer DMA Transfer Level
Block Block ... Block Block Transfer Level
Burst Burst Burst Single Transfer

Transfer Transfer
... Transfer Transfer Level
Figure 5-3 GPDMA Transfer Hierarchy for Memory

Block - Block of GPDMA data, the amount of which is the block length and is
determined by the flow controller. For transfers between the GPDMA and memory, a
block is broken directly into a sequence of bursts and single transfers. For transfers
between the GPDMA and a non-memory peripheral, a block is broken into a
sequence of GPDMA transactions (single and bursts). These are in turn broken into
a sequence of AHB transfers.
Transaction - Basic unit of a GPDMA transfer, as determined by either the hardware
or software handshaking interface. A transaction is relevant only for transfers

XMC4500
XMC4000 Family
between the GPDMA and a source or destination peripheral if the peripheral is a non-
memory device. There are two types of transactions:
Single transaction - is always converted to a single AHB transfer.
Burst transaction - Length of a burst transaction is programmed into the GPDMA.
The burst transaction is converted into a sequence of AHB fixed length bursts and
AHB single transfers. GPDMA executes each burst transfer by performing
incremental bursts that are no longer than the maximum burst size set; the only
type of burst in this kind of transaction is incremental. The burst transaction length
is under program control and normally bears some relationship to the FIFO sizes
in the GPDMA and in the source and destination peripherals.
DMA transfer - Software controls the number of blocks in a GPDMA transfer. Once
the DMA transfer has completed, the hardware within the GPDMA disables the
channel and can generate an interrupt to signal the DMA transfer completion. You
can then reprogram the channel for a new DMA transfer.
Single-block DMA transfer - Consists of a single block.
Multi-block DMA transfer - DMA transfer may consist of multiple GPDMA blocks.
Multi-block DMA transfers are supported through block chaining (linked list
pointers), auto-reloading channel registers, and contiguous blocks. The source
and destination can independently select which method to use
- Linked lists (block chaining) - Linked list pointer (LLP) points to the location in
system memory where the next linked list item (LLI) exists. The LLI is a set of
registers that describes the next block (block descriptor) and an LLP register. The
GPDMA fetches the LLI at the beginning of every block when block chaining is
enabled.
LLI accesses are always 32-bit accesses aligned to 32-bit boundaries and cannot
be changed or programmed to anything other than 32-bit, even if the AHB master
interface of the LLI supports more than a 32-bit data width.
- Auto-reloading - GPDMA automatically reloads the channel registers at the end
of each block to the value when the channel was first enabled.
- Contiguous blocks - Address between successive blocks is selected to be a
continuation from the end of the previous block.
Scatter - Relevant to destination transfers within a block. The destination address is
incremented or decremented by a programmed amount when a scatter boundary is
reached. The number of AHB transfers between successive scatter boundaries is
under software control.
Gather - Relevant to source transfers within a block. The source address is
incremented or decremented by a programmed amount when a gather boundary is
reached. The number of AHB transfers between successive gather boundaries is
under software control.
Channel locking - Software can program a channel to keep the AHB master
interface by locking arbitration of the master AHB interface for the duration of a DMA
transfer, block, or transaction (single or burst).

XMC4500
XMC4000 Family
Bus locking - Software can program a channel to maintain control of the AHB bus
for the duration of a DMA transfer, block, or transaction (single or burst). At minimum,
channel locking is asserted during bus locking.
FIFO mode - Special mode to improve bandwidth. When enabled, the channel waits
until the FIFO is less than half full to fetch the data from the source peripheral, and
waits until the FIFO is greater than or equal to half full in order to send data to the
destination peripheral. Because of this, the channel can transfer the data using
bursts, which eliminates the need to arbitrate for the AHB master interface in each
single AHB transfer. When this mode is not enabled, the channel waits only until the
FIFO can transmit or accept a single AHB transfer before it requests the master bus
interface.
5.2.2 Block Flow Controller and Transfer Type

The device that controls the length of a block is known as the flow controller.
The block size should be programmed into the CTL.BLOCK_TS field.
The CTL.TT_FC field indicates the transfer type and flow controller for that channel.
Table 5-2 lists valid transfer types and flow controller combinations.
Table 5-2 Transfer Types and Flow Control Combinations

Transfer Type Flow Controller
Memory to Memory GPDMA
Memory to Peripheral GPDMA
Peripheral to Memory GPDMA
Peripheral to Peripheral GPDMA
5.2.3 Handshaking Interface

Handshaking interfaces are used at the transaction level to control the flow of single or
burst transactions.
The peripheral uses the handshaking interface to indicate to the GPDMA that it is ready
to transfer data over the AHB bus.
A non-memory peripheral can request a DMA transfer through the GPDMA using one of
two types of handshaking interfaces:
Hardware
Software
Software selects between the hardware or software handshaking interface on a per-
channel basis. Software handshaking is accomplished through memory-mapped
registers, while hardware handshaking is accomplished using a dedicated handshaking
interface.

XMC4500
XMC4000 Family
Note: Throughout the remainder of this chapter, references to both source and
destination hardware handshaking interfaces assume an active-high interface
(refer to CFGx.SRC(DST)_HS_POL bits in the Channel Configuration register,
CFG). When active-low handshaking interfaces are used, then the active level and
edge are reversed from that of an active-high interface.
Note: Source and destination peripherals can independently select the handshaking
interface type; that is, hardware or software handshaking. For more information,
refer to the CFGx.HS_SEL_SRC and CFGx.HS_SEL_DST parameters in the
CFG register.
5.2.4 Basic Interface Definitions

The following definitions are used in this chapter:
Source single transaction size in bytes, see (5.1)
Source burst transaction size in bytes, see (5.2)
Destination single transaction size in bytes, see (5.3)
Destination burst transaction size in bytes, see (5.4)
Block size in bytes:
GPDMA as flow controller: With the GPDMA as the flow controller, the processor
programs the GPDMA with the number of data items (block size) of source transfer
width (CTL.SRC_TR_WIDTH) to be transferred by the GPDMA in a block transfer;
this is programmed into the CTL.BLOCK_TS field. Therefore, the total number of
bytes to be transferred in a block is defined by (5.5)
src_single_size_bytes = CTLx.SRC_TR_WIDTH/8 (5.1)
src_burst_size_bytes = CTLx.SRC_MSIZE * src_single_size_bytes

(5.2)
dst_single_size_bytes = CTLx.DST_TR_WIDTH/8 (5.3)
dst_burst_size_bytes = CTLx.DEST_MSIZE * dst_single_size_bytes

(5.4)
blk_size_bytes_dma = CTLx.BLOCK_TS * src_single_size_bytes

(5.5)
Note: In the above equations, references to CTLx.SRC_MSIZE, CTLx.DEST_MSIZE,
CTLx.SRC_TR_WIDTH, and CTLx.DST_TR_WIDTH refer to the decoded values
of the parameters; for example, CTLx.SRC_MSIZE = 001B decodes to 4, and
CTLx.SRC_TR_WIDTH = 010B decodes to 32 bits.

XMC4500
XMC4000 Family
5.2.5 Memory Peripherals

Figure 5-3 shows the DMA transfer hierarchy of the GPDMA for a memory peripheral.
There is no handshaking interface with the GPDMA, and therefore the memory
peripheral can never be a flow controller. Once the channel is enabled, the transfer
proceeds immediately without waiting for a transaction request.
5.2.6 Software Handshaking

When the slave peripheral requires the GPDMA to perform a DMA transaction, it
communicates this request by sending a service request to the interrupt controller. The
interrupt service routine then uses the software registers, detailed in Section 5.6.4, to
initiate and control a DMA transaction. This group of software registers is used to
implement the software handshaking interface.
Peripheral GPDMA CPU
Interrupt
Figure 5-4 Software Controlled DMA Transfers

The HS_SEL_SRC/HS_SEL_DST bit in the CFG channel configuration register must be
set, to enable software handshaking.
Software Controlled DMA Transfers

Program and enable channel through Section 5.6.2
After interrupt, initiate and control DMA transaction between peripherals GPDMA
through Section 5.6.4
The software handshaking registers are:
REQSRCREG - source software transaction request
REQDSTREG - destination software transaction request
SGLREQSRCREG - single source transaction request
SGLREQDSTREG - single destination transaction request

XMC4500
XMC4000 Family
LSTSRCREG - last source transaction request

LSTDSTREG - last destination transaction request
5.2.7 Handshaking Interface

The GPDMA tries to efficiently transfer the data using as little of the bus bandwidth as
possible. Generally, the GPDMA tries to transfer the data using burst transactions and,
where possible, fill or empty the channel FIFO in single bursts - provided that the
software has not limited the burst length.
The GPDMA can also lock the arbitration for the master bus interface so that a channel
is permanently granted the master bus interface. Additionally, the GPDMA can assert the
lock signal to lock the system arbiter. For more information, refer to Section 5.2.11.1.
Before describing the handshaking interface operation, the following sections define the
terms "Single Transaction Region" and "Early-Terminated Burst Transaction."
5.2.7.1 Single Transaction Region

There are cases where a DMA block transfer cannot be completed using only burst
transactions. Typically this occurs when the block size is not a multiple of the burst
transaction length. In these cases, the block transfer uses burst transactions up to the
point where the amount of data left to complete the block is less than the amount of data
in a burst transaction. At this point, the GPDMA samples the "single" status flag and
completes the block transfer using single transactions.
The peripheral asserts a single status flag to indicate to the GPDMA that there is enough
data or space to complete a single transaction from or to the source/destination
peripheral.
Note: For hardware handshaking, the single status flag is a signal on the hardware
handshaking interface and handled automatically by the hardware (refer to
Section 5.2.7.3). For software handshaking, the single status flag is one of the
software handshaking interface registers (refer to Section 5.2.7.4).
The Single Transaction Region is the time interval where the GPDMA uses single
transactions to complete the block transfer (burst transactions are exclusively used
outside this region).
Note: Burst transactions can also be used in this region. For more information, refer to
Section 5.2.7.2.
Rules for entering Single Transaction Regions:

The source peripheral enters the Single Transaction Region when the number of
bytes left to complete in the source block transfer is less than
src_burst_size_bytes.

XMC4500
XMC4000 Family
If (5.6) is fulfilled then the source never enters this region, and the source block
uses only burst transactions.
The destination peripheral enters the Single Transaction Region when the number
of bytes left to complete in the destination block transfer is less than
dst_burst_size_bytes.
If (5.7) is fulfilled then the destination never enters this region, and the destination
block uses only burst transactions.
blk_size_bytes/src_burst_size_bytes = integer (5.6)
blk_size_bytes/dst_burst_size_bytes = integer
(5.7)
Note: The above conditions cause a peripheral to enter the Single Transaction Region.
When the peripheral is outside the Single Transaction Region, then the GPDMA
responds to only burst transaction requests.
5.2.7.2 Early-Terminated Burst Transaction

When a source or destination peripheral is in the Single Transaction Region, a burst
transaction can still be requested. However, src_burst_size_bytes/
dst_burst_size_bytes is greater than the number of bytes left to complete in the
source/destination block transfer at the time that the burst transaction is triggered. In this
case, the burst transaction is started and "early-terminated" at block completion without
transferring the programmed amount of data, that is, src_burst_size_bytes or
dst_burst_size_bytes, but only the amount required to complete the block transfer. An
Early-Terminated Burst Transaction occurs between the GPDMA and the peripheral only
when the peripheral is not the flow controller.
5.2.7.3 Hardware Handshaking

Figure 5-5 illustrates the hardware handshaking interface between a peripheral
(whether a destination or source) and the GPDMA.

XMC4500
XMC4000 Family
Program the channel
Peripheral DMA request GPDMA CPU
Figure 5-5 Hardware Handshaking Interface

The interface illustrated in Figure 5-5 is the simplified version of the hardware
handshaking interface. In this mode:
The interrupt line from the peripheral is tied to the dma request input.
The interrupt line from the peripheral is tied to the dma request line (programming the
DLR is needed), as shown in Figure 5-5.
The handshaking loop is as follows:
1. Peripheral generates an interrupt that asserts the dma request.
2. GPDMA completes the burst transaction and generates an end-of-burst transaction
interrupt, IntSrcTran/IntDstTran. Interrupts must be enabled and the transaction
complete interrupt unmasked.
3. The interrupt service routine clears the interrupt in the peripheral so that the dma
request is de-asserted.
5.2.7.4 Software Handshaking

When the peripheral is not the flow controller, then the last transaction registers -
LSTSRCREG and LSTDSTREG - are not used, and the values in these registers are
ignored.
Operation - Peripheral Not In Single Transaction Region

Writing a 1 to the REQSRCREG[x]/REQDSTREG[x] register is always interpreted as a
burst transaction request, where x is the channel number. However, in order for a burst
transaction request to start, software must write a 1 to the SGLREQSRCREG[x]/
SGLREQDSTREG[x] register.
You can write a 1 to the SGLREQSRCREG[x]/SGLREQDSTREG[x] and
REQSRCREG[x]/REQDSTREG[x] registers in any order, but both registers must be
asserted in order to initiate a burst transaction. Upon completion of the burst transaction,

XMC4500
XMC4000 Family
the hardware clears the SGLREQSRCREG[x]/SGLREQDSTREG[x] and

REQSRCREG[x]/ REQDSTREG[x] registers.
Operation - Peripheral In Single Transaction Region

Writing a 1 to the SGLREQSRCREG/SGLREQDSTREG initiates a single transaction.
Upon completion of the single transaction, both the
SGLREQSRCREG/SGLREQDSTREG and REQSRCREG/REQDSTREG bits are
cleared by hardware. Therefore, writing a 1 to the REQSRCREG/REQDSTREG is
ignored while a single transaction has been initiated, and the requested burst transaction
is not serviced.
Again, writing a 1 to the REQSRCREG/REQDSTREG register is always a burst
transaction request. However, in order for a burst transaction request to start, the
corresponding channel bit in the SGLREQSRCREG/SGLREQDSTREG must be
asserted. Therefore, to ensure that a burst transaction is serviced in this region, you
must write a 1 to the REQSRCREG/REQDSTREG before writing a 1 to the
SGLREQSRCREG/SGLREQDSTREG register. If the programming order is reversed, a
single transaction is started instead of a burst transaction. The hardware clears both the
REQSRCREG/REQDSTREG and the SGLREQSRCREG/SGLREQDSTREG registers
after the burst transaction request completes. When a burst transaction is initiated in the
Single Transaction Region, then the block completes using an Early-Terminated Burst
Transaction.
Software can poll the relevant channel bit in the SGLREQSRCREG/SGLREQDSTREG
and REQSRCREG/REQDSTREG registers. When both are 0, then either the requested
burst or single transaction has completed. Alternatively, the IntSrcTran or IntDstTran
interrupts can be enabled and unmasked in order to generate an interrupt when the
requested source or destination transaction has completed.
Note: The transaction-complete interrupts are triggered when both single and burst
transactions are complete. The same transaction-complete interrupt is used for
both single and burst transactions.
5.2.8 Single Transactions

Being the GPDMA the flow controller of the DMA transactions, a burst transaction can
always be performed if:
blk_size_bytes_dma/src_burst_size_bytes = integer
If that condition cannot be met, then a series of burst transactions followed by single
transactions is needed to complete the source/destination block transfer.

XMC4500
XMC4000 Family
5.2.9 Setting Up Transfers

Transfers are set up by programming fields of the CTL and CFG registers for that
channel. As shown in Figure 5-2, a single block is made up of numerous transactions -
single and burst - which are in turn composed of AHB transfers. A peripheral requests a
transaction through the DLR to the GPDMA (for more information, refer to
Section 5.2.3).
Table 5-3 lists the parameters that are investigated in the following examples. The
effects of these parameters on the flow of the block transfer are highlighted.
Table 5-3 Parameters Used in Transfer Examples

Parameter Description
CTLx.TT_FC Transfer type and flow control
CTLx.BLOCK_TS Block transfer size
CTLx.SRC_TR_WIDTH Source transfer width
CTLx.DST_TR_WIDTH Destination transfer width
CTLx.SRC_MSIZE Source burst transaction length
CTLx.DEST_MSIZE Destination burst transaction length
CFGx.MAX_ABRST Maximum AMBA burst length
CFGx.FIFO_MODE FIFO mode select
CFGx.FCMODE Flow-control mode
5.2.9.1 Transfer Operation

The following examples show the effect of different settings of each parameter from
Table 5-3 on a DMA block transfer. In all examples, it is assumed that no bursts are
early-terminated by the system arbiter, unless otherwise stated.
The GPDMA is programmed with the number of data items that are to be transferred for
each burst transaction request, CTL.SRC_MSIZE /CTL.DEST_MSIZE. Similarly, the
width of each data item in the transaction is set by the CTL.SRC_TR_WIDTH and
CTL.DST_TR_WIDTH fields.
Example 1
Scenario: Example block transfer when the GPDMA is the flow controller. This example
is the same for both software and hardware handshaking interfaces. Table 5-4 lists the
DMA parameters for this example (as an exemple the FIFO depth is taken as 16 bytes).

XMC4500
XMC4000 Family
Table 5-4 Parameters in Transfer Operation - Example 1

Parameter Description
CTLx.TT_FC = 011B Peripheral-to-peripheral transfer with
GPDMA as flow controller
CTLx.BLOCK_TS = 12 -
CTLx.SRC_TR_WI DTH = 010B 32 bits
CTLx. DST_TR_WI DTH = 010B 32 bits
CTLx.SRC_MSIZE = 001B Source burst transaction length = 4
CTLx.DEST_MSIZE = 001B Destination burst transaction length = 4
CFGx.MAX_ABRST = 0B No limit on maximum AMBA burst length
Using (5.5), a total of 48 bytes are transferred in the block (that is blk_size_bytes_dma
= 48). As shown in Figure 5-6, this block transfer consists of three bursts of length 4 from
the source, interleaved with three bursts, again of length 4, to the destination.
Figure 5-6 Breakdown of Block Transfer

The channel FIFO is alternatively filled by a burst from the source and emptied by a burst
to the destination until the block transfer has completed, as shown in Figure 5-7.

XMC4500
XMC4000 Family
D3 Empty D7 Empty D11 Empty

Time t1 Time t2 Time t3 Time t4 Time t5 Time t6
Figure 5-7 Channel FIFO Contents

Burst transactions are completed in one burst. Additionally, because (8) and (9) are both
true, neither the source or destination peripherals enter their Single Transaction Region
at any stage throughout the DMA transfer, and the block transfer from the source and to
the destination consists of burst transactions only.
Example 2
Scenario: Effect of the maximum AMBA burst length, CFGx.MAX_ABRST. This
example is the same for both software and hardware handshaking interfaces.
If the CFGx.MAX_ABRST = 2 parameter and all other parameters are left unchanged
from Example 1, Table 5-4, then the block transfer would look like that shown in
Figure 5-8.
Channel Fifo
32
Figure 5-8 Breakdown of Block Transfer where max_abrst = 2, Case 1

XMC4500
XMC4000 Family
The channel FIFO is alternatively half filled by a burst from the source, and then emptied
by a burst to the destination until the block transfer has completed; this is illustrated in
Figure 5-9.
D3 Empty D7 Empty Empty Empty

D2 Empty D6 Empty Empty Empty
...

In this example block transfer, each source or destination burst transaction is made up
of two bursts, each of length 2. As Figure 5-9 illustrates, the top two channel FIFO
locations are redundant for this block transfer. However, this is not the general case. The
block transfer could proceed as indicated in Figure 5-10.
Channel Fifo
32
Figure 5-10 Breakdown of Block Transfer where max_abrst = 2, Case 2

This depends on the timing of the source and destination transaction requests, relative
to each other. Figure 5-11 illustrates the channel FIFO status for Figure 5-10.

XMC4500
XMC4000 Family

Recommendation
To allow a burst transaction to complete in a single burst, the following should be true:
CFGx.MAX_ABRST >= max(src_burst_size_bytes,
dst_burst_size_bytes)
Adhering to the above recommendation results in a reduced number of bursts per block,
which in turn results in improved bus utilization and lower latency for block transfers.
Limiting a burst to a maximum length prevents the GPDMA from saturating the AHB bus
when the system arbiter is configured to only allow changing of the grant signals to bus
masters at the end of an undefined length burst. It also prevents a channel from
saturating a GPDMA master bus interface.
Example 3
Scenario: Source peripheral enters Single Transaction Region; the GPDMA is the flow
controller.
This example is the same for both hardware and software handshaking and
demonstrates how a block from the source can be completed using a series of single
transactions. It also demonstrates how the watermark level that triggers a burst request
in the source peripheral can be dynamically adjusted so that the block transfer from the
source completes with an Early-terminated Burst Transaction. Table 5-5 lists the
parameters used in this example (as an example the FIFO depth was considered as 16
bytes).

Parameter Comment

XMC4500
XMC4000 Family
Table 5-5 Parameters in Transfer Operation - Example 4 (contd)

Parameter Comment
In this case, CTL.BLOCK_TS is not a multiple of the source burst transaction length,
CTL.SRC_MSIZE, so near the end of a block transfer from the source, the amount of
data left to be transferred is less than src_burst_size_bytes.
In this example, the block size is a multiple of the destination burst transaction length:
blk_size_bytes_dma/dst_burst_size_bytes = 48/16 = integer
The destination block is made up of three burst transactions to the destination and does
not enter the Single Transaction Region.
The block size is not a multiple of the source burst transaction length:
blk_size_bytes_dma/src_burst_size_bytes = 48/32 != integer
Consider the case where the watermark level that triggers a source burst request in the
source peripheral is equal to CTL.SRC_MSIZE = 8; that is, eight entries or more need
to be in the source peripheral FIFO in order to trigger a burst request. Figure 5-12 shows
how this block transfer is broken into burst and single transactions, and bursts and single
transfers.

XMC4500
XMC4000 Family
Channel Fifo
32
Figure 5-12 Breakdown of Block Transfer

XMC4500
XMC4000 Family
Figure 5-13 shows the status of the source FIFO at various times throughout the source
block transfer.
Figure 5-13 Source FIFO Contents

As shown in Figure 5-14, if the GPDMA does not perform single transactions, the source
FIFO contains four entries at time t1. However, the source has no more data to send.
Therefore, if the watermark level remains at 8 (at time t1, Case A in Figure 5-14), the
watermark level is never reached and a new burst request is never triggered.
Figure 5-14 Source FIFO Contents where Watermark Level is Dynamically

Adjusted
The source peripheral, not knowing the length of a block and only able to request burst
transactions, sits and waits for the FIFO level to reach a watermark level before
requesting a new burst transaction request. This region, where the amount of data left to
transfer in the source block is less than src_burst_size_bytes, is known as the Single
Transaction Region.

XMC4500
XMC4000 Family
In the Single Transaction Region, the GPDMA performs single transactions from the
source peripheral until the source block transfer has completed. In this example, the
GPDMA completes the source block transfer using four single transactions from the
source.
Now consider Case B in Figure 5-14, where the source peripheral can dynamically
adjust the watermark level that triggers a burst transaction request near the end of a
block. After the first source burst transaction completes, the source peripheral
recognizes that it has only four data items left to complete in the block and adjusts the
FIFO watermark level that triggers a burst transaction to 4. This triggers a burst request,
and the block completes using a burst transaction. However, CTL.SRC_MSIZE = 8, and
there are only four data items left to transfer in the source block. The GPDMA terminates
the last source burst transaction early and fetches only four of the eight data items in the
last source burst transaction. This is called an Early-Terminated Burst Transaction.
Observation: Under certain conditions, it is possible to hardcode dma_single from the
source peripheral to an inactive level (hardware handshaking). Under the same
conditions, it is possible for software to complete a source block transfer without initiating
single transactions from the source. For more information, refer to Section 5.2.8.
Example 4
Scenario: The destination peripheral enters the Single Transaction Region while the
GPDMA is the flow controller. This example also demonstrates how the GPDMA channel
FIFO is flushed at the end of a block transfer to the destination; this example is the same
for both hardware and software handshaking.
Consider the case with the parameters set to values listed in Table 5-6 (as an example
the FIFO depth was considered as 32 bytes).

Parameter Comment
CTLx.TT_FC = 011B Peripheral-to-peripheral transfer with GPDMA
as flow controller
CTLx.SRC_TR_WI DTH = 000B 8 bit
CTLx. DST_TR_WI DTH = 011B 64bit

XMC4500
XMC4000 Family
In this example, the block size is a multiple of the source burst transaction length:
blk_size_bytes_dma/src_burst_size_bytes = (44 * 1)/4 = 11
= integer
The source block transfer is completed using only burst transactions, and the source
does not enter the Single Transaction Region.
The block size is not a multiple of the destination burst transaction length:
blk_size_bytes_dma/dst_burst_size_bytes 44/32 != integer
So near the end of the block transfer to the destination, the amount of data left to be
transferred is less than dst_burst_size_bytes and the destination enters the Single
Transaction Region.
Figure 5-15 shows one way in which the block transfer to the destination can occur.
Figure 5-15 Block Transfer to Destination

After the first 32 bytes (dst_burst_size_bytes = 32) of the destination burst transaction
have been transferred to the destination, there are 12 bytes (blk_size_bytes_dma -
dst_burst_size_bytes = 44 - 32) left to transfer. This is less then the amount of data that
is transferred in a destination burst (dst_burst_size_bytes = 32). Therefore, the
destination peripheral enters the Single Transaction Region where the GPDMA can
complete a block transfer to the destination using single transactions.
Notes
1. In the Single Transaction Region, asserting dma_single initiates a single transaction
for hardware handshaking. Writing a 1 to the relevant channel bit of the
SGLREQDSTREG register initiates a single transaction for software handshaking.
2. The destination peripheral, not knowing the length of a block and only able to request
burst transactions, sits and waits for the FIFO to fall below a watermark level before
requesting a new burst transaction request.

XMC4500
XMC4000 Family
At time t2 in Figure 5-15, a single transaction to the destination has been completed.
There are now only four bytes (12 - dst_single_size_bytes = 12 - 8) left to transfer in the
destination block. However, CTL.DST_TR_WIDTH implies 64-bit AHB transfers to the
destination (dst_single_size_bytes = 8 byte); therefore, the GPDMA cannot form a single
word of the specified CTL.DST_TR_WIDTH.
The GPDMA channel FIFO has four bytes in it that must be flushed to the destination.
The GPDMA switches into a "FIFO flush mode, where the block transfer to the
destination is completed by changing the AHB transfer width to the destination to be
equal to that of the CTL.SRC_TR_WIDTH; that is, byte AHB transfers in this example.
Thus the last single transaction in the destination block is made up of a burst of length 4
and CTL.SRC_TR_WIDTH width.
When the GPDMA is in FIFO flush mode, the address is incremented by the value of
CTL.SRC_TR_WIDTH and not CTL.DST_TR_WIDTH.
In cases where the DAR is selected to be contiguous between blocks, the DARx will
need re-alignment at the start of the next block, since it is aligned to
CTL.SRC_TR_WIDTH and not CTL.DST_TR_WIDTH at the end of the previous block
(this is handled by hardware).
In general, channel FIFO flushing to the destination occurs if all three of the following are
true:
GPDMA or the Source peripheral are flow control peripherals
CTL.DST_TR_WIDTH > CTL.SRC_TR_WIDTH
Flow control device:
If GPDMA is flow controller:
blk_size_bytes_dma/dst_single_size_bytes != integer
If source is flow controller:
blk_size_bytes_src /dst_single_size_bytes != integer
Note: When not in FIFO flush mode, a single transaction is mapped to a single AHB
transfer. However, in FIFO flush mode, a single transaction is mapped to multiple
AHB transfers of CTLx.SRC_TR_WIDTH width. The cumulative total of data
transferred to the destination in FIFO flush mode is less than
dst_single_size_bytes.
In the above example, a burst request is not generated in the Single Transaction Region.
If a burst request were generated at time t1 in Figure 5-15, then the burst transaction
would proceed until there was not enough data left in the destination block to form a
single data item of CTL.DST_TR_WIDTH width. The burst transaction would then be
early-terminated. In this example, only one data item of the four requested (decoded
value of DEST_MIZE = 4) would be transferred to the destination in the burst transaction.
This is referred to as an Early-Terminated Burst Transaction. If a burst request were
generated at time t2 in Figure 5-15, then the destination block would be completed (four
byte transfers to the destination to flush the GPDMA channel FIFO) and this burst
request would again be early-terminated at the end of the destination block.

XMC4500
XMC4000 Family
Observation: If the source transfer width - CTL.SRC_TR_WIDTH in the channel control

register (CTL) - is less than the destination transfer width (CTL.DST_TR_WIDTH), then
the FIFO may need to be flushed at the end of the block transfer. This is done by setting
the AHB transfer width of the last few AHB transfers of the block to the destination so
that it is equal to CTL.SRC_TR_WIDTH and not the programmed
CTL.DST_TR_WIDTH.
Example 5
Scenario: In all examples presented so far, none of the bursts have been early-
terminated by the system arbiter. Referring to Example 1, the AHB transfers on the
source and destination side look somewhat symmetric. In the examples presented so
far, where the bursts are not early-terminated by the system arbiter, the traffic profile on
the AHB bus would be the same, regardless of the value of CFGx.FIFO_MODE.
This example, however, considers the effect of CFGx.FIFO_MODE; it is the same for
both hardware and software handshaking.
CFGx.FIFO_MODE: Determines how much space or data needs to be available in the
FIFO before a burst transaction request is serviced.
0B - Space/data available for single AHB transfer of the specified transfer width.
1B - Data available is greater than or equal to half the FIFO depth for destination transfers
and space available is greater than half the fifo depth for source transfers. The
exceptions are at the end of a burst transaction request or at the end of a block transfer.

XMC4500
XMC4000 Family
Table 5-7 lists the parameters used in this example (as an example the FIFO depth was
considered as 16 bytes).

Parameter Comment
CTLx.SRC_MSIZE = 010B Decoded value = 8
CTLx.DEST_MSIZE = 001B Decoded value = 4

XMC4500
XMC4000 Family
The block transfer may proceed by alternately filling and emptying the GPDMA channel
FIFO. Up to time t4, the transfer might proceed like that shown in Figure 5-16.
Figure 5-16 Block Transfer Up to Time "t4"

XMC4500
XMC4000 Family
At time t4, the src, channel, and destination FIFOs might look like that shown in
Figure 5-17
Figure 5-17 Source, GPDMA Channel and Destination FIFOs at Time 't4'
At time t4, a source burst transaction is requested, and the GPDMA attempts a burst of
length 4. Suppose that this burst is early-burst terminated after three AHB transfers. The
FIFO status after this burst might look like that shown in Figure 5-18.
Referring to Figure 5-18, notice that a burst request from the destination is not triggered,
since the destination FIFO contents are above the watermark level. The GPDMA has
space for one data item in the channel FIFO.
The GPDMA will attempt to perform a single transfer, to fill the channel FIFO, if
CFGx.FIFO_MODE = 0.
If CFGx.FIFO_MODE = 1, then the GPDMA waits until the channel FIFO is less than
half-full before initiating a burst from the source, as illustrated in Figure 5-18.

XMC4500
XMC4000 Family
Figure 5-18 FIFO Status After Early-Terminated Burst

Observation: When CFGx.FIFO_MODE = 1, the number of bursts per block is less than
when CFGx.FIFO_MODE = 0, hence, the bus utilization will improve. This setting favors
longer bursts. However, the latency of DMA transfers may increase when
CFGx.FIFO_MODE = 1, since the GPDMA waits for the channel FIFO contents to be
less than half the FIFO depth for source transfers, or greater than or equal to half the
FIFO depth for destination transfers. Therefore, system bus occupancy and usage can
be improved by delaying the servicing of multiple requests until there is sufficient
data/space available in the FIFO to generate a burst (rather than multiple single AHB
transfers); this comes at the expense of transfer latency. For reduced block transfer
latency, set CFGx.FIFO_MODE = 0. For improved bus utilization, set
CFGx.FIFO_MODE = 1.
5.2.10 Flow Control Configurations

Figure 5-19 indicates three different flow control configurations using hardware
handshaking interfaces - a simplified version of the interface is shown. These scenarios
can also be used for software handshaking, which uses software registers instead of
signals.

XMC4500
XMC4000 Family
Flow Control by the DMA
Memory
Channel
control
CPU Block size
register
GPDMA
(CTLx)
Memory
Memory
Channel
control
CPU Block size
register
GPDMA
(CTLx)
finish Peripheral 1
finish Peripheral 1
Channel
control
CPU Block size
register
GPDMA
(CTLx)
finish Peripheral 2
Figure 5-19 Flow Control Configurations
5.2.11 Generating Requests for the AHB Master Bus Interface

Each channel has a source state machine and destination state machine running in
parallel. These state machines generate the request inputs to the arbiter, which
arbitrates for the master bus interface (one arbiter per master bus interface).
When the source/destination state machine is granted control of the master bus
interface, and when the master bus interface is granted control of the external AHB bus,
then AHB transfers between the peripheral and the GPDMA (on behalf of the granted
state machine) can take place.
AHB transfers from the source peripheral or to the destination peripheral cannot proceed
until the channel FIFO is ready. For burst transaction requests and for transfers involving

XMC4500
XMC4000 Family
memory peripherals, the criterion for "FIFO readiness" is controlled by the FIFO_MODE
field of the CFG register.
The definition of FIFO readiness is the same for:
Single transactions
Burst transactions, where CFGx.FIFO_MODE = 0
Transfers involving memory peripherals, where CFGx.FIFO_MODE = 0
The channel FIFO is deemed ready when the space/data available is sufficient to
complete a single AHB transfer of the specified transfer width. FIFO readiness for source
transfers occurs when the channel FIFO contains enough room to accept at least a
single transfer of CTL.SRC_TR_WIDTH width. FIFO readiness for destination transfers
occurs when the channel FIFO contains data to form at least a single transfer of
CTL.DST_TR_WIDTH width.
Note: An exception to FIFO readiness for destination transfers occurs in "FIFO flush
mode" In this mode, FIFO readiness for destination transfers occurs when the
channel FIFO contains data to form at least a single transfer of
CTL.SRC_TR_WIDTH width (and not CTL.DST_TR_WIDTH width, as is the
normal case).
When CFG.FIFO_MODE = 1, then the criteria for FIFO readiness for burst transaction
requests and transfers involving memory peripherals are as follows:
A FIFO is ready for a source burst transfer when the FIFO is less than half empty.
A FIFO is ready for a destination burst transfer when the FIFO is greater than or equal
to half full.
Exceptions to this "readiness" occur. During these exceptions, a value of CTL.
FIFO_MODE = 0 is assumed. The following are the exceptions:
Near the end of a burst transaction or block transfer - The channel source state
machine does not wait for the channel FIFO to be less than half empty if the number
of source data items left to complete the source burst transaction or source block
transfer is less than FIFO DEPTH/2. Similarly, the channel destination state machine
does not wait for the channel FIFO to be greater than or equal to half full, if the
number of destination data items left to complete the destination burst transaction or
destination block transfer is less than FIFO DEPTH/2.
In FIFO flush mode
When a channel is suspended - The destination state machine does not wait for the
FIFO to become half empty to flush the FIFO, regardless of the value of the
FIFO_MODE field.
When the source/destination peripheral is not memory, the source/destination state
machine waits for a single/burst transaction request. Upon receipt of a transaction
request and only if the channel FIFO is "ready" for source/destination AHB transfers, a
request for the master bus interface is made by the source/destination state machine.

XMC4500
XMC4000 Family
Note: There is one exception to this, which occurs when the destination peripheral is the
flow controller and CFGx.FCMODE = 1 (data pre-fetching is disabled). Then the
source state machine does not generate a request for the master bus interface
(even if the FIFO is "ready" for source transfers and has received a source
transaction request) until the destination requests new data.
When the source/destination peripheral is memory, the source/destination state
machine must wait until the channel FIFO is "ready". A request is then made for the
master bus interface. There is no handshaking mechanism employed between a
memory peripheral and the GPDMA.
5.2.11.1 Locked DMA Transfers

It is possible to program the GPDMA for:
Bus locking
Channel locking - Locks the arbitration for the AHB master interface, which grants
ownership of the master bus interface to one of the requesting channel state
machines (source or destination).
Bus and channel locking can proceed for the duration of a DMA transfer, a block transfer,
or a single or burst transaction.
Bus Locking
If the LOCK_B bit in the channel configuration register (CFG) is set, then the AHB bus is
locked for the duration specified in the LOCK_B_L field.
Channel Locking
If the LOCK_CH field is set, then the arbitration for the master bus interface is exclusively
reserved for the source and destination peripherals of that channel for the duration
specified in the LOCK_CH_L field.
If bus locking is activated for a certain duration, then it follows that the channel is also
automatically locked for that duration. Three cases arise:
CFGx.LOCK_B = 0 - Programmed values of CFGx.LOCK_CH and
CFGx.LOCK_CH_L are used.
CFGx.LOCK_B = 1 and CFGx.LOCK_CH = 0 - DMA transfer proceeds as if
CFGx.LOCK_CH = 1 and CFGx.LOCK_CH_L = CFGx.LOCK_B_L. The
programmed values of CFGx.LOCK_CH and CFGx.LOCK_CH_L are ignored.
CFGx.LOCK_B = 1 and CFGx.LOCK_CH = 1 - Two cases arise:
CFGx.LOCK_B_L <= CFGx.LOCK_CH_L - In this case, the DMA transfer
proceeds as if CFGx.LOCK_CH_L = CFGx. LOCK_B_L and the programmed
value of CFGx.LOCK_CH_L is ignored. Thus, if bus locking is enabled over the
DMA transfer level, then channel locking is enabled over the DMA transfer level,
regardless of the programmed value of CFGx.LOCK_CH_LCFGx.

XMC4500
XMC4000 Family
LOCK_B_L > CFGx.LOCK_CH_L - The programmed value of CFGx.LOCK_CH_L

is used. Thus, if bus locking is enabled over the DMA block transfer level and
channel locking is enabled over the DMA transfer level, then channel locking is
performed over the DMA transfer level.
Locking Levels
If locking is enabled for a channel, then locking of the AHB master bus interface at a
programmed locking transfer level is activated when the channel is first granted the AHB
master bus interface at the start of that locking transfer level. It continues until the locking
transfer level has completed; that is, if channel 0 has enabled channel level locking at
the block transfer level, then this channel locks the master bus interface when it is first
granted the master bus interface at the start of the block transfer, and continues to lock
the master bus interface until the block transfer has completed.
Source and destination block transfers occur successively in time, and a new source
block cannot commence until the previous destination block has completed.
When both source and destination are on the same AHB layer, then block level locking
is terminated on completion of the block to the destination. If they are on separate layers,
then block-level locking is terminated on completion of the block on that layerwhen the
source block on the source AHB layer completes, and when the destination block on the
destination AHB layer completes. The same is true for DMA transfer-level locking.
Transaction-level locking is different due to the fact that source and destination
transactions occur independently in time, and the number of source and destination
transactions in a DMA block or DMA transfer do not have to match. When the source and
destination are on the same AHB layer, then transaction-level locking is cleared at the
end of a source or destination transaction only if the opposing peripheral is not currently
in the middle of a transaction.
For example, if locking is enabled at the transaction level and an end-of-source
transaction is signaled, then this disables locking only if one of the following is true:
The destination is on a different AHB layer
The destination is on the same AHB layer, but the channel is not currently in the
middle of a transaction to the destination peripheral.
The same rules apply when an end-of-destination transaction is signalled.
If channel-level or bus-level locking is enabled for a channel at the transaction level, and
either the source or destination of the channel is a memory device, then the locking is
ignored and the channel proceeds as if locking (bus or channel) is disabled.
Note: Since there is no notion of a transaction level for a memory peripheral, then
transaction-level locking is not allowed when either source or destination is
memory.

XMC4500
XMC4000 Family
5.2.12 Arbitration for AHB Master Interface

Each GPDMA channel has two request lines that request ownership of a particular
master bus interface: channel source and channel destination request lines.
Source and destination arbitrate separately for the bus. Once a source/destination state
machine gains ownership of the master bus interface and the master bus interface has
ownership of the AHB bus, then AHB transfers can proceed between the peripheral and
GPDMA. Figure 5-20 illustrates the arbitration flow of the master bus interface.
An arbitration scheme decides which of the request lines is granted the particular master
bus interface. Each channel has a programmable priority. A request for the master bus
interface can be made at any time, but is granted only after the current AHB transfer
(burst or single) has completed. Therefore, if the master interface is transferring data for
a lower priority channel and a higher priority channel requests service, then the master
interface will complete the current burst for the lower priority channel before switching to
transfer data for the higher priority channel.
To prevent a channel from saturating the master bus interface, it can be given a
maximum AMBA burst length (MAX_ABRST field in CFG register) at channel setup time.
This also prevents the master bus interface from saturating the AHB bus where the
system arbiter cannot change the grant lines until the end of an undefined length burst.
The following is the interface arbitration scheme employed when no channel has locked
the arbitration for the master bus interface:
If only one request line is active at the highest priority level, then the request with the
highest priority wins ownership of the AHB master bus interface; it is not necessary
for the priority levels to be unique.
If more than one request is active at the highest requesting priority, then these
competing requests proceed to a second tier of arbitration.
If equal priority requests occur, then the lower-numbered channel is granted.
In other words, if a peripheral request attached to Channel 7 and a peripheral request
attached to Channel 8 have the same priority, then the peripheral attached to
Channel 7 is granted first.
Note: A channel source is granted before the destination if both have their request lines
asserted when a grant decision is made. A channel source and channel
destination inherit their channel priority and therefore always have the same
priority.

XMC4500
XMC4000 Family
Request = 0
IDLE
Request = 1
Arbiter Locked by this Yes

channel?
No
Transfer in progress?
Yes
Transfer complete
No
Arbiter locked by Yes

different channel?
No
Highest priority channel?

No
Yes
Lowest numbered No
highest priority request?
Yes
Transfer incomplete
Granted Master
Interface
Figure 5-20 Arbitration Flow for Master Bus Interface

XMC4500
XMC4000 Family
5.2.13 Scatter/Gather
Scatter is relevant to a destination transfer. The destination address is incremented or
decremented by a programmed amount - the scatter increment - when a scatter
boundary is reached. Figure 5-21 shows an example destination scatter transfer. The
destination address is incremented or decremented by the value stored in the destination
scatter increment (DSRx.DSI) field (refer to DSR), multiplied by the number of bytes in
a single AHB transfer to the destination s (decoded value of CTL.DST_TR_WIDTH)/8 -
when a scatter boundary is reached. The number of destination transfers between
successive scatter boundaries is programmed into the Destination Scatter Count (DSC)
field of the DSRx register.
Scatter is enabled by writing a 1 to the CTL.DST_SCATTER_EN field. The CTL.DINC
field determines if the address is incremented, decremented, or remains fixed when a
scatter boundary is reached. If the CTL.DINC field indicates a fixed-address control
throughout a DMA transfer, then the CTL.DST_SCATTER_EN field is ignored, and the
scatter feature is automatically disabled.
Gather is relevant to a source transfer. The source address is incremented or
decremented by a programmed amount when a gather boundary is reached. The
number of source transfers between successive gather boundaries is programmed into
the Source Gather Count (SGRx.SGC) field. The source address is incremented or
decremented by the value stored in the source gather increment (SGRx.SGI) field (refer
to SGR), multiplied by the number of bytes in a single AHB transfer from the source -
(decoded value of CTL.SRC_TR_WIDTH)/8 - when a gather boundary is reached.
Gather is enabled by writing a 1 to the CTL.SRC_GATHER_EN field. The CTL.SINC
field determines if the address is incremented, decremented, or remains fixed when a
gather boundary is reached. If the CTL.SINC field indicates a fixed-address control
throughout a DMA transfer, then the CTL.SRC_GATHER_EN field is ignored, and the
gather feature is automatically disabled.
Note: For multi-block transfers, the counters that keep track of the number of transfers
left to reach a gather/scatter boundary are re-initialized to the source gather count
(SGRx.SGC) and destination scatter count (DSC), respectively, at the start of
each block transfer.

XMC4500
XMC4000 Family
Figure 5-21 Example of Destination Scatter Transfer

As an example of gather increment, consider the following:
SRC_TR_WIDTH = 3'b010 (32 bits)
SGR.SGC = 0x04 (source gather count)
CTLx.SRC_GATHER_EN = 1 (source gather enabled)
SARx = A0 (starting source address)

XMC4500
XMC4000 Family
Figure 5-22 Source Gather when SGR.SGI = 0x1

In general, if the starting address is A0 and CTL.SINC = 00B (increment source address
control), then the transfer will be:
A0, AO + TWB, A0 + 2*TWB (A0 + (SGR.SGC-1)*TWB)
<-scatter_increment-> (A0 + (SGR.SGC*TWB) + (SGR.SGI *TWB))
where TWB is the transfer width in bytes, decoded value of CTL.SRC_TR_WIDTH/8 =
src_single_size_bytes.

XMC4500
XMC4000 Family
5.3 Programming
The GPDMA can be programmed through software registers or the GPDMA low-level
software driver; software registers are described in more detail in Section 5.6.
Note: There are references to both software parameters throughout this chapter. The
software parameters are the field names in each register description table and are
prefixed by the register name; for example, the Block Transfer Size field in the
Control Register for Channel x is designated as "CTL.BLOCK_TS."
5.3.1 Illegal Register Access

An illegal access can be any of the following:
1. A write to the SAR, DAR, LLP, CTL, SSTAT, DSTAT, SSTATAR, DSTATAR, SGR,
or DSR registers occurs when the channel is enabled.
2. A read from the Interrupt Clear Registers is attempted.
3. A write to the Interrupt Status Registers, GPDMA0_STATUSINT, ID or VERSION is
attempted.
An illegal access (read/write) returns an AHB error response.
5.3.2 GPDMA Transfer Types

A DMA transfer may consist of
single block transfer, supported by all channels.
multi-block transfers, supported by channels 0 and 1.
On successive blocks of a multi-block transfer, the SAR/DAR register in the GPDMA is
reprogrammed using either of the following methods:
Block chaining using linked lists
Auto-reloading
Contiguous address between blocks
On successive blocks of a multi-block transfer, the CTL register in the GPDMA is
reprogrammed using either of the following methods:
Block chaining using linked lists
Auto-reloading
When block chaining, using Linked Lists is the multi-block method of choice. On
successive blocks, the LLP register in the GPDMA is reprogrammed using block
chaining with linked lists.
A block descriptor consists of six registers: SAR, DAR, LLP, CTL, SSTAT and DSTAT.
The first four registers, along with the CFG register, are used by the GPDMA to set up
and describe the block transfer.
Note: The term Link List Item (LLI) and block descriptor are synonymous.

XMC4500
XMC4000 Family
5.3.2.1 Multi-Block Transfers

Multi-block transfersin which the source and destination are swapped during the
transferare not supported. In a multi-block transfer, the direction must not change for
the duration of the transfer.
Block Chaining Using Linked Lists

In this case, the GPDMA reprograms the channel registers prior to the start of each block
by fetching the block descriptor for that block from system memory. This is known as an
LLI update.
GPDMA block chaining uses a Linked List Pointer register (LLP) that stores the address
in memory of the next linked list item. Each LLI contains the corresponding block
descriptors:
1. SAR
2. DAR
3. LLP
4. CTL
5. SSTAT
6. DSTAT
To set up block chaining, you program a sequence of Linked Lists in memory.
LLI accesses are always 32-bit accesses aligned to 32-bit boundaries and cannot be
changed or programmed to anything other than 32-bit, even if the AHB master interface
of the LLI supports more than a 32-bit data width.
The SAR, DAR, LLP, and CTL registers are fetched from system memory on an LLI
update. The updated contents of the CTL, SSTAT, and DSTAT registers are optionally
written back to memory on block completion. Figure 5-23 and Figure 5-24 show how
you use chained linked lists in memory to define multi-block transfers using block
chaining.
Figure 5-23 Multi-Block Transfer Using Linked Lists When CFGx.SS_UPD_EN is

set to 1

XMC4500
XMC4000 Family
It is assumed that no allocation is made in system memory for the source status when
the parameter CFGx.SS_UPD_EN is set to 0. In this case, then the order of a Linked
List item is as follows:
1. SAR
2. DAR
3. LLP
4. CTL
5. DSTAT
Figure 5-24 Multi-Block Transfer Using Linked Lists When CFGx.SS_UPD_EN is

set to 0
Note: In order to not confuse the SAR, DAR, LLP, CTL, SSTAT and DSTAT register
locations of the LLI with the corresponding GPDMA memory mapped register
locations, the LLI register locations are prefixed with LLI; that is, LLI.SARx,
LLI.DARx, LLI.LLPx, LLI.CTLx, LLI.SSTATx, and LLI.DSTATx.
Figure 5-23 and Figure 5-24 show the mapping of a Linked List Item stored in memory
to the channel registers block descriptor.
Rows 6 through 10 of Table 5-8 show the required values of LLPx, CTLx, and CFGx for
multi-block DMA transfers using block chaining.
Note: For rows 6 through 10 of Table 5-8, the LLI.CTLx, LLI.LLPx, LLI.SARx, and
LLI.DARx register locations of the LLI are always affected at the start of every
block transfer. The LLI.LLPx and LLI.CTLx locations are always used to
reprogram the GPDMA LLPx and CTLx registers. However, depending on the
Table 5-8 row number, the LLI.SARx/LLI.DARx address may or may not be used
to reprogram the GPDMA SARx/DARx registers.

XMC4500
XMC4000 Family
Table 5-8 Programming of Transfer Types and Channel Register Update

Method
CFGx.RELOAD_SRC
CFGx.RELOAD_DST
CTLx.LLP_ SRC EN
CTLx.LLPDST_EN
UpdateMethod
UpdateMethod
UpdateMethod
Transfer Type
LLP. LOC = 0
Write Back1)
CTLx, LLPx
DARx
SARx
1. Single-block or Yes 0 0 0 0 None, user None None No
last transfer of reprograms (single) (single)
multi-block.
2. Auto-reload Yes 0 0 0 1 CTLx, LLPx are Contig Auto- No
multi-block reloaded from uous Reload
transfer with initial values.
contiguous SAR
3. Auto-reload Yes 0 1 0 0 CTLx, LLPx are Auto- Contig No
multi-block reloaded from Reload uous
transfer with initial values
contiguous DAR.
4. Auto-reload Yes 0 1 0 1 CTLx, LLPx are Auto- Auto- No
multi-block reloaded from reload Reload
transfer initial values
5. Single-block or No 0 0 0 0 None, user None None Yes
last transfer of reprograms (single) (single)
multi-block.
6. Linked list No 0 0 1 0 CTLx, LLPx Contig Linked Yes
multi-block loaded from uous List
transfer with next Linked List
contiguous SAR item.
7. Linked list No 0 1 1 0 CTLx, LLPx Auto- Linked Yes
multi-block loaded from Reload List
auto-reload SAR item.
8. Linked list No 1 0 0 0 CTLx, LLPx Linked Contig Yes
multi-block loaded from List uous
contiguous DAR item.

XMC4500
XMC4000 Family
Table 5-8 Programming of Transfer Types and Channel Register Update

Method (contd)
CFGx.RELOAD_SRC
CFGx.RELOAD_DST
CTLx.LLP_ SRC EN
CTLx.LLPDST_EN
UpdateMethod
UpdateMethod
UpdateMethod
Transfer Type
LLP. LOC = 0
Write Back1)
CTLx, LLPx
DARx
SARx
9. Linked list No 1 0 0 1 CTLx, LLPx Linked Auto- Yes
multi-block loaded from List Reload
auto-reload DAR item.
10. Linked list No 1 0 1 0 CTLx, LLPx Linked Linked Yes
multi-block loaded from List List
transfer next Linked List
item.
1) Applicable to channels 0 and 1 only.
Figure 5-25 Mapping of Block Descriptor (LLI) in Memory to Channel Registers

When CFG.SS_UPD_EN = 1

XMC4500
XMC4000 Family
Figure 5-26 Mapping of Block Descriptor (LLI) in Memory to Channel Registers

When CFG.SS_UPD_EN = 0
Notes
1. Throughout this chapter, there are descriptions about fetching the LLI.CTLx register
from the location pointed to by the LLPx register. This exact location is the LLI base
address (stored in LLPx register) plus the fixed offset. For example, in Figure 5-25
the location of the LLI.CTLx register is LLPx.LOC + 0xc.
2. Referring to Table 5-8, if the Write Back column entry is "Yes" and the channel is 0
or 1, then the CTLxH register is always written to system memory (to LLI.CTLxH) at
the end of every block transfer.
3. The source status is fetched and written to system memory at the end of every block
transfer if the Write Back column entry is "Yes" and CFGx.SS_UPD_EN is enabled.
4. The destination status is fetched and written to system memory at the end of every
block transfer if the Write Back column entry is "Yes and CFGx.DS_UPD_EN is
enabled.
5.3.2.2 Auto-Reloading of Channel Registers

During auto-reloading, the channel registers are reloaded with their initial values at the
completion of each block and the new values used for the new block. Depending on the
row number in Table 5-8, some or all of the SARx, DARx, and CTLx channel registers
are reloaded from their initial value at the start of a block transfer.
5.3.2.3 Contiguous Address Between Blocks

In this case, the address between successive blocks is selected as a continuation from
the end of the previous block.
Enabling the source or destination address to be contiguous between blocks is a function
of the CTL.LLP_SRC_EN, CFG.RELOAD_SRC, CTL.LLP_DST_EN, and
CTL.RELOAD_DST registers (see Table 5-8).

XMC4500
XMC4000 Family
Note: You cannot select both SARx and DARx updates to be contiguous. If you want this
functionality, you should increase the size of the Block Transfer
(CTL.BLOCK_TS), or if this is at the maximum value, use Row 10 of Table 5-8
and set up the LLI.SARx address of the block descriptor to be equal to the end
SARx address of the previous block. Similarly, set up the LLI.DARx address of the
block descriptor to be equal to the end DARx address of the previous block.
5.3.2.4 Suspension of Transfers Between Blocks

At the end of every block transfer, an end-of-block interrupt is asserted if:
1. Interrupts are enabled, CTL.INT_EN = 1, and
2. The channel block interrupt is unmasked, MASKBLOCK[n] = 1, where n is the
channel number.
Note: The block-complete interrupt is generated at the completion of the block transfer
to the destination.
For rows 6, 8, and 10 of Table 5-8, the DMA transfer does not stall between block
transfers. For example, at the end-of-block N, the GPDMA automatically proceeds to
block N + 1.
For rows 2, 3, 4, 7, and 9 of Table 5-8 (SARx and/or DARx auto-reloaded between block
transfers), the DMA transfer automatically stalls after the end-of-block interrupt is
asserted, if the end-of-block interrupt is enabled and unmasked.
The GPDMA does not proceed to the next block transfer until a write to the
CLEARBLOCK[n] block interrupt clear register, done by software to clear the channel
block-complete interrupt, is detected by hardware.
For rows 2, 3, 4, 7, and 9 of Table 5-8 (SARx and/or DARx auto-reloaded between block
transfers), the DMA transfer does not stall if either:
Interrupts are disabled, CTL.INT_EN = 0, or
The channel block interrupt is masked, MASKBLOCK[n] = 0, where n is the channel
number.
Channel suspension between blocks is used to ensure that the end-of-block ISR
(interrupt service routine) of the next-to-last block is serviced before the start of the final
block commences. This ensures that the ISR has cleared the CFG.RELOAD_SRC
and/or CFG.RELOAD_DST bits before completion of the final block. The reload bits
CFG.RELOAD_SRC and/or CFG.RELOAD_DST should be cleared in the end-of-block
ISR for the next-to-last block transfer.

XMC4500
XMC4000 Family
5.3.2.5 Ending Multi-Block Transfers

All multi-block transfers must end as shown in either Row 1 or Row 5 of Table 5-8. At
the end of every block transfer, the GPDMA samples the row number, and if the GPDMA
is in the Row 1 or Row 5 state, then the previous block transferred was the last block and
the DMA transfer is terminated.
Note: Row 1 and Row 5 are used for single-block transfers or terminating multi-block
transfers. Ending in the Row 5 state enables status fetch and write-back for the
last block. Ending in the Row 1 state disables status fetch and write-back for the
last block.
For rows 2, 3, and 4 of Table 5-8, (LLPx.LOC = 0 and CFG.RELOAD_SRC and/or
CFG.RELOAD_DST is set), multi-block DMA transfers continue until both the
CFG.RELOAD_SRC and CFG.RELOAD_DST registers are cleared by software. They
should be programmed to 0 in the end-of-block interrupt service routine that services the
next-to-last block transfer; this puts the GPDMA into the Row 1 state.
For rows 6, 8, and 10 of Table 5-8 (both CFG.RELOAD_SRC and CFG.RELOAD_DST
cleared), the user must set up the last block descriptor in memory so that both
LLI.CTLx.LLP_SRC_EN and LLI.CTLx.LLP_DST_EN are 0. If the LLI.LLPx register of
the last block descriptor in memory is non-zero, then the DMA transfer is terminated in
Row 5. If the LLI.LLPx register of the last block descriptor in memory is 0, then the DMA
transfer is terminated in Row 1.
Note: The only allowed transitions between the rows of Table 5-8 are from any row into
Row 1 or Row 5. As already stated, a transition into row 1 or row 5 is used to
terminate the DMA transfer; all other transitions between rows are not allowed.
Software must ensure that illegal transitions between rows do not occur between
blocks of a multi-block transfer. For example, if block N is in row 10, then the only
allowed rows for block N +1 are rows 10, 5, or 1.
5.3.3 Programing Examples

Three registers - LLP, CTL, and CFG - need to be programmed to determine whether
single- or multi-block transfers occur, and which type of multi-block transfer is used. The
different transfer types are shown in Table 5-8.
The GPDMA can be programmed to fetch the status from the source or destination
peripheral; this status is stored in the SSTAT and DSTAT registers. When the GPDMA
is programmed to fetch the status from the source or destination peripheral, it writes this
status and the contents of the CTL register back to memory at the end of a block transfer.
The Write Back column of Table 5-8 shows when this occurs.
The "Update Method" columns indicate where the values of SAR, DAR, CTL, and LLP
are obtained for the next block transfer when multi-block GPDMA transfers are enabled.

XMC4500
XMC4000 Family
Note: In Table 5-8, all other combinations of LLPx.LOC = 0, CTL.LLP_SRC_EN,

CFGx.RELOAD_SRC, CTL.LLP_DST_EN, and CFGx.RELOAD_DST are illegal,
and will cause indeterminate or erroneous behavior.
Generic Setup of Transfer Type and Characteristics

This generic sequence is referenced by the examples further below in this section.
1. Set up the transfer type (memory or non-memory peripheral for source and
destination) and flow control device by programming the TT_FC of the CTL register.
Table 5-13 lists the decoding for this field.
2. Set up the transfer characteristics, such as:
a) Transfer width for the source in the SRC_TR_WIDTH field.
b) Transfer width for the destination in the DST_TR_WIDTH field.
c) Source master layer in the SMS field where the source resides.
d) Destination master layer in the DMS field where the destination resides.
e) Incrementing/decrementing or fixed address for the source in the SINC field.
f) Incrementing/decrementing or fixed address for the destination in the DINC field.
5.3.3.1 Single-block Transfer (Row 1)

This section describes a single-block transfer, Row 1 in Table 5-8.
Note: Row 5 in Table 5-8 is also a single-block transfer with write-back of control and
status information enabled at the end of the single-block transfer.
1. Read the Channel Enable register to choose a free (disabled) channel.
2. Clear any pending interrupts on the channel from the previous DMA transfer by
writing to the Interrupt Clear registers: CLEARTFR, CLEARBLOCK,
CLEARSRCTRAN, CLEARDSTTRAN, and CLEARERR. Reading the Interrupt Raw
Status and Interrupt Status registers confirms that all interrupts have been cleared.
3. Program the following channel registers:
a) Write the starting source address in the SAR register for channel x.
b) Write the starting destination address in the DAR register for channel x.
c) Program CTL and CFG according to Row 1, as shown in Table 5-8. Program the
LLP register with 0.
d) Write the control information for the DMA transfer in the CTL register for channel x.
e) Write the channel configuration information into the CFG register for channel x.
1. Designate the handshaking interface type (hardware or software) for the source
and destination peripherals; this is not required for memory.
This step requires programming the CFG.HS_SEL_SRC or CFG.HS_SEL_DST
bits, respectively. Writing a 0 activates the hardware handshaking interface to
handle source/destination requests. Writing a 1 activates the software
handshaking interface to handle source and destination requests.

XMC4500
XMC4000 Family
2. If the hardware handshaking interface is activated for the source or destination

peripheral, assign a handshaking interface to the source and destination
peripheral; this requires programming the CFG.SRC_PER and CFG.DEST_PER
bits, respectively.
f) If gather is enabled (CTL.SRC_GATHER_EN = 1), program the SGR register for
channel x.
g) If scatter is enabled (CTL.DST_SCATTER_EN = 1), program the DSR register for
channel x.
4. After the GPDMA-selected channel has been programmed, enable the channel by
writing a 1 to the GPDMA0_CHENREG.CH_EN bit. Ensure that bit 0 of the
GPDMA0_DMACFGREG register is enabled.
5. Source and destination request single and burst DMA transactions in order to transfer
the block of data (assuming non-memory peripherals). The GPDMA acknowledges
at the completion of every transaction (burst and single) in the block and carries out
the block transfer.
6. Once the transfer completes, hardware sets the interrupts and disables the channel.
At this time, you can respond to either the Block Complete or Transfer Complete
interrupts, or poll for the transfer complete raw interrupt status register (RAWTFR[n],
n = channel number) until it is set by hardware, in order to detect when the transfer
is complete. Note that if this polling is used, the software must ensure that the transfer
complete interrupt is cleared by writing to the Interrupt Clear register, CLEARTFR[n],
before the channel is enabled.
5.3.3.2 Multi-Block Transfer with Linked List for Source and Linked List
for Destination (Row 10)
This type of transfer is supported by channels 0 and 1 only.
1. Read the Channel Enable register (see GPDMA0_CHENREG) to choose a free
(disabled) channel.
2. Set up the chain of Linked List Items (otherwise known as block descriptors) in
memory. Write the control information in the LLI.CTL register location of the block
descriptor for each LLI in memory (see Figure 5-23) for channel x.
3. Write the channel configuration information into the CFG register for channel x.
a) Designate the handshaking interface type (hardware or software) for the source
This step requires programming the CFG.HS_SEL_SRC or CFG.HS_SEL_DST
bits, respectively. Writing a 0 activates the hardware handshaking interface to
handle source/destination requests for the specific channel. Writing a 1 activates
the software handshaking interface to handle source/destination requests.
b) If the hardware handshaking interface is activated for the source or destination
peripheral, assign the handshaking interface to the source and destination
peripheral. This requires programming the CFG.SRC_PER and CFG.DEST_PER
bits, respectively.

XMC4500
XMC4000 Family
4. Make sure that the LLI.CTLx register locations of all LLI entries in memory (except
the last) are set as shown in Row 10 of Table 5-8. The LLI.CTLx register of the last
Linked List Item must be set as described in Row 1 or Row 5 of Table 5-8.
Figure 5-23 shows a Linked List example with two list items.
5. Make sure that the LLI.LLPx register locations of all LLI entries in memory (except
the last) are non-zero and point to the base address of the next Linked List Item.
6. Make sure that the LLI.SARx/LLI.DARx register locations of all LLI entries in memory
point to the start source/destination block address preceding that LLI fetch.
7. Ensure that the LLI.CTLx.DONE field of the LLI.CTLx register locations of all LLI
entries in memory is cleared.
8. If source status fetching is enabled (CFGx.SS_UPD_EN is enabled), program the
SSTATAR register so that the source status information can be fetched from the
location pointed to by the SSTATAR. For conditions under which the source status
information is fetched from system memory, refer to the Write Back column of
Table 5-8.
9. If destination status fetching is enabled (CFGx.DS_UPD_EN is enabled), program
the DSTATAR register so that the destination status information can be fetched from
the location pointed to by the DSTATAR register. For conditions under which the
destination status information is fetched from system memory, refer to the Write Back
column of Table 5-8.
10. If gather is enabled (CTL.SRC_GATHER_EN = 1), program the SGR register for
channel x.
11. If scatter is enabled (CTL.DST_SCATTER_EN = 1), program the DSR register for
channel x.
13. Program the CTL and CFG registers according to Row 10, as shown in Table 5-8.
14. Program the LLP register with LLP(0), the pointer to the first linked list item.
15. Finally, enable the channel by writing a 1 to the GPDMA0_CHENREG.CH_EN bit;
the transfer is performed.
16. The GPDMA fetches the first LLI from the location pointed to by LLPx(0).
Note: The LLI.SARx, LLI.DARx, LLI.LLPx, and LLI.CTLx registers are fetched. The
GPDMA automatically reprograms the SARx, DARx, LLPx, and CTLx channel
registers from the LLPx(0).
17. Source and destination request single and burst DMA transactions to transfer the
block of data (assuming non-memory peripheral). The GPDMA acknowledges at the
completion of every transaction (burst and single) in the block and carries out the
block transfer.
18. Once the block of data is transferred, the source status information is fetched from
the location pointed to by the SSTATAR register and stored in the SSTAT register if
CFGx.SS_UPD_EN is enabled. For conditions under which the source status

XMC4500
XMC4000 Family
Table 5-8.
The destination status information is fetched from the location pointed to by the
DSTATAR register and stored in the DSTAT register if CFGx.DS_UPD_EN is
enabled. For conditions under which the destination status information is fetched
from system memory, refer to the Write Back column of Table 5-8.
19. The CTLxH register is written out to system memory. For conditions under which the
CTLxH register is written out to system memory, refer to the Write Back column of
Table 5-8.
The CTLxH register is written out to the same location on the same layer (LLP.LMS)
where it was originally fetched; that is, the location of the CTL register of the linked
list item fetched prior to the start of the block transfer. Only the CTLxH register is
written out, because only the CTL.BLOCK_TS and CTL.DONE fields have been
updated by the GPDMA hardware. Additionally, the CTL.DONE bit is asserted to
indicate block completion. Therefore, software can poll the LLI.CTLx.DONE bit of the
CTL register in the LLI to ascertain when a block transfer has completed.
Note: Do not poll the CTLx.DONE bit in the GPDMA memory map; instead, poll the
LLI.CTLx.DONE bit in the LLI for that block. If the polled LLI.CTLx.DONE bit is
asserted, then this block transfer has completed. This LLI.CTLx.DONE bit was
cleared at the start of the transfer (Step 7).
20. The SSTAT register is now written out to system memory if CFGx.SS_UPD_EN is
enabled. It is written to the SSTAT register location of the LLI pointed to by the
previously saved LLPx.LOC register.
The DSTAT register is now written out to system memory if CFGx.DS_UPD_EN is
enabled. It is written to the DSTAT register location of the LLI pointed to by the
The end-of-block interrupt, int_block, is generated after the write-back of the control
and status registers has completed.
Note: The write-back location for the control and status registers is the LLI pointed to
by the previous value of the LLPx.LOC register, not the LLI pointed to by the current
value of the LLPx.LOC register.
21. The GPDMA does not wait for the block interrupt to be cleared, but continues fetching
the next LLI from the memory location pointed to by the current LLP register and
automatically reprograms the SAR, DAR, CTL, and LLP channel registers. The DMA
transfer continues until the GPDMA determines that the CTL and LLP registers at the
end of a block transfer match the ones described in Row 1 or Row 5 of Table 5-8 (as
discussed earlier). The GPDMA then knows that the previously transferred block was
the last block in the DMA transfer.
The DMA transfer might look like that shown in Figure 5-27.

XMC4500
XMC4000 Family
Figure 5-27 Multi-Block with Linked Address for Source and Destination
If the user needs to execute a DMA transfer where the source and destination address
are contiguous, but where the amount of data to be transferred is greater than the
maximum block size CTL.BLOCK_TS, then this can be achieved using the type of multi-
block transfer shown in Figure 5-28.

XMC4500
XMC4000 Family
Figure 5-28 Multi-Block with Linked Address for Source and Destination Where
SARx and DARx Between Successive Blocks are Contiguous

XMC4500
XMC4000 Family
The DMA transfer flow is shown in Figure 5-29.
Channel enabled by software
LLI fetch
Hardware reprograms SARx, DARx,

CTLx and LLPx
DMA block transfer
Source/destination status fetch
Write-back of control and source/

destination status to LLI
Block interrupt
generated here
Is the GPDMA in No
row1 or row5
Transfer complete Yes

interrupt generated here
Channel disabled by hardware
Figure 5-29 DMA Transfer Flow for Source and Destination Linked List Address

XMC4500
XMC4000 Family

Destination Address Auto-Reloaded (Row 4)
1. Read the Channel Enable register (see GPDMA0_CHENREG) to choose an
available (disabled) channel.
c) Program CTL and CFG according to Row 4, as shown in Table 5-8. Program the
LLP register with 0.
e) If gather is enabled (CTL.SRC_GATHER_EN = 1), program the SGR register for
channel x.
f) If scatter is enabled (CTL.DST_SCATTER_EN = 1), program the DSR register for
channel x.
g) Write the channel configuration information into the CFG register for channel x.
Ensure that the reload bits, CFGx. RELOAD_SRC and CFGx.RELOAD_DST, are
enabled.
This step requires programming the HS_SEL_SRC/HS_SEL_DST bits,
respectively. Writing a 0 activates the hardware handshaking interface to handle
source/destination requests for the specific channel. Writing a 1 activates the
software handshaking interface to handle source/destination requests.
peripheral. This requires programming the SRC_PER and DEST_PER bits,
respectively.
4. After the GPDMA selected channel has been programmed, enable the channel by
writing a 1 to the GPDMA0_CHENREG.CH_EN bit. Ensure that bit 0 of the
5. Source and destination request single and burst GPDMA transactions to transfer the
block of data (assuming non-memory peripherals). The GPDMA acknowledges on
completion of each burst/single transaction and carries out the block transfer.
6. When the block transfer has completed, the GPDMA reloads the SAR, DAR, and
CTL registers. Hardware sets the block-complete interrupt. The GPDMA then
samples the row number, as shown in Table 5-8. If the GPDMA is in Row 1, then the
DMA transfer has completed. Hardware sets the transfer complete interrupt and

XMC4500
XMC4000 Family
disables the channel. You can either respond to the Block Complete or Transfer
Complete interrupts, or poll for the transfer complete raw interrupt status register
(RAWTFR[n], where n is the channel number) until it is set by hardware, in order to
detect when the transfer is complete. Note that if this polling is used, software must
ensure that the transfer complete interrupt is cleared by writing to the Interrupt Clear
register, CLEARTFR[n], before the channel is enabled. If the GPDMA is not in Row
1, the next step is performed.
7. The DMA transfer proceeds as follows:
a) If interrupts are enabled (CTL.INT_EN = 1) and the block-complete interrupt is
unmasked (MASKBLOCK[x] = 1B, where x is the channel number), hardware sets
the block-complete interrupt when the block transfer has completed. It then stalls
until the block-complete interrupt is cleared by software. If the next block is to be
the last block in the DMA transfer, then the block-complete ISR (interrupt service
routine) should clear the reload bits in the CFGx.RELOAD_SRC and
CFGx.RELOAD_DST registers. This puts the GPDMA into Row 1, as shown in
Table 5-8. If the next block is not the last block in the DMA transfer, then the reload
bits should remain enabled to keep the GPDMA in Row 4.
b) If interrupts are disabled (CTL.INT_EN = 0) or the block-complete interrupt is
masked (MASKBLOCK[x] = 0B, where x is the channel number), then hardware
does not stall until it detects a write to the block-complete interrupt clear register;
instead, it immediately starts the next block transfer. In this case, software must
clear the reload bits in the CFGx.RELOAD_SRC and CFGx.RELOAD_DST
registers to put the GPDMA into Row 1 of Table 5-8 before the last block of the
DMA transfer has completed.
The transfer is similar to that shown in Figure 5-30.

XMC4500
XMC4000 Family
Figure 5-30 Multi-Block DMA Transfer with Source and Destination Address
Auto-Reloaded

XMC4500
XMC4000 Family
Channel enabled by SW
Block transfer
Reload SARx, DARx and CTLx
Yes Is the GPDMA in row1

Transfer complete
Channel disabled by HW No
CTLx.INT_EN = 1
AND
No
MASKBLOCK[x] = 1
Block-complete Yes
Stall until block-complete interrupt

cleared by SW
Figure 5-31 DMA Transfer Flow for Source and Destination Address Auto-
Reloaded

XMC4500
XMC4000 Family

Linked List Destination Address (Row 7)
1. Read the Channel Enable register (see GPDMA0_CHENREG) in order to choose a
free (disabled) channel.
2. Set up the chain of linked list items (otherwise known as block descriptors) in
memory. Write the control information in the LLI.CTL register location of the block
descriptor for each LLI in memory (see Figure 5-23) for channel x.
3. Write the starting source address in the SAR register for channel x.
Note: The values in the LLI.SARx register locations of each of the Linked List Items
(LLIs) set up in memory, although fetched during an LLI fetch, are not used.
a) Designate the handshaking interface type (hardware or software) for the source
This step requires programming the HS_SEL_SRC/HS_SEL_DST bits. Writing a
0 activates the hardware handshaking interface to handle source/destination
requests for the specific channel. Writing a 1 activates the software handshaking
interface source/destination requests.
peripheral; this requires programming the SRC_PER and DEST_PER bits,
respectively.
5. Make sure that the LLI.CTLx register locations of all LLIs in memory (except the last)
are set as shown in Row 7 of Table 5-8, while the LLI.CTLx register of the last Linked
List item must be set as described in Row 1 or Row 5 of Table 5-8. Figure 7-1 shows
a Linked List example with two list items.
6. Ensure that the LLI.LLPx register locations of all LLIs in memory (except the last) are
non-zero and point to the next Linked List Item.
7. Ensure that the LLI.DARx register location of all LLIs in memory point to the start
destination block address preceding that LLI fetch.
8. Ensure that the LLI.CTLx.DONE fields of the LLI.CTLx register locations of all LLIs in
memory are cleared.
location pointed to by the SSTATAR. For conditions under which the source status
Table 5-8.

XMC4500
XMC4000 Family
channel x.
channel x.
15. Program the LLP register with LLP(0), the pointer to the first Linked List item.
the transfer is performed. Ensure that bit 0 of the GPDMA0_DMACFGREG register
is enabled.
17. The GPDMA fetches the first LLI from the location pointed to by LLP(0).
LLI.SARx register - although fetched - is not used.
18. Source and destination request single and burst GPDMA transactions in order to
transfer the block of data (assuming non-memory peripherals). The GPDMA
acknowledges at the completion of every transaction (burst and single) in the block
and carries out the block transfer.
Table 5-8.
The destination status information is fetched from the location pointed to by the
DSTATAR register and stored in the DSTAT register if CFGx.DS_UPD_EN is
Table 5-8.
The CTLxH register is written out to the same location on the same layer (LLP.LMS)
where it was originally fetched; that is, the location of the CTL register of the linked
list item fetched prior to the start of the block transfer. Only the CTLxH register is
written out, because only the CTL.BLOCK_TS and CTL.DONE fields have been
updated by hardware within the GPDMA. The LLI.CTLx.DONE bit is asserted to
indicate block completion. Therefore, software can poll the LLI.CTL.DONE bit field of
the CTL register in the LLI to ascertain when a block transfer has completed.
Note: Do not poll the CTLx.DONE bit in the GPDMA memory map. Instead, poll the

XMC4500
XMC4000 Family
enabled. It is written to the SSTATx register location of the LLI pointed to by the
The DSTAT register is now written out to system memory if CFGx.DS_UPD_EN is
enabled. It is written to the DSTATx register location of the LLI pointed to by the
The end-of-block interrupt, int_block, is generated after the write-back of the control
and status registers has completed.
22. The GPDMA reloads the SAR register from the initial value. Hardware sets the block-
complete interrupt. The GPDMA samples the row number, as shown in Table 5-8. If
the GPDMA is in Row 1 or Row 5, then the DMA transfer has completed. Hardware
sets the transfer complete interrupt and disables the channel. You can either respond
to the Block Complete or Transfer Complete interrupts, or poll for the transfer
complete raw interrupt status register (RAWTFR[n], n = channel number) until it is set
by hardware, in order to detect when the transfer is complete. Note that if this polling
is used, software must ensure that the transfer complete interrupt is cleared by
writing to the Interrupt Clear register, CLEARTFR[n], before the channel is enabled.
If the GPDMA is not in Row 1 or Row 5 as shown in Table 5-8, the following steps
are performed.
routine) should clear the CFGx.RELOAD_SRC source reload bit. This puts the
GPDMA into Row 1, as shown in Table 5-8. If the next block is not the last block
in the DMA transfer, then the source reload bit should remain enabled to keep the
GPDMA in Row 7, as shown in Table 5-8.
instead, it immediately starts the next block transfer. In this case, software must
clear the source reload bit, CFGx.RELOAD_SRC in order to put the device into
Row 1 of Table 5-8 before the last block of the DMA transfer has completed.
24. The GPDMA fetches the next LLI from memory location pointed to by the current LLP
register and automatically reprograms the DAR, CTL, and LLP channel registers.
Note that the SAR is not reprogrammed, since the reloaded value is used for the next
DMA block transfer. If the next block is the last block of the DMA transfer, then the

XMC4500
XMC4000 Family
CTL and LLP registers just fetched from the LLI should match Row 1 or Row 5 of
Table 5-8.

XMC4500
XMC4000 Family
The DMA transfer might look like that shown in Figure 5-32.
Figure 5-32 Multi-Block DMA Transfer with Source Address Auto-Reloaded and
Linked List Destination Address

XMC4500
XMC4000 Family
LLI fetch
HW reprograms DARx, CTLx and LLPx
Block transfer

Reload SARx

Transfer complete
CTLx.INT_EN = 1
AND
No
MASKBLOCK[x] = 1
Block-complete Yes

cleared by SW
Figure 5-33 DMA Transfer Flow for Source Address Auto-Reloaded and Linked
List Destination Address

XMC4500
XMC4000 Family

Contiguous Destination Address (Row 3)
(disabled) channel.
c) Program CTL and CFG according to Row 3, shown in Table 5-8. Program the LLP
register with 0.
e) If gather is enabled (CTL.SRC_GATHER_EN = 1), program the SGR register for
channel x.
f) If scatter is enabled (CTL.DST_SCATTER_EN = 1), program the DSR register for
channel x.
g) Write the channel configuration information into the CFG register for channel x.
This step requires programming the HS_SEL_SRC/HS_SEL_DST bits,
respectively. Writing a 0 activates the hardware handshaking interface to handle
source/destination requests for the specific channel. Writing a 1 activates the
software handshaking interface to handle source/destination requests.
peripheral. This requires programming the SRC_PER and DEST_PER bits,
respectively.
4. After the GPDMA channel has been programmed, enable the channel by writing a 1
to the GPDMA0_CHENREG.CH_EN bit. Ensure that bit 0 of the
block of data (assuming non-memory peripherals). The GPDMA acknowledges at the
block transfer.
6. When the block transfer has completed, the GPDMA reloads the SAR register; the
DAR register remains unchanged. Hardware sets the block-complete interrupt. The
GPDMA then samples the row number, as shown in Table 5-8. If the GPDMA is in
Row 1, then the DMA transfer has completed. Hardware sets the transfer-complete
interrupt and disables the channel. You can either respond to the Block Complete or

XMC4500
XMC4000 Family
Transfer Complete interrupts, or poll for the transfer complete raw interrupt status
register (RAWTFR[n], n = channel number) until it is set by hardware, in order to
detect when the transfer is complete. Note that if this polling is used, software must
ensure that the transfer complete interrupt is cleared by writing to the Interrupt Clear
register, CLEARTFR[n], before the channel is enabled. If the GPDMA is not in Row
1, the next step is performed.
routine) should clear the source reload bit, CFGx.RELOAD_SRC. This puts the
GPDMA into Row 1, as shown in Table 5-8. If the next block is not the last block
in the DMA transfer, then the source reload bit should remain enabled to keep the
GPDMA in Row 3, as shown in Table 5-8.
instead, it starts the next block transfer immediately. In this case, software must
clear the source reload bit, CFGx.RELOAD_SRC, to put the device into Row 1 of
Table 5-8 before the last block of the DMA transfer has completed.
The transfer is similar to that shown in Figure 5-34.
Figure 5-34 Multi-Block DMA Transfer with Source Address Auto-Reloaded and
Contiguous Destination Address

XMC4500
XMC4000 Family
Block transfer
Reload SARx and CTLx

Transfer complete
CTLx.INT_EN = 1
AND
No
MASKBLOCK[x] = 1
Block-complete Yes

cleared by SW

XMC4500
XMC4000 Family
5.3.3.6 Multi-Block DMA Transfer with Linked List for Source and
Contiguous Destination Address (Row 8)
(disabled) channel.
2. Set up the linked list in memory. Write the control information in the LLI.CTL register
location of the block descriptor for each LLI in memory (see Figure 5-23) for channel
x.
3. Write the starting destination address in the DAR register for channel x.
Note: The values in the LLI.DARx register location of each Linked List Item (LLI) in
memory, although fetched during an LLI fetch, are not used.
This step requires programming the HS_SEL_SRC/HS_SEL_DST bits. Writing a 0
activates the hardware handshaking interface to handle source/destination requests
for the specific channel. Writing a 1 activates the software handshaking interface to
handle source/destination requests.
peripherals. This requires programming the SRC_PER and DEST_PER bits,
respectively.
5. Ensure that all LLI.CTLx register locations of the LLI (except the last) are set as
shown in Row 8 of Table 5-8, while the LLI.CTLx register of the last Linked List item
must be set as described in Row 1 or Row 5 of Table 5-8. Figure 5-23 shows a
Linked List example with two list items.
6. Ensure that the LLI.LLPx register locations of all LLIs in memory (except the last) are
non-zero and point to the next Linked List Item.
7. Ensure that the LLI.SARx register location of all LLIs in memory point to the start
source block address preceding that LLI fetch.
8. Ensure that the LLI.CTLx.DONE fields of the LLI.CTLx register locations of all LLIs in
memory are cleared.
location pointed to by SSTATAR. For conditions under which the source status
Table 5-8.

XMC4500
XMC4000 Family
channel x.
channel x.
15. Program the LLP register with LLP(0), the pointer to the first Linked List item.
the transfer is performed. Ensure that bit 0 of the GPDMA0_DMACFGREG register
is enabled.
17. The GPDMA fetches the first LLI from the location pointed to by LLP(0).
LLI.DARx register location of the LLI - although fetched - is not used. The DAR
register in the GPDMA remains unchanged.
block of data (assuming non-memory peripherals). The GPDMA acknowledges at the
block transfer.
Table 5-8.The destination status information is fetched from the location pointed to
by the DSTATAR register and stored in the DSTAT register if CFGx.DS_UPD_EN is
Table 5-8.The CTLxH register is written out to the same location on the same layer
(LLPx.LMS) where it was originally fetched; that is, the location of the CTL register of
the linked list item fetched prior to the start of the block transfer. Only the second word
of the CTL register is written out, CTLxH, because only the CTL.BLOCK_TS and
CTL.DONE fields have been updated by hardware within the GPDMA. Additionally,
the CTL.DONE bit is asserted to indicate block completion. Therefore, software can
poll the LLI.CTL.DONE bit field of the CTL register in the LLI to ascertain when a
block transfer has completed.
Note: Do not poll the CTL.DONE bit in the GPDMA memory map. Instead, poll the

XMC4500
XMC4000 Family
enabled. It is written to the SSTAT register location of the LLI pointed to by the
previously saved LLPx.LOC register.The DSTAT register is now written out to
system memory if CFGx.DS_UPD_EN is enabled. It is written to the DSTAT register
location of the LLI pointed to by the previously saved LLPx.LOC register.The end-of-
block interrupt, int_block, is generated after the write-back of the control and status
registers has completed.
22. The GPDMA does not wait for the block interrupt to be cleared, but continues and
fetches the next LLI from the memory location pointed to by the current LLP register
and automatically reprograms the SAR, CTL, and LLP channel registers. The DAR
register is left unchanged. The DMA transfer continues until the GPDMA samples
that the CTL and LLP registers at the end of a block transfer match those described
in Row 1 or Row 5 of Table 5-8 (as discussed earlier). The GPDMA then knows that
the previously transferred block was the last block in the DMA transfer.
The GPDMA transfer might look like that shown in Figure 5-36. Note that the destination
address is decrementing.
Figure 5-36 Multi-Block DMA Transfer with Linked List Source Address and
Contiguous Destination Address

XMC4500
XMC4000 Family
LLI fetch
HW reprograms DARx, CTLx and LLPx
Block transfer

Block-complete complete
No
Is the GPDMA in row1
Transfer complete Yes

Channel disabled by HW
5.3.3.7 Programming Example for Linked List Multi-Block Transfer

The flow diagram in Figure 5-38 shows an overview of programming the DMA.

XMC4500
XMC4000 Family
Figure 5-38 Flowchart for DMA Programming Example

This section explains the step-by-step programming of the GPDMA. The example
demonstrates row 10 of Table 5-8 for Multi-Block Transfer with Linked List for Source

XMC4500
XMC4000 Family
and Linked List for Destination. This example uses the GPDMA to move four blocks of
contiguous data from source to destination memory using the Linked List feature.
1. Set up the chain of Linked List items otherwise known as block descriptors in
memory. Write the control information in the LLI.CTLx register location of the block
descriptor for each LLI in memory for Channel 1. In the LLI.CTLx register, the
following is programmed:
a) Set up the transfer type for a memory-to-memory transfer:
- ctlx[22:20] = 000;
b) Set up the transfer characteristics:
1. Transfer width for the source in the SRC_TR_WIDTH field
- ctlx[6:4] = 001;
2. Transfer width for the destination in the DST_TR_WIDTH field
- ctlx[3:1] = 001;
3. Source master layer in the SMS field where the source resides
- ctlx[26:25] = 00;
4. Destination master layer in the DMS field where the destination resides
- ctlx[24:23] = 00;
5. Incrementing address for the source in the SINC field
- ctlx[10:9] = 00;
6. Incrementing address for the destination in the DINC field
- ctlx[8:7] = 00;
2. Write the channel configuration information into the CFGx register for Channel 1:
a) HS_SEL_SRC/HS_SEL_DST bits select which of the handshaking interfaces
hardware or softwareis active for source requests on this channel.
- cfgx[11] = 0;
- cfgx[10] = 0;
These settings are ignored because both the source and destination are memory
types
peripheral by programming the SRC_PER and DEST_PER bits:
- cfgx[46:43] = 0;
- cfgx[42:39] = 0;
These settings are ignored because both the source and destination are memory
types.
3. The following For loop, shown as a programming example, sets the following:
a) LLI.LLPx register locations of all LLI entries in memory (except the last) to non-
zero and point to the base address of the next Linked List Item
b) LLI.SARx/LLI.DARx register locations of all LLI entries in memory point to the start
source/destination block address preceding that LLI fetch. The For statement
below configures the LLPx entries:
for(i=0 ; i < 4 ; i=i+1) begin

XMC4500
XMC4000 Family
if (i == 3)llpx = 0; // end of LLI

elsellpx = llp_addr + 20; // start of next LLI
//-: Program SAR"AHB_MASTER.write(0, llp_addr, sarx,

AhbWord32Attrb, handle[0]);
//-: Program DAR"AHB_MASTER.write(0, (llp_addr + 4), darx,

//-: Program LLP"AHB_MASTER.write(0, (llp_addr + 8), llpx,

//-: Program CTL"AHB_MASTER.write(0, (llp_addr + 12),

ctlx[31:0], AhbWord32Attrb, handle[0]);"AHB_MASTER.write(0,
(llp_addr + 16), ctlx[63:32], AhbWord32Attrb, handle[0]);//
update pointersllp_addr = llp_addr + 20; // start of next LLI
// 4 16-bit words each with scatter/gather interval in each
block
// ( will work only with scatter_gather count of 2)
sarx = sarx + 24;
darx = darx + 24;
end
4. If Gather is enabled (CTL.SRC_GATHER_EN = 1), program the SGRx register for
Channel 1.
5. If Scatter is enabled (CTL.DST_SCATTER_EN = 1) program the DSRx register for
Channel 1.
writing to the Interrupt Clear registers.
7. Finally, enable the channel by writing a 1 to the CHENREG.CH_EN bit; the transfer
is performed

XMC4500
XMC4000 Family
5.3.4 Abnormal Transfer Termination

A GPDMA DMA transfer may be terminated abruptly by software by clearing the channel
enable bit, CHENREG.CH_EN or by clearing the global enable bit in the GPDMA
Configuration Register (DMACFGREG[0]).
If a transfer is in progress while a channel is disabled, abnormal transfer termination and
data corruption occurs. Also the transfer acknowledge may be lost. Therefore this must
be avoided.
Attention: Disabling a channel via software prior to completing a transfer is not
supported.

The GPDMA unit is inside the power core domain, therefore no special considerations
about power up or power down sequences need to be taken. For an explanation about
the different power domains, please address the SCU (System Control Unit) chapter.
Additionally, if a GPDMA unit is not needed, it can be set in reset via the
PRSET2.DMAyRS bitfield (address the SCU chapter for a full description).
The clock used for the GPDMA unit is described on the SCU chapter as fDMA. Please
address the specific section under the SCU chapter for a detailed description on the
clock configuration schemes.

The generic initialization sequence for an application that is using the GPDMA, should
be the following:
1st Step: Release reset of the GPDMA, via the specific SCU bitfield on the PRCLR2
register.
2nd Step: If the GPDMA is already under use (step 1 was not performed) do the following
steps:
read the channel Enable register to choose a free channel, CHENREG. Clear also
any pending requests of the specific channel, by writing into the CLEARTFR,
CLEARBLOCK, CLEARSRCTRAN, CLEARDSTTRAN and CLEARERR
confirm that all the interrupts have been cleared via the Status and RAW registers.
3rd Step: Configure the GPDMA channels accordingly with the wanted transfer type:
Configure the starting source address and starting destination address, on the SAR
and DAR, respectively.
Configure the type of transfer that are going to be used via the LLP, CTL and CFG
registers.
4th Step: Enable the GPDMA channel, by setting the specific bitfield on the CHENREG.

XMC4500
XMC4000 Family
5th Step: Configure the DLR (DMA Line Router) block to map the DMA requests from
the peripherals to the wanted DMA request lines (if not previously done).
6th Step: Configure the peripherals that are linked with DMA requests.
7th Step: Enable the specific Service requests on the peripheral blocks.
8th Step: Start the peripheral(s)
Note: This is a generic channel initialization example. Please address Section 5.3 for a
complete description and examples of how to control the complete flow for a
GPDMA channel.

XMC4500
XMC4000 Family
5.6 Registers
This chapter includes information on how to program the GPDMA.
Notes
1. There are references to software parameters throughout this chapter. The software
parameters are the field names in each register description table and are prefixed by
the register name; for example, the Block Transfer Size field in the Control register
for channel x of GPDMA0 is designated as "GPDMA0_CTLxH.BLOCK_TS

GPDMA0_CH0 5001 4000H 5001 4054H
GPDMA0_CH1 5001 4058H 5001 40ACH
GPDMA0_CH2 5001 40B0H 5001 4104H
GPDMA0_CH3 5001 4108H 5001 415CH
GPDMA0_CH4 5001 4160H 5001 41B4H
GPDMA0_CH5 5001 41B8H 5001 420CH
GPDMA0_CH6 5001 4210H 5001 4264H
GPDMA0_CH7 5001 4268H 5001 42BCH
GPDMA0 5001 42C0H 5001 7FFFH
GPDMA1_CH0 5001 8000H 5001 8054H
GPDMA1_CH1 5001 8058H 5001 80ACH
GPDMA1_CH2 5001 80B0H 5001 8104H
GPDMA1_CH3 5001 8108H 5001 815CH
GPDMA1 5001 82C0H 5001 FFFFH
Table 5-10 Register Overview

ChannelRegisters
SARx Source Address Register 0000H + U, PV U, PV Page 5-83
x*58H
DARx Destination Address 0008H + U, PV U, PV Page 5-84
Register x*58H

XMC4500
XMC4000 Family
Table 5-10 Register Overview (contd)

Control Registers
CTLxH Control Register High 001CH U, PV U, PV Page 5-88
+ x*5CH
CTLxL Control Register Low 0018H + U, PV U, PV Page 5-90
x*58H
LLPx Linked List Pointer Register 0010H + U, PV U, PV Page 5-86
x*58H
SSTATx Source Status Register 0020H + U, PV U, PV Page 5-97
x*58H
DSTATx Destination Status Register 0028H + U, PV U, PV Page 5-98
x*58H
SSTATARx Source Status Register 0030H + U, PV U, PV Page 5-99
x*58H
DSTATARx Destination Status Register 0038H + U, PV U, PV Page 5-100
x*58H
CFGxH Configuration Register High 0044H + U, PV U, PV Page 5-101
x*5CH
CFGxL Configuration Register Low 0040H + U, PV U, PV Page 5-106
x*58H
SGRx Source Gather Register 0048H + U, PV U, PV Page 5-113
x*58H
DSRx Destination Scatter Register 0050H + U, PV U, PV Page 5-114
x*58H
Interrupt Registers
RAW* with Interrupt Raw Status 02C0H - U, PV U, PV Page 5-117
*TFR, Registers 02E0H
*BLOCK,
*SRCTRAN,
*DSTTRAN,
*ERR

XMC4500
XMC4000 Family

STATUS* with Interrupt Status Registers 02E8H - U, PV U, PV Page 5-120
*TFR, 0308H
*BLOCK,
*SRCTRAN,
*DSTTRAN,
*ERR
MASK* with Interrupt Mask Registers 0310H - U, PV U, PV Page 5-122
*TFR, 0330H
*BLOCK,
*SRCTRAN,
*DSTTRAN,
*ERR
CLEAR* with Interrupt Clear Registers 0338H - U, PV U, PV Page 5-125
*TFR, 0358H
*BLOCK,
*SRCTRAN,
*DSTTRAN,
*ERR
STATUSINT Combined Interrupt Status 0360H U, PV U, PV Page 5-126
Register
Software Handshaking Registers
REQSRCREG Source Software 0368H U, PV U, PV Page 5-128
Transaction Request
Register
REQDSTREG Destination Software 0370H U, PV U, PV Page 5-129
Transaction Request
Register
SGLREQSRCR Single Source Transaction 0378H U, PV U, PV Page 5-131
EG Request Register
SGLREQDSTR Single Destination 0380H U, PV U, PV Page 5-132
EG Transaction Request
Register
LSTSRCREG Last Source Transaction 0388H U, PV U, PV Page 5-134
Request Register

XMC4500
XMC4000 Family

LSTDSTREG Last Destination 0390H U, PV U, PV Page 5-135
Transaction Request
Register
Configuration and Channel Enable Registers
DMACFGREG Configuration Register 0398H U, PV U, PV Page 5-80
CHENREG Channel Enable Register 03A0H U, PV U, PV Page 5-80
Miscellaneous GPDMA Registers
ID GPDMA Module ID 03A8H U, PV U, PV Page 5-138
Reserved Reserved 03B0H - nBE nBE
03F4H
TYPE GPDMA Component Type 03F8H U, PV U, PV Page 5-138
VERSION GPDMA Component 03FCH U, PV U, PV Page 5-139
Version
Reserved Reserved 0400H - nBE nBE
7FFCH

XMC4500
XMC4000 Family
5.6.1 Configuration and Channel Enable Registers
DMACFGREG
This register is used to enable the GPDMA, which must be done before any channel
activity can begin.
GPDMA0_DMACFGREG
GPDMA Configuration Register (398H) Reset Value: 0000 0000H
GPDMA1_DMACFGREG
GPDMA Configuration Register (398H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DMA
0
_EN
r rw

0 [31:1] r Reserved
DMA_EN 0 rw GPDMA Enable bit.
0B GPDMA Disabled
1B GPDMA Enabled.
If the global channel enable bit is cleared while any channel is still active, then
DMACFGREG.DMA_EN still returns 1 to indicate that there are channels still active until
hardware has terminated all activity on all channels, at which point the
DMACFGREG.DMA_EN bit returns 0.
CHENREG
This is the GPDMA Channel Enable Register. If software needs to set up a new
channel, then it can read this register in order to find out which channels are currently
inactive; it can then enable an inactive channel with the required priority.
All bits of this register are cleared to 0 when the global GPDMA channel enable bit,
DMACFGREG[0], is 0. When the global channel enable bit is 0, then a write to the
CHENREG register is ignored and a read will always read back 0.

XMC4500
XMC4000 Family
The channel enable bit, CHENREG.CH_EN, is written only if the corresponding channel
write enable bit, CHENREG.CH_EN_WE, is asserted on the same AHB write transfer.
For example, writing hex 01x1 writes a 1 into CHENREG[0], while CHENREG[7:1]
remains unchanged. Writing hex 00xx leaves CHENREG[7:0] unchanged. Note that a
read-modified write is not required.
GPDMA0_CHENREG
GPDMA Channel Enable Register (3A0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 WE_CHx CHx
r w rw

WE_CHx [15:8] w Channel enable write enable
CHx [7:0] rw Enables/Disables the channel
Setting this bit enables a channel; clearing this bit
disables the channel.
0B Disable the Channel
1B Enable the Channel
The CHENREG.CH_EN bit is automatically cleared by
hardware to disable the channel after the last AMBA
transfer of the DMA transfer to the destination has
completed. Software can therefore poll this bit to
determine when this channel is free for a new DMA
transfer.
GPDMA1_CHENREG
GPDMA Channel Enable Register (3A0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 WE_CHx 0 CHx
r w r rw

XMC4500
XMC4000 Family

WE_CHx [11:8] w Channel enable write enable
0 [7:4] r Reserved
CHx [3:0] rw Enables/Disables the channel
Setting this bit enables a channel; clearing this bit
disables the channel.
0B Disable the Channel
1B Enable the Channel
The CHENREG.CH_EN bit is automatically cleared by
hardware to disable the channel after the last AMBA
transfer of the DMA transfer to the destination has
completed. Software can therefore poll this bit to
determine when this channel is free for a new DMA
transfer.
5.6.2 Channel Registers

The SAR, DAR, LLP, CTL, and CFG channel registers should be programmed prior to
enabling the channel. However, if an LLI update occurs before commencing data
transfer, SAR and DAR may not need to be programmed prior to enabling the channel;
refer to rows 6 to 10 in Table 5-8 . It is an illegal register access (see Section 5.3.1)
when a write to the SAR, DAR, LLP, CTL, SSTAT, DSTAT, SSTATAR, DSTATAR,
SGR, or DSR registers occurs when the channel is enabled.

XMC4500
XMC4000 Family
SAR
The starting source address is programmed by software before the DMA channel is
enabled, or by an LLI update before the start of the DMA transfer. While the DMA transfer
is in progress, this register is updated to reflect the source address of the current AHB
transfer.
Note: You must program the SAR address to be aligned to CTL.SRC_TR_WIDTH.
For information on how the SARx is updated at the start of each DMA block for multi-
block transfers, refer to Table 5-8.
GPDMA0_CHx_SAR (x=0-7)
Source Address Register for Channel x
(00H + x*58H) Reset Value: 0000 0000H
GPDMA1_CHx_SAR (x=0-3)
Source Address Register for Channel x
(00H + x*58H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SAR
rw

SAR [31:0] rw Current Source Address of DMA transfer
Updated after each source transfer. The SINC field in the
CTL register determines whether the address increments,
decrements, or is left unchanged on every source transfer
throughout the block transfer.
Reset: 0D

XMC4500
XMC4000 Family
DAR
The starting destination address is programmed by software before the DMA channel is
enabled, or by an LLI update before the start of the DMA transfer. While the DMA transfer
is in progress, this register is updated to reflect the destination address of the current
AHB transfer.
Note: You must program the DAR to be aligned to CTL.DST_TR_WIDTH.
GPDMA0_CHx_DAR (x=0-7)
Destination Address Register for Channel x
(08H + x*58H) Reset Value: 0000 0000H
GPDMA1_CHx_DAR (x=0-3)
Destination Address Register for Channel x
(08H + x*58H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DAR
rw

DAR [31:0] rw Current Destination address of DMA transfer
Updated after each destination transfer. The DINC field in
the CTL register determines whether the address
increments, decrements, or is left unchanged on every
destination transfer throughout the block transfer.
Reset: 0D
Hardware Realignment of SAR/DAR Registers

In a particular circumstance, during contiguous multi-block DMA transfers, the
destination address can become misaligned between the end of one block and the start
of the next block. When this situation occurs, GPDMA re-aligns the destination address
before the start of the next block.
Consider the following example. If the block length is 9, the source transfer width is 16
(halfword), and the destination transfer width is 32 (word) the destination is
programmed for contiguous block transfers then the destination performs four word
transfers followed by a halfword transfer to complete the block transfer to the destination.
At the end of the destination block transfer, the address is aligned to a 16-bit transfer as
the last AMBA transfer is halfword. This is misaligned to the programmed transfer size
of 32 bits for the destination. However, for contiguous destination multi-block transfers,
GPDMA re-aligns the DAR address to the nearest 32-bit address (next 32-bit address

XMC4500
XMC4000 Family
upwards if address control is incrementing or next address downwards if address control

is decrementing).
The destination address is automatically realigned by the GPDMA in the following DMA
transfer setup scenario:
Contiguous multi-block transfers on destination side, AND
DST_TR_WIDTH > SRC_TR_WIDTH, AND
(BLOCK_TS * SRC_TR_WIDTH)/DST_TR_WIDTH != integer (where
SRC_TR_WIDTH, DST_TR_WIDTH is byte width of transfer)

XMC4500
XMC4000 Family
LLP
You need to program this register to point to the first Linked List Item (LLI) in memory
prior to enabling the channel if block chaining is enabled.
GPDMA0_CHx_LLP (x = 0-1)
Linked List Pointer Register for Channel x
(10H + x*58H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
LOC 0
rw r

LOC [31:2] rw Starting Address In Memory
of next LLI if block chaining is enabled. Note that the two
LSBs of the starting address are not stored because the
address is assumed to be aligned to a 32-bit boundary.
LLI accesses are always 32-bit accesses (Hsize = 2)
aligned to 32-bit boundaries and cannot be changed or
programmed to anything other than 32bit.
0 [1:0] r Reserved
The LLP register has two functions:

The logical result of the equation LLP.LOC != 0 is used to set up the type of DMA
transfer single or multi-block. Table 5-8 shows how the method of updating the
channel registers is a function of LLP.LOC != 0. If LLP.LOC is set to 0, then transfers
using linked lists are not enabled. This register must be programmed prior to enabling
the channel in order to set up the transfer type.
LLP.LOC != 0 contains the pointer to the next LLI for block chaining using linked lists.
The LLPx register can also point to the address where write-back of the control and
source/destination status information occur after block completion.

XMC4500
XMC4000 Family
CTL
These registers contain fields that control the DMA transfer.
The CTLxH and CTLxL registers are part of the block descriptor (linked list item - LLI)
when block chaining is enabled. It can be varied on a block-by-block basis within a DMA
transfer when block chaining is enabled.
If status write-back is enabled, the upper control register, CTLxH, is written to the control
register location of the LLI in system memory at the end of the block transfer.
Note: You need to program these registers prior to enabling the channel.

XMC4500
XMC4000 Family
CTLxH
Control Register High.
GPDMA0_CHx_CTLH (x=0-7)
Control Register High for Channel x
(1CH + x*58H) Reset Value: 0000 0002H
GPDMA1_CHx_CTLH (x=0-3)
Control Register High for Channel x
(1CH + x*58H) Reset Value: 0000 0002H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
D
O
0 BLOCK_TS
N
E
r rw rw


XMC4500
XMC4000 Family

DONE 12 rw Done bit
If status write-back is enabled, the upper word of the
control register, CTLX[63:32], is written to the control
register location of the Linked List Item (LLI) in system
memory at the end of the block transfer with the done
bit set.
Software can poll the LLI CTLX.DONE bit to see when
a block transfer is complete. The LLI CTLX.DONE bit
should be cleared when the linked lists are set up in
memory prior to enabling the channel.
LLI accesses are always 32-bit accesses (Hsize = 2)
aligned to 32-bit boundaries and cannot be changed
or programmed to anything other than 32-bit.
BLOCK_TS [11:0] rw Block Transfer Size
When the GPDMA is the flow controller, the user
writes this field before the channel is enabled in order
to indicate the block size. The number programmed
into BLOCK_TS indicates the total number of single
transactions to perform for every block transfer; a
single transaction is mapped to a single AMBA beat.
Width: The width of the single transaction is
determined by CTL.SRC_TR_WIDTH. Once the
transfer starts, the read-back value is the total number
of data items already read from the source peripheral,
regardless of what is the flow controller.

XMC4500
XMC4000 Family
CTLxL
Control Register Low.
GPDMA0_CHx_CTLL (x=0-1)
Control Register Low for Channel x
(18H + x*58H) Reset Value: 0030 4801H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DST SRC
LLP_ LLP_ _SC _GA SRC
0 SRC DST 0 TT_FC 0 ATT THE _MSI
_EN _EN ER_ R_E ZE
EN N
r rw rw r rw r rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SRC_MSIZ INT_
DEST_MSIZE SINC DINC SRC_TR_WIDTH DST_TR_WIDTH
E EN
rw rw rw rw rw rw rw

LLP_SRC_EN 28 rw Linked List Pointer for Source Enable
Block chaining is enabled on the source side only if
the LLP_SRC_EN field is high and LLPx.LOC is non-
zero.
LLP_DST_EN 27 rw Linked List Pointer for Destination Enable
Block chaining is enabled on the destination side only
if the LLP_DST_EN field is high and LLPx.LOC is non-
zero.
TT_FC [22:20] rw Transfer Type and Flow Control
The following transfer types are supported.
Memory to Memory
Memory to Peripheral
Peripheral to Memory
Peripheral to Peripheral
Flow Control can be assigned to the GPDMA, the
source peripheral, or the destination peripheral.

XMC4500
XMC4000 Family

0 19 r Reserved
DST_SCATTE 18 rw Destination scatter enable
R_EN 0B Scatter disabled
1B Scatter enabled
Scatter on the destination side is applicable only when
the DINC bit indicates an incrementing or
decrementing address control.
SRC_GATHE 17 rw Source gather enable
R_EN 0B Gather disabled
1B Gather enabled
Gather on the source side is applicable only when the
SINC bit indicates an incrementing or decrementing
address control.
SRC_MSIZE [16:14] rw Source Burst Transaction Length
Number of data items, each of width
SRC_TR_WIDTH, to be read from the source every
time a source burst transaction request is made from
either the corresponding hardware or software
handshaking interface. Table 5-11 lists the decoding
for this field;
Note: This value is not related to the AHB bus master
HBURST bus.
DEST_MSIZE [13:11] rw Destination Burst Transaction Length
DST_TR_WIDTH, to be written to the destination
every time a destination burst transaction request is
made from either the corresponding hardware or
software handshaking interface. Table 5-11 lists the
decoding for this field.
HBURST bus.

XMC4500
XMC4000 Family

SINC [10:9] rw Source Address Increment
Indicates whether to increment or decrement the
source address on every source transfer. If the device
is fetching data from a source peripheral FIFO with a
fixed address, then set this field to "No change".
00B Increment
01B Decrement
1xB No change
Note: Incrementing or decrementing is done for
alignment to the next CTLx.SRC_TR_WIDTH
boundary.
DINC [8:7] rw Destination Address Increment
destination address on every destination transfer. If
your device is writing data to a destination peripheral
FIFO with a fixed address, then set this field to "No
change".
00B Increment
01B Decrement
1xB No change
alignment to the next CTLx.DST_TR_WIDTH
boundary.
SRC_TR_WID [6:4] rw Source Transfer Width
TH Table 5-12 lists the decoding for this field.
DST_TR_WID [3:1] rw Destination Transfer Width
INT_EN 0 rw Interrupt Enable Bit
If set, then all interrupt-generating sources are
enabled. Functions as a global mask bit for all
interrupts for the channel; Raw* interrupt registers still
assert if INT_EN = 0.

XMC4500
XMC4000 Family
(18H + x*58H) Reset Value: 0030 4801H
(18H + x*58H) Reset Value: 0030 4801H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SRC
0 TT_FC 0 _MSI
ZE
r rw r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SRC_MSIZ INT_
DEST_MSIZE SINC DINC SRC_TR_WIDTH DST_TR_WIDTH
E EN

TT_FC [22:20] rw Transfer Type and Flow Control
The following transfer types are supported.
Memory to Memory
Memory to Peripheral
Peripheral to Memory
Peripheral to Peripheral
Flow Control can be assigned to the GPDMA, the
source peripheral, or the destination peripheral.
SRC_MSIZE [16:14] rw Source Burst Transaction Length
SRC_TR_WIDTH, to be read from the source every
time a source burst transaction request is made from
either the corresponding hardware or software
handshaking interface. Table 5-11 lists the decoding
for this field.
HBURST bus.

XMC4500
XMC4000 Family

DEST_MSIZE [13:11] rw Destination Burst Transaction Length
DST_TR_WIDTH, to be written to the destination
every time a destination burst transaction request is
made from either the corresponding hardware or
software handshaking interface. Table 5-11 lists the
decoding for this field.
HBURST bus.
SINC [10:9] rw Source Address Increment
source address on every source transfer. If the device
is fetching data from a source peripheral FIFO with a
fixed address, then set this field to "No change".
00B Increment
01B Decrement
1xB No change
alignment to the next CTLx.SRC_TR_WIDTH
boundary.
DINC [8:7] rw Destination Address Increment
destination address on every destination transfer. If
your device is writing data to a destination peripheral
FIFO with a fixed address, then set this field to "No
change".
00B Increment
01B Decrement
1xB No change
alignment to the next CTLx.DST_TR_WIDTH
boundary.
SRC_TR_WID [6:4] rw Source Transfer Width

XMC4500
XMC4000 Family

DST_TR_WID [3:1] rw Destination Transfer Width
INT_EN 0 rw Interrupt Enable Bit
If set, then all interrupt-generating sources are
enabled. Functions as a global mask bit for all
interrupts for the channel; Raw* interrupt registers still
assert if INT_EN = 0.
Table 5-11 CTLx.SRC_MSIZE and CTLx.DST_MSIZE Field Decoding

CTLx.SRC_MSIZE / Number of data items to be transferred(of width
CTLx.DEST_MSIZE CTLx.SRC_TR_WIDTH or CTLx.DST_TR_WIDTH)
000B 1
001B 4
010B 8
others reserved
Table 5-12 CTLx.SRC_TR_WIDTH and CTLx.DST_TR_WIDTH Field Decoding

CTLx.SRC_TR_WIDTH / Size (bits)
CTLx.DST_TR_WIDTH
000B 8
001B 16
010B 32
others reserved
Table 5-13 CTLx.TT_FC Field Decoding

CTLx.TT_FC Field Transfer Type Flow Controller
000B Memory to Memory GPDMA
001B Memory to Peripheral GPDMA
010B Peripheral to Memory GPDMA
011B Peripheral to Peripheral GPDMA
100B Peripheral to Memory Peripheral
101B Peripheral to Peripheral Source Peripheral

XMC4500
XMC4000 Family
Table 5-13 CTLx.TT_FC Field Decoding (contd)

CTLx.TT_FC Field Transfer Type Flow Controller
110B Memory to Peripheral Peripheral
111B Peripheral to Peripheral Destination Peripheral

XMC4500
XMC4000 Family
SSTAT
After each block transfer completes, hardware can retrieve the source status information
from the address pointed to by the contents of the SSTATAR register. This status
information is then stored in the SSTATx register and written out to the SSTATx register
location of the LLI before the start of the next block.
Note: This register is a temporary placeholder for the source status information on its
way to the SSTATx register location of the LLI. The source status information
should be retrieved by software from the SSTATx register location of the LLI, and
not by a read of this register over the GPDMA slave interface.
GPDMA0_CHx_SSTAT (x=0-1)
Source Status Register for Channel x
(20H + x*58H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SSTAT
rw

SSTAT [31:0] rw Source Status
retrieved by hardware from the address pointed to by the
contents of the SSTATAR register.

XMC4500
XMC4000 Family
DSTAT
After the completion of each block transfer, hardware can retrieve the destination status
information from the address pointed to by the contents of the DSTATAR register. This
status information is then stored in the DSTATx register and written out to the DSTATx
register location of the LLI before the start of the next block. This register does only exist
for channels 0 and 1, for other channels the read-back value is always 0.
Note: This register is a temporary placeholder for the destination status information on
its way to the DSTATx register location of the LLI. The destination status
information should be retrieved by software from the DSTATx register location of
the LLI and not by a read of this register over the GPDMA slave interface.
GPDMA0_CHx_DSTAT (x=0-1)
Destination Status Register for Channel x
(28H + x*58H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DSTAT
rw

DSTAT [31:0] rw Destination Status
retrieved by hardware from the address pointed to by the
contents of the DSTATAR register.

XMC4500
XMC4000 Family
SSTATAR
After the completion of each block transfer, hardware can retrieve the source status
information from the address pointed to by the contents of the SSTATARx register.
GPDMA0_CHx_SSTATAR (x=0-1)
Source Status Address Register for Channel x
(30H + x*58H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SSTATAR
rw

SSTATAR [31:0] rw Source Status Address
Pointer from where hardware can fetch the source status
information, which is registered in the SSTAT register
and written out to the SSTATx register location of the LLI
before the start of the next block.

XMC4500
XMC4000 Family
DSTATAR
After the completion of each block transfer, hardware can retrieve the destination status
information from the address pointed to by the contents of the DSTATARx register.
GPDMA0_CHx_DSTATAR (x=0-1)
Destination Status Address Register for Channel x
(38H + x*58H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DSTATAR
rw

DSTATAR [31:0] rw Destination Status Address
Pointer from where hardware can fetch the destination
status information, which is registered in the DSTAT
register and written out to the DSTATx register location of
the LLI before the start of the next block.

XMC4500
XMC4000 Family
CFG
These registers contain fields that configure the DMA transfer. The channel configuration
register remains fixed for all blocks of a multi-block transfer.
Note: You need to program this register prior to enabling the channel.
GPDMA0_CHx_CFGH (x=0-1)
Configuration Register High for Channel x
(44H + x*58H) Reset Value: 0000 0004H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SS_ DS_ FIFO
FCM
0 DEST_PER SRC_PER UPD UPD PROTCTL _MO
ODE
_EN _EN DE
r rw rw rw rw rw rw rw

Reset: 0D
DEST_PER [14:11] rw Destination Peripheral
Assigns a DLR line as hardware handshaking interface
to the destination of channel x if the
CFGLx.HS_SEL_DST field is 0; otherwise, this field is
ignored. The channel can then communicate with the
destination peripheral connected to that interface
through the assigned hardware handshaking interface.
Note: For correct DMA operation, only one peripheral
(source or destination) should be assigned to the
same handshaking interface.

XMC4500
XMC4000 Family

SRC_PER [10:7] rw Source Peripheral
to the source of channel x if the CFGLx.HS_SEL_SRC
field is 0; otherwise, this field is ignored. The channel
can then communicate with the source peripheral
connected to that interface through the assigned
hardware handshaking interface.
Note: For correct GPDMA operation, only one
peripheral (source or destination) should be
assigned to the same handshaking interface.
SS_UPD_EN 6 rw Source Status Update Enable
Source status information is fetched only from the
location pointed to by the SSTATAR register, stored in
the SSTAT register and written out to the SSTAT
location of the LLI if SS_UPD_EN is high.
DS_UPD_EN 5 rw Destination Status Update Enable
Destination status information is fetched only from the
location pointed to by the DSTATAR register, stored in
the DSTAT register and written out to the DSTATx
location of the LLI if DS_UPD_EN is high.
PROTCTL [4:2] rw Protection Control
Used to drive the AHB HPROT[3:1] bus. The AMBA
Specification recommends that the default value of
HPROT indicates a non-cached, non-buffered,
privileged data access. The reset value is used to
indicate such an access. HPROT[0] is tied high
because all transfers are data accesses, as there are
no opcode fetches.
There is a one-to-one mapping of these register bits to
the HPROT[3:1] master interface signals. Table 5-14
shows the mapping of bits in this field to the AHB
HPROT[3:1] bus.

XMC4500
XMC4000 Family

FIFO_MODE 1 rw FIFO Mode Select
Determines how much space or data needs to be
available in the FIFO before a burst transaction request
is serviced.
0B Space/data available for single AHB transfer of
the specified transfer width.
1B Data available is greater than or equal to half the
FIFO depth for destination transfers and space
available is greater than half the fifo depth for
source transfers. The exceptions are at the end of
a burst transaction request or at the end of a
block transfer.
FCMODE 0 rw Flow Control Mode
Determines when source transaction requests are
serviced when the Destination Peripheral is the flow
controller.
0B Source transaction requests are serviced when
they occur. Data pre-fetching is enabled.
1B Source transaction requests are not serviced until
a destination transaction request occurs. In this
mode, the amount of data transferred from the
source is limited so that it is guaranteed to be
transferred to the destination prior to block
termination by the destination. Data pre-fetching
is disabled.

XMC4500
XMC4000 Family
(44H + x*58H) Reset Value: 0000 0004H
(44H + x*58H) Reset Value: 0000 0004H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FIFO
FCM
0 DEST_PER SRC_PER 0 PROTCTL _MO
ODE
DE
r rw rw r rw rw rw

DEST_PER [14:11] rw Destination Peripheral
to the destination of channel x if the
CFGLx.HS_SEL_DST field is 0; otherwise, this field is
ignored. The channel can then communicate with the
destination peripheral connected to that interface
through the assigned hardware handshaking interface.
Note: For correct DMA operation, only one peripheral
(source or destination) should be assigned to the
same handshaking interface.
SRC_PER [10:7] rw Source Peripheral
to the source of channel x if the CFGLx.HS_SEL_SRC
field is 0; otherwise, this field is ignored. The channel
can then communicate with the source peripheral
connected to that interface through the assigned
hardware handshaking interface.
Note: For correct GPDMA operation, only one
peripheral (source or destination) should be
assigned to the same handshaking interface.

XMC4500
XMC4000 Family

0 [6:5] r Reserved
PROTCTL [4:2] rw Protection Control
Used to drive the AHB HPROT[3:1] bus. The AMBA
Specification recommends that the default value of
HPROT indicates a non-cached, non-buffered,
privileged data access. The reset value is used to
indicate such an access. HPROT[0] is tied high
because all transfers are data accesses, as there are
no opcode fetches.
There is a one-to-one mapping of these register bits to
the HPROT[3:1] master interface signals. Table 5-14
shows the mapping of bits in this field to the AHB
HPROT[3:1] bus.
FIFO_MODE 1 rw FIFO Mode Select
Determines how much space or data needs to be
available in the FIFO before a burst transaction request
is serviced.
0B Space/data available for single AHB transfer of
the specified transfer width.
1B Data available is greater than or equal to half the
FIFO depth for destination transfers and space
available is greater than half the fifo depth for
source transfers. The exceptions are at the end of
a burst transaction request or at the end of a
block transfer.
FCMODE 0 rw Flow Control Mode
Determines when source transaction requests are
serviced when the Destination Peripheral is the flow
controller.
0B Source transaction requests are serviced when
they occur. Data pre-fetching is enabled.
1B Source transaction requests are not serviced until
a destination transaction request occurs. In this
mode, the amount of data transferred from the
source is limited so that it is guaranteed to be
transferred to the destination prior to block
termination by the destination. Data pre-fetching
is disabled.

XMC4500
XMC4000 Family
GPDMA0_CHx_CFGL (x=0-1)
Configuration Register Low for Channel x
(40H + x*58H) Reset Value: 0000 0EX0H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
REL REL SRC DST
LOC
OAD OAD _HS _HS LOC
MAX_ABRST K_C
_DS _SR _PO _PO K_B
H
T C L L
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
HS_ HS_
FIFO CH_
LOCK_B_ LOCK_CH SEL SEL
_EM SUS CH_PRIOR 0
L _L _SR _DS
PTY P
C T
rw rw rw rw r rw rw r

RELOAD_D 31 rw Automatic Destination Reload
ST The DAR register can be automatically reloaded from
its initial value at the end of every block for multi-block
transfers. A new block transfer is then initiated. For
conditions under which this occurs, refer to Table 5-8.
RELOAD_S 30 rw Automatic Source Reload
RC The SAR register can be automatically reloaded from
its initial value at the end of every block for multi-block
transfers. A new block transfer is then initiated. For
conditions under which this occurs, refer to Table 5-8.
MAX_ABRS [29:20] rw Maximum AMBA Burst Length
T Maximum AMBA burst length that is used for DMA
transfers on this channel. A value of 0 indicates that
software is not limiting the maximum AMBA burst length
for DMA transfers on this channel.
SRC_HS_PO 19 rw Source Handshaking Interface Polarity
L 0B Active high
1B Active low
For information on this, refer to Section 5.2.3.

XMC4500
XMC4000 Family

DST_HS_PO 18 rw Destination Handshaking Interface Polarity
L 0B Active high
1B Active low
LOCK_B 17 rw Bus Lock Bit
When active, the AHB bus master signal hlock is
asserted for the duration specified in
CFGLx.LOCK_B_L. For more information, refer to
Section 5.2.11.1.
LOCK_CH 16 rw Channel Lock Bit
When the channel is granted control of the master bus
interface and if the CFGLx.LOCK_CH bit is asserted,
then no other channels are granted control of the
master bus interface for the duration specified in
CFGLx.LOCK_CH_L. Indicates to the master bus
interface arbiter that this channel wants exclusive
access to the master bus interface for the duration
specified in CFGLx.LOCK_CH_L.
LOCK_B_L [15:14] rw Bus Lock Level
Indicates the duration over which CFGLx.LOCK_B bit
applies.
00B Over complete DMA transfer
01B Over complete DMA block transfer
1xB Over complete DMA transaction
LOCK_CH_L [13:12] rw Channel Lock Level
Indicates the duration over which CFGLx.LOCK_CH bit
applies.

XMC4500
XMC4000 Family

HS_SEL_SR 11 rw Source Software or Hardware Handshaking Select
C This register selects which of the handshaking
interfaces - hardware or software - is active for source
requests on this channel.
0B Hardware handshaking interface. Software-
initiated transaction requests are ignored.
1B Software handshaking interface. Hardware-
If the source peripheral is memory, then this bit is
ignored.
HS_SEL_DS 10 rw Destination Software or Hardware Handshaking
T Select
This register selects which of the handshaking
interfaces - hardware or software - is active for
destination requests on this channel.
If the destination peripheral is memory, then this bit is
ignored.
FIFO_EMPT 9 r Indicates if there is data left in the channel FIFO
Y Can be used in conjunction with CFGLx.CH_SUSP to
cleanly disable a channel.
1B Channel FIFO empty
0B Channel FIFO not empty
CH_SUSP 8 rw Channel Suspend
Suspends all DMA data transfers from the source until
this bit is cleared. There is no guarantee that the current
transaction will complete. Can also be used in
conjunction with CFGLx.FIFO_EMPTY to cleanly
disable a channel without losing any data.
0B Not suspended.
1B Suspend DMA transfer from the source.

XMC4500
XMC4000 Family

CH_PRIOR [7:5] rw Channel priority
A priority of 7 is the highest priority, and 0 is the lowest.
The value programmed to this field must be within 0 and
7. A programmed value outside this range will cause
erroneous behavior.
Reset: Channel Number
For example:
Chan0 = 000B
Chan1 = 001B
0 [4:0] r Reserved
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SRC DST
LOC
_HS _HS LOC
0 MAX_ABRST K_C
_PO _PO K_B
H
L L
r rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
HS_ HS_
FIFO CH_
LOCK_B_ LOCK_CH SEL SEL
_EM SUS CH_PRIOR 0
L _L _SR _DS
PTY P
C T
rw rw rw rw r rw rw r

MAX_ABRS [29:20] rw Maximum AMBA Burst Length
T Maximum AMBA burst length that is used for DMA
transfers on this channel. A value of 0 indicates that
software is not limiting the maximum AMBA burst length
for DMA transfers on this channel.

XMC4500
XMC4000 Family

SRC_HS_PO 19 rw Source Handshaking Interface Polarity
L 0B Active high
1B Active low
DST_HS_PO 18 rw Destination Handshaking Interface Polarity
L 0B Active high
1B Active low
LOCK_B 17 rw Bus Lock Bit
When active, the AHB bus master signal hlock is
asserted for the duration specified in
CFGLx.LOCK_B_L. For more information, refer to
Section 5.2.11.1.
LOCK_CH 16 rw Channel Lock Bit
When the channel is granted control of the master bus
interface and if the CFGLx.LOCK_CH bit is asserted,
then no other channels are granted control of the
master bus interface for the duration specified in
CFGLx.LOCK_CH_L. Indicates to the master bus
interface arbiter that this channel wants exclusive
access to the master bus interface for the duration
specified in CFGLx.LOCK_CH_L.
LOCK_B_L [15:14] rw Bus Lock Level
Indicates the duration over which CFGLx.LOCK_B bit
applies.
LOCK_CH_L [13:12] rw Channel Lock Level
Indicates the duration over which CFGLx.LOCK_CH bit
applies.

XMC4500
XMC4000 Family

HS_SEL_SR 11 rw Source Software or Hardware Handshaking Select
C This register selects which of the handshaking
interfaces - hardware or software - is active for source
requests on this channel.
If the source peripheral is memory, then this bit is
ignored.
HS_SEL_DS 10 rw Destination Software or Hardware Handshaking
T Select
This register selects which of the handshaking
interfaces - hardware or software - is active for
destination requests on this channel.
If the destination peripheral is memory, then this bit is
ignored.
FIFO_EMPT 9 r Indicates if there is data left in the channel FIFO
Y Can be used in conjunction with CFGLx.CH_SUSP to
cleanly disable a channel.
1B Channel FIFO empty
0B Channel FIFO not empty
CH_SUSP 8 rw Channel Suspend
Suspends all DMA data transfers from the source until
this bit is cleared. There is no guarantee that the current
transaction will complete. Can also be used in
conjunction with CFGLx.FIFO_EMPTY to cleanly
disable a channel without losing any data.
0B Not suspended.
1B Suspend DMA transfer from the source.

XMC4500
XMC4000 Family

CH_PRIOR [7:5] rw Channel priority
A priority of 7 is the highest priority, and 0 is the lowest.
The value programmed to this field must be within 0 and
7. A programmed value outside this range will cause
erroneous behavior.
Reset: Channel Number
For example:
Chan0 = 000B
Chan1 = 001B
0 [4:0] r Reserved
Table 5-14 PROTCTL field to HPROT Mapping

1B HPROT[0]
CFGHx.PROTCTL[1] HPROT[1]

XMC4500
XMC4000 Family
SGR
The Source Gather register contains two fields:
Source gather count field (SGRx.SGC) - Specifies the number of contiguous source
transfers of CTL.SRC_TR_WIDTH between successive gather intervals. This is
defined as a gather boundary.
Source gather interval field (SGRx.SGI) - Specifies the source address
increment/decrement in multiples of CTL.SRC_TR_WIDTH on a gather boundary
when gather mode is enabled for the source transfer.
The CTL.SINC field controls whether the address increments or decrements. When the
CTL.SINC field indicates a fixed-address control, then the address remains constant
throughout the transfer and the SGRx register is ignored. For more information, see
Section 5.2.13.
GPDMA0_CHx_SGR (x=0-1)
Source Gather Register for Channel x
(48H + x*58H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SGC SGI
rw rw

SGC [31:20] rw Source gather count
Source contiguous transfer count between successive
gather boundaries.
SGI [19:0] rw Source gather interval

XMC4500
XMC4000 Family
DSR
The Destination Scatter register contains two fields:
Destination scatter count field (DSRx.DSC) - Specifies the number of contiguous
destination transfers of CTL.DST_TR_WIDTH between successive scatter
boundaries.
Destination scatter interval field (DSRx.DSI) - Specifies the destination address
increment/decrement in multiples of CTL.DST_TR_WIDTH on a scatter boundary
when scatter mode is enabled for the destination transfer.
The CTL.DINC field controls whether the address increments or decrements. When the
CTL.DINC field indicates a fixed address control, then the address remains constant
throughout the transfer and the DSRx register is ignored. For more information, see
Section 5.2.13.
GPDMA0_CHx_DSR (x=0-1)
Destination Scatter Register for Channel x
(50H + x*58H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DSC DSI
rw rw

DSC [31:20] rw Destination scatter count
Destination contiguous transfer count between successive
scatter boundaries.
DSI [19:0] rw Destination scatter interval

XMC4500
XMC4000 Family
5.6.3 Interrupt Registers

The following sections describe the registers pertaining to interrupts, their status, and
how to clear them. For each channel, there are five types of interrupt sources:
IntBlock - Block Transfer Complete Interrupt. This interrupt is generated on DMA
block transfer completion to the destination peripheral.
IntDstTran - Destination Transaction Complete Interrupt
This interrupt is generated after completion of the last AHB transfer of the requested
single/burst transaction from the handshaking interface (either the hardware or
software handshaking interface) on the destination side.
Note: If the destination for a channel is memory, then that channel will never generate
the IntDstTran interrupt. Because of this, the corresponding bit in this field will not
be set.
IntErr - Error Interrupt
This interrupt is generated when an ERROR response is received from an AHB slave
on the HRESP bus during a DMA transfer. In addition, the DMA transfer is cancelled
and the channel is disabled.
IntSrcTran - Source Transaction Complete Interrupt
This interrupt is generated after completion of the last AHB transfer of the requested
single/burst transaction from the handshaking interface (either the hardware or
software handshaking interface) on the source side.
Note: If the source or destination is memory, then IntSrcTran/IntDstTran interrupts
should be ignored, as there is no concept of a "DMA transaction level" for memory.
IntTfr - DMA Transfer Complete Interrupt
This interrupt is generated on DMA transfer completion to the destination peripheral.
There are several groups of interrupt-related registers:
Interrupt Raw Status Registers
Interrupt Status Registers
Interrupt Mask Registers
Interrupt Clear Registers
Combined Interrupt Status Register
When a channel has been enabled to generate interrupts, the following is true:
Interrupt events are stored in the Raw Status registers.
The contents of the Raw Status registers are masked with the contents of the Mask
registers.
The masked interrupts are stored in the Status registers.
The contents of the Status registers are used to drive the int_* port signals.
Writing to the appropriate bit in the Clear registers clears an interrupt in the Raw
Status registers and the Status registers on the same clock cycle.

XMC4500
XMC4000 Family
The contents of each of the five Status registers is ORed to produce a single bit for each
interrupt type in the Combined Status register; that is, STATUSINT.
Note: For interrupts to propagate past the raw* interrupt register stage, CTL.INT_EN
must be set to 1B, and the relevant interrupt must be unmasked in the mask*
interrupt register.

XMC4500
XMC4000 Family
Interrupt Raw Status Registers

Interrupt events are stored in these Raw Interrupt Status registers before masking:
RAWBLOCK, RawDstTran, RawErr, RawSrcTran, and RAWTFR. Each Raw Interrupt
Status register has a bit allocated per channel; for example, RAWTFR[2] is the Channel
2 raw transfer complete interrupt.
Each bit in these registers is cleared by writing a 1 to the corresponding location in the
CLEARTFR, CLEARBLOCK, CLEARSRCTRAN, CLEARDSTTRAN, CLEARERR
registers.
Note: Write access is available to these registers for software testing purposes only.
Under normal operation, writes to these registers are not recommended.
RAWTFR
Raw DMA Transfer Complete Interrupt Status.
RAWBLOCK
Raw Block Transfer Complete Interrupt Status.
RAWSRCTRAN
Raw Source Transaction Complete Interrupt Status.
RAWDSTTRAN
Raw Block Transfer Complete Interrupt Status.
RAWERR
Raw Error Interrupt Status.

XMC4500
XMC4000 Family
GPDMA0_RAWTFR
Raw IntTfr Status (2C0H) Reset Value: 0000 0000H
GPDMA0_RAWBLOCK
Raw IntBlock Status (2C8H) Reset Value: 0000 0000H
GPDMA0_RAWSRCTRAN
Raw IntSrcTran Status (2D0H) Reset Value: 0000 0000H
GPDMA0_RAWDSTTRAN
Raw IntBlock Status (2D8H) Reset Value: 0000 0000H
GPDMA0_RAWERR
Raw IntErr Status (2E0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
C C C C C C C C
0 H H H H H H H H
7 6 5 4 3 2 1 0
r rw rw rw rw rw rw rw rw

0 [31:8] r Reserved
CHx x rw Raw Interrupt Status for channel x
(x=0-7)
GPDMA1_RAWTFR
Raw IntTfr Status (2C0H) Reset Value: 0000 0000H
GPDMA1_RAWBLOCK
Raw IntBlock Status (2C8H) Reset Value: 0000 0000H
GPDMA1_RAWSRCTRAN
Raw IntSrcTran Status (2D0H) Reset Value: 0000 0000H
GPDMA1_RAWDSTTRAN
Raw IntBlock Status (2D8H) Reset Value: 0000 0000H
GPDMA1_RAWERR
Raw IntErr Status (2E0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
C C C C
0 H H H H
3 2 1 0
r rw rw rw rw

XMC4500
XMC4000 Family

0 [31:4] r Reserved
CHx x rw Raw Interrupt Status for channel x
(x=0-3)

XMC4500
XMC4000 Family

All interrupt events from all channels are stored in these Interrupt Status registers after
masking: STATUSBLOCK, STATUSDSTTRAN, STATUSERR, STATUSSRCTRAN,
and STATUSTFR. Each Interrupt Status register has a bit allocated per channel; for
example, STATUSTFR[2] is the Channel 2 status transfer complete interrupt. The
contents of these registers are used to generate the interrupt signals (int or int_n bus,
depending on interrupt polarity) leaving the GPDMA.
STATUSTFR
DMA Transfer Complete Interrupt Status.
STATUSBLOCK
Block Transfer Complete Interrupt Status.
STATUSSRCTRAN
Source Transaction Complete Interrupt Status.
STATUSDSTTRAN
Block Transfer Complete Interrupt Status.
STATUSERR
Error Interrupt Status.
GPDMA0_STATUSTFR
IntTfr Status (2E8H) Reset Value: 0000 0000H
GPDMA0_STATUSBLOCK
IntBlock Status (2F0H) Reset Value: 0000 0000H
GPDMA0_STATUSSRCTRAN
IntSrcTran Status (2F8H) Reset Value: 0000 0000H
GPDMA0_STATUSDSTTRAN
IntBlock Status (300H) Reset Value: 0000 0000H
GPDMA0_STATUSERR
IntErr Status (308H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
C C C C C C C C
0 H H H H H H H H
7 6 5 4 3 2 1 0
r r r r r r r r r

XMC4500
XMC4000 Family

0 [31:8] r Reserved
CHx x r Interrupt Status for channel x
(x=0-7)
GPDMA1_STATUSTFR
IntTfr Status (2E8H) Reset Value: 0000 0000H
GPDMA1_STATUSBLOCK
IntBlock Status (2F0H) Reset Value: 0000 0000H
GPDMA1_STATUSSRCTRAN
IntSrcTran Status (2F8H) Reset Value: 0000 0000H
GPDMA1_STATUSDSTTRAN
GPDMA1_STATUSERR
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
C C C C
0 H H H H
3 2 1 0
r r r r r

0 [31:4] r Reserved
CHx x r Interrupt Status for channel x
(x=0-3)

XMC4500
XMC4000 Family
Interrupt Mask Registers

The contents of the Raw Status registers are masked with the contents of the Mask
registers: MASKBLOCK, MASKDSTTRAN, MASKERR, MASKSRCTRAN, and
MASKTFR. Each Interrupt Mask register has a bit allocated per channel; for example,
MASKTFR[2] is the mask bit for the Channel 2 transfer complete interrupt.
When the source peripheral of DMA channel i is memory, then the source transaction
complete interrupt, MASKSRCTRAN[z], must be masked to prevent an erroneous
triggering of an interrupt on the int_combined signal. Similarly, when the destination
peripheral of DMA channel i is memory, then the destination transaction complete
interrupt, MASKDSTTRAN[i], must be masked to prevent an erroneous triggering of an
interrupt on the int_combined(_n) signal.
A channel INT_MASK bit will be written only if the corresponding mask write enable bit
in the INT_MASK_WE field is asserted on the same AHB write transfer. This allows
software to set a mask bit without performing a read-modified write operation. For
example, writing hex 01x1 to the MASKTFR register writes a 1 into MASKTFR[0], while
MASKTFR[7:1] remains unchanged. Writing hex 00xx leaves MASKTFR[7:0]
unchanged.
Writing a 1 to any bit in these registers unmasks the corresponding interrupt, thus
allowing the GPDMA to set the appropriate bit in the Status registers and int_* port
signals.
MASKTFR
Mask for Raw DMA Transfer Complete Interrupt Status.
MASKBLOCK
Mask for Raw Block Transfer Complete Interrupt Status.
MASKSRCTRAN
Mask for Raw Source Transaction Complete Interrupt Status.
MASKDSTTRAN
Mask for Raw Block Transfer Complete Interrupt Status.
MASKERR
Mask for Raw Error Interrupt Status.

XMC4500
XMC4000 Family
GPDMA0_MASKTFR
Mask for Raw IntTfr Status (310H) Reset Value: 0000 0000H
GPDMA0_MASKBLOCK
Mask for Raw IntBlock Status (318H) Reset Value: 0000 0000H
GPDMA0_MASKSRCTRAN
Mask for Raw IntSrcTran Status (320H) Reset Value: 0000 0000H
GPDMA0_MASKDSTTRAN
GPDMA0_MASKERR
Mask for Raw IntErr Status (330H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W W W W W
E_ E_ E_ E_ E_ E_ E_ E_ C C C C C C C C
0 C C C C C C C C H H H H H H H H
H H H H H H H H 7 6 5 4 3 2 1 0
7 6 5 4 3 2 1 0
r w w w w w w w w rw rw rw rw rw rw rw rw

WE_CHx 8+x w Write enable for mask bit of channel x
(x=0-7) 0B write disabled
1B write enabled
CHx x rw Mask bit for channel x
(x=0-7) 0B masked
1B unmasked

XMC4500
XMC4000 Family
GPDMA1_MASKTFR
Mask for Raw IntTfr Status (310H) Reset Value: 0000 0000H
GPDMA1_MASKBLOCK
GPDMA1_MASKSRCTRAN
Mask for Raw IntSrcTran Status (320H) Reset Value: 0000 0000H
GPDMA1_MASKDSTTRAN
GPDMA1_MASKERR
Mask for Raw IntErr Status (330H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W
E_ E_ E_ E_ C C C C
0 C C C C 0 H H H H
H H H H 3 2 1 0
3 2 1 0
r w w w w r rw rw rw rw

WE_CHx 8+ x w Write enable for mask bit of channel x
1B write enabled
0 [7:4] r Reserved
CHx x rw Mask bit for channel x
(x=0-3) 0B masked
1B unmasked

XMC4500
XMC4000 Family
Interrupt Clear Registers

Each bit in the Raw Status and Status registers is cleared on the same cycle by writing
a 1 to the corresponding location in the Clear registers: CLEARBLOCK,
CLEARDSTTRAN, CLEARERR, CLEARSRCTRAN, and CLEARTFR. Each Interrupt
Clear register has a bit allocated per channel; for example, CLEARTFR[2] is the clear bit
for the Channel 2 transfer complete interrupt. Writing a 0 has no effect. These registers
are not readable.
CLEARTFR
Clear DMA Transfer Complete Interrupt Status and Raw Status.
CLEARBLOCK
Clear Block Transfer Complete Interrupt Status and Raw Status.
CLEARSRCTRAN
Clear Source Transaction Complete Interrupt Status and Raw Status.
CLEARDSTTRAN
Clear Block Transfer Complete Interrupt Status and Raw Status.
CLEARERR
Clear Error Interrupt Status and Raw Status.
GPDMA0_CLEARTFR
IntTfr Status (338H) Reset Value: 0000 0000H
GPDMA0_CLEARBLOCK
GPDMA0_CLEARSRCTRAN
IntSrcTran Status (348H) Reset Value: 0000 0000H
GPDMA0_CLEARDSTTRAN
GPDMA0_CLEARERR
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
C C C C C C C C
0 H H H H H H H H
7 6 5 4 3 2 1 0
r w w w w w w w w

XMC4500
XMC4000 Family

0 [31:8] r Reserved
CHx x w Clear Interrupt Status and Raw Status for channel x
(x=0-7) 0B no effect
1B clear status
GPDMA1_CLEARTFR
IntTfr Status (338H) Reset Value: 0000 0000H
GPDMA1_CLEARBLOCK
GPDMA1_CLEARSRCTRAN
IntSrcTran Status (348H) Reset Value: 0000 0000H
GPDMA1_CLEARDSTTRAN
GPDMA1_CLEARERR
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
C C C C
0 H H H H
3 2 1 0
r w w w w

0 [31:4] r Reserved
CHx x w Clear Interrupt Status and Raw Status for channel x
(x=0-3) 0B no effect
1B clear status
Combined Interrupt Status Register

The contents of each of the five Status registers - STATUSTFR, STATUSBLOCK,
STATUSSRCTRAN, STATUSDSTTRAN, STATUSERR - is ORed to produce a single
bit for each interrupt type in the Combined Status register (STATUSINT). This register is
read-only.

XMC4500
XMC4000 Family
GPDMA0_STATUSINT
Combined Interrupt Status Register (360H) Reset Value: 0000 0000H
GPDMA1_STATUSINT
Combined Interrupt Status Register (360H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DST SRC BLO
0 ERR TFR
T T CK
r r r r r r

0 [31:5] r Reserved
ERR 4 r OR of the contents of STATUSERR register
DSTT 3 r OR of the contents of STATUSDSTTRAN register
SRCT 2 r OR of the contents of STATUSSRCTRAN register
BLOCK 1 r OR of the contents of STATUSBLOCK register
TFR 0 r OR of the contents of STATUSTFR register

XMC4500
XMC4000 Family
5.6.4 Software Handshaking Registers

The registers that comprise the software handshaking registers allow software to initiate
single or burst transaction requests in the same way that handshaking interface signals
do in hardware.
Setting CFG.HS_SEL_SRC to 1 enables software handshaking on the source of channel
x. Setting CFG.HS_SEL_DST to 1 enables software handshaking on the destination of
channel x.
REQSRCREG
A bit is assigned for each channel in this register. REQSRCREG[n] is ignored when
software handshaking is not enabled for the source of channel n.
A channel SRC_REQ bit is written only if the corresponding channel write enable bit in
the SRC_REQ_WE field is asserted on the same AHB write transfer, and if the channel
is enabled in the CHENREG register. For example, writing hex 0101 writes a 1 into
REQSRCREG[0], while REQSRCREG[7:1] remains unchanged. Writing hex 00xx
leaves REQSRCREG[7:0] unchanged. This allows software to set a bit in the
REQSRCREG register without performing a read-modified write operation.
The functionality of this register depends on whether the source is a flow control
peripheral or not. For a description of when the source is not a flow controller, refer to
Section 5.2.7.4.
GPDMA0_REQSRCREG
Source Software Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W W W W W
H H H H H H H H 7 6 5 4 3 2 1 0
7 6 5 4 3 2 1 0

WE_CHx 8+x w Source request write enable for channel x
1B write enabled
CHx x rw Source request for channel x
(x=0-7)

XMC4500
XMC4000 Family
GPDMA1_REQSRCREG
Source Software Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W
E_ E_ E_ E_ C C C C
0 C C C C 0 H H H H
H H H H 3 2 1 0
3 2 1 0

1B write enabled
0 [7:4] r Reserved
(x=0-3)
REQDSTREG
A bit is assigned for each channel in this register. REQDSTREG[n] is ignored when
A channel DST_REQ bit is written only if the corresponding channel write enable bit in
the DST_REQ_WE field is asserted on the same AHB write transfer, and if the channel
is enabled in the CHENREG register.
The functionality of this register depends on whether the destination is a flow control
peripheral or not. For a description of when the destination is not a flow controller, refer
to Section 5.2.7.4.

XMC4500
XMC4000 Family
GPDMA0_REQDSTREG
Destination Software Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W W W W W
H H H H H H H H 7 6 5 4 3 2 1 0
7 6 5 4 3 2 1 0

1B write enabled
(x=0-7)
GPDMA1_REQDSTREG
Destination Software Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W
E_ E_ E_ E_ C C C C
0 C C C C 0 H H H H
H H H H 3 2 1 0
3 2 1 0

1B write enabled

XMC4500
XMC4000 Family

0 [7:4] r Reserved
(x=0-3)
SGLREQSRCREG
A bit is assigned for each channel in this register. SGLREQSRCREG[n] is ignored when
A channel SRC_SGLREQ bit is written only if the corresponding channel write enable bit
in the SRC_SGLREQ_WE field is asserted on the same AHB write transfer, and if the
channel is enabled in the CHENREG register.
The functionality of this register depends on whether the source is a flow control
peripheral or not. For a description of when the source is not a flow controller, refer to
Section 5.2.7.4.
GPDMA0_SGLREQSRCREG
Single Source Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W W W W W
H H H H H H H H 7 6 5 4 3 2 1 0
7 6 5 4 3 2 1 0

1B write enabled
(x=0-7)

XMC4500
XMC4000 Family
GPDMA1_SGLREQSRCREG
Single Source Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W
E_ E_ E_ E_ C C C C
0 C C C C 0 H H H H
H H H H 3 2 1 0
3 2 1 0

1B write enabled
0 [7:4] r Reserved
(x=0-3)
SGLREQDSTREG
A bit is assigned for each channel in this register. SGLREQDSTREG[n] is ignored when
software handshaking is not enabled for the destination of channel n.
A channel DST_SGLREQ bit is written only if the corresponding channel write enable bit
in the DST_SGLREQ_WE field is asserted on the same AHB write transfer, and if the
channel is enabled in the CHENREG register.
The functionality of this register depends on whether the destination is a flow control
peripheral or not. For a description of when the destination is not a flow controller, refer
to Section 5.2.7.4.

XMC4500
XMC4000 Family
GPDMA0_SGLREQDSTREG
Single Destination Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W W W W W
H H H H H H H H 7 6 5 4 3 2 1 0
7 6 5 4 3 2 1 0

1B write enabled
(x=0-7)
GPDMA1_SGLREQDSTREG
Single Destination Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W
E_ E_ E_ E_ C C C C
0 C C C C 0 H H H H
H H H H 3 2 1 0
3 2 1 0

1B write enabled

XMC4500
XMC4000 Family

0 [7:4] r Reserved
(x=0-3)
LSTSRCREG
A bit is assigned for each channel in this register. LSTSRCREG[n] is ignored when
software handshaking is not enabled for the source of channel n, or when the source of
channel n is not a flow controller.
A channel LSTSRC bit is written only if the corresponding channel write enable bit in the
LSTSRC_WE field is asserted on the same AHB write transfer, and if the channel is
enabled in the CHENREG register.
GPDMA0_LSTSRCREG
Last Source Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W W W W W
H H H H H H H H 7 6 5 4 3 2 1 0
7 6 5 4 3 2 1 0

WE_CHx 8+x w Source last transaction request write enable for
(x=0-7) channel x
0B write disabled
1B write enabled
CHx x rw Source last request for channel x
(x=0-7) 0B Not last transaction in current block
1B Last transaction in current block

XMC4500
XMC4000 Family
GPDMA1_LSTSRCREG
Last Source Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W
E_ E_ E_ E_ C C C C
0 C C C C 0 H H H H
H H H H 3 2 1 0
3 2 1 0

WE_CHx 8+x w Source last transaction request write enable for
(x=0-3) channel x
0B write disabled
1B write enabled
0 [7:4] r Reserved
CHx x rw Source last request for channel x
LSTDSTREG
A bit is assigned for each channel in this register. LSTDSTREG[n] is ignored when
software handshaking is not enabled for the destination of channel n or when the
destination of channel n is not a flow controller.
A channel LSTDST bit is written only if the corresponding channel write enable bit in the
LSTDST_WE field is asserted on the same AHB write transfer, and if the channel is
enabled in the CHENREG register.

XMC4500
XMC4000 Family
GPDMA0_LSTDSTREG
Last Destination Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W W W W W
H H H H H H H H 7 6 5 4 3 2 1 0
7 6 5 4 3 2 1 0

WE_CHx 8+x w Destination last transaction request write enable for
(x=0-7) channel x
0B write disabled
1B write enabled
CHx x rw Destination last request for channel x
GPDMA1_LSTDSTREG
Last Destination Transaction Request Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
W W W W
E_ E_ E_ E_ C C C C
0 C C C C 0 H H H H
H H H H 3 2 1 0
3 2 1 0

WE_CHx 8+x w Destination last transaction request write enable for
(x=0-3) channel x
0B write disabled
1B write enabled

XMC4500
XMC4000 Family

0 [7:4] r Reserved
CHx x rw Destination last request for channel x

XMC4500
XMC4000 Family
5.6.5 Miscellaneous GPDMA Registers
ID
This is the GPDMA ID register, which is a read-only register that reads back the
hardcoded module ID number.
GPDMA0_ID
GPDMA0 ID Register (3A8H) Reset Value: 00AF C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VALUE

VALUE [31:0] r Hardcoded GPDMA Peripheral ID
GPDMA1_ID
GPDMA1 ID Register (3A8H) Reset Value: 00B0 C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
VALUE
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VALUE

VALUE [31:0] r Hardcoded GPDMA Peripheral ID
TYPE
This is the GPDMA Component Type register, which is a read-only register that specifies
the type of the packaged component.

XMC4500
XMC4000 Family
GPDMA0_TYPE
GPDMA Component Type (3F8H) Reset Value: 4457 1110H
GPDMA1_TYPE
GPDMA Component Type (3F8H) Reset Value: 4457 1110H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VALUE

VALUE [31:0] r Component Type
number = 44_57_11_10.
VERSION
This is the GPDMA Component Version register, which is a read-only register that
specifies the version of the packaged component.
GPDMA0_VERSION
DMA Component Version (3FCH) Reset Value: 3231 342AH
GPDMA1_VERSION
DMA Component Version (3FCH) Reset Value: 3231 342AH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VALUE

VALUE [31:0] r Version number of the component

XMC4500
XMC4000 Family
6 Flexible CRC Engine (FCE)

The FCE provides a parallel implementation of Cyclic Redundancy Code (CRC)
algorithms. The current FCE version for the XMC4500 microcontroller implements the
IEEE 802.3 ethernet CRC32, the CCITT CRC16 and the SAE J1850 CRC8 polynomials.
The primary target of FCE is to be used as an hardware acceleration engine for software
applications or operating systems services using CRC signatures.
The FCE operates as a standard peripheral bus slave and is fully controlled through a
set of configuration and control registers. The different CRC algorithms are independent
from each other, they can be used concurrently by different software tasks.
Note: The FCE kernel register names described in Registers on Page 6-11 are
referenced in a product Reference Manual by the module name prefix FCE_.
Input documents
[5] A painless guide to CRC Error Detection Algorithms, Ross N. Williams
[6] 32-Bit Cyclic Redundancy Codes for Internet Applications, Philip Koopman,
International Conference on Dependable Systems and Networks (DSN), 2002
Related standards and norms

[7] IEEE 802.3 Ethernet 32-bits CRC
Table 6-1 FCE Abbreviations

CRC Cyclic Redundancy Checksum
FCE Flexible CRC Engine
IR Input Register
RES Result
STS Status
CFG Configuration
6.1 Overview
This chapter provides on overview of the features, applications and architecture of the
FCE module.
6.1.1 Features
The FCE provides the following features:
The FCE implements the following CRC polynomials:

FCE, V2.7 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
CRC kernel 0 and 1: IEEE 802.3 CRC32 ethernet polynomial: 0x04C11DB71) -

x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1
CRC kernel 2: CCITT CRC16 polynomial: 0x1021 - x16+x12+x5+1
CRC kernel 3: SAE J1850 CRC8 polynomial: 0x1D - x8+x4+x3+x2+1
Parallel CRC implementation
Data blocks to be computed by FCE shall be a multiple of the polynomial degree
Start address of Data blocks to be computed by FCE shall be aligned to the
polynomial degree
Register Interface:
Input Register
CRC Register
Configuration Registers enabling to control the CRC operation and perform
automatic checksum checks at the end of a message.
Extended register interface to control reliability of FCE execution in safety
applications.
Error notification scheme via dedicated interrupt node for:
Transient error detection: error interrupt generation (maskable) with local status
register (cleared by software)
Checksum failure: error interrupt generation (maskable) with local status register
(cleared by software)
FCE provides one interrupt line to the interrupt system. Each CRC engine has its own
set of flag registers.
6.1.2 Application Mapping

Among other applications, CRC algorithms are commonly used to calculate message
signatures to:
Check message integrity during transport over communication channels like internal
buses or interfaces between microcontrollers
Sign blocks of data residing in variable or invariable storage elements
Compute signatures for program flow monitoring
One important property to be taken into account by the application when choosing a
polynomial is the hamming distance: see Chapter 6.9.
6.1.3 Block Diagram

The FCE is a standard peripheral slave module which is controlled over a set of memory
mapped registers. The FCE is fully synchronous with the CPU clock and runs with a 1:1
clock ratio.
1) The polynomial hexadecimal representation covers the coefficients (degree - 1) down to 0.

XMC4500
XMC4000 Family
Depending on the hardware configuration the FCE may implement more CRC kernels
with different CRC polynomials. The specific configuration for the XMC4500
microcontroller is shown in the Figure 6-1 FCE Block Diagram on Page 6-3.
Interrupt System Control Unit

Peripheral Bridge
Control (SCU)
fCPU
Reset
SR0
CRC Kernel CRC Kernel CRC Kernel CRC Kernel

Registers Registers Registers Registers
CRC 32-bit CRC 32-bit CRC 16-bit CRC 8-bit
Ethernet Ethernet
IEEE 802.3 IEEE 802.3 CRC-CCITT SAE-J1850
0x04C11DB7 0x04C11DB7 0x1021 0x1D
CRC Kernel 0 CRC Kernel 1 CRC Kernel 2 CRC Kernel 3

FCE
Figure 6-1 FCE Block Diagram

Every CRC kernel will present the same hardware and software architecture. The rest of
this document will focus only on the description of the generic CRC kernel architecture.
In a multi-kernel implementation the interrupt lines are ored together, the FCE only
presents a single interrupt node to the system. Each CRC kernel implements a status
register that enables the software to identify which interrupt source is active. Please refer
to the STSm (m = 0-3) register for a detailed description of the status and interrupt
handling.

.
A checksum algorithm based on CRC polynomial division is characterized by the
following properties:
1. polynomial degree (e.g. 32, that represents the highest power of two of the
polynomial)
2. polynomial (e.g. 0x04C11DB7: the 33rd bit is omitted because always equal to 1)
3. init value: the initial value of the CRC register

XMC4500
XMC4000 Family
4. input data reflected: indicates if each byte of the input parallel data is reflected before
being used to compute the CRC
5. result data reflected: indicates if the final CRC value is reflected or not
6. XOR value: indicates if a final XOR operation is done before returning the CRC result
All the properties are fixed once a polynomial has been chosen. However the FCE
provides the capability to control the two reflection steps and the final XOR through the
CFG register. The reset values are compatible with the implemented algorithm. The final
XOR control enables to select either 0xFFFFFFFF or 0x00000000 to be XORed with the
POST_CRC1 value. These two values are those used by the most common CRC
polynomials.
Note: The reflection steps and final XOR do not modify the properties of the CRC
algorithm in terms of error detection, only the CRC final signature is affected.
The next two figures provides an overview of the control and status features of a CRC
kernel.
CRC Configuration Register

Interrupt generation control
[0] Interrupt Control
CMI: Enables CRC Mismatch Interrupt
CEI: Enables Configuration Error Interrupt
LEI: Enables Length Error Interrupt
BEI: Enables Bus Error Interrupt
CRC operation control

[4] CCE: CRC Check Enable
[5] ALR: Automatic Length Reload
CRC algorithm control

[8] REFIN: Input byte reflection enable
[9] REFOUT: Final CRC reflexion enable
[10] XOROUT: selects value for final xor
Figure 6-2 CRC kernel configuration register

XMC4500
XMC4000 Family
CRC Status Register
[0] Interrupt Status

CMF: CRC Mismatch Flag
CEF: Configuration Error Flag
LEF: Length Error Flag

BEF: Bus Error Flag
Figure 6-3 CRC kernel status register
6.2.1 Basic Operation

The software must first ensure that the CRC kernel is properly configured, especially the
initial CRC value written via the CRC register. Then, it writes as many times as
necessary into the IR register according to the length of the message. The resulting
signature is stored in the CRC engine result register, RESm, which can be read by the
software.
Depending on the CRC kernel accesses by software the following rules apply:
When accessing a CRC kernel of degree <N> only the bits N-1 down to 0 are used
by the CRC kernel. The upper bits are ignored on write. When reading from a CRC
kernel register the non-used upper bits are set to 0.
6.2.2 Automatic Signature Check

The automatic signature check compares the signature at the end of a message with the
expected signature configured in the CHECK register. In case of a mismatch, an event
is generated (see Section 6.3. This feature is enabled by the CFG.CCE bit field (see
CFGm (m = 0-3) register).
If the software whishes to use this feature, the LENGTH register and CHECK registers
must be configured with respectively the length as number of words of the message and
the expected signature (CHECK). The word length is defined by the degree of the
polynomial used. The CHECK value takes into account the final CRC reflection and XOR
operation.
When the CFG.CCE bit field is set, every time the IR register is written, the LENGH
register is decremented by one until it reaches zero. The hardware monitors the
transition of the LENGTH register from 1 to 0 to detect the end of the message and
proceed with the comparison of the result register RESvalue with the CHECK register
value. If the automatic length reload feature is enabled by the CFG.ALR bit field (see

XMC4500
XMC4000 Family
CFGm (m = 0-3)), the LENGTH register is reinitialized with the previously configured
value. This feature is especially suited when the FCE is used in combination with a DMA
engine.
In the case the automatic length reload feature is not enabled, if LENGTH is already at
zero but software still writes to IR (by mistake) every bit of the LENGTH should be set to
1 and hold this value until software initializes it again for the processing of a new
message. In such case the STS.LEF (Length Error Flag) should be set and an interrupt
generated if the CFG.LEI (Length Error Interrupt) is set.
Usually, the CRC signature of a message M0 is computed and appended to M0 to form
the message M1 which is transmitted. One interesting property of CRCs is that the CRC
signature of M1 shall be zero. This property is particularly useful when automatically
checking the signature of data blocks of fixed length with the automatic length reload
enabled. LENGTH should be loaded with the length of M1 and CHECK with 0.
6.2.3 Register protection and monitoring methods
Register Monitoring: applied to CFG and CHECK registers

Because CFG and CHECK registers are critical to the CRC operation, some
mechanisms to detect and log transient errors are provided. Early detection of transient
failures enables to improve the failure detection time and assess the severity of the
failure. The monitoring mechanisms are implemented using two redundant instances as
presented in Figure 6-4.

XMC4500
XMC4000 Family
SW Write access
Property: Redundant Register shall

be physically isolated from the
functional Register
Register <REG> Redundant Register <REG>
Register Contents
Shifted Left
Force Register Mismatch

0 1
CTR.FRM_<REG>
Compare
<reg> versus redundant <reg>
SW Read Access OR results of all redundant registers per crc kernel

or
STS.CEF
Figure 6-4 Register monitoring scheme

Let <REG> designate either CFG or CHECK registers. When a write to <REG> takes
place the redundant register is also updated. Redundant registers are not visible to
software. Bits of <REG> reserved have no storage and are not used for redundancy. A
compare logic continuously compares the two stored values and provides a signal that
indicates if the compare is successful or not. The result of all compare blocks are ored
together to provide a single flag information. If a mismatch is detected the STS.CEF
(Configuration Error Flag) bit is set. For run-time validation of the compare logic a Force
Register Mismatch bit field (CTR.FRM_<REG>) is provided. When set to 1 by software
the contents of the redundant register is shifted left by one bit position (redundant bit 0
position is always replaced by a logical 0 value) and is given to the compare logic instead
of the redundant register value. This enables to check the compare logic is functional.
Using a walking bit pattern, the software can completely check the full operation of the
compare logic. Software needs to clear the CTR.FRM_<REG> bit to 0 to be able to
trigger again a new comparison error interrupt.
Register Access Protection: applies to LENGTH and CHECK registers

In order to reduce the probability of a mis-configuration of the CHECK and LENGTH
registers (in the case the automatic check is used), the write access to the CHECK and
LENGTH registers must follow a procedure:
Let <REG> designate CHECK or LENGTH registers. Before being able to configure a
new <value> value into the <REG> register of a CRC kernel, software must first write the

XMC4500
XMC4000 Family
0xFACECAFE value to the <REG> address. The 0xFACECAFE is not written into the
<REG> register. The next write access will proceed as a normal bus write access. The
write accesses shall use full 32-bit access only. This procedure will then be repeated
every time software wants to configure a new <REG> value. If software reads the
CHECK register just after writing 0xFACECAFE it returns the current <REG> contents
and not 0xFACECAFE. A read access to <REG> has no effect on the protection
mechanism.
The following C-code shows write accesses to the CHECK and LENGTH registers
following this procedure:
//set CHECK register
FCE_CHECK0.U = 0xFACECAFE;
FCE_CHECK0.U = 0;
//set LENGTH register

FCE_LENGTH0.U = 0xFACECAFE;
FCE_LENGTH0.U = 256;

Each FCE CRC kernel provides one internal interrupt source. The interrupt lines from
each CRC kernel are ored together to be sent to the interrupt system. The system
interrupt is an active high pulse with the duration of one cycle (of the peripheral clock).
The FCE interrupt handler can use the status information located within the STS status
register of each CRC kernel.
Each CRC kernel provides the following interrupt sources:
CRC Mismatch Interrupt controlled by CFG.CMI bit field and observable via the
status bit field STS.CMF (CRC Mismatch Flag).
Configuration Error Interrupt controlled by CFG.CEI bit field and observable via the
status bit field STS.CEF (Configuration Error Flag).
Length Error Interrupt controlled by CFG.LEI bit field and observable via the status
bit field STS.LEF (Length Error Flag).
Bus Error Interrupt controlled by CFG.BEI bit field and observable via the status bit
field STS.BEF (Bus Error Flag).
Interrupt generation rules

A status flag shall be cleared by software by writing a 1 to the corresponding bit
position.
If an status flag is set and a new hardware condition occurs, no new interrupt is
generated by the kernel: the STS.<FLAG> bit field masks the generation of a new

XMC4500
XMC4000 Family
interrupt from the same source. If a SW access to clear the interrupt status bit takes
place and in the same cycle the hardware wants to set the bit, the hardware condition
wins the arbitration.
As all the interrupts are caused by an error condition, the interrupt shall be handled by a
Error Management software layer. The software services using the FCE as acceleration
engine may not directly deal with error conditions but let the upper layer using the service
to deal with the error handling.
6.4 Debug Behavior

The FCE has no specific debug feature.

The FCE is inside the power core domain, therefore no special considerations about
power up or power down sequences need to be taken. For an explanation about the
different power domains, please address the SCU (System Control Unit) chapter.
A power down mode can be achieved by disabling the module using the Clock Control
Register (CLC).
The FCE module has one reset source. This reset source is handled at system level and
it can be generated independently via a system control register (address SCU chapter
for full description).
After release, the complete IP is set to default configuration. The default configuration for
each register field is addressed on Section 6.7.
The FCE uses the CPU clock, fCPU (address SCU chapter for more details on clocking).

The FCE may have dependencies regarding the bus clock frequency. This
dependencies should be addressed in the SCU and System Architecture Chapters.
Initialization:
The FCE is enabled by writing 0x0 to the CLC register. Software must first ensure that
the CRC kernel is properly configured, especially the initial CRC register value written
via the CRC register, the input and result reflection as well as the final xored value via
the CFG register. The following source code is an example of initialization for the basic
operation of the FCE kernel 0:
//enable FCE
FCE_CLC.U = 0x0;
//final result to be xored with 0xFFFFFFFF, no reflection

XMC4500
XMC4000 Family
FCE_CFG0.U = 0x400;
//set CRC initial value (seed)
FCE_CRC0.U = 0xFFFFFFFF;

XMC4500
XMC4000 Family
6.7 Registers
Table 6-3 show all registers associated with a FCE CRC-kernel. All FCE kernel register
names are described in this section. They should get the prefix FCE_ when used in the
context of a product specification.
The registers are numbered by one index to indicate the related FCE CRC Kernel
(m = 0-3). Some kernel registers are adapted to the degree of the polynomial
implemented by the kernel.
Table 6-2 Registers Address Space - FCE Module

FCE 5002 0000H 5002 3FFFH
Table 6-3 Registers Overview - CRC Kernel Registers

Short Description Offset Access Mode Reset Description
Name Addr.1) Read Write Class See
System Registers
CLC Clock Control 00H U, PV SV,E 3 Page 6-12
Register
ID Module 08H U, PV BE 3 Page 6-12
Identification
Register
Generic CRC Engine Registers
IRm Input Register m 20H + m*20H U, PV U, PV 3 Page 6-14
RESm CRC Result 24H + m*20H U, PV BE 3 Page 6-15
Register m
CFGm CRC Configuration 28H + m*20H U, PV PV 3 Page 6-17
Register m
STSm CRC Status 2CH + m*20H U, PV U, PV 3 Page 6-19
Register m
LENGTH CRC Length 30H + m*20H U, PV U, PV 3 Page 6-20
m Register m
CHECKm CRC Check 34H + m*20H U, PV U, PV 3 Page 6-20
Register m
CRCm CRC Register m 38H + m*20H U, PV U, PV 3 Page 6-22

XMC4500
XMC4000 Family
Table 6-3 Registers Overview - CRC Kernel Registers (contd)

Short Description Offset Access Mode Reset Description
Name Addr.1) Read Write Class See
CTRm CRC Test Register 3CH + m*20H U, PV U, PV 3 Page 6-23
m
CTRm CRC Test Register 3CH + m*20H U, PV U, PV 3 Page 6-23
m
1) The absolute register byte address for each CRC kernel m is calculated as follows:
CRC kernel register base Address (Table 6-2) + m*20H, m = 0-3
Disabling the FCE

The FCE module can be disabled using the CLC register.
When the disable state is requested all pending transactions running on the bus slave
interface must be completed before the disabled state is entered. The CLC Register
Module Disable Bit Status CLC.DISS indicates whether the module is currently disabled
(DISS == 1). Any attempt to write any register with the exception of the CLC Register will
generate a bus error. A read operation is allowed and does not generate a bus error.
6.7.1 System Registers description

This section describes the registers related to the product system architecture.
Clock Control Register (CLC)

The Clock Control Register allows the programmer to adapt the functionality and power
consumption of the module to the requirements of the application.
CLC
Clock Control Register (00H) Reset Value: 0000 0003H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 DISS DISR
r rh rw

XMC4500
XMC4000 Family

DISR 0 rw Module Disable Request Bit
Used for enable/disable control of the module.
DISS 1 rh Module Disable Status Bit
Bit indicates the current status of the module.
0 [31:2] r Reserved
Module Identification Register
ID
Module Identification Register (08H) Reset Value: 00CA C001H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MOD_NUMBER
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MOD_TYPE MOD_REV
r r

MOD_REV [7:0] r Module Revision Number
This bit field defines the module revision number.
The value of a module revision starts with 01H (first
revision). The current revision number is 01H
MOD_TYPE [15:8] r Module Type
The bit field is set to C0H which defines the module
as a 32-bit module.
MOD_NUMBER [31:16] r Module Number Value
This bit field defines a module identification number.
The value for the FCE module is 00CAH.

XMC4500
XMC4000 Family
6.7.2 CRC Kernel Control/Status Registers
CRC Engine Input Register
IRm (m = 0-1)
Input Register m (20H + m*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
IR
rw

IR [7:0] r Input Register
This bit field holds the 32-bit data to be computed
A write to IRm triggers the CRC kernel to update the message checksum according to
the IR contents and to the current CRC register contents. Only 32-bit write transactions
are allowed to this IRm registers, any other bus write transaction will lead to a Bus Error.
IRm (m = 2-2)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 IR
r rw

IR [15:0] r Input Register
the IR contents and to the current CRC register contents. Only 32-bit or 16-bit write

XMC4500
XMC4000 Family
transactions are allowed to this IRm register, any other bus write transaction will lead to
a Bus Error. Only the lower 16-bit of the write transactions will be used.
IRm (m = 3-3)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 IR
r rw

IR [7:0] rw Input Register
0 [31:8] r Reserved
the IR contents and to the current CRC register contents. Any write transaction is
allowed to this IRm register. Only the lower 8-bit of the write transactions will be used.
CRC Engine Result Register
RESm (m = 0-1)
CRC Result Register m (24H + m*20H) Reset Value: FFFF FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RES
rh

RES [31:0] rh Result Register
Returns the final CRC value including CRC reflection
and final XOR according to the CFG register
configuration. Writing to this register has no effect.

XMC4500
XMC4000 Family
RESm (m = 2-2)
CRC Result Register m (24H + m*20H) Reset Value: 0000 FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 RES
r rh

RESm (m = 3-3)
CRC Result Register m (24H + m*20H) Reset Value: 0000 00FFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 RES
r rh

0 [31:8] r Reserved

XMC4500
XMC4000 Family
CRC Engine Configuration Register
CFGm (m = 0-3)
CRC Configuration Register m
(28H + m*20H) Reset Value: 0000 0700H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
XSE REF REFI
0 0 ALR CCE BEI LEI CEI CMI
L OUT N
r rw rw rw r rw rw rw rw rw rw

CMI 0 rw CRC Mismatch Interrupt
0B CRC Mismatch Interrupt is disabled
1B CRC Mismatch Interrupt is enabled
CEI 1 rw Configuration Error Interrupt
When enabled, a Configuration Error Interrupt is
generated whenever a mismatch is detected in the
CFG and CHECK redundant registers.
0B Configuration Error Interrupt is disabled
1B Configuration Error Interrupt is enabled
LEI 2 rw Length Error Interrupt
When enabled, a Length Error Interrupt is generated if
software writes to IR register with LENGTH equal to 0
and CFG.CCE is set to 1.
0B Length Error Interrupt is disabled
1B Length Error Interrupt is enabled
BEI 3 rw Bus Error Interrupt
When enabled, an interrupt is generated if a bus write
transaction with an access width smaller than the
kernel width is issued to the input register.
0B Bus Error Interrupt is disabled
1B Bus Error Interrupt is enabled

XMC4500
XMC4000 Family

CCE 4 rw CRC Check Comparison
0B CRC check comparison at the end of a message
is disabled
1B CRC check comparison at the end of a message
is enabled
ALR 5 rw Automatic Length Reload
0B Disables automatic reload of the LENGTH field.
1B Enables automatic reload of the LENGTH field at
the end of a message.
REFIN 8 rw IR Byte Wise Reflection
0B IR Byte Wise Reflection is disabled
1B IR Byte Wise Reflection is enabled
REFOUT 9 rw CRC 32-Bit Wise Reflection
0B CRC 32-bit wise is disabled
1B CRC 32-bit wise is enabled
XSEL 10 rw Selects the value to be xored with the final CRC
0B 0x00000000
1B 0xFFFFFFFF
0 [7:6], r Reserved

XMC4500
XMC4000 Family
CRC Engine Status Register
STSm (m = 0-3)
CRC Status Register m (2CH + m*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 BEF LEF CEF CMF
r rwh rwh rwh rwh

CMF 0 rwh CRC Mismatch Flag
This bit is set per hardware only. To clear this bit,
software must write a 1 to this bit field location. Writing
0 per software has no effect.
CEF 1 rwh Configuration Error Flag
LEF 2 rwh Length Error Flag
BEF 3 rwh Bus Error Flag
0 [31:4] r Reserved

XMC4500
XMC4000 Family
CRC Engine Length Register
LENGTHm (m = 0-3)
CRC Length Register m (30H + m*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 LENGTH
r rwh

LENGTH [15:0] rwh Message Length Register
Number of words building the message over which the
CRC checksum is calculated. This bit field is modified by
the hardware: every write to the IR register decrements
the value of the LENGTH bit field. If the CFG.ALR field
is set to 1, the LENGTH field shall be reloaded with its
configuration value at the end of the cycle where
LENGTH reaches 0.
CRC Engine Check Register
CHECKm (m = 0-1)
CRC Check Register m (34H + m*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CHECK
rw

CHECK [31:0] rw CHECK Register
Expected CRC value to be checked by the hardware
upon detection of a 1 to 0 transition of the LENGTH
register. The comparison is enabled by the CFG.CCE bit
field

XMC4500
XMC4000 Family
CHECKm (m = 2-2)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 CHECK
r rw

field
CHECKm (m = 3-3)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 CHECK
r rw

field
0 [31:8] r Reserved

XMC4500
XMC4000 Family
CRC Engine Initialization Register
CRCm (m = 0-1)
CRC Register m (38H + m*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CRC
rwh

CRC [31:0] rwh CRC Register
This register enables to directly access the internal CRC
register
CRCm (m = 2-2)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 CRC
r rwh

register

XMC4500
XMC4000 Family
CRCm (m = 3-3)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 CRC
r rwh

register
0 [31:8] r Reserved
CRC Test Register
CTRm (m = 0-3)
CRC Test Register m (3CH + m*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FRM FRM
0 _CH _CF FCM
ECK G
r rw rw rw

FCM 0 rw Force CRC Mismatch
Forces the CRC compare logic to issue an error
regardless of the CHECK and CRC values. The
hardware detects a 0 to 1 transition of this bit field and
triggers a CRC Mismatch interrupt

XMC4500
XMC4000 Family

FRM_CFG 1 rw Force CFG Register Mismatch
This field is used to control the error injection
mechanism used to check the compare logic of the
redundant CFG registers. This is a one shot operation.
When the hardware detects a 0 to 1 transition of this bit
field it triggers a Configuration Mismatch interrupt (if
enabled by the corresponding CFGm register).
FRM_CHECK 2 rw Force Check Register Mismatch
This field is used to control the error injection
mechanism used to check the compare logic of the
redundant CHECK registers. This is a one shot
operation. The hardware detects a 0 to 1 transition of
this bit field and triggers a Check Register Mismatch
interrupt (if enabled by the corresponding CFGm
register).
0 [31:3] r Reserved
6.8 Interconnects
The interfaces of the FCE module shall be described in the module design specification.
The Table 6-4 shows the services requests of the FCE module.
Table 6-4 FCE Service Requests

Inputs/Outputs I/O Connected To Description
FCE.SR0 O NVIC Service request line
6.9 Properties of CRC code
Hamming Distance
The Hamming distance defines the error detection capability of a CRC polynomial. A
cyclic code with a Hamming Distance of D can detect all D-1 bit errors. Table 6-5
Hamming Distance as a function of message length (bits) on Page 6-25 shows
the dependency of the Hamming Distance with the length of the message.

XMC4500
XMC4000 Family
Table 6-5 Hamming Distance as a function of message length (bits)1)

Hamming Distance IEEE-802.3 CRC32 CCITT CRC16 J1850 CRC8
15 8 - 10 Information not Information not
14 8 - 10 available available
13 8 - 10
12 11 - 12
11 13 - 21
10 22 - 34
9 35 - 57
8 58 - 91
7 92 - 171
6 172 - 268
5 269 - 2974
4 2973 - 91607
3 91607 - 131072
1) Data from technical paper 32-Bit Cyclic Redundancy Codes for Internet Applications by Philip Koopman,
Carnegie Mellon University, 2002

XMC4500
XMC4000 Family
On-Chip Memories
On-Chip Memories

XMC4500
XMC4000 Family
Memory Organization
7 Memory Organization
This chapter provides description of the system Memory Organization and basic
information related to Parity Testing and Parity Error handling.
References
[8] Cortex-M4 User Guide, ARM DUI 0508B (ID062910)
7.1 Overview
The Memory Map is intended to balance decoding cost at various level of the system bus
infrastructure.
7.1.1 Features
The Memory Map implements the following features:
Compatibility with standard ARM Cortex-M4 CPU [8]
Compatibility across entire XMC4000 Family
Optimal functional module address spaces grouping
7.1.2 Cortex-M4 Address Space

The system memory map defines several regions. Address boundaries of each of the
regions are determined by the Cortex-M4 core architecture.

Memory Organization, V2.5 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Memory Organization
0xE0100000 0xFFFFFFFF
ROM Table
0xE00FF000
External PPB System
0xE0042000
ETM
0xE0041000 0xE0100000
TPIU
0xE0040000 Private peripheral bus - External
0xE0040000
Private peripheral bus - Internal
0xE0040000
Reserved 0xE0000000
0xE000F000
SCS
0xE000E000
Reserved
0xE0003000 External device 1.0GB
FPB
0xE0002000
DWT
0xE0001000
ITM
0xE0000000 0xA0000000
External RAM 1.0GB
0x60000000
Peripheral 0.5GB
0x40000000
SRAM 0.5GB
0x20000000
Code 0.5GB
0x00000000
Figure 7-1 Cortex-M4 processor address space

XMC4500
XMC4000 Family
Memory Organization
7.2 Memory Regions

The XMC4500 device specific address map assumes presence of internal and external
memories and peripherals. The memory regions for XMC4500 are described in
Table 7-1.
Table 7-1 Memory Regions

Start End Size (hex) Space name Usage
00000000 1FFFFFFF 20000000 Code Boot ROM
Flash
Program SRAM
20000000 3FFFFFFF 20000000 SRAM Fast internal
SRAMs
40000000 47FFFFFF 08000000 Peripheral 0 Internal
Peripherals
group 0
48000000 4FFFFFFF 08000000 Peripheral 1 Internal
Peripherals
group 1
50000000 57FFFFFF 08000000 Peripheral 2 Internal
Peripherals
group 2
58000000 5FFFFFFF 08000000 Peripheral 3 Internal
Peripherals
group 3
60000000 9FFFFFFF 40000000 External SRAM External
Memories
A0000000 DFFFFFFF 40000000 External Device External
Devices
E0000000 E00FFFFF 00100000 Private CPU
Peripheral Bus
E0100000 EFFFFFFF 0FF00000 Vedor specific 1 reserved
F0000000 FFFFFFFF 10000000 Vedor specific 2 reserved
7.3 Memory Map

Table 7-2 defines detailed system memory map of XMC4500 where each individual
peripheral or memory instance implement its own address spaces. For detailed register
description of the system components and peripherals please refer to respective
chapters of this document.

XMC4500
XMC4000 Family
Memory Organization
Table 7-2 Memory Map

Addr space Start Address (hex) End Address (hex) Modules
Code 00000000 00003FFF BROM (PMU ROM)
00004000 07FFFFFF reserved
08000000 080FFFFF PMU/FLASH
(cached)
08100000 09E1FFFF reserved
09E20000 09E23FFF reserved
09E24000 0BFFFFFF reserved
0C000000 0C0FFFFF PMU/FLASH
(uncached)
0C100000 0FFFFFFF reserved
0DE20000 0DE23FFF reserved
0DE24000 0FFFFFFF reserved
10000000 1000FFFF PSRAM (code)
10010000 1FFFFFFF reserved
SRAM 20000000 2000FFFF DSRAM1 (system)
30000000 30007FFF DSRAM2 (comm)

XMC4500
XMC4000 Family
Memory Organization
Table 7-2 Memory Map (contd)

Peripherals 0 40000000 40003FFF PBA0
40004000 40007FFF VADC
40008000 4000BFFF DSD
4000C000 4000FFFF CCU40
40010000 40013FFF CCU41
40014000 40017FFF CCU42
40018000 4001BFFF reserved
4001C000 4001FFFF reserved
40020000 40023FFF CCU80
40024000 40027FFF CCU81
40028000 4002BFFF POSIF0
4002C000 4002FFFF POSIF1
40030000 40033FFF USIC0
40034000 40037FFF reserved
40044000 40047FFF ERU1
48004000 48007FFF CCU43
48010000 48013FFF LEDTS0
48014000 48017FFF CAN
48018000 4801BFFF DAC
4801C000 4801FFFF SDMMC
48020000 48023FFF USIC1
48024000 48027FFF USIC2
48028000 4802BFFF PORTS
4802C000 4FFFFFFF reserved

XMC4500
XMC4000 Family
Memory Organization

50004000 50007FFF SCU & RTC
50008000 5000BFFF WDT
5000C000 5000FFFF ETH
50014000 50017FFF DMA0
50018000 5001BFFF DMA1
50020000 50023FFF FCE
50024000 5003FFFF reserved
50040000 5007FFFF USB
Peripherals 3 58000000 58003FFF PMU0 registers
58004000 58007FFF PMU0 prefetch
58008000 5800BFFF EBU registers
External SRAM 60000000 63FFFFFF EBU memory CS0
64000000 67FFFFFF EBU memory CS1
68000000 6BFFFFFF EBU memory CS2
6C000000 6FFFFFFF EBU memory CS3
External Device A0000000 A3FFFFFF EBU devices CS0
A4000000 A7FFFFFF EBU devices CS1
A8000000 ABFFFFFF EBU devices CS2
AC000000 AFFFFFFF EBU devices CS3
B0000000 DFFFFFFF reserved

XMC4500
XMC4000 Family
Memory Organization

Private Peripheral E0000000 E0000FFF ITM
Bus E0001000 E0001FFF DWT
E0002000 E0002FFF FPB
E0003000 E000DFFF reserved
E000E000 E000EFFF SCS
E000E010 E000E01C SysTick
E000EF34 E000EF47 FPU
E000F000 E003FFFF reserved
E0040000 E0040FFF TPIU
E0041000 E0041FFF ETM
E0042000 E00FEFFF reserved
E00FF000 E00FFFFF ROM Table
Vedor specific 1 E0100000 EFFFFFFF reserved
Vedor specific 2 F0000000 FFFFFFFF reserved

Memory modules and other system components are capable of generating error
reposnses indicated to the CPU as bus error exceptions or interrupts.
Types of error causes

Unsupported Access Mode
Access to Invalid Address
Parity Error (memories only)
Bufferable Write Accesses to Peripheral
Errors that cannot be indicated with bus errors get indicated with service requests that
get propagated to CPU as interrupts. Typically lack of bus error response capability
applies to memory modules that lack of direct access from the system bus This applies
to memories that serve the purpose of internal FIFOs and local storage buffers.
Unsupported Access Modes

Unsupported access modes can be clasiffied in various ways and are usually specific to
the module that access is performed to. The typical examples of unsupported access
modes are read access to write-only or write access to read-only type of address

XMC4500
XMC4000 Family
Memory Organization
mapped ressources, unsupported access data witdhs, protected memory regions. For
module specific limitations please refer to individual module chapters.
Invalid Address
Accesses to invalid addresses result in error responses. Invalid addresses are defined
as those that do not mapped to any valid ressources. This applies to single addresses
and to wider address ranges. Some invalid addresses within valid module address
ranges may not produce error responses and this is specific to individual modules.
Parity Errors
Parity test is performed on the XMC4500 memories in normal functional mode. Parity
errors are generated in case of failure of parity test performed inside of each of the
memory module. The mechnism of parity testing depends on memory data width and
access mode, i.e. memory modules that are accessible byte-wise implement parity
check for each data byte individually while for memory modules that are accessible
double-word-wise it is sufficient to perform joint check for all bits.
The occurrence of a parity error gets signalized to the system with system bus error or
an interrupt (parity trap). For details on parity errror generation control and handling
please refer to the SCU chapter. For more details please refer to Table 7-3.
Table 7-3 Parity Test Enabled Memories and Supported Parity Error Indication
Memory Number of Parity Test Bus Parity

Parity Bits Granularity Error Trap
Program SRAM (PSRAM) 1 4 bytes yes yes
System SRAM (DSRAM1) 4 1 byte yes yes
Communication SRAM (DSRAM2) 4 1 byte yes yes
USIC 0 Buffer Memory 1 4 bytes no yes
MultiCAN Buffer Memory 1 4 bytes no yes
PMU Prefetch Buffer Memory 1 4 bytes no yes
USB Buffer Memory 1 4 bytes no yes
ETH 0 TX Buffer Memory 1 4 bytes no yes
ETH 0 RX Buffer Memory 1 4 bytes no yes
SDMMC Buffer Memory 0 1 4 bytes no yes
SDMMC Buffer Memory 1 1 4 bytes no yes

XMC4500
XMC4000 Family
Memory Organization
Bufferable Write Access to Peripheral

Bufferable writes to peripheral may result in error reponses as described above. Bus
error responses from modules attached to peripheral bridges PBA0 and PBA1 trigger
service request from the respective bridge that will result in NMI to the CPU. Error status
and access address that caused the service request get stored in dedicated registers of
the peripheral bridges. For detail please refer to Registers.
7.5 Debug Behavior

The bus system in debug mode allows debug probe access to all system ressources
except for the Flash sectors protected with a dedicated protection mechanism (for more
details please refer to Flash Memory chapter). No special handling of HALT mode is
implemented and all interfaces respond with a valid bus response upon accesses.

The bus system clocking scheme enables stable system operation and accesses to
system ressources for all valid system clock rates. Some parts of the system may also
run at a half of the system clock rate and no special handling is required as appropriate
alignment of the bus system protocol is provided on the clock domain boundary (for
details please refer to clocking system description in SCU chapter).

No initialization is required for the memory system from user point of view. All valid
memories are available after reset. Some peripherals may need to be initialized (e.g.
released from reset state) before accessed. For details please refer to individual
peripheral chapters.

XMC4500
XMC4000 Family
Memory Organization
7.8 Registers
This section describes registers of the Peripheral Bridges. The purpose of the registers
is handling of errors signalized during bufferable accesses to peripherals connected to
the respective bridges. Aactive errors on bufferable writes trigger interrupt requests
geberated from the Peripheral Bridges that can be monitored and cleared in the register
defiled in this chapter.

PBA0 4000 0000H 4000 3FFFH Peripheral
Bridge 0
PBA1 4800 0000H 4800 3FFFH Peripheral
Bridge 1

Register Register Long Offset Access Mode Description
Short Name Name Address Read Write
PBA0_STS PBA 0 Status 0000H U, PV PV Page 7-10
Register
PBA0_WADDR PBA 0 Write Error 0004H U, PV Page 7-11
Address
PBA1_STS PBA 1 Status 0000H U, PV PV Page 7-12
Register
PBA1_WADDR PBA 1 Write Error 0004H U, PV Page 7-12
Address
PBA0_STS
The status register of PBA0 bridge indicates bus error occurrence for write access. Is
meant to be used for errors triggered upon buffered writes. The bit gets set and interrupt
request has been generated to the SCU.
Write one to clear, writing zero has no effect.

XMC4500
XMC4000 Family
Memory Organization
PBA0_STS
Peripheral Bridge Status Register (0000H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
WER
0
R
r rw

WERR 0 rw Bufferable Write Access Error
0B no write error occurred.
1B write error occurred, interrupt request is pending.
0 [31:1] r Reserved bits. Write zeros
PBA0_WADDR
The Write Error Address Register keeps write access address that caused a bus error
upon bufferable write attempt to a peripheral connected to PBA0 bridge. This register
store the address that of the bufferable write access attempt that caused error resulting
in setting WERR bit of the PBA0_STS register.
This register value remains unchanged when WERR bit of PBA0_STS register is set.
PBA0_WADDR
PBA Write Error Address Register (0004H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
WADDR
rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
WADDR
rh

XMC4500
XMC4000 Family
Memory Organization

WADDR [31:0] rh Write Error Address
Address of the write access that caused a bus error
on the bridge Master port.
PBA1_STS
The status register of PBA1 bridge indicates bus error occurrence for write access. Is
meant to be used for errors triggered upon buffered writes. The bit gets set and interrupt
request has been generated to the SCU.
Write one to clear, writing zero has no effect.
PBA1_STS
Peripheral Bridge Status Register (0000H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
WER
0
R
r rw

WERR 0 rw Bufferable Write Access Error
0B no write error occurred.
1B write error occurred, interrupt request is pending.
0 [31:1] r Reserved bits. Write zeros
PBA1_WADDR
The Write Error Address Register keeps write access address that caused a bus error
upon bufferable write attempt to to a peripheral connected to PBA1 bridge. This register
store the address that of the bufferable write access attempt that caused error resulting
in setting WERR bit of the PBA1_STS register.
This register value remains unchanged when WERR bit of PBA1_STS register is set.

XMC4500
XMC4000 Family
Memory Organization
PBA1_WADDR
PBA Write Error Address Register (0004H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
WADDR
rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
WADDR
rh

WADDR [31:0] rh Write Error Address
Address of the write access that caused a bus error
on the bridge Master port.

XMC4500
XMC4000 Family
Flash and Program Memory Unit (PMU)
8 Flash and Program Memory Unit (PMU)

The Program Memory Unit (PMU) controls the Flash memory and the BROM and
connects these to the system. The Prefetch unit maximizes system performance with
higher system frequencies, by buffering instruction and data accesses to the Flash.
8.1 Overview
In the XMC4500, the PMU controls the following interfaces:
The Flash command and fetch control interface for Program Flash
The Boot ROM interface
The PMU interfaces via the Prefetch unit to the Bus Matrix
Following memories are controlled by and belong to the PMU:
1.0 Mbyte of Program Flash memory (PFLASH)
16 Kbyte of BROM (BROM)
4 Kbyte of Instruction Cache memory in the Prefetch unit
256-bit Data Buffer in the Prefetch unit
8.1.1 Block Diagram

The PMU block diagram is shown in Figure 8-1.
Bus Matrix
PREFETCH
PMU
Control
PFLASH BROM
Figure 8-1 PMU Block Diagram

PMU, V1.4 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
8.2 Boot ROM (BROM)

The Boot ROM in PMU0 has a capacity of 16 KB. The BROM contains the Firmware
with:
startup routines
bootstrap loading software.
Details on the operations of the BROM are given in the chapter Startup Modes.
8.2.1 BROM Addressing

The BROM is visible at one location, as can be seen in the memory map:
(non-cached space) starting at location 0000 0000H
After any reset, the hardware-controlled start address is 0000 0000H. At this location, the
startup procedure is stored and started. As no other start location after reset is
supported, the startup software within the BROM is always executed first after any reset.
8.3 Prefetch Unit

The purpose of the Prefetch unit is to reduce the Flash latency gap at higher system
frequencies to increase the instruction per cycle performance.
8.3.1 Overview
The Prefetch unit separates between instruction and data accesses to the Flash with the
following configuration:
4 Kbyte Instruction Buffer
2-way set associative
Least-Recently-Used (LRU) replacement policy
Cache line size: 256 bits
Critical word first
Streaming1)
Line wrap around
Parity, 32-bit granularity
Buffer can be bypassed
Buffer can be globally invalidated
256-bit Data Buffer
Single line
Critical word first
Streaming1)
Line Wrap around
1) The first 32-bit data from Flash gets immediately forwarded to the CPU

XMC4500
XMC4000 Family
Instruction
ICode Bus I/F
Instruction
Buffer
PMU
Flash memory
I/F
DCode Bus Data Buffer

Data
System Bus
I/F
DMA
Figure 8-2 Prefetch Unit
8.3.2 Operation
8.3.2.1 Instruction Buffer

The instruction buffer acts like a regular instruction cache with the characteristics
described in the overview, optimized for minimum latency via the dedicated instruction
interface. Instruction fetches to the non-cacheable address space bypass the instruction
buffer. For software development and benchmarking purposes the cacheable accesses
can also bypass the instruction buffer by setting PREF_PCON.IBYP to 1B.
Prefetch buffer hits are without any penalty i.e. single cycle access rate. This ensures a
minimized latency.
The instruction buffer may be invalidated by writing a 1B to PREF_PCON.IINV. After
system reset, the instruction buffer is automatically invalidated.
A parity error during a buffer read operation is automatically turned into a buffer miss,
triggering a refill operation of the cache line.
Note: The complete invalidation operation is performed in a single cycle.
Note: The parity information is generated on the fly during the cache refill operation.
Parity is checked for each read operation targeting the instruction buffer.
The streaming operation is on the fly - it does not cause any additional latency.
8.3.2.2 Data Buffer

The characteristics of the data buffer are described in the overview. It is used for data
read requests from the CPU using the DCode interface and for data read requests from

XMC4500
XMC4000 Family
the DMA. CPU read accesses to the prefetch buffer are without any penalty i.e. single
cycle access rate. The miss latency is minimized.
The data interface is shared between DMA requests, CPU DCode bus requests and
CPU System bus requests. The CPU System bus is attached to the Prefetch unit to
access configuration and status registers within the Prefetch unit and the PMU and
Flash. All read requests outside the cacheable address space and all write accesses
bypass the data buffer.
Note: The streaming operation is on the fly - it does not cause any additional latency.
8.3.2.3 PMU Interface

Each Flash read access returns 256 bits, intermediately stored in a global read buffer
in the Flash (Chapter 8.4.4). The Prefetch unit reads from this buffer via a 64-bit
interface. Cacheable read accesses that are not yet stored in the Prefetch buffer (cache
miss) trigger a refill operation by a 4x64-bit burst transfer. By that burst transfer the data
from the global buffer is copied, refilling the instruction buffer (code fetch) or data buffer
(data fetch) respectively.
Only the initial Flash read access is affected by the Flash latency. The subsequent read
accesses of the burst transfer are serviced by the global read buffer with no additional
delay. An additional prefetch mechanism in the PFLASH further reduces the latency for
linear Flash accesses (Chapter 8.4.4).
Non-cacheable accesses benefit from the global read buffer in the same way, as long as
its content is not trashed by a new Flash read access (e.g. from a different bus master).
Accesses to the BROM and register address spaces and write operations are ignored by
the Prefetch buffers.

XMC4500
XMC4000 Family
8.4 Program Flash (PFLASH)

This chapter describes the embedded Flash module of the XMC4500 and its software
interface.
8.4.1 Overview
The embedded Flash module of XMC4500 includes 1.0 MB of Flash memory for code or
constant data (called Program Flash).
8.4.1.1 Features
The following list gives an overview of the features implemented in the Program Flash.
Absolute values can be found in the Data Sheet.
Consists of one bank.
Commonly used for instructions and constant data.
High throughput burst read based on a 256-bit Flash access.
Application optimized sector structure with sectors ranging from 16 Kbytes to
256 Kbytes.
High throughput programming of a 256 byte page (see Data Sheet tPRP).
Sector-wise erase on logical and physical sectors (see Data Sheet tERP).
Write protection separately configurable for groups of sectors.
Hierarchical write protection control with 3 levels of which 2 are password based and
1 is a one-time programmable one.
Password based read protection combined with write protection for the whole Flash.
Separate configuration sector containing the protection configuration and boot
configuration (BMI).
All Flash operations initiated by command sequences as protection against
unintended operation.
Erase and program performed by a Flash specific control logic independent of the
CPU.
End of erase and program operations reported by interrupt.
Dynamic Error Correcting Code (ECC) with Single-bit Error Correction and Double-
bit Error Detection (SEC-DED).
Error reporting by bus error, interrupts and status flags.
Margin reads for quality assurance.
Delivery in the erased state.
Configurable wait state configuration for optimum read performance depending on
CPU frequency (see FCON.WSPFLASH).
High endurance and long retention.
Pad supply voltage used for program and erase.

XMC4500
XMC4000 Family
8.4.2 Definition of Terms

The description of Flash memories uses a specific terminology for operations and the
hierarchical structure.
Flash Operation Terms

Erasing: The erased state of a Flash cell is logical 0. Forcing a cell to this state is
called erasing. Depending on the Flash area always complete physical sectors,
logical sectors are erased. All Flash cells in this area incur one cycle that counts
for the endurance.
Programming: The programmed state of a cell is logical 1. Changing an erased
Flash cell to this state is called programming. The 1-bits of a page are programmed
concurrently.
Retention: This is the time during which the data of a Flash cell can be read reliably.
The retention time is a statistical figure that depends on the operating conditions of
the device (e.g. temperature profile) and is affected by operations on other Flash cells
in the same word-line and physical sector. With an increasing number of
program/erase cycles (see endurance) the retention is lowered. Figures are
documented in the Data Sheet separately for physical sectors (tRET) and UCBs (tRTU).
Endurance: The maximum number of program/erase cycles of each Flash cell is
called endurance. The endurance is a statistical figure that depends on operating
conditions and the use of the flash cells and also on the required quality level. The
endurance is documented in the Data Sheet as a condition to the retention
parameters.
Flash Structure Terms

Flash Module: The PMU contains one Flash module with its own operation control
logic.
Bank: A Flash module may contain separate banks. Banks support concurrent
operations (read, program, erase) with some limitations due to common logic.
Physical Sector: A Flash bank consists of physical sectors ranging from
64 Kbytes to 256 Kbytes. The Flash cells of different physical sectors are isolated
from each other. Therefore cycling Flash cells in one physical sectors does not affect
the retention of Flash cells in other physical sectors. A physical sector is the largest
erase unit.
Logical Sector: A logical sector is a group of word-lines of one physical sector.
They can be erased with a single operation but other Flash cells in the same physical
sector are slightly disturbed.
Sector: The plain term sector means logical sector when a physical sector is
divided in such, else it means the complete physical sector.
User Configuration Block UCB: A UCB is a specific logical sector contained in
the configuration sector. It contains the protection settings and other data configured

XMC4500
XMC4000 Family
by the user. The UCBs are the only part of the configuration sector that can be
programmed and erased by the user.
Word-Line: A word-line consists of two pages, an even one and an odd one. In the
PFLASH a word-line contains aligned 512 bytes.
Page: A page is a part of a word-line that is programmed at once. In PFLASH a
page is an aligned group of 256 bytes.
8.4.3 Flash Structure

The PMU contains one PFLASH bank, accessible via the cacheable or non-cacheable
address space. The offset address of each sector is relative to the base address of its
bank which is given in Table 8-1.
Derived devices (see Data Sheet) can have less Flash memory. The PFLASH bank
shrinks by cutting-off higher numbered physical sectors.
Table 8-1 Flash Memory Map

Range Size Start Address
Description
PMU0 Program Flash Bank 1.0 Mbyte 0C00 0000H
non-cached
PMU0 Program Flash Bank 1.0 Mbyte 0800 0000H
cached space
(different address space for the same
physical memory, mapped in the non-
cached address space)
PMU0 UCB 3 Kbyte 0C00 0000H
User Configuration Blocks
PMU0 Flash Registers 1 Kbyte 5800 2000H
PFLASH
All addresses offset to the start addresses given in Table 8-1. All sectors from S9 on
have a size of 256 Kbyte.
Table 8-2 Sector Structure of PFLASH

Sector Phys. Sector Size Offset Address
S0 PS0 16 KB 000000H
S1 16 KB 004000H
S2 16 KB 008000H
S3 16 KB 00C000H

XMC4500
XMC4000 Family
Table 8-2 Sector Structure of PFLASH (contd)

Sector Phys. Sector Size Offset Address
S4 PS4 16 KB 010000H
S5 16 KB 014000H
S6 16 KB 018000H
S7 16 KB 01C000H
S8 128 KB 020000H
S9 256 KB 040000H
S10 256 KB 080000H
S11 256 KB 0C0000H
UCB
All addresses offset to the start addresses given in Table 8-1. As explained before the
UCBx are logical sectors.
Table 8-3 Structure of UCB Area

Sector Size Offset Address
UCB0 1 KB 000000H
UCB1 1 KB 000400H
UCB2 1 KB 000800H
8.4.4 Flash Read Access

Flash banks that are active and in read mode can be directly read like a ROM.
The wait cycles for the Flash read access must be configured based on the CPU
frequency fCPU (incl. PLL jitter) in relation to the Flash access time ta defined in the Data
Sheet. The follwing formula applies for FCON.WSPFLASH > 0H1):
WSPFLASH (1 / fCPU) ta (8.1)
The PFLASH delivers 256 bits per read access. All read data from the PFLASH passes
through a 256-bit global read buffer.
The PMU allows 4x64-bit burst accesses to the cached address space and single 32-bit
read accesses to the non-cached address space of the PFLASH.
1) WSPFLASH = 0H deviates from this formula and results in the same timing as WSPFLASH = 1H.

XMC4500
XMC4000 Family
The Prefetch generates the 4x64-bit bursts for code and data fetches from the cached
address range in order to fill one cache line or the data buffer respectively. Data reads
from the non-cached address range are performed with single 32-bit transfers.
Following an inital Flash access, the PFLASH automatically starts a prefetch of the next
linear address (even before it has been requested). Has the content of the global read
buffer been read completely (e.g. by a burst from the Prefetch unit), the new prefetched
data is copied to the read buffer and another prefetch to the PFLASH is started. This
significantly reduces the Flash latency for mostly linearly accessed code or data
sections. To avoid additional wait states due to these prefetches, they can be aborted in
case a new (initial) read access is requested from a different address. For power saving
purposes these prefetch operations can be disabled by FCON.IDLE (Idle Read Path).
Read accesses from Flash can be blocked by the read protection (see Chapter 8.4.8).
ECC errors can be detected and corrected (see Chapter 8.4.9).
8.4.5 Flash Write and Erase Operations

Flash write and erase operations are triggered by Command Sequences to avoid harm
to the stored data by accidential accesses from faulty code. Erase operations are
executed on sectors, write operations on pages.
Attention: Flash write and erase operations must be executed to the non-
cacheable address space.
8.4.6 Modes of Operation

A Flash module can be in one of the following states:
Active (normal) mode.
Sleep mode (see Chapter 8.6.2).
In sleep mode write and read accesses to all Flash ranges of this PMU are refused with
a bus error.
When the Flash module is in active mode the Flash bank can be in one of these modes:
Read mode.
Command mode.
In read mode a Flash bank can be read and command sequences are interpreted. In
read mode a Flash bank can additionally enter page mode which enables it to receive
data for programming.
In command mode an operation is performed. During its execution the Flash bank
reports BUSY in FSR. In this mode read accesses to this Flash bank are refused with a
bus error. At the end of an operation the Flash bank returns to read mode and BUSY is
cleared. Only operations with a significant duration (shown in the command
documentation) set BUSY.

XMC4500
XMC4000 Family
Register read and write accesses are not affected by these modes.
8.4.7 Command Sequences

All Flash operations except read are performed with command sequences. When a
Flash bank is in read mode or page mode all write accesses to its reserved address
range are interpreted as command cycle belonging to a command sequence. Write
accesses to a busy bank cause a sequence error (SQER).
Attention: For the proper execution of the command sequences and the triggered
operations fCPU must be equal or above 1 MHz.
Command sequences consist of 1 to 6 command cycles. The command interpreter
checks that a command cycle is correct in the current state of command interpretation.
Else a SQER is reported.
When the command sequence is accepted the last command cycle finishes read mode
and the Flash bank transitions into command mode.
These write accesses must be single transfers and must address the non-cacheable
address range.
Generally when the command interpreter detects an error it reports a sequence error by
setting FSR.SQER. Then the command interpreter is reset and a page mode is left. The
next command cycle must be the 1st cycle of a command sequence. The only exception
is Enter Page Mode when a bank is already in page mode (see below).
8.4.7.1 Command Sequence Definitions

Table 8-4 gives an overview of the supported command sequence, with the following
nomenclature:
The parameter addr can be one of the following:
CCCCH: The addr must point into the bank that performs the operation. The last 16
address bits must match CCCCH. It is recommended to use as address the base
address of the bank incremented by CCCCH.
PA: Absolute start address of the Flash page.
UCPA: Absolute start address of a user configuration block page.
SA: Absolute start address of a Flash sector. Allowed are the PFLASH sectors Sx.
PSA: Absolute start address of a physical sector. Allowed are the PFLASH physical
sectors PSx.
UCBA: Absolute start address of a user configuration block.
The parameter data can be one of the following:
WD: 64-bit or 32-bit write data to be loaded into the page assembly buffer.
xxYY: 8-bit write data as part of a command cycle. Only the byte YY is used for
command interpretation. The higher order bytes xx are ignored.
xx5y: Specific case for YY. The y can be 0H for selecting the PFLASH bank.

XMC4500
XMC4000 Family
UL: User protection level (xxx0H or xxx1H for user levels 0 and 1).
PWx: 32-bit password.
When using for command cycles 64-bit transfers the data is expected in the correct 32-
bit word as indicated by the address addr.
Command Sequence Overview Table

The Table 8-4 summarizes all commands sequences. The following sections describe
each command sequence in detail.
Table 8-4 Command Sequences for Flash Control

Command Sequence 1. 2. 3. 4. 5. 6.
Cycle Cycle Cycle Cycle Cycle Cycle
Reset to Read Address .5554
Data ..xxF0
Enter Page Mode Address .5554
Data ..xx5y
Load Page Address .55F0
Data WD
Write Page Address .5554 .AAA8 .5554 PA
Data ..xxAA ..xx55 ..xxA0 ..xxAA
Write User Address .5554 .AAA8 .5554 UCPA
Configuration Page Data ..xxAA ..xx55 ..xxC0 ..xxAA
Erase Sector Address .5554 .AAA8 .5554 .5554 .AAA8 SA
Data ..xxAA ..xx55 ..xx80 ..xxAA ..xx55 ..xx30
Erase Physical Sector Address .5554 .AAA8 .5554 .5554 .AAA8 SA
Data ..xxAA ..xx55 ..xx80 ..xxAA ..xx55 ..xx40
Erase User Address .5554 .AAA8 .5554 .5554 .AAA8 UCBA
Configuration Block Data ..xxAA ..xx55 ..xx80 ..xxAA ..xx55 ..xxC0
Disable Sector Write Address .5554 .AAA8 .553C .AAA8 .AAA8 .5558
Protection Data ..xxAA ..xx55 UL PW 0 PW 1 ..xx05
Disable Read Address .5554 .AAA8 .553C .AAA8 .AAA8 .5558
Protection Data ..xxAA ..xx55 ..xx00 PW 0 PW 1 ..xx08
Resume Protection Address .5554
Data ..xx5E
Clear Status Address .5554
Data ..xxF5

XMC4500
XMC4000 Family
Reset to Read
This function resets the command interpreter to its initial state (i.e. the next command
cycle must be the 1st cycle of a sequence). A page mode is aborted.
This command is the only one that is accepted without generating a SQER when the
command interpreter has already received command cycles of a different sequence but
is still not in command mode. Thus Reset to Read can cancel every command
sequence before its last command cycle has been received.
The error flags of FSR (PFOPER, SQER, PROER, PFDBER, ORIER, VER) are cleared.
The flags can be also cleared in the status registers without command sequence.
If any Flash bank is busy this command is executed but the flag SQER is set.
Enter Page Mode

The PFLASH enters page mode. The selection of the PFLASH assembly buffer (256
bytes) is additionally done by the parameter yH = 0H.
The write pointer of the page assembly buffer is set to 0, its previous content is
maintained.
The page mode is signalled by the flag PAGEx in the FSR.
If a new Enter Page Mode command sequence is received while any Flash bank is
already in page mode SQER is set but this sequence is correctly executed (i.e. in this
case the command interpreter is not reset).
Load Page
Loads the data WD into the page assembly buffer and increments the write pointer to
the next position1).
All WD transfers for one page must have the same width (either all 32-bit or all 64-bit).
Else the transfer is refused with SQER.
The addressed bank must be in page mode, else SQER is issued.
If Load Page is called more often than necessary for filling the page SQER is issued
and if configured an interrupt is triggered. The overflow data is discarded. The page
mode is not left.
Write Page
This function starts the programming process for one page with the data transferred
previously by Load Page commands. Upon entering command mode the page mode
1) More specifically: after Load Page has transferred 64 bits (i.e. two command with 32-bit WD or one command
with one 64-bit WD) the ECC is calculated and the result is transferred to the assembly buffer.

XMC4500
XMC4000 Family
is finished (indicated by clearing the corresponding PAGE flag) and the BUSY flag of the
bank is set.
This command is refused with SQER when the addressed Flash bank is not in page
mode.
SQER is also issued when PA addresses an unavailable Flash range or when PA does
not point to a legal page start address.
If after Enter Page Mode too few data or no data was transferred to the assembly buffer
with Load Page then Write Page programs the page but sets SQER. The missing data
is programmed with the previous content of the assembly buffer.
When the page PA is located in a sector with active write protection or the Flash module
has an active global read protection the execution fails and PROER is set.
Write User Configuration Page

As for Write Page, except that the page UCPA is located in a user configuration block.
This changes the Flash modules protection configuration.
When the page UCPA is located in an UCB with active write protection or the Flash
module has an active global read protection the execution fails and PROER is set.
When UCPA is not the start address of a page in a valid UCB the command fails with
SQER.
Erase Sector
The sector SA is erased.
SQER is returned when SA does not point to the base address of a correct sector (as
specified at the beginning of this section) or to an unavailable sector.
When SA has an active write protection or the Flash module has an active global read
protection the execution fails and PROER is set.
Erase Physical Sector

The physical sector PSA is erased.
SQER is returned when PSA does not point to the base address of a correct sector (as
specified at the beginning of this section) or an unavailable sector.
When PSA has an active write protection or the Flash module has an active global read
protection the execution fails and PROER is set.
Erase User Configuration Block

The addressed user configuration block UCB is erased.
When the UCB has an active write protection or the Flash module has an active global
read protection the execution fails and PROER is set.

XMC4500
XMC4000 Family
The command fails with SQER when UCBA is not the start address of a valid UCB.
Disable Sector Write Protection

The sector write protection belonging to user level UL is temporarily disabled by setting
FSR.WPRODIS when the passwords PW0 and PW1 match their configured values in
the corresponding UCB.
The command fails by setting PROER when any of PW0 and PW1 does not match. In
this case until the next application reset all further calls of Disable Sector Write
Protection and Disable Read Protection fail with PROER independent of the supplied
password.
Disable Read Protection

The Flash module read protection including the derived module wide write protection are
temporarily disabled by setting FSR.RPRODIS when the passwords PW0 and PW1
match their configured values in the UCB0.
The command fails by setting PROER when any of PW0 and PW1 does not match. In
this case until the next application reset all further calls of Disable Sector Write
Protection and Disable Read Protection fail with PROER independent of the supplied
password.
Resume Protection
This command clears all FSR.WPRODISx and the FSR.RPRODIS effectively enabling
again the Flash protection as it was configured.
A FSR.WPRODISx is not cleared when corresponding UCBx is not in the confirmed
state (see Chapter 8.4.8.1).
Clear Status
The flags FSR.PROG and FSR.ERASE and the error flags of FSR (PFOPER, SQER,
PROER, PFDBER, ORIER, VER) are cleared. These flags can be also cleared in the
status registers without command sequence.
When any Flash bank is busy this command fails by setting additionally SQER.
8.4.8 Flash Protection

The Flash memory can be read and write protected. The protection is configured by
programming the User Configuration Blocks UCB.
For an effective IP protection the Flash read protection must be activated. This ensures
system wide that the Flash cannot be read from external or changed without
authorization.

XMC4500
XMC4000 Family
8.4.8.1 Configuring Flash Protection in the UCB

As indicated above the effective protection is determined by the content of the
Protection Configuration Indication PROCON02 registers. These are loaded during
startup from the UCB02. Each UCB comprises 1 Kbyte of Flash organized in 4 UC
pages of 256 bytes. The UCBs have the following structure:
Table 8-5 UCB Content

UC Bytes UCB0 UCB1 UCB2
Page
0 [1:0] PROCON0 PROCON1 PROCON2
[7:2] unused unused unused
[9:8] PROCON0 (copy) PROCON1 (copy) PROCON2 (copy)
[15:10] unused unused unused
[19:16] PW0 of User 0 PW0 of User 1 unused
[23:20] PW1 of User 0 PW1 of User 1 unused
[27:24] PW0 of User 0 (copy) PW0 of User 1 (copy) unused
[31:28] PW1 of User 0 (copy) PW1 of User 1 (copy) unused
others unused unused unused
1 unused unused BMI and configuration
data (details in
Startup Mode
chapter)
2 [3:0] confirmation code confirmation code confirmation code
[11:8] confirmation code confirmation code confirmation code
(copy) (copy) (copy)
others unused unused unused
3 unused unused unused unused
If the confirmation code field is programmed with 8AFE 15C3H the UCB content is
confirmed otherwise it is unconfirmed. The status flags FSR.PROIN, FSR.RPROIN
and FSR.WPROIN02 indicate this confirmation state:
FSR.PROIN: set when any UCB is in the confirmed state.
FSR.RPROIN: set when PROCON0.RPRO is 1 and the UCB0 is in confirmed
state.
FSR.WPROIN02: set when their UCB02 is in confirmed state.

XMC4500
XMC4000 Family
An UCB can be erased with the command Erase User Configuration Block. An UCB
page can be programmed with the command Write User Configuration Page. These
commands fail with PROER when the UCB is write-protected.
An UCB is write-protected if:
UCB0: (FSR.RPROIN and not FSR.RPRODIS) or
(FSR.WPROIN0 and not FSR.WPRODIS0)
UCB1: FSR.WPROIN1 and not FSR.WPRODIS1.
UCB2: FSR.WPROIN2
So when the UCB2 is in the confirmed state its protection can not be changed anymore.
Therefore this realizes a one-time programmable protection.
Changing UCBs
The protection installation is modified by erasing and programming the UCBs with
dedicated command sequences, described in Chapter 8.4.7.1. These operations need
to be performed with care as described in the following.
Aborting an Erase UC Block operation (e.g. due to reset or power failure) must be
avoided at all means, as it can result in an unusable device.
UCBs are logical sectors, and as such the allowed number of program/erase cycles of
the UCBs must not be exceeded. Over-cycling the UCBs can also lead to an unusable
device.
The installation of the protection and its confirmation on different pages of the UCB offers
the possibility to check the installation before programming the confirmation. First the
protection needs to be programmed, then an application reset must be triggered to
trigger the reading of the UCBs by the PMU and after that the protection can be verified
(e.g. Disable Protection to check the password and by checking PROCONs and
FCON). The application reset is inevitable because the PMU reads the UCBs only during
the startup phase.
8.4.8.2 Flash Read Protection

Read protection can be activated for the whole Flash module.
Read Protection Status

A read access to PFLASH fails with bus error under the following conditions:
Code fetch: FCON.DCF and FCON.RPA.
Data read: FCON.DDF and FCON.RPA.
The read protection bit FCON.RPA is determined during startup by the protection
configuration of UCB0. It can be temporarily modified by the command sequences
Disable Read Protection and Resume Protection which modify FSR.RPRODIS.
FCON.RPA is determined by the following equation:

XMC4500
XMC4000 Family
FCON.RPA = PROCON0.RPRO and not FSR.RPRODIS.

The bits FCON.DDF and FCON.DCF are initialized by the startup software depending
on the configured protection and the startup mode. They can also be directly modified by
the user software under conditions noted in the description of FCON.
Initializing Read Protection

Installation of read protection is performed with the Write User Configuration Page
operation, controlled by the user 0. With this command, user 0 writes the protection
configuration bits RPRO, and the two 32-bit keywords into the UCB0-page 0.
Additionally, with a second Write User Configuration Page command, a special 32-bit
confirmation (lock-) code is written into the UCB0-page2. Only this confirmation code
enables the protection and thus the keywords. The confirmation write operation to the
second wordline of the User Configuration Block shall be executed only after check of
keyword-correctness (with command Disable Read Protection after next reset). The
confirmed state and thus the installation of protection is indicated with the FSR-bit
PROIN in Flash Status Register FSR and for read protection with bit RPROIN in FSR. If
read protection is not correctly confirmed and thus not enabled, the bits PROIN and
RPROIN in the FSR are not set. The configured read protection as fetched from UCB0
is indicated in the protection configuration register PROCON0.
For safety of the information stored in the UCB pages, all keywords, lock bits and the
confirmation code are stored two-times in the two wordlines. In case of a disturbed
original data detected during ramp up, its copy is usedFSR. Layout of the four UC pages
belonging to the users UC block is shown in Table 8-5, the command Write User
Configuration Page is described in Chapter 8.4.7.1.
Disabling Read Protection

With the command sequence Disable Read Protection short-term disabling of read
protection is possible. This command disables the Flash protection (latest until next
reset) for user controlled erase and re-program operations as well as for clearing of DCF
and DDF control bits after external program execution. The Disable Read Protection
command sequence is a protected command, which is only processed by the command
state machine, if the included two passwords are identical to the two keywords of user 0.
The disabled state of read protection is controlled with the FCON.RPA=0 and indicated
in the Flash Status Register FSR with the RPRODIS bit (see Chapter 8.7.3.1). As long
as read protection is disabled (and thus not active), the FCON-bits DDF and DCF can
be cleared.
Resumption of read protection after disablement is performed with the Resume
Read/Write Protection command. After execution of this single cycle command, read
protection (if installed) is again active, indicated by the FCON bit RPA=1.
Generally, Flash read protection will remain installed as long as it is confirmed (locked)
in the User Configuration Block 0. Erase of UC block and re-program of UC pages can

XMC4500
XMC4000 Family
be performed up to 4 times. But note, after execution of the Erase UC block command
(which is protected and therefore requires the preceding disable command with the
users specific passwords), all keywords and all protection installations of user 0 are
erased; thus, the Flash is no more read protected (beginning with next reset) until re-
programming the UC pages. But the division and separation of the protection
configuration data and of the confirmation data into two different UCB-wordlines
guarantees, that a disturb of keywords can be discovered and corrected before the
protection is confirmed. For this reason, the command sequence Disable Read
Protection can also be used when protection is programmed (configured) but not
confirmed; wrong keywords are then indicated by the error flag PROER.
Read protection can be combined with sector specific write protection. In this case, after
execution of the command Disable Read Protection only those sectors are unlocked for
write accesses, which are not separately write protected.
8.4.8.3 Flash Write and OTP Protection

A range of Flash can be write protected by several means:
The complete PFLASH can be write protected by the read protection.
Groups of sectors of PFLASH can be write-protected by three different users, i.e.
UCBs:
UCB0: Write protection that can be disabled with the password of UCB0.
UCB1: Write protection that can be disabled with the password of UCB1.
UCB2: Write protection that can not be disabled anymore (ROM or OTP function:
One-Time Programmable).
Write and OTP Protection Status

An active write protection is indicated by WPROIN bits in FSR register. It causes the
program and erase command sequences to fail with a PROER.
A range x (i.e. a group of sectors, see PROCON0) of the PFLASH is write protected if
any of the following conditions is true:
FCON.RPA
PROCON2.SxROM
PROCON0.SxL and not(FSR.WPRODIS0)
PROCON1.SxL and not(PROCON0.SxL) and not(FSR.WPRODIS1)
Thus with the password of UCB0 the write protection of sectors protected by user 0 and
user 1 can be disabled, however with the password of UCB1 only those sectors that are
only protected by user 1. The write protection of user 2 (OTP) can be obviously not
disabled. The global write protection caused by the read protection can be disabled as
described above by using the password of UCB0 to disable the read protection.

XMC4500
XMC4000 Family
Initialization of Write and OTP Protection

Installation of write protection is performed with the Write User Configuration Page
operation, controlled by the user. With this command, the user defines and writes into
the UCBx page 0 the write protection configuration bits for all sectors, which shall be
locked by the specific user, and the user-specific two keywords (not necessary for
user 2). The position of sector lock bits is identical as defined for the PROCON registers.
The correctness of keywords shall then (after next reset) be checked with the command
Disable Sector Write Protection, which delivers a protection error PROER in case of
wrong passwords. Only if the keywords are correct, the special 32-bit confirmation code
must be written into the page 2 of UCBx with a second Write User Configuration Page
command. Only this confirmation code enables the write protection of the User Control
Block UCBx, and only in this case the installation bit(s) in FSR is (are) set during ramp
up.
Note: If the write protection is configured in the users UCB page 0 but not confirmed via
page 2 (necessary for check of keywords), the state after next reset is as follows:
- The selected sector(s) are protected (good for testing of protection, also of OTP)
- The UCBx is not protected, thus it can be erased without passwords
- The related WPROINx bit in FSR is not set
- The Disable Write Protection command sets the WPRODISx bit
- The Resume command does not clear the WPRODISx bit.
The structure and layout of the three UC blocks is shown in Table 8-3 below, the
command Write User Configuration Page is described in Chapter 8.4.7.1.
Disabling Write Protection (not applicable to OTP)

With the command sequence Disable Sector Write Protection short-term disabling of
write protection for user 0 or user 1 is possible. This command unlocks temporarily all
locked sectors belonging to the user. The Disable Sector Write Protection command
sequence is a protected command, which is only processed by the command state
machine, if the included two passwords are correct. The disabled state of sector
protection is indicated in the Flash Status Register FSR with the WPRODIS bit of the
user 0 or/and user 1 (see Chapter 8.7.3.1). For user 2 who owns the sectors with ROM
functionality, a disablement of write protection and thus re-programming is not possible.
Resumption of write protection after disablement is performed with the Resume
Read/Write Protection command, which is identical for user 0 and user 1.
Generally, sector write protection will remain installed as long as it is configured and
confirmed in the User Configuration Block belonging to the user. Erase of UC block and
re-program of UC pages can be performed up to 4 times, for user 0 and user 1 only. But
note, after execution of the Erase UC block command (which is still protected and
therefore requires the preceding disablement of write protection with the users
passwords), the complete protection configuration including the keywords of the specific
user (not user 2) is erased; thus, the sectors belonging to the user are unprotected until

XMC4500
XMC4000 Family
the users UC pages are re-programmed. Only exception: sectors protected by user 2
are locked for ever because the UCB2 can no more be erased after installation of write
protection in UCB2.
8.4.8.4 System Wide Effects of Flash Protection

An active Flash read protection needs to be respected in the complete system.
The startup software (SSW) checks if the Flash read protection is active in the PMU, if
yes:
If the selected boot mode executes from internal PFLASH.
The SSW clears the DCF and DDF.
The SSW leaves the debug interface locked.
If the selected boot mode does not execute from internal PFLASH:
The SSW either leaves DCF and DDF set or actively sets them again in the PMU
after evaluating the configuration sector.
The debug interface is unlocked.
If the read protection is inactive in the PMU the DCF and DDF flags are cleared by the
SSW and the debug interface is unlocked.
Note: Full Flash analysis of an FAR device is only possible when the customer has
removed all installed protections or delivers the necessary passwords with the
device. As the removal of an OTP protection in UCB2 is not possible the OTP
protection inevitably limits analysis capabilities.
8.4.9 Data Integrity and Safety

The data in Flash is stored with error correcting codes ECC in order to protect against
data corruption. The healthiness of Flash data can be checked with margin checks.
8.4.9.1 Error-Correcting Code (ECC)

The data in the PFLASH is stored with ECC codes. These are automatically generated
when the data is programmed. When data is read these codes are evaluated. Data in
PFLASH uses an ECC code with SEC-DED (Single Error Correction, Double Error
Detection) capabilities. Each block of 64 data bits is accompanied with 8 ECC bits.
Standard PFLASH ECC

In the standard PFLASH ECC the 8-bit ECC value is calculated over 64 data bits. An
erased data block (all bits 0) has an ECC value of 00H. Therefore an erased sector is
free of ECC errors. A data block with all bits 1 has an ECC value of FFH.
The ECC is automatically generated when programming the PFLASH.
The ECC is automatically evaluated when reading data.

XMC4500
XMC4000 Family
This algorithm has the following capabilities:

Single-bit error:
Is noted in FSR.PFSBER.
Data and ECC value are corrected.
Interrupt is triggered if enabled with FCON.PFSBERM.
Double-bit error:
Is noted in FSR.PFDBER.
Causes a bus error if not disabled by MARP.TRAPDIS.
Interrupt is triggered if enabled with FCON.PFDBERM. This interrupt shall only be
used for margin check, when the bus error is disabled.
8.4.9.2 Margin Checks

The Flash memory offers a margin check feature: the limit which defines if a Flash cell
is read as logic 0 or logic 1 can be shifted. This is controlled by the register MARP. The
Margin Control Register MARP is used to change the margin levels for read operations
to find problematic array bits. The array area to be checked is read with more restrictive
margins. Problematic bits will result in a single or double-bit error that is reported to the
CPU by an error interrupt or a bus error trap. The double-bit error trap can be disabled
for margin checks and also redirected to an error interrupt.
After changing the read margin at least tFL_MarginDel have to be waited before reading the
affected Flash module. During erase or program operation only the standard (default)
margins are allowed.

Access and/or operational errors (e.g. wrong command sequences) may be reported to
the user by interrupts, and they are indicated by flags in the Flash Status Register FSR.
Additionally, bus errors may be generated resulting in CPU traps.
8.5.1 Interrupt Control

The PMU and Flash module supports immediate error and status information to the user
by interrupt generation. One CPU interrupt request is provided by the Flash module.
The Flash interrupt can be issued because of following events:
End of busy state: program or erase operation finished
Operational error (OPER): program or erase operation aborted
Verify error (VER): program or erase operation not correctly finished
Protection error
Sequence error
Single-bit error: corrected read data from PFLASH delivered
Double-bit error in Program Flash.

XMC4500
XMC4000 Family
Note: In case of an OPER or VER error, the error interrupt is issued not before the busy
state of the Flash is deactivated.
The source of interrupt is indicated in the Flash Status Register FSR by the error flags
or by the PROG or ERASE flag in case of end of busy interrupt. An interrupt is also
generated for a new error event, even if the related error flag is still set from a previous
error interrupt.
Every interrupt source is masked (disabled) after reset and can be enabled via dedicated
mask bits in the Flash Configuration Register FCON.
8.5.2 Trap Control

CPU traps are executed because of bus errors, generated by the PMU in case of
erroneous Flash accesses. Bus errors are generated synchronously to the bus cycle
requesting the not allowed Flash access or the disturbed Flash read data. Bus errors are
issued because of following events:
Not correctable double-bit error of 64-bit read data from PFLASH (if not disabled for
margin check)
Not allowed write access to read only register (see Table 8-11)
Not allowed write access to Privileged Mode protected register (see Table 8-11)
Not allowed data or instruction read access in case of active read protection
Access to not implemented addresses within the register or array space.
Read-modify-write access to the Flash array.
Write accesses to the Flash array address space are interpreted as command cycles
and initiate not a bus error but a sequence error if the address or data pattern is not
correct. However, command sequence cycles, which address a busy Flash bank, are
serviced with busy cycles, not with a sequence error.
If the trap event is a double-bit error in PFLASH, it is indicated in the FSR. With exception
of this error trap event, all other trap sources cannot be disabled within the PMU.
Note: A double-bit error trap during margin check can be disabled (via MARP register)
and redirected to an interrupt request.
8.5.3 Handling Errors During Operation

The previous sections described shortly the functionality of error indicating bits in the
flash status register FSR. This section elaborates on this with more in-depth explanation
of the error conditions and recommendations how these should be handled by customer
software. This first part handles error conditions occurring during operation (i.e. after
issuing command sequences) and the second part (Section 8.5.3.6) error conditions
detected during startup.

XMC4500
XMC4000 Family
8.5.3.1 SQER Sequence Error

Fault conditions:
Improper command cycle address or data, i.e. incorrect command sequence.
New Enter Page in Page Mode.
Load Page and not in Page Mode.
Load Page results in buffer overflow.
First Load Page addresses 2. word.
Write Page with buffer underflow.
Write Page and not in Page Mode.
Write Page to wrong Flash type.
Byte transfer to password or data.
Clear Status or Reset to Read while busy1).
Erase UCB with wrong UCBA.
New state:
Read mode is entered with following exceptions:
Enter Page in Page Mode re-enters Page Mode.
Write Page with buffer underflow is executed.
After Load Page causing a buffer overflow the Page Mode is not left, a following
Write Page is executed.
Proposed handling by software:
Usually this bit is only set due to a bug in the software. Therefore in development code
the responsible error tracer should be notified. In production code this error should not
occur. It is however possible to clear this flag with Clear Status or Reset to Read and
simply issue the corrected command sequence again.
8.5.3.2 PFOPER Operation Error

Fault conditions:
ECC double-bit error detected in Flash module internal SRAM during a program or erase
operation in PFLASH. This can be a transient event due to alpha-particles or illegal
operating conditions or it is a permanent error due to a hardware defect. This situation
will practically not occur.
Attention: these bits can also be set during startup (see Chapter 8.5.3.6).
New state:
The Flash operation is aborted, the BUSY flag is cleared and read mode is entered.
1) When the command addresses the busy Flash bank, the access is serviced withbusy cycles.

XMC4500
XMC4000 Family
The flag should be cleared with Clear Status. The last operation can be determined
from the PROG and ERASE flags. In case of an erase operation the affected physical
sector must be assumed to be in an invalid state, in case of a program operation only the
affected page. Other physical sectors can still be read. New program or erase
commands must not be issued before the next reset.
Consequently a reset must be performed. This performs a new Flash ramp up with
initialization of the microcode SRAM. The application must determine from the context
which operation failed and react accordingly. Mostly erasing the addressed sector and
re-programming its data is most appropriate. If a Program Page command was affected
and the sector can not be erased the wordline could be invalidated if needed by marking
it with all-one data and the data could be programmed to another empty wordline.
Only in case of a defective microcode SRAM the next program or erase operation will
incur again this error.
Note: Although this error indicates a failed operation it is possible to ignore it and rely on
a data verification step to determine if the Flash memory has correct data. Before
re-programming the Flash the flow must ensure that a new reset is applied.
Note: Even when the flag is ignored it is recommended to clear it. Otherwise all following
operations including sleep could trigger an interrupt even when they are
successful (see Chapter 8.5.1, interrupt because of operational error).
8.5.3.3 PROER Protection Error

Fault conditions:
Password failure.
Erase/Write to protected sector.
Erase UCB and protection active.
Write UC-Page to protected UCB.
Attention: a protection violation can even occur when a protection was not explicitly
installed by the user. This is the case when the Flash startup detects an error and starts
the user software with read-only Flash (see Chapter 8.5.3.6). Trying to change the Flash
memory will then cause a PROER.
New state:
Read mode is entered. The protection violating command is not executed.
Usually this bit is only set during runtime due to a bug in the software. In case of a
password failure a reset must be performed in the other cases the flag can be cleared
with Clear Status or Reset to Read. After that the corrected sequence can be
executed.

XMC4500
XMC4000 Family
8.5.3.4 VER Verification Error

Fault conditions:
This flag is a warning indication and not an error. It is set when a program or erase
operation was completed but with a suboptimal result. This bit is already set when only
a single bit is left over-erased or weakly programmed which would be corrected by the
ECC anyhow.
However, excessive VER occurrence can be caused by operating the Flash out of the
specified limits, e.g. incorrect voltage or temperature. A VER after programming can also
be caused by programming a page whose sector was not erased correctly (e.g. aborted
erase due to power failure).
Under correct operating conditions a VER after programming will practically not occur. A
VER after erasing is not unusual.
Attention: this bit can also be set during startup (see Chapter 8.5.3.6).
New state:
No state change. Just the bit is set.
This bit can be ignored. It should be cleared with Clear Status or Reset to Read. In-
spec operation of the Flash memory must be ensured.
If the application allows (timing and data logistics), a more elaborate procedure can be
used to get rid of the VER situation:
VER after program: erase the sector and program the data again. This is only
recommended when there are more than 3 program VERs in the same sector. When
programming the Flash in field ignoring program VER is normally the best solution
because its most likely cause are violated operating conditions. Take care that never
a sector is programmed in which the erase was aborted.
VER after erase: the erase operation can be repeated until VER disappears.
Repeating the erase more than 3 times consecutively for the same sector is not
recommended. After that it is better to ignore the VER, program the data and check
its readability. Again its most likely cause are violated operating conditions. Therefore
it is recommended to repeat the erase at most once or ignore it altogether.
For optimizing the quality of Flash programming see the following section about handling
single-bit ECC errors.
Note: Even when this flag is ignored it is recommended to clear it. Otherwise all following
operations including sleep could trigger an interrupt even when they are
successful (see Chapter 8.5.1, interrupt because of verify error).
8.5.3.5 PFSBER/DFSBER Single-Bit Error

Fault conditions:

XMC4500
XMC4000 Family
When reading data or fetching code from PFLASH the ECC evaluation detected a single-
bit error (SBE) which was corrected.
This flag is a warning indication and not an error. A certain amount of single-bit errors
must be expected because of known physical effects.
New state:
No state change. Just the bit is set.
This flag can be used to analyze the state of the Flash memory. During normal operation
it should be ignored. In order to count single-bit errors it must be cleared by Clear
Status or Reset to Read after each occurrence1).
Usually it is sufficient after programming data to compare the programmed data with its
reference values ignoring the SBE bits. When there is a comparison error the sector is
erased and programmed again.
When programming the PFLASH (end-of-line programming or SW updates) customers
can further reduce the probability of future read errors by performing the following check
after programming:
Change the read margin to high margin 0.
Verify the data and count the number of SBEs.
When the number of SBEs exceeds a certain limit (e.g. 10 in 2 Mbyte) the affected
sectors could be erased and programmed again.
Repeat the check for high margin 1.
Each sector should be reprogrammed at most once, afterwards SBEs can be
ignored.
Due to the specificity of each application the appropriate usage and implementation of
these measures (together with the more elaborate VER handling) must be chosen
according to the context of the application.
8.5.3.6 Handling Flash Errors During Startup

During startup, a fatal error during Flash ramp up forces the Firmware to terminate the
startup process and to end in the Debug Monitor Mode (see Firmware chapter).
The reason for a failed Flash startup can be a hardware error or damaged configuration
data.
1) Further advice: remember that the ECC is evaluated when the data is read from the PMU. When counting
single-bit errors use always the non-cached address range otherwise the error count can depend on cache hit
or miss and it refers to the complete cache line. As the ECC covers a block of 64 data bits take care to evaluate
the FSR only once per 64-bit block.

XMC4500
XMC4000 Family
FSR bits set after startup are of informative warning nature.

FSR.PFOPER can indicate a problem of a program/erase operation before the last
system reset or an error when restoring the Flash module internal SRAM content after
the last reset. In both cases it is advised to clear the flag with the command sequence
Clear Status and trigger a system reset. If the error shows up again it is an indication
for a permanent fault which will limit the Flash operation to read accesses. Under this
condition program and erase operations are forbidden (but not blocked by hardware!).

The following chapters describe the required power supplies, the power consumption
and its possible reduction, the control of Flash Sleep Mode and the basic control of
Reset.
8.6.1 Power Supply

The Flash module uses the standard VDDP I/O power supply to generate the voltages for
both read and write functions. Internally generated and regulated voltages are provided
for the program and erase operations as well as for read operations. The standard VDDC
is used for all digital control functions.
8.6.2 Power Reduction

The Flash Sleep Mode can be used to drastically reduce power consumption while the
Flash is not accessed for longer periods of time.
The Idle Read Path slightly reduces the dynamic power consumption during normal
operation with marginal impact on the Flash read performance.
Flash Sleep Mode

As power reduction feature, the Flash module provides the Flash Sleep mode which can
be selected by the user individually for the Flash. The Sleep mode can be requested by:
Programming 1B to the bit FCON.SLEEP.
External sleep mode by the SCU (see Flash Power Control in the SCU). Only
executed by the Flash when FCON.ESLDIS = 0B.
Attention: fCPU must be equal or above 1 MHz when Sleep mode is requested until
the Sleep mode is indicated in FSR.SLM, and when a wake-up request
is triggered, until FSR.PBUSY is cleared.
The requested Sleep mode is only taken if the Flash is in idle state and when all pending
or active requests are processed and terminated. Only then, the Flash array performs
the ramp down into the Sleep mode: the sense amplifiers are switched off and the
voltages are ramped down.
During ramp down to Sleep mode FSR.PBUSY is set.

XMC4500
XMC4000 Family
As long as the Flash is in Sleep mode, this state is indicated by the bit FSR.SLM. The
FSR.PBUSY stays set as well.
Wake-up from sleep is controlled with clearing of bit FCON.SLEEP, if selected via this
bit, or wake-up is initiated by releasing the external sleep signal from SCU. After wake-
up, the Flash enters read mode and is available again after the wake-up time tWU. During
the wake-up phase the FSR.PBUSY is set until the wake-up process is completed.
Note: During sleep and wake-up, the Flash is reported to be busy. Thus, read and write
accesses to the Flash in Sleep mode are acknowledged with busy and should
therefore be avoided; those accesses make sense only during wake-up, when
waiting for the Flash read mode.
2. The wake-up time tWU is documented in the Data Sheet. This time may fully delay the
interrupt response time in Sleep mode.
3. Note: A wake-up is only accepted by the Flash if it is in Sleep mode. The Flash will
first complete the ramp down to Sleep mode before reacting to a wake-up trigger.
Idle Read Path

An additional power saving feature is enabled by setting FCON.IDLE. In this case the
PFLASH read path (Flash Read Access) is switched off when no read access is
pending. System performance for sequential accesses is slightly reduced because
internal linear prefetches of the PFLASH are disabled. Non-sequential read accesses
requested by the CPU or any other bus master see no additional delayed.
8.6.3 Reset Control

All PMU and Flash functionality is reset with the system reset with the exception of the
register bits: FSR.PROG, FSR.ERASE, FSR.PFOPER. These bits are reset with the
power-on reset.
The flash will be automatically reset to the read mode after every reset.
8.6.3.1 Resets During Flash Operation

A reset or power failure during an ongoing Flash operation (i.e. program or erase) must
be considered as violation of stable operating conditions. However the Flash was
designed to prevent damage to non-addressed Flash ranges when the reset is applied
as defined in the data sheet. The exceptions are erasing logical sectors and UCBs.
Aborting an erase process of a logical sector can leave the complete physical sector
unreadable.When an UCB erase is aborted the complete Flash can become unusable.
So UCBs must be only erased in a controlled environment. The addressed Flash range
is left in an undefined state.
When an erase operation is aborted the addressed logical or physical sector can contain
any data. It can even be in a state that doesnt allow this range to be programmed.

XMC4500
XMC4000 Family
When a page programming operation is aborted the page can still appear as erased (but
contain slightly programmed bits), it can appear as being correctly programmed (but the
data has a lowered retention) or the page contains garbage data. It is also possible that
the read data is instable so that depending on the operating conditions different data is
read.
For the detection of an aborted Flash process the flags FSR.PROG and FSR.ERASE
could be used as indicator but only when the reset was a System Reset. Power-on resets
can not be determined from any flags. It is not possible to detect an aborted operation
simply by reading the Flash range. Even the margin reads dont offer a reliable
indication.
When erasing or programming the PFLASH usually an external instance can notice the
reset and simply restart the operation by erasing the Flash range and programming it
again.
However, in cases where this external instance is not existing, a common solution is
detecting an abort by performing two operations in sequence and determine after reset
from the correctness of the second the completeness of the first operation.
E.g. after erasing a sector a page is programmed. After reset the existence of this page
proves that the erase process was performed completely.
The detection of aborted programming processes can be handled similarly. After
programming a block of data an additional page is programmed as marker. When after
reset the block of data is readable and the marker is existent it is ensured that the block
of data was programmed without interruption.
If a complete page can be spent as marker, the following recipe allows to reduce the
marker size to 8 bytes. This recipe violates the rule that a page may be programmed only
once. This violation is only allowed for this purpose and only when the algorithm is robust
against disturbed pages (see also recommendations for handling single-bit errors) by
repeating a programming step when it detects a failure.
Robust programming of a page of data with an 8 byte marker:
1. After reset program preferably always first to an even page (Target Page).
2. If the Other Page on the same wordline contains active data save it to SRAM (the
page can become disturbed because of the 4 programming operations per wordline).
3. Program the data to the Target Page.
4. Perform strict check of the Target Page (see below).
5. Program 8 byte marker to Target Page.
6. Perform strict check of the Target Page.
7. In case of any error of the strict check go to the next wordline and program the saved
data and the target data again following the same steps.
8. Ensure that the algorithm doesnt repeat unlimited in case of a violation of operating
conditions.
Strict checking of programmed data:

XMC4500
XMC4000 Family
1. Ignore single-bit errors and the VER flag.

2. Switch to tight margin 0.
3. If the data (check the complete page) is not equal to the expected data report an
error.
4. If a double-bit error is detected report an error.
After reset the algorithm has to check the last programmed page if it was programmed
completely:
1. Read with normal read level. Ignore single-bit errors.
2. Read 8-byte marker and check for double-bit error.
3. Read data part and verify its consistency (e.g. by evaluating a CRC). Check for
double-bit error.
4. If the data part is defective dont use it (e.g. by invalidating the page).
5. If the data part is ok:
a) If the marker is erased the data part could have been programmed incompletely.
Therefore the data part should not be used or alternatively it could be programmed
again to a following page.
b) If the marker contains incorrect data the data part was most likely programmed
correctly but the marker was programmed incompletely. The page could be used
as is or alternatively the data could be programmed again to a following page.
c) If the marker is ok the data part was programmed completely and has the full
retention. However this is not ensured for the marker part itself. Therefore the
algorithm must be robust against the case that the marker becomes unreadable
later.
8.6.4 Clock
The Flash interface is operating at the same clock speed as the CPU, fCPU. Depending
on the frequency, wait states must be inserted in the Flash accesses. Further details
onthe wait states configuration are give in Chapter 8.4.4.
For proper operation of command sequences and when entering or waking up
from Sleep mode, fCPU must be equal or above 1 MHz.
8.7 Registers
The register set consists of the PMU ID register (Chapter 8.7.1), the Prefetch Control
register (Chapter 8.7.2). The other registers control Flash functionality (Chapter 8.7.3).
All accesses prevented due to access mode restrictions fail with a bus error.
Also accesses to unoccupied register addresses fail with a bus error.
8.7.1 PMU Registers

The PMU only contains the ID register.

XMC4500
XMC4000 Family

reserved 5800 0000H 5800 04FFH Bus Error
PMU0 5800 0500H 5800 05FFH
reserved 5800 0600H 5800 0FFFH Bus Error
reserved 5800 2400H 5800 3FFFH Bus Error

Short Name Description Offset Access Mode Reset Page
Addr.1) Read Write Class Number
ID Module Identification 08H U, PV BE System 8-31

Reset
1) The absolute register address is calculated as follows:
Module Base Address (Table 8-6) + Offset Address (shown in this column)
8.7.1.1 PMU ID Register

The PMU0_ID register is a read-only register, thus write accesses lead to a bus error
trap. Read accesses are permitted in Privileged Mode PV and in User Mode. The
PMU0_ID register is defined as follows:
PMU0_ID
PMU0 Identification Register (5800 0508H) Reset Value: 00A1 C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MOD_NUMBER
r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MOD_TYPE MOD_REV
r r

XMC4500
XMC4000 Family

MOD_REV defines the module revision number. The
value of a module revision starts with 01H (first rev.).
This bit field is C0H. It defines the module as a 32-bit
module.
This bit field defines the module identification number
for PMU0.
8.7.2 Prefetch Registers

This section describes the register of the Prefetch unit.

PREF 5800 4000H 5800 7FFFH Prefetch Module
Registers

Short Name Description Offset Access Mode Reset Page
Addr.1) Read Write Class Number
PCON Prefetch Configuration 0H U, PV U, PV System Page 8-

Register Reset 33
8.7.2.1 Prefetch Configuration Register

This register provides control bits for instruction buffer invalidation and bypass.

XMC4500
XMC4000 Family
PREF_PCON
Prefetch Configuration Register (5800 4000H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0
r rwrw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 IINV IBYP
r r r r w rw

IBYP 0 rw Instruction Prefetch Buffer Bypass
0B Instruction prefetch buffer not bypassed.
1B Instruction prefetch buffer bypassed.
IINV 1 w Instruction Prefetch Buffer Invalidate
Write Operation:
0B No effect.
1B Initiate invalidation of entire instruction cache.
0 16 rw Reserved
Must be written with 0.
4, 3, 2, returns 0 if read; should be written with 0.
[31:17]
8.7.3 Flash Registers

All register addresses are word aligned, independently of the register width. Besides
word-read/write accesses, also byte or half-word read/write accesses are supported.
The absolute address of a Flash register is calculated by the base address from
Table 8-10 plus the offset address of this register from Table 8-11.

FLASH0 5800 1000H 5800 23FFH Flash registers of PMU0

XMC4500
XMC4000 Family
The following table shows the addresses, the access modes and reset types for the
Flash registers in PMU0:
Table 8-11 Addresses of Flash0 Registers

Short Description Address Access Mode Reset See
Name Read Write
Reserved 5800 2000H BE BE
5800 2004H
FLASH0_ Flash Module 5800 2008H U, PV BE System Page
ID Identification Register Reset 8-44
Reserved 5800 200CH BE BE
FLASH0_ Flash Status Register 5800 2010H U, PV BE System Page
FSR + 8-35
PORST
FLASH0_ Flash Configuration 5800 2014H U, PV PV System Page
FCON Register Reset 8-41
FLASH0_ Flash Margin Control 5800 2018H U, PV PV System Page
MARP Register PFLASH Reset 8-45
FLASH0_ Flash Protection 5800 2020H U, PV BE System Page
PROCON0 Configuration User 0 Reset 8-46
Reserved 5800 202CH BE BE
5800 23FCH
8.7.3.1 Flash Status Definition

The Flash Status Register FSR reflects the overall status of the Flash module after Reset
and after reception of the different commands. Sector specific protection states are not
indicated in the FSR, but in the registers PROCON0, PROCON1 and PROCON2. The
status register is a read-only register. Only the error flags and the two status flags
(PROG, ERASE) are affected with the Clear Status command. The error flags are also
cleared with the Reset to Read command.
The FSR is defined as follows:

XMC4500
XMC4000 Family
FSR
Flash Status Register (1010H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
W W W W W R R
PRO
VER X 0 SLM 0 PRO PRO 0 PRO PRO PRO 0 PRO PRO 0
IN
DIS1 DIS0 IN2 IN1 IN0 DIS IN
rh rh r rh r rh rh r rh rh rh r rh rh r rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PF PF PF PF FA P
PRO SQ ERA PRO
0 DB 0 SB 0 OP 0 PAG 0 0 BUS BUS
ER ER SE G
ER ER ER E Y Y
r rh r rh rh rh r rh r rh rh rh r r rh rh

1)
PBUSY 0 rh Program Flash Busy
HW-controlled status flag.
0B PFLASH ready, not busy; PFLASH in read
mode.
1B PFLASH busy; PFLASH not in read mode.
Indication of busy state of PFLASH because of
active execution of program or erase operation;
PFLASH busy state is also indicated during Flash
recovery (after reset) and in power ramp-up state or
in sleep mode; while in busy state, the PFLASH is
not in read mode.
FABUSY1) 1 rh Flash Array Busy
Internal busy flag for testing purposes. Must be
ignored by application software, which must use
PBUSY instead.

XMC4500
XMC4000 Family

PROG3)4) 4 rh Programming State
0B There is no program operation requested or in
progress or just finished.
1B Programming operation (write page)
requested (from FIM) or in action or finished.
Set with last cycle of Write Page command
sequence, cleared with Clear Status command (if not
busy) or with power-on reset. If one BUSY flag is
coincidently set, PROG indicates the type of busy
state. If xOPER is coincidently set, PROG indicates
the type of erroneous operation. Otherwise, PROG
indicates, that operation is still requested or finished.
ERASE3)4) 5 rh Erase State
0B There is no erase operation requested or in
progress or just finished
1B Erase operation requested (from FIM) or in
action or finished.
Set with last cycle of Erase command sequence,
cleared with Clear Status command (if not busy) or
with power-on reset. Indications are analogous to
PROG flag.
PFPAGE1)2) 6 rh Program Flash in Page Mode
0B Program Flash not in page mode
1B Program Flash in page mode; assembly buffer
of PFLASH (256 byte) is in use (being filled up)
Set with Enter Page Mode for PFLASH, cleared with
Write Page command
Note: Concurrent page and read modes are allowed
2)3)4)
PFOPER 8 rh Program Flash Operation Error
0B No operation error reported by Program Flash
1B Flash array operation aborted, because of a
Flash array failure, e.g. an ECC error in
microcode.
This bit is not cleared with System Reset, but with
power-on reset.
Registered status bit; must be cleared per command

XMC4500
XMC4000 Family

SQER1)2)3) 10 rh Command Sequence Error
0B No sequence error
1B Command state machine operation
unsuccessful because of improper address or
command sequence.
A sequence error is not indicated if the Reset to
Read command aborts a command sequence.
PROER1)2)3) 11 rh Protection Error
0B No protection error
1B Protection error.
A Protection Error is reported e.g. because of a not
allowed command, for example an Erase or Write
Page command addressing a locked sector, or
because of wrong password(s) in a protected
command sequence such as Disable Read
Protection
PFSBER1)2)3) 12 rh PFLASH Single-Bit Error and Correction
0B No Single-Bit Error detected during read
access to PFLASH
1B Single-Bit Error detected and corrected
PFDBER1)2)3) 14 rh PFLASH Double-Bit Error
0B No Double-Bit Error detected during read
access to PFLASH
1B Double-Bit Error detected in PFLASH
PROIN 16 rh Protection Installed
0B No protection is installed
1B Read or/and write protection for one or more
users is configured and correctly confirmed in
the User Configuration Block(s).
HW-controlled status flag

XMC4500
XMC4000 Family

RPROIN 18 rh Read Protection Installed
0B No read protection installed
1B Read protection and global write protection is
configured and correctly confirmed in the User
Configuration Block 0.
Supported only for the master user (user zero).
RPRODIS1)5) 19 rh Read Protection Disable State
0B Read protection (if installed) is not disabled
1B Read and global write protection is temporarily
disabled.
Flash read with instructions from other memory, as
well as program or erase on not separately write
protected sectors is possible.
WPROIN0 21 rh Sector Write Protection Installed for User 0
0B No write protection installed for user 0
1B Sector write protection for user 0 is configured
and correctly confirmed in the User
WPROIN1 22 rh Sector Write Protection Installed for User 1
0B No write protection installed for user 1
1B Sector write protection for user 1 is configured
and correctly confirmed in the User
WPROIN2 23 rh Sector OTP Protection Installed for User 2
0B No OTP write protection installed for user 2
1B Sector OTP write protection with ROM
functionality is configured and correctly
confirmed in the UCB2. The protection is
locked for ever.

XMC4500
XMC4000 Family

WPRODIS01)5) 25 rh Sector Write Protection Disabled for User 0
0B All protected sectors of user 0 are locked if
write protection is installed
1B All write-protected sectors of user 0 are
temporarily unlocked, if not coincidently locked
by user 2 or via read protection.
Hierarchical protection control: User-0 sectors are
also unlocked, if coincidently protected by user 1.
But not vice versa.
WPRODIS11)5) 26 rh Sector Write Protection Disabled for User 1
0B All protected sectors of user 1 are locked if
write protection is installed
1B All write-protected sectors of user 1 are
temporarily unlocked, if not coincidently locked
by user 0 or user 2 or via read protection.
SLM1) 28 rh Flash Sleep Mode
HW-controlled status flag. Indication of Flash sleep
mode taken because of global or individual sleep
request; additionally indicates when the Flash is in
shut down mode.
0B Flash not in sleep mode
1B Flash is in sleep or shut down mode
X 30 rh Reserved
Value undefined
VER1)3) 31 rh Verify Error
0B The page is correctly programmed or the
sector correctly erased. All programmed or
erased bits have full expected quality.
1B A program verify error or an erase verify error
has been detected. Full quality (retention time)
of all programmed (1) or erased (0) bits
cannot be guaranteed.
See Chapter 8.5.3 and Chapter 8.5.3.6 for proper
reaction.

XMC4500
XMC4000 Family

0 2,3,7, r Reserved
9,13, Read zero, no write
15,17,
20,24,
27, 29
Note: The footnote numbers of FSR bits describe the specific reset conditions:
1)Cleared with System Reset
2)Cleared with command Reset to Read
3)Cleared with command Clear Status
4)Cleared with power-on reset (PORST)
5)Cleared with command Resume Protection
Note: The xBUSY flags as well as the protection flags cannot be cleared with the Clear
Status command or with the Reset to Read command. These flags are
controlled by HW.
Note: The reset value above is indicated after correct execution of Flash ramp up.
Additionally, errors are possible after ramp up (see Chapter 8.5.3.6).
8.7.3.2 Flash Configuration Control

The Flash Configuration Register FCON reflects and controls the following general Flash
configuration functions:
Number of wait states for Flash accesses.
Indication of installed and active read protection.
Instruction and data access control for read protection.
Interrupt mask bits.
Power reduction and shut down control.
FCON is a Privileged Mode protected register. It is defined as follows:

XMC4500
XMC4000 Family
FCON
Flash Configuration Register (1014H) Reset value: 0007 0006H1)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PF PF
EOB PRO SQ VOP
0 DB 0 SB 0 0 0 0 0 DDF DCF RPA
M ERM ERM ERM
ERM ERM
rw r rw r rw rw rw rw r r r r r rwh rwh rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
WS
SL ESL
IDLE 0 EC WSPFLASH
EEP DIS
PF
rw rw rw r r r rw rw
1) After Flash ramp up and execution of the startup software in BROM (after firmware exit), the initial value is
000X 0006H.

WSPFLASH [3:0] rw Wait States for read access to PFLASH
This bit field defines the number of wait states n, which
are used for an initial read access to the Program
Flash memory area, with
WSPFLASH x (1 / fCPU) ta1).
0000B PFLASH access in one clock cycle
0001B PFLASH access in one clock cycle
0010B PFLASH access in two clock cycles
0011B PFLASH access in three clock cycles
.... PFLASH access in four up to fourteen clock cycles.
1111B PFLASH access in fifteen clock cycles.
WSECPF 4 rw Wait State for Error Correction of PFLASH
0B No additional wait state for error correction
1B One additional wait state for error correction
during read access to Program Flash.
If enabled, this wait state is only used for the
first transfer of a burst transfer.
Set this bit only when requested by Infineon.
IDLE 13 rw Dynamic Flash Idle
0B Normal/standard Flash read operation
1B Dynamic idle of Program Flash enabled for
power saving; static prefetching disabled

XMC4500
XMC4000 Family

ESLDIS 14 rw External Sleep Request Disable
0B External sleep request signal input is enabled
1B Externally requested Flash sleep is disabled
The external signal input is connected with a global
power-down/sleep request signal from SCU.
SLEEP 15 rw Flash SLEEP
0B Normal state or wake-up
1B Flash sleep mode is requested
Wake-up from sleep is started with clearing of the
SLEEP-bit.
RPA 16 rh Read Protection Activated
This bit monitors the status of the Flash-internal read
protection. This bit can only be 0 when read
protection is not installed or while the read protection
is temporarily disabled with password sequence.
0B The Flash-internal read protection is not
activated. Bits DCF, DDF are not taken into
account. Bits DCF, DDFx can be cleared
1B The Flash-internal read protection is activated.
Bits DCF, DDF are enabled and evaluated.
DCF 17 rwh Disable Code Fetch from Flash Memory
This bit enables/disables the code fetch from the
internal Flash memory area. Once set, this bit can
only be cleared when RPA=0.
This bit is automatically set with reset and is cleared
during ramp up, if no RP installed, and during startup
(BROM) in case of internal start out of Flash.
0B Code fetching from the Flash memory area is
allowed.
1B Code fetching from the Flash memory area is
not allowed. This bit is not taken into account
while RPA=0.

XMC4500
XMC4000 Family

DDF 18 rwh Disable Any Data Fetch from Flash
This bit enables/disables the data read access to the
Flash memory area (Program Flash and Data Flash).
Once set, this bit can only be cleared when RPA=0.
This bit is automatically set with reset and is cleared
during ramp up, if no RP installed, and during startup
(BROM) in case of internal start out of Flash.
0B Data read access to the Flash memory area is
allowed.
1B Data read access to the Flash memory area is
not allowed. This bit is not taken into account
while RPA=0.
VOPERM 24 rw Verify and Operation Error Interrupt Mask
0B Interrupt not enabled
1B Flash interrupt because of Verify Error or
Operation Error in Flash array (FSI) is enabled
SQERM 25 rw Command Sequence Error Interrupt Mask
1B Flash interrupt because of Sequence Error is
enabled
PROERM 26 rw Protection Error Interrupt Mask
1B Flash interrupt because of Protection Error is
enabled
PFSBERM 27 rw PFLASH Single-Bit Error Interrupt Mask
0B No Single-Bit Error interrupt enabled
1B Single-Bit Error interrupt enabled for PFLASH
PFDBERM 29 rw PFLASH Double-Bit Error Interrupt Mask
0B Double-Bit Error interrupt for PFLASH not
enabled
1B Double-Bit Error interrupt for PFLASH enabled.
Especially intended for margin check
EOBM 31 rw End of Busy Interrupt Mask
1B EOB interrupt is enabled
[23:19], Always read/write zero
28, 30

XMC4500
XMC4000 Family
1) WSPFLASH = 0H deviates from this formula and results in the same timing as WSPFLASH = 1H.
Note: The default numbers of wait states represent the slow cases. This is a general
proceeding and additionally opens the possibility to execute higher frequencies
without changing the configuration.
Note: After reset and execution of Firmware, the read protection control bits are coded
as follows:
DDF, DCF, RPA = 110: No read protection installed
DDF, DCF, RPA = 001: Read protection installed; start in internal Flash
DDF, DCF, RPA = 111: Read protection installed; start not in internal Flash.
8.7.3.3 Flash Identification Register

The module identification register of Flash module is directly accessible by the CPU via
PMU access. This register is mapped into the space of the Flash Interface Modules
registers (see Table 8-11).
FLASH0_ID
Flash Module Identification Register (1008H) Reset Value: 00A2 C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MOD_NUMBER
r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MOD_TYPE MOD_REV
r r

MOD_REV defines the module revision number. The
value of a module revision starts with 01H (first
revision).
module.

XMC4500
XMC4000 Family

This bit field defines a module identification number.
For the XMC4500 Flash0 this number is 00A2H.
8.7.3.4 Margin Check Control Register
MARP
Margin Control Register PFLASH (1018H) Reset Value: 0000 8000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TR
AP 0 MARGIN
DIS
rw r rw

MARGIN [3:0] rw PFLASH Margin Selection
0000BDefault, Standard (default) margin.
0001BTight0, Tight margin for 0 (low) level.
Suboptimal 0-bits are read as 1s.
0100BTight1, Tight margin for 1 (high) level.
Suboptimal 1-bits are read as 0s.
Reserved.
TRAPDIS 15 rw PFLASH Double-Bit Error Trap Disable
0B If a double-bit error occurs in PFLASH, a bus
error trap is generated1).
1B The double-bit error trap is disabled.
Shall be used only during margin check
[31:16] Always read as 0; should be written with 0.
1) After Boot ROM exit, double-bit error traps are enabled (TRAPDIS = 0).

XMC4500
XMC4000 Family
8.7.3.5 Protection Configuration Indication

The configuration of read/write/OTP protection is indicated with registers PROCON0,
PROCON1 and PROCON2, thus separately for every user, and it is generally indicated
in the status register FSR.
If write protection is installed for user 0 or 1 or OTP protection for user 2, for each sector
of the Program Flash it is indicated in the user-specific Protection Configuration register
PROCONx, if it is locked or unlocked for program or erase operations.
The Flash Protection Configuration registers PROCONx are loaded by the FIM state
machine out of the users configuration block directly after reset during ramp up. The
three PROCONx registers are read-only registers.
PROCON0
Flash Protection Configuration Register User 0
(1020H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R S10_
0 0 0 0 S9L S8L S7L S6L S5L S4L S3L S2L S1L S0L
PRO S11L
rh r rh rh rh rh rh rh rh rh rh rh rh rh rh rh

SnL (n=0-9) n rh Sector n Locked for Write Protection by User 0
These bits indicate whether PFLASH sector n is
write-protected by user 0 or not.
0B No write protection is configured for sector n.
1B Write protection is configured for sector n.

XMC4500
XMC4000 Family

S10_S11L 10 rh Sectors 10 and 11 Locked for Write Protection by
User 0
This bit is only used if PFLASH has more than
0.5 Mbyte. It indicates whether PFLASH sectors
10+11 (together 512 KB) are write-protected by user
0 or not.
0B No write protection is configured for
sectors 10+11.
1B Write protection is configured for sectors
10+11.
RPRO 15 rh Read Protection Configuration
This bit indicates whether read protection is
configured for PFLASH by user 0.
0B No read protection configured
1B Read protection and global write protection is
configured by user 0 (master user)
0 13, 12, rh Reserved
11 deliver the corresponding UCB0 entry. Shall be
configured to 0.
14 Always reads as 0.
PROCON1
(1024H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
S10_
0 0 0 0 S9L S8L S7L S6L S5L S4L S3L S2L S1L S0L
S11L
r rh rh rh rh rh rh rh rh rh rh rh rh rh rh

XMC4500
XMC4000 Family

SnL (n=0-9) n rh Sector n Locked for Write Protection by User 1
These bits indicate whether PFLASH sector n is
write-protected by user 1 or not.
0B No write protection is configured for sector n.
1B Write protection is configured for sector n.
S10_S11L 10 rh Sectors 10 and 11 Locked for Write Protection by
User 1
10+11 (together 512 KB) are write-protected by
user 1 or not.
0B No write protection is configured for
sectors 10+11.
1B Write protection is configured for sectors
10+11.
0 13, 12, rh Reserved
11 Deliver the corresponding UCB1 entry. Shall be
configured to 0.
15, 14 Always reads as 0.
PROCON2
(1028H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
S10_
S9 S8 S7 S6 S5 S4 S3 S2 S1 S0
0 0 0 0 0 S11
ROM ROM ROM ROM ROM ROM ROM ROM ROM ROM
ROM
r r rh rh rh rh rh rh rh rh rh rh rh rh rh rh

XMC4500
XMC4000 Family

SnROM (n=0- n rh Sector n Locked Forever by User 2
9) These bits indicate whether PFLASH sector n is an
OTP protected sector with read-only functionality,
thus if it is locked for ever.
0B No ROM functionality configured for sector n.
1B ROM functionality is configured for sector n.
Re-programming of this sector is no longer
possible.
S10_S11ROM 10 rh Sectors 10 and 11 Locked Forever by User 2
10+11 (together 512 KB) are read-only sectors or
not.
0B No ROM functionality is configured for
sectors 10+11.
1B ROM functionality is configured for sectors
10+11.
0 13, 12, r Reserved
11 Deliver the corresponding UCB2 entry. Shall be
configured to 0.
15, 14 Always reads as 0.

XMC4500
XMC4000 Family
System Control
System Control

XMC4500
XMC4000 Family
Window Watchdog Timer (WDT)
9 Window Watchdog Timer (WDT)

Purpose of the Window Watchdog Timer module is an improvement of the system
integrity. The WDT triggers the system reset or other corrective actions like e.g. non-
maskable interrupt if the main program, due to some fault condition, neglects to regularly
service the watchdog (also referred to as kicking the dog, petting the dog, feeding
the watchdog or waking the watchdog). The intention is to bring the system back from
unresponsive state into normal operation.
References
[9] Cortex-M4 User Guide, ARM DUI 0508B (ID062910)
9.1 Overview
A successful servicing of the WDT results in a pulse on the signal wdt_service. The
signal is offered also as an alternate function output. It can be used to show to an
external watchdog that the system is alive.
The WDT timer is a 32-bit counter, which counts up from 0H. It can be serviced while the
counter value is within the window boundary, i.e. between the lower and the upper
boundary value. Correct servicing results in a reset of the counter to 0H. A so called Bad
Service attempt results in a system reset request.
The timer block is running on the fWDT clock which is independent from the bus clock. The
timer value is updated in the corresponding register TIM, whenever the timer value
increments. This mechanism enables immediate response on a read access from the
bus.
The WDT module provides a register interface for configuration. A write to writable
registers is only allowed, when the access is in privileged mode. A write access in user
mode results in a bus error response.
9.1.1 Features
The watchdog timer (WDT) is an independent window watchdog timer.
The features are:
Triggers system reset when not serviced on time or serviced in a wrong way
Servicing restricted to be within boundaries of a user definable refresh window
Can run from an independent clock
Provides service indication to an external pin
Can be suspended in HALT mode
Provides optional pre-warning alarm before reset

WDT, V2.2 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Table 9-1 Application Features

Feature Purpose/Application
System reset upon Bad Servicing Triggered to restore system stable
operation and ensure system integrity
Servicing restricted to be within Allows to consider minimum and maximum
defined boundaries of refresh window software timing
Independent clocks To ensure that WDT counts even in case
of the system clock failure
Service indication on external pin For dual-channel watchdog solution,
additional external control of system
integrity
Suspending in HALT mode Enables safe debugging with productive
code
Pre-warning alarm Software recovery to allow corrective
action via software recovery routine
bringing system back from the
unresponsive state into normal operation
9.1.2 Block Diagram

The WDT block diagram is shown in Figure 9-1.

XMC4500
XMC4000 Family
PBA2
Bus Interface
wdt_service SCU.HCU
external
WDT watchdog
Registers
CPU wdt_alarm SCU.GCU
HALTED
wdt_rst_req SCU.RCU
Timer
SCU.CCU fWDT
Figure 9-1 Watchdog Timer Block Diagram
9.2 Time-Out Mode
An overflow results in an immediate reset request going to the RCU of the SCU via the
signal wdt_rst_req whenever the counter crosses the upper boundary it triggers an
overflow event pre-warning is not enabled with CTR register. A successful servicing
performed with writing a unique value, referred to as Magic Word to the SRV register
of the WDT within the valid servicing window, results in a pulse on the signal wdt_service
and reset of the timer counter.

XMC4500
XMC4000 Family
WDT WDT First

serviced serviced overflow
Window Upper Bound
Window Lower Bound
0H
No
Servicing
servicing
allowed
allowed
wdt_service
wdt_alarm
wdt_rst_req
Figure 9-2 Reset without pre-warning

The example scenario depicted in Figure 9-2 shows two consecutive service pulses
generated from WDT module as the result of successful servicing within valid time
windows. The situation where no service has been performed immediately triggers
generation of reset request on the wdt_rst_req output after the counter value has
exceeded window upper bound value.
9.3 Pre-warning Mode

While in prewarning mode the effect of the overflow event is different with and without
pre-warning enabled. The first crossing of the upper bound triggers the outgoing alarm
signal wdt_alarm when pre-warning is enabled. Only the next overflow results a reset
request. The alarm status is shown via register WDTSTS and can be cleared via register
WDTCLR. A clear of the alarm status will bring the WDT back to normal state. The alarm
signal is routed as request to the SCU, where it can be promoted to NMI.

XMC4500
XMC4000 Family
WDT First Second

serviced overflow overflow
Window Upper Bound
Window Lower Bound
0H
No
Servicing
servicing
allowed
allowed
wdt_service
wdt_alarm
wdt_rst_req
Figure 9-3 Reset after pre-warning

The example scenario depicted in Figure 9-3 shows service pulse generated from WDT
module as the result of successful servicing within valid time window. WDT generates
alarm pulse on wdt_alarm upon first missing servicing. The alarm signal is routed as
interrupt request to the SCU, where it can be promoted to NMI. Within this alarm service
request the user can clear the WDT status bit and give a proper WDT service before it
overflows next time. Otherwise WDT generates reset request on wdt_rstn upon the
second missing service.
9.4 Bad Service Operation

A bad service attempt results in a reset request. A bad service attempt can be due to
servicing outside the window boundaries or servicing with an invalid Magic Word.

XMC4500
XMC4000 Family
serviced
WDT in wrong
serviced window
Window Upper Bound
Window Lower Bound
0H
No
Servicing
servicing
allowed
allowed
wdt_service
wdt_alarm
wdt_rst_req
Figure 9-4 Reset upon servicing in a wrong window

The example in Figure 9-4 shows servicing performed outside of valid servicing window.
Attempt to service WDT while counter value remains below the Window Lower Bound
results in immediate reset request on wdt_rst_req signal.
serviced with
WDT invalid magic
serviced word
Window Upper Bound
Window Lower Bound
0H
No
Servicing
servicing
allowed
allowed
wdt_service
wdt_alarm
wdt_rst_req
Figure 9-5 Reset upon servicing with a wrong magic word

XMC4500
XMC4000 Family
The example in Figure 9-5 shows servicing performed within a valid servicing window
but with an invalid Magic Word. Attempt to write a wrong word to the SRV register results
in immediate reset request on wdt_rst_req signal.
9.5 Service Request Processing

The WDT generates watchdog alarm service requests via wdt_alarm output signal upon
first counter overflow over Watchdog Upper Bound when pre-warning mode is enabled.
The alarm service request may be promoted by the SCU in two alternative modes:
service request
trap request causing NMI interrupt
Service requests can be disabled i SCU with service request mask or trap request
disable registers respectively.
9.6 Debug Behavior

The WDT function can be suspended when the CPU enters HALT mode. WDT debug
function is controlled by DSP bit field in CTR register.

The WDT module is a part of the core domain and supplied with VDDC voltage.
All WDT registers get reset with the system reset.
A sticky bit in the RSSTAT register of SCU/RCU module indicates whether the last
system reset has been triggered by the WDT module. This bit does not get reset with
system reset.
The input clock of the WDT counter can be selected by the user between system PLL
output, direct output of the internal system oscillator or 32kHz clock of hibernate domain,
independently from the AHB interface clock. Selection of the WDT input clock is
performed in SCU using WDTCLKCR register (for details please refer to the SCU/CCU
chapter).
9.8 Initialization and Control Sequence

The programming model of the WDT module assumes several scenarios where different
control sequences apply.
Note: Some of the scenarios described in this chapter require operations on system
level the that are not in the scope of the WDT module description, therefore for
detailed information please refer to relevant chapters of this document.

XMC4500
XMC4000 Family
9.8.1 Initialization & Start of Operation

Complete WDT module initialization is required after system reset.
check reason for last system reset in order to determine power state
read out SCU_RSTSTAT.RSTSTAT register bit field to determine last system
reset cause
perform appropriate operations dependent on the last system reset cause
WDT software initialization sequence
enable WDT clock with SCU_CLKSET.WDTCEN register bit field
release WDT reset with SCU_PRCLR2.WDTRS register bit field
set lower window bound with WDT_WLB register
set upper window bound with WDT_WUB register
configure external watchdog service indication (optional, please refer to SCU/HCU
chapter)
select and enable WDT input clock with SCU_WDTCLKCR register
enable system trap for pre-warning alarm on system level with SCU_NMIREQEN
register (optional, used in WDT pre-warning mode only)
software start sequence
select mode (Time-Out or Pre-warning) and enable WDT module with WDT_CTR
register
service the watchdog
check current timer value in WDT_TIM register against programmed time window
write magic word to WDT_SRV register within valid time window
9.8.2 Reconfiguration & Restart of Operation

Reset and initialization of the WDT module is required in order to update its settings.
software initialization sequence

assert WDT reset with SCU_PRSET2.WDTCEN register bit field
release WDT reset with SCU_PRCLR2.WDTRS register bit field register
set lower window bound with WDT_WLB register
set upper window bound with WDT_WUB register
configure external watchdog service indication (optional, please refer to SCU/HCU
chapter)
select and enable WDT input clock (if change of the clock settings required) with
SCU_WDTCLKCR register
enable system trap for pre-warning alarm on system level with SCU_NMIREQEN
register (optional, used in WDT pre-warning mode only)
software start sequence
select mode (Time-Out or Pre-warning) and enable WDT module with WDT_CTR
register

XMC4500
XMC4000 Family

9.8.3 Software Stop & Resume Operation

The WDT module can be stopped and re-started at any point of time for e.g. debug
purpose using software sequence.
software stop sequence

disable WDT module with WDT_CTR register
perform any user operations
software start (resume) sequence
enable WDT module with WDT_CTR register with WDT_CTR register
9.8.4 Enter Sleep/Deep Sleep & Resume Operation

The WDT counter clock can be configured to stop while in sleep or deep-sleep mode. No
direct software interaction with the WDT is required in those modes and no watchdog
time-out will fire if the WDT clock is configured to stop while CPU is sleeping.
software configuration sequence for sleep/deep-sleep mode

configure WDT behavior with SCU register SLEEPCR or DSLEEPCR
enter sleep/deep-sleep mode software sequence
select sleep or deep-sleep mode in CPU (for details please refer to Cortex-M4
documentation [9])
enter selected mode (for details please refer to Cortex-M4 documentation [9])
wait for a wake-up event (no software interaction, CPU stopped)
resume operation (CPU clock restarted automatically on an event)
9.8.5 Prewarning Alarm Handling

The WDT will fire prewarning alarm before requesting system reset while in pre-warning
mode and not serviced within valid time window. The WDT status register indicating
alarm must be cleared before the timer counter value crosses the upper bound for the
second time after firing the alarm. After clearing of the alarm status regular watchdog
servicing must be performed within valid time window.

XMC4500
XMC4000 Family
alarm event
exception routine (system trap or service request) clearing WDT_WDTSTAT
register with WDT_WDTCLR register

XMC4500
XMC4000 Family
9.9 Registers
Registers Overview
All these registers can be read in User Mode, but can only be written in Supervisor Mode.

WDT 5000 8000H 5000 BFFFH Watchdog Timer
Registers

Short Name Register Long Name Offset Access Mode Description
Addr. Read Write
WDT Kernel Registers
ID Module ID Register 00H U, PV PV Page 9-11
CTR Control Register 04H U, PV PV Page 9-12
SRV Service Register 08H BE PV Page 9-13
TIM Timer Register 0CH U, PV BE Page 9-14
WLB Window Lower Bound 10H U, PV PV Page 9-14
WUB Window Upper Bound 14H U, PV PV Page 9-14
WDTSTS Watchdog Status Register 18H U, PV PV Page 9-15
WDTCLR Watchdog Status Clear 1CH U, PV PV Page 9-16
Register
9.9.1 Registers Description
ID
The module ID register.

XMC4500
XMC4000 Family
ID
WDT ID Register (00H) Reset Value: 00AD C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MOD_NUMBER MOD_TYPE MOD_REV
r r r

MOD_REV [7:0] r Module Revision
Indicates the revision number of the implementation.
This information depends on the design step.
This internal marker is fixed to C0H.
MOD_NUMBER [31:16] r Module Number
Indicates the module identification number
CTR
The operation mode control register.
CTR
WDT Control Register (04H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SPW 0 DSP 0 PRE ENB
rw r rw r rw rw

ENB 0 rw Enable
0B disables watchdog timer,
1B enables watchdog timer

XMC4500
XMC4000 Family

PRE 1 rw Pre-warning
0B disables pre-warning
1B enables pre-warning,
DSP 4 rw Debug Suspend
0B watchdog timer is stopped during halting mode
debug,
1B watchdog timer is not stopped during halting mode
debug
SPW [15:8] rw Service Indication Pulse Width
Pulse width (SPW+1) of service indication
in fWDT cycles
0 [3:2], r Reserved
[7:5],
[31:16]
SRV
The WDT service register. Software must write a magic word while the timer value is
within the valid window boundary. Writing the magic word while the timer value is within
the window boundary will service the watchdog and result a reload of the timer with 0H.
Upon writing data different than the magic word within valid time window or writing even
correct Magic Word but outside of the valid time window no servicing will be performed.
Instead will request an immediate system reset request.
SRV
WDT Service Register (08H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SRV

SRV [31:0] w Service
Writing the magic word ABADCAFEH while the timer
value is within the window boundary will service the
watchdog.

XMC4500
XMC4000 Family
TIM
The actual watchdog timer register count value. This register can be read by software in
order to determine current position in the WDT time window.
TIM
WDT Timer Register (0CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TIM
rh

TIM [31:0] rh Timer Value
Actual value of watchdog timer value.
WLB
The Window Lower Bound register defines the lower bound for servicing window.
Servicing of the watchdog has only effect within the window boundary
WLB
WDT Window Lower Bound Register (10H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
WLB
rw

WLB [31:0] rw Window Lower Bound
Lower bound for servicing window.
Setting the lower bound to 0H disables the window
mechanism.
WUB
The Window Upper Bound register defines the upper bound for servicing window.
Servicing of the watchdog has only effect within the window boundary.

XMC4500
XMC4000 Family
WUB
WDT Window Upper Bound Register (14H) Reset Value: FFFF FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
WUB
rw

WUB [31:0] rw Window Upper Bound
Upper Bound for servicing window.
The WDT triggers an reset request when the timer is
crossing the upper bound value without pre-warning
enabled.
With pre-warning enabled the first crossing triggers a
watchdog alarm and the second crossing triggers a
system reset.
WDTSTS
The status register contains sticky bit indicating occurrence of alarm condition.
WDTSTS
WDT Status Register (0018H) Reset Value: 00000000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ALM
0
S
r r

ALMS 0 r Pre-warning Alarm
1B pre-warning alarm occurred,
0B no pre-warning alarm occurred

XMC4500
XMC4000 Family

0 [31:1] r Reserved
WDTCLR
The status register contains sticky bit field indicating occurrence of alarm condition.
WDTCLR
WDT Clear Register (001CH) Reset Value: 00000000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ALM
0
C
r w

ALMC 0 w Pre-warning Alarm
1B clears pre-warning alarm
0B no-action
0 [31:1] r Reserved
9.10 Interconnects
Table 9-4 Pin Table

Input/Output I/O Connected To Description
Clock and Reset Signals
fWDT I SCU.CCU timer clock
Timer Signals
wdt_service O SCU.HCU service indication to external
watchdog

XMC4500
XMC4000 Family
Table 9-4 Pin Table (contd)

HALTED I CPU In halting mode debug.
HALTED remains
asserted while the core is in
debug.
Service Request Connectivity
wdt_alarm O SCU.GCU pre-warning alarm
wdt_rst_req O SCU.RCU reset request

XMC4500
XMC4000 Family
Real Time Clock (RTC)
10 Real Time Clock (RTC)

Real-time clock (RTC) is a clock that keeps track of the current time. RTCs are present
in almost any electronic device which needs to keep accurate time in a digital format for
clock displays and real-time actions.
10.1 Overview
The RTC module tracks time with separate registers for hours, minutes, and seconds.
The calendar registers track date, day of the week, month and year with automatic leap
year correction.
The RTC is capable of running from an alternate source of power, so it can continue to
keep time while the primary source of power is off or unavailable. The timer remains
operational when the core domain is in power-down. The kernel part of the RTC keeps
running as long as the hibernate domain is powered with an alternate supply source. The
alternate source can be for example a lithium battery or a supercapacitor.
10.1.1 Features
The features of the Real Time Clock (RTC) module are:
Precise real time keeping with
32.768 kHz external crystal clock
32.768 kHz high precision internal clock
Periodic time-based interrupt
Programmable alarm interrupt on time match
Supports wake-up mechanism from hibernate state
Table 10-1 Application Features

Feature Purpose/Application
Precise real-time keeping Reduced need for time adjustments
Periodic time-based interrupt Scheduling of operations performed on
precisely defined intervals
Programmable alarm interrupt on time Scheduling of operations performed on
match precisely defined times
Supports wake-up mechanism from Autonomous wake up from hibernate for
hibernate state system state control and maintaintenance
routine operations
10.1.2 Block Diagram

The RTC block diagram is shown in Figure 10-1.

RTC, V2.2 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
The main building blocks of the RTC is Time Counter implementing real time counter and
RTC registers containing multi-field registers for the time counter and alarm
programming register. Dedicated fields represent values for elapsing second, minutes,
hours, days, days of week, months and years.
The kernel of the RTC module is instantiated in the hibernate domain.
The RTC registers are instantiated in hibernate domain and mirrored in SCU. Access to
the RTC registers is performed via register mirror updated over serial interface.
Time
Counter alarm
RTC
periodic_event
SCU
Prescaler RTC Serial

Registers Interface
32.768 kHz clock
Figure 10-1 Real-Time Clock Block Diagram Structure
10.2 RTC Operation

The RTC timer counts seconds, minutes, hours, days of month, days of week, months
and years each in a separate field (see Figure 10-2). Individual bit fields of the RTC
counter can be programmed and read with software over serial interface via mirror
registers in SCU module. For details of the serial communication please refer to SCU
chapter.

XMC4500
XMC4000 Family
seconds minutes hours days months years
Alarm Time
(ATIM0 & ATIM1)
alarm
Real Time
=
(TIM0 & TIM1)
days of
week
Prescaler
1 second seconds minutes hours days months years
tick
periodic_event
Periodic Service Request Logic
Figure 10-2 Block Diagram of RTC Time Counter

Occurrence of an internal timer event is stored in the service request raw status register
RAWSTAT. The values of the status register RAWSTAT drive the outgoing service
request lines alarm and periodic_event.
10.3 Register Access Operations

The RTC module is a part of SCU from programmming model perepcetive and shares
register address space for configuration with other sub-modulesof SCU. RTC registers
are instantiated in hibernate domain are mirrored in SCU. The registers get updated in
both clock domains over serial interface running at 32kHz clock rate.
Any update of the registers is performed with some delay required for data to propagate
to and from the mirror registers over serial interface. Accesses to the RTC registers in
core domain must not block the bus interface of SCU module. For details of the register
mirror and serial communication handling please refer to SCU chapter.
A write to writable registers is only allowed, when the access is in privileged mode. A
write access in user mode results in a bus error response.
For consistent write to the timer registers TIM0 and TIM1, the register TIM0 has to be
written before the register TIM1.

XMC4500
XMC4000 Family
After wake-up from hibernate state the content of the mirror registers TIM0 and TIM1 is
undefined until the first update of the corresponding RTC timers occurs and is
propagated to the registers.
For consistent read-out of the timer registers TIM0 and TIM1, the register TIM0 has to
be read before the register TIM1. The value of TIM1 is stored in a shadow register upon
each read of TIM0 before they get copied to the mirror register in core domain.

The RTC generates service requests upon:
periodic timer events
configured alarm condition
The service requests can be processed in the core domain as regular service requests
or as wake-up triggers from hibernate mode in HCU module in hibernate domain (for
more details please refer to hibernate control description in SCU chapter).
10.4.1 Periodic Service Request

The periodic timer service request is raised whenever a non-masked field of the timer
counter gets updated. Masking of the bits is performed using MSKSR register. Periodic
Service requests can be disabled with MSKSR.
10.4.2 Timer Alarm Service Request

The alarm interrupt is triggered when TIM0 and TIM1 bit fields values match all
corresponding bit fields values of ATIM0, ATIM1 registers selected with CTR register.
Timer Alarm Service requests can be disabled with CTR.
10.5 Debug behavior

The RTC clock does not implement dedicated debug mechanisms.

RTC is instantiated entirely in hibernate domain and remains powered up when
hibernate domain is powered up. Supply voltage is passed either from VDDP or VBAT
pin as specified in the SCU chapter.
The RTC module remains in reset state along with entire hibernate domain after initial
power up of hibernate domain until reset released with software.
The RTC timer is running from ether internal or external 32.768 kHz clock selectable with
HDCR control register of SCU/HCU module. The prescaler setting of 7FFFH results in an
once per second update of the RTC timer.

XMC4500
XMC4000 Family
10.7 Initialization and Control Sequence

Programming model of the RTC module assumes several scenarios where different
control sequences apply.
Note: Some of the scenarios described in this chapter require operations on system
level the that are not in the scope of the RTC module description, therefore for
detailed information please refer to relevant chapters of this document.
10.7.1 Initialization & Start of Operation

Complete RTC module initialization is required upon hibernate domain reset. The
hibernate domain needs to be enabled before any programming of RTC registers takes
place. Accesses to RTC registers are performed via dedicated mirror registers (for more
details please refer to SCU chapter)
enable hibernate domain (if not disabled)
write one to SCU_PWRSET.HIB
release reset of hibernate domain reset (if asserted)
write one to SCU_RSTCLR.HIBRS
enable RTC module to start counting time
write one to RTC_CTR.ENB
program RTC_TIM0 and RTC_TIM1 registers with current time
check SCU_MIRRSTS to ensure that no transfer over serial interface is pending
to the RTC_TIM0 register
write a new value to the RTC_TIM0 register
10.7.2 Re-configuration & Re-start of Operation

Reset and re-initialization of the RTC module may be required without complee power
up sequence of the hibernate domain.
apply and release reset of hibernate domain reset
write one to SCU_RSTSET.HIBRS
write one to SCU_RSTCLR.HIBRS
enable RTC module to start counting time
write one to RTC_CTR.ENB
program RTC_TIM0 and RTC_TIM1 registers with current time

XMC4500
XMC4000 Family
10.7.3 Configure and Enable Periodic Alarm

The RTC periodic alarm configuration require programming in order to enable intrrupt
request generation out upon a change of value in the corresponding bit fields.
enable service request for periodic timer events in RTC module
to the RTC_MSKSR register
set MAI bit field of RTC_MSKSR register in order enable individual periodic timer
events
enable service request for periodic timer events in RTC module
set PI bit field of SCU_SRMSK register in order enable generation of interrupts
upon periodic timer events
10.7.4 Configure and Enable Timer Alarm

The RTC periodic alarm configuration require programming in order to enable intrrupt
request generation out upon compare match of values in the corresponding bit fields of
TIM0 and TIM1 against ATIM0 and ATIM1 respectively.
program compare values in individual bit fields of ATIM0 and ATIM1 in RTC module
to the RTC_ATIM0 register
write to RTC_ATIM0 register bit fields
to the RTC_ATIM1 register
write to RTC_ATIM1 register bit fields
enable service request for timer alarm events in RTC module
to the RTC_CTR register
set TAE bit field of RTC_CTR register in order enable individual periodic timer
events
enable service request for timer alarm events in RTC module
write one to AI bit field of SCU_SRMSK register in order enable generation of
interrupts upon periodic timer events

XMC4500
XMC4000 Family
10.8 Registers
Registers Overview

RTC 5000 4A00H 5000 4BFFH Accessible via Mirror
Registers

Addr. Read Write
RTC Kernel Registers
ID ID Register 0000H U, PV BE Page 10-7
CTR Control Register 0004H U, PV PV Page 10-8
RAWSTAT Raw Service Request 0008H U, PV BE Page 10-9
Register
STSSR Status Service Request 000CH U, PV BE Page 10-10
Register
MSKSR Mask Service Request 0010H U, PV PV Page 10-11
Register
CLRSR Clear Service Request 0014H BE PV Page 10-13
Register
ATIM0 Alarm Time Register 0 0018H U,PV PV Page 10-14
ATIM1 Alarm Time Register 1 001CH U,PV PV Page 10-15
TIM0 Time Register 0 0020H U, PV PV Page 10-16
TIM1 Time Register 1 0024H U, PV PV Page 10-18
ID
Read-only ID register of the RTC module containing unique identification code of the
RTC module.

XMC4500
XMC4000 Family
ID
RTC ID Register (00H) Reset Value: 00A3 C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
r r r

CTR
RTC Control Register providing control means of the operation mode of the module.
CTR
RTC Control Register (04H) Reset Value: 7FFF 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DIV
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EYE EMO EDA EHO EMI ESE
0 0 0 TAE 0 ENB
C C C C C C
r rw rw r rw rw rw rw r rw r rw

ENB 0 rw RTC Module Enable
0B disables RTC module
1B enables RTC module

XMC4500
XMC4000 Family

TAE 2 rw Timer Alarm Enable
0B disable timer alarm
1B enable timer alarm
ESEC 8 rw Enable Seconds Comparison
0B disabled
1B enabled
EMIC 9 rw Enable Minutes Comparison
0B disabled
1B enabled
EHOC 10 rw Enable Hours Comparison
0B disabled
1B enabled
EDAC 11 rw Enable Days Comparison
0B disabled
1B enabled
EMOC 13 rw Enable Months Comparison
0B disabled
1B enabled
EYEC 14 rw Enable Years Comparison
0B disabled
1B enabled
DIV [31:16] rw Divider Value
reload value of RTC prescaler. Clock is divided by
DIV+1.
7FFFH is default value for RTC mode with 32.768
kHz crystal or internal clock
0 1,[7:3], r Reserved
12,15 Read as 0; should be written with 0
RAWSTAT
RTC Raw Service Request Register contains raw status info i.e. before status mask
takes effect on generation of service requests. This register serves debug purpose but
can be also used for polling of the status without generating serice requests.

XMC4500
XMC4000 Family
RAWSTAT
RTC Raw Service Request Register (08H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RPY RPM RPD RPH RPM RPS
0 RAI 0 0
E O A O I E
r rh r rh rh r rh rh rh rh

RPSE 0 rh Raw Periodic Seconds Service Request
Set whenever seconds count increments
RPMI 1 rh Raw Periodic Minutes Service Request
Set whenever minutes count increments
RPHO 2 rh Raw Periodic Hours Service Request
Set whenever hours count increments
RPDA 3 rh Raw Periodic Days Service Request
Set whenever days count increments
RPMO 5 rh Raw Periodic Months Service Request
Set whenever months count increments
RPYE 6 rh Raw Periodic Years Service Request
Set whenever years count increments
RAI 8 rh Raw Periodic Alarm Service Request
Set whenever count value matches compare value
0 4, r Reserved
7,
[31:9]
STSSR
RTC Service Request Status Register contains status info reflecting status mask effect
on generation of service requests. This register needs to be accessed by software in
order to determine the actual cause of an event.

XMC4500
XMC4000 Family
STSSR
RTC Service Request Status Register (0CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SPY SPM SPD SPH SPS
0 SAI 0 0 SPMI
E O A O E
r rh r rh rh r rh rh rh rh

SPSE 0 rh Periodic Seconds Service Request Status after
Masking
SPMI 1 rh Periodic Minutes Service Request Status after
Masking
SPHO 2 rh Periodic Hours Service Request Status after
Masking
SPDA 3 rh Periodic Days Service Request Status after
Masking
SPMO 5 rh Periodic Months Service Request Status after
Masking
SPYE 6 rh Periodic Years Service Request Status after
Masking
SAI 8 rh Periodic Alarm Service Request Status after
Masking
0 4, r reserved
7,
[31:9]
MSKSR
RTC Service Request Mask Register contains masking value for generation control of
service requests or interrupts.

XMC4500
XMC4000 Family
MSKSR
RTC Service Request Mask Register (10H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MPY MPM MPD MPH MPM MPS
0 MAI 0 0
E O A O I E
r rw r rw rw r rw rw rw rw

MPSE 0 rw Periodic Seconds Interrupt Mask
0B disable
1B enable
MPMI 1 rw Periodic Minutes Interrupt Mask
0B disable
1B enable
MPHO 2 rw Periodic Hours Interrupt Mask
0B disable
1B enable
MPDA 3 rw Periodic Days Interrupt Mask
0B disable
1B enable
MPMO 5 rw Periodic Months Interrupt Mask
0B disable
1B enable
MPYE 6 rw Periodic Years Interrupt Mask
0B disable
1B enable
MAI 8 rw Periodic Alarm Interrupt Mask
0B disable
1B enable
0 4, r Reserved
7,
[31:9]

XMC4500
XMC4000 Family
CLRSR
RTC Clear Service Request Register serves purpose of clearing sticky bits of
RAWSTAT and STSSR registers. Write one to a bit in order to clear it is set. Writing zero
has no effect on the set nor reset bits.
CLRSR
RTC Clear Service Request Register (14H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RPY RPM RPD RPH RPM RPS
0 RAI 0 0
E O A O I E
r w r w w r w w w w

RPSE 0 w Raw Periodic Seconds Interrupt Clear
0B no effect
1B clear raw status bit
RPMI 1 w Raw Periodic Minutes Interrupt Clear
0B no effect
RPHO 2 w Raw Periodic Hours Interrupt Clear
0B no effect
RPDA 3 w Raw Periodic Days Interrupt Clear
0B no effect
RPMO 5 w Raw Periodic Months Interrupt Clear
0B no effect
RPYE 6 w Raw Periodic Years Interrupt Clear
0B no effect

XMC4500
XMC4000 Family

RAI 8 w Raw Alarm Interrupt Clear
0B no effect
0 4, r Reserved
7,
[31:9]
ATIM0
RTC Alarm Time Register 0 serves purpose of programming single alarm time at a
desired point of time reflecting comparison configuration in the CTR for individual fields
against TIM0 register. The register contains portion of bit fields for seconds, minutes,
hours and days. Upon attempts to write an invalid value to a bit field e.g. exceeding
maximum value default value gets programmed as described for each individual bit
fields.
ATIM0
RTC Alarm Time Register 0 (18H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 ADA 0 AHO
r rw r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 AMI 0 ASE
r rw r rw

ASE [5:0] rw Alarm Seconds Compare Value
Match of seconds timer count to this value triggers
alarm seconds interrupt.
Setting value equal or above 3CH results in setting
the field value to 0H

XMC4500
XMC4000 Family

AMI [13:8] rw Alarm Minutes Compare Value
Match of minutes timer count to this value triggers
alarm minutes interrupt.
AHO [20:16] rw Alarm Hours Compare Value
Match of hours timer count to this value triggers
alarm hours interrupt.
Setting value equal or above 18H results in setting
ADA [28:24] rw Alarm Days Compare Value
Match of days timer count to this value triggers
alarm days interrupt.
Setting valueequal above 1FH results in setting the
field value to 0H
0 [7:6], r Reserved
[15:14],
[23:21],
[31:29]
ATIM1
RTC Alarm Time Register 1 serves purpose of programming single alarm time at a
desired point of time reflecting comparison configuration in the CTR for individual fields
against TIM1 register. The ATM1 register contains portion of bit fields for days of week,
months and years. Upon attempts to write an invalid value to a bit field e.g. exceeding
maximum value default value gets programmed as described for each individual bit
fields.

XMC4500
XMC4000 Family
ATIM1
RTC Alarm Time Register 1 (1CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
AYE
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 AMO 0
r rw r

AMO [11:8] rw Alarm Month Compare Value
Match of months timer count to this value triggers
alarm month interrupt.
Setting value equal or above the number of days of
the actual month count results in setting the field
value to 0H
AYE [31:16] rw Alarm Year Compare Value
Match of years timer count to this value triggers
alarm years interrupt.
0 [7:0], r Reserved
[15:12]
TIM0
RTC Time Register 0 contains current time value for seconds, minutes, hours and days.
The bit fields get updated in intervals corresponding with their meaning accordingly. The
register needs to be programmed to reflect actual time after initial power up and will
continue counting time also while in hibernate mode. Upon attempts to write an invalid
value to a bit bield e.g. exceeding maximum value a default value gets programmed as
described for each individual bit fields.

XMC4500
XMC4000 Family
TIM0
RTC Time Register 0 (20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 DA 0 HO
r rwh r rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 MI 0 SE
r rwh r rwh

SE [5:0] rwh Seconds Time Value
the field value to 0H.
Value can only be written, when RTC is disabled.
After wake-up from hibernate, value is undefined
until first update of RTC.
MI [13:8] rwh Minutes Time Value
the field value to 0H.
HO [20:16] rwh Hours Time Value
Setting value equal or above 18H results in setting

XMC4500
XMC4000 Family

DA [28:24] rwh Days Time Value
Setting value equal or above the number of days of
the actual month count results in setting the field
value to 0H
Days counter starts with value 0 for the first day of
month.
0 [7:6], r Reserved
[15:14],
[23:21],
[31:29]
TIM1
RTC Time Register 1 contains current time value for days of week, months and years.
The bit fields get updated in intervals corresponding with their meaning accordingly. The
register needs to be programmed to reflect actual time after initial power up and will
continue counting time also while in hibernate mode. Upon attempts to write an invalid
value to a bit bield e.g. exceeding maximum value a default value gets programmed as
described for each individual bit fields.
TIM1
RTC Time Register 1 (24H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
YE
rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 MO 0 DAWE
r rwh r rwh

XMC4500
XMC4000 Family

DAWE [2:0] rwh Days of Week Time Value
Setting value above 6H results in setting the field
value to 0H
Days counter starts with value 0 for the first day of
week.
MO [11:8] rwh Month Time Value
Setting value equal or above CH results in setting the
field value to 0H.
Months counter starts with value 0 for the first month
of year.
YE [31:16] rwh Year Time Value
0 [7:3], r Reserved
[15:12]
10.9 Interconnects
Table 10-4 Pin Connections

Clock Signals
fRTC I SCU.HCU 32.768 kHz clock selected in
hibernate domain
Service Request Connectivity
periodic_event O SCU.GCU Timer periodic service request
alarm O SCU.GCU Alarm service request

XMC4500
XMC4000 Family
System Control Unit (SCU)
11 System Control Unit (SCU)

The SCU is the SoC power, reset and a clock manager with additional responsibility of
providing system stability protection and other auxiliary functions.
11.1 Overview
The functionality of the SCU described in this chapter is organized in the following sub-
chapters, representing different aspects of system control:
Miscellaneous control functions, Chapter 11.2
Power Control, Chapter 11.3
Hibernate Control, Chapter 11.4
Reset Control, Chapter 11.5
Clock Control, Chapter 11.6
11.1.1 Features
The following features are provided for monitoring and controlling the system:
General Control
Boot Mode Detection
Memory Content Protection
Trap Generation
Die Temperature Measurement
Retention Memory Support
Power Control
Power Sequencing
EVR Control
Supply Watchdog
Voltage Monitoring
Power Validation
Power State Indication
Flash Power Control
Hibernate Control
Hibernate Mode Control
Wake-up from Hibernate Mode
Hibernate Domain Control
Reset Control
Reset assertion on various reset request sources
System Reset Generation
Inspection of Reset Sources After Reset
Selective Module reset
Clock Control

SCU, V2.5 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Input clock selection

Clock Generation
Clock Distribution
Clock Supervision
Power Management
RTC Clock

The block diagram shown in Figure 11-1 reflects logical organization of the System
Control Unit.
Power Control Unit (PCU)
Hibernate Control Unit (HCU)
Reset Control Unit (RCU)
General Control Unit (GCU)
Clock Control Unit (CCU)

XMC4500
XMC4000 Family
Bus Interface
SCU Register
Interface
Parity Error
Trap Request RTC
GCU RTC Module
Service Request Interface
NMI/IRQ
Retention Memory
EVR Module
PCU HCU Hibernate Control
I/O Control
Wake-up Triggers
XTAL1
XTAL2 Reset Requests

CCU RCU
EXTCLK Reset Signals
Clock Signals
Figure 11-1 SCU Block Diagram
Interface of General Control Unit

The General Control Unit GCU has a memory fault interface to the memory validation
logic of each on-chip SRAM and the Flash to receive memory fault events, as parity
errors. NMI request are routed to the unit to be gated and combined. The GCU provides
the start up protection to all units, which require an additional level of protection.
Interface of Power Control Unit

The Power Control Unit PCU has an interface to the Embedded Voltage Regulator (EVR)
and an interface to the PORTS module. The PCU related signals are described in more
detail in Chapter 11.3.
Interface of Reset Control Unit

The Reset Control Unit RCU has an interface to the Embedded Voltage Regulator
(EVR). The RCU receives from the EVR the power-on reset and the reset information for

XMC4500
XMC4000 Family
each power related reset. Reset requests are coming to the unit from the watchdog, the
CPU and the test control unit. The RCU is providing the reset signals to all other units of
the chip in the Core power domain. The RCU related signals are described in more detail
in Chapter 11.5.
Interface of Clock Control Unit

The Clock Control Unit (CCU) receives the external clock source via the crystal pins
XTAL1 and XTAL2. As further clock source the CCU receives the standby clock fSTDBY
from the Hibernate domain. The CCU drives an external clock output, where internal
clocks can be routed out. The CCU provides the clock signals to all other units of the
chip.
Interface of Hibernate Power Domain

The interface to the Hibernate domain provides mirror registers updated via a shared
serial interface to the Retention Memory, RTC module registers and Hibernate domain
control registers. Update of the mirror registers over the serial is controlled using
MIRRSTS, RMDATA and RMACR registers. End of update can also trigger service
requests via SRSTAT register. Refresh of the Hibernate domain registers in the register
mirror are performed continuously, as fast as possible in order to instantly reflect any
register state change on both sides. The serial interface is inactivated while in hibernate
mode in order to reduce power.
Interface of Retention Memory

Access to the Retention Memory is served over shared serial interface identical to the
one used to access Hibernate domain registers, for detail please refer to Interface of
Hibernate Power Domain on Page 11-4.
Interface of RTC
Access to the RTC module is served over shared serial interface identical to the one
used to access Hibernate domain registers, for detail please refer to Interface of
Hibernate Power Domain on Page 11-4. The RTC module functionality is described
in separate RTC chapter.

XMC4500
XMC4000 Family
11.2 Miscellaneous control functions

System Control implements system management functions accessible via GCU
registers. General system control including various auxiliary function is performed in
General Control Unit (GCU).
11.2.1 Startup Software Support

Externally driven boot mode pins decide the boot mode after a power on reset. It also
possible for applications to decide the boot mode. Ability to determine boot mode values
on boot mode pins and user application desired boot modes is provided by SCU.

XMC4500
XMC4000 Family
11.2.2 Service Requests

Service request events listed in Table 11-1 can result in assertion of a regular interrupt
or an NMI. Please refer to SRMSK and NMIREQEN register description.
The interrupt structure is shown in Figure 11-2. The interrupt request or the
corresponding interrupt set bit (in register SRSET) can trigger the interrupt generation at
the selected interrupt node x. The service request pulse is generated independently from
the interrupt flag in register SRSTAT. The interrupt flag can be cleared by software by
writing to the corresponding bit in register SRCLR. In addition several service requests
can be promoted to NMI trigger level using NMIREQEN register
SRSET.x SRCLR.x SRMSK.x SRSTAT.x NMIREQEN.x
clear
to NMI request
combined output
Service
request
Request set raw request & 1
Event x 1 SRRAW.x
to IRQ request
combined output
Figure 11-2 Service Request Subsystem

The trap flag in register SRSTAT can be cleared by software by writing to the
corresponding bit in register SRCLR. All trap requests are combined to one common line
and connected to a regular interrupt node or NMI node of NVIC.
The trap requests have a sticky flag in register SRRAW.
Note: When servicing an SCU service request, make sure that all related request flags
are cleared after the identified request has been handled.
11.2.2.1 Service Request Sources

The SCU supports service request sources listed in Table 11-2 and reflected in the
SRSTAT, SRRAW, SRMSK, SRCLR and SRSET registers.

XMC4500
XMC4000 Family
Table 11-1 Service Requests

Service Request Name Service Request Short Name
WDT pre-warning PRWARN
RTC Periodic Event PI
RTC Alarm AI
DLR Request Overrun DLROVR
HDCTAT Mirror Register Updated HDSTAT
HDCLR Mirror Register Updated HDCLR
HDSET Mirror Register Updated HDSET
HDCR Mirror Register Updated HDCR
OSCSICTRL Mirror Register Updated OSCSICTRL
OSCULSTAT Mirror Register Updated OSCULSTAT
OSCULCTRL Mirror Register Updated OSCULCTRL
RTC CTR Mirror Register Updated RTC_CTR
RTC ATIM0 Mirror Register Updated RTC_ATIM0
RTC ATIM1 Mirror Register Updated RTC_ATIM1
RTC TIM0 Mirror Register Updated RTC_TIM0
RTC TIM1 Mirror Register Updated RTC_TIM1
Retention Memory Mirror Register Updated RMX
11.2.3 Memory Content Protection

For supervising the content of the on-chip memories, the following mechanism is
provided:
All on-chip SRAMs provide protection of content via parity checking. The parity logic
generates additional parity bits which are stored along with each data word at a write
operation. A read operation implies checking of the previous stored parity information.
An occurrence of a parity error is observable at the memory error raw status register. It
is configurable whether a memory error should trigger an NMI or system reset.
11.2.3.1 Parity Error Handling

The on-chip RAM modules check parity information during read accesses and in case of
an error a signal can be generated if enabled with PEEN register. Two modes of parity
error signalling are implemented:
bus error
parity error trap (NMI)

XMC4500
XMC4000 Family
The bus error generation applies to memories that can be accessed directly from the bus
system level. Apart from that, all memories, including those that are not accessible
directly and are internal to peripherals are capable of generating system traps resulting
in NMI. Parity trap requests get enabled with PETE register implementing individual
control for each memory. Parity error signalling with trap generation is not recommended
to be used for memories capable of bus error generation and therefore should be
disabled.
Parity error trap generation mechanism can be also used to generate system reset if
enabled with PERSTEN register in conjunction with the PETE register configuration. For
more details of the parity error generation scheme please refer to Figure 11-3.

XMC4500
XMC4000 Family
RESET TRAP
REQUEST REQUEST
&
RESET
ENABLE
>1
& & & & & & & & & & & &
PETE.PEENDS2 PFLAG.PEFDS2
PETE.PEENDS1 PFLAG.PEFDS1
PETE.PEENPS PFLAG.PEFPS
PETE.PEENU2 PFLAG.PEFU2
PETE.PEENPPRF PFLAG.PEFPPRF
PETE.PEENUSB PFLAG.PEFUSB
PETE.PEENETH0TX PFLAG.PEFETH0TX
PETE.PEENETH0RX PFLAG.PEFETH0RX
PETE.PEENSD0 PFLAG.PEFSD0
PETE.PEENSD1 PFLAG.PEFSD1
Parity
Parity
Parity
Parity
Parity
Parity
Parity
Parity
Parity
Parity
Parity
Parity
error
error
error
error
error
error
error
error
error
error
error
error
SD MMC 0 RAM
SD MMC 1 RAM
ETH 0RX R AM
ETH 0TX RAM
PMUPF R AM
U SB RAM
DSRAM1
DSRAM2
U0 RAM
U1 RAM
U2 RAM
PSR AM
PEEN.PEENETH 0RX
PEEN .PEEN ETH 0TX
PEEN.PEENPPR F
PEEN.PEENUSB
PEEN.PEEN SD 1
PEEN.PEEN SD 0
PEEN.PEEN DS1
PEEN.PEEN DS2
PEEN.PEENU 0
PEEN.PEENU 1
PEEN.PEENU 2
PEEN.PEEN PS
Figure 11-3 XMC4500 Parity Error Control Logic

The logic is controlled by registers PMTSR and PMTPR. Via bit field PMTPR.PWR a
parity value can be written to any address of every memory for software driven testing
purpose. The parity control software test update has to be enabled with bit PMTSR for
each memory individually. Otherwise a write to the parity control has no effect. With each
read access to a memory the parity from the memory parity control is stored in register
PMTPR and accessible with software.

XMC4500
XMC4000 Family
Note: Test software should be located in external memory.
11.2.4 Trap Generation

Several abnormal events listed in Table 11-2 can result in assertion of NMI. Please refer
to TRAPDIS register description.
TRAPSET.x TRAPCLR.x TRAPDIS.x TRAPSTAT.x
clear
to NMI request
combined output
Trap request
Event x set raw request & 1
1 TRAPRAW.x
Figure 11-4 Trap Subsystem

The trap flag in register TRAPSTAT can be cleared by software by writing to the
corresponding bit in register TRAPCLR. All trap requests are combined to one common
line and connected to NMI node of NVIC.
The trap requests have a sticky flag in register TRAPRAW.
Note: When servicing an SCU trap request, make sure that all related request flags are
cleared after the identified request has been handled.
11.2.4.1 Trap Sources

The SCU supports trap sources listed in Table 11-2 and reflected in the TRAPSTAT,
TRAPRAW, TRAPDIS, TRAPCLR and TRAPSET registers.
Table 11-2 Trap Requests
Source of Trap Short Trap Name
System PLL Trap SOSCWDGT
USB VCO Lock Trap SVCOLCKT
System VCO Lock Trap UVCOLCKT
Parity Error Trap PET
Brownout Trap BRWNT

XMC4500
XMC4000 Family
Table 11-2 Trap Requests (contd)

Source of Trap Short Trap Name
OSCULP Watchdog Trap ULPWDGT
Peripheral Bus 0 Write Error Trap BWERR0T
Peripheral Bus 1 Write Error Trap BWERR1T
11.2.5 Die Temperature Measurement
The Die Temperature Sensor (DTS) generates a measurement result that indicates
directly the current temperature. The result of the measurement is displayed via bit field
DTSSTAT.RESULT. In order to start one measurement bit DTSCON.START needs to
be set.
The DTS has to be enabled before it can be used via bit DTSCON.PWD. When the DTS
is powered temperature measurement can be started.
In order to adjust production variations of temperature measurement accuracy bit field
DTSCON.BGTRIM is provided. DTSCON.BGTRIM can be programmed by the user
software.
Measurement data is available certain time after measurement started. Register
DTSSTAT.RDY bit indicated that the DTS is ready to start a measurement. If a started
measurement is finished or still in progress is indicated via the status bit
DTSSTAT.BUSY.
The formula to calculate the die temperature is defined in the Target Data Sheet.
Note: The first measurement after the DTS was powered delivers a result without
calibration adjustment and should be ignored.
11.2.6 Retention Memory

Retention memory for context store/restore is available hibernate mode support. The
retention memory area is located in Hibernate domain. Any content is retained in
hibernate mode, when the core might be without power supply. The user software can
store some context critical data in the memory before entering hibernate mode and
access the data after booting up if a wake-up from hibernate bode is signalized in
RSTSTAT register.
Access to the 64 Bytes of retention memory is provided via RMDATA register, controlled
with RMACR register. The purpose of RMACR register is addressing of the memory
cells and issuing read/write command. The RMDATA is read or written by software
according to the access direction after data transfer has been completed as indicated
with RMX bit field in MIRRSTS.

XMC4500
XMC4000 Family
11.2.7 Out of Range Comparator Control
GCU
GxORCy
PORTS GxORCOUTy
+ORC To ERU
VAREF -
GxORCEN.ENORCy
Figure 11-5 Out od Range Comparator Control

The out of range comparator serves the purpose of overvoltage monitoring for analog
input pins of the chip. A number of analog channels are associated with dedicated pads
connected to inputs of analog modules. They get supervised by dedicated circuits
constituted of analog comparator controlled by digital signals as depicted in Figure 11-5.
Detection of input voltage exceeding VAREF triggers a service request to the ERU. Digital
control signals are generated in GCU submodule of SCU. Dedicated registers
G0ORCEN and G1ORCEN provide control means for enabling and disabling monitoring
of analog channels.
11.3 Power Management

Power management control is performed in the Power Control Unit (PCU).
11.3.1 Functional Description

The XMC4500 is running from a single external power supply (VDDP). The main supply
voltage is supervised by a supply watchdog.
The I/Os and the main part of the flash block are running directly from the external supply
voltage. The core voltage (VDDC) is generated by an on-chip Embedded Voltage

XMC4500
XMC4000 Family
Regulator (EVR). The safe voltage range of the core voltage is supervised by a power
validation circuit, which is part of the EVR.
Logic in the hibernate domain, mainly the real-time clock RTC, hibernate control and
retention memory, is supplied by an auxiliary power supply using an additional power
pad called. The auxiliary VBAT voltage, supplied from e.g. a coin battery, enables the RTC
to operate while the main supply is switched off.
11.3.2 System States

The system has the following general system states:
Active
Sleep
Deep-Sleep
Hibernate
Figure 11-6 shows the state diagram and the transitions between these power modes.
The additional state power-up is only a transient state which is passed on cold or warm
start-up from Off state.
Sleep
Sleep Request Wake-up Event
Deep Sleep Request
Off Power-up Active Deep Sleep

Supply
Wake-up Event
Hibernate Request
Wake-up Event
Hibernate
Figure 11-6 System States Diagram
Active State
The Active state is the normal operation state. The system is fully powered. The CPU is
usually running from a high-speed clock. Depending on the application the system clock

XMC4500
XMC4000 Family
might be slowed down. The PLL output clock or another clock can be selected as clock
source. Unused peripherals might be stopped. Stopping a peripheral means that the
peripheral i put into reset and the clock to this peripherals is disabled.
After a cold start the hibernate domain stays disabled until activated by user code.
Sleep State
The Sleep state of the system corresponds to the Sleep state of the CPU. The state is
entered via WFI or WFE instruction of the CPU. In this state the clock to the CPU is
stopped. The source of the system clock may be altered. Peripherals clocks are gated
according to the SLEEPCR register.
Peripherals can continue to operate unaffected and eventually generate an event to
wake-up the CPU. Any interrupt to the NVIC will bring the CPU back to operation. The
clock tree upon exit from SLEEP state is restored to what it was before entry into SLEEP
state.
Deep-Sleep State
The Deep-Sleep State is entered on the same mechanism as the Sleep state with the
addition that user code has enabled the Deep Sleep state in system control register. In
Deep-Sleep state the OSCHP and the PLL may be switched off. The wake-up logic in
the NVIC is still clocked by a free-running clock. Peripherals are only clocked when
configured to stay enabled in the DSLEEPCR register. Configuration of peripherals and
any SRAM content is preserved.
The Flash can be put into low-power mode to achieve a further power reduction. On
wake-up Flash will be restarted again before instructions or data access is possible.
Any interrupt will bring the system back to operation via the NVIC.The clock setup before
entering Deep Sleep state is restored upon wake-up.
Hibernate State
In Hibernate mode the power supply to the core is switched off. Additionally the power
to the analog domain and the main supply VDDP can be switched off. Only the Hibernate
power domain will stay powered. The power supply of the Hibernate domain is switched
automatically to the auxiliary supply when the main supply is no longer present.
The Hibernate State is entered using control register HDCR of HCU in the Hibernate
domain that will drive the external Voltage Regulator with HIBOUT signal to switch off
power to the chip (see System Level Power Control Example).
Depending on configuration the following wake-up sources will wake-up the system to
normal operation:
Edge detection on external WKUP signal

XMC4500
XMC4000 Family
RTC Alarm Event

RTC Periodic Event
OSCULP Watchdog Event
The system can only wake-up from Hibernate if VDDP is present. An external power
supply can be switched on by the HIBOUT signal of the Hibernate Control Unit.
All blocks outside of the Hibernate domain will see a complete power-up sequence upon
wake-up.
11.3.3 Hibernate Domain Operating Modes

The standard use case of the Hibernate domain is the time keeping function with VBAT
available, keeping the Real Time Counter active while the System Supply is powered off.
voltage
System Supply
3.3 V VDDP
VBAT
1.3 V VDDC
0V
time
Figure 11-7 Hibernate state in time keeping mode

A special case of the Hibernate domain assumes that the VBAT supply voltage is
available only after the core domain power-up. This may occur if, for example, the battery
gets plugged in or replaced after the core domain startup, or, if only a capacitor is
available to hold VBAT voltage for some limited time in case of absence of the main supply
voltage in order to keep the Real Time Counter unaffected. The Hibernate domain
requires to be switched on once after core domain power up with the dedicated register
PWRSET.HIB. In this application case even switching off the main supply of the board
does not affect availability of the VHIB voltage required to keep RTC running.

XMC4500
XMC4000 Family
voltage
System Supply
3.3 V VDDP
VBAT
1.3 V VDDC
time
Figure 11-8 Hibernate controlled with external voltage regulator

The system power-down mode is controlled via HIB pin and external power supply
device. The main supply voltage of the board stays active allowing selective disabling of
the XMC4500 in order to save power while other devices of on the board remain active.
At the time HIB pin indicates Hibernate mode the dedicated pass device connected to
the chip will stop generating VDDP and voltage and in effect complete chip except the
Hibernate domain will be powered off. On a wake-up event the Hibernate domain will
dessert HIB control signal and enable generation of VDDP voltage, hence complete
power-up sequence of the core domain.

XMC4500
XMC4000 Family
voltage
System Supply
Battery insertion
3.3 V VDDP
VBAT
1.3 V VDDC
0V
time
Figure 11-9 Initial power-up sequence

One of the valid power-up scenarios assumes that battery will be installed, possibly
soldered, before core supply is available (see Figure 11-9). That would be a common
situation after PCB assembly, before the complete device is installed in the target
system. The battery voltage VBAT gets connected before the main supply of the board is
available and only the Hibernate domain is supplied. No current (only leakage is allowed)
is drawn from the battery before explicit switching on Hibernate domain with software
after Core domain power up using dedicated register PWRSET.HIBEN. This feature
allows to keep the device in a storage for a long time before shipment to the end user,
without significant loss of charge in the battery.
11.3.4 Embedded Voltage Regulator (EVR)

The EVR generates the core voltage VDDC out of the external supplied voltage VDDP. The
EVR provides a supply watchdog (SWD) for the input voltage VDDP. The generated core
voltage VDDC is monitored by a power validation circuit (PV).
11.3.5 Supply Watchdog (SWD)

Figure 11-10 shows the operation of the supply monitor. The supply watchdog
compares the supply voltage against the reset threshold VPOR. The Data Sheet defines
the nominal value and applied hysteresis.

XMC4500
XMC4000 Family
voltage
VPOR
time
PORST
Figure 11-10 Supply Voltage Monitoring
While the supply voltage is below VPOR the device is held in reset. As soon as the voltage
falls below VPOR a power on reset is triggered.
11.3.6 Power Validation (PV)

A power validation (PV) circuit monitors the internal core supply voltage of the core
domain. It monitors that the core voltage is above the voltage threshold VPV which
guarantees save operation. Whenever the voltage falls below the threshold level a
power-on reset is generated.
11.3.7 Supply Voltage Brown-out Detection

Brown-out detection is an additional voltage monitoring feature that enables the user
software to perform some corrective action that bring the chip into safe operation in case
a critical supply voltage drop and avoids system reset generated by the Supply Voltage
Monitoring.
A drop of supply voltage to a critical threshold level programmed by the user can be
signalized to the CPU with an NMI. An emergency corrective action may involve e.g.
reduction of current consumption by switching of some modules or some interaction with
external devices that should result in recovery of the supply voltage level.
Automatic monitoring of the voltage against programmed voltage allows efficient
operation without a need for software interaction if the supply voltage remains at a safe

XMC4500
XMC4000 Family
level. The supply voltage can be monitored also directly by software in register
EVRVADCSTAT. The threshold value and the inspection interval is configured at
PWRMON.
11.3.8 Hibernate Domain Power Management

The switch for the supply voltage of the Hibernate domain is depending of the voltage
relation between VDDP and VBAT. It is strongly recommended to avoid supplying hibernate
domain from a battery when valid VDDP supply voltage is available in order to extend the
battery life time. For XMC4500 product external supply voltage switching solution is
based on Shottky diodes is proposed (see Figure 11-11).
11.3.9 Flash Power Control

The Flash module can be configured to operate in low power mode while in Deep Sleep
state. Control of the Flash power mode it is performed using the DSLEEPCR register
prior to entering the Deep Sleep mode. The user needs to trade the reduced leakage
current against longer startup time.
11.4 Hibernate Control

Hibernate control is performed with Hibernate Control Unit (HCU).
In the operation mode with lowest power consumption only the hibernate domain
remains powered up. In this state the hibernate domain enable switching off externally
the main power supply (see Figure 11-11).
The HCU can request a complete power down of the core logic by programming HIB bit
field of HDCR register.
The pin that controls external voltage regulator has a defined voltage level under all
conditions. The pin remains at a default level if the hibernate domain is not enabled or
not correctly powered.
Externally Controlled Hibernate Mode

External Voltage Regulator is controlled from Hibernate domain and VDDP gets switched
off when hibernate mode is entered. No reset of hibernate control occurs in hardware
upon power-up but the chip will boot up as normal since in this mode no internal state of
the chip is affected except for the hibernate control pin from hibernate domain to the
External Voltage Regulator. Re-initialization of is possible with software upon boot-up.

XMC4500
XMC4000 Family
Hibernation Support
The entry of the hibernate state is configured via the register HDCR by setting of the HIB
bit. The HIBOUT bit in conjunction with selected HIBIOnPOL bit of HDCR register drives
HIB_IO_n pad.
The hibernation control signal HIBOUT is connected to an open-drain pad to enable
control of an external power regulator for VDDP.
Wake-up from Hibernate Mode

The hibernation control supports multiple wake-up sources. Occurrence of any of the
Wake-up from hibernate triggers resets of HDCR.HIB bit which results resetting of the
HIBOUT signal that controls the External Voltage Regulator.
The additional wake-up sources shown as part of the Wake-up Unit will not be
implemented in the XMC4500 and are shown here for future enhancements.
System Level Integration

The Power Control scheme require additional external devices in order to fully support
defined functionality as shown in Figure 11-11.
OR
USB
supply
EVR core domain CPU
External Voltage
Buck 5V Regulator 3.3V
Converter irq alarm
IN OUT
12-48V
SPI
EN#
SHTDN
Hibernate hibernate VBAT 2V...VDDP
Control
LOW = ON domain
32kHz
OR RTC
Clock
WAKE
Retention
Memory
Battery or optional
capacitor Zener diode
Figure 11-11 System Level Power Control Example

The external switch based on Shottky diode prevents discharging battery when voltage
is supplied to the chip from the external power supply.
Hibernate Domain Pin Functions

Hibernate domain control register HDCR implements fields for alternate pin function
selection.

XMC4500
XMC4000 Family
HIB_SR1 WWDT_SERVICE_OUT HIB_SR0
Core
Domain
Isolation Isolation Isolation
Cell Cell Cell
X1D Hibernate
RTC_XTAL_1 Domain
fULP
HIB_IO_0
MUX
HIB_IO_0
HIBIO0SEL
HIB_SR0
MUX
GPI0SEL
HIBOUT
Hibernate
Control
WKUP
MUX
WKUP
WKUPSEL
HIB_IO_1
HIB_IO_1
MUX
HIBIO1SEL
Figure 11-12 Alternate function selection of HIB_IO_0 and HIB_IO_1 pins of

Hibernate Domain
The HIB_IO_0 pad is configured as open drain low and HIB_IO_1 as input after reset.
This configuration enables use of low-enabled external voltage regulator as depicted in
the Figure 11-11. In case of high-active external voltage regulator and battery presence

XMC4500
XMC4000 Family
in the pins may be swapped to ensure safe startup of the system (additional external pull-
up required on HIB_IO_1)
11.5 Reset Control

Reset Control Unit (RCU) performs control of all reset related functionality including:
Reset assertion on various reset request sources
Inspection of reset sources after reset
Selective reset of peripherals
11.5.1 Supported Reset types

The XMC4500 has the following reset types:
Power-on Reset, PORESETn
System Reset, SYSRESETn
Standby Reset, STDBYRESETn
Debug Reset, DBGRESETn
Power-on Reset, PORESETn

A complete reset of the core domain of the device is executed upon power-up. Whenever
the supply VDDP is ramped-up and crossing the PORST voltage threshold the power-on
reset is released. Additional a power-on reset is triggered by asserting the external
PORST pin.
A Power-on reset is asserted again whenever the VDDP voltage or the VDDC voltage falls
below defined reset thresholds.
System Reset, SYSRESETn

System reset is triggered by sources:
Power-on reset
Software reset via Cortex-M4 Application Interrupt and Reset Control Register
(AIRCR)
Lockup signal from Cortex-M4 when enabled at RCU
Watchdog reset
Memory Parity Error
A system reset resets almost all logic in the core domain. The only exceptions in the core
domain are RCU Registers and Debug Logic.

XMC4500
XMC4000 Family
Standby Reset, STDBYRESETn

The Hibernate domain including the RTC is only reset by a standby reset. A standby
reset is triggered by a power-on reset specific to the Hibernate domain. Additionally a
standby reset can be activated by software:
Power-on reset specific to the Hibernate domain
Software reset via RSTSET register
Debug Reset, DBGRESETn

Debug reset is triggered by the following sources:
Debug Reset request from DAP while in mission mode and with debug probe present
System Reset while in normal mode and debug probe not present
The Debug Reset is triggered by System Reset while in normal operation mode while
debug probe is not present. When debug probe is present System Reset does not affect
Debug Reset generation.
11.5.2 Peripheral Reset Control

Software can activate the reset of all peripherals individually via the registers PRSET0,
PRSET1, PRSET2 and PRSET3. The default state is that all peripherals are in reset
after power-up. A return to the default state of a peripheral can be performed by forcing
it to reset state by a separate reset.
The user needs to properly configure the port values before resetting a module to assure
that the default output values of a peripheral do not harm external circuitry. Similarly the
user has to take care of top-level interconnects, which will not be affected by a module
specific reset.
11.5.3 Reset Status

The EVR provides the cause of a power reset to the RCU. The reset cause can be
inspected after resuming operation by reading register RSTSTAT.
All register of the RCU undergo reset only by a power-on reset PORESETn.
Table 11-3 shows an overview of the reset signals their source and effects on the
various parts of the system.

XMC4500
XMC4000 Family
Table 11-3 Reset Overview

Name Source Core PAD Hibernate Debug &
Domain Domain Domain Trace
System
PORESETn EVR yes yes no yes

SYSRESETn PORESETn yes no no no
Software
WDT
STDBYRESETn Power-on no no yes no
Software
DBGRESETn DAP no no no yes
Software
11.6 Clock Control

Clock generation and control is performed in the Clock Control Unit (CCU).

The clock control unit has as major sub blocks the main Clock Generation Unit (CGU),
the Standby Clock Generation Unit (SCGU) in the Hibernate power domain and the clock
selection unit (CSU). The clock generation unit is connected to the external crystal pins
XTAL1 and XTAL2. The clock generation unit provides in parallel three clocks to the
clock selection unit, i.e. the USB PLL clock fUSB, the PLL output clock fPLL and a fast
internal generated clock fOFI generated by the backup clock source. The clock selection
unit receives as additional clocks sources a slow standby clock from the hibernate
domain. The fSTDBY clock is one of the two clock sources of the Standby Clock
Generation Unit (SGCU) in the hibernate domain. The standby clock is sourced by either
the 32 kHz external crystal oscillator or by an internal 32 kHz clock source.
The clock selection unit provides various clocks to the modules of the system. The CSU
allows to select the source of the clocks and to apply scaling of the frequency.
Major clock sources can be selected for driving the external clock pin EXTCLK to be
observed externally.

XMC4500
XMC4000 Family
Core Domain
Clock Generation Unit

fCPU
fPLLUSB fDMA
fOSCHP PLLUSB
XTAL1/CLKIN fOHP fPERIPH
OSCHP
XTAL2 fCCU
fPLL
PLL
fUSB
Clock
Generation fSDMMC
fSTDBY Backup fOFI Control
Clock fETH
Source
fEBU
fWDT
fEXT
EXTCLK
Standby Clock Generation Unit

Hibernate Domain
fOSCULP
RTC_XTAL1 fULP
OSCULP
fSTDBY
RTC_XTAL2
fRTC
Internal fOSI
Slow Clock
Source
Figure 11-13 Clock Control Unit
11.6.2 Clock Sources

The system has four clock sources distributed over the core power domain and the
hibernate power domain. The clock sources in the core power domain are:
OSCHP, a high speed crystal oscillator to be used with an external clock signal or a
crystal
The backup clock source, fOFI
During start-up, first the backup clock fOFI is used. The fOFI clock may be used during
normal operation for low power operation.
The high precision oscillator OSCHP can be used with an external crystal or accepts an
external clock source via pin XTAL1/CLKIN. Both the clock signals from OSCHP and the
fOFI can be selected as input clock source for the main PLL. The main PLL provides a
maximum frequency of 520 MHz.

XMC4500
XMC4000 Family
The clock sources in the hibernate power domain are:

OSCULP, an ultra low power oscillator to be used with external crystal - 32kHz clock
fULP
Internal Slow Clock source 32 kHz clock fOSI
The clocks drive the logic in the hibernate domain. In addition one of the two can be used
as standby clock for low power operation in the core power domain.
To generate the required high precision fPLLUSB clock for operation of the USB and the
MMC/SD modules additional PLL can be optionally used if the desired clock frequency
cannot be derived from the system PLL output fPLL. The dedicated PLL referred to as
PLLUSB, shown the block diagram in Figure 11-14.
Clock Generation Unit
fPLLUSB
fOSCHP PLLUSB
XTAL1/CLKIN fOHP
OSCHP
XTAL2
fOSC fPLL
PLL
fSTDBY Backup fOFI

Clock
Source
Figure 11-14 Clock Generation Block Diagram
11.6.3 Clock System Overview

The clock selection unit CSU provides the following clocks to the system:
Table 11-4 Clock Signals

Clock name From/to Description
module or pin
System Clock Signals
fSYS SCU.CCU System master clock

XMC4500
XMC4000 Family
Table 11-4 Clock Signals (contd)

module or pin
fCPU CPU CPU and NVIC clock
fDMA DMA0, DMA1 DMA clock
fPERIPH PBA0 Peripheral clock for modules connected to
PBA1 peripheral bridges PBA0 and PBA1
fCCU CCU4 Clock for CCU4, CCU8 and POSIF modules
CCU8
POSIF
fUSB USB UTMI clock of USB
fETH ETH0 ETH clock
fEBU EBU EBU clock
fWDT WDT Clock for independent watchdog timer
Internal Clock Signals
fPLL System PLL System PLL output clock
fPLLUSB USB PLL USB PLL output clock
fOHP OSCHP External crystal oscillator output clock
fOFI Internal System Backup Block
Backup Clock
Source
fULP OSCULP External crystal slow oscillator output clock
fOSI Slow Internal 32 kHz backup clock for Hibernate domain
Backup Clock
Source
fOSC PLL input PLL input clock
fSTDBY Hibernate 32kHz clock, optional WDT independent clock
Domain
fFLASH FLASH Internal Flash clock
External Clock Signals
fOSCHP XTAL1/CLKIN External crystal input, optionally also direct input
clock to system PLL

XMC4500
XMC4000 Family
Table 11-4 Clock Signals (contd)

module or pin
fOSCULP RTC_XTAL1 External crystal input, optionally also direct input
clock to Hibernate domain and RTC module
fEXT Clock output to Chip output clock
pin EXTCLK
The clock sources of the clock selection unit are the four clocks from the clock generation
unit, i.e. the USB clock fUSB, the PLL output clocks fPLL and a fast internal generated clock
fOFI.The clock selection unit receives as additional clocks source a slow standby clock
from the hibernate domain.
11.6.3.1 Clock System Architecture

The system clock fSYS drives the CPU clock and all peripheral modules. It can be
selected from the following clock sources:
fPLL, main PLL output clock divided by a 8-bit divider
fOFI, fast internal clock, bypassing PLL
fOSCHP, external clock, bypassing PLL
fOHP, external crystal oscillator clock, bypassing PLL
Please note that in dependence of the PLL mode setting the PLL output clock fPLL is
either a scaled version of the VCO clock in normal mode or a scaled version of one of
the input clocks.
In Deep Sleep mode the system clocks can be switched to a clock which does not require
PLL and thereby allowing the power down of the system PLL. This is either the fast
internal clock or the slow standby clock. The DSLEEPCR register controls the clock
settings for Deep Sleep mode.

XMC4500
XMC4000 Family
fPLL
fSYS fETH
SYSDIV ETHDIV
fOFI /n /2
fCCU
CCUDIV
/1/2
fCPU, fDMA
CPUDIV
/1/2
fPERIPH
PBDIV
/1/2
fUSBPLL
fUSB, fSDMMC
USBDIV
fPLL /n
fPLL fEBU
EBUDIV
/n
fSTDBY
fWDT
fOFI WDTDIV
/n
fPLL
Figure 11-15 Clock Generation Control

Some limitations apply on clock ratio combinations between fCCU, fCPU and fPERIPH. Only
divider setting listed in the table Table 11-5 are allowed for the fCCU, fCPU and fPERIPH
clocks. All other clock dividers settings must be prohibited by software applications in
order to avoid invalid clock ratios leading to system malfunctions. The Table 11-5 table
shows also example clock rate values assuming fSYS rate of 120 MHz.
Table 11-5 Valid values of clock divide registers for fCCU, fCPU and fPERIPH clocks
CCUCLKCR.CCUDIV CPUCLKCR.CPUDIV PBCLKCR.PBDIV
0 (120 MHz) 0 (120 MHz) 0 (120 MHz)
0 (120 MHz) 0 (120 MHz) 1 (60 MHz)

XMC4500
XMC4000 Family
Table 11-5 Valid values of clock divide registers for fCCU, fCPU and fPERIPH clocks
CCUCLKCR.CCUDIV CPUCLKCR.CPUDIV PBCLKCR.PBDIV
0 (120 MHz) 1 (60 MHz) 0 (60 MHz)
1 (60 MHz) 0 (120 MHz) 1 (60 MHz)
1 (60 MHz) 1 (60 MHz) 0 (60 MHz)
USB and MMC/SD Clock Selection

The clock for the USB module and the clock for the MMC/SD module are both derived
from the clock fUSB or from the clock fPLL of the main PLL. The later is only feasible, when
the main PLL is providing a frequency which allows to generate the 48MHz with a 3-bit
divider.
The USB clock is automatically gated and the USB PLL put in power-down by the USB
suspend signal.
The clock divider and the MUX must only be configured while the USB and MMC/SD are
not enabled.
Ethernet Clock Selection

The Ethernet module receives SRAM clock fSYS which has to be twice the frequency of
the ETH MAC internal clock fETH. The SRAM clock rate must always be above 100 MHz
which guarantee that the clock of ETH MAC is of rate above its acceptable minimum of
50 MHz.
Both clocks are disabled with software in Wake-On-Lan mode. The clocks have to be
enabled via software when the related interrupt the end of Wake-On-Lan mode.
The clock divider and the clock MUX must only be configured while ETH module is not
enabled.
CPU Clock Selection

The CPU clock fCPU may be equal to or a half of the system clock fSYS.
Peripheral Bus Clock Selection

The Peripheral Bus clock is derived from the fCPU clock and may be equal t or a half of
the fCPU. There are some limitations imposed on peripheral bus configuration in term of
clock ratio with respect to the fCCU clock. The Peripheral Bus clock rate must never be
less than half and more than the fCCU clock.

XMC4500
XMC4000 Family
CAPCOM and POSIF Clock Selection
The capture compare blocks CCU4, CCU8 and POSIF use as timer clock the clock fCCU
derived from system fSYS via CCUDIV clock divider. The clock divider allows to adjust
clock frequency of the timers with respect to the rest of the system. Relation between
fCCU clock and other clocks in the system is constrained as described in the Table 11-5.
The fCCU clock frequency must only be configured while all CAPCOM and POSIF
modules are not enabled.
Watchdog Clock Selection

The watchdog module uses as independent clock either the internal fast clock fOFI or the
slow clock fSTDBY. The system clock fPLL is available as additional clock source.
Both the clock divider and the clock MUX must only be configured while the WDT is not
enabled.
External Clock Output

An external clock is provided via clock pin EXTCLK. All clock sources can be selected
as clock signal for the external clock output. Optionally a divider can be used before
bringing the system clock to the outside to stay within the limit of the supported
frequencies for the pads.

XMC4500
XMC4000 Family
fSYS
fFLASH
EXTCLK
fEXT
fUSB
fPLL ECKDIV
/n
Figure 11-16 External Clock Selection
11.6.4 High Precision Oscillator Circuit (OSCHP)

The high precision oscillator circuit can drive an external crystal or accepts an external
clock source. It consists of an inverting amplifier with XTAL1 as input, and XTAL2 as
output.
Figure 11-18 and Figure 11-17 show the recommended external circuitries for both
operating modes, External Crystal Mode and External Input Clock Mode.
External Input Clock Mode
In this usage an external clock signal is supplied directly not using an external crystal
and bypassing the amplifier of the oscillator. The input frequency must be in the range
from 4 to 40 MHz.When using an external clock signal it must be connected to XTAL1.
XTAL2 is left open i.e. unconnected.

XMC4500
XMC4000 Family
XTAL1 fOSCHP
External
Clock Signal
OSC_HP fOHP
XTAL2
leave unconnected
VSS
Figure 11-17 External Clock Input Mode for the High-Precision Oscillator
External Crystal Mode
For the external crystal mode an external oscillator load circuitry is required. The circuitry
must be connected to both pins, XTAL1 and XTAL2. It consists normally of the two load
capacitances C1 and C2. For some crystals a series damping resistor might be
necessary. The exact values and related operating range depend on the crystal and
have to be determined and optimized together with the crystal vendor using the negative
resistance method.
Fundamental Mode
Crystal
XTAL1 fOSCHP
OSC_HP fOHP
XTAL2
C1 C2
VSS
Figure 11-18 External Crystal Mode Circuitry for the High-Precision Oscillator
11.6.5 Backup Clock Source

The backup clock fOFI generated internally is the default clock after start-up. It is used for
bypassing the PLL for startup of the system without external clock. Furthermore it can
be used as independent clock source for the watchdog module or even as system clock

XMC4500
XMC4000 Family
source during normal operation. While in prescaler mode this clock is automatically used
as emergency clock if the external clock failure is detected.
Clock adjustment is required to reach desired level of fOFI precision. The backup clock
source provides two adjustment procedures:
loading of adjustment value during start-up
continuos adjustment using the high-precision fSTDBY clock as reference
11.6.6 Main PLL

The main PLL converts a low-frequency external clock signal to a high-speed internal
clock. The PLL also has fail-safe logic that detects degenerative external clock behavior
such as abnormal frequency deviations or a total loss of the external clock. The PLL
triggers autonomously emergency action if it loses its lock on the external clock and
switches to the Fast Internal Backup Clock.
This module is a phase locked loop for integer frequency synthesis. It allows the use of
input and output frequencies of a wide range by varying the different divider factors.
11.6.6.1 Features
VCO lock detection

4-bit input divider P: (divide by PDIV+1)
7-bit feedback divider N: (multiply by NDIV+1)
7-bit output dividers K1 or K2: (divide by KxDIV+1)
Oscillator Watchdog
Detecting too low input frequencies
Detecting too high input frequencies
Spike detection for the OSC input frequency
Different operating modes
Bypass Mode
Prescaler Mode
Normal Mode
VCO Power Down
PLL Power Down
Glitch less switching between K-Dividers
Switching between Normal Mode and Prescaler Mode
11.6.6.2 System PLL Functional Description

The PLL consists of a Voltage Controlled Oscillator (VCO) with a feedback path. A
divider in the feedback path (N-Divider) divides the VCO frequency down. The resulting
frequency is then compared with the externally provided and divided frequency (P-
Divider). The phase detection logic determines the difference between the two clocks

XMC4500
XMC4000 Family
and accordingly controls the frequency of the VCO (fVCO). A PLL lock detection unit
monitors and signals this condition. The phase detection logic continues to monitor the
two clocks and adjusts the VCO clock if required.
The following figure shows the PLL block structure.
Clock Source Control

The input clock for the PLL fOSC can be one of the following two clock sources:
The internal generated fast clock fOFI
The clock fOHP sourced by the crystal oscillator OSCHP
The PLL clock fPLL is generated from the input clock in one of two software selectable
operation modes:
Normal Mode, using VCO output clock
Prescaler Mode, using input clock directly
The PLL output clock fPLL is derived from either

VCO clock divided by the K2-Divider, normal mode
external oscillator clock divided by the K1-Divider, prescaler mode
backup clock divided by the K1-Divider, prescaler mode
The PLL clock fPLL is generated in emergency from one of two sources:
Free running VCO if Emergency entered from Normal Mode of PLL
Backup Clock if emergency entered from Prescaler Mode of PLL
Configuration and Operation of the Normal Mode

In Normal Mode, the PLL is running at the frequency fOSC and fPLL is divided down by a
factor P, multiplied by a factor N and then divided down by a factor K2.
The output frequency is given by:

(11.1)
N
f PLL = -------------- f OSC
P K2
The maximum frequency in normal mode is 520 MHz corresponding to the maximum
supported VCO frequency.

XMC4500
XMC4000 Family
PLLSTAT.FINDIS
1
0 M
fP f REF U fPLL
P-
f OSC f VCO K2-
0 X
Divider VCO
Divider f K2
Lock
N-
Detect.
Osc. fDIV Divider PLLCON0.
WDG VCOBYP
PLL Block
Figure 11-19 PLL Normal Mode

The Normal Mode is selected by the following settings
Register Setting
PLLCON0.VCOBYP = 0
PLLCON0.FINDIS = 0
The Normal Mode is entered when the following requirements are all together valid:
Register Values
PLLCON0.FINDIS = 0
PLLSTAT.VCOBYST = 0
PLLSTAT.VCOLOCK = 1
PLLSTAT.PLLLV = 1
PLLSTAT.PLLLH = 1
Operation on the Normal Mode does require an input clock frequency of fOSC. Therefore
it is recommended to check and monitor if an input frequency fOSC is available at all by
checking PLLSTAT.PLLLV. For a better monitoring also the upper frequency can be
monitored via PLLSTAT.PLLHV.
For the Normal Mode there is the following requirement regarding the frequency of fOSC.
A modification of the two dividers P and N has a direct influence to the VCO frequency
and lead to a loss of the VCO Lock status. A modification of the K2-divider has no impact
on the VCO Lock status.
When the frequency of the Normal Mode should be modified or entered the following
sequence needs to be followed:
Configure and enter Prescaler Mode
Disable NMI trap generation for the VCO Lock

XMC4500
XMC4000 Family
Configure Normal Mode

Wait for a positive VCO Lock status (PLLSTAT.VCOLOCK = 1).
Switch to Normal Mode by clearing PLLCON.VCOBYP
The Normal Mode is entered when the status bit PLLSTAT.VCOBYST is cleared.
When the Normal Mode is entered, the NMI status flag for the VCO Lock trap should be
cleared and then enabled again. The intended PLL output target frequency can now be
configured by changing only the K2-Divider. This can result in multiple changes of the
K2-Divider to avoid to big frequency changes. Between the update of two K2-Divider
values 6 cycles of fPLL should be waited. For ramping up PLL output frequency in Normal
Mode the following steps are required:
The first target frequency of the Normal Mode should be selected in a way that it
matches or is only slightly higher as the one used in the Prescaler Mode. This avoids
big changes in the system operation frequency and therefore power consumption
when switching later from Prescaler Mode to Normal Mode.
Selecting P and N in a way that fVCO is in the upper area of its allowed values leads
to a slightly increased power consumption but to a slightly reduced jitter
Selecting P and N in a way that fVCO is in the lower area of its allowed values leads
to a slightly reduced power consumption but to a slightly increased jitter
It is recommended to reset the fVCO Lock detection (PLLCON0.RESLD = 1) after the
new values of the dividers are configured to get a defined VCO lock check time.
Depending on the selected divider value of the K2-Divider the duty cycle of the clock is
selected. This can have an impact for the operation with an external communication
interface. The duty cycles values for the different K2-divider values are defined in the
Data Sheet.
PLL VCO Lock Detection
The PLL has a lock detection that supervises the VCO part of the PLL in order to
differentiate between stable and unstable VCO circuit behavior. The lock detector marks
the VCO circuit and therefore the output fVCO of the VCO as instable if the two inputs fREF
and fDIV differ too much. Changes in one or both input frequencies below a level are not
marked by a loss of lock because the VCO can handle such small changes without any
problem for the system.
PLL VCO Loss-of-Lock Event
The PLL may become unlocked, caused by a break of the crystal or the external clock
line. In such a case, an NMI trap is generated if it were enabled. Additionally, the OSC
clock input fOSC is disconnected from the PLL VCO to avoid unstable operation due to
noise or sporadic clock pulses coming from the oscillator circuit. Without a clock input
fOSC, the PLL gradually slows down to its VCO base frequency and remains there. This
default feature can be disabled by setting bit PLLCON0.OSCDISCDIS. If this bit is set
the OSC clock remains connected to the VCO.

XMC4500
XMC4000 Family
11.6.6.3 Configuration and Operation of the Prescaler Mode

In Prescaler Mode, the PLL is running at the external frequency fOSC and fPLL1 is derived
from fOSC only by the K1-Divider.
The output frequency is given by

(11.2)
f OSC
f PLL = -------------
-
K1
f K1
K1-
f OSC 1
Divider M
U f PLL
0 X
Osc.
WDG
OSCCON.PLLLV PLLCON0.
VCOBYP
OSCCON.PLLHV PLL Block
Figure 11-20 PLL Prescaler Mode Diagram

The Prescaler Mode is selected by the following settings
PLLCON0.VCOBYP = 1
The Prescaler Mode is entered when the following requirements are all together valid:
PLLSTAT.VCOBYST = 1
PLLSAT.PLLLV = 1
Operation on the Prescaler Mode does require an input clock frequency of fOSC.
Therefore it is recommended to check and monitor if an input frequency fOSC is available
at all by checking PLLSAT.PLLLV. For a better monitoring also the upper frequency can
be monitored via PLLSAT.PLLHV.
For the Prescaler Mode there are no requirements regarding the frequency of fOSC.
The system operation frequency is controlled in the Prescaler Mode by the value of the
K1-Divider. When the value of PLLCON1.DIV was changed the next update of this value
should not be done before bit PLLSTAT.K1RDY is set.

XMC4500
XMC4000 Family
Depending on the selected divider value of the K1-Divider the duty cycle of the clock is
selected. This can have an impact for the operation with an external communication
interface. The duty cycles values for the different K1-divider values are defined in the
Data Sheet.
The Prescaler Mode is requested from the Normal Mode by setting bit
PLLCON.VCOBYP. The Prescaler Mode is entered when the status bit
PLLSTAT.VCOBYST is set. Before the Prescaler Mode is requested the K1-Divider
should be configured with a value generating a PLL output frequency fPLL that matches
the one generated by the Normal Mode as much as possible. In this way the frequency
change resulting out of the mode change is reduced to a minimum.
The Prescaler Mode is requested to be left by clearing bit PLLCON.VCOBYP. The
Prescaler Mode is left when the status bit PLLSTAT.VCOBYST is cleared.
11.6.6.4 Bypass Mode

The bypass mode is used only for testing purposes. In Bypass Mode the input clock fOSC
is directly connected to the PLL output fPLL.
The output frequency is given by:
(11.3)
f PLL = f OSC
11.6.6.5 System Oscillator Watchdog (OSC_WDG)

The oscillator watchdog monitors the incoming clock frequency fOSC from OSCHP or fOFI.
A stable and defined input frequency is a mandatory requirement for operation in both
Prescaler Mode and Normal Mode. In addition for the Normal Mode it is required that the
input frequency fOSC is in a certain frequency range to obtain a stable master clock from
the VCO part.
The expected input frequency is selected via the bit field OSCHPCTRL.OSCVAL. The
OSC_WDG checks for spikes, too low frequencies, and for too high frequencies.
The frequency that is monitored is fOSCREF which is derived from fOSC.
(11.4)
f
f
OSC
= -----------------------------------
OSCREF OSCVAL + 1
The divider value OSCHPCTRL.OSCVAL has to be selected in a way that fOSCREF is

2.5 MHz.

XMC4500
XMC4000 Family
Note: fOSCREF has to be within the range of 2 MHz to 3 MHz and should be as close as
possible to 2.5 MHz.
The monitored frequency is too low if it is below 1.25 MHz and too high if it is above
7.5 MHz. This leads to the following two conditions:
Too low: fOSC < 1.25 MHz (OSCHPCTRL.OSCVAL+1)
Too high: fOSC > 7.5 MHz (OSCHPCTRL.OSCVAL+1)
Before configuring the OSC_WDG function all the trap options should be disabled in
order to avoid unintended traps. Thereafter the value of OSCHPCTRL.OSCVAL can be
changed. Then the OSC_WDG should be reset by setting PLLCON0.OSCVAL. This
requests the start of OSC_WDG monitoring with the new configuration. When the
expected positive monitoring results of PLLSAT.PLLLV and / or PLLSAT.PLLHV are set
the input frequency is within the expected range. As setting PLLCON0.OSCVAL clears
all three bits PLLSAT.PLLSP, PLLSAT.PLLLV, and PLLSAT.PLLHV all three trap status
flags will be set. Therefore all three flags should be cleared before the trap generation is
enabled again. The trap disabling-clearing-enabling sequence should also be used if
only bit PLLCON0.OSCVAL is set without any modification of OSCHPCTRL.OSCVAL.
11.6.6.6 VCO Power Down Mode

The PLL offers a VCO Power Down Mode. This mode can be entered to save power
within the PLL. The VCO Power Down Mode is entered by setting bit
PLLCON0.VCOPWD. While the PLL is in VCO Power Down Mode only the Prescaler
Mode is operable. Please note that selecting the VCO Power Down Mode does not
automatically switch to the Prescaler Mode. So before the VCO Power Down Mode is
entered the Prescaler Mode must be active.
11.6.6.7 PLL Power Down Mode

The PLL offers a Power Down Mode. This mode can be entered to save power if the PLL
is not required. The Power Down Mode is entered by setting bit PLLCON0.PLLPWD.
While the PLL is in Power Down Mode no PLL output frequency is generated.
11.6.7 USB PLL

The USB PLL serves the special purpose to provide an accurate 48MHz clock for USB
2.0 full-speed operation. The basic functionality of the USB PLL is similar to the main PLL
(see Figure 11-21).

XMC4500
XMC4000 Family
PLLSTAT.FINDIS
0
fP f REF
fOSCHP P-
f VCO
Divider VCO fPLLUSB
Lock
N-
Detect.
f DIV Divider
USBPLL Block
Figure 11-21 USB PLL Block Diagram

Below table shows the required values of N divider for different crystal values.
Table 11-6 USB support and N Divider Values for crystal frequencies
Crystal frequency [MHz] N Divider Value
4 24
6 16
8 12
12 8
16 6
The USB PLL is put automatically in power-down by the USB suspend signal, when the
clock is not used for SD/MMC operation.
Note: Reconfiguration of the P-Divider before USB-PLL has locked must be avoided.
11.6.8 Ultra Low Power Oscillator

The ultra low power oscillator is providing a real time clock source of 32 kHz when paired
with an external crystal. It operates in the supply voltage range of the Hibernate power
domain. However a secure start-up of the oscillator requires a power-up of the device
with a power supply above 3.0 V present. The crystal pads are always powered by VBAT
or VDDP. It is further used for continuos adjustment of the fast internal backup clock
source fOFI.
When paired with an appropriate crystal the real time clock has a very high precision of
+/- 1 sec. / week.
The precise and stable 32kHz clock propagated to Core domain as fSTDBY can be used
for continuos adjustments the fast internal backup clock source fOFI.

XMC4500
XMC4000 Family
11.6.9 Slow Internal Clock Source

The slow internal clock source provides a clock fOSI of 32 kHz. This clock can be used
as independent clock source for WDT module and as the clock for periodic wake-up
events in power saving modes.
11.6.9.1 OSCULP Oscillator Watchdog (ULPWDG)

The slow oscillator watchdog monitors the incoming clock frequency fULP from OSCULP.
A reliable32kHz clock is required in the Hibernate domain in Hibernate state in order to
perform system wake-up upon occurrence of configured events. In order to ensure that
a clock watchdog is required to continuously monitor the enabled clock sources. In case
of external crystal failure the clock source must switch to the It is further used for
continuos adjustments the fast internal backup clock source fOFI. Occurrence of the
switch must be indicated in the HDSTAT register.
11.6.10 Clock Gating Control

The clock to peripherals can be individually gated and parts of the system stopped by
these means.
Clock gating in Sleep and Deep-Sleep modes

Global power management related to clock generation and selection is supported for the
sleep modes of the system. The user has full control on the clock configuration for these
modes. The registers SLEEPCR and DSLEEPCR control which clocks should remain
active and which are to be gated by entering the corresponding Sleep or Deep Sleep
mode. Furthermore the system clock can be switched to a slow standby clock and the
PLLs put into power-down mode in Deep Sleep mode.
11.7 Debug Behavior

The SCU module does not get affected with the HALTED signal from SCU upon debug
activities performed using external debug probe.

The SCU module implements functions that involve various types of modules controlled
directly or via dedicated interfaces that are instantiated in different power, clock and
reset domains. These modules are functionally considered parts of the SCU and
therefore SCU is also considered a multi domain circuit in this sense.
Power domains:
Power domains get separated with appropriate power separation cells.
Core domain supplied with VDDC voltage

XMC4500
XMC4000 Family
Pad domain supplied with VDDP voltage

Hibernate domain supplied with VBAT (optional external battery, capacitor) voltage
Clock domains:
All cross-domain interfaces implement signal synchronization.
internal SCU clock is fSYS always identical to the CPU clock and selectable within
SCU
HCU, RTC and register mirror interface clock is 32.786 kHz clock generated in
hibernate domain
Reset domains:
All resets get internally synchronized to respective clocks.
System Reset (SYSRESETn) resets most of the logic in SCU and can be triggered
from various sources (please refer to Reset Control chapter for more details)
Power-on Reset (PORESETn) resets directly a few registers and contributes in
generation of the System Reset an gets triggered upon power-up sequence of the
Core domain
Standby Reset (STDBYRESETn) resets HCU part of SCU, get triggered by power-
up sequence of Hibernate domain and is not affected by power-up sequence of the
Core domain
Debug Reset (DBGRESETn) is used in various debug or test related scenarios
(please refer to Reset Control chapter for more details)

The following system dependencies should be considered.
Initialization
The system initialization requires that all required clocks are enabled and the relevant
modules get released from reset state. After system reset release a number of modules
clocked with fPERIPH still remain in reset state. Reset release of those modules is
controlled with PRCLR0, PRCLR1, PRCLR2 and PRCLR3.
The system relevant clocks are configured with the dedicated registers SYSCLKCR,
CPUCLKCR and PBCLKCR. Some modules require explicit clock enable with CLKSET
register. For details please refer to Reset Control on Page 11-22
After reset release the system is clocked with a clock derived from the Backup Clock
source. If a PLL output clock is required as the system clock source then it is necessary
to initialize the respective PLL with a software routine. For details please refer to PLL
section in Main PLL on Page 11-34.

XMC4500
XMC4000 Family
Auxiliary functionality of the system control, like Memory Parity, Die Temperature
Sensor, Out of Range Comparators for analog inputs can be activated with the registers
defined in GCU section of the GCU Registers on Page 11-50
The Watchdog Timer requires the activation of an independent clock. For more details
please refer to WDT chapter.
Hibernate Control logic and the RTC module needs to be activated with PWRSET
register before it can be used. This initialization has to be performed only once if the VBAT
is newly applied and it stays enabled until VBAT is removed. After power off of the chips
the hibernate domain will remain intact while VBAT is still supplied. For details of hibernate
control please refer to Hibernate Control on Page 11-19. For details of RTC module
control please refer o RTC chapter.

XMC4500
XMC4000 Family
11.10 Registers
This section describes the registers of SCU. Most of the registers are reset SYSRESETn
reset signal but some of the registers can be reset only with PORST reset.
Table 11-7 Base Addresses of sub-sections of SCU registers

Short Name Description Offset
Addr.1)
GCU Registers Offset address of General Control Unit 0000H
PCU Registers Offset address of Power Control Unit 0200H
HCU Registers Offset address of Hibernate Control Unit 0300H
RCU Registers Offset address of Reset Control Unit 0400H
CCU Registers Offset address of Clock Control Unit 0600H
Module Base Address + Sub-Module Offset Address (shown in this column) + Register Offset Address
Following access result an AHB error response:

Read or write access to undefined address
Write access in user mode to registers which allow only privileged mode write
Write access to read-only registers
Write access to startup protected registers

SCU 5000 4000H 5000 7FFFH System Control
Unit Registers

Addr. Read Write
1)
General SCU Registers

GCU Registers
ID Module Identification 0000H U, PV BE Page 11-50
Register
IDCHIP Chip ID 0004H U, PV BE Page 11-51

XMC4500
XMC4000 Family

Addr. Read Write
1)
IDMANUF Manufactory ID 0008H U, PV BE Page 11-51

STCON Start-up Control 0010H U, PV PV Page 11-52
GPR0 General Purpose 002CH U, PV PV Page 11-53
Register 0
GPR1 General Purpose 0030H U, PV PV Page 11-53
Register 1
ETH0_CON Ethernet 0 Port Control 0040H U, PV PV Page 11-54
CCUCON CCUx Global Start 004CH U, PV U Page 11-56
Control Register
SRSTAT Service Request Status 0074H U, PV U, PV Page 11-58
SRRAW RAW Service Request 0078H U, PV BE Page 11-60
Status
SRMSK Service Request Mask 007CH U, PV PV Page 11-62
SRCLR Service Request Clear 0080H nBE PV Page 11-64
SRSET Service Request Set 0084H nBE PV Page 11-66
NMIREQEN Enable Promoting 0088H U, PV PV Page 11-68
Events to NMI Request
DTSCON DTS Control 008CH U, PV PV Page 11-69
DTSSTAT DTS Status 0090H U, PV BE Page 11-71
SDMMCDEL SD-MMC Delay Control 009CH U, PV U Page 11-72
Register
G0ORCEN Out-Of-Range 00A0H U, PV U, PV Page 11-72
Comparator Enable
Register
G1ORCEN Out-Of-Range 00A4H U, PV U, PV Page 11-73
Comparator Enable
Register
MIRRSTS Mirror Update Status 00C4H U, PV BE Page 11-74
Register
RMACR Retention Memory 00C8H U, PV U, PV Page 11-76
Access Control Register

XMC4500
XMC4000 Family

Addr. Read Write
1)
RMADATA Retention Memory 00CCH U, PV U, PV Page 11-77

Access Data Register
PEEN Parity Error Enable 013CH U, PV PV Page 11-78
Register
MCHKCON Memory Checking 0140H U, PV PV Page 11-79
Control Register
PETE Parity Error Trap Enable 0144H U, PV PV Page 11-81
Register
PERSTEN Reset upon Parity Error 0148H U, PV PV Page 11-83
Enable Register
PEFLAG Parity Error Control 0150H U, PV PV Page 11-84
Register
PMTPR Parity Memory Test 0154H U, PV PV Page 11-86
Pattern Register
PMTSR Parity Memory Test 0158H U, PV PV Page 11-87
Select Register
TRAPSTAT Trap Status Register 0160H U, PV BE Page 11-89
TRAPRAW Trap Raw Status 0164H U, PV BE Page 11-91
Register
TRAPDIS Trap Mask Register 0168H U, PV PV Page 11-92
TRAPCLR Trap Clear Register 016CH nBE PV Page 11-93
TRAPSET Trap Set Register 0170H nBE PV Page 11-95
PCU Registers
PWRSTAT Power Status Register 0000H U, PV Page 11-96
PWRSET Power Set Control 0004H nBE PV Page 11-97
Register
PWRCLR Power Clear Control 0008H nBE PV Page 11-98
Register
EVRSTAT EVR Status Register 0010H U, PV BE Page 11-99
EVRVADCSTAT EVR VADC Status 0014H U, PV BE Page 11-99
Register
PWRMON Power Monitor Value 002CH U, PV PV Page 11-100

XMC4500
XMC4000 Family

Addr. Read Write
1)
HCU Registers
HDSTAT Hibernate Domain Status 0000H U, PV PV Page 11-101
Register
HDCLR Hibernate Domain Status 0004H U, PV PV Page 11-102
Clear Register
HDSET Hibernate Domain Status 0008H U, PV PV Page 11-103
Set Register
HDCR Hibernate Domain 000CH U, PV PV Page 11-104
Control Register
OSCSICTRL Internal 32 kHz Clock 0014H U, PV PV Page 11-107
Source Control Register
OSCULSTAT OSCULP Status Register 0018H U, PV BE Page 11-107
OSCULCTRL OSCULP Control 001CH U, PV PV Page 11-108
Register
RCU Registers
RSTSTAT System Reset Status 0000H U, PV BE Page 11-109
RSTSET Reset Set Register 0004H nBE PV Page 11-110
RSTCLR Reset Clear Register 0008H nBE PV Page 11-111
PRSTAT0 Peripheral Reset Status 000CH U, PV PV Page 11-112
Register 0
PRSET0 Peripheral Reset Set 0010H nBE PV Page 11-114
Register 0
PRCLR0 Peripheral Reset Clear 0014H nBE PV Page 11-116
Register 0
PRSTAT1 Peripheral Reset Status 0018H U, PV BE Page 11-117
Register 1
PRSET1 Peripheral Reset Set 001CH nBE PV Page 11-119
Register 1
PRCLR1 Peripheral Reset Clear 0020H nBE PV Page 11-120
Register 1
Register 2

XMC4500
XMC4000 Family

Addr. Read Write
1)
PRSET2 Peripheral Reset Set 0028H nBE PV Page 11-123

Register 2
PRCLR2 Peripheral Reset Clear 002CH nBE PV Page 11-124
Register 2
Register 3
PRSET3 Peripheral Reset Set 0034H BE PV Page 11-126
Register 3
PRCLR3 Peripheral Reset Clear 0038H BE PV Page 11-126
Register 3
CCU Registers
CLKSTAT Clock Status Register 0000H U,PV BE Page 11-127
CLKSET Clock Set Control 0004H nBE PV Page 11-128
Register
CLKCLR Clock clear Control 0008H nBE PV Page 11-129
Register
SYSCLKCR System Clock Control 000CH U, PV PV Page 11-130
CPUCLKCR CPU Clock Control 0010H U, PV PV Page 11-131
PBCLKCR Peripheral Bus Clock 0014H U, PV PV Page 11-132
Control
USBCLKCR USB Clock Control 0018H U, PV PV Page 11-132
EBUCLKCR EBU Clock Control 001CH U, PV PV Page 11-133
CCUCLKCR CCU Clock Control 0020H U, PV PV Page 11-134
WDTCLKCR WDT Clock Control 0024H U, PV PV Page 11-134
EXTCLKCR External clock Control 0028H U, PV PV Page 11-135
Register
SLEEPCR Sleep Control Register 0030H U, PV PV Page 11-136
DSLEEPCR Deep Sleep Control 0034H U, PV PV Page 11-138
Register
OSCHPSTAT OSCHP Status Register 0100H U, PV BE Page 11-139
OSCHPCTRL OSCHP Control Register 0104H U, PV PV Page 11-140

XMC4500
XMC4000 Family

Addr. Read Write
1)
PLLSTAT PLL Status Register 0110H U, PV BE Page 11-141

PLLCON0 PLL Configuration 0 0114H U, PV PV Page 11-143
Register
PLLCON1 PLL Configuration 1 0118H U, PV PV Page 11-145
Register
PLLCON2 PLL Configuration 2 011CH U, PV PV Page 11-145
Register
USBPLLSTAT USB_PLL Status 0120H U, PV PV Page 11-146
Register
USBPLLCON USB_PLL Control 0124H U, PV PV Page 11-147
Register
CLKMXSTAT Clock Multiplexing Status 0138H U, PV BE Page 11-149
Register
Module Base Address + Sub-Module Offset Address + Offset Address (shown in this column)
11.10.1 GCU Registers
ID
Register containing unique ID of the module.
ID
SCU Module ID Register (0000H) Reset Value: 00A0 C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
r r r

XMC4500
XMC4000 Family

IDCHIP
Register containing unique ID of the chip.
IDCHIP
Chip ID Register (0004H) Reset Value: XXXX XXXXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
IDCHIP

IDCHIP [31:0] r Chip ID
IDMANUF
Register containing unique manufactory ID of the chip.
IDMANUF
Manufactory ID Register (0008H) Reset Value: 0000 1820H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MANUF DEPT
r r

XMC4500
XMC4000 Family

DEPT [4:0] r Department Identification Number
DEPT indicated department within Infineon
Technologies.
MANUF [15:5] r Manufacturer Identification Number
JEDEC normalized Manufacturer code. MANUF =
C1H stands for Infineon Technologies.
STCON
Startup configuration register determining boot process of the chip.
STCON
Startup Configuration Register (0010H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 SWCON 0 HWCON
r rw r rh

HWCON [1:0] rh HW Configuration
At PORESET the following values are latched
HWCON.0 = not (TMS)
HWCON.1 = TCK
00B Normal mode, JTAG
01B ASC BSL enabled
10B BMI customized boot enabled
11B CAN BSL enabled

XMC4500
XMC4000 Family

SWCON [11:8] rw SW Configuration
Bit[9:8] is copy of Bit[1:0] after PORESET
0000B Normal mode, boot from Boot ROM
0001B ASC BSL enabled
0010B BMI customized boot enabled
0011B CAN BSL enabled
0100B Boot from Code SRAM
1000B Boot from alternate Flash Address 0
1100B Boot from alternate Flash Address 1
1110B Enable fallback Alternate Boot Mode (ABM)
Note: Only reset with Power-on Reset
0 [7:2], r Reserved
GPRx
Software support registers. Can be reset only with PORST reset.
GPRx (x=0-1)
General Purpose Register x (002CH+ x*4) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DAT
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DAT
rw

DAT [31:0] rw User Data
32-bit data
Note: GPRx registers can be reset with PORST
reset only

XMC4500
XMC4000 Family
ETH0_CON
ETH0 module configuration register.
ETH0_CON
Ethernet 0 Port Control Register (50004040H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
INFS
0 0 MDIO 0 CLK_TX COL
EL
r rw r rw r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXER CRS CRS_DV CLK_RMII RXD3 RXD2 RXD1 RXD0

RXD0 [1:0] rw MAC Receive Input 0
This bit field indicates the receive input position of
the RXD0 signal.
00B Data input RXD0A is selected
01B Data input RXD0B is selected
10B Data input RXD0C is selected
11B Data input RXD0D is selected
the RXD1 signal.
the RXD2 signal.

XMC4500
XMC4000 Family

the RXD3 signal.
CLK_RMII [9:8] rw RMII clock input
the RMII clock input signal.
00B Data input RMIIA is selected
01B Data input RMIIB is selected
10B Data input RMIIC is selected
11B Data input RMIID is selected
CRS_DV [11:10] rw CRS_DV input
the CRS_DV input signal.
00B Data input CRS_DVA is selected
01B Data input CRS_DVB is selected
10B Data input CRS_DVC is selected
11B Data input CRS_DVD is selected
CRS [13:12] rw CRS input
the CRS input signal.
00B Data input CRSA
01B Data input CRSB
10B Data input CRSC
11B Data input CRSD
RXER [15:14] rw RXER Input
the RXER input signal.
00B Data input RXERA is selected
01B Data input RXERB is selected
10B Data input RXERC is selected
11B Data input RXERD is selected

XMC4500
XMC4000 Family

COL [17:16] rw COL input
the COL clock input signal.
00B Data input COLA is selected
01B Data input COLB is selected
10B Data input COLC is selected
11B Data input COLD is selected
CLK_TX [19:18] rw CLK_TX input
the CLK_TX input signal.
00B Data input CLK_TXA is selected
01B Data input CLK_TXB is selected
10B Data input CLK_TXC is selected
11B Data input CLK_TXD is selected
MDIO [23:22] rw MDIO Input Select
This bit field selects the input position of the MDI
signal.
00B Data input MDIA is selected
01B Data input MDIB is selected
10B Data input MDIC is selected
11B Data input MDID is selected
INFSEL 26 rw Ethernet MAC Interface Selection
This bit selects Ethernet MAC interface to PHY.
0B MII
1B RMII
[31:27]
CCUCON
CAPCOM module control register. Individual signals signal is generated with fCCU clock.

XMC4500
XMC4000 Family
CCUCON
CCU Control Register (004CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0
r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
GSC GSC GSC GSC GSC GSC
0 0
81 80 43 42 41 40

GSC40 0 rw Global Start Control CCU40
0B Disable
1B Enable
0B Disable
1B Enable
0B Disable
1B Enable
0B Disable
1B Enable
0B Disable
1B Enable
0B Disable
1B Enable
0 [7:4], r Reserved
24,
[31:25]

XMC4500
XMC4000 Family
SRSTAT
Service request status reflecting masking with SRMSK mask register. Write one to a bit
in SRCLR register to clear a bit or SRSET to set a bit. Writing zero has no effect. Outputs
of this register are used to trigger interrupts or service requests.
SRSTAT
SCU Service Request Status (0074H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RTC RTC RTC RTC RTC OSC OSC OSC
HDC HDS HDC HDS
0 RMX _TIM _TIM _ATI _ATI _CT ULC ULS SICT 0
R ET LR TAT
1 0 M1 M0 R TRL TAT RL
r rh rh rh rh rh rh rh rh rh r rh rh rh rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DLR PRW
0 0 0 AI PI
OVR ARN
r r r rh rh rh rh

PRWARN 0 rh WDT pre-warning Interrupt Status
0B Inactive
1B Active
PI 1 rh RTC Periodic Interrupt Status
Set whenever periodic counter increments
AI 2 rh Alarm Interrupt Status
DLROVR 3 rh DLR Request Overrun Interrupt Status
Set whenever DLR overrun condition occurs.
HDSTAT 16 rh HDSTAT Mirror Register Update Status
0B Not updated
1B Update completed
HDCLR 17 rh HDCLR Mirror Register Update Status
0B Not updated
1B Update completed
HDSET 18 rh HDSET Mirror Register Update Status
0B Not updated
1B Update completed

XMC4500
XMC4000 Family

HDCR 19 rh HDCR Mirror Register Update Status
0B Not updated
1B Update completed
OSCSICTRL 21 rh OSCSICTRL Mirror Register Update Status
0B Not updated
1B Update completed
OSCULSTAT 22 rh OSCULSTAT Mirror Register Update Status
0B Not updated
1B Update completed
OSCULCTRL 23 rh OSCULCTRL Mirror Register Update Status
0B Not updated
1B Update completed
RTC_CTR 24 rh RTC CTR Mirror Register Update Status
0B Not updated
1B Update completed
RTC_ATIM0 25 rh RTC ATIM0 Mirror Register Update Status
0B Not updated
1B Update completed
0B Not updated
1B Update completed
RTC_TIM0 27 rh RTC TIM0 Mirror Register Update Status
0B Not updated
1B Update completed
0B Not updated
1B Update completed
RMX 29 rh Retention Memory Mirror Register Update Status
0B Not updated
1B Update completed
0 [5:4], r Reserved
[14:6],
15, 20,
[31:30]

XMC4500
XMC4000 Family
SRRAW
Service request status without masking. Write one to a bit in SRCLR register to clear a
bit or SRSET to set a bit. Writing zero has no effect.
SRRAW
SCU Raw Service Request Status (0078H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
HDC HDS HDC HDS
R ET LR TAT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DLR PRW
0 0 0 AI PI
OVR ARN
r r r rh rh rh rh

PRWARN 0 rh WDT pre-warning Interrupt Status Before
Masking
0B Inactive
1B Active
PI 1 rh RTC Raw Periodic Interrupt Status Before
Masking
Set whenever periodic counter increments
AI 2 rh RTC Raw Alarm Interrupt Status Before Masking
DLROVR 3 rh DLR Request Overrun Interrupt Status Before
Masking
Set whenever DLR overrun condition occurs.
HDSTAT 16 rh HDSTAT Mirror Register Update Status Before
Masking
0B Not updated
1B Update completed
HDCLR 17 rh HDCLR Mirror Register Update Status Before
Masking
0B Not updated
1B Update completed

XMC4500
XMC4000 Family

HDSET 18 rh HDSET Mirror Register Update Status Before
Masking
0B Not updated
1B Update completed
HDCR 19 rh HDCR Mirror Register Update Status Before
Masking
0B Not updated
1B Update completed
Before Masking
0B Not updated
1B Update completed
0B Not updated
1B Update completed
Before Masking
0B Not updated
1B Update completed
RTC_CTR 24 rh RTC CTR Mirror Register Update Status Before
Masking
0B Not updated
1B Update completed
RTC_ATIM0 25 rh RTC ATIM0 Mirror Register Update Status Before
Masking
0B Not updated
1B Update completed
RTC_ATIM1 26 rh RTC ATIM1 Mirror Register Update Status Before
Masking
0B Not updated
1B Update completed
RTC_TIM0 27 rh RTC TIM0 Mirror Register Update Before
Masking Status
0B Not updated
1B Update completed

XMC4500
XMC4000 Family

RTC_TIM1 28 rh RTC TIM1 Mirror Register Update Status Before
Masking
0B Not updated
1B Update completed
RMX 29 rh Retention Memory Mirror Register Update
Status
Before Masking
0B Not updated
1B Update completed
0 [5:4], r Reserved
[14:6],
15, 20,
[31:30]
SRMSK
Service request mask used to mask outputs of SRRAW register outputs connected to
SRSTAT register.
SRMSK
SCU Service Request Mask (007CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
HDC HDS HDC HDS
R ET LR TAT
r rw rw rw rw rw rw rw rw rw r rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DLR PRW
0 0 0 AI PI
OVR ARN
r r r rw rw rw rw

PRWARN 0 rw WDT pre-warning Interrupt Mask
0B Disabled
1B Enabled

XMC4500
XMC4000 Family

PI 1 rw RTC Periodic Interrupt Mask
0B Disabled
1B Enabled
AI 2 rw RTC Alarm Interrupt Mask
0B Disabled
1B Enabled
DLROVR 3 rw DLR Request Overrun Interrupt Mask
0B Disabled
1B Enabled
HDSTAT 16 rw HDSTAT Mirror Register Update Mask
0B Disabled
1B Enabled
HDCLR 17 rw HDCLR Mirror Register Update Mask
0B Disabled
1B Enabled
HDSET 18 rw HDSET Mirror Register Update Mask
0B Disabled
1B Enabled
HDCR 19 rw HDCR Mirror Register Update Mask
0B Disabled
1B Enabled
OSCSICTRL 21 rw OSCSICTRL Mirror Register Update Mask
0B Disabled
1B Enabled
OSCULSTAT 22 rw OSCULSTAT Mirror Register Update Mask
0B Disabled
1B Enabled
OSCULCTRL 23 rw OSCULCTRL Mirror Register Update Mask
0B Disabled
1B Enabled
RTC_CTR 24 rw RTC CTR Mirror Register Update Mask
0B Disabled
1B Enabled
RTC_ATIM0 25 rw RTC ATIM0 Mirror Register Update Mask
0B Disabled
1B Enabled

XMC4500
XMC4000 Family

RTC_ATIM1 26 rw RTC ATIM1 Mirror Register Update Mask
0B Disabled
1B Enabled
RTC_TIM0 27 rw RTC TIM0 Mirror Register Update Mask
0B Disabled
1B Enabled
RTC_TIM1 28 rw RTC TIM1 Mirror Register Update Mask
0B Disabled
1B Enabled
RMX 29 rw Retention Memory Mirror Register Update Mask
0B Disabled
1B Enabled
0 [5:4], r Reserved
[14:6],
15, 20,
[31:30]
SRCLR
Clear service request bits of registers SRRAW and SRSTAT. Write one to clear
corresponding bits. Writing zeros has no effect.
SRCLR
SCU Service Request Clear (0080H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
HDC HDS HDC HDS
R ET LR TAT
r w w w w w w w w w r w w w w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DLR PRW
0 0 0 AI PI
OVR ARN
r r r w w w w

XMC4500
XMC4000 Family

PRWARN 0 w WDT pre-warning Interrupt Clear
0B No effect
1B Clear the status bit
PI 1 w RTC Periodic Interrupt Clear
0B No effect
AI 2 w RTC Alarm Interrupt Clear
0B No effect
DLROVR 3 w DLR Request Overrun Interrupt clear
0B No effect
HDSTAT 16 w HDCTAT Mirror Register Update Clear
0B No effect
HDCLR 17 w HDCLR Mirror Register Update Clear
0B No effect
HDSET 18 w HDSET Mirror Register Update Clear
0B No effect
HDCR 19 w HDCR Mirror Register Update Clear
0B No effect
OSCSICTRL 21 w OSCSICTRL Mirror Register Update Clear
0B No effect
OSCULSTAT 22 w OSCULSTAT Mirror Register Update Clear
0B No effect
OSCULCTRL 23 w OSCULCTRL Mirror Register Update Clear
0B No effect
RTC_CTR 24 w RTC CTR Mirror Register Update Clear
0B No effect

XMC4500
XMC4000 Family

RTC_ATIM0 25 w RTC ATIM0 Mirror Register Update Clear
0B No effect
RTC_ATIM1 26 w RTC ATIM1 Mirror Register Update Clear
0B No effect
RTC_TIM0 27 w RTC TIM0 Mirror Register Update Clear
0B No effect
RTC_TIM1 28 w RTC TIM1 Mirror Register Update Clear
0B No effect
RMX 29 w Retention Memory Mirror Register Update Clear
0B No effect
0 [5:4], r Reserved
[14:6],
15, 20,
[31:30]
SRSET
Set service request fits of registers SRRAW and SRSTAT. Write one to clear
corresponding bits. Writing zeros has no effect.
SRSET
SCU Service Request Set (0084H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RTC RTC RTC RTC RTC OSC OSC OSC HDC HDC
HDC HDS
0 RMX _TIM _TIM _ATI _ATI _CT ULC ULS SICT 0 RSE RCL
R TAT
1 0 M1 M0 R TRL TAT RL T R
r w w w w w w w w w r w w w w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DLR PRW
0 0 0 AI PI
OVR ARN
r r r w w w w

XMC4500
XMC4000 Family

PRWARN 0 w WDT pre-warning Interrupt Set
0B No effect
1B set the status bit
PI 1 w RTC Periodic Interrupt Set
0B No effect
AI 2 w RTC Alarm Interrupt Set
0B No effect
DLROVR 3 w DLR Request Overrun Interrupt Set
0B No effect
HDSTAT 16 w HDSTAT Mirror Register Update Set
0B No effect
HDCRCLR 17 w HDCRCLR Mirror Register Update Set
0B No effect
HDCRSET 18 w HDCRSET Mirror Register Update Set
0B No effect
HDCR 19 w HDCR Mirror Register Update Set
0B No effect
OSCSICTRL 21 w OSCSICTRL Mirror Register Update Set
0B No effect
OSCULSTAT 22 w OSCULSTAT Mirror Register Update Set
0B No effect
OSCULCTRL 23 w OSCULCTRL Mirror Register Update Set
0B No effect
RTC_CTR 24 w RTC CTR Mirror Register Update Set
0B No effect

XMC4500
XMC4000 Family

RTC_ATIM0 25 w RTC ATIM0 Mirror Register Update Set
0B No effect
RTC_ATIM1 26 w RTC ATIM1 Mirror Register Update Set
0B No effect
RTC_TIM0 27 w RTC TIM0 Mirror Register Update Set
0B No effect
RTC_TIM1 28 w RTC TIM1 Mirror Register Update Set
0B No effect
RMX 29 w Retention Memory Mirror Register Update Set
0B No effect
0 [5:4], r Reserved
[14:6],
15, 20,
[31:30]
NMIREQEN
The NMIREQEN register serves purpose of promoting service requests to NMI requests.
Is a bit is set then corresponding service request reflected in SRSTAT otherwise will be
mirrored in the TRAPSTAT register instead.
NMIREQEN
SCU Service Request Mask (0088H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ERU ERU ERU ERU
0
03 02 01 00
r rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRW
0 AI PI
ARN
r rw rw rw

XMC4500
XMC4000 Family

PRWARN 0 rw Promote Pre-Warning Interrupt Request to NMI
Request
0B Disabled
1B Enabled
PI 1 rw Promote RTC Periodic Interrupt request to NMI
Request
0B Disabled
1B Enabled
AI 2 rw Promote RTC Alarm Interrupt Request to NMI
Request
0B Disabled
1B Enabled
ERU00 16 rw Promote Channel 0 Interrupt of ERU0 Request to
NMI Request
0B Disabled
1B Enabled
NMI Request
0B Disabled
1B Enabled
NMI Request
0B Disabled
1B Enabled
NMI Request
0B Disabled
1B Enabled
[31:20]
DTSCON
Die temperature sensor control register

XMC4500
XMC4000 Family
DTSCON
Die Temperature Sensor Control Register (008CH) Reset Value: 0000 0001H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
GAI
0 BGTRIM REFTRIM
N
r rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
STA
GAIN OFFSET 0 PWD
RT
rw rw r w rw

PWD 0 rw Sensor Power Down
This bit defines the DTS power state.
0B The DTS is powered
1B The DTS is not powered
START 1 w Sensor Measurement Start
This bit starts a measurement of the DTS.
0B No DTS measurement is started
1B A DTS measurement is started
If set this bit is automatically cleared.
This bit always reads as zero.
OFFSET [10:4] rw Offset Calibration Value
This bit field interfaces the offset calibration values to
the DTS.
The calibration values are forwarded to the DTS by
setting bit START.
GAIN [16:11] rw Gain Calibration Value
This bit field interfaces the gain calibration values to
the DTS.
setting bit START.
REFTRIM [19:17] rw Reference Trim Calibration Value
This bit field interfaces the reference trim calibration
values to the DTS.
setting bit START.

XMC4500
XMC4000 Family

BGTRIM [23:20] rw Bandgap Trim Calibration Value
This bit field interfaces the bandgap trim calibration
values to the DTS.
setting bit START.
0 [3:2], r Reserved
DTSSTAT
Die temperature status register
DTSSTAT
Die Temperature Sensor Status Register (0090H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BUS
RDY 0 RESULT
Y
rh rh r rh

RESULT [9:0] rh Result of the DTS Measurement
This bit field shows the result of the DTS
measurement. The value given is directly related to
the die temperature.
RDY 14 rh Sensor Ready Status
This bit indicate the DTS is ready or not.
0B The DTS is not ready
1B The DTS is ready

XMC4500
XMC4000 Family

BUSY 15 rh Sensor Busy Status
This bit indicate if the DTS is currently busy. If the
sensor is busy a measurement is still running and
the result should not be used.
0B not busy
1B busy
SDMMCDEL
Delay control register for SD-MMC module.
SDMMCDEL
SD-MMC Delay Control Register (009CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TAP
0 TAPDEL 0
EN
r rw r rw

TAPEN 0 rw Enable delay on the CMD/DAT out lines
0B Disabled
1B Enabled
TAPDEL [7:4] rw Number of Delay Elements Select
number of delay elements of (TAPDEL+1),
0 [3:1], r Reserved
G0ORCEN
Enable register for out-of-range comparators of group 0 of analog input channels.

XMC4500
XMC4000 Family
G0ORCEN
Out of Range Comparator Enable Register 0 (00A0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ENO ENO
0 0
RC7 RC6
r rw rw r

ENORC6 6 rw Enable Out of Range Comparator, Channel 6
Each bit (when set) enables the out of range
comparator of the associated channel
0B Disabled
1B Enabled
0B Disabled
1B Enabled
0 [5:0], r Reserved
[31:8] returns 0 if read; should be written with 0;
G1ORCEN
Enable register for out-of-range comparators of group 1 of analog input channels.

XMC4500
XMC4000 Family
G1ORCEN
Out of Range Comparator Enable Register 1 (00A4H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ENO ENO
0 0
RC7 RC6
r rw rw r

0B Disabled
1B Enabled
0B Disabled
1B Enabled
0 [5:0], r Reserved
[31:8] returns 0 if read; should be written with 0;
MIRRSTS
Mirror status register for control of communication between SCU and other modules in
hibernate domain.

XMC4500
XMC4000 Family
MIRRSTS
Mirror Update Status Register (00C4H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0
r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
HDC HDS HDC HDS
R ET LR TAT
Field Bits Type Function

HDSTAT 0 rh HDSTAT Mirror Register Update Status
0B No update pending
1B Update pending
HDCLR 1 rh HDCLR Mirror Register Update Status
1B Update pending
HDSET 2 rh HDSET Mirror Register Update Status
1B Update pending
HDCR 3 rh HDCR Mirror Register Update Status
1B Update pending
1B Update pending
1B Update pending
1B Update pending
RTC_CTR 8 rh RTC CTR Mirror Register Update Status
1B Update pending

XMC4500
XMC4000 Family

1B Update pending
1B Update pending
1B Update pending
1B Update pending
RMX 13 rh Retention Memory Access Register Update Status
This fields indicates status of retention memory
update from RMDATA register to Hibernate domain
retention memory or from Hibernate domain to
RMDATA
1B Update pending
0 4, r Reserved
[24:16],
[31:25]
RMACR
Access control to retention memory in hibernate domain.
RMACR
Retention Memory Access Control Register (00C8H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 ADDR
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RDW
0
R
r rw

XMC4500
XMC4000 Family

RDWR 0 rw Hibernate Retention Memory Register Update
Control
This field controls access to Retention Memory using
address selected in ADDR slice
0B transfer data from Retention Memory in
Hibernate domain to RMDATA register
1B transfer data from RMDATA into Retention
Memory in Hibernate domain
ADDR [19:16] rw Hibernate Retention Memory Register Address
Select
This field selects Retention Memory address of 0 to 15
for read or write access.
RMDATA
Access data of retention memory in hibernate domain.
RMDATA
Retention Memory Access Data Register (00CCH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DATA
rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DATA
rwh

DATA [31:0] rwh Hibernate Retention Memory Data
This field data of selected of Retention Memory using
address. The address of 0-15 is selected with RMACR
register.

XMC4500
XMC4000 Family
PEEN
The following register enables parity check mechanism on peripheral modules.
PEEN
Parity Error Enable Register (013CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PEE PEE
PEE PEE PEE
NET NET
0 NSD NSD NUS
H0R H0T
1 0 B
X X
r rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PEE PEE PEE
PEE PEE PEE PEE PEE
0 NPP 0 0 NDS NDS
NMC NU2 NU1 NU0 NPS
RF 2 1
r rw rw r rw rw rw r rw rw rw

PEENPS 0 rw Parity Error Enable for PSRAM
0B Disabled
1B Enabled
PEENDS1 1 rw Parity Error Enable for DSRAM1
0B Disabled
1B Enabled
PEENDS2 2 rw Parity Error Enable for DSRAM2
0B Disabled
1B Enabled
PEENU0 8 rw Parity Error Enable for USIC0 Memory
0B Disabled
1B Enabled
0B Disabled
1B Enabled
0B Disabled
1B Enabled

XMC4500
XMC4000 Family

PEENMC 12 rw Parity Error Enable for MultiCAN Memory
0B Disabled
1B Enabled
PEENPPRF 13 rw Parity Error Enable for PMU Prefetch Memory
0B Disabled
1B Enabled
PEENUSB 16 rw Parity Error Enable for USB Memory
0B Disabled
1B Enabled
PEENETH0TX 17 rw Parity Error Enable for ETH TX Memory
0B Disabled
1B Enabled
PEENETH0RX 18 rw Parity Error Enable for ETH RX Memory
0B Disabled
1B Enabled
PEENSD0 19 rw Parity Error Enable for SDMMC Memory 0
0B Disabled
1B Enabled
PEENSD1 20 rw Parity Error Enable for SDMMC Memory 1
0B Disabled
1B Enabled
0 [7:3], r Reserved
11, Should be written with 0.
[15:14],
[31:21]
MCHKCON
The following register enables the functional parity check mechanism for testing
purpose. MCHKCON register is used to support access to parity bits of SRAM modules
for various types of peripherals. The SRAM modules providing direct access natively
need to be selected in order to enable direct write to parity bits using PMTPR register.

XMC4500
XMC4000 Family
MCHKCON
Memory Checking Control Register (0140H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SEL SEL
SEL SEL SEL
0 ETH ETH
SD1 SD0 USB
0RX 0TX
r rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PPR MCA USIC USIC USIC
SEL SEL SEL
0 FDR NDR 0 2DR 1DR 0DR 0
DS2 DS1 PS
A A A A A

SELPS 0 rw Select Memory Check for PSRAM
0B Not selected
1B Selected
SELDS1 1 rw Select Memory Check for DSRAM1
0B Not selected
1B Selected
SELDS2 2 rw Select Memory Check for DSRAM2
0B Not selected
1B Selected
USIC0DRA 8 rw Select Memory Check for USIC0
0B Not selected
1B Selected
0B Not selected
1B Selected
0B Not selected
1B Selected
MCANDRA 12 rw Select Memory Check for MultiCAN
0B Not selected
1B Selected

XMC4500
XMC4000 Family

PPRFDRA 13 rw Select Memory Check for PMU
0B Not selected
1B Selected
SELUSB 16 rw Select Memory Check for USB SRAM
0B Not selected
1B Selected
SELETH0TX 17 rw Select Memory Check for ETH0 TX SRAM
0B Not selected
1B Selected
SELETH0RX 18 rw Select Memory Check for ETH0 RX SRAM
0B Not selected
1B Selected
SELSD0 19 rw Select Memory Check for SDMMC SRAM 0
0B Not selected
1B Selected
SELSD1 20 rw Select Memory Check for SDMMC SRAM 1
0B Not selected
1B Selected
0 [7:3], r Reserved
[15:14],
[31:21]
PETE
The following register enables the functional parity error trap generation mechanism.
The trap flag gets reflected in TRAPRAW register and needs to be enabled with
TRAPDIS register before can be effectively used to generate an NMI. The same tap flag
can be configured with PERSTEN register to generate system reset instead of an NMI.

XMC4500
XMC4000 Family
PETE
Parity Error Trap Enable Register (0144H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PET PET
PET PET PET
EET EET
0 ESD ESD EUS
H0R H0T
1 0 B
X X
r rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PET PET PET
PET PET PET PET PET
0 EPP 0 0 EDS EDS
EMC EU2 EU1 EU0 EPS
RF 2 1

PETEPS 0 rw Parity Error Trap Enable for PSRAM
0B Disabled
1B Enabled
PETEDS1 1 rw Parity Error Trap Enable for DSRAM1
0B Disabled
1B Enabled
PETEDS2 2 rw Parity Error Trap Enable for DSRAM2
0B Disabled
1B Enabled
PETEU0 8 rw Parity Error Trap Enable for USIC0 Memory
0B Disabled
1B Enabled
0B Disabled
1B Enabled
0B Disabled
1B Enabled
PETEMC 12 rw Parity Error Trap Enable for MultiCAN Memory
0B Disabled
1B Enabled

XMC4500
XMC4000 Family

PETEPPRF 13 rw Parity Error Trap Enable for PMU Prefetch
Memory
0B Disabled
1B Enabled
PETEUSB 16 rw Parity Error Trap Enable for USB Memory
0B Disabled
1B Enabled
PETEETH0TX 17 rw Parity Error Trap Enable for ETH 0TX Memory
0B Disabled
1B Enabled
PETEETH0RX 18 rw Parity Error Trap Enable for ETH0 RX Memory
0B Disabled
1B Enabled
PETESD0 19 rw Parity Error Trap Enable for SDMMC SRAM 0
Memory
0B Disabled
1B Enabled
PETESD1 20 rw Parity Error Trap Enable for SDMMC SRAM 1
Memory
0B Disabled
1B Enabled
0 [7:3], r Reserved
[15:14],
[31:21]
PERSTEN
The following register enables reset upon parity error flag from the functional parity
check mechanism indicated in PEFLAG register.

XMC4500
XMC4000 Family
PERSTEN
Parity Error Reset Enable Register (0148H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RSE
0
N
r rw

RSEN 0 rw System Reset Enable upon Parity Error Trap
0B Reset request disabled
1B Reset request enabled
0 [31:1] r Reserved
Should be written with 0.
PEFLAG
The PEFLAG register controls the functional parity check mechanism.
The register bits can only get set by corresponding parity error assertion if enabled and
can only be cleared via software. Writing a zero to this bit does not change the content.
Writing a one to this bit does clear the bit.
PEFLAG
Parity Error Flag Register (0150H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PEE PEE
PES PES PEU
0 TH0 TH0
D1 D0 SB
RX TX
r rwh rwh rwh rwh rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PEF
PEF PEF PEF PEF PEF PEF PEF
0 PPR 0 0
MC U2 U1 U0 DS2 DS1 PS
F
r rwh rwh r rwh rwh rwh r rwh rwh rwh

XMC4500
XMC4000 Family

PEFPS 0 rwh Parity Error Flag for PSRAM
0B No parity error detected
1B Parity error detected
PEFDS1 1 rwh Parity Error Flag for DSRAM1
PEFDS2 2 rwh Parity Error Flag for DSRAM2
PEFU0 8 rwh Parity Error Flag for USIC0 Memory
PEFMC 12 rwh Parity Error Flag for MultiCAN Memory
PEFPPRF 13 rwh Parity Error Flag for PMU Prefetch Memory
PEUSB 16 rwh Parity Error Flag for USB Memory
PEETH0TX 17 rwh Parity Error Flag for ETH TX Memory
PEETH0RX 18 rwh Parity Error Flag for ETH RX Memory
PESD0 19 rwh Parity Error Flag for SDMMC Memory 0

XMC4500
XMC4000 Family

PESD1 20 rwh Parity Error Flag for SDMMC Memory 1
0 [7:3], r Reserved
[15:14],
[31:21]
PMTPR
The following register provides direct access to parity bits of a selected module.
The width and therefore the valid bits in register PMTPR is listed in Table 11-10.
Table 11-10 Memory Widths

Memory Number of Valid Bits in PWR/PRD
Parity Bits
Program SRAM (PSRAM) 4 PWR[3:0]/PRD[11:8]
System SRAM (DSRAM1) 4 PWR[3:0]/PRD[11:8]
Communication SRAM (DSRAM2) 4 PWR[3:0]/PRD[11:8]
USIC 0 Buffer Memory (U0) 1 PWR[0]/PRD[8]
MultiCAN Buffer Memory (MC) 1 PWR[0]/PRD[8]
PMU Prefetch Buffer Memory (PPRF) 1 PWR[0]/PRD[8]
USB Buffer Memory (USB) 1 PWR[0]/PRD[8]
ETH 0 TX Buffer Memory (ETH0TX) 1 PWR[0]/PRD[8]
ETH 0 RX Buffer Memory (ETH0RX) 1 PWR[0]/PRD[8]
SDMMC Buffer Memory 0 (SD0) 1 PWR[0]/PRD[8]
SDMMC Buffer Memory 1 (SD1) 1 PWR[0]/PRD[8]

XMC4500
XMC4000 Family
PMTPR
Parity Memory Test Pattern Register (0154H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRD PWR
rh rw

PRD [15:8] rh Parity Read Values for Memory Test
For each byte of a memory module the parity bits
generated during the most recent read access are
indicated here.
PWR [7:0] rw Parity Write Values for Memory Test
For each byte of a memory module the parity bits
corresponding to the next write access are stored
here.
Should be written with 0.
PMTSR
This register selects parity test output from a memory instance that will be reflected in
PRD bit field of PMTPR register.
Note: Only one bit shall be set at the same time in register PMTPR. Otherwise the result
of the parity software test is unpredictable.

XMC4500
XMC4000 Family
PMTSR
Parity Memory Test Select Register (0158H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MTE MTE
MTS MTS MTU
0 TH0 TH0
D1 D0 SB
RX TX
r rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MTE MTE MTE
MTE MTE MTE MTE MTE
0 PPR 0 0 NDS NDS
MC U2 U1 U0 NPS
F 2 1
r rwh rwh r rwh rwh rwh r rw rw rw

MTENPS 0 rw Test Enable Control for PSRAM
0B Standard operation
1B Parity bits under test
MTENDS1 1 rw Test Enable Control for DSRAM1
MTENDS2 2 rw Test Enable Control for DSRAM2
MTEU0 8 rwh Test Enable Control for USIC0 Memory
MTEMC 12 rwh Test Enable Control for MultiCAN Memory

XMC4500
XMC4000 Family

MTEPPRF 13 rwh Test Enable Control for PMU Prefetch Memory
MTUSB 16 rw Test Enable Control for USB Memory
MTETH0TX 17 rw Test Enable Control for ETH TX Memory
MTETH0RX 18 rw Test Enable Control for ETH RX Memory
MTSD0 19 rw Test Enable Control for SDMMC Memory 0
MTSD1 20 rw Test Enable Control for SDMMC Memory 1
0 [7:3], r Reserved
[15:14],
[31:21]
TRAPSTAT
This register contains the status flags for all trap request trigger sources of the SCU.
A trap flag is set when a corresponding emergency event occurs. Trap mechanism
supports testing and debug of these status bits by software using registers TRAPSET
and TRAPCLR. This register reflects masking with TRAPDIS register.

XMC4500
XMC4000 Family
TRAPSTAT
Trap Status Register (0160H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BWE BWE ULP UVC SVC SOS
BRW
0 0 0 0 RR1 RR0 WDG PET OLC OLC 0 CWD
NT
T T T KT KT GT
r r r r rh rh rh rh rh rh rh r rh

SOSCWDGT 0 rh System OSC WDT Trap Status
0B No pending trap request
1B Pending trap request
SVCOLCKT 2 rh System VCO Lock Trap Status
UVCOLCKT 3 rh USB VCO Lock Trap Status
PET 4 rh Parity Error Trap Status
BRWNT 5 rh Brown Out Trap Status
ULPWDGT 6 rh OSCULP WDG Trap Status
BWERR0T 7 rh Peripheral Bridge 0 Trap Status
This trap flags error responses for buffered write
operations on the Peripheral Bridge 0

XMC4500
XMC4000 Family

BWERR1T 8 rh Peripheral Bridge 1 Trap Status
This trap flags error responses for buffered write
operations on the Peripheral Bridge 1
0 1, r Reserved
12,13,
[31:14]
TRAPRAW
This register contains the status flags for all trap request trigger sources of the SCU
before masking with TRAPDIS.
A trap flag is set when a corresponding emergency event occurs. For setting and
clearing of these status bits by software see registers TRAPSET and TRAPCLR,
respectively.
TRAPRAW
Trap Raw Status Register (0164H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BRW
NT
T T T KT KT GT
r r r r rh rh rh rh rh rh rh r rh

SOSCWDGT 0 rh System OSC WDT Trap Raw Status
SVCOLCKT 2 rh System VCO Lock Trap Raw Status

XMC4500
XMC4000 Family

UVCOLCKT 3 rh USB VCO Lock Trap Raw Status
PET 4 rh Parity Error Trap Raw Status
BRWNT 5 rh Brown Out Trap Raw Status
ULPWDGT 6 rh OSCULP WDG Trap RAW Status
BWERR0T 7 rh Peripheral Bridge 0 Trap Raw Status
BWERR1T 8 rh Peripheral Bridge 1 Trap Raw Status
0 1, r Reserved
12,13,
[31:14]
TRAPDIS
Disable corresponding traps.
TRAPDIS
Trap Disable Register (0168H) Reset Value: 0000 01FFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BRW
NT
T T T KT KT GT
r r r r rw rw rw rw rw rw rw r rw

XMC4500
XMC4000 Family

SOSCWDGT 0 rw System OSC WDT Trap Disable
0B Trap request enabled
1B Trap request disabled
SVCOLCKT 2 rw System VCO Lock Trap Disable
UVCOLCKT 3 rw USB VCO Lock Trap Disable
PET 4 rw Parity Error Trap Disable
BRWNT 5 rw Brown Out Trap Disable
ULPWDGT 6 rw Wake-up Trap Disable
BWERR0T 7 rw Peripheral Bridge 0 Trap Disable
BWERR1T 8 rw Peripheral Bridge 1 Trap Disable
0 1, r Reserved
12,13,
[31:14]
TRAPCLR
This register contains the software clear control for the trap status flags in register
TRAPRAW and TRAPSTAT.

XMC4500
XMC4000 Family
TRAPCLR
Trap Clear Register (016CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BRW
NT
T T T KT KT GT
r r r r w w w w w w w r w

SOSCWDGT 0 w System OSC WDT Trap Clear
0B No effect
1B Clear trap request
SVCOLCKT 2 w System VCO Lock Trap Clear
0B No effect
UVCOLCKT 3 w USB VCO Lock Trap Clear
0B No effect
PET 4 w Parity Error Trap Clear
0B No effect
BRWNT 5 w Brown Out Trap Clear
0B No effect
ULPWDGT 6 w OSCULP WDG Trap Clear
0B No effect
BWERR0T 7 w Peripheral Bridge 0 Trap Clear
0B No effect
BWERR1T 8 w Peripheral Bridge 1 Trap Clear
0B No effect

XMC4500
XMC4000 Family

0 1, r Reserved
12,13,
[31:14]
TRAPSET
This register contains the software set control for the trap status flags in register
TRAPRAW.
TRAPSET
Trap Set Register (0170H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BWE BWE UVC SVC SOS
ULP BRW
0 0 0 0 RR1 RR0 PET OLC OLC 0 CWD
WDT NT
T T KT KT GT
r r r r w w w w w w w r w

SOSCWDGT 0 w System OSC WDT Trap Set
0B No effect
1B Set trap request
SVCOLCKT 2 w System VCO Lock Trap Set
0B No effect
1B Set trap request
UVCOLCKT 3 w USB VCO Lock Trap Set
0B No effect
1B Set trap request
PET 4 w Parity Error Trap Set
0B No effect
1B Set trap request

XMC4500
XMC4000 Family

BRWNT 5 w Brown Out Trap Set
0B No effect
1B Set trap request
ULPWDT 6 w OSCULP WDG Trap Set
0B No effect
1B Set trap request
BWERR0T 7 w Peripheral Bridge 0 Trap Set
0B No effect
1B Set trap request
BWERR1T 8 w Peripheral Bridge 1 Trap Set
0B No effect
1B Set trap request
0 1, r Reserved
12,13,
[31:14]
11.10.2 PCU Registers
PWRSTAT
Power status register.
PWRSTAT
PCU Status Register (0200H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
USB USB USB
0 PUW OTG PHY
Q EN PDQ
r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
HIBE
0 0
N
r r r

XMC4500
XMC4000 Family

HIBEN 0 r Hibernate Domain Enable Status
0B Inactive
1B Active
USBPHYPDQ 16 r USB PHY Transceiver State
0B Power-down
1B Active
USBOTGEN 17 r USB On-The-Go Comparators State
0B Power-down
1B Active
USBPUWQ 18 r USB Weak Pull-Up at PADN State
0B Pull-up active
1B Pull-up not active
0 1, r Reserved
[15:2],
[31:19]
PWRSET
Power control register. Write one to set, writing zeros have no effect.
PWRSET
PCU Set Control Register (0204H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
USB USB USB
0 PUW OTG PHY
Q EN PDQ
r w w w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 HIB
r w

HIB 0 w Set Hibernate Domain Enable
0B No effect
1B Enable Hibernate domain

XMC4500
XMC4000 Family

USBPHYPDQ 16 w Set USB PHY Transceiver Disable
0B No effect
1B Active
USBOTGEN 17 w Set USB On-The-Go Comparators Enable
0B No effect
1B Active
USBPUWQ 18 w Set USB Weak Pull-Up at PADN Enable
0B No effect
1B Pull-up not active
[31:19]
PWRCLR
Power control register. Write one to clear, writing zeros have no effect.
PWRCLR
PCU Clear Control Register (0208H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
USB USB USB
0 PUW OTG PHY
Q EN PDQ
r w w w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 HIB
r w

HIB 0 w Clear Disable Hibernate Domain
0B No effect
1B Disable Hibernate domain
USBPHYPDQ 16 w Clear USB PHY Transceiver Disable
0B No effect
1B Power-down

XMC4500
XMC4000 Family

USBOTGEN 17 w Clear USB On-The-Go Comparators Enable
0B No effect
1B Power-down
USBPUWQ 18 w Clear USB Weak Pull-Up at PADN Enable
0B No effect
1B Pull-up active
[31:19]
EVRSTAT
EVR status register.
EVRSTAT
EVR Status Register (0210H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
OV1
0 0
3
r rh r

OV13 1 rh Regulator Overvoltage for 1.3 V
0B No overvoltage condition
1B Regulator is in overvoltage
0 0, r Reserved
EVRVADCSTAT
Supply voltage monitor register.

XMC4500
XMC4000 Family
EVRVADCSTAT
EVR VADC Status Register (0214H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VADC33V VADC13V
rh rh

VADC13V [7:0] rh VADC 1.3 V Conversion Result
This bit field contains the last conversion result of the
VADC for the EVR13.
VADC33V [15:8] rh VADC 3.3 V Conversion Result
This bit field contains the last conversion result of the
VADC for the EVR33.
The value is used for brown-out detection
Read as 0.
PWRMON
Power monitoring control register for brown-out detection.

XMC4500
XMC4000 Family
PWRMON
Power Monitor Control (022CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 ENB
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
INTV THRS
rw rw

THRS [7:0] rw Threshold
Threshold value for comparison to VDDP for brown-
out detection
INTV [15:8] rw Interval
Interval value for comparison to VDDP expressed in
cycles of system clock
ENB 16 rw Enable
Enable of comparison and interrupt generation
11.10.3 HCU Registers
HDSTAT
Hibernate domain status register

XMC4500
XMC4000 Family
HDSTAT
Hibernate Domain Status Register (0300H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0
r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
HIBN ULP RTC ENE EPE
0 0 0
OUT WDG EV V V
r r r rh rh rh rh rh

EPEV 0 rh Wake-up Pin Event Positive Edge
0B Wake-up on positive edge pin event inactive
1B Wake-up on positive edge pin event active
ENEV 1 rh Wake-up Pin Event Negative Edge
0B Wake-up on negative edge pin event inactive
1B Wake-up on negative edge pin event active
RTCEV 2 rh RTC Event
0B Wake-up on RTC event inactive
1B Wake-up on RTC event active
ULPWDG 3 rh ULP WDG Alarm Status
0B Watchdog alarm did not occur
1B Watchdog alarm occurred
HIBNOUT 4 rh Hibernate Control Status
0B Hibernate not driven active to pads
1B Hibernate driven active to pads
0 [7:5], r Reserved
[30:14],
31
HDCLR
Hibernate domain clear status register. Write one to clear, writing zeros has no effect.

XMC4500
XMC4000 Family
HDCLR
Hibernate Domain Status Clear Register (0304H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0
r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ULP RTC ENE EPE
0 0 0
WDG EV V V
r r r w w w w

EPEV 0 w Wake-up Pin Event Positive Edge Clear
0B No effect
1B Clear wake-up event
ENEV 1 w Wake-up Pin Event Negative Edge Clear
0B No effect
RTCEV 2 w RTC Event Clear
0B No effect
ULPWDG 3 w ULP WDG Alarm Clear
0B No effect
1B Clear watchdog alarm
0 [7:4], r Reserved
[30:14],
31
HDSET
Hibernate domain set status register. Write one to set, writing zeros has no effect.

XMC4500
XMC4000 Family
HDSET
Hibernate Domain Status Set Register (0308H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0
r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ULP RTC ENE EPE
0 0 0
WDG EV V V
r r r w w w w

EPEV 0 w Wake-up Pin Event Positive Edge Set
0B No effect
1B Set wake-up event
ENEV 1 w Wake-up Pin Event Negative Edge Set
0B No effect
RTCEV 2 w RTC Event Set
0B No effect
ULPWDG 3 w ULP WDG Alarm Set
0B No effect
1B Set watchdog alarm
0 [7:4], r Reserved
[30:14],
31
HDCR
Hibernate domain configuration register.

XMC4500
XMC4000 Family
HDCR
Hibernate Domain Control Register (030CH) Reset Value: 000C 2000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 HIBIO1SEL HIBIO0SEL
r r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
HIBI HIBI WKU STD ULP
GPI0 RTC WKP WKP
0 O1P O0P 0 0 PSE BYS RCS 0 HIB WDG
SEL E EN EP
OL OL L EL EN
r rw rw r rw r rw rw rw r rwh rw rw rw rw

WKPEP 0 rw Wake-Up on Pin Event Positive Edge Enable
0B Wake-up event disabled
1B Wake-up event enabled
WKPEN 1 rw Wake-up on Pin Event Negative Edge Enable
RTCE 2 rw Wake-up on RTC Event Enable
ULPWDGEN 3 rw ULP WDG Alarm Enable
HIB 4 rwh Hibernate Request Value Set
0B External hibernate request inactive
1B External hibernate request active
Note: This bit get automatically cleared by hardware
upon occurrence of any wake-up event
enabled in this register
RCS 6 rw fRTC Clock Selection
0B fOSI selected
1B fULP selected
STDBYSEL 7 rw fSTDBY Clock Selection
0B fOSI selected
1B fULP selected

XMC4500
XMC4000 Family

WKUPSEL 8 rw Wake-Up from Hibernate Trigger Input Selection
0B HIB_IO_1 pin selected
GPI0SEL 10 rw General Purpose Input 0 Selection
This bit field selects input to ERU0 module that
optionally can be used with software as a general
purpose input.
HIBIO0POL 12 rw HIBIO0 Polarity Set
Selects the output polarity of the HIBIO0
0B Direct value
1B Inverted value
HIBIO1POL 13 rw HIBIO1 Polarity Set
Selects the output polarity of the HIBIO1
0B Direct value
1B Inverted value
HIBIO0SEL [19:16] rw HIB_IO_0 Pin I/O Control (default HIBOUT)
This bit field determines the Port n line x functionality.
0000B Direct input, No input pull device connected
0001B Direct input, Input pull-down device connected
0010B Direct input, Input pull-up device connected
1000B Push-pull HIB Control output
1001B Push-pull WDT service output
1010B Push-pull GPIO output
1100B Open-drain HIB Control output
1101B Open-drain WDT service output
1110B Open-drain GPIO output
HIBIO1SEL [23:20] rw HIB_IO_1 Pin I/O Control (Default WKUP)
This bit field determines the Port n line x functionality.
0000B Direct input, No input pull device connected
0001B Direct input, Input pull-down device connected
0010B Direct input, Input pull-up device connected
1000B Push-pull HIB Control output
1001B Push-pull WDT service output
1010B Push-pull GPIO output
1100B Open-drain HIB Control output
1101B Open-drain WDT service output
1110B Open-drain GPIO output

XMC4500
XMC4000 Family

0 5,9, r Reserved
[15:14],
[29:24],
[31:30]
OSCSICTRL
Control register for fOSI clock source. A special mechanism keeps the fOSI clock active if
the external crystal oscillator is switched off, regardless of the value of the PWD bit field.
The fOSI can be switched off only if the external crystal oscillator is enabled and the fULP
clock toggling.
OSCSICTRL
fOSI Control Register (0314H) Reset Value: 0000 0001H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 PWD
r rw

PWD 0 rw Tun OFF the fOSI Clock Source
0B Enabled
1B Disabled
0 [31:1] r Reserved
OSCULSTAT
Status register of the OSCULP oscillator.

XMC4500
XMC4000 Family
OSCULSTAT
OSCULP Status Register (0318H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 X1D
r rh

X1D 0 rh XTAL1 Data Value
This bit monitors the value (level) of pin XTAL1. If
XTAL1 is not used as clock input it can be used as
GPI pin.
This bit is only updated if X1DEN is set.
0 [31:1] r Reserved
OSCULCTRL
Control register for OSCULP oscillator. This register allows selection of clock generation
with external crystal, direct clock input, or power down mode. Alternate GPI function of
the pin is also controlled with this register.
OSCULCTRL
OSCULP Control Register (031CH) Reset Value: 0000 0020H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
X1D
0 MODE 0
EN
r rw r rw

XMC4500
XMC4000 Family

X1DEN 0 rw XTAL1 Data General Purpose Input Enable
The GPI data can be monitored with X1D bit of
OSCULSTAT register
0B Data input inactivated, power down
1B Data input active
Note: It is strongly recommended to keep this
function inactivated if the XTAL1 input is used
as clock source
MODE [5:4] rw Oscillator Mode
00B Oscillator is enabled, in operation
01B Oscillator is enabled, in bypass mode
10B Oscillator in power down
11B Oscillator in power down, can be used as GPI
Note: Use of the oscillator input require that X1DEN
bit is activated
0 [3:1], r Reserved
11.10.4 RCU Registers
RSTSTAT
Reset status register. This register needs to be checked after system startup in order to
determine last reset reason.
RSTSTAT
RCU Reset Status (0400H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
LCK HIBR HIB
0 0 RSTSTAT
EN S WK
r r r r rh rh

XMC4500
XMC4000 Family

RSTSTAT [7:0] rh Reset Status Information
Provides reason of last reset
00000001B PORST reset
00000010B SWD reset
00000100B PV reset
00001000B CPU system reset
00010000B CPU lockup reset
00100000B WDT reset
01000000B Reserved
10000000B Parity Error reset
HIBWK 8 rh Hibernate Wake-up Status
0B No Wake-up
1B Wake-up event
Note: Field is cleared with enable of Hibernate
mode
HIBRS 9 r Hibernate Reset Status

0B Reset de-asserted
1B Reset asserted
LCKEN 10 r Enable Lockup Status
0B Reset by Lockup disabled
1B Reset by Lockup enabled
0 11, r Reserved
[31:12]
RSTSET
Selective configuration of reset behavior in the system. Write one to set selected bit,
writing zeros has no effect.

XMC4500
XMC4000 Family
RSTSET
RCU Reset Set Register (0404H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
LCK HIBR HIB
0 0
EN S WK
r w w w r

HIBWK 8 w Set Hibernate Wake-up Reset Status
0B No effect
1B Assert reset status bit
HIBRS 9 w Set Hibernate Reset
0B No effect
1B Assert reset
LCKEN 10 w Enable Lockup Reset
0B No effect
1B Enable reset when Lockup gets asserted
0 [7:0], r Reserved
[31:11]
RSTCLR
Selective configuration of reset behavior in the system. Write one to clear selected bit,
writing zeros has no effect.

XMC4500
XMC4000 Family
RSTCLR
RCU Reset Clear Register (0408H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
LCK HIBR HIB RSC
0 0
EN S WK LR
r w w w r w

RSCLR 0 w Clear Reset Status
0B No effect
1B Clears field RSTSTAT.RSTSTAT
HIBWK 8 w Clear Hibernate Wake-up Reset Status
0B No effect
1B De-assert reset status bit
HIBRS 9 w Clear Hibernate Reset
0B No effect
1B De-assert reset
LCKEN 10 w Enable Lockup Reset
0B No effect
1B Disable reset when Lockup gets asserted
0 [7:1], r Reserved
[31:11]
PRSTAT0
Selective reset status register for peripherals for Peripherals 0.

XMC4500
XMC4000 Family
PRSTAT0
RCU Peripheral 0 Reset Status (040CH) Reset Value: 0001 0F9FH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ERU
0 0 0
1RS
r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
POSI POSI CCU CCU CCU CCU CCU
USIC DSD VAD
0 F1R F0R 81R 80R 0 42R 41R 40R
0RS RS CRS
S S S S S S S
r r r r r r r r r r r r

VADCRS 0 r VADC Reset Status
1B Reset asserted
DSDRS 1 r DSD Reset Status
1B Reset asserted
CCU40RS 2 r CCU40 Reset Status
1B Reset asserted
1B Reset asserted
1B Reset asserted
1B Reset asserted
1B Reset asserted
POSIF0RS 9 r POSIF0 Reset Status
1B Reset asserted

XMC4500
XMC4000 Family

POSIF1RS 10 r POSIF1 Reset Status
1B Reset asserted
USIC0RS 11 r USIC0 Reset Status
1B Reset asserted
ERU1RS 16 r ERU1 Reset Status
1B Reset asserted
0 [6:5], r Reserved
[15:12],
[22:17],
23,
[31:24]
PRSET0
Selective reset assert register for peripherals for Peripherals 0. Write one to assert
selected reset, writing zeros has no effect.
PRSET0
RCU Peripheral 0 Reset Set (0410H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ERU
0 0 0
1RS
r r r w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
USIC DSD VAD
0 F1R F0R 81R 80R 0 42R 41R 40R
0RS RS CRS
S S S S S S S
r w w w w w r w w w w w

XMC4500
XMC4000 Family

VADCRS 0 w VADC Reset Assert
0B No effect
1B Assert reset
DSDRS 1 w DSD Reset Assert
0B No effect
1B Assert reset
CCU40RS 2 w CCU40 Reset Assert
0B No effect
1B Assert reset
0B No effect
1B Assert reset
0B No effect
1B Assert reset
0B No effect
1B Assert reset
0B No effect
1B Assert reset
POSIF0RS 9 w POSIF0 Reset Assert
0B No effect
1B Assert reset
POSIF1RS 10 w POSIF1 Reset Assert
0B No effect
1B Assert reset
USIC0RS 11 w USIC0 Reset Assert
0B No effect
1B Assert reset
ERU1RS 16 w ERU1 Reset Assert
0B No effect
1B Assert reset

XMC4500
XMC4000 Family

0 [6:5], r Reserved
[15:12],
[22:17],
23,
[31:24]
PRCLR0
Selective reset de-assert register for peripherals for Peripherals 0. Write one to de-assert
PRCLR0
RCU Peripheral 0 Reset Clear (0414H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ERU
0 0 0
1RS
r r r w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
USIC DSD VAD
0 F1R F0R 81R 80R 0 42R 41R 40R
0RS RS CRS
S S S S S S S
r w w w w w r w w w w w

VADCRS 0 w VADC Reset Clear
0B No effect
1B De-assert reset
DSDRS 1 w DSD Reset Clear
0B No effect
1B De-assert reset
CCU40RS 2 w CCU40 Reset Clear
0B No effect
1B De-assert reset

XMC4500
XMC4000 Family

0B No effect
1B De-assert reset
0B No effect
1B De-assert reset
0B No effect
1B De-assert reset
0B No effect
1B De-assert reset
POSIF0RS 9 w POSIF0 Reset Clear
0B No effect
1B De-assert reset
POSIF1RS 10 w POSIF1 Reset Clear
0B No effect
1B De-assert reset
USIC0RS 11 w USIC0 Reset Clear
0B No effect
1B De-assert reset
ERU1RS 16 w ERU1 Reset Clear
0B No effect
1B De-assert reset
0 [6:5], r Reserved
[15:12],
[22:17],
23,
[31:24]
PRSTAT1

XMC4500
XMC4000 Family
PRSTAT1
RCU Peripheral 1 Reset Status (0418H) Reset Value: 0000 01F9H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
LED
PPO MCA CCU
USIC USIC MMC DAC TSC
0 RTS N0R 0 43R
2RS 1RS IRS RS U0R
RS S S
S
r r r r r r r r r r

1B Reset asserted
LEDTSCU0RS 3 r LEDTS Reset Status
1B Reset asserted
MCAN0RS 4 r MultiCAN Reset Status
1B Reset asserted
DACRS 5 r DAC Reset Status
1B Reset asserted
MMCIRS 6 r MMC Interface Reset Status
1B Reset asserted
1B Reset asserted
1B Reset asserted

XMC4500
XMC4000 Family

PPORTSRS 9 r PORTS Reset Status
1B Reset asserted
0 [2:1], r Reserved
[31:10]
PRSET1
PRSET1
RCU Peripheral 1 Reset Set (041CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
LED
PPO MCA CCU
0 RTS N0R 0 43R
2RS 1RS IRS RS U0R
RS S S
S
r w w w w w w w r w

0B No effect
1B Assert reset
LEDTSCU0RS 3 w LEDTS Reset Assert
0B No effect
1B Assert reset
MCAN0RS 4 w MultiCAN Reset Assert
0B No effect
1B Assert reset

XMC4500
XMC4000 Family

DACRS 5 w DAC Reset Assert
0B No effect
1B Assert reset
MMCIRS 6 w MMC Interface Reset Assert
0B No effect
1B Assert reset
0B No effect
1B Assert reset
0B No effect
1B Assert reset
PPORTSRS 9 w PORTS Reset Assert
0B No effect
1B Assert reset
0 [2:1], r Reserved
[31:10]
PRCLR1
PRCLR1
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
LED
PPO MCA CCU
0 RTS N0R 0 43R
2RS 1RS IRS RS U0R
RS S S
S
r w w w w w w w r w

XMC4500
XMC4000 Family

0B No effect
1B De-assert reset
LEDTSCU0RS 3 w LEDTS Reset Clear
0B No effect
1B De-assert reset
MCAN0RS 4 w MultiCAN Reset Clear
0B No effect
1B De-assert reset
DACRS 5 w DAC Reset Clear
0B No effect
1B De-assert reset
MMCIRS 6 w MMC Interface Reset Clear
0B No effect
1B De-assert reset
0B No effect
1B De-assert reset
0B No effect
1B De-assert reset
PPORTSRS 9 w PORTS Reset Clear
0B No effect
1B De-assert reset
0 [2:1], r Reserved
[31:10]
PRSTAT2

XMC4500
XMC4000 Family
PRSTAT2
RCU Peripheral 2 Reset Status (0424H) Reset Value: 0000 00F6H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
USB FCE DMA DMA ETH WDT
0 0 0
RS RS 1RS 0RS 0RS RS
r r r r r r r r r

WDTRS 1 r WDT Reset Status
1B Reset asserted
ETH0RS 2 r ETH0 Reset Status
1B Reset asserted
DMA0RS 4 r DMA0 Reset Status
1B Reset asserted
DMA1RS 5 r DMA1 Reset Status
1B Reset asserted
FCERS 6 r FCE Reset Status
1B Reset asserted
USBRS 7 r USB Reset Status
1B Reset asserted
0 0, r Reserved
3,
[31:8]

XMC4500
XMC4000 Family
PRSET2
PRSET2
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0
r w w w w r w w r

WDTRS 1 w WDT Reset Assert
0B No effect
1B Assert reset
ETH0RS 2 w ETH0 Reset Assert
0B No effect
1B Assert reset
DMA0RS 4 w DMA0 Reset Assert
0B No effect
1B Assert reset
DMA1RS 5 w DMA1 Reset Assert
0B No effect
1B Assert reset
FCERS 6 w FCE Reset Assert
0B No effect
1B Assert reset
USBRS 7 w USB Reset Assert
0B No effect
1B Assert reset

XMC4500
XMC4000 Family

0 0, r Reserved
3,
[31:8]
PRCLR2
PRCLR2
RCU Peripheral 2 Reset Clear (042CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0
r w w w w r w w r

WDTRS 1 w WDT Reset Clear
0B No effect
1B De-assert reset
ETH0RS 2 w ETH0 Reset Clear
0B No effect
1B De-assert reset
DMA0RS 4 w DMA0 Reset Clear
0B No effect
1B De-assert reset
DMA1RS 5 w DMA1 Reset Clear
0B No effect
1B De-assert reset
FCERS 6 w FCE Reset Clear
0B No effect
1B De-assert reset

XMC4500
XMC4000 Family

USBRS 7 w USB Reset Clear
0B No effect
1B De-assert reset
0 0, r Reserved
3,
[31:8]
PRSTAT3
Note: Reset release must be effectively prevented for unless module clock is gated or
off in cases where kernel clock and bus interface clocks are shared, in order to
avoid system hang-ups.
PRSTAT3
RCU Peripheral 3 Reset Status (0430H) Reset Value: 0000 0004H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 EBU 0
r r r

EBU 2 r EBU Reset Status
1B Reset asserted
0 [1:0], r Reserved
[31:3]

XMC4500
XMC4000 Family
PRSET3
PRSET3
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 EBU 0
r w r

EBU 2 w EBU Reset Assert
0B No effect
1B Assert reset
0 [1:0], r Reserved
[31:3]
PRCLR3
PRCLR3
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 EBU 0
r w r

XMC4500
XMC4000 Family

EBU 2 w EBU Reset Assert
0B No effect
1B De-assert reset
0 [1:0], r Reserved
[31:3]
11.10.5 CCU Registers
CLKSTAT
Global clock status register.
CLKSTAT
Clock Status Register (0600H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ETH
WDT CCU EBU MMC USB
0 0CS
CST CST CST CST CST
T
r r r r r r r

USBCST 0 r USB Clock Status
0B Clock disabled
1B Clock enabled
MMCCST 1 r MMC Clock Status
0B Clock disabled
1B Clock enabled
ETH0CST 2 r Ethernet Clock Status
0B Clock disabled
1B Clock enabled

XMC4500
XMC4000 Family

EBUCST 3 r EBU Clock Status
0B Clock disabled
1B Clock enabled
CCUCST 4 r CCU Clock Status
0B Clock disabled
1B Clock enabled
WDTCST 5 r WDT Clock Status
0B Clock disabled
Note: WDT clock can be put on hold in debug
mode when this behavior is enabled at
the watchdog
1B Clock enabled
0 [31:6] r Reserved
Read as 0.
CLKSET
Global clock enable register. Write one to enable selected clock, writing zeros has no
effect.
CLKSET
CLK Set Register (0604H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ETH
WDT CCU EBU MMC USB
0 0CE
CEN CEN CEN CEN CEN
N
r w w w w w w

USBCEN 0 w USB Clock Enable
0B No effect
1B Enable

XMC4500
XMC4000 Family

MMCCEN 1 w MMC Clock Enable
0B No effect
1B Enable
ETH0CEN 2 w Ethernet Clock Enable
0B No effect
1B Enable
EBUCEN 3 w EBU Clock Enable
0B No effect
1B Enable
CCUCEN 4 w CCU Clock Enable
0B No effect
1B Enable
WDTCEN 5 w WDT Clock Enable
0B No effect
1B Enable
0 [31:6] r Reserved
Read as 0.
CLKCLR
Global clock disable register. Write one to disable selected clock, writing zeros has no
effect.
CLKCLR
CLK Clear Register (0608H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
WDT CCU EBU ETH MMC USB
0
CDI CDI CDI 0CDI CDI CDI
r w w w w w w

XMC4500
XMC4000 Family

USBCDI 0 w USB Clock Disable
0B No effect
1B Disable clock
MMCCDI 1 w MMC Clock Disable
0B No effect
1B Disable clock
ETH0CDI 2 w Ethernet Clock Disable
0B No effect
1B Disable clock
EBUCDI 3 w EBU Clock Disable
0B No effect
1B Disable clock
CCUCDI 4 w CCU Clock Disable
0B No effect
1B Disable clock
WDTCDI 5 w WDT Clock Disable
0B No effect
1B Disable clock
0 [31:6] r Reserved
Read as 0.
SYSCLKCR
System clock control register.
SYSCLKCR
System Clock Control Register (060CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SYS
0
SEL
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 SYSDIV
r rw

XMC4500
XMC4000 Family

SYSDIV [7:0] rw System Clock Division Value
The value the divider operates is (SYSDIV+1).
SYSSEL 16 rw System Clock Selection Value
0B fOFI clock
1B fPLL clock
CPUCLKCR
CPU clock control register.
CPUCLKCR
CPU Clock Control Register (0610H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CPU
0
DIV
r rw

CPUDIV 0 rw CPU Clock Divider Enable
This bit enables division of fSYS clock to produce fCPU
clock.
0B fCPU = fSYS
1B fCPU = fSYS / 2
Note: Some clock division settings are not allowed.
See Table 11-5 for more details.
0 [31:1] r Reserved

XMC4500
XMC4000 Family
PBCLKCR
Peripheral clock control register.
PBCLKCR
Peripheral Bus Clock Control Register (0614H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PBDI
0
V
r rw

PBDIV 0 rw PB Clock Divider Enable
This bit enables division of fSYS clock to produce
fPERIPH clock.
0B fPERIPH = fCPU
1B fPERIPH = fCPU / 2
0 [31:1] r Reserved
USBCLKCR
USB clock control register.

XMC4500
XMC4000 Family
USBCLKCR
USB Clock Control Register (0618H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
USB
0
SEL
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 USBDIV
r rw

USBDIV [2:0] rw USB Clock Divider Value
PLL clock is divided by USBDIV + 1
Must only be programmed, when clock is not used
USBSEL 16 rw USB Clock Selection Value
0B USB PLL Clock
1B PLL Clock
EBUCLKCR
EBU clock control register.
EBUCLKCR
EBU Clock Control Register (061CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 EBUDIV
r rw

XMC4500
XMC4000 Family

EBUDIV [5:0] rw EBU Clock Divider Value
PLL clock is divided by EBUDIV + 1
0 [31:6] r Reserved
CCUCLKCR
CCUx clock control register.
CCUCLKCR
CCU Clock Control Register (0620H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CCU
0
DIV
r rw

CCUDIV 0 rw CCU Clock Divider Enable
This bit enables division of fSYS clock to produce fCCU
clock.
0B fCCU = fSYS
1B fCCU = fSYS / 2
0 [31:1] r Reserved
WDTCLKCR
System watchdog (WDT) clock control register.

XMC4500
XMC4000 Family
WDTCLKCR
WDT Clock Control Register (0624H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 WDTSEL
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 WDTDIV
r rw

WDTDIV [7:0] rw WDT Clock Divider Value
WDT is divided by WDTDIV + 1
WDTSEL [17:16] rw WDT Clock Selection Value
00B fOFI clock
01B fSTDBY clock
10B fPLL clock
11B Reserved
EXTCLKCR
External clock control register. Use this register to select output clock.

XMC4500
XMC4000 Family
EXTCLKCR
External Clock Control (0628H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 ECKDIV
rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 ECKSEL
rw rw

ECKSEL [1:0] rw External Clock Selection Value
00B fSYS clock
01B fFLASH clock
10B fUSB clock
11B fPLL clock divided according to ECKDIV bit field
configuration
ECKDIV [24:16] rw External Clock Divider Value
PLL clock is divided by ECKDIV + 1
0 [15:2], rw Reserved
[31:25] Read as 0.
SLEEPCR
Configuration register that defines some system behavior aspects while in sleep mode.
The original system state gets restored upon wake-up from sleep mode.

XMC4500
XMC4000 Family
SLEEPCR
Sleep Control Register (0630H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0
CR CR CR 0CR CR CR
r rw rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SYS
0 0
SEL
r r rwh

SYSSEL 0 rwh System Clock Selection Value
0B fOFI clock
1B fPLL clock
USBCR 16 rw USB Clock Control
0B Disable
1B Enable
MMCCR 17 rw MMC Clock Control
0B Disable
1B Enable
ETH0CR 18 rw Ethernet Clock Control
0B Disable
1B Enable
EBUCR 19 rw EBU Clock Control
0B Disable
1B Enable
CCUCR 20 rw CCU Clock Control
0B Disable
1B Enable
WDTCR 21 rw WDT Clock Control
0B Disable
1B Enable
0 1, r Reserved
[15:2], Read as 0.
[31:22]

XMC4500
XMC4000 Family
DSLEEPCR
Configuration register that defines some system behavior aspects while in deep-sleep
mode. The original system state gets restored upon wake-up from sleep mode except
for PLL re-start if enabled before entering deep-sleep mode and configured to go into
power down while in deep-sleep mode.
DSLEEPCR
Deep Sleep Control Register (0634H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0
CR CR CR 0CR CR CR
r rw rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VCO PLL FPD
0 0 SYSSEL
PDN PDN N
r rw rw rw r rwh

SYSSEL [1:0] rwh System Clock Selection Value
0B fOFI clock
1B fPLL clock
FPDN 11 rw Flash Power Down
1B Flash power down module
0B No effect
PLLPDN 12 rw PLL Power Down
1B switch off main PLL
0B No effect
VCOPDN 13 rw VCO Power Down
1B switch off VCO of main PLL
0B No effect
USBCR 16 rw USB Clock Control
0B Disable
1B Enable
MMCCR 17 rw MMC Clock Control
0B Disable
1B Enable

XMC4500
XMC4000 Family

ETH0CR 18 rw Ethernet Clock Control
0B Disable
1B Enable
EBUCR 19 rw EBU Clock Control
0B Disable
1B Enable
CCUCR 20 rw CCU Clock Control
0B Disable
1B Enable
WDTCR 21 rw WDT Clock Control
0B Disable
1B Enable
[15:14], Read as 0.
[31:22]
OSCHPSTAT
Status register of the OSCHP oscillator.
OSCHPSTAT
OSCHP Status Register (0700H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 X1D
r rh

X1D 0 rh XTAL1 Data Value
This bit monitors the value (level) of pin XTAL1. If
XTAL1 is not used as clock input it can be used as
GPI pin.
This bit is only updated if X1DEN is set.

XMC4500
XMC4000 Family

0 [31:1] r Reserved
OSCHPCTRL
Control register of the OSCHP oscillator.
OSCHPCTRL
OSCHP Control Register (0704H) Reset Value: 0000 003CH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 OSCVAL
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SHB X1D
0 MODE 0 0
Y EN
r rw r r rwh rw

X1DEN 0 rw XTAL1 Data Enable
0B Bit X1D is not updated
1B Bit X1D can be updated
SHBY 1 rwh Shaper Bypass
0B The shaper is not bypassed
1B The shaper is bypassed
MODE [5:4] rw Oscillator Mode
00B External Crystal Mode and External Input
Clock Mode. The oscillator Power-Saving
Mode is not entered.
01B OSC is disabled. The oscillator Power-Saving
Mode is not entered.
10B External Input Clock Mode and the oscillator
Power-Saving Mode is entered
11B OSC is disabled. The oscillator Power-Saving
Mode is entered.

XMC4500
XMC4000 Family

OSCVAL [20:16] rw OSC Frequency Value
This bit field defines the divider value that generates
the reference clock that is supervised by the
oscillator watchdog. fOSC is divided by OSCVAL + 1
in order to generate fOSCREF.
0 2,3, r Reserved
[31:21]
PLLSTAT
System PLL Status register.
PLLSTAT
PLL Status Register (0710H) Reset Value: 0000 0002H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VCO PWD VCO
PLL PLL PLL K2R K1R
0 BY 0 LOC STA BYS
SP HV LV DY DY
K T T
r rh rh rh rh rh rh r rh rh rh

VCOBYST 0 rh VCO Bypass Status
0B Free-running / Normal Mode is entered
1B Prescaler Mode is entered
PWDSTAT 1 rh PLL Power-saving Mode Status
0B PLL Power-saving Mode was not entered
1B PLL Power-saving Mode was entered
VCOLOCK 2 rh PLL LOCK Status
0B PLL not locked
1B PLL locked

XMC4500
XMC4000 Family

K1RDY 4 rh K1 Divider Ready Status
This bit indicates if the K1-divider operates on the
configured value or not. This is of interest if the value
is changed.
0B K1-Divider does not operate with the new
value
1B K1-Divider operate with the new value
K2RDY 5 rh K2 Divider Ready Status
This bit indicates if the K2-divider operates on the
configured value or not. This is of interest if the value
is changed.
0B K2-Divider does not operate with the new
value
1B K2-Divider operate with the new value
BY 6 rh Bypass Mode Status
0B Bypass Mode is not entered
1B Bypass Mode is entered. Input fOSC is selected
as output fPLL.
PLLLV 7 rh Oscillator for PLL Valid Low Status Bit
This bit indicates if the frequency output of OSC is
usable for the VCO part of the PLL.
This is checked by the Oscillator Watchdog of the
PLL.
0B The OSC frequency is not usable. Frequency
fREF is too low.
1B The OSC frequency is usable
PLLHV 8 rh Oscillator for PLL Valid High Status Bit
PLL.
0B The OSC frequency is not usable. Frequency
fOSC is too high.

XMC4500
XMC4000 Family

PLLSP 9 rh Oscillator for PLL Valid Spike Status Bit
PLL.
0B The OSC frequency is not usable. Spikes are
detected that disturb a locked operation
0 3, r Reserved
[31:10] Read as 0.
PLLCON0
System PLL configuration register 0.
PLLCON0
PLL Configuration 0 Register (0714H) Reset Value: 0003 0003H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RES OSC PLL
0
LD RES PWD
r w rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
OSC
FIND VCO VCO VCO
0 DISC 0 0
IS TR PWD BYP
DIS
r rw r rwh r rw rw rw

VCOBYP 0 rw VCO Bypass
0B Normal operation, VCO is not bypassed
1B Prescaler Mode, VCO is bypassed
VCOPWD 1 rw VCO Power Saving Mode
0B Normal behavior
1B The VCO is put into a Power Saving Mode and
can no longer be used. Only the Bypass and
Prescaler Mode are active if previously
selected.

XMC4500
XMC4000 Family

VCOTR 2 rw VCO Trim Control
0B VCO bandwidth is operation in the normal
range. VCO output frequency is between 260
and 520 MHz for a input frequency between 8
and 16 MHz.
1B VCO bandwidth is operation in the test range.
VCO output frequency is between 260 and
520 MHz for a input frequency between 8 and
16 MHz.
Selecting a VCO trim value of one can result in a
high jitter but the PLL is still operable.
FINDIS 4 rwh Disconnect Oscillator from VCO
0B connect oscillator to the VCO part
1B disconnect oscillator from the VCO part.
OSCDISCDIS 6 rw Oscillator Disconnect Disable
This bit is used to disable the control FINDIS in a
PLL loss-of-lock case.
0B In case of a PLL loss-of-lock bit FINDIS is set
1B In case of a PLL loss-of-lock bit FINDIS is
cleared
PLLPWD 16 rw PLL Power Saving Mode
0B Normal behavior
1B The complete PLL block is put into a Power
Saving Mode and can no longer be used. Only
the Bypass Mode is active if previously
selected.
OSCRES 17 rw Oscillator Watchdog Reset
This bit controls signal osc_fail_res_i at the PLL
module.
0B The Oscillator Watchdog of the PLL is not
cleared and remains active
1B The Oscillator Watchdog of the PLL is cleared
and restarted
RESLD 18 w Restart VCO Lock Detection
Setting this bit will clear bit PLLSTAT.VCOLOCK
and restart the VCO lock detection.
Reading this bit returns always a zero.

XMC4500
XMC4000 Family

0 3, 5, r Reserved
[31:19]
PLLCON1
PLLCON1
PLL Configuration 1 Register (0718H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 PDIV 0 K2DIV
r rw r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 NDIV 0 K1DIV
r rw r rw

K1DIV [6:0] rw K1-Divider Value
The value the K1-Divider operates is K1DIV+1.
NDIV [14:8] rw N-Divider Value
The value the N-Divider operates is NDIV+1.
K2DIV [22:16] rw K2-Divider Value
The value the K2-Divider operates is K2DIV+1.
PDIV [27:24] rw P-Divider Value
The value the P-Divider operates is PDIV+1.
0 7,15, r Reserved
[31:28]
PLLCON2

XMC4500
XMC4000 Family
PLLCON2
PLL Configuration 2 Register (071CH) Reset Value: 0000 0001H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
K1IN PINS
0 0
SEL EL
r rw r rw

PINSEL 0 rw P-Divider Input Selection
0B PLL external oscillator selected
1B Backup clock fofi selected
K1INSEL 8 rw K1-Divider Input Selection
0B PLL external oscillator selected
1B Backup clock fofi selected
0 [7:1], r Reserved
USBPLLSTAT
USB PLL Status register.
USBPLLSTAT
USB PLL Status Register (0720H) Reset Value: 0000 0002H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VCO VCO PWD VCO
0 LOC BY 0 0 LOC STA BYS
KED K T T
r rh rh r r rh rh rh

XMC4500
XMC4000 Family

VCOBYST 0 rh VCO Bypass Status
0B Normal Mode is entered
1B Prescaler Mode is entered
PWDSTAT 1 rh PLL Power-saving Mode Status
0B PLL Power-saving Mode was not entered
1B PLL Power-saving Mode was entered
VCOLOCK 2 rh PLL VCO Lock Status
0B The frequency difference of fREF and fDIV is
greater than allowed. The VCO part of the PLL
can not lock on a target frequency.
1B The frequency difference of fREF and fDIV is
small enough to enable a stable VCO
operation
Note: In case of a loss of VCO lock the fVCO goes to
the upper boundary of the VCO frequency if
the reference clock input is greater than
expected.
Note: In case of a loss of VCO lock the fVCO goes to
the lower boundary of the VCO frequency if the
reference clock input is lower than expected.
BY 6 rh Bypass Mode Status
0B Bypass Mode is not entered
1B Bypass Mode is entered. Input fOSC is selected
as output fPLL.
VCOLOCKED 7 rh PLL LOCK Status
0B PLL not locked
1B PLL locked
0 3, r Reserved
[5:4], Read as 0.
[31:8]
USBPLLCON
USB PLL configuration register 0.

XMC4500
XMC4000 Family
USBPLLCON
USB PLL Configuration Register (0724H) Reset Value: 0001 0003H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RES PLL
0 PDIV 0 0
LD PWD
r rw r w r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
OSC
FIND VCO VCO VCO
0 NDIV 0 DISC 0 0
IS TR PWD BYP
DIS
r rw r rw r rwh r rw rw rw

VCOBYP 0 rw VCO Bypass
0B Normal operation, VCO is not bypassed
1B Prescaler Mode, VCO is bypassed
VCOPWD 1 rw VCO Power Saving Mode
0B Normal behavior
1B The VCO is put into a Power Saving Mode
VCOTR 2 rw VCO Trim Control
0B VCO bandwidth is operating in the normal
range. VCO output frequency is between 260
and 520 MHz for a input frequency between
8 and 16 MHz.
1B VCO bandwidth is operating in the test range.
VCO output frequency is between 260 and
520 MHz for a input frequency between 8 and
16 MHz.
Selecting a VCO trim value of one can result in a
high jitter but the PLL is still operable.
FINDIS 4 rwh Disconnect Oscillator from VCO
0B Connect oscillator to the VCO part
1B Disconnect oscillator from the VCO part.

XMC4500
XMC4000 Family

OSCDISCDIS 6 rw Oscillator Disconnect Disable
This bit is used to disable the control FINDIS in a
PLL loss-of-lock case.
0B In case of a PLL loss-of-lock bit FINDIS is set
1B In case of a PLL loss-of-lock bit FINDIS is
cleared
NDIV [14:8] rw N-Divider Value
The value the N-Divider operates is NDIV+1.
PLLPWD 16 rw PLL Power Saving Mode
0B Normal behavior
1B The complete PLL block is put into a Power
Saving Mode. Only the Bypass Mode is
active if previously selected.
RESLD 18 w Restart VCO Lock Detection
Setting this bit will clear bit PLLSTAT.VCOLOCK
and restart the VCO lock detection.
Reading this bit returns always a zero.
PDIV [27:24] rw P-Divider Value
The value the P-Divider operates is PDIV+1.
0 3, r Reserved
7,
15,
17,
[23:19],
[31:28]
CLKMXSTAT
Clock Multiplexer Switching Status
This register shows status of clock multiplexing upon switching from one clock source to
another. This register should be checked before disabling any of the multiplexer input
clock sources after switching. Bits of this registers indicate which of the corresponding
input clocks must not be switched off under any circumstances until indicated as inactive.
The clocks sources that are indicated as active are still contributing in driving the output
clock from respective multiplexer. This is a side effect of glitch-free clock switching
mechanism.

XMC4500
XMC4000 Family
CLKMXSTAT
Clock Multiplexing Status Register (0738H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SYSCLKM
0
UX
r rh

SYSCLKMUX [1:0] rh Status of System clock multiplexing upon source
switching
Clock sources that are indicated active are still
contributing in glitch-free switching
x1B fOFI clock active
1xB fPLL clock active
0 [31:2] r Reserved
11.11 Interconnects
The system control unit SCU is connected towards the system via bus interface. The bus
interface provides register access for monitoring and controlling operation of all sub-
modules of the SCU.
A number of signals connected to the submodules os SCU allow monitoring and control
of various aspects of the system. The following tables provide logical grouping of
different signals vital for the SCU module operation.
Table 11-11 GCU Signals

PARITY_ERROR I SRAMs Parity error from on-chip SRAMs

NMI O CPU NMI output
IRQ O CPU Interrupt output

XMC4500
XMC4000 Family
Table 11-11 GCU Signals (contd)

AHB0_BUS_ERR I PBA0 Bus error indication for PBA 0
AHB1_BUS_ERR I PBA1 Bus error indication for PBA 1
SCU_ETH_PHY_ O ETH Used to select the PHY interface
RMII_O from outside Ethernet MAC
during reset of MAC.
G0ORCEN6 O PORTS Enable Out-Of-Range
comparator of VADC kernel 0,
channel 6
channel 7
channel 6
channel 7
DBGEN O Debug Debug enable, driven by
DBGCON0.DAPSA
alarm I RTC RTC alarm
periodic_event I RTC RTC periodic event
Table 11-12 PCU Signals

POWER_STATUS O PORTS Indication of power status to
PORTS
Table 11-13 HCU Signals

HIB_SR0 O Hibernate GPI
Domain

XMC4500
XMC4000 Family
Table 11-13 HCU Signals (contd)

HIB_SR1 O Hibernate GPI
Domain
WWDT_SERVICE_OUT I Hibernate WDT service signal to external
Domain Timeout Watchdog
Table 11-14 RCU Signals

PORST I Core Modules Power-on reset
SYSRESET O Core Modules Reset signals to core modules
STDBYRESET O Hibernate Reset signals to hibernate domain
Domain logic
DBGRESET O DAP Reset signals to debug logic
SYSRSTREQ I CPU Reset request from CPU
wdt_rst_req_n I WDT Reset request from watchdog
module
LOCKUP I CPU Lockup signal from CPU
DBG_PRESENT I Debug Debugger present. Connect to
CDBGPWRUPREQ
Table 11-15 CCU Signals

External Signals
XTAL1/CLKIN I Crystal pin or external clock input
XTAL2 O Crystal pin
EXTCLK O External clock output
Other Signals
SLEEPING I Debug Indicates that processor is in sleep
mode
SLEEPDEEP I Debug Indicates that processor is in
deep sleep mode
System Clock Signals
fSYS O SCU.CCU System master clock

XMC4500
XMC4000 Family
Table 11-15 CCU Signals (contd)

fCPU O CPU CPU and NVIC clock
fDMA O DMA0, DMA1 DMA clock
fPERIPH O PBA0 Peripheral clock for modules
PBA1 connected to peripheral bridges
PBA0 and PBA1
fCCU O CCU4 Clock for CCU4, CCU8 and
CCU8 POSIF modules
POSIF
fUSB O USB UTMI clock of USB
fETH O ETH0 ETH clock
fEBU O EBU EBU clock
fWDT O WDT Clock for independent watchdog
timer
External Clock Signals
fOSCHP I XTAL1/CLKIN External crystal input, optionally
also direct input clock to system
PLL
fOSCULP I RTC_XTAL1 External crystal input, optionally
also direct input clock to Hibernate
domain and RTC module
fEXT O Clock output to Chip output clock
pin EXTCLK

XMC4500
XMC4000 Family

XMC4500
XMC4000 Family
LED and Touch-Sense (LEDTS)
12 LED and Touch-Sense (LEDTS)

The LED and Touch-Sense (LEDTS) drives LEDs and controls touch pads used as
human-machine interface (HMI) in an application.

LEDTS LED and Touch-sense
TSD time slice duration
TFD time frame duration
TPD time period duration
12.1 Overview
The LEDTS can measure the capacitance of up to 8 touch pads using the relaxation
oscillator (RO) topology. The pad capacitance is measured by generating oscillations on
the pad for a fixed time period and counting them. The module can also drive up to 64
LEDs in an LED matrix. Touch pads and LEDs can share pins to minimize the number
of pins needed for such applications. This configuration is realized by the module
controlling the touch pads and driving the LEDs in a time-division multiplexed manner.
The LEDs in the LED matrix are organized into columns and lines. Every line can be
shared between up to 8 LEDs and one touch pad. Certain functions such as column
enabling, function selection and control are controlled by hardware. Application software
is required to update the LED lines and evaluate the touch pad measurement results.
12.1.1 Features
For the LED driving function, LEDTS provides features:
Selection of up to 8 LED columns; Up to 7 LED columns if touch-sense function is
also enabled
Configurable active time in LED columns to control LED brightness
Possibility to drive up to 8 LEDs per column, common-anode or common-cathode
Shadow activation of line pattern for LED column time slice; LED line patterns are
updated synchronously to column activation
Configurable interrupt enable on selected event
Line and column pins controlled by PORTS SFR setting
For the touch-sensing function, LEDTS provides features:
Up to 8 touch-sense input turns
Only one pad can be measured at any time; selection of active pad controllable by
software or hardware round-robin
Flexible measurement time on touch pads
Pin oscillation control circuit with adjustments for oscillation

LEDTS, V 1.5 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
16-bit counter: For counting oscillations at pin

Configurable interrupt enable on selected event
Pin over-rule control for active touch input line (pin)
Note: This chapter refers to the LED or touch-sense pins, e.g. pin COL[x], pin TSIN[x].
In all instances, it refers to the user-configured pin(s) which selects the LED/touch-
sense function. Refer to Section 12.9.5 for more elaboration.
Table 12-2 LEDTS Applications

Use Case Application
Non-mechanical switch HMI
LED feedback HMI
Simple PWM PWM

The LEDTS block diagram is shown in Figure 12-1.

XMC4500
XMC4000 Family
Column Control TS Control

Pad
BUS_CLK prescaler LEDTS counter reload value Select
CLK_PS 3bit 8bit NR_LEDCOL Oscillation
Oscillator
0: no clock Pulse
pad osc Loop
1: clk/1
Internal Compare AND
enable
Counter
... Pad
65535 : clk/65535 Registers
COLLEV Control
AND XOR COL6

COL5
AND XOR
COL4
AND XOR
de- AND XOR COL3
COL2
mux AND XOR
COL1
AND XOR
AND XOR COL0
COLA
AND XOR
Compare mux
Interrupt Control Line Control

TFF (extended) LINE7
ITF_EN time-frame LINE6

TPF
autoscan LINE5
time period P
ITP_EN
O LINE4 LEDs and/or Touch
Internal Line R
time-slice LINE3 Pads
ITS_EN Registers LED
T
output
TSF
value x LINE2
Line mux
ISR LINE1
LEDTS LINE0
Library
Figure 12-1 LEDTS Block Diagram

XMC4500
XMC4000 Family
12.2 Functional Overview

The same pin can support LED & touch-sense functions in a time-multiplexed manner.
LED mode or touch-sense mode can be enabled by hardware for respective function
controls.
Time-division multiplexing is done by dividing the time domain into time slots. This basic
time slot is called a time slice. In one time slice, one LED column is activated or the
capacitance of one touch pad is measured.
A time frame is composed of 1 or more time slices, up to a maximum of eight. There is
one time slice for every LED column enabled. If only LED function is enabled, a time
frame can compose up to 8 LED time slices. However, if touch sense function is enabled,
the last time slice in every time frame is reserved for touch-sense function. This reduces
the maximum number of time slices that can be used for LED function in each time frame
to 7. Only one time slice is used for touch sense function in every time frame. This is
regardless of the number of touch pads enabled.
In each time slice used for LED function, only one LED column is enabled at a time. In
the time slice reserved for touch-sense function, oscillations are enabled and measured
on the pin which is activated. No LED column is active during this time slice. A touch pad
input line (TSIN[x] pin) is active when its pad turn is enabled. If more than one touch pad
input lines are enabled, the enabling and measurement on the touch pads in performed
in a round robin manner. Only one touch pad is measured in every time frame.
The resolution of oscillation measurement can be increased by accumulating oscillation
counts on each touch input line. When enabled by configuration of Accumulate Count
(ACCCNT), the pad turn can be extended on consecutive time frames by up to 16 times.
This also means that the same touch pad will be measured in consecutive time frames.
This control will be handled by hardware. Otherwise it is also possible to enable for
software control where the active pad turn is fully under user control.
The number of consecutive time frames, for which a pad turn has been extended, forms
an extended time frame. When touch-sense function is enabled for automatic hardware
pad turn control, several (extended) time frames make up one autoscan time period
where all pad turns are completed. The time slice duration is configured centrally for the
LED and/or touch-sense functions, using the LEDTS-counter. Refer to the description in
Section 12.3, Section 12.9.3 and Figure 12-4.
If enabled, a time slice interrupt is triggered on overflow of the 8LSBs of the LEDTS-
counter for each new time slice started. The (extended) time frame interrupt may also be
enabled. It is triggered on (the configured counts of) overflow of the whole LEDTS-
counter. The autoscan time period interrupt may also be enabled. However, this interrupt
will require that the hardware pad turn control is enabled. It is triggered when hardware
completes the last pad turn on the highest enabled touch input line TSIN[NR_TSIN].
The column activation and pin oscillation duty cycles can be configured for each time
slice. This allows the duration of activation of LED columns and/or touch-sense

XMC4500
XMC4000 Family
oscillation counting to be flexible. This is also how the relative brightness of the LEDs
can be controlled. In case of touch pads, the activation time is called the oscillation
window.
Figure 12-1 shows an example for a LED matrix configuration with touch pads. The
configuration in this example is 8 X 4 LED matrix with 4 touch input lines (here: 6
touchpads with two being dual-pad) enabled in sequence by hardware. Here no pad
turn is extended by ACCCNT, so four time frames complete an autoscan time period.
In the time slice interrupt, software can:
set up line pattern for next time slice
set up compare value for next time slice
evaluate current function in time slice (especially for analysis/debugging)
Refer to Section 12.9.1 for Interpretation of Bit Field FNCOL to determine the
currently active time slice.
The (extended) time frame interrupt indicates one touch input line TSIN[x] has been
sensed (once or number of times in consecutive frames), application-level software can,
for example:
start touch-sense processing (e.g. filtering) routines and update status
update LED display data to SFR
In the autoscan time period interrupt which indicates all touch-sense input TSIN[x] have
been scanned one round, application-level software can:
evaluate touch detection result & action
update LED display data to SFR

XMC4500
XMC4000 Family
Autoscan Time Period
Frame 0 Frame 1 Frame 2 Frame 3

time frame time frame interrupt
interrupt +
autoscan time period interrupt
C3 C2 C1 C0 TS C3 C2 C1 C0 TS C3 C2 C1 C0 TS C3 C2 C1 C0 TS
ledts _fn
COLA
pad _turn_0
pad _turn_1
pad _turn_2
pad _turn_3
COL3
COLLEV = 0
COL2
COL1
COL0
line_3
line_2
line_1
line_0
line_A
LED function LED function Touch-sense function LED function

LED first column active - LED last column active - Oscillat ion active on pin with Repeat control on LED first
SW: Executions wrt time slice /time SW: Executions wrt time slice active turn - column in new time period-
frame interrupt. interrupt. SW: Executions wrt time slice SW: Executions wrt time slice /
HW: On compare match, LED HW: On compare match, LED interrupt. time frame/autoscan time
column is de-activated. column is de-activated. HW: LED columns at inactive period interrupt.
HW: On time slice event, activate HW: On time slice event, activate level. ...
line pattern & compare value for (line pattern&) compare value for HW: On compare match, enable
next time slice (LED column 2). next time slice (touch-sense). pin oscillation . Oscillations are
counted.
HW: On time slice event, activate
line pattern & compare value for
next time slice (1st column).
Disable pin oscillation .
HW/SW: Update bit PADT for next
pad turn.
Figure 12-2 Time-Multiplexed LEDTS Functions on Pin (Example)

XMC4500
XMC4000 Family
12.3 LED Drive Mode

LED driving is supported mainly for LED column selection and line control. At one time,
only one column is active. The corresponding line level at high or low determines if the
associated LED on column is lit or not. Up to eight columns are supported, and up to
eight LEDs can be controlled per column.
With direct LED drive, adjustment of luminence for different types of LEDs with different
forward voltages is supported. A compare register for LEDTS-counter is provided so that
the duty cycle for column enabling per time slice can be adjusted. The LED column is
enabled from the beginning of the time slice until compare match event. For 100% duty
cycle for LED column enable in time slice, the compare value should be set to FFH. If
the compare value is set to 00H, the LED column will stay at passive level during the time
slice. Update of the internal compare register for each time slice is by shadow transfer
from the corresponding compare SFR which takes place automatically at the beginning
of each time slice, refer Figure 12-3.
A similar shadow transfer mechanism to update the LED line pattern (LED enabling) per
column (time slice) is also provided, as illustrated in Figure 12-3. This shadow transfer
of the corresponding line pattern to the internal line SFR takes place automatically at the
beginning of each new time slice.
Note: Any write to any compare or line SFR within the time slice does not affect the
internal latched configuration of current time slice.
(Control (Control
signals ) signals )
Time Slice Time Slice

CMP_TS0 Event Event
.
.
. LINE_A
LINE_0
COMPARE
LINE MUX
CMP_TS7 Internal Internal

.
MUX
CMP_LDA_TSCOM Compare Line

.
CMP_LD0 Register Register
.
.
. LINE_6
.
CMP_LD6
Definition : Definition :
CMP_TS[x] = Compare for touch -sense TSIN[x] LINE_A = Output on LINE[x] pins when LED COLA or touch -sense time slice active
CMP_LD [y] = Compare for LED COL [y] LINE_[y] = Output on LINE [x] pins when LED COL [y] active
CMP_LDA /TSCOM = Compare for LED COLA or touch -sense common
compare value for all TSIN [x]
Note: If TSCCMP bit is enabled , then CMP _TS[x] will never be referenced .
Figure 12-3 Activate Internal Compare/Line Register for New Time Slice
When the LEDTS-counter is first started (enable input clock by CLK_PS), a shadow
transfer of line pattern and compare value is activated for the first time slice (column).

XMC4500
XMC4000 Family
A time slice interrupt can be enabled. A new time slice starts on the overflow of the
8LSBs of the LEDTS-counter.
Figure 12-4 shows the LED function control circuit. This circuit also provides the control
for enabling the pad oscillator. A 16-bit divider provides pre-scale possibilities to flexibly
configure the internal LEDTS-counter count rate, which overflows in one time frame at
the end. During a time frame comprising a configurable number of time slices, the
configured number of LED columns are activated in sequence. In the last time slice of
the time frame, touch-sense function is activated if enabled.
The LEDTS-counter is started when bit CLK_PS is set to any value other than 0 and
either the LED or touch-sense function is enabled. It does not run when both functions
are disabled. To avoid over-write of function enable which disturbs the hardware control
during LEDTS-counter running, the TS_EN and LD_EN bits can only be modified when
bit CLK_PS = 0. It is nonetheless possible to set the bits TS_EN and LD_EN in one
single write to SFR GLOBCTL when setting CLK_PS from 0 to 1, or from 1 to 0.
When started, the counter starts running from a reset/reload value based on enabled
function(s): 1) the number of columns (bit-field NR_LEDCOL) when LED function is
enabled, 2) add one time slice at end of time frame when touch-sense function is
enabled. The counter always counts up and overflows from 7FFH to the reload value
which is the same as the reset value. Within each time frame, the sequence of LED
column enabling always starts from the most-significant enabled column (column with
highest numbering).
To illustrate this point, in the case of four LED columns enabled, the column enabling
sequence will be as follows:
Start with COL3,
followed by COL2,
followed by COL1,
followed by COL0,
then COLA for touch sense function.
If touch-sense function is not enabled, COLA will be available for LED function as the
last LED column time slice of a time frame. The column enabling sequence will then be
as follows:
Start with COL2,
followed by COL1,
followed by COL0,
then COLA.

XMC4500
XMC4000 Family
No. time slice per time frame =

No. LE D Column & & LD_E N + 1 Touch-sense & & TS _E N
NR_LE DCOL : LE DTS counter reset/ reload value (in case of TS _E N = 0)
ledts_clk CLK_PS LEDTS-Counter 000 B: 700 H 010 B : 500 H 100 B : 300 H 110 B: 100 H
prescaler
001 B: 600 H 011 B : 400 H 101 B : 200 H 111B: 000 H
(16-bit)
8-bit compare On compare On 8-bit
0: No clock
reg. match overflow
1: /1
n: /n & Enable pin oscillation *
...
OR
65535 : / 111 B
65535 & ^ COLA *
110 B
& ^ COL0
101 B
& ^ COL1
100 B
de- & ^ COL2
011 B
mux & ^ COL3
010 B
& ^ COL4
001 B
& ^ COL5
000 B
& ^ COL6
CA/
C6 C5 C4 C3 C2 C1 C0
COLLEV = 1 TS*
* If touch-sense function is enabled , this time

slice is reserved for pin osc . enabling and LED
Activate corresponding compare column control is not available .
value & line pattern for next time slice For touch-sense function , pin COLA may be
configured to enable external pull -up not
shown here .
Time slice
Interrupt
(Extended )
Counter overflow count= & Time frame
Accumulate count Interrupt
Figure 12-4 LED Function Control Circuit (also provides pad oscillator enable)
In Section 12.9.3, the time slice duration and formulations for LEDTS related timings are
provided.
12.3.1 LED Pin Assignment and Current Capability

One LED column pin is enabled within each configured time slice duration to control up
to eight LEDs at a time. The assignment of COL[x] to pins is configurable to provide
options for application pin usage. The current capability of device pins is also a
consideration factor for deciding pin assignment to LED function.
The product data-sheet provides data for all I/O parameters relevant to LED drive.
12.4 Touchpad Sensing

Figure 12-5 shows the pin oscillation control unit, which is integrated with the standard
PORTS pad. An active pad turn (pad_turn_x) is defined for the touch-sense input pin
TSIN[x] as the duration within the touch-sense time slice where the TS-counter is
counting oscillations on the pin. In case of hardware pad turn control enabled (default),
the same TS-counter is connected sequentially on enabled touch-sense inputs to
execute a round-robin touch-sensing of TSIN[x] pins.

XMC4500
XMC4000 Family
COLA
enable external pull- up
enable pad oscillator
pad_turn_num
&
pad_turn_x counter reset on start of1st
pad turn on new TSIN[x]
TSIN[x]
write,
16-bit TS-counter
read
active- (Extended) Time
Sensor Pad
extend Frame event
ledts_extended read
Shadow TS -counter
s tandard P ORTS pad
Figure 12-5 Touch-Sense Oscillator Control Circuit

Example in case of four touch-sense inputs, in ordered sequence of touch-sense time
slice in sequential frames:
Always start with TSIN0,
followed by TSIN1 in touch-sense time slice of next frame,
followed by TSIN2 in next touch-sense time slice,
then TSIN3, and repeat.
It is possible to enable the touch-sense time slice on the same touch-sense input for
consecutive frames (up to 16 times), to accumulate the oscillation count in TS-counter
(see Figure 12-6). To illustrate this point, in the same case of four touch input lines
enabled, and 2 accumulation counts configured, is as follows:
Always starts with TSIN0,
followed by TSIN0 again in touch-sense time slice of next frame,
then TSIN3 again, and repeat cycle.

XMC4500
XMC4000 Family
auto scan period

extended frame
3 2 1 0 TS 3 2 1 0 TS
... ... ... ...
... ... ... ...
... ... ... ...
... ... ... ...
Figure 12-6 Hardware-Controlled Pad Turns for Autoscan of Four TSIN[x] with
Extended Frames
There is a 16-bit TS-counter register and there is a 16-bit shadow TS-counter register.
The former is both write- and read-accesible, while the latter is only read-accessible. The
actual TS-counter counts the latched number of oscillations and can only be written
when there is no active pad turn. The content of the TS-counter is latched to the shadow
register on every (extended) time frame event. Reading from the shadow register
therefore shows the latest valid oscillation count on one TSIN[x] input, ensuring for the
application SW there is at least one time slice duration to get the valid oscillation count
and meanwhile the actual TS-counter could continually update due to enabled pin
oscillations in current time slice.
The TS-counter and shadow TS-counter have another user-enabled function on
(extended) time frame event, which is to validate the counter value differences. When
this function is enabled by the user and in case the counter values do not differ by 2n LSB
bits (n is configurable), the (extended) time frame interrupt request is gated (no
interrupt) and the time frame event flag TFF is not set. This gating is on top of the time
frame interrupt enable/disable control.
The TS-counter may be enabled for automatic reset (to 00H) on the start of a new pad
turn on the next TSIN[x], i.e. resets in the first touch-sense time slice of each (extended)
time frame. Bit TSCTROVF indicates that the counter has overflowed. Alternatively, it
can be configured such that the TS-counter stops counting in touch-sense time slice(s)
of the same extended frame when the count value saturates, i.e. does not overflow &
stops at FFFFH. In this case, the TS-counter starts running again only in a new
(extended) frame on the start of a new pad turn on the next TSIN[x].
A configurable pin-low-level active extension is provided for adjustment of oscillation per
user system. The extension is active during the discharge phase of oscillation, and can
be configured to be extended by a number of peripheral clocks. This function is very
useful if there is a series resistor between the pin and the touch pad which makes the
discharge slower. Figure 12-7 illustrates this function.
The configuration of the active touch-sense pin TSIN[x] is over-ruled by hardware in the
active duration to enable oscillations, reference Section 12.9.5. In particular, the weak

XMC4500
XMC4000 Family
internal pull-up enable over-rule can be optionally de-activated (correspondingly internal

pull-down disable over-rule is also de-activated; PORTS pin SFR setting for pull applies
instead), such as when the user system utilize external resistor for pull-up instead. In the
whole duration of the touch-sense time slice, COLA is activated high. This activates a
pull-up via an external resistor connected to pin COLA. This configuration provides some
flexibility to adjust the pin oscillation rate for adaptation to user system.
The touch-sense function is time-multiplexed with the LED function on enabled
LINE[x]/TSIN[x] pins. During the touch-sense time slice for the other TSIN pins which are
not on active pad turn, the corresponding LINE[x] output remains active. Software should
take care to set the line bits to 1 to avoid current sink from pin COLA.
The touch-sense function is active in the last time slice of a time frame. Refer to
Section 12.2, and Section 12.3 for more details on time slice allocation and
configuration.
TS-counter input
Input high
threshold
ledts _extended
Input high
threshold
pin oscillation
Input high
threshold
Input low
threshold
Figure 12-7 Pin-Low-Level Extension Function

XMC4500
XMC4000 Family
The oscillation is enabled on the pin with valid turn for a configurable duration. A
compare value provides the means to adjust the duty cycle within the time slice. The pin
oscillation is enabled (TS-counter is counting) only on compare match until the end of
the time slice. The time interval, in which the TS-counter is counting, is called the
oscillation window. For a 100% duty cycle, the compare value has to be set to 00H. In
this case, the oscillation window fills in the entire time slice. Setting the compare value
to FFH results in no pin oscillation in time slice.
The time slice interrupt, (extended) time frame interrupt and/or autoscan time period
interrupt may be enabled as required for touch-sense control.
12.4.1 Finger Sensing

When a finger is placed on the sensor pad, it increases the pin capacitance and
frequency of oscillation on pin is reduced. Various factors affect the oscillation frequency
including the size of touch pad, ground planes around and below the pad, the material
and thickness of the overlay cover, the trace length and the individual pin itself (every pin
has a different pull-up resistance).
In a real-world application, the printed circuit board (PCB) will not be touched directly.
Instead, there is usually some sort of a transparent cover material, like a piece of
plexiglass sheet, glued onto the PCB. In most of these applications, the oscillation
frequency will change by about 2-10% when touched. This change in oscillation
frequency can be considered to be very small, and therefore, further signal processing
is necessary for reliable detection. Typically, this processing takes the form of a moving
average calculation. It is never recommended to try to detect touches based on the raw
oscillation count value.
As described in above section, some flexibility is provided to adjust the oscillation
frequency in the user system: 1) Configurable pin low-level active extension, 2)
Alternative enabling of external pull-up with resistance selectable by user. With a
configurable time slice duration, the software can configure the duration of the active pad
turn (adjustable within time slice using compare function) and set a count threshold for
oscillations to detect if there is a finger touch or not.
To increase touch-sensing oscillation count accuracy, the input clock to LEDTS kernel
should be set as high as possible.
12.5 Operating both LED Drive and Touch-Sense Modes

It is possible to enable both LED driving and touch-sense functions in a single time
frame. If both functions are enabled, up to 7 time slices are configurable for the LED
function, and the last time slice is reserved for touch-sensing function.
The touch-sense function is time-multiplexed with the LED function on enabled
LINE[x]/TSIN[x] pins. During the touch-sense time slice (COLA), the corresponding
LINE[s] output remains active for the other TSIN pins which are not on active pad turn.

XMC4500
XMC4000 Family
In a typical application, COLA is not used and the oscillation is generated by the internal
pad structure only. The bits in LINE_A will determine whether the pads, that are not being
measured in the given COLA time slice, have a floating or 0V value. This setting usually
has a serious effect on the sensitivity and noise robustness of the touch pads.
Refer to Section 12.2 and Section 12.3 for more details on time slice allocation and
configuration.

There are three interrupts triggered by LEDTS kernel, all assigned on same node: 1)
time slice event, 2) (extended) time frame event, 3) autoscan time period event. The
flags are set on event or when CLK_PS is set from 0 regardless of whether the
corresponding interrupt is enabled or not. When enabled, the event (including setting of
CLK_PS from 0) activates the SR0 interrupt request from the kernel.
Table 12-3 lists the interrupt event sources from the LEDTS, and the corresponding
event interrupt enable bit and flag bit.
Table 12-3 LEDTS Interrupt Events

Event Event Interrupt Enable Bit Event Flag Bit
Start of Time Slice GLOBCTL.ITS_EN EVFR.TSF
Start of (Extended) Time GLOBCTL.ITF_EN EVFR.TFF
Frame1)
Start of Autoscan Time GLOBCTL.ITP_EN EVFR.TPF
Period
1) In case of consecutive pad turns enabled on same TSIN[x] pin by ACCCNT bit-field, interrupt is not triggered
on a time frame but on the extended time frame.
Table 12-4 shows the interrupt node assignment for each LEDTS interrupt source.
Table 12-4 LEDTS Events Interrupt Node Control

Event Interrupt Node Interrupt Node Flag Node ID
Enable Bit Bit
Start of Time Slice LEDTS0.SR0 LEDTS0.SR0 102
Start of (Extended) Time
Frame
Start of Autoscan Time Period

XMC4500
XMC4000 Family
12.7 Debug Behavior

The LEDTS timers/counters LEDTS-counter and TS-counter can be enabled (together)
for suspend operation when debug mode becomes active (indicated by HALTED signal
from CPU).
At the onset of debug suspend, these counters stop counting (retains the last value) for
the duration of the device in debug mode. The function that was active in current time
slice on the onset of debug suspend, continues to be active. When debug suspend is
revoked, the kernel would resume operation according to latest SFR settings.

The LEDTS kernel is clocked and accessible on the peripheral bus frequency. User
should set up consistent time-slice durations for correct function by ensuring a constant
frequency input clock when the kernel is in operation. It is recommended to set the input
clock ledts_clk to highest frequency where possible for optimal touch-sensing accuracy.
Kernel is in operation in active mode except power-down modes where touch-sensing
and LED functions are not available.
12.9 Initialisation and System Dependencies

This section provides hints for enabling the LEDTS functions and using them.
12.9.1 Function Enabling

It is recommended to set up all configuration for the LEDTS in all SFRs before write
GLOBCTL SFR to enable and start LED and/or touch-sense function(s).
Note: SFR bits especially affecting the LEDTS-counter configuration for LED/touch-
sense function can only be written when the counter is not running i.e.
CLK_PS = 0. Refer to SFR bit description Section 12.10.
Enable LED Function Only

To enable LED function only: set LD_EN, clear TS_EN.
Initialization after reset:
MOV GLOBCTL, #0bXXXXXXXX XXXXXXXX XXX00000 0000XX10
;set LD_EN and start LEDTS-counter on prescaled clock
;(CLK_PS != 0)
Re-configuration during run-time:
MOV GLOBCTL, #0x0000X00X;stop LEDTS-counter by clearing prescaler

XMC4500
XMC4000 Family
Enable Touch-Sense Function Only

To enable touch-sense function only: clear LD_EN, set TS_EN.
;set TS_EN and start LEDTS-counter on prescaled clock
;(CLK_PS != 0)
Enable Both LED and Touch-Sense Function

To enable both functions: set LD_EN, set TS_EN.
MOV GLOBCTL, #XXXXXXXX XXXXXXXX XXX00000 0000XX11
;set TS_EN and start LEDTS-counter on prescaled clock
;(CLK_PS != 0)
12.9.2 Interpretation of Bit Field FNCOL

The interpretation of the FNCOL bit field can be handled by software. The following
example where six time slices are enabled (per time frame), with five LED columns and
touch-sensing enabled, illustrates this (Table 12-5).
The FNCOL bit field provides information on the function/column active in the previous
time slice. With this information, software can determine the active function/column in
current time slice and prepare the necessary values (to be shadow-transferred) valid for
the next time slice.
Referring to the example below, when the FNCOL bit field is 111B, it can be derived that
the touch-sensing function/column was active in the previous time slice and therefore the
current active column is LED COL[4]. Hence, the software can update the shadow line
and compare registers for LED COL[3] so that these changes will be reflected when LED
COL[3] gets activated in the next time slice.

XMC4500
XMC4000 Family
Table 12-5 Interpretation of FNCOL Bit Field

FNCOL Active Function / Column in SW Prepare via Shadow Registers for
Current Time Slice Function / Column of Next Time Slice
111H LED COL[4] LED COL[3]
101H LED COL[0] Touch Input Line TSIN[PADT]
110H Touch Input Line TSIN[PADT] LED COL[4]
12.9.3 LEDTS Timing Calculations

LEDTS main timing or duration formulation are provided in following.
Count-Rate (CR):
CR = ( fCLK ) ( PREscaler ) (12.1)
where fCLK = LEDTS module input clock; PREscaler = GLOBCTL.CLK_PS

Time slice duration (TSD):
TSD = 2 8 ( CR ) (12.2)
Time frame duration (TFD):
TFD = ( Number of time slices ) TSD (12.3)
Extended TFD:
ExtendedTFD = ACCCNT TFD (12.4)
where ACCCNT = FNCTL.ACCCNT

Autoscan time period duration (TPD):
TPD = ( Number of touch-sense inputs TSIN[x] ) TFD (12.5)
LED drive active duration:
LED Drive Active Duration = TSD Compare_VALUE 2 8 (12.6)
Touch-sense drive active duration:
Touch-sense Drive Active Duration = TSD ( 2 8 Compare_VALUE ) 2 8 (12.7)

XMC4500
XMC4000 Family
12.9.4 Time-Multiplexed LED and Touch-Sense Functions on Pin

Some hints are provided regarding the time-multiplexed usage of a pin for LED and
touch-sense function:
The maximum number of LED columns = 7 when touch-sense function is also
enabled.
If enabled by pin, COLA outputs HIGH to enable external R (resistor) as pull-up for
touch-sense function.
During touch-sense time slice, it is recommended to set LED lines to output LOW.
During LED time slice, COLA outputs LOW and will sink current if connected lines
output HIGH.
The effective capacitance for each TSIN[x] depends largely on what is connected to
the pin and the application board layout. All touch-pads for the application should be
calibrated for robust touch-detection.
12.9.5 LEDTS Pin Control

The user may flexibly assign pins as provided by PORTS SFRs, for the LEDTS
functions:
COL[x] (for LED column control)
LINE[x] (for LED line control)
TSIN[x] (for touch-sensing)
Refer also to Section 12.3 for more considerations with regards to which COL[x] and/or
LINE[x]/TSIN[x] will be active based on user configuration.
User code must configure the assigned LED pin PORTS SFR alternate output selection
for the LED function, see Table 12-6 and Figure 12-8.
For the touch-sense function, it is also required to configure the PORTS SFRs to enable
the hardware function on TSIN[x] pin (similarly alternate output COLA). However, the
LEDTS will provide some pin over-rule controls to the assigned touch-sense pin with
active pad turn, see Table 12-6 and Figure 12-8.
Table 12-6 LEDTS Pin Control Signals

Function ld/ts_en ledts_fn Pin Control of Assigned Pin
LED LD_EN 0 = LED Enable COL[x]; PORTS SFR setting
column =1 Passive level on
COL[the rest].
If TS_EN = 1,
COLA = 0.

XMC4500
XMC4000 Family
Table 12-6 LEDTS Pin Control Signals (contd)

Function ld/ts_en ledts_fn Pin Control of Assigned Pin
LED line LD_EN 0 = LED LINE[x] = internal line PORTS SFR setting
=1 register value latched
from bit field LINE_[x]
Touch- TS_EN 1= Enable TSIN[x] for Hardware over-rule on
sense =1 Touch- oscillation. pad_turn_x1) for active
sense All other TSIN pins duration:
output line value. - Enable pull-up, disable pull-
down (pull over-rule can be
Passive level on disabled by bit EPULL)
COL[the rest] except - Set to output mode (both
COLA = 1. input, output stages enabled)
- Enable open-drain
1) For the other pad inputs not on turn, there is no HW over-rule which means the PORTS SFR setting is active.

XMC4500
XMC4000 Family
HWS E L
HW S elect
(Touch -sense time slice active ) AND (Pad turn on pin )
Touch -sense disable pull over -rule
Touch -sense pull -up enable , pull -down disable

1
IOCR 0
P ull Control
Touch -sense open -drain enable

1
IOCR
Definition : Open Drain 0
Control
P ORTS function Touch -sense output & input drivers enable

by S FR control 1
IOCR
LE DTS output signal Direction 0
Control
HWS E L
HW S elect
(Touch-sense time slice active ) AND (Pad turn on pin )
IOCR
A lternate Output
S elect
Pull
Device
LED line output ALT[LED]
ALT[x] Output
M Driver
Touch -sense HW_OUT[LED ] U
output Pin
X
Data OUT LED line /

Input Touch-sense pad x
Driver
Schmitt
Trigger
Pad
Figure 12-8 Over-rule Control on Pin for Touch-Sense Function
12.9.6 Software Hints

This section provides some useful software hints:
Compare value 00H enables oscillation for the full duration of the time slice, whereas
FFH disables oscillation.
In order to maximize the resolution of the oscillation window, compare value should
be selected to maximize the oscillation count without overflowing the TS-counter.
Valid pad detection period (the time required to detect a valid touch on a pad) can be
extended by:
enabling dummy LED columns (without assigning/setting the LED column pins)
selecting bigger pre-scale factor (GLOBCTL.CLK_PS)

XMC4500
XMC4000 Family
accumulating the number of pad oscillations (FNCTL.ACCCNT)

Valid pad detection period can be reduced by:
selecting smaller pre-scale factor (GLOBCTL.CLK_PS)
reducing the number of accumulations for pad oscillations (FNCTL.ACCCNT)
12.9.7 Hardware Design Hints

This section provides some hardware design hints:
Touch button oscillation frequency changes when the value of the external pull-up
resistor (connected to COLA pin) changes. This results in different sensitivity of the
touch button as well as the crosstalk between the adjacent touch buttons.
A suitable pull-up resistor should be selected to balance the sensitivity of the touch
button and the accuracy of the detection.
The presence of LEDs modifies the equivalent capacitance for a touch pad. A larger
number of LEDs connected to a touch pad will increase the self-capacitance of the
pad. This makes the pad less sensitive.
If possible, LEDs should be located near to the touch pads, to reduce the additional
parasitic capacitance introduced by the traces.

XMC4500
XMC4000 Family
12.10 Registers
Registers Overview

LEDTS0 4801 0000H 4801 00FFH
The prefix LEDTSx_ is added to the register names in this table to indicate they belong
to the LEDTS kernel.
Access rights within the address range of an LEDTS kernel:
Read or write access to defined register addresses: U, PV
Accesses to empty addresses: nBE
Table 12-8 Register Overview of LEDTS

ID Module Identification 0000H U, PV U, PV Page 12-23
Register
GLOBCTL Global Control Register 0004H U, PV U, PV Page 12-24
FNCTL Function Control Register 0008H U, PV U, PV Page 12-26
EVFR Event Flag Register 000CH U, PV U, PV Page 12-29
TSVAL Touch-Sense TS-Counter 0010H U, PV U, PV Page 12-31
Value
LINE0 Line Pattern Register 0 0014H U, PV U, PV Page 12-32
LINE1 Line Pattern Register 1 0018H U, PV U, PV Page 12-32
LDCMP0 LED Compare Register 0 001CH U, PV U, PV Page 12-33
LDCMP1 LED Compare Register 1 0020H U, PV U, PV Page 12-34
TSCMP0 Touch-Sense Compare 0024H U, PV U, PV Page 12-35
Register 0

XMC4500
XMC4000 Family
Table 12-8 Register Overview of LEDTS (contd)

TSCMP1 Touch-Sense Compare 0028H U, PV U, PV Page 12-35
Register 1
Reserved Reserved 002CH nBE nBE
-
1FFCH

The LEDTS SFRs are organized into registers for global initialization control, functional
control comprising TS-counter value, line pattern and compare value registers.
ID
The module identification register indicate the function and the design step of the
peripheral.
ID
Module Identification Register (0000H) Reset Value: 00AB C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MOD_NUMBER
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MOD_TYPE MOD_REV
r r

MOD_REV defines the revision number. The value
of a module revision starts with 01H (first revision).
module.

XMC4500
XMC4000 Family

MOD_NUMBE [31:16] r Module Number Value
R This bit field defines the module identification
number.
GLOBCTL
The GLOBCTL register is used to initialize the LEDTS global controls.
GLOBCTL
Global Control Register (04H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CLK_PS
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ENS LD_
ITP_ ITF_ ITS_ FEN SUS CMT TS_
MASKVAL 0 YNC EN1)
EN EN EN VAL CFG R1)0 EN
1)0 0
rw rw rw rw rw rw r rw rw rw rw

TS_EN1) 0 rw Touch-Sense Function Enable
Set to enable the kernel for touch-sense function
control when CLK_PS is set from 0.
LD_EN1) 1 rw LED Function Enable
Set to enable the kernel for LED function control
when CLK_PS is set from 0.
CMTR1) 2 rw Clock Master Disable
0B Kernel generates its own clock for LEDTS-
counter based on SFR setting
1B LEDTS-counter takes its clock from another
master kernel
ENSYNC1) 3 rw Enable Autoscan Time Period Synchronization
0B No synchronization
1B Synchronization enabled on Kernel0 autoscan
time period

XMC4500
XMC4000 Family

SUSCFG 8 rw Suspend Request Configuration
0B Ignore suspend request
1B Enable suspend according to request
This bit is restored to default with Debug Reset.
MASKVAL [11:9] rw Mask Number of LSB Bits for Event Validation
This defines the number of LSB bits to mask for TS-
counter and shadow TS-counter comparison when
Time Frame validation is enabled.
0D Mask LSB bit
1D Mask 2 LSB bits
...
7D Mask 8 LSB bits
FENVAL 12 rw Enable (Extended) Time Frame Validation
When enabled, TS-counter and shadow TS-counter
values are compared to validate a Time Frame event
for set flag and interrupt request. When validation
fail, TFF flag does not get set and interrupt is not
requested.
0B Disable
1B Enable
ITS_EN 13 rw Enable Time Slice Interrupt
0B Disable
1B Enable
ITF_EN 14 rw Enable (Extended) Time Frame Interrupt
0B Disable
1B Enable
ITP_EN 15 rw Enable Autoscan Time Period Interrupt
0B Disable
1B Enable (valid only for case of hardware-
enabled pad turn control)

XMC4500
XMC4000 Family

CLK_PS [31:16] rw LEDTS-Counter Clock Pre-Scale Factor
The constant clock input is prescaled according to
setting.
0D No clock
1D Divide by 1
...
65535DDivide by 65535
This bit can only be set to any other value (from 0)
provided at least one of touch-sense or LED function
is enabled. The LEDTS-counter starts running on the
input clock from reset/reload value based on enabled
function(s) (and NR_LEDCOL). Refer Section 12.3
for details.
When this bit is clear to 0 from other value, the
LEDTS-counter stops running and resets.
0 [7:4] r Reserved
1) This bit can only be modified when bit CLK_PS = 0.
FNCTL
The FNCTL control register provides control bits for the LED and Touch Sense functions.
FNCTL
Function Control Register (08H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TSC
COL TSC TSC
NR_LEDCOL NR_TSIN TRS TSOEXT ACCCNT
LEV TRR CMP
AT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EPU PAD
0 FNCOL PADT
LL TSW
r rh rw rw rwh

XMC4500
XMC4000 Family

PADT [2:0] rwh Touch-Sense TSIN Pad Turn
This is the TSIN[x] pin that is next or currently active
in pad turn. When PADTSW = 0, the value is updated
by hardware at the end of touch-sense time slice.
Software write is always possible.
0D TSIN0
...
7D TSIN7
PADTSW1) 3 rw Software Control for Touch-Sense Pad Turn
0B The hardware automatically enables the
touch-sense inputs in sequence round-robin,
starting from TSIN0.
1B Disable hardware control for software control
only. The touch-sense input is configured in bit
PADT.
EPULL 4 rw Enable External Pull-up Configuration on Pin
COLA
When set, the internal pull-up over-rule on active
touch-sense input pin is disabled.
0B HW over-rule to enable internal pull-up is
active on TSIN[x] for set duration in touch-
sense time slice. With this setting, it is not
specified to assign the COLA to any pin.
1B Enable external pull-up: Output 1 on pin COLA
for whole duration of touch-sense time slice.
Note: Independent of this setting, COLA always
outputs 1 for whole duration of touch-sense
time slice.
FNCOL [7:5] rh Previous Active Function/LED Column Status
Shows the active function / LED column in the
previous time slice. Updated on start of new time-
slice when LEDTS-counter 8LSB over-flows.
Controlled by latched value of the internal DE-MUX,
see Figure 12-4.

XMC4500
XMC4000 Family

ACCCNT1) [19:16] rw Accumulate Count on Touch-Sense Input
Defines the number of times a touch-sense input/pin
is enabled in touch-sense time slice of consecutive
frames. This provides to accumulate oscillation
count on the TSIN[x].
0D 1 time
1D 2 times
...
15D 16 times
TSCCMP 20 rw Common Compare Enable for Touch-Sense
0B Disable common compare for touch-sense
1B Enable common compare for touch-sense
TSOEXT [22:21] rw Extension for Touch-Sense Output for Pin-Low-
Level
00B Extend by 1 ledts_clk
TSCTRR 23 rw TS-Counter Auto Reset
0B Disable TS-counter automatic reset
1B Enable TS-counter automatic reset to 00H on
the first pad turn of a new TSIN[x]. Triggered
on compare match in time slice.
TSCTRSAT 24 rw Saturation of TS-Counter
0B Disable
1B Enable. TS-counter stops counting in the
touch-sense time slice(s) of the same
(extended) frame when it reaches FFH.
Counter starts to count again on the first pad
turn of a new TSIN[x], triggered on compare
match.
NR_TSIN1) [27:25] rw Number of Touch-Sense Input
Defines the number of touch-sense inputs TSIN[x].
Used for the hardware control of pad turn enabling.
0D 1
...
7D 8

XMC4500
XMC4000 Family

COLLEV 28 rw Active Level of LED Column
0B Active low
1B Active high
NR_LEDCOL1) [31:29] rw Number of LED Columns
Defines the number of LED columns.
000B 1 LED column
001B 2 LED columns
010B 3 LED columns
011B 4 LED columns
100B 5 LED columns
101B 6 LED columns
110B 7 LED columns
111B 8 LED columns (max. LED columns = 7 if bit
TS_EN = 1)
Note: LED column is enabled in sequence starting
from highest column number. If touch-sense
function is not enabled, COLA is activated in
last time slice.
0 [15:8] r Reserved
1) This bit can only be modified when bit CLK_PS = 0.
EVFR
The EVFR register contains the status flags for events and control bits for requesting
clearance of event flags.
EVFR
Event Flag Register (0CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CTP CTF CTS
0
F F F
r w w w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TSC
0 TRO TPF TFF TSF
VF
r rh rh rh rh

XMC4500
XMC4000 Family

TSF 0 rh Time Slice Interrupt Flag
Set on activation of each new time slice, including
when bit CLK_PS is set from 0. To be cleared by
software.
TFF 1 rh (Extended) Time Frame Interrupt Flag
Set on activation of each new (extended) time frame,
including when bit CLK_PS is set from 0.
TPF 2 rh Autoscan Time Period Interrupt Flag
Set on activation of each new time period, including
when bit CLK_PS is set from 0.
This bit will never be set in case of hardware pad turn
control is disabled (bit PADTSW = 1).
TSCTROVF 3 rh TS-Counter Overflow Indication
This bit indicates whether a TS-counter overflow has
occurred. This bit is cleared on new pad turn,
triggered on compare match.
0B No overflow has occurred.
1B The TS-counter has overflowed at least once.
CTSF 16 w Clear Time Slice Interrupt Flag
0B No action.
1B Bit TSF is cleared.
Read always as 0.
CTFF 17 w Clear (Extended) Time Frame Interrupt Flag
0B No action.
1B Bit TFF is cleared.
Read always as 0.
CTPF 18 w Clear Autoscan Time Period Interrupt Flag
0B No action.
1B Bit TPF is cleared.
Read always as 0.
TSVAL
The TSVAL register holds the current and shadow touch sense counter values.

XMC4500
XMC4000 Family
TSVAL
Touch-sense TS-Counter Value (10H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TSCTRVAL
rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TSCTRVALR

TSCTRVALR [15:0] r Shadow TS-Counter (Read)
This is the latched value of the TS-counter (on every
extended time frame event).
It shows the latest valid oscillation count from the last
completed time slice.
TSCTRVAL [31:16] rwh TS-Counter Value
This is the actual TS-counter value. It can only be
written when no pad turn is active.
The counter may be enabled for automatic reset
once per (extended) frame on the start of a new pad
turn on the next TSIN[x] pin.
LINEx (x = 0-1)
The LINEx registers hold the values that are output to the respective line pins during their
active column period.

XMC4500
XMC4000 Family
LINE0
Line Pattern Register 0 (14H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
LINE_3 LINE_2
rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
LINE_1 LINE_0
rw rw

LINE_0, [7:0], rw Output on LINE[x]
LINE_1, [15:8], This value is output on LINE[x] to pin when LED
LINE_2, [23:16], COL[x] is active.
LINE_3 [31:24]
LINE1
Line Pattern Register 1 (18H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
LINE_A LINE_6
rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
LINE_5 LINE_4
rw rw

LINE_4, [7:0], rw Output on LINE[x]
LINE_5, [15:8], This value is output on LINE[x] to pin when LED
LINE_6 [23:16] COL[x] is active.

XMC4500
XMC4000 Family

LINE_A [31:24] rw Output on LINE[x]
This value is output on LINE[x] to pin when LED
COLA or touch-sense time slice is active.
LDCMPx (x = 0-1)
The LDCMPx registers hold the COMPARE values for their respective LED columns.
These values are used for LED brightness control.
LDCMP0
LED Compare Register 0 (1CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CMP_LD3 CMP_LD2
rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CMP_LD1 CMP_LD0
rw rw

CMP_LD0, [7:0], rw Compare Value for LED COL[x]
CMP_LD1, [15:8],
CMP_LD2, [23:16],
CMP_LD3 [31:24]

XMC4500
XMC4000 Family
LDCMP1
LED Compare Register 1 (20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CMP_LDA_TSCOM CMP_LD6
rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CMP_LD5 CMP_LD4
rw rw

CMP_LD4, [7:0], rw Compare Value for LED COL[x]
CMP_LD5, [15:8],
CMP_LD6 [23:16]
CMP_LDA_TS [31:24] rw Compare Value for LED COLA / Common
COM Compare Value for Touch-sense Pad Turns
LED function
The compare value for LED COLA is only valid when
touch-sense function is not enabled.
Touch-sense function
The common compare value for touch-sense pad
turns is enabled by set TSCCMP bit. When enabled
for common compare, settings in SFRs
LEDTS_TSCMP0,1 are not referenced.
TSCMPx (x = 0-1)
The TSCMPx registers hold the COMPARE values for their respective touch pad input
lines. These values determine the size of the pad oscillation window for each pad input
lines during their pad turn.

XMC4500
XMC4000 Family
TSCMP0
Touch-sense Compare Register 0 (24H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CMP_TS3 CMP_TS2
rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CMP_TS1 CMP_TS0
rw rw

CMP_TS0, [7:0], rw Compare Value for Touch-Sense TSIN[x]
CMP_TS1, [15:8],
CMP_TS2, [23:16],
CMP_TS3 [31:24]
TSCMP1
Touch-sense Compare Register 1 (28H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CMP_TS7 CMP_TS6
rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CMP_TS5 CMP_TS4
rw rw

CMP_TS4, [7:0], rw Compare Value for Touch-Sense TSIN[x]
CMP_TS5, [15:8],
CMP_TS6, [23:16],
CMP_TS7 [31:24]

XMC4500
XMC4000 Family
12.11 Interconnects
The LEDTS has interconnection to other peripherals enabling higher level of automation
without requiring software. Table 12-9 provides a list of the pin connections.
LEDTS.FN is an output signal denoting LEDTS active function. This signal can be used
as a source for VADC request gating and background gating.

LEDTS.FN O VADC.GxREQGTJ VADC request gating
VADC.BGREQGTJ VADC background gating input J

XMC4500
XMC4000 Family
SD/MMC Interface (SDMMC)
13 SD/MMC Interface (SDMMC)

This chapter describes the SD/MMC module. The XMC4500 uses the following SD and
MMC card standard specification. For more detailed information on how to operate the
SDMMC interface, please refer to the SD and MMC specification referenced below.
References
[10] SD Specifications Part A2, SD Host Controller Standard Specification, Version 2.00,
February 2007
https://www.sdcard.org/developers/overview/host_controller/simple_spec
[11] SD Specifications Part 1, Physical Layer Specification, Version 2.00, May 2006
https://www.sdcard.org/downloads/pls
[12] SD Specifications Part E1, SDIO Specification, Version 2.00, January 2007
https://www.sdcard.org/developers/overview/sdio/sdio_spec
[13] SD Memory Card Security Specification, Version 1.01
[14] The MultiMediaCard System Specification, Version 3.31, 4.2 and 4.4
13.1 Overview
The Secure Digital/ MultiMediaCard interface (SDMMC) of the XMC4500 provides an
interface between SD/SDIO/MMC cards and the AHB bus. The CPU is programmed to
support SD, SDIO, SDHC and MMC cards, and can operate up to 48 MHz. The SDMMC
module is able to transfer a maximum of 24 MB/sec for SD cards and 48 MB/sec for
MMC cards.
13.1.1 Features
The SDMMC Host Controller handles SDIO/SD protocol at transmission level, packing
data, adding cyclic redundancy check (CRC), start/end bit, and checking for transaction
format correctness. Some useful applications of the SDMMC includes memory
extension, data logging, and firmware update.
The SDMMC is compliant with the following specifications:

SD Card Host Controller Version 2.0
SD Physical Layer Specification Version 2.0
SDIO Card Specification Version 2.0
SD Memory Card Security Specification Version 1.01
MMC Specification version 3.31, 4.2 and 4.4
Fully compatible with earlier versions of MMC
The following functionalities are supported by the SDMMC module:

SDMMC, V1.4 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
System Interface
Data transfer using Programmed IO mode on AHB Slave interface
SD/SDIO/MMC Card Interface
Transfers data in 1 bit and 4 bit SD modes and SPI mode
Cyclic Redundancy Check CRC7 for command and CRC16 for data integrity
Variable-length data transfers for SD/SDIO cards
Designed to work with SD I/O cards, Read-only cards and Read/Write cards
Supports Read wait Control, and Suspend/Resume operation for SD/SDIO cards
Supports MMC Plus and MMC Mobile
MMC Card detection for insertion/removal
Error Correction Codes (ECC) for eMMC 4.4 cards
Password protection for MMC cards
Two 512 byte buffer for data transfers between core and cards
Handles FIFO overrun and underrun conditions
Table 13-1 SDMMC Applications

Use Case SDMMC Application
Memory Extension All
Data Logging All
Firmware Update All
Data Transfer (PC and Application) All

The SDMMC block diagram is shown in Figure 13-1.

XMC4500
XMC4000 Family
BUS
Power Monitor
Management
AHB BUS
Synchronizer
Command
Control Unit
SD2.0/
SD Protocol unit SDIO2.0/
MMC4.4
Device
AHB Data
Interface Control Unit
SD
Data
Registers FIFO
To NVIC
Interrupts
Clock
Control
Figure 13-1 SDMMC Block Diagram

XMC4500
XMC4000 Family

This section describes the functional blocks of the SDMMC.
AHB Interface
Host AHB interface acts as a bridge between AHB and the host controller. The SDMMC
host controller provides Programmed IO method in which the ARM Host Driver transfers
data using the Buffer Data Port Register SDMMC_DATA_BUFFER. The AHB target is
having the Host control register SDMMC_HOST_CTRL and these registers are
programmed by the CPU through the AHB target interface. The data transaction is
performed through the AHB target interface in case of Programmed IO method of data
transfer.
Interrupt controller
The SDMMC host controller generates interrupt to the Nested Vectored Interrupt
Controller (NVIC) if any of the interrupt bits are set in the interrupt status register
SDMMC_INT_STATUS_NORM.
DATA FIFO
The SDMMC host controller uses two 512 bytes dual port fifo for performing both read
and write transactions. During a write transaction (data transferred from CPU to
SD/SDIO/MMC card), the data will be filled in to the first and second fifo alternatively.
When data from first fifo is transferring to the SD/SDIO/MMC card, the second fifo will be
filled and vice versa. The two fifos are alternatively used to store data which will give
maximum throughput. During a read transaction (data transferred from SD/SDIO/MMC
card to CPU), the data from SD/SDIO/MMC card will be written in to the two fifos
alternatively. When data from one fifo is transferring to the CPU, the second fifo will be
filled and vice versa and thereby the throughput will be maximum. If the host controller
cannot accept any data from SD/SDIO/MMC card, it will issue read wait (if card supports
read wait mechanism) to stop the data coming from card or through stopping clock.
DAT[0-7] Control Logic

The DAT[0-7] control logic block transmits data in the data lines during write transaction
and receives data in the data lines during read transaction.
BUS Monitor
Bus monitor will check for any violations occurring in the SD bus and time-out conditions.
Command Control Logic

The Command control logic block sends the command in the cmd line and receives the
response coming from the SD/SDIO/MMC card.

XMC4500
XMC4000 Family
Power Control
The SDMMC host controller controls the SD Bus Power depending on the value
programmed in the Power Control Register SDMMC_POWER_CTRL by the CPU. The
system has the responsibility to supply SD Bus Voltage according to card OCR and
supply voltage capabilities depending on the host controller. If SD Bus power
SDMMC_POWER_CTRL.SD_BUS_POWER = 1, the system shall supply voltage to the
Card. If an unsupported voltage is selected in the SD Bus Voltage Select
SDMMC_POWER_CTRL.SD_BUS_VOLTAGE_SEL field, the system may ignore write
to SD Bus Power and keep its value at 0.
Clock Control
The Clock generation block will generate the SD clock depending on the value
programmed by the CPU in the Clock Control Register SDMMC_CLOCK_CTRL.
Stream write and read transaction

SDMMC host controller will switch to second fifo after writing/reading a block of data to
the first fifo, but in stream transaction, block size will not be programmed by the driver.
For both stream write and read transaction, it is recommended to write the maximum fifo
size value to Block Size Register SDMMC_BLOCK_SIZE. For example if fifo size is 512
bytes, host driver needs to write 512 bytes to the SDMMC_BLOCK_SIZE. Fifo switching
will occur after writing/ reading 512 bytes of data (fifo size).

XMC4500
XMC4000 Family
13.3 Card Detection

When card insertion or removal in the slot is detected, the status will be sent to the CPU
via interrupt methodology. The active low card signal SDCD_n is set to 0 during card
detection. The SDMMC_PRESENT_STATE.CARD_INSERTED bit indicates whether a
card has been inserted. A change from 0 to 1 generates a Card Insertion interrupt in the
Normal Interrupt Status register SDMMC_INT_STATUS_NORM.CARD_INS = 1, and a
change from 1 to 0 generates a Card Removal Interrupt in the Normal Interrupt Status
register SDMMC_INT_STATUS_NORM.CARD_REMOVAL = 1.
Note: LED light indicates that card is being accessed. Do not remove card when LED
light is ON.
13.4 Data Transfer Modes

SDMMC transfers are classified into following three modes, according to how the
number of blocks is specified:
Single Block Transfer

Single block transfer mode can be selected by setting
SDMMC_TRANSFER_MODE.MULTI_BLOCK_SELECT = 0. The number of blocks is
specified to the host controller before the transfer via Block Count Register, and it is
always set to 1. SDMMC_BLOCK_COUNT.BLOCK_COUNT = 0001H.
Multiple Block Transfer

Multiple block transfer mode can be selected by setting
SDMMC_TRANSFER_MODE.MULTI_BLOCK_SELECT = 1. The number of blocks is
specified to the host controller before the transfer via Block Count Register
SDMMC_BLOCK_COUNT.BLOCK_COUNT, and it can be set to 1 or more.
Infinite Block Transfer

The number of blocks is not specified to the host controller before the transfer. This
transfer is continued until an abort transaction is executed. Refer to Section 13.5.3 for
details on Abort Transaction.

XMC4500
XMC4000 Family
13.5 Read/ Write Operation

The controller will be configued to work with buffer data port registers
SDMMC_DATA_BUFFER without internal DMA. The CPU will act as a master and start
writing / reading data via SDMMC_DATA_BUFFER.
13.5.1 Write Operation

On receiving the Buffer Write Ready interrupt the CPU will act as a master and start
transferring the data via Buffer data port register SDMMC_DATA_BUFFER (fifo_1).
Transmitter starts sending the data in SD bus when a block of data is ready in fifo_1.
While transmitting the data in sd bus, the buffer write ready interrupt is sent to the
interrupt controller for the second block of data. The CPU will act as a master and start
sending the second block of data via SDMMC_DATA_BUFFER to fifo_2. Buffer write
ready interrupt will be asserted only when a fifo is empty to receive a block of data.
During write transaction the host controller will transmit data to card only when a block
of data is ready to transmit and also the card is not driving busy. So underrun condition
will not occur in SD side. The controller will assert buffer write ready interrupt
SDMMC_INT_STATUS_NORM.BUFF_WRITE_READY = 1 only if space is available to
accept a block of data.
13.5.2 Read Operation

Buffer Read Ready interrupt is asserted whenever a block of data is ready in one of the
fifos. On receiving the Buffer Read Ready interrupt, the CPU will act as a master and
start reading the data via Buffer data port register SDMMC_DATA_BUFFER (fifo_1).
Receiver start reading the data from SD bus only when a fifo is empty to receive a block
of data. When both the fifos are full the host controller will stop the data coming from the
card through read wait mechanism (if card supports read wait) or through clock stopping.
During read transaction when fifo is full, that is, no space to accept one block of data from
card, the host controller will stop the clock to card so overrun condition will not occur in
SD side. The controller will assert buffer read ready interrupt
SDMMC_INT_STATUS_NORM.BUFF_READ_READY = 1 only on reception of block of
data from card.
13.5.3 Abort Transaction

There are two cases where the host driver needs to perform an Abort Transaction:
1. When the host driver stops infinite block transfers.
2. When host driver stops transfers while a multiple block transfer is exacting.
There are two ways to issue an Abort command; Asynchronous Abort and Synchronous
Abort.

XMC4500
XMC4000 Family
Asynchronous Abort
In an Asynchronous Abort sequence, the host driver can issue an Abort Command at
anytime unless Command Inhibit (CMD) in the Present State Register is set to 1.
SDMMC_PRESENT_STATE.COMMAND_INHIBIT_CMD = 1.
Synchronous Abort
In a Synchronous Abort, the host driver shall issue an Abort command after the data
transfer stopped by using Stop At Block Gap Request in the Block Gap Control register.
SDMMC_BLOCK_GAP_CTRL.STOP_AT_BLOCK_GAP = 1.

XMC4500
XMC4000 Family
13.6 Special Command Types

There are three types of special commands. Suspend, Resume and Abort. These bits
shall be set to 00B for all other commands.
Suspend Command
Suspend command can be selected by setting SDMMC_COMMAND.CMD_TYPE =
01B.
If the Suspend command succeeds, the host controller shall assume the SD Bus has
been released and that it is possible to issue the next command which uses the DAT line.
The controller shall de-assert Read Wait for read transactions and stop checking busy
for write transactions. The Interrupt cycle shall start, in 4-bit mode. If the Suspend
command fails, the controller shall maintain its current state, and the host driver shall
restart the transfer by setting Continue Request in the Block Gap Control Register
SDMMC_BLOCK_GAP_CTRL.CONTINUE_REQ = 1 to restart the transfer.
Note: Suspend / Resume cannot be supported if Read Wait Control is disabled. Set
SDMMC_BLOCK_GAP_CTRL.READ_WAIT_CTRL = 1 to enable Read Wait
Control if the SD/SDIO card supports read wait function.
Resume Command
Resume command can be selected by setting SDMMC_COMMAND.CMD_TYPE = 10B.
The host driver re-starts the data transfer by restoring the registers in the range of 000H
- 00DH. The host controller shall check for busy before starting write transfers.
Note: Suspend / Resume cannot be supported if Read Wait Control is disabled. Set
SDMMC_BLOCK_GAP_CTRL.READ_WAIT_CTRL = 1 to enable Read Wait
Control if the SD/SDIO card supports the read wait function.
Abort Command
Abort command can be selected by setting SDMMC_COMMAND.CMD_TYPE = 11B.
If this command is set when executing a read transfer, the host controller shall stop reads
to the buffer. If this command is set when executing a write transfer, the host controller
shall stop driving the DAT line. After issuing the Abort command, the controller should
issue a software reset

XMC4500
XMC4000 Family
13.7 Error Detection

This section describes data errors or defects detection methods.
Cyclic Redundancy Check (CRC)

The CRC7 and CRC16 generators calculate the CRC for Command and Data
respectively to send the CRC to the SD/SDIO/MMC card. The CRC7 and CRC16
checker checks for any CRC error in the Response and Data sent by the SD/SDIO/MMC
card. When a CRC error is generated, an interrupt will be triggered if the Error Interrupt
Signal Enable is enabled. SDMMC_EN_INT_SIGNAL_ERR.DATA_CRC_ERR_EN = 1
for data CRC error, and SDMMC_EN_INT_STATUS_ERR.CMD_CRC_ERR_EN = 1 for
command CRC error.
Error Correction Code (ECC)

Error correction codes (ECC) may be included in the payload data to detect data defects
on the cards. An ECC code is used to store data on the MMC card. This ECC code is
used by the SDMMC or application to decode the user data.

The SDMMC module provides one service request output. The service request output
MMCI.SR0 is connected to interrupt node in the Nested Vectored Interrupt Controller
(NVIC). For details on the service request and interrupt node, please refer to Service
Request Processing and Nested Vectored Interrupt Controller chapters in the
reference manual.
13.9 Debug Behavior

Suspend mode can be activated by issuing the suspend command. For details on the
suspend command, please refer to Section 13.6.
13.10 Power, Reset and Clocks

This section describes the behaviour of power, reset and clocks.
Power
The SD/MMC card power supply can be controlled by the signal bus_pow. The SD bus
voltage supported by the SDMMC is 3.3V. If the SD Bus power is set to 1 in the Power
Control Register SDMMC_POWER_CTRL.SD_BUS_POWER = 1, the system shall
supply voltage to the card.
Reset
The SDMMC host controller is reset asynchronously when one of the following occurs:

XMC4500
XMC4000 Family
A hardware reset to the card triggered by the MMC.RST pin.

A software reset occurs. A reset pulse is generated when writing 1 to each bit of the
Software Reset Register SDMMC_SW_RESET.
Clocks
The clocks connected to SDMMC include:
clk_xin
Input clock to the SDMMC controller.
This is used to generate clk_sdcard_out and clk_sleep_out.
Frequency of clock is 48 MHz, generated from the System Control Unit (SCU)
module.
clk_sdcard_out
Clock supplied to the SD/MMC card.
clk_sdcard_in
Feedback clock of clk_sdcard_out from the pad.
Feedback clock is used to reduce the pad delay in the clock line.

XMC4500
XMC4000 Family
13.11 Initialisation and System Dependencies

This section provides information on how to initialise and use the SDMMC.
13.11.1 Setup SDMMC Data Transfer

Figure 13-2 shows the flowchart of SDMMC read/ write data transfer.
Start
1. Set Block Size Register 5. Set Command Register
2. Set Block Count Register 6. Wait for Command Complete Interrupt

Command Complete
Interrupt occur
3. Set Argument Register 7. Clear Command Complete status
4. Set Transfer Mode Register 8. Get Response Data
Write Read
9. Write or Read?
10-W. Wait for Buffer Write 10-R. Wait for Buffer Read
Ready Interrupt Ready Interrupt
Buffer Write Ready Buffer Read Ready
Interrupt occur Interrupt occur
11-W. Clear Buffer 11-R. Clear Buffer
Write Ready status Read Ready status
12-W. Get Block 12-R. Get Block

Data Data
Yes Yes
13-W. More Blocks? 13-R. More Blocks?
No No
Single/ Multiple Infinite

Block Transfer 14. Single / Multiple/ Infinite Block Transfer
Block Transfer?
15. Wait for Transfer

Complete Interrupt
17. Abort
Transfer Complete Transaction
Interrupt occur
16. Clear Transfer
Complete status
End
Figure 13-2 Data Transfer sequence

XMC4500
XMC4000 Family
The following describes how to setup read/ write data transfer:

1. Set Block Size Register. Set executed data byte length of one block.
SDMMC_BLOCK_SIZE.TX_BLOCK_SIZE
2. Set Block Count Register. Set executed data block count.
SDMMC_BLOCK_COUNT.BLOCK_COUNT
3. Set Argument Register. Set value correspoinding to issued command.
SDMMC_ARGUMENT1.ARGUMENT1
4. Set Transfer Mode Register. Set Multi / single block, block count enable, data transfer
direction, Auto CMD12 enable.
SDMMC_TRANSFER_MODE.MULTI_BLOCK_SELECT.
SDMMC_TRANSFER_MODE.BLOCK_COUNT_EN
SDMMC_TRANSFER_MODE.TX_DIR_SELECT
SDMMC_TRANSFER_MODE.ACMD_EN
5. Set Command Register. Set value corresponding to the issued command.
Note: When writing the upper byte of Command register, SD command is issued.
SDMMC_COMMAND
6. Wait for Command Complete Interrupt.
SDMMC_INT_STATUS_NORM.CMD_COMPLETE
7. Clear Command Complete status
Write SDMMC_INT_STATUS_NORM.CMD_COMPLETE = 1 to clear bit
8. Read Response Register and get the necessary information in accordance with the
issued command.
SDMMC_RESPONSE
9. For Read Operation (read from card), go to step (10-R). See Section 13.11.2.
For Write Operation (write to card), go to step (10-W). See Section 13.11.3.

XMC4500
XMC4000 Family
13.11.2 Read Operation

The following shows the configurations for SDMMC read operation:
10-R. Wait for Buffer Read Ready Interrupt
SDMMC_INT_STATUS_NORM.BUFF_READ_READY
11-R. Clear Buffer Read Ready status
Write SDMMC_INT_STATUS_NORM.BUFF_READ_READY = 1 to clear bit
12-R. Read Block Data (in accordance with the number of bytes specified in step (1))
SDMMC_DATA_BUFFER
13-R. Repeat until all blocks are received and then go to step (14)
14-R. For Single or Multiple Block Transfer, go to step (15). For Infinite Block Transfer,
go to step (17)
15-R. Wait for Transfer Complete Interrupt
SDMMC_INT_STATUS_NORM.TX_COMPLETE
16-R. Get Transfer Complete status and end data transfer
Write SDMMC_INT_STATUS_NORM.TX_COMPLETE = 1 to clear bit
17-R. Perform Abort Transaction. See Section 13.11.4.
13.11.3 Write Operation

The following shows the configurations for SDMMC write operation:
10-W. Wait for Buffer Write Ready Interrupt
SDMMC_INT_STATUS_NORM.BUFF_WRITE_READY
11-W. Clear Buffer Write Ready status
Write SDMMC_INT_STATUS_NORM.BUFF_WRITE_READY = 1 to clear bit
12-W. Write Block Data (in accordance with the number of bytes specified in step (1))
SDMMC_DATA_BUFFER
13-W. Repeat until all blocks are received and then go to step (14)
14-W. For Single or Multiple Block Transfer, go to step (15). For Infinite Block Transfer,
go to step (17)
15-W. Wait for Transfer Complete Interrupt
SDMMC_INT_STATUS_NORM.TX_COMPLETE
16-W. Get Transfer Complete status and end data transfer
Write SDMMC_INT_STATUS_NORM.TX_COMPLETE = 1 to clear bit
17-W. Perform Abort Transaction. See Section 13.11.4.

XMC4500
XMC4000 Family
13.11.4 Abort Transaction

This section describes the sequence for the abort transaction.
Asynchronous Abort
The following shows the asynchronous abort sequence:
1. Check SDMMC_PRESENT_STATE.COMMAND_INHIBIT_CMD is not set to 1.
2. Issue Abort Command. SDMMC_COMMAND.CMD_TYPE = 11B.
Synchronous Abort
The following shows the synchronous abort sequence:
1. Set SDMMC_BLOCK_GAP_CTRL.STOP_AT_BLOCK_GAP = 1 to stop SD
transactions.
2. Wait for Transfer Complete Interrupt. SDMMC_INT_STATUS_NORM.TX_COMPLETE.
3. Set SDMMC_INT_STATUS_NORM.TX_COMPLETE = 1 to clear this bit.
4. Issue Abort Command. SDMMC_COMMAND.CMD_TYPE = 11B.
5. Set SDMMC_SW_RESET.SW_RST_DAT_LINE = 1 and
SDMMC_SW_RESET.SW_RST_CMD_LINE = 1 to do software reset.
6. Check SW_RST_DAT_LINE and SW_RST_CMD_LINE. If both are 0, end data transfer.
If either SW_RST_DAT_LINE or SW_RST_CMD_LINE is 1, repeat step (6).
Start
1. Set Stop at Block Gap Request 5. Set Software Reset for DAT line
(DR) and CMD line (CR)
2. Wait for Transfer

Complete Interrupt DR=1 or CR=1
Transfer Complete Interrupt occur 6. Check DR and CR
3. Clear Transfer Complete status

DR=0 and CR=0
End
4. Issue Abort Command
Figure 13-3 Synchronous Abort sequence

XMC4500
XMC4000 Family
13.12 Registers
Registers Overview

SDMMC 4801 C000H 4801 FFFFH

Short Name Description Offset Access Mode Descripti
Addr. Read Write on See
0002H
Block Registers
SDMMC_BLOC Block Size Register 0004H U, PV U, PV Page 13-2
K_SIZE 0
BLOCK_COUNT Block Count Register 0006H U, PV U, PV Page 13-2
1
Argument1 Register
SDMMC_ARGU Argument1 Register 0008H U, PV U, PV Page 13-2
MENT1 2
Transfer Mode Register
SDMMC_TRAN Transfer Mode Register 000CH U, PV U, PV Page 13-2
SFER_MODE 3
Command Register
SDMMC_COMM Command Register 000EH U, PV U, PV Page 13-2
AND 6
Response Register
SDMMC_RESP Response 0 Register 0010H U, PV U, PV Page 13-2
ONSE0 8
ONSE2 8

XMC4500
XMC4000 Family

ONSE4 8
SDMMC_RESP Response 6 Register 001CH U, PV U, PV Page 13-2
ONSE6 8
Buffer Data Port Register
SDMMC_DATA_ Data Buffer Register 0020H U, PV U, PV Page 13-3
BUFFER 2
Present State Register
SDMMC_PRES Present State Register 0024H U, PV U, PV Page 13-3
ENT_STATE 3
Control Registers
SDMMC_HOST Host Control Register 0028H U, PV U, PV Page 13-4
_CTRL 1
SDMMC_POWE Power Control Register 0029H U, PV U, PV Page 13-4
R_CTRL 3
SDMMC_BLOC Block Gap Control Register 002AH U, PV U, PV Page 13-4
K_GAP_CTRL 4
SDMMC_WAKE Wake-up Control Register 002BH U, PV U, PV Page 13-4
UP_CTRL 7
SDMMC_CLOC Clock Control Register 002CH U, PV U, PV Page 13-4
K_CTRL 8
SDMMC_TIMEO Timeout Control Register 002EH U, PV U, PV Page 13-5
UT_CTRL 1
SDMMC_SW_R Software Reset Register 002FH U, PV U, PV Page 13-5
ESET 2
SDMMC_INT_S Normal Interrupt Status 0030H U, PV U, PV Page 13-5
TATUS_NORM Register 4
SDMMC_INT_S Error Interrupt Status Register 0032H U, PV U, PV Page 13-6
TATUS_ERR 0
SDMMC_EN_IN Normal Interrupt Status 0034H U, PV U, PV Page 13-6
T_STATUS_NO Enable Register 4
RM

XMC4500
XMC4000 Family

SDMMC_EN_IN Error Interrupt Status Enable 0036H U, PV U, PV Page 13-6
T_STATUS_ER Register 6
R
SDMMC_EN_IN Normal Interrupt Signal 0038H U, PV U, PV Page 13-6
T_SIGNAL_NOR Enable Register 8
M
SDMMC_EN_IN Error Interrupt Signal Enable 003AH U, PV U, PV Page 13-7
T_SIGNAL_ERR Register 0
SDMMC_ACMD Auto CMD12 Error Status 003CH U, PV U, PV Page 13-7
_ERR_STATUS Register 2
Reserved Reserved 003EH nBE nBE
-
004EH
Error Status Registers
SDMMC_FORC Force Event Register for Auto 050H U, PV U, PV Page 13-7
E_EVENT_ACM CMD Error Status 5
D_ERR_STATU
S
SDMMC_FORC Force Event Register for Error 052H U, PV U, PV Page 13-7
E_EVENT_ERR Interrupt Status 7
_STATUS
0072H
Debug Selection Register
SDMMC_DEBU Debug Selection Register 0074H U, PV U, PV Page 13-7
G_SEL 9
00EEH
SPI Interrupt Support Register
SDMMC_SPI SPI Interrupt Support Register 00F0H Page 13-8
0
Reserved Reserved 00F2H nBE nBE
-
00FAH

XMC4500
XMC4000 Family

Slot Interrupt Status Register
SDMMC_SLOT_ Slot Interrupt Status Register 00FCH U, PV U, PV Page 13-8
INT_STATUS 1
Reserved Reserved 00FEH nBE nBE
Access Restrictions
Note: The SDMMC registers are accessible only through word accesses. Half-word and
byte accesses on SDMMC registers will not generate a bus error. Writes to
unused address space will not cause an error but will be ignored.

XMC4500
XMC4000 Family
SDMMC_BLOCK_SIZE
This register is used to configure the block size for data transfer.
SDMMC_BLOCK_SIZE
Block Size Register (0004H) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TX_
BLO
CK_ 0 TX_BLOCK_SIZE
SIZE
_12
rw rw rw

TX_BLO 15 rw Transfer Block Size 12th bit.
CK_SIZE This bit is added to support 4Kb Data block transfer.
_12 This bit can be set and cleared only by software.
Read as 0; must be written with 0.
TX_BLO [11:0] rw Transfer Block Size
CK_SIZE This register specifies the block size for block data
transfers for CMD17, CMD18, CMD24, CMD25, and
CMD53. It can be accessed only if no transaction is
executing (i.e after a transaction has stopped). Read
operations during transfer return an invalid value and write
operations shall be ignored.
0000H No Data Transfer
0001H 1 Byte
0002H 2 Bytes
0003H 3 Bytes
0004H 4 Bytes
...
01FFH 511 Bytes
0200H 512 Bytes (Maximum Block Size)
Note: Other values are reserved
This bit can be set and cleared only by software.

XMC4500
XMC4000 Family
SDMMC_BLOCK_COUNT
This register is used to configure the block count for current transfer.
SDMMC_BLOCK_COUNT
Block Count Register (0006H) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BLOCK_COUNT
rw

BLOCK_CO [15:0] rw Blocks Count for Current Transfer
UNT This register is enabled when Block Count Enable in the
Transfer Mode register is set to 1 and is valid only for
multiple block transfers. The host controller decrements
the block count after each block transfer and stops when
the count reaches zero. It can be accessed only if no
transaction is executing (i.e after a transaction has
stopped). Read operations during transfer return an
invalid value and write operations shall be ignored.
When saving transfer context as a result of Suspend
command, the number of blocks yet to be transferred
can be determined by reading this register. When
restoring transfer context prior to issuing a Resume
command, the host driver shall restore the previously
save block count.
0000H Stop Count
0001H 1 block
0002H 2 blocks
...
FFFFH 65535 blocks

XMC4500
XMC4000 Family
SDMMC_ARGUMENT1
This register is used to configure the SD command argument.
SDMMC_ARGUMENT1
Argument1 Register (0008H) Reset Value: 00000000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ARGUMENT1
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ARGUMENT1
rw

ARGUMEN [31:0] rw Command Argument
T1 The SD Command Argument is specified as bit 39-8 of
Command-Format.

XMC4500
XMC4000 Family
SDMMC_TRANSFER_MODE
This register is used to configure the data transfer mode.
SDMMC_TRANSFER_MODE
Transfer Mode Register (000CH) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MUL BLO
CMD TX_
TI_B CK_
_CO LOC DIR_
0 ACMD_EN COU 0
MP_ SEL
K_S NT_
ATA ECT
ELE EN
r rw rw rw rw rw rw

0 [15:7] r Reserved
CMD_CO 6 rw Command Completion Signal Enable for CE-ATA Device
MP_ATA 1B Device will send command completion Signal
0B Device will not send command completion Signal
MULTI_B 5 rw Multi / Single Block Select
LOCK_S This bit enables multiple block DAT line data transfers.
ELECT 0B Single Block
1B Multiple Block
TX_DIR_ 4 rw Data Transfer Direction Select
SELECT This bit defines the direction of DAT line data transfers.
0B Write (Host to Card)
1B Read (Card to Host)

XMC4500
XMC4000 Family

ACMD_E [3:2] rw Auto CMD Enable
N This field determines use of auto command functions
00B Auto Command Disabled
01B Auto CMD12 Enable
To stop Multiple-block read and write operation:
Auto CMD12 Enable
Multiple-block read and write commands for memory
require CMD12 to stop the operation. When this field is set
to 01B, the host controller issues CMD12 automatically
when last block transfer is completed. Auto CMD12 error
is indicated to the Auto CMD Error Status register. The
Host Driver shall not set this bit if the command does not
require CMD12.
BLOCK_ 1 rw Block Count Enable
COUNT_ This bit is used to enable the Block count register, which is
EN only relevant for multiple block transfers. When this bit is 0,
the Block Count register is disabled, which is useful in
executing an infinite transfer.
0B Disable
1B Enable
0 0 rw Reserved

XMC4500
XMC4000 Family
Determination of transfer type
Table 13-4 Determination of transfer type

Multi / Single Block Block Count Block Count Function
Select Enable
0 Dont Care Dont Care Single Transfer
1 0 Dont Care Infinite Transfer
1 1 Not Zero Multiple Transfer
1 1 Zero Stop Multiple Transfer

XMC4500
XMC4000 Family
SDMMC_COMMAND
This register is used to configure the SDMMC command.
SDMMC_COMMAND
Command Register (000EH) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DAT CMD CMD
A_P _IND _CR RESP_TY
CMD_TYP RES C_C
0 CMD_IND _CH 0 PE_SELE
E
ENT ECK HEC CT
_SE _EN K_E
r rw rw rw rw rw r rw

CMD_I [13:8] rw Command Index
ND This bit shall be set to the command number (CMD0-63,
ACMD0-63).
CMD_ [7:6] rw Command Type
TYPE There are three types of special commands. Suspend,
Resume and Abort. These bits shall bet set to 00b for all other
commands.
00B Normal
01B Suspend
10B Resume
11B Abort
DATA_ 5 rw Data Present Select
PRESE This bit is set to 1 to indicate that data is present and shall be
NT_SE transferred using the DAT line. If is set to 0 for the following:
LECT 1. Commands using only CMD line (ex. CMD52)
2. Commands with no data transfer but using busy signal on
DAT[0] line (R1b or R5b ex. CMD38)
3. Resume Command
0B No Data Present
1B Data Present

XMC4500
XMC4000 Family

CMD_I 4 rw Command Index Check Enable
ND_C If this bit is set to 1, the host controller shall check the index
HECK_ field in the response to see if it has the same value as the
EN command index. If it is not, it is reported as a Command Index
Error. If this bit is set to 0, the Index field is not checked.
0B Disable
1B Enable
CMD_ 3 rw Command CRC Check Enable
CRC_ If this bit is set to 1, the host controller shall check the CRC
CHEC field in the response. If an error is detected, it is reported as a
K_EN Command CRC Error. If this bit is set to 0, the CRC field is not
checked.
0B Disable
1B Enable
0 2 r Reserved
RESP_ [1:0] rw Response Type Select
TYPE_ 00B No Response
SELEC 01B Response length 136
T 10B Response length 48
11B Response length 48 check Busy after response

XMC4500
XMC4000 Family
SDMMC_RESPONSE
This register is used to configure the command response. Table 13-5 shows the relation
between parameters and the name of response type.
Table 13-5 Relation between parameters and the name of response type
Response Type Index Check CRC Check Name of Response
Enable Enable Type
00 0 0 No Response
01 0 1 R2
10 0 0 R3, R4
10 1 1 R1, R6, R5, R7
11 1 1 R1b, R5b
Table 13-6 describes the mapping of command responses from the SD Bus to this
register for each response type. In the table, R[] refers to a bit range within the response
data as transmitted on the SD Bus, RESPONSE[] refers to a bit range within the
Response register.
Table 13-6 Response bit definition for each response type

Kind of Response Meaning of Response Response Response
Field Register
R1, R1b (normal response) Card Status R[39:8] RESPONSE
0[31:0]
R1b (Auto CMD12 Card Status for Auto CMD12 R[39:8] RESPONSE
response) 6[31:0]
R2 (CID, CSD Register) CID or CSD reg. incl. R[127:8] RESPONSE
6[23:0],
RESPONSE
4[31:0]
RESPONSE
2[31:0],
RESPONSE
0[31:0]
R3 (OCR Register) OCR Register for memory R[39:8] RESPONSE
0[31:0]
R4 (OCR Register) OCR Register for I/O etc. R[39:8] RESPONSE
0[31:0]

XMC4500
XMC4000 Family
Table 13-6 Response bit definition for each response type (contd)
Kind of Response Meaning of Response Response Response
Field Register
R5, R5b SDIO Response R[39:8] RESPONSE
0[31:0]
R6 (Published RCA New published RCA[31:16] R[39:8] RESPONSE
response) etc. 0[31:0]
SDMMC_RESPONSE0
Response 0 Register (0010H) Reset Value: 00000000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RESPONSE1
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RESPONSE0

RESPONS [31:16] r Response1
E1 This bit is initialized to 0 at reset.

XMC4500
XMC4000 Family
SDMMC_RESPONSE2
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RESPONSE3
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RESPONSE2

SDMMC_RESPONSE4
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RESPONSE5
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RESPONSE4


XMC4500
XMC4000 Family
SDMMC_RESPONSE6
Response 6 Register (001CH) Reset Value: 00000000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RESPONSE7
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RESPONSE6


XMC4500
XMC4000 Family
SDMMC_DATA_BUFFER
This register is used to configure the SDMMC host controller data buffer.
SDMMC_DATA_BUFFER
Data Buffer Register (0020H) Reset Value: 00000000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DATA_BUFFER
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DATA_BUFFER
rw

DATA_B [31:0] rw Data Buffer
UFFER The host controller buffer can be accessed through this 32-
bit Data Port Register.
Reset: X

XMC4500
XMC4000 Family
SDMMC_PRESENT_STATE
This register is used to check the present state of the SDMMC host controller.
SDMMC_PRESENT_STATE
Present State Register (0024H) Reset Value: 00000000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CMD WRI CAR CAR
CAR
_LIN TE_ D_D D_S
D_IN
0 DAT_7_4_PIN_LEVEL E_L DAT_3_0_PIN_LEVEL PRO ETE TAT
SER
EVE TEC CT_ E_S
TED
L T_PI PIN_ TAB
r r r r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BUF BUF REA WRI DAT COM COM
FER FER D_T TE_T _LIN MAN MAN
0 _RE _WR RAN RAN 0 E_A D_IN D_IN
AD_ ITE_ SFE SFE CTIV HIBI HIBI
ENA ENA R_A R_A E T_D T_C
r r r r r r r r r

DAT_7_4_ [28:25] r Line Signal Level
PIN_LEVE This status is used to check DAT line level to recover
L from errors, and for debugging.
D28 - DAT[7]
D27 - DAT[6]
D26 - DAT[5]
D25 - DAT[4]
Reset: FH
CMD_LINE 24 r CMD Line Signal Level
_LEVEL This status is used to check CMD line level to recover
from errors, and for debugging.
Reset: 1B

XMC4500
XMC4000 Family

DAT_3_0_ [23:20] r Line Signal Level
PIN_LEVE This status is used to check DAT line level to recover
L from errors, and for debugging. This is especially useful
in detecting the busy signal level from DAT[0].
D23 - DAT[3]
D22 - DAT[2]
D21 - DAT[1]
D20 - DAT[0]
Reset: FH
WRITE_PR 19 r Write Protect Switch Pin Level
OTECT_PI The Write Protect Switch is supported for memory and
N_LEVEL combo cards. This bit reflects the SDWP pin.
0B Write protected (SDWP = 1)
1B Write enabled (SDWP = 0)
CARD_DE 18 r Card Detect Pin Level
TECT_PIN This bit reflects the inverse value of the SDCD pin.
_LEVEL 0B No Card present (SDCD = 1)
1B Card present (SDCD = 0)
CARD_ST 17 r Card State Stable
ATE_STA This bit is used for testing. If it is 0, the Card Detect Pin
BLE Level is not stable. If this bit is set to 1, it means the Card
Detect Pin Level is stable. The Software Reset For All in
the Software Reset Register shall not affect this bit.
0B Reset of Debouncing
1B No Card or Inserted
Reset: 1B

XMC4500
XMC4000 Family

CARD_INS 16 r Card Inserted
ERTED This bit indicates whether a card has been inserted.
Changing from 0 to 1 generates a Card Insertion
interrupt in the Normal Interrupt Status register and
changing from 1 to 0 generates a Card Removal
Interrupt in the Normal Interrupt Status register. The
Software Reset For All in the Software Reset register
shall not affect this bit.
If a Card is removed while its power is on and its clock is
oscillating, the host controller shall clear SD Bus Power
in the Power Control register and SD Clock Enable in the
Clock control register. In addition the host driver should
clear the host controller by the Software Reset For All in
Software register. The card detect is active regardless of
the SD Bus Power.
0B Reset or Debouncing or No Card
1B Card Inserted
BUFFER_ 11 r Buffer Read Enable
READ_EN This status is used for non-DMA read transfers. This
ABLE read only flag indicates that valid data exists in the host
side buffer status. If this bit is 1, readable data exists in
the buffer. A change of this bit from 1 to 0 occurs when
all the block data is read from the buffer. A change of this
bit from 0 to 1 occurs when all the block data is ready in
the buffer and generates the Buffer Read Ready
Interrupt.
0B Read Disable
1B Read Enable.
This bit is initialized to 0 at reset.

XMC4500
XMC4000 Family

BUFFER_ 10 r Buffer Write Enable
WRITE_EN This status is used for non-DMA write transfers. This
ABLE read only flag indicates if space is available for write
data. If this bit is 1, data can be written to the buffer. A
change of this bit from 1 to 0 occurs when all the block
data is written to the buffer. A change of this bit from 0 to
1 occurs when top of block data can be written to the
buffer and generates the Buffer Write Ready Interrupt.
0B Write Disable
1B Write Enable.
READ_TR 9 r Read Transfer Active
ANSFER_ This status is used for detecting completion of a read
ACTIVE transfer.
This bit is set to 1 for either of the following conditions:
After the end bit of the read command
When writing a 1 to continue Request in the Block Gap
Control register to restart a read transfer
This bit is cleared to 0 for either of the following
conditions:
When the last data block as specified by block length is
transferred to the system.
When all valid data blocks have been transferred to the
system and no current block transfers are being sent as
a result of the Stop At Block Gap Request set to 1. A
transfer complete interrupt is generated when this bit
changes to 0.
0B No valid data
1B Transferring data

XMC4500
XMC4000 Family

WRITE_TR 8 r Write Transfer Active
ANSFER_ This status indicates a write transfer is active. If this bit is
ACTIVE 0, it means no valid write data exists in the host
controller. This bit is set in either of the following cases:
After the end bit of the write command.
When writing a 1 to Continue Request in the Block Gap
Control register to restart a write transfer.
This bit is cleared in either of the following cases:
After getting the CRC status of the last data block as
specified by the transfer count (Single or Multiple)
After getting a CRC status of any block where data
transmission is about to be stopped by a Stop At Block
Gap Request.
During a write transaction, a Block Gap Event interrupt is
generated when this bit is changed to 0, as a result of the
Stop At Block Gap Request being set. This status is
useful for the host driver in determining when to issue
commands during write busy.
0B No valid data
1B Transferring data
0 [7:3] r Reserved
DAT_LINE 2 r DAT Line Active
_ACTIVE This bit indicates whether one of the DAT line on SD bus
is in use 1).
0B DAT line inactive
1B DAT line active

XMC4500
XMC4000 Family

COMMAN 1 r Command Inhibit (DAT)
D_INHIBIT This status bit is generated if either the DAT Line Active
_DAT or the Read transfer Active is set to 1. If this bit is 0, it
indicates the host controller can issue the next SD
command. Commands with busy signal belong to
Command Inhibit (DAT) (ex. R1b, R5b type). Changing
from 1 to 0 generates a Transfer Complete interrupt in
the Normal interrupt status register.
Note: The SD Host Driver can save registers in the
range of 000H - 00DH for a suspend transaction
after this bit has changed from 1 to 0.
0B Can issue command which uses the DAT line
1B Cannot issue command which uses the DAT line
COMMAN 0 r Command Inhibit (CMD)
D_INHIBIT If this bit is 0, it indicates the CMD line is not in use and
_CMD the host controller can issue a SD command using the
CMD line. This bit is set immediately after the Command
register (00Fh) is written. This bit is cleared when the
command response is received. Even if the Command
Inhibit (DAT) is set to 1, Commands using only the CMD
line can be issued if this bit is 0. Changing from 1 to 0
generates a Command complete interrupt in the Normal
Interrupt Status register. If the host controller cannot
issue the command because of a command conflict error
or because of Command Not Issued By Auto CMD12
Error, this bit shall remain 1 and the Command Complete
is not set. Status issuing Auto CMD12 is not read from
this bit.
Auto CMD12 consists of two responses. In this case,
this bit is not cleared by the response of CMD12 but
cleared by the response of a read/write command.
Status issuing Auto CMD12 is not read from this bit. So
if a command is issued during Auto CMD12 operation,
host controller shall manage to issue two commands:
CMD12 and a command set by Command register.
1) DAT line active indicates whether one of the DAT line is on SD bus is in use.

XMC4500
XMC4000 Family
(a) In the case of read transactions

This status indicates whether a read transfer is executing on the SD Bus. Changing this
value from 1 to 0 generates a Block Gap Event interrupt in the Normal Interrupt Status
register, as the result of the Stop At Block Gap Request being set.
This bit shall be set in either of the following cases:
1. After the end bit of the read command.
2. When writing a 1 to Continue Request in the Block Gap Control register to restart a
read transfer.
This bit shall be cleared in either of the following cases:
1. When the end bit of the last data block is sent from the SD Bus to the host controller.
2. When a read transfer is stopped at the block gap initiated by a Stop At BlockGap
Request.
The host controller shall stop read operation at the start of the interrupt cycle of the next
block gap by driving Read Wait or stopping SD clock. If the Read Wait signal is already
driven (due to data buffer cannot receive data), the host controller can continue to stop
read operation by driving the Read Wait signal. It is necessary to support Read Wait in
order to use suspend / resume function.
(b) In the case of write transactions

This status indicates that a write transfer is executing on the SD Bus. Changing this value
from 1 to 0 generate a Transfer Complete interrupt in the Normal Interrupt Status
register.
This bit shall be set in either of the following cases:
1. After the end bit of the write command.
2. When writing to 1 to Continue Request in the Block Gap Control register to continue
a write transfer.
This bit shall be cleared in either of the following cases:
1. When the SD card releases write busy of the last data block. If SD card does not drive
busy signal for 8 SD Clocks, the host controller shall consider the card drive "Not
Busy".
2. When the SD card releases write busy prior to waiting for write transfer as a result of
a Stop At Block Gap Request.
(c) Command with busy

This status indicates whether a command indicates busy (ex. erase command for
memory) is executing on the SD Bus. This bit is set after the end bit of the command with
busy and cleared when busy is de-asserted. Changing this bit from 1 to 0 generate a
Transfer Complete interrupt in the Normal Interrupt Status register.

XMC4500
XMC4000 Family
Note: The host driver can issue cmd0, cmd12, cmd13 (for memory) and cmd52 (for
SDIO) when the DAT lines are busy during data transfer. These commands can
be issued when Command Inhibit (CMD) is set to zero. Other commands shall be
issued when Command Inhibit (DAT) is set to zero.

XMC4500
XMC4000 Family
SDMMC_HOST_CTRL
This register is used to configure the modes of the SDMMC host controller.
SDMMC_HOST_CTRL
Host Control Register (0028H) Reset Value: 00H
7 6 5 4 3 2 1 0
CARD_DE CARD_DE
HIGH_SPE DATA_TX LED_CTR
T_SIGNAL TECT_TES 0
ED_EN _WIDTH L
_DETECT T_LEVEL
rw rw rw rw rw rw

CARD_DET 7 rw Card detect signal detetction
_SIGNAL_D This bit selects source for card detection.
ETECT 0B SDCD is selected (for normal use)
1B The card detect test level is selected
CARD_DET 6 rw Card Detect Test Level
ECT_TEST_ This bit is enabled while the Card Detect Signal
LEVEL Selection is set to 1 and it indicates card inserted or not.
Generates (card ins or card removal) Interrupt when the
normal int sts enable bit is set.
0B No Card
1B Card Inserted
0 [5:3] rw Reserved
HIGH_SPEE 2 rw High Speed Enable
D_EN This bit is optional. If this bit is set to 0 (default), the host
controller outputs CMD line and DAT lines at the falling
edge of the SD clock (up to 25 MHz / 20 MHz for MMC).
If this bit is set to 1, the host controller outputs CMD line
and DAT lines at the rising edge of the SD clock (up to
50 MHz for SD / 52 MHz for MMC)
0B Normal Speed Mode
1B High Speed Mode

XMC4500
XMC4000 Family

DATA_TX_ 1 rw Data Transfer Width (SD1 or SD4)
WIDTH This bit selects the data width of the host controller. The
host driver shall select it to match the data width of the
SD card.
0B 1 bit mode
1B 4-bit mode
LED_CTRL 0 rw LED Control
This bit is used to caution the user not to remove the
card while the SD card is being accessed. If the software
is going to issue multiple SD commands, this bit can be
set during all transactions. It is not necessary to change
for each transaction.
0B LED off
1B LED on

XMC4500
XMC4000 Family
SDMMC_POWER_CTRL
This register is used to configure the SD bus power.
SDMMC_POWER_CTRL
Power Control Register (0029H) Reset Value: 00H
7 6 5 4 3 2 1 0
HARDWA
SD_BUS_
0 RE_RESE SD_BUS_VOLTAGE_SEL
POWER
T
r rw rw rw

0 [7:5] r Reserved
HARDWA 4 rw Hardware reset
RE_RES Hardware reset signal is generated for eMMC4.4 card when
ET this bit is set
SD_BUS_ [3:1] rw SD Bus Voltage Select
VOLTAG By setting these bits, the host driver selects the voltage level
E_SEL for the SD card. If an unsupported voltage is selected, the
Host System shall not supply SD bus voltage
111B 3.3V (Flattop.)
SD_BUS_ 0 rw SD Bus Power
POWER Before setting this bit, the SD host driver shall set SD Bus
Voltage Select. If the host controller detects the No Card
State, this bit shall be cleared.
0B Power off
1B Power on

XMC4500
XMC4000 Family
SDMMC_BLOCK_GAP_CTRL
This register is used to configure the block gap request.
SDMMC_BLOCK_GAP_CTRL
Block Gap Control Register (002AH) Reset Value: 00H
7 6 5 4 3 2 1 0
INT_AT_B STOP_AT
SPI_MOD READ_WA CONTINU
0 0 LOCK_GA _BLOCK_
E IT_CTRL E_REQ
P GAP
r rw rw rw rw rw rw

0 7 r Reserved
0 [6:5] rw Reserved
SPI_MOD 4 rw SPI_MODE
E SPI mode enable bit.
0B SD mode
1B SPI mode
INT_AT_B 3 rw Interrupt At Block Gap
LOCK_GA This bit is valid only in 4-bit mode of the SDIO card and
P selects a sample point in the interrupt cycle. Setting to 1
enables interrupt detection at the block gap for a multiple
block transfer. If the SD card cannot signal an interrupt
during a multiple block transfer, this bit should be set to
0. When the host driver detects an SD card insertion, it
shall set this bit according to the CCCR of the SDIO card.

XMC4500
XMC4000 Family

READ_W 2 rw Read Wait Control
AIT_CTRL The read wait function is optional for SDIO cards. If the
card supports read wait, set this bit to enable use of the
read wait protocol to stop read data using DAT[2] line.
Otherwise the host controller has to stop the SD clock to
hold read data, which restricts commands generation.
When the host driver detects an SD card insertion, it
shall set this bit according to the CCCR of the SDIO card.
If the card does not support read wait, this bit shall never
be set to 1 otherwise DAT line conflict may occur. If this
bit is set to 0, Suspend / Resume cannot be supported
0B Disable Read Wait Control
1B Enable Read Wait Control
CONTINU 1 rw Continue Request
E_REQ This bit is used to restart a transaction which was
stopped using the Stop At Block Gap Request. To cancel
stop at the block gap, set Stop At block Gap Request to
0 and set this bit to restart the transfer.
The host controller automatically clears this bit in either
of the following cases:
1. In the case of a read transaction, the DAT Line Active
changes from 0 to 1 as a read transaction restarts.
2. In the case of a write transaction, the Write transfer
active changes from 0 to 1 as the write transaction
restarts.
Therefore it is not necessary for Host driver to set this bit
to 0. If Stop At Block Gap Request is set to 1, any write
to this bit is ignored.
0B Ignored
1B Restart

XMC4500
XMC4000 Family

STOP_AT 0 rw Stop At Block Gap Request
_BLOCK_ This bit is used to stop executing a transaction at the next
GAP block gap for non- DMA transfers. Until the transfer
complete is set to 1, indicating a transfer completion the
host driver shall leave this bit set to 1. Clearing both the
Stop At Block Gap Request and Continue Request shall
not cause the transaction to restart. Read Wait is used to
stop the read transaction at the block gap. The host
controller shall honour Stop At Block Gap Request for
write transfers, but for read transfers it requires that the
SD card support Read Wait. Therefore the host driver
shall not set this bit during read transfers unless the SD
card supports Read Wait and has set Read Wait Control
to 1. In case of write transfers in which the host driver
writes data to the Buffer Data Port register, the host
driver shall set this bit after all block data is written. If this
bit is set to 1, the host driver shall not write data to Buffer
data port register. This bit affects Read Transfer Active,
Write Transfer Active, DAT line active and Command
Inhibit (DAT) in the Present State register.
0B Transfer
1B Stop
There are three cases to restart the transfer after stop at the block gap. Which case is
appropriate depends on whether the host controller issues a Suspend command or the
SD card accepts the Suspend command.
1. If the host driver does not issue Suspend command, the Continue Request shall be
used to restart the transfer.
2. If the host driver issues a Suspend command and the SD card accepts it, a Resume
Command shall be used to restart the transfer.
3. If the host driver issues a Suspend command and the SD card does not accept it, the
Continue Request shall be used to restart the transfer.
Any time Stop At Block Gap Request stops the data transfer, the host driver shall wait
for Transfer Complete (in the Normal Interrupt Status register) before attempting to
restart the transfer. When restarting the data transfer by Continue Request, the host
driver shall clear Stop At Block Gap Request before or simultaneously.

XMC4500
XMC4000 Family
SDMMC_WAKEUP_CTRL
Wakeup functionality depends on the host controller system hardware and software. The
host driver shall maintain voltage on the SD Bus, by setting SD Bus power to 1 in the
Power Control register, when wakeup event via card interrupt is desired.
SDMMC_WAKEUP_CTRL
Wake-up Control Register (002BH) Reset Value: 00H
7 6 5 4 3 2 1 0
WAKEUP_ WAKEUP_ WAKEUP_
0 EVENT_E EVENT_E EVENT_E
N_REM N_INS N_INT
r rw rw rw

0 [7:3] r Reserved
WAKEUP 2 rw Wakeup Event Enable On SD Card Removal
_EVENT_ This bit enables wakeup event via Card Removal assertion
EN_REM in the Normal Interrupt Status register. FN_WUS (Wake up
Support) in CIS does not affect this bit.
0B Disable
1B Enable
WAKEUP 1 rw Wakeup Event Enable On SD Card Insertion
_EVENT_ This bit enables wakeup event via Card Insertion assertion
EN_INS in the Normal Interrupt Status register. FN_WUS (Wake up
Support) in CIS does not affect this bit.
0B Disable
1B Enable
WAKEUP 0 rw Wakeup Event Enable On Card Interrupt
_EVENT_ This bit enables wakeup event via Card Interrupt assertion
EN_INT in the Normal Interrupt Status register. This bit can be set
to 1 if FN_WUS (Wake Up Support) in CIS is set to 1.
0B Disable
1B Enable

XMC4500
XMC4000 Family
SDMMC_CLOCK_CTRL
This register is used to configure the SD Clock.
SDMMC_CLOCK_CTRL
Clock Control Register (002CH) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
INTE INTE
SDC
RNA RNA
LOC L_C L_C
SDCLK_FREQ_SEL 0 0
K_E
LOC LOC
N
K_S K_E
rw rw r rw r rw

XMC4500
XMC4000 Family

SDCLK_ [15:8] rw SDCLK Frequency Select
FREQ_S This register is used to select the frequency of the SDCLK pin.
EL The frequency is not programmed directly; this register holds
the divisor of the Base Clock Frequency for SD clock. Only the
following settings are allowed.
8-bit Divided Clock Mode
00H base clock(10MHz-63MHz)
01H base clock divided by 2
Setting 00H specifies the highest frequency of the SD Clock.
When setting multiple bits, the most significant bit is used as
the divisor. But multiple bits should not be set. The two default
divider values can be calculated by the Base Clock Frequency
for SD Clock (48MHz).
1. 25 MHz divider value
2. 400 kHz divider value
The frequency of the SDCLK is set by the following formula:
Clock Frequency = (Base clock) / divisor.
Thus choose the smallest possible divisor which results in a
clock frequency that is less than or equal to the target
frequency.
Maximum Frequency for SD = 48 MHz (base clock)
Maximum Frequency for MMC = 48 MHz (base clock)
Minimum Frequency = 187.5 kHz (48 MHz / 256), same
calculation for MMC
0 [7:6] rw Reserved
0 [5:3] r Reserved

XMC4500
XMC4000 Family

SDCLO 2 rw SD Clock Enable
CK_EN The host controller shall stop SDCLK when writing this bit to
0. SDCLK frequency Select can be changed when this bit is
0. Then, the host controller shall maintain the same clock
frequency until SDCLK is stopped (Stop at SDCLK = 0). If the
host controller detects the No Card state, this bit shall be
cleared.
0B Disable
1B Enable
INTERN 1 r Internal Clock Stable
AL_CLO This bit is set to 1 when SD clock is stable after writing to
CK_STA Internal Clock Enable in this register to 1. The SD Host Driver
BLE shall wait to set SD Clock Enable until this bit is set to 1.
Note: This is useful when using PLL for a clock oscillator that
requires setup time.
0B Not Ready
1B Ready
INTERN 0 rw Internal Clock Enable
AL_CLO This bit is set to 0 when the host driver is not using the host
CK_EN controller or the host controller awaits a wakeup event. The
host controller should stop its internal clock to go very low
power state. Still, registers shall be able to be read and
written. Clock starts to oscillate when this bit is set to 1. When
clock oscillation is stable, the host controller shall set Internal
Clock Stable in this register to 1. This bit shall not affect card
detection.
0B Stop
1B Oscillate

XMC4500
XMC4000 Family
SDMMC_TIMEOUT_CTRL
This register is used to configure the interval for data timeout.
SDMMC_TIMEOUT_CTRL
Timeout Control Register (002EH) Reset Value: 00H
7 6 5 4 3 2 1 0
0 DAT_TIMEOUT_CNT_VAL
r rw

0 [7:4] r Reserved
DAT_TIM [3:0] rw Data Timeout Counter Value
EOUT_C This value determines the interval by which DAT line time-
NT_VAL outs are detected. Refer to the Data Time-out Error in the
Error Interrupt Status register for information on factors that
dictate time-out generation. Time-out clock frequency will
be generated by dividing the sdclock TMCLK by this value.
When setting this register, prevent inadvertent time-out
events by clearing the Data Time-out Error Status Enable
(in the Error Interrupt Status Enable register)
0000B TMCLK * 2^13
0001B TMCLK * 2^14
...
1110B TMCLK * 2^27
1111B Reserved

XMC4500
XMC4000 Family
SDMMC_SW_RESET
A reset pulse is generated when writing 1 to each bit of this register. After completing the
reset, the host controller shall clear each bit. Because it takes some time to complete
software reset, the SD Host Driver shall confirm that these bits are 0.
SDMMC_SW_RESET
Software Reset Register (002FH) Reset Value: 00H
7 6 5 4 3 2 1 0
SW_RST_ SW_RST_ SW_RST_
0
DAT_LINE CMD_LINE ALL
r rw rw rw

0 [7:3] r Reserved
SW_RST 2 rw Software Reset for DAT Line
_DAT_LI Only part of data circuit is reset. The following
NE registers and bits are cleared by this bit:
Buffer Data Port Register
Buffer is cleared and Initialized.
Present State register
Buffer read Enable
Buffer write Enable
Read Transfer Active
Write Transfer Active
DAT Line Active
Command Inhibit (DAT)
Block Gap Control register
Continue Request
Stop At Block Gap Request
Normal Interrupt Status register
Buffer Read Ready
Buffer Write Ready
Block Gap Event
Transfer Complete
0B Work
1B Reset

XMC4500
XMC4000 Family

SW_RST 1 rw Software Reset for CMD Line
_CMD_LI Only part of command circuit is reset.
NE The following registers and bits are cleared by this
bit:
Present State Register
Command Inhibit (CMD)
Normal Interrupt Status Register
Command Complete
0B Work
1B Reset
SW_RST 0 rw Software Reset for All
_ALL

XMC4500
XMC4000 Family
SDMMC_INT_STATUS_NORM
The Normal Interrupt Status Enable affects read of this register, but Normal Interrupt
Signal does not affect these reads. An Interrupt is generated when the Normal Interrupt
Signal Enable is enabled and at least one of the status bits is set to 1. For all bits except
Card Interrupt and Error Interrupt, writing 1 to a bit clears it. The Card Interrupt is cleared
when the card stops asserting the interrupt: that is when the Card Driver services the
Interrupt condition.
SDMMC_INT_STATUS_NORM
Normal Interrupt Status Register (0030H) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BUF BUF BLO
CAR TX_ CMD
CAR CAR F_R F_W CK_
ERR D_R COM _CO
0 0 D_IN D_IN EAD RITE 0 GAP
_INT EMO PLE MPL
T S _RE _RE _EV
VAL TE ETE
ADY ADY ENT
r rw r r rw rw rw rw rw rw rw rw

ERR_INT 15 r Error Interrupt
If any of the bits in the Error Interrupt Status Register
are set, then this bit is set. Therefore the host driver can
test for an error by checking this bit first.
0B No Error.
1B Error.
0 [12:9] r Reserved

XMC4500
XMC4000 Family

CARD_IN 8 r Card Interrupt
T Writing this bit to 1 does not clear this bit. It is cleared
by resetting the SD card interrupt factor. In 1-bit mode,
the host controller shall detect the Card Interrupt
without SD Clock to support wakeup. In 4-bit mode, the
card interrupt signal is sampled during the interrupt
cycle, so there are some sample delays between the
interrupt signal from the card and the interrupt to the
Host system.
When this status has been set and the host driver
needs to start this interrupt service, Card Interrupt
Status Enable in the Normal Interrupt Status register
shall be set to 0 in order to clear the card interrupt
statuses latched in the host controller and stop driving
the Host System. After completion of the card interrupt
service (the reset factor in the SD card and the interrupt
signal may not be asserted), set Card Interrupt Status
Enable to 1 and start sampling the interrupt signal
again.
Interrupt detected by DAT[1] is supported when there is
a card in slot.
0B No Card Interrupt
1B Generate Card Interrupt
CARD_R 7 rw Card Removal
EMOVAL This status is set if the Card Inserted in the Present
State register changes from 1 to 0. When the host
driver writes this bit to 1 to clear this status the status of
the Card Inserted in the Present State register should
be confirmed. Because the card detect may possibly be
changed when the host driver clear this bit an Interrupt
event may not be generated.
0B Card State Stable or Debouncing
1B Card Removed
This bit can be cleared by a software write of 1 to the
bit. A software write of 0 to the bit has no effect.

XMC4500
XMC4000 Family

CARD_IN 6 rw Card Insertion
S This status is set if the Card Inserted in the Present
State register changes from 0 to 1. When the host
driver writes this bit to 1 to clear this status the status of
the Card Inserted in the Present State register should
be confirmed. Because the card detect may possibly be
changed when the host driver clear this bit an Interrupt
event may not be generated.
0B Card State Stable or Debouncing
1B Card Inserted
BUFF_RE 5 rw Buffer Read Ready
AD_REA This status is set if the Buffer Read Enable changes
DY from 0 to 1.
0B Not Ready to read Buffer.

1B Ready to read Buffer.
BUFF_W 4 rw Buffer Write Ready
RITE_RE This status is set if the Buffer Write Enable changes
ADY from 0 to 1.
0B Not Ready to Write Buffer.
1B Ready to Write Buffer.
0 3 rw Reserved

XMC4500
XMC4000 Family

BLOCK_ 2 rw Block Gap Event
GAP_EV If the Stop At Block Gap Request in the Block Gap
ENT Control Register is set, this bit is set.
Read Transaction:
This bit is set at the falling edge of the DAT Line Active
Status (When the transaction is stopped at SD Bus
timing. The Read Wait must be supported inorder to
use this function).
Write Transaction:
This bit is set at the falling edge of Write Transfer Active
Status (After getting CRC status at SD Bus timing).
0B No Block Gap Event
1B Transaction stopped at Block Gap

XMC4500
XMC4000 Family

TX_COM 1 rw Transfer Complete
PLETE This bit is set when a read / write transaction is
completed.
Read Transaction:
This bit is set at the falling edge of Read Transfer Active
Status.
There are two cases in which the Interrupt is
generated. The first is when a data transfer is
completed as specified by data length (After the last
data has been read to the Host System). The second is
when data has stopped at the block gap and completed
the data transfer by setting the Stop At Block Gap
Request in the Block Gap Control Register (After valid
data has been read to the Host System).
Write Transaction:
This bit is set at the falling edge of the DAT Line Active
Status.
There are two cases in which the Interrupt is
generated. The first is when the last data is written to
the card as specified by data length and Busy signal is
released. The second is when data transfers are
stopped at the block gap by setting Stop At Block Gap
Request in the Block Gap Control Register and data
transfers completed. (After valid data is written to the
SD card and the busy signal is released).
Transfer Complete has higher priority than Data Time-
out Error. If both bits are set to 1, the data transfer can
be considered complete
0B No Data Transfer Complete
1B Data Transfer Complete

XMC4500
XMC4000 Family

CMD_CO 0 rw Command Complete
MPLETE This bit is set when get the end bit of the command
response (Except Auto CMD12).
Command Time-out Error has higher priority than
Command Complete. If both are set to 1, it can be
considered that the response was not received
correctly.
0B No Command Complete
1B Command Complete
Table 13-7 Relation between transfer complete and data timeout error
Transfer Data Timeout Error Meaning of the Status
Complete
0 0 Interrupted by Another Factor.
0 1 Timeout occur during transfer.
1 Dont Care Data Transfer Complete
Table 13-8 Relation between command complete and command timeout error
Command Command Timeout Meaning of the Status
Complete Error
0 0 Interrupted by Another Factor.
Dont Care 1 Response not received within 64 SDCLK cycles.
1 0 Response Received

XMC4500
XMC4000 Family
SDMMC_INT_STATUS_ERR
Status defined in this register can be enabled by the Error Interrupt Status Enable
Register, but not by the Error Interrupt Signal Enable Register. The Interrupt is generated
when the Error Interrupt Signal Enable is enabled and at least one of the statuses is set
to 1. Writing to 1 clears the bit and writing to 0 keeps the bit unchanged. More than one
status can be cleared at a single register write.
SDMMC_INT_STATUS_ERR
Error Interrupt Status Register (0032H) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CUR DAT DAT CMD CMD
DAT CMD CMD
CEA ACM REN A_E A_TI _EN _TIM
A_C _IND _CR
0 TA_ 0 0 0 D_E T_LI ND_ MEO D_BI EOU
RC_ _ER C_E
ERR RR MIT_ BIT_ UT_ T_E T_E
ERR R RR
ERR ERR ERR RR RR
r rw rw r rw rw rw rw rw rw rw rw rw rw

CEATA_ 13 rw Ceata Error Status
ERR Occurs when ATA command termination has occured
due to an error condition the device has encountered.
0B no error
1B error
0 12 rw Reserved
0 11 r Reserved

XMC4500
XMC4000 Family

ACMD_E 8 rw Auto CMD Error
RR Auto CMD12 uses this error status. This bit is set when
detecting that one of the bits D00-D04 in Auto CMD
Error Status register has changed from 0 to 1. In case
of Auto CMD12, this bit is set to 1, not only when the
errors in Auto CMD12 occur but also when Auto
CMD12 is not executed due to the previous command
error.
0B No Error
1B Error
CURREN 7 rw Current Limit Error
T_LIMIT_ By setting the SD Bus Power bit in the Power Control
ERR Register, the host controller is requested to supply
power for the SD Bus. If the host controller supports the
Current Limit Function, it can be protected from an
Illegal card by stopping power supply to the card in
which case this bit indicates a failure status. Reading 1
means the host controller is not supplying power to SD
card due to some failure. Reading 0 means that the
host controller is supplying power and no error has
occurred. This bit shall always set to be 0, if the host
controller does not support this function.
0B No Error
1B Power Fail
DATA_E 6 rw Data End Bit Error
ND_BIT_ Occurs when detecting 0 at the end bit position of read
ERR data which uses the DAT line or the end bit position of
the CRC status.
0B No Error
1B Error

XMC4500
XMC4000 Family

DATA_C 5 rw Data CRC Error
RC_ERR Occurs when detecting CRC error when transferring
read data which uses the DAT line or when detecting
the Write CRC Status having a value of other than
010.
0B No Error
1B Error
DATA_TI 4 rw Data Timeout Error
MEOUT_ Occurs when detecting one of following timeout
ERR conditions.
Busy Timeout for R1b, R5b type.
Busy Timeout after Write CRC status
Write CRC status Timeout
Read Data Timeout
0B No Error
1B Timeout
CMD_IND 3 rw Command Index Error
_ERR Occurs if a Command Index error occurs in the
Command Response.
0B No Error
1B Error
CMD_EN 2 rw Command End Bit Error
D_BIT_E Occurs when detecting that the end bit of a command
RR response is 0.
0B No Error
1B End Bit Error Generated

XMC4500
XMC4000 Family

CMD_CR 1 rw Command CRC Error
C_ERR Command CRC Error is generated in two cases.
If a response is returned and the Command Time-out
Error is set to 0, this bit is set to 1 when detecting a CRT
error in the command response
The host controller detects a CMD line conflict by
monitoring the CMD line when a command is issued. If
the host controller drives the CMD line to 1 level, but
detects 0 level on the CMD line at the next SDCLK
edge, then the host controller shall abort the command
(Stop driving CMD line) and set this bit to 1. The
Command Timeout Error shall also be set to 1 to
distinguish CMD line conflict.
0B No Error
1B CRC Error Generated
CMD_TIM 0 rw Command Timeout Error
EOUT_E Occurs only if the no response is returned within 64
RR SDCLK cycles from the end bit of the command. If the
host controller detects a CMD line conflict, in which
case Command CRC Error shall also be set. This bit
shall be set without waiting for 64 SDCLK cycles
because the command will be aborted by the host
controller.
0B No Error
1B Timeout
Table 13-9 Relation between command CRC error and command time-out error
Command CRC Command Kinds of Error
Error Time-out Error
0 0 No Error
0 1 Response Timeout Error
1 0 Response CRC Error
1 1 CMD Line Conflict

XMC4500
XMC4000 Family
SDMMC_EN_INT_STATUS_NORM
Interrupt status can be enabled by writing 1 to the bit in this register. The host controller
may sample the card Interrupt signal during interrupt period and may hold its value in the
flip-flop. If the Card Interrupt Status Enable is set to 0, the host controller shall clear all
internal signals regarding Card Interrupt.
SDMMC_EN_INT_STATUS_NORM
Normal Interrupt Status Enable Register(0034H) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CAR BUF BUF BLO TX_ CMD
CAR CAR
FIXE D_R F_R F_W CK_ COM _CO
D_IN D_IN EAD RITE GAP
D_T 0 EMO 0 PLE MPL
T_E S_E
O_0 VAL _RE _RE _EV TE_ ETE
N N
_EN ADY ADY ENT EN _EN
r rw rw rw rw rw rw rw rw rw rw

FIXED_TO 15 r Fixed to 0
_0 The host controller shall control error Interrupts using the
Error Interrupt Status Enable register.
CARD_INT 8 rw Card Interrupt Status Enable
_EN If this bit is set to 0, the host controller shall clear Interrupt
request to the System. The Card Interrupt detection is
stopped when this bit is cleared and restarted when this bit
is set to 1. The host driver may clear the Card Interrupt
Status Enable before servicing the Card Interrupt and may
set this bit again after all Interrupt requests from the card
are cleared to prevent inadvertent Interrupts.
0B Masked
1B Enabled
CARD_RE 7 rw Card Removal Status Enable
MOVAL_E 0B Masked
N 1B Enabled

XMC4500
XMC4000 Family

CARD_INS 6 rw Card Insertion Status Enable
_EN 0B Masked
1B Enabled
BUFF_RE 5 rw Buffer Read Ready Status Enable
AD_READ 0B Masked
Y_EN 1B Enabled
BUFF_WR 4 rw Buffer Write Ready Status Enable
ITE_READ 0B Masked
Y_EN 1B Enabled
0 3 rw Reserved
BLOCK_G 2 rw Block Gap Event Status Enable
AP_EVEN 0B Masked
T_EN 1B Enabled
TX_COMP 1 rw Transfer Complete Status Enable
LETE_EN 0B Masked
1B Enabled
CMD_CO 0 rw Command Complete Status Enable
MPLETE_ 0B Masked
EN 1B Enabled

XMC4500
XMC4000 Family
SDMMC_EN_INT_STATUS_ERR
Interrupt status can be enabled by writing 1 to the bit in this register. To Detect CMD Line
conflict, the host driver must set both Command Time-out Error Status Enable and
Command CRC Error Status Enable to 1.
SDMMC_EN_INT_STATUS_ERR
Error Interrupt Status Enable Register(0036H) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TAR CUR DAT DAT DAT CMD CMD CMD CMD
CEA GET ACM REN A_E A_TI _EN
A_C _IND _CR _TIM
VSES1514 TA_ D_E
_RE 0 0 T_LI ND_ RC_ MEO _ER D_BI C_E EOU
_EN ERR RR_
SP_ MIT_ BIT_ ERR UT_ R_E T_E RR_ T_E
_EN ERR EN ERR ERR ERR RR_
_EN N EN RR_

CEATA_E 13 rw Ceata Error Status Enable
RR_EN 0B Masked
1B Enabled
TARGET_ 12 rw Target Response Error Status Enable
RESP_ER 0B Masked
R_EN 1B Enabled
0 11 r Reserved
ACMD_E 8 rw Auto CMD12 Error Status Enable
RR_EN 0B Masked
1B Enabled
CURRENT 7 rw Current Limit Error Status Enable
_LIMIT_E 0B Masked
RR_EN 1B Enabled

XMC4500
XMC4000 Family

DATA_EN 6 rw Data End Bit Error Status Enable
D_BIT_ER 0B Masked
R_EN 1B Enabled
DATA_CR 5 rw Data CRC Error Status Enable
C_ERR_E 0B Masked
N 1B Enabled
DATA_TI 4 rw Data Timeout Error Status Enable
MEOUT_E 0B Masked
RR_EN 1B Enabled
CMD_IND 3 rw Command Index Error Status Enable
_ERR_EN 0B Masked
1B Enabled
CMD_EN 2 rw Command End Bit Error Status Enable
D_BIT_ER 0B Masked
R_EN 1B Enabled
CMD_CR 1 rw Command CRC Error Status Enable
C_ERR_E 0B Masked
N 1B Enabled
CMD_TIM 0 rw Command Timeout Error Status Enable
EOUT_ER 0B Masked
R_EN 1B Enabled

XMC4500
XMC4000 Family
SDMMC_EN_INT_SIGNAL_NORM
This register is used to select which interrupt status is indicated to the Host System as
the Interrupt. The interrupt line is shared by all the status bits. Interrupt generation can
be enabled by writing 1 to any of these bits.
SDMMC_EN_INT_SIGNAL_NORM
Normal Interrupt Signal Enable Register(0038H) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CAR BUF BUF BLO TX_ CMD
CAR CAR F_R F_W CK_
FIXE D_R COM _CO
D_IN D_IN
D_T 0 EMO EAD RITE 0 GAP PLE MPL
T_E S_E
O_0 VAL _RE _RE _EV TE_ ETE
N N ADY ADY ENT
_EN EN _EN

FIXED_T 15 r Fixed to 0
O_0 The host driver shall control error Interrupts using the Error
Interrupt Signal Enable register.
CARD_IN 8 rw Card Interrupt Signal Enable
T_EN 0B Masked
1B Enabled
CARD_R 7 rw Card Removal Signal Enable
EMOVAL 0B Masked
_EN 1B Enabled
CARD_IN 6 rw Card Insertion Signal Enable
S_EN 0B Masked
1B Enabled
BUFF_RE 5 rw Buffer Read Ready Signal Enable
AD_REA 0B Masked
DY_EN 1B Enabled

XMC4500
XMC4000 Family

BUFF_W 4 rw Buffer Write Ready Signal Enable
RITE_RE 0B Masked
ADY_EN 1B Enabled
0 3 rw Reserved
BLOCK_ 2 rw Block Gap Event Signal Enable
GAP_EV 0B Masked
ENT_EN 1B Enabled
TX_COM 1 rw Transfer Complete Signal Enable
PLETE_E 0B Masked
N 1B Enabled
CMD_CO 0 rw Command Complete Signal Enable
MPLETE_ 0B Masked
EN 1B Enabled

XMC4500
XMC4000 Family
SDMMC_EN_INT_SIGNAL_ERR
This register is used to select which interrupt status is notified to the Host System as the
Interrupt. The interrupt line is shared by all the status bits. Interrupt generation can be
enabled by writing 1 to any of these bits.
SDMMC_EN_INT_SIGNAL_ERR
Error Interrupt Signal Enable Register(003AH) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TAR CUR DAT DAT DAT CMD CMD CMD CMD
CEA GET ACM REN A_E A_TI _EN
A_C _IND _CR _TIM
TA_ D_E
0 _RE 0 0 T_LI ND_ RC_ MEO _ER D_BI C_E EOU
ERR RR_
SP_ MIT_ BIT_ ERR UT_ R_E T_E RR_ T_E
_EN ERR EN ERR ERR ERR RR_
_EN N EN RR_

CEATA_ERR_E 13 rw Ceata Error Signal Enable
N 0B Masked
1B Enabled
TARGET_RESP 12 rw Target Response Error Signal Enable
_ERR_EN 0B Masked
1B Enabled
0 11 r Reserved
ACMD_ERR_E 8 rw Auto CMD12 Error Signal Enable
N 0B Masked
1B Enabled
CURRENT_LIM 7 rw Current Limit Error Signal Enable
IT_ERR_EN 0B Masked
1B Enabled

XMC4500
XMC4000 Family

DATA_END_BI 6 rw Data End Bit Error Signal Enable
T_ERR_EN 0B Masked
1B Enabled
DATA_CRC_E 5 rw Data CRC Error Signal Enable
RR_EN 0B Masked
1B Enabled
DATA_TIMEOU 4 rw Data Timeout Error Signal Enable
T_ERR_EN 0B Masked
1B Enabled
CMD_IND_ERR 3 rw Command Index Error Signal Enable
_EN 0B Masked
1B Enabled
CMD_END_BIT 2 rw Command End Bit Error Signal Enable
_ERR_EN 0B Masked
1B Enabled
CMD_CRC_ER 1 rw Command CRC Error Signal Enable
R_EN 0B Masked
1B Enabled
CMD_TIMEOUT 0 rw Command Timeout Error Signal Enable
_ERR_EN 0B Masked
1B Enabled

XMC4500
XMC4000 Family
SDMMC_ACMD_ERR_STATUS
This register is used to indicate CMD12 response error of Auto CMD12. The Host driver
can determine what kind of Auto CMD12 errors occur by this register. This register is
valid only when the Auto CMD Error is set.
SDMMC_ACMD_ERR_STATUS
Auto CMD Error Status Register (003CH) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CMD ACM ACM ACM
_NO ACM ACM D12_
D_E D_TI
D_IN D_C
0 T_IS 0 ND_ MEO NOT
D_E RC_
SUE BIT_ UT_ _EX
D_B RR ERR EC_
ERR ERR
r r r r r r r r

0 15:8 r Reserved
CMD_NOT 7 r Command Not Issued By Auto CMD12 Error
_ISSUED_ Setting this bit to 1 means CMD_wo_DAT is not
BY_ACMD executed due to an Auto CMD12 error (D04 - D01) in this
12_ERR register.
0B No Error
1B Not Issued
0 [6:5] r Reserved
ACMD_IND 4 r Auto CMD Index Error
_ERR Occurs if the Command Index error occurs in response
to a command.
0B No Error
1B Error
ACMD_EN 3 r Auto CMD End Bit Error
D_BIT_ER Occurs when detecting that the end bit of command
R response is 0.
0B No Error
1B End Bit Error Generated

XMC4500
XMC4000 Family

ACMD_CR 2 r Auto CMD CRC Error
C_ERR Occurs when detecting a CRC error in the command
response.
0B No Error
1B CRC Error Generated
ACMD_TIM 1 r Auto CMD Timeout Error
EOUT_ER Occurs if the no response is returned within 64 SDCLK
R cycles from the end bit of the command.
If this bit is set to 1, the other error status bits (D04 - D02)
are meaningless.
0B No Error
1B Timeout
ACMD12_ 0 r Auto CMD12 Not Executed
NOT_EXE If memory multiple block data transfer is not started due
C_ERR to command error, this bit is not set because it is not
necessary to issue Auto CMD12. Setting this bit to 1
means the host controller cannot issue Auto CMD12 to
stop memory multiple block transfer due to some error.
If this bit is set to 1, other error status bits (D04 - D01)
are meaningless.
0B Executed
1B Not Executed

XMC4500
XMC4000 Family
Table 13-10 Relation between Auto CMD12 CRC error and Auto CMD12 timeout
error
Auto Cmd12 CRC Error Auto CMD12 Timeout Error Kinds of Error
0 0 No Error
0 1 Response Timeout Error
1 0 Response CRC Error
1 1 CMD Line Conflict
The timing of changing Auto CMD12 Error Status can be classified in three scenarios:
1. When the host controller is going to issue Auto CMD12.
a) Set D00 to 1 if Auto CMD12 cannot be issued due to an error in the previous
command.
b) Set D00 to 0 if Auto CMD12 is issued.
2. At the end bit of Auto CMD12 response.
a) Check received responses by checking the error bits D01, D02, D03, D04.
b) Set to 1 if Error is Detected.
c) Set to 0 if Error is Not Detected.
3. Before reading the Auto CMD12 Error Status bit D07
a) Set D07 to 1 if there is a command cannot be issued.
b) Set D07 to 0 if there is no command to issue.
Timing of generating the Auto CMD12 Error and writing to the Command register are
Asynchronous. Then D07 shall be sampled when driver never writing to the Command
register. So just before reading the Auto CMD12 Error Status register is good timing to
set the D07 status bit.

XMC4500
XMC4000 Family
SDMMC_FORCE_EVENT_ACMD_ERR_STATUS
The Force Event Register is an address at which the Auto CMD12 Error Status Register
can be written.
Writing 1 : set each bit of the Auto CMD12 Error Status Register
Writing 0 : no effect.
SDMMC_FORCE_EVENT_ACMD_ERR_STATUS
Force Event Register for Auto CMD Error Status(0050H) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FE_ FE_ FE_ FE_ FE_ FE_
CMD ACM ACM ACM ACM ACM
0 _NO 0 D_IN D_E D_C D_TI D_N
T_IS D_E ND_ RC_ MEO OT_
SUE RR BIT_ ERR UT_ EXE
r w r w w w w w

0 [15:8] r Reserved
FE_CMD 7 w Force Event for CMD not issued by Auto CMD12
_NOT_IS Error
SUED_A 0B No interrupt
CMD12_E 1B Interrupt is generated
RR
0 [6:5] r Reserved
FE_ACM 4 w Force Event for Auto CMD Index Error
D_IND_E 0B No interrupt
RR 1B Interrupt is generated
FE_ACM 3 w Force Event for Auto CMD End bit Error
D_END_ 0B No interrupt
BIT_ERR 1B Interrupt is generated
FE_ACM 2 w Force Event for Auto CMD CRC Error
D_CRC_ 0B No interrupt
ERR 1B Interrupt is generated
FE_ACM 1 w Force Event for Auto CMD timeout Error
D_TIMEO 0B No interrupt
UT_ERR 1B Interrupt is generated

XMC4500
XMC4000 Family

FE_ACM 0 w Force Event for Auto CMD12 NOT Executed
D_NOT_E 0B No interrupt
XEC 1B Interrupt is generated

XMC4500
XMC4000 Family
SDMMC_FORCE_EVENT_ERR_STATUS
The Force Event Register is an address at which the Error Interrupt Status register can
be written. The effect of a write to this address will be reflected in the Error Interrupt
Status Register if the corresponding bit of the Error Interrupt Status Enable Register is
set.
Writing 1 : set each bit of the Error Interrupt Status Register
Writing 0 : no effect
SDMMC_FORCE_EVENT_ERR_STATUS
Force Event Register for Error Interrupt Status(0052H) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FE_T FE_ FE_ FE_ FE_ FE_ FE_ FE_ FE_
FE_ ARG FE_ CUR DAT DAT CMD
DAT CMD CMD CMD
CEA ACM
0 ET_ 0 0 REN A_E A_C A_TI _IND _EN _CR _TIM
TA_ D12_
RES T_LI ND_ RC_ MEO _ER D_BI C_E EOU
ERR PON ERR MIT_ BIT_ UT_ T_E
ERR R RR T_E
w w w r w w w w w w w w w w

0 [15:14] w Reserved
FE_CEATA 13 w Force Event for Ceata Error
_ERR 0B No interrupt
1B Interrupt is generated
FE_TARGE 12 w Force event for Target Response Error
T_RESPO 0B No interrupt
NSE_ERR 1B Interrupt is generated
0 9 w Reserved
FE_ACMD 8 w Force Event for Auto CMD Error
12_ERR 0B No interrupt
FE_CURR 7 w Force Event for Current Limit Error
ENT_LIMIT 0B No interrupt
_ERR 1B Interrupt is generated

XMC4500
XMC4000 Family

FE_DATA_ 6 w Force Event for Data End Bit Error
END_BIT_ 0B No interrupt
FE_DATA_ 5 w Force Event for Data CRC Error
CRC_ERR 0B No interrupt
FE_DATA_ 4 w Force Event for Data Timeout Error
TIMEOUT_ 0B No interrupt
FE_CMD_I 3 w Force Event for Command Index Error
ND_ERR 0B No interrupt
FE_CMD_E 2 w Force Event for Command End Bit Error
ND_BIT_E 0B No interrupt
FE_CMD_ 1 w Force Event for Command CRC Error
CRC_ERR 0B No interrupt
FE_CMD_T 0 w Force Event for Command Timeout Error
IMEOUT_E 0B No interrupt

XMC4500
XMC4000 Family
SDMMC_DEBUG_SEL
This register is used to select the debug mode.
SDMMC_DEBUG_SEL
Debug Selection Register (0074H) Reset Value: 00000000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DEB
0 UG_
SEL
r w

0 [31:1] r Reserved
DEBUG_ 0 w Debug_sel
SEL 0B receiver module and fifo_ctrl module signals are
probed out
1B cmd register, Interrupt status, transmitter module and
clk sdcard signals are probed out.

XMC4500
XMC4000 Family
SDMMC_SPI
This register is used to configure the SPI interrupt support.
SDMMC_SPI
SPI Interrupt Support Register (00F0H) Reset Value: 00000000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 SPI_INT_SUPPORT
r rw

0 [31:8] r Reserved
SPI_INT_ [7:0] rw SPI INT SUPPORT
SUPPOR This bit is set to indicate the assertion of interrupts in the
T SPI mode at any time, irrespective of the status of the card
select (CS) line. If this bit is zero, then SDIO card can only
assert the interrupt line in the SPI mode when the CS line
is asserted.

XMC4500
XMC4000 Family
SDMMC_SLOT_INT_STATUS
This register is used to configure the interrupt signal for card slot.
SDMMC_SLOT_INT_STATUS
Slot Interrupt Status Register (00FCH) Reset Value: 0000H
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 SLOT_INT_STATUS
r r

0 [15:8] r Reserved
SLOT_IN [7:0] r Interrupt Signal for Card Slot
T_STATU These status bit indicate the Interrupt signal and Wakeup
S signal for the card slot. By a power on reset or by Software
Reset For All, the Interrupt signal shall be de asserted and
this status shall read 00H.
00H Slot 1

XMC4500
XMC4000 Family
13.13 Interconnects
The interface signals of the SDMMC Host Controller are described below.
Table 13-11 SDMMC Pin Connections

Input/ Output I/O Connected to Description
clk_xin I SCU.EXTCLK Input clock to SDMMC controller
SDMMC.CLK_IN I P3.6 Feedback clock of clk_sdcard_out
from the pads
SDMMC.DATA7_IN I P1.13 MMC8 mode: Data7 Input
SDMMC.DATA3_IN I P4.1 SD4/MMC8 mode: Data3 Input
SDMMC.DATA2_IN I P1.7 SD4/MMC8 : Data2 input
SDMMC.DATA1_IN I P1.6 SD1 mode: Interrupt
SD4 mode: Data1 Input or Interrupt
(optional)
MMC8 mode: Data1 Input
SDMMC.DATA0_IN I P4.0 SD1/SD4/MMC8 : Data0 Input
SPI mode : Command response
input, read data and crc status for
write data
SDMMC.SDCD I P1.10 Active low. Card Detection
SDMMC.SDWC I P1.1 Active High. SD Card Write Protect
SDMMC.CMD_IN I P3.5 SD1/SD4/MMC8 : Command Input
SDMMC.CLK_OUT O P3.6 Clock supplied to SD/MMC card
SDMMC.DATA7_OUT O P1.13 MMC8 mode: Data7 Output
SDMMC.DATA3_OUT O P4.1 SD4/MMC8 mode: Data3 Output
SPI mode : chip select

XMC4500
XMC4000 Family
Table 13-11 SDMMC Pin Connections (contd)

Input/ Output I/O Connected to Description
SDMMC.DATA2_OUT O P1.7 SD1 mode: Read Wait(optional)
SD4 mode: Data2 Output or Read
Wait (optional)
MMC8 mode: Data2 Output
SDMMC.DATA1_OUT O P1.6 SD4/MMC8 : Data1 Output
SDMMC.DATA0_OUT O P4.0 SD1/SD4/MMC8 : Data0 Output
SDMMC.CMD_OUT O P3.5 SD1/SD4/MMC8 : Command Output
SDMMC.BUS_POWER O P3.4 Control Card Power Supply
SDMMC.LED O P3.3 LED indication
SDMMC.RST O P0.11 Hardware reset to card
SDMMC.SR0 O NVIC Service request line

XMC4500
XMC4000 Family
SDMMC controller I/O Port

rst_n SDMMC.RST
clk_sdcard_out SDMMC.CLK_OUT
clk_sdcard_in
OUT_EN
DATA0 OUT SDMMC.DATA0_OUT
IN
OUT_EN
IN
OUT_EN
IN
OUT_EN
IN
OUT_EN
IN
OUT_EN
IN
OUT_EN
IN
OUT_EN
IN
OUT_EN
CMD OUT SDMMC.CMD
IN
bus_pow SDMMC.BUS_POWER
led_on SDMMC.LED
SDCD_n SDMMC.SDCD
SDWP SDMMC.SDWC
Figure 13-4 External Pin Connections of SDMMC

XMC4500
XMC4000 Family
14 External Bus Unit (EBU)

The EBU controls the transactions between external memories or peripheral units, and
the internal memories and peripheral units. Several external device configurations are
supported with little or no additional circuitry, making the EBU a very powerful peripheral
for expansion and support of several applications.
14.1 Overview
The Memory Controller module for ARM-based systems connects on-chip controller
cores (e.g. ARM9EJ CPU, DMA Controller) to external resources such as memories and
peripherals. Figure 14-1 shows Memory Controller within a typical system.
Several type of external memories are supported, such as: Burst FLASH, Cellular RAM,
SDRAM or NAND.
Any AHB master can (in conjunction with an AHB Bus Matrix) access external memories
through the Memory Controller.
XIP Burst SDRAM

Flash
Memory
Interface
Data Flash Peripheral
Figure 14-1 Typical External Memory System
14.1.1 Features
External bus frequency: Module frequency: flash clock = 1:1, 1:2, 1:3 or 1:4.
External bus frequency: Module frequency: SDRAM clock = 1:1, 1:2, or 1:4.
Highly programmable access parameters.
Intel-style peripheral/device support.
Burst FLASH support (see Section 14.12 for specific device types).
Cellular RAM support (see Section 14.12 for specific device types).
SDRAM support (see Section 14.13 for specific device types).
NAND flash
Asynchronous static memory device e.g. ROM, RAM, NOR Flash

EBU, V1.4 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Multiplexed access (address & data on the same bus)

Data Buffering: Two read buffers. One write buffer.
Multiple (four) programmable address regions.
Little-endian support.

Figure 14-2 shows the block diagram of the EBU. The AHB2IF bridge translates the
transactions into requests that can be handled by the arbiter block. The arbiter after
receiving the transaction requests, it forwards them to the appropriate state machine.
The dedicated state machines are used to sequence the control signals and to
coordinate accesses, to each of the different external memory/device types.
Clock Mode
Clock Source Switch
Control
Transaction Address (28-bit)
Data & Address Path Address &

Write Data (32-bit)
Data
External Bus 8-word Read
Arbitration I/F Read Data Buffer (8x32-bit) 8-word Read
Arbitration Data Buffer
Transaction Data Buffer
Request Arbiter
Burst-Flash State Machine
Control
Lines
Asynchronous
(& NAND Flash)
Internal I/F Data (32-bit) AHB2IF State Machine
Internal I/F Address (28-bit) Burst Capable SDRAM State Machine

Bridge
Region Select (5)
(8-word Write Control Registers
Buffer) Transaction
& Select
Region
Selector
Figure 14-2 EBU Block Diagram

XMC4500
XMC4000 Family
14.2 Interface Signals

The external EBU interface signals are listed in Table 14-1 below.
Table 14-1 EBU Interface Signals

Signal/Pin Type Function
AD[31:0] I/O Multiplexed Address/Data bus lines 0-31
A[24:16] O Address bus lines 16-24
CS[3:0] O Chip select 0-3
RD O Read control line
RD/WR O Write control line
ADV O Address valid output
BC[3:0] O Byte control lines 0-3
BFCLKO O Clock Output for Synchronous Accesses
BFCLKI I Feedback clock input for Synchronous Accesses
SDCLKO O Clock Output for SDRAM Accesses
SDCLKI I Feedback Clock for SDRAM Clock Output
CKE O Clock Enable Output for SDRAM
RAS O Row Address Strobe for SDRAM
CAS O Column Address Strobe for SDRAM
WAIT I Wait input
HOLD I Hold request input
HLDA I/O Hold acknowledge
BREQ O Bus request output
14.2.1 Address/Data Bus, AD[31:0]

This bus transfers address and data information. The width of this bus is 32 bits. External
devices with 8, 16 or 32 bits of data width can be connected to the data bus. Burst Mode
instruction fetches can be performed with only 32 or 16 bit data bus width. 8 bit devices
have to be treated as 16 bit devices and data alignment accomplished using software.
The EBU adjusts the data on the data bus to the width of the external device, according
to the programmed parameters in its control registers. The byte control signals BC[3:0]
specify which parts of the data bus carry valid data.

XMC4500
XMC4000 Family
14.2.2 Address Bus, A[24:16]

The total address bus of the EBU consists of 25 address output lines, giving a directly
addressable range of up to 128 Mbyte (225 * 32-bit). A[15:0] will be output on AD[31:16]
restricting support for devices using separate address and data buses to those with a 16
bit data bus. An external device can be selected via one of the chip select lines. Since
there are four chip select lines, four such devices with up to 512 Mbyte of address range
can be used in the external system.
14.2.3 Chip Selects, CS[3:0]

The EBU provides up to four chip select outputs, CS0, CS1, CS2 and CS3. The address
range for each chip select is fixed. More details are described on Section 14.7.2.
14.2.4 Read/Write Control Lines, RD, RD/WR

Two lines are provided to trigger the read (RD) and write (RD/WR) operations of external
devices. While some read/write devices require both signals, there are devices with only
one control input. The RD/WR line is then used for these devices. This line will go to an
active-low level on a write, and will stay inactive high on a read. The external device
should only evaluate this signal in conjunction with an active chip select. Thus, an active
chip select in combination with a high level on the RD/WR line indicates a read access
to this device.
14.2.5 Address Valid, ADV

The address valid signal, ADV, validates the address lines A[23:0] (and also the address
placed on the data bus AD[31:0] when attaching multiplexed address/data devices). It
can be used to latch these addresses externally.
14.2.6 Byte Controls, BC[3:0]

The byte control signals BC[3:0] select the appropriate byte lanes of the data bus for both
read and write accesses. Table 14-2 shows the activation on access to a 16-bit or 8-bit
external device. Please note that this scheme supports little-endian devices.
Table 14-2 Byte Control Pin Usage

Width of External Device BC3 BC2 BC1 BC0
32-bit device D[31:24] D[23:16] D[15:8] D[7:0]
with byte write capability

XMC4500
XMC4000 Family
Table 14-2 Byte Control Pin Usage (contd)

Width of External Device BC3 BC2 BC1 BC0
16-bit device inactive inactive D[15:8] D[7:0]
with byte write capability (high) (high)
8-bit device inactive inactive inactive D[7:0]
(high) (high) (high)
Signals BCx can be programmed for different timing. The available modes cover a wide
range of external devices, such as RAM with separate byte write-enable signals, and
RAM with separate byte chip select signals. This allows external devices to connect
without any external glue logic.
Table 14-3 Byte Control Signal Timing Options

Mode BUSCONx.BCG Description
EN
Chip Select Mode 00B BCx signals have the same timing as the
generated chip select CS.
Control Mode 01B BCx signals have the same timing as the
generated control signals RD or RD/WR.
Write Enable Mode 10B BCx signals have the same timing as the
generated control signal RD/WR.
14.2.7 Burst Flash Clock Output/Input, BFCLKO/BFCLKI

The flash clock output signal of the EBU is provided at pin BFCLKO. It is used for timing
purposes (timing reference) during Burst Mode accesses. BFCLKO is, by default, only
generated during synchronous accesses.
The clock input BFCLKI of the EBU is used to latch read data into the EBU. Normally
BFCLKI is directly fed back and connected to BFCLKO. This feedback path can be
configured externally to maximize the operating frequency for a given Flash device or to
compensate the BFCLKO clock pad delay. More details are given on Section 14.12.4.
14.2.8 Wait Input, WAIT

This is an input signal to the EBU that is used to dynamically insert wait states into read
or write data cycles controlled by the device on the external bus.

XMC4500
XMC4000 Family
14.2.9 SDRAM Clock Output/Input SDCLKO/SDCLKI

The EBU provides a clock output for SDRAM devices on the SDCLKO pin. SDCLKO is,
by default, a continuously running signal but can also be configured to switch off between
accesses to conserve power.
The feedback clock input, SDCLKI, is used as a timing reference for the capture of read
data on SDRAM accesses. It should be connected via a PCB trace to the clock pin of the
SDRAM device.
14.2.10 SDRAM Control Signals, CKE, CAS and RAS

These signals implement, along with the RD/WR signal, the command interface for an
attached SDRAM memory device.
14.2.11 Bus Arbitration Signals, HOLD, HLDA, and BREQ

The HOLD input signal is the external bus arbitration signal that indicates to the EBU
when an external bus master requests to obtain ownership of the external bus.
The HLDA is used as input or output depending on the arbitration mode. With this signal
the bus master informs the participant that ownership of the external bus has been
obtained.
The BREQ output signal is the external bus arbitration signal that is asserted by the EBU
when it requests to obtain back the ownership of the external bus.
14.2.12 EBU Reset

The EBU is asynchronously initialized by the system reset.
14.2.12.1 Allocation of Unused Signals as GPIO

The EBU will allow pins not required for its programmed configuration to be allocated for
use as GPIO. The signals required are as defined below:
Table 14-4 EBU Interface Signals Required by Operating Mode

Signal/Pin When Needed by EBU
AD[15:0] Always needed when the EBU is enabled.
RD MODCON.ARBMODE != 00B1)
RD/WR
BC[1:0]

XMC4500
XMC4000 Family
Table 14-4 EBU Interface Signals Required by Operating Mode (contd)

WAIT This signal is required by the EBU when any enable region is
configured to use WAIT by setting the BUSCONx.WAIT field to a
value other than 00B
(MODCON.ARBMODE != 00B) AND
(ADDRSELx.REGENAB=1B OR
ADDRSELx.ALTENAB=1B)
AND (BUSRCONx.WAIT != 00B)
A[24:16] These address bits can be individually enabled for use as GPIO by
setting the relevant enable bit in the USERCON register. Setting
MODCON.ARBMODE = 00B will also enable for GPIO.
ADV The ADV output can be made available for GPIO by setting the
relevant bit in the USERCON register. Setting MODCON.ARBMODE
= 00B will also enable for GPIO.
BFCLKO These signals are required by the EBU when the EBU is enabled and
BFCLKI an enabled region is configured for burst device support
BFCLKI can be driven from BFCLKO when configuring the chip
internal feedback in the PORTS
AND (BUSRCONx.AGEN = 1H OR 3H OR 5H OR 7H)
RAS These signals are required by the EBU when the EBU is enabled and
CAS an enabled region is configured for SDRAM support
CKE ((ADDRSELx.REGENAB=1B OR
SDCLKO ADDRSELx.ALTENAB=1B)
SDCLKI AND (BUSRCONx.AGEN = 1000B)
HOLD These signals are required by the EBU when the EBU is configured
BREQ to arbitrate for the external bus. e.g. MODCON.ARBMODE = 01B or
10B
HLDA

XMC4500
XMC4000 Family
Table 14-4 EBU Interface Signals Required by Operating Mode (contd)

AD[31:16] These signals are required by the EBU when the EBU is enabled and
BC[3:2] an enabled region is configured for accessing 32 bit memory or a
non-muxed memory type
(((ADDRSELx.REGENAB=1B OR
AND (BUSRCONx.PORTW = 10B or 11B) OR
(BUSCONx.AGEN = non muxed device type))
Availability of pins AD[31:30] as GPIO is controlled directly by the
PORTS module. These pins can be used as GPIO.
CS[3:0] The Chip select lines are individually controlled and will be required
for EBU operation when the associated memory region is enabled.
1) If the EBU is disabled by writing 00 to the EBUCON.ARBMODE field, there will be a delay before the signals
become available for GPIO usage as the EBU will wait for all pending external memory accesses to be
completed and the arbitration logic to return to the nobus state before releasing the signals.
14.3 External Bus States when EBU inactive

The state of the various bus signals is controlled by the EBU during inactive states as
listed below. Note that in the XMC4500 the PORTS unit disables the EBU port control
lines during reset. The lines must be explicitly enabled by the user software.
Table 14-5 Memory Controller External Bus pin states during reset
Pin Name State during Reset and State during Idle2)
no bus mode1)
AD(31:0) GPIO High Impedance - pull ups enabled
to pull to 1.
A(24:16) GPIO Driven to 0 after reset, otherwise
last used address
CS(3:0) GPIO Driven to 1 (High).
RD GPIO Driven to 1 (High).
WR GPIO Driven to 1 (High).
CAS GPIO Driven to 1 (High).
RAS GPIO Driven to 1 (High).

XMC4500
XMC4000 Family
Table 14-5 Memory Controller External Bus pin states during reset (contd)
Pin Name State during Reset and State during Idle2)
no bus mode1)
CKE GPIO Dependant on SDRAM
clocking/power save mode
ADV GPIO Driven to 1 (High).
SDCLKO GPIO Dependant on SDRAM
clocking/power save mode
SDCLKI GPIO High Impedance
BFCLKI GPIO High Impedance
BFCLKO GPIO Driven to 0 (Low).
BC(3:0) GPIO Driven to 1 (High).
WAIT GPIO Always an input (must have a pull-
resistor to inactive state).
1) GPIO controlled pins should be high impedance with pull up during reset, except for CKE which should be high
impedance with pull down.
2) Assuming that the pins have not been made available as GPIO.
Applicable reset is cgu_con_clk_rst_n_i.
14.4 Memory Controller Structure

The AHBIF bridges translate AHB transactions into appropriate transaction requests
which can be transferred to the arbiter (see Section 14.5).
The arbiter looks at the transaction requests and schedules corresponding requests to
the relevant state machine. Only one state machine can be active at any time. The
dedicated state machines are used to sequence control signals and to co-ordinate
accesses to each of the different external memory/device types and also the internal
registers.

XMC4500
XMC4000 Family
Clock Mode
Clock Source Switch
Control
Transaction Address (28-bit)
Data & Address Path Address &

Write Data (32-bit)
Data
External Bus 8-word Read
Arbitration I/F Read Data Buffer (8x32-bit) 8-word Read
Arbitration Data Buffer
Transaction Data Buffer
Request Arbiter
Burst-Flash State Machine
Control
Lines
Asynchronous
(& NAND Flash)
AHB Data (32-bit) AHB2IF State Machine
AHB Address (28-bit) Burst Capable SDRAM State Machine

Bridge
Region Select (5)
(8-word Write Control Registers
Buffer) Transaction
& Select
Region
Selector
Figure 14-3 Memory Controller Block Diagram
14.5 Memory Controller AHBIF Bridge

As shown in the Memory Controller Block Diagram (Figure 14-3) Memory Controller
contains an EBU specific AHBIF bridge. This bridge supports the AHB-lite protocol which
means (among other things) that masters are not allowed to perform early burst
termination (except after an error response) and that retries are not generated by slaves.

XMC4500
XMC4000 Family
AHB Write data (32 bit) Write Burst Buffer

Write FIFO Data Write Data (16 bit)
(FIFO per AHB Port) Write Data Mux
AHB Control Signals
Transaction Request Transaction Request

Transaction
AHB Address Bus Error Transaction Scheduler
Request
Decode
Latch Transaction Ack
Transaction Ack
AHB Response Signals
Read Burst Buffer Read Data (16 bit)

Read FIFO Data
AHB Read Data (32 bit) Read Data Mux
Figure 14-4 AHB Bridge Block Diagram

The bridges map the AHB accesses into appropriate external memory/device
transaction requests. Only a limited subset of AHB transactions are supported optimally
in order to simplify and reduce the area of the design. All other AHB transactions are split
into single data phases and passed to the core logic as multiple accesses.
Table 14-6 Supported AHB Transactions

AHB Transfer Type Support1)
Transfer Comment Type
Size
Byte Aligned to any byte address single Yes
(8 bits) others No (split)
Half- Aligned to any half-word single Yes
Word address others No (split)
(16-bits)
Word Aligned to any word address single Yes
(32-bits) incr4 Yes (if address aligned,
otherwise split))
incr8 Yes (if address aligned,
otherwise split))
wrap8 Yes
others No (split)
1) Unsupported transactions are split into multiple, 32 bit data transfers

XMC4500
XMC4000 Family
The bridge contains a Write Burst Buffer which allows the bridge to accept a complete
AHB Write Access prior to generation of the matching Write Transaction Request.
The bridge can be operated either Synchronously or Asynchronously. Support is
provided for dynamic switching of clocking modes (see Section 14.6.1).
The AHB port is configured with a 8 x 32-bit word write buffer and supports all AHB
transactions.
Byte and half-word transfers are supported for all transactions from external memory
shown in the Table 14-6. Byte accesses may be aligned to any byte boundary. Half-word
accesses may be aligned to any half-word boundary.
The Memory Controller will ensure that the limitations of external memories are
transparent to the AHB interfaces. If an AHB request cannot be directly mapped to an
access supported by the external memory, the Memory Controller will split and realign
the access into transfers supportable by the external memory. The most noticeable
effects of this are:
1. All burst accesses to an external memory are realigned so that the lowest address
is fetched first (unless specifically disabled using BUSRCON[3:0].dba)
This prevents unexpected interaction between AHB access wrapping and any
wrapping built into external memories such as SDRAM or burst flash.
2. An AHB, burst access to an asynchronous memory such as SRAM will result in
multiple accesses on the external bus as the Memory Controller fetches enough
single words from the memory to complete the burst
14.5.1 AHB Error Generation

The bridge generates AHB Error Events as appropriate. There are several types of AHB
Error Events which can be generated by Memory Controller. These errors are:-
1. Access to disabled region: If an access is attempted to a memory region which is
disabled then an AHB Error Response is returned (i.e. the AHB access is terminated
with an error). Note that the region can be disabled for reads and/or writes separately.
2. Illegal Register Access: Register accesses must ONLY be 32-bit accesses. Write
accesses must be performed with HPROT in privilege mode. Any write accesses
attempted in user mode, or any type of access attempted as either an 8-bit or 16-bit
transfer, or a burst will be terminated with an AHB Error Response.
Once a phase of a transaction has been errored, the initiating master is allowed to
terminate the burst without completing the remaining phases. This is the only case in
which the memory controller supports early burst termination.
14.5.2 Read Data Buffering

The memory controller contains two, identical read buffers with a capacity of eight 32-bit
words. A read access will be allowed to proceed if one of the buffers is flagged as
available. The data read from the external memory will be stored in the read buffer and

XMC4500
XMC4000 Family
the outputs from the read buffer will be multiplexed to the AHB port. Once the AHB port
signals that all data has been returned to the requesting AHB master, the read buffer will
again be flagged as available.
This architecture allows reads to be in progress simultaneously, as a second read can
be running while the first read is still waiting for data to be returned to the AHB master.
14.5.3 Write Data Buffering

The data for all AHB writes are posted into a buffer in the AHB interface before the
access is passed to the state machine blocks for execution.
14.6 Clocking Strategy and Local Clock Generation

The Memory Controller can be configured to operate from several possible clock
sources. The clock generation logic is used to select between these clock sources and
generate the internal clock used for the memory controller, EBU_CLK.
14.6.1 Clocking Modes

The bridges can be operated in one of three modes:-
Asynchronous: The AHB clock and Memory Controller internal clock (EBU_CLK) are
assumed to be asynchronous. EBU_CLK is derived from a dedicated clock source
Synchronous: The EBU_CLK is derived from the AHB bus clock . The CLK and AHB
interface clocks have aligned edges (although pulse swallowing can be used on the
AHB interface clock, so that the AHB interfaces run at the same speed as the rest of
the bus matrix).
Divide by 2: The EBU clock is running at half the frequency of the AHB bus clock .
The EBU clock is edge aligned with the processor and AHB interface clock.
The clock for the AHB interface of the memory controller must always be derived from
the same synchronous source (the AHB bus clock).
Operation of the bridge in Asynchronous mode provides maximum flexibility in clocking
different domains at different frequencies. This is, however, at the cost of additional
latency (for signal resynchronisation) through the bridge.
Operation of the bridge in synchronous mode minimizes the latency through the bridge
at the cost of forcing the AHB and EBU_CLK domains to run from the same source clock
(the AHB bus clock).
The mode of operation of the bridge is controlled by the EBUCLC.SYNC register field.
The EBUCLC.SYNCACK field will be updated to report the current operating mode.
The CLC.SYNC register field can be used (dynamically) to switch between these two
modes. The Memory Controller contains internal control logic to sequence the switching
between modes to ensure that external bus accesses are not corrupted as a result of
switching clocking modes. The Memory Controller updates the CLC.SYNCACK to signal

XMC4500
XMC4000 Family
the status of the bridge (1 = operating in Synchronous Mode, 0 = operating in

Asynchronous Mode).
If CLC.DIV2 is set to 0B, then EBU.CLC.SYNC also controls the clock input and switches
it between the AHB bus clock and the dedicated EBU clock source from the Clock
Generation Unit.
However, if EBUCLC.DIV2 is set to 1B, then EBU clock source is forced to be half the
frequency of the AHB bus clock and EBUCLC.SYNC only enables and disables the
resynchronisation stages necessary for asynchronous operation. Setting
EBUCLC.SYNC to 0B will only activate the resynchronisation stages, the EBU clock will
remain fixed at half the AHB bus clock frequency. The value of DIV2 in use by the
memory controller is stored in the EBUCLC.DIV2ACK field.
Local Clock Divider

A local divider can be used to reduce the frequency of EBU_CLK. The divider can be
programmed to for divide ratios of 1:1, 2:1, 3:1 or 4:1 using the EBUCLC.DIV register
field. The ratio currently in use is provided in the EBUCLC.DIVACK register field.
The purposes of the divider is to allow the memory controller core to operate
synchronously at an integer divide ratio of the AHB bus clock.
If a divide ratio other than 1:1 is selected using the local clock divider and a memory
device is being used at a 1:1 external clock ratio, then the device clock outputs BFCLKO
and SDCLKO will not have a 50% duty cycle. This is because the local divider operates
by pulse swallowing the module input clock to generate EBU_CLK.
Memory
Controller
AHB Bridge
AHB Data (32-bit) Data Core
INT_CLK
domain
HCLK domain
AHB Address (28-bit) Transaction
INT_CLK
Pulse
fCPU Swallowing
Clock Divide
fEBU
Clock Control
Figure 14-5 AHB/Memory Controller Clocking Domains (Simplified Block

Diagram)

XMC4500
XMC4000 Family
14.6.1.1 Clock Requirements

The Memory Controller has the ability to clock SDRAM and other synchronous memory
devices at the same frequency as the Memory Controller core logic. In this case, using
pulse swallowing on the clock inputs can cause the asymmetric clock waveform
generated by pulse swallowing to violate clock pulse width parameters of the connected
devices.
This is particularly important when using SDRAM at the maximum supported frequency
of the device.
14.6.2 Standby Mode

The Memory Controller can be configured to disable its internal clock and enter standby
mode by writing a logic 1 to the EBUCLC.DISR register field.
Once the register field is written, the Memory Controller will wait for any running
accesses to finish and will then disable the clock to the core logic of the Memory
Controller (EBU_CLK). As this will also disable the refresh counters, it is necessary to
set the SDRMREF.AUTOSELFR register field if this mode is to be used with SDRAM.
This will instruct the EBU to place any attached SDRAM into self refresh mode before
allowing clock mode switching or standby.
Note: For the purposes of standby mode, AHB accesses which are split by the AHB
interfaces into multiple accesses to the memory controller count as multiple
accesses. This means that the memory controller will attempt to enter standby
mode at the end of the current data transfer, not at the end of the final data transfer
of the AHB access.
An access arriving on any of the Memory Controller, AHB interfaces will trigger an
automatic exit from standby mode to service the access request. This condition may also
prevent standby mode being entered at all depending upon when the new access arrives
at the AHB interface.
Note: Once a pending AHB access has triggered an exit from standby mode, if all
pending AHB accesses have been serviced and the ARM is still in standby wait
for interrupt mode, the EBU will not return to standby mode.
An automatic exit from standby mode will not clear the EBUCLC.DISR field. This has to
be explicitly written with 0 by software before writing another 1 will trigger a further
entry to standby mode.
14.7 External Bus Operation

The EBU supports interconnection to a wide variety of memory/peripheral devices with
flexible programming of the access parameters. In the following sections, the basic
features for these access modes are described. The types of external access cycles
provided by the EBU are:

XMC4500
XMC4000 Family
Asynchronous and synchronous devices with demultiplexed access

ROMs, EPROMs
NOR flash devices
Static RAMs and PSRAMs
Asynchronous and synchronous devices with multiplexed access
NOR flash devices
PSRAMs
SDRAM Memories
Note: Not all memory types supported by the memory controller are known to be
available in all quality grades.
Each internal AHB master can access external devices via the EBU. The EBU provides
four user-programmable external memory regions. Each of these regions is provided
with a set of registers that determine the parameters of the external bus transaction and
one chip select signal. An AHB transaction that matches one of these external memory
regions is translated by the EBU to the appropriate external access(es).
The address space of each of the four regions and the registers is defined at the system
level by the address decoder in the AHB bus matrix.
14.7.1 External Memory Regions

The memory controller of the XMC4500 supports four memory regions, which have its
own associated chip select outputs CS[3:0]. Each of these regions has a set of control
registers to specify the type of memory/peripheral device and the access parameters.
Each of the four user-programmable regions (x = 0-3 is the numbering index of these
regions) is can be configured to respond to a particular address space through registers
ADDRSELx,
The access parameters for each of the regions can be programmed individually to
accommodate different types of external devices. Separate control registers are
available to control read and write accesses. This allows optimal access types, speeds
and parameters to be chosen. Access type is configured via BUSRCONx and
BUSWCONx. Access parameters are configured via BUSRAPx and BUWAPx.
Throughout this document the generic term BUSCONx is used when either of
BUSRCONx or BUSWCONx is applicable and BUSAPx is used when either of
BUSRAPx or BUSWAPx is applicable.

XMC4500
XMC4000 Family
Table 14-7 EBU Address Regions, Registers and Chip Selects

Region Associated Address Select Bus Bus Access
Chip Registers Configuration Parameters
Select Registers Registers
Region 0 CS0 ADDRSEL0 BUSRCON0 BUSRAP0
BUSWCON0 BUSWAP0
BUSWCON1 BUSWAP1
BUSWCON2 BUSWAP2
BUSWCON3 BUSWAP3
Table 14-8 lists the programmable parameters that are available for the four external
regions (regions 0 to 3).
Table 14-8 Programmable Parameters of Regions

Register Parameter Function
(Bit/Bit field)
ADDRSELx WPROT Write Protect bit for each region.
ALTENAB Alternate segment enable of a region.
REGENAB Enable bit for each region.
BUSCONx AGEN Region access type: See Section 14.7.3
14.7.2 Chip Select Control

The EBU generates four chip select signals, CSx, which are all available at dedicated
chip select outputs.
14.7.3 Programmable Device Types

Each CS region (0 to 3) can be individually configured using the BUSCONx.AGEN
register field, to be connected to one of the following external memory/device types:
Table 14-9 AGEN description

AGEN value Device Type
0 Muxed Asynchronous Type External Memory (default after reset)
1 Muxed Burst Type External Memory

XMC4500
XMC4000 Family
Table 14-9 AGEN description (contd)

AGEN value Device Type
2 NAND flash (page optimized)
3 Muxed Cellular RAM External Memory
4 Demuxed Asynchronous Type External Memory
5 Demuxed Burst Type External Memory
6 Demuxed Page Mode External Memory
7 Demuxed Cellular RAM External Memory
8 SDRAM External Memory
9 reserved
10 reserved
11 reserved
12 reserved
13 reserved
14 reserved
15 reserved
14.7.4 Support for Multiplexed Device Configurations

Memory Controller supports a number of configurations of Multiplexed
memory/peripheral devices using different values of the BUSRCONx.PORTW bit-field.
The BUSWCONx registers also contain the PORTW field but in this case the field is read
only and reflects the value set in the related one of the BUSRCONx registers. The values
set in the BUSRCONx registers are used for both read and write accesses.
Note: When using multiplexed devices a non-zero recovery phase is mandatory for all
devices to prevent read data from one access conflicting with the address for the
multiplexed memory.
Table 14-10 Pins used to connect Multiplexed Devices to Memory Controller

Memory Memory Controller Pins Section
Device A(24:16) 1)
AD(31:16) 2)
AD(15:0)
Configuration
16-bit MUX A(24:16) - A(15:0)/ 16-bit Multiplexed
D(15:0) Memory/Peripheral
Configuration

XMC4500
XMC4000 Family
Table 14-10 Pins used to connect Multiplexed Devices to Memory Controller

Device A(24:16)1) AD(31:16)2) AD(15:0)
Configuration
Twin 16-bit A(24:16) A(15:0)/ A(15:0)/ Twin 16-bit Multiplexed
MUX D(31:16) D(15:0) Device Configuration
32-bit MUX - A(31:16)/ A(15:0)/ 32-bit Multiplexed
D(31:16) D(15:0) Memory/Peripheral
Configuration
1) These pins are always outputs which are connected to address pins on the Multiplexed device(s)
2) These pins are dual function and act as AD(31:16) when required for 32-bit, multiplexed devices
Table 14-11 Selection of Multiplexed Device Configuration

PORTW value
00B reserved
01B 16-bit multiplexed1)
10B Twin, 16-bit Multiplexed2)
11B 32 bit multiplexed3)
1) Address will only be driven onto AD(15:0) during the address and address hold
phases. A(15:0) will be driven with address for duration of access
2) Lower 16 bits of address will be driven onto both A(15:0) and AD(15:0) during the
address and address hold phases
3) Full address will be driven onto A(15:0) and AD(15:0) during the address and address
hold phases
16-bit Multiplexed Memory/Peripheral Configuration

Throughout the complete external bus cycle the address1) is driven onto Memory
Controller pins A(24:16). During the address phase the low 16 bits of the address are
driven to Memory Controller pins AD(15:0). Data (16-bit) is driven to/read back from the
AD(15:0) pins during the data phase. The interconnect between Memory Controller and
a 16-bit Multiplexed device in this mode is shown below (note: for clarity only the
address/data signals are shown):-
1) This address is pre-aligned according to the bus width as detailed in Section 14.7.7.

XMC4500
XMC4000 Family
Memory Controller
Memory/Peripheral A(MAX:16)
A(MAX:16)
AD(15:0) AD(15:0)
Figure 14-6 Connection of a 16-bit Multiplexed Device to Memory Controller
Twin 16-bit Multiplexed Device Configuration

This mode allows the use of two 16-bit multiplexed devices to create a 32-bit wide bus.
Controller pins A(24:0). During the address phase the low 16 bits of the address are
driven (in parallel) to Memory Controller pins AD(15:0) and AD(31:16). This ensures that
both multiplexed devices are issued with the same address during the address phase.
Data (32-bit) is written to/read from the AD(31:16) pins for MSW and the AD(15:0) pins
for LSW during the data phase. The interconnect between Memory Controller and two
16-bit Multiplexed devices in this mode is shown below (note: for clarity only the
Memory/Peripheral
A(MAX:16)
AD(15:0)
MEMORY
CONTROLLER
A(MAX:16)
AD(31:16)
AD(15:0) AD(15:0)
Figure 14-7 Connection of twin 16-bit Multiplexed Devices to Memory Controller

XMC4500
XMC4000 Family
32-bit Multiplexed Memory/Peripheral Configuration

During the address phase the lower 16 bits of the 25 bit address are driven to Memory
Controller pins AD(15:0), the most significant 9 bits of the address are driven to pins
AD(24:16) and pins AD(31:17) are driven with 0 (zero). Data (32-bit) is driven to/read
from the AD(31:0) pins during the data phase. The interconnect between Memory
Controller and a 32-bit Multiplexed device in this mode is shown below (note: for clarity
only the address/data signals are shown):-
Memory Controller
AD(31:0) AD(31:0)
Figure 14-8 Connection of a 32-bit Multiplexed Device to Memory Controller
14.7.5 Support for Non-Multiplexed Device Configurations

The Memory Controller supports 16-bit non-multiplexed memory devices.
Table 14-12 Pins used to connect non-multiplexed Devices to Memory

Controller
Device A(24:16) 1)
AD(31:16) AD(15:0)
Configuration
16-bit non-MUX A(24:16) A(15:0) D(15:0) 16-bit non-
Multiplexed
Memory/Peripheral
Configuration
1) These pins are always outputs which are connected to address pins on the device(s)
Table 14-13 Selection of non-Multiplexed Device Configuration

PORTW value
00B reserved
01B 16-bit1)

XMC4500
XMC4000 Family
Table 14-13 Selection of non-Multiplexed Device Configuration (contd)

PORTW value
10B reserved
11B 32-bit - not supported
1) Address will only be driven onto AD(15:0) during the address and address
hold phases. AD(31:16) will be driven with address for duration of access
16-bit non-Multiplexed Memory/Peripheral Configuration

Controller pins A(24:16) and AD(15:0). Data (16-bit) is driven to/read back from the
AD(15:0) pins during the data phase. The interconnect between Memory Controller and
a 16-bit non-Multiplexed device in this mode is shown below (note: for clarity only the
Memory Controller
Memory/Peripheral
A(MAX:0) A(MAX:16)
AD(31:16)
D(15:0) AD(15:0)
Figure 14-9 Connection of a 16-bit non-Multiplexed Device to Memory Controller
14.7.6 AHB Bus Width Translation

If the internal access width is wider than the external bus width specified for the selected
external region, the internal access is split in the EBU into several external accesses. For
example, if the AHB requests to read a 64-bit word and the external device is only 16-bit
wide, the EBU will automatically perform four external 16-bit accesses. When multiple
accesses are generated in this way, external bus arbitration is blocked until the multiple
access is complete. This means that the EBU remains the owner of the external bus for
the duration of the access sequence. The external accesses are performed in ascending
AHB address order.
To allow proper bus width translation, the EBU has the capability to re-align data
between the external bus and the AHB as shown in Figure 14-10.

XMC4500
XMC4000 Family
memory
controller External
Data32(31:16) DataMS16(15:0) Address Data Bus
Bus pins AD(31:16)
1 A(15:0)
AHB/memory
controller
Bus Interface Data32(31:0) Data32(31:16)
2 memory
controller External
DataLS16(15:0) Data Bus Data Bus
pins AD(15:0)
Data32(15:0) AD(15:0)
Figure 14-10 AHB to External Bus Data Re-Alignment

During an access to a 32-bit wide external region, Buffer 1 and Buffer 2 are enabled.
During an access to a 16-bit wide external region, either Buffer 1 or Buffer 3 is
enabled (according to bit 1 of the AHB address being accessed). This allows either
AHB channel byte pair (i.e. any properly aligned 16-bit data) to be re-aligned to the
lower 16 bits of the external data bus D[15:0].
14.7.7 Address Alignment During Bus Accesses

During an external bus access, the EBU will align the internal byte address to generate
the appropriate external word or half-word address aligned to the external address pins.
The address alignment will be done as follows:
For 16 bit memory accesses
AD[15:0] will be driven with the value from AHBA[16:1] (multiplexed accesses
only)
AD[31:16] will be driven with the value from AHBA[15:1] (non-multiplexed
accesses only)
A[24:16] will be driven with the value from AHBA[24:17]
For 32 bit memory accesses
AD[15:0] and AD[31:16] will be driven with the value from AHBA[17:2] (accesses
to paired 16-bit multiplexed devices only)
AD[31:0] will be driven with the right-justified and zero-padded value from
AHBA[31:2] (accesses to paired 32-bit multiplexed devices only)
A[24:16] will be driven with the value from AHBA[25:18]
14.8 External Bus Arbitration

External bus arbitration is provided to allow the EBU to share its external bus with other
master devices. This capability allows other external master devices to obtain ownership

XMC4500
XMC4000 Family
of the external bus, and to use the bus to access external devices connected to this bus.
The scheme provided by the EBU is compatible with other Infineon microcontroller
devices and therefore allows the use of such devices as (external bus) masters together
with the XMC4500.
Note: In this section, the term external master is used to denote a device which is
located on the external bus and is capable of generating accesses across the
external bus (i.e. is capable of driving the external bus). An external master is not
able to access units that are located inside the XMC4500.
14.8.1 External Bus Modes

The EBU can operate in two bus modes on the external bus:
Owner Mode
Hold Mode
When in Owner Mode, the EBU operates as the master of the external bus. In other
words, the EBU drives the external bus as required in order to access devices located
on the external bus. While the EBU is in Owner Mode it is not possible for any other
master to perform any accesses on the external bus.
During Hold Mode, the EBU tri-states the appropriate signal on the external bus in order
to allow another external bus master to perform accesses on the external bus (i.e. to
allow another master to drive the various external bus signals without contention with
EBU).
14.8.2 Arbitration Signals and Parameters

The arbitration scheme consists of an external bus master that is responsible for
controlling the allocation of the external bus. This master is referred to as the Arbiter
within this document. The other external bus master (termed Participant within this
document) requests ownership of the bus, and when necessary, from the Arbiter. The
EBU can be programmed to operate either as an Arbiter or as a Participant (see
Section 14.8.3). The following three lines are used by the EBU to arbitrate the external
bus.

XMC4500
XMC4000 Family
Table 14-14 EBU External Bus Arbitration Signals

Signal Direction Function
HOLD In HOLD is asserted (low) by an external bus master when the
external bus master requests to obtain ownership of the
external bus from the EBU.
HLDA In/Out1) HLDA is asserted (low) by the Arbiter to signal that the
external bus is available for use by the Participant (i.e. the bus
is not being used by the Arbiter). HLDA is sampled by the
Participant to detect when it may use the external bus.
BREQ Out BREQ is asserted (low) by the EBU when the EBU requests
to obtain ownership of the external bus.
1) The direction of this signal depends upon the mode in which the EBU is operating (see Section 14.8.3).
Two components that are equipped with the EBU arbitration protocol can be directly
connected together (without additional external logic) as shown below:
HOLD HOLD
HLDA HLDA
Arbiter User
BREQ BREQ
Figure 14-11 Connection of Bus Arbitration Signals

Note: In the example of Figure 14-11, it is possible for the EBU to perform the function
or either Arbiter or Participant (or indeed both the Arbiter and Participant may be
the EBU).
Table 14-15 lists the programmable parameters for the external bus arbitration.

XMC4500
XMC4000 Family
Table 14-15 External Bus Arbitration Programmable Parameters

Parameter Function Description
see
MODCON.ARBMODE Arbitration mode selection Section 14.8.
MODCON.ARBSYNC Arbitration input signal sampling control 3
MODCON.EXTLOCK External bus ownership locking control
MODCON.TIMEOUTC External bus time-out control
14.8.3 Arbitration Modes

The arbitration mode of the EBU can be selected through configuration pins during reset
or by programming the MODCON.ARBMODE bit field (see Section 14.8.3) after reset.
Four different modes are available:
No Bus Mode
Sole Master Mode
Arbiter Mode
Participant Mode
14.8.3.1 No Bus Arbitration Mode

All accesses of the EBU to devices on the external bus are prohibited and will generate
an AHB bus error. The EBU operates in Hold Mode all the time.
No Bus Mode is selected by MODCON.ARBMODE = 00B.
14.8.3.2 Sole Master Arbitration Mode

In this mode, the EBU must be the only master on the external bus. Therefore no
arbitration is necessary and the EBU has access to the external bus at any time. The
EBU operates in Owner Mode all the time.
Sole Master Mode is selected by MODCON.ARBMODE = 11B.
14.8.3.3 Arbiter Mode Arbitration Mode

The EBU is the default owner of the external bus (e.g. applicable when operating from
external memory). Arbitration is performed if an external master (e.g. second CPU)
needs to access the external bus.
The EBU is cooperative in relinquishing ownership of the external bus while operating in
Arbiter Mode. When the HOLD input is active, the EBU will generate a retry in response
to any attempt to access the external bus from the internal AHB. However, the EBU is
aggressive in regaining ownership of the external bus while operating in Arbiter Mode.

XMC4500
XMC4000 Family
The EBU, having yielded ownership of the bus, will always request return of ownership
even if there is no EBU external bus access pending.
Arbiter Mode is selected by MODCON.ARBMODE = 01B.
Table 14-16 and Figure 14-12 show the functionality of the arbitration signals in Arbiter
Mode.
Table 14-16 Function of Arbitration Pins in Arbiter Mode

Pin Type Pin Function in Arbiter Mode
HOLD In In Owner Mode (EBU is the owner of the external
bus), a low level at HOLD indicates a request for bus
ownership from the external master.
In Hold Mode (EBU is not the owner of the external
bus), a high level at HOLD indicates that the external
master has relinquished bus ownership, which
causes the EBU to exit Hold Mode.
HLDA Out While HLDA is high, the EBU is operating in Owner
Mode. A high-to-low transition indicates that the
EBU has entered Hold Mode and that the external
bus is available to the external master.
While HLDA is low, the EBU is operating in Hold
Mode. A low-to-high transition indicates that the
EBU has exited Hold Mode, and has retaken
ownership of the external bus.
BREQ Out BREQ is high during normal operation. The EBU
drives BREQ low for two EBU clock cycles after
entering Hold Mode (after asserting HLDA low).
BREQ returns high one clock cycle after the EBU
has exited Hold Mode (after driving HLDA high).

XMC4500
XMC4000 Family
HOLD 1) 4)
(EBU Input)
1 Cycle
HLDA 2) 5)
(EBU Output)
2 Cycles
1 Cycle
BREQ 3) 6)
(EBU Output)
External Bus EBU on Bus External Master on Bus EBU on Bus
Figure 14-12 Arbitration Sequence with the EBU in Arbiter Mode

In Arbiter Mode, the arbitration sequence starts with the EBU as owner of the external
bus.
1. The external master wants to perform an external bus access by asserting a low
signal on the HOLD input.
2. When the EBU is able to release bus ownership, it enters Hold Mode by tri-stating its
bus interface lines and drives HLDA = 0 to indicate that it has released the bus. At
this point, the external master ia allowed to drive the bus.
3. Two clock (EBU_CLK) cycles minimum after issuing HLDA low, the EBU drives
BREQ low in order to regain bus ownership. This bus request is issued whether or
not the EBU has a pending external bus access. However, the external master will
ignore this signal until it has finished its bus access. This scheme assures that the
external master can perform at least one complete external bus access.
4. When the external master has completed its access, it tri-states its bus interface and
sets HOLD to inactive (high) level to signal that it has released the bus back to the
EBU.
5. When the EBU detects that the bus has been released, it returns HLDA to high level
and returns to Owner Mode by actively driving the bus interface lines. There is always
at least one clock (EBU_CLK) cycle delay from the release of the HOLD input to the
EBU driving the bus.
6. Finally, the EBU deactivates the BREQ signal a minimum of one clock (EBU_CLK)
cycle after deactivation of HLDA. Now (and not earlier) the external master can
generate a new hold request to the EBU.
This sequence assures that the EBU can perform at least one complete bus cycle before
it re-enters Hold Mode as a result of a request from the external master.
The conditions that cause change of bus ownership when the EBU is operating in Arbiter
Mode are shown in Figure 14-13.

XMC4500
XMC4000 Family
Start
EBU in Owner Mode

(i.e. owner of the
external bus) The EBU holds ownership of the
external bus:
While EXTLOCK = 1
Perform Appropriate or
LMB access yes External Bus Access Until all current/queued external
to external bus (for read access return accesses are completed.
is starting? result to LMB)
When the external master requests
no the external bus (HOLD = 0) and
conditions are appropriate the EBU
releases ownership of the bus by
EBU_CON. yes HLDA = 0.
EXTLOCK = 1?
no
no
HOLD = 0?
yes
EBU in Hold Mode The EBU remains in Hold Mode

(i.e. not owner of the until the bus is released by the
external bus) external master (signalled by the
external master setting HOLD = 1).
yes
HOLD = 0?
no
Figure 14-13 Bus Ownership Control in Arbiter Mode

XMC4500
XMC4000 Family
14.8.3.4 Participant Mode Arbitration Mode

The EBU tries to gain bus ownership only in case of pending transfers (e.g. when
operating from internal memory and performing stores to external memory). While the
EBU is not the owner of the external bus (default state), any AHB access to the external
bus will be issued with a retry by the EBU. Any such access will, however, cause the EBU
to arbitrate for ownership of the external bus.
Once the EBU has gained ownership of the external bus, it will wait until either the
occurrence of an external bus access (e.g. the repeat of the request that originally
caused the arbitration to occur) or for a programmable time-out (see Section 14.8.7).
Once the first access has been completed, the EBU will continue to accept requests from
the AHB bus until the external master asserts HOLD = 0. After the external master has
asserted HOLD = 0, the EBU will respond to subsequent AHB accesses to external
memory with a retry, and will return ownership of the bus to the external master once any
ongoing transaction is complete.
Note: Regardless of the state of the HOLD input, the EBU will always perform at least
one external bus access (assumed that there is not a time-out) before returning
ownership of the bus to the external master.
The use of the arbitration signals in Participant Mode is:
Table 14-17 Function of Arbitration Pins in Participant Mode

Pin Type Pin Function in Participant Mode
HOLD In When the EBU is not in Hold Mode (HLDA = 0) and has completely
taken over control of the external bus, a low level at HOLD requests
the EBU to return to Hold Mode.
HLDA In When the HLDA signal is high, the EBU is in Hold Mode. When the
EBU has requested ownership of the bus by a high-to-low transition
at HLDA, the EBU is released from Hold Mode.
BREQ Out BREQ remains high as long as the EBU does not need to access the
external bus. When the EBU detects that an external access is
required, it sets BREQ = 0 and waits for signal HLDA to become low.
When the EBU has completed the external bus access (and has re-
entered Hold Mode), it will set BREQ = 1 to signal that it has
relinquished ownership of the external bus.
Participant Mode arbitration mode is selected by CON.ARBMODE = 10B.

XMC4500
XMC4000 Family
BREQ 1) 5)
(EBU Output) 7) 8)
1 Cycle
HLDA 2) 6)
(EBU Input)
1 Cycle
HOLD 4)
(EBU Input)
1 Cycle
External Bus Ext. Master on Bus 3) EBU on Bus Ext. Master on Bus
Figure 14-14 Arbitration Sequence with the EBU in Participant Mode

In Participant Mode, the arbitration sequence starts with the EBU in Hold Mode.
1. The EBU detects that it has to perform an external bus access by asserting a low
signal on the BREQ output.
2. When the external master is able to release bus ownership, the external master
releases the external bus by tri-stating its bus interface lines and drives the
HLDA = 0.
3. At least one clock (EBU_CLK) cycle after detecting HLDA = 0, the EBU will start to
drive the external bus.
4. When the EBU is in Owner Mode, the external master may optionally drive HOLD = 0
to signal that it wants to regain ownership of the external bus.
5. When the criteria are met for the EBU to release the bus ownership, the EBU enters
Hold Mode and drives BREQ = 1 output high to signal that it has released the bus.
6. When the external master detects that the EBU has released the bus (BREQ = 1), it
returns HLDA to high level and takes ownership of the external bus.
7. The EBU will not request ownership of the external bus again (BREQ = 0) at least
one clock (EBU_CLK) cycle after HLDA has been driven high).
8. In Owner Mode, the EBU will not request ownership of the external bus BREQ = 0)
for at least one clock (EBU_CLK) cycle after its HOLD input has been driven high.
The conditions that cause change of bus ownership when the EBU is operating in
Participant Mode is shown in Figure 14-13.

XMC4500
XMC4000 Family
Start
EBU is in Hold Mode

The EBU remains in Hold Mode
until an PLMB access to the
external bus is received. This
access is rejected with a retry and
EBU access no the EBU starts an arbitration cycle
to ext. bus is
to gain ownership of the bus.
pending?
yes
EBU is in Hold Mode
The EBU remains in Hold Mode

until the bus is released by the
no Arbiter (signalled by the HLDA = 0).
HLDA = 0?
yes
EBU is in Owner Mode
EBU_CON. yes Once the EBU has gained the

EXTLOCK = 1? external bus ownership it holds
ownership:
no
While EXTLOCK = 1
or
EBU access yes Until all queued external accesses
to ext. bus is are completed.
underway? or
While an PLMB access is pending
no (i.e. until a time-out occurs).
New EBU yes When the conditions are

access to ext. bus is appropriate the EBU voluntarily
waiting? surrenders external bus ownership
to the Arbiter (regardless of the
no state of the HOLD input).
EBU access yes

to ext. bus is
pending?
no
Figure 14-15 Bus Ownership Control with the EBU in Participant Mode
14.8.4 Arbitration Input Signal Sampling

The sampling of the arbitration inputs can be programmed for two modes:
Synchronous Arbitration
Asynchronous Arbitration

XMC4500
XMC4000 Family
When synchronous arbitration signal sampling is selected (ARBSYNC = 0), the

arbitration input signals are sampled and evaluated in the same clock cycle. This mode
provides the least overhead during arbitration (i.e. when changing bus ownership). The
disadvantage is that the input signals must adhere to setup and hold times with respect
to EBU_CLK to prevent the propagation of meta-stable signals in the EBU.
When asynchronous arbitration signal sampling is selected (ARBSYNC = 1), the
arbitration signals are sampled and then fed to an additional latch to be evaluated in the
cycle following that in which they were sampled. This provides the EBU with good
immunity to signals changing state at or around the time at which they are sampled. The
disadvantage is the introduction of additional latency during arbitration (i.e. when
changing bus ownership).
14.8.5 Locking the External Bus

The external bus can be locked to allow the EBU to perform uninterrupted sequences of
external bus accesses. The EBU allows two methods of locking the external bus:
Locked AHB accesses
Lock bit EXTLOCK
When the EBU has ownership of the external bus and is performing external bus
accesses in response to a locked AHB access sequence, the ownership of the external
bus will not be relinquished until the locked AHB access sequence has been completed.
When lock bit EXTLOCK = 1, the EBU will hold the ownership of the external bus until
EXTLOCK is subsequently cleared. If EXTLOCK is written to 1 while the EBU is the
owner of the external bus, the EBU is immediately prevented from responding to
requests for the external bus until EXTLOCK is cleared1). If EXTLOCK is written to 1
while the EBU is not the owner of the external bus, the EBU will immediately attempt to
gain ownership. When the EBU gains the ownership of the external bus the next time,
the external master is prevented from regaining ownership of the external bus until
EXTLOCK is again cleared.
Note: There is no time-out mechanism available for the EXTLOCK bit. When the EBU is
owner of the external bus with EXTLOCK bit set, the external master will remain
locked off the bus until the EXTLOCK bit is cleared by software.
1) Requests for the external bus already pending when EXTLOCK is set will not be cancelled so the EBU can
give up control of the external bus after EXTLOCK is set provided that the request occurs before the
EXTLOCK bit is set.

XMC4500
XMC4000 Family
14.8.6 Reaction to an AHB Access to the External Bus

The reaction of the memory controller to an external bus request from an AHB master is
controlled as shown in Figure 14-16.
LMB Master generates

access to external bus
no yes
Arbitration Mode =
"No Bus"?
Arbitration Mode = no Reject LMB access

"Sole Master"? with ERROR (external
bus is not available)
yes EBU has and no
can retain ownership of the
external bus?
yes
Perform external bus Reject LMB access

access with RETRY
Return acknowledge/ Request ownership

result to LMB master of external bus
Done
Figure 14-16 EBU Reaction to AHB to External Bus Access

If the EBU is operating in No Bus Mode, it is not possible for an AHB master to access
the external bus. For this reason, the EBU generates an AHB error whenever an attempt
is made to access the external bus while in No Bus Mode.
If the EBU is operating in Sole Master Mode, it has access to the external bus at all times
and as a result it is possible for the EBU to immediately perform the required external
bus access.
If the EBU is operating in Arbiter or Participant Modes and receives a request for an
external access from an AHB when it is not the owner of the external bus (or is not able
to retain ownership of the bus), the request is stalled by taking HRDY low. As shown in
Figure 14-16, this event also triggers the EBU to arbitrate with the external master in
order to attempt to gain ownership of the external bus so that the request can be
serviced.

XMC4500
XMC4000 Family
14.8.7 Pending Access Time-Out

The strategy of stalling an AHB access (when the EBU is not the owner of the external
bus) as described in the previous section may result in the occurrence of a time-out
condition.
To avoid a bus-locking condition, the EBU contains a time-out mechanism. When the
EBU has gained ownership of the external bus, it will retain ownership only until a AHB-
to-external bus access occurs or a programmable number of EBU_CLK clock cycles has
elapsed. If one of these conditions has occurred, the pending access is cancelled and
the EBU will continue to arbitrate the external bus in the normal fashion. The desired
time-out time (number of EBU_CLK cycles) is programmed using bit field TIMEOUTC.
The time-out value can be in the range 1 8 up to 255 8 EBU_CLK clock cycles.
14.8.8 Arbitrating SDRAM control signals

Normally, the memory controller will not surrender control of a connected SDRAM device
when arbitrating the external bus. This is because the memory controller needs to keep
track of which pages are open in the SDRAM and also because of restrictions on the
SDRAM clock.
However, the memory controller can be programmed to tri-state the SDRAM control
signals SDCLKO, CKE, RAS and CAS by setting the MODCON.SDTRI bit to 1B. When
this bit is set, SDRAM can be shared with another controller provided certain conditions
are met by both memory controllers.
The SDRAM must be in self refresh mode with the clock safely stopped before
ownership of the external bus is transferred. This ensures that all pages in the
SDRAM are closed and that the CKE signal is at logic zero. This can be achieved for
the memory controller by setting the SDRMREF.AUTOSELFR to 1B.
The SDRAM CKE input must have a pull down sufficient to ensure that there is a
guaranteed logic zero on the input while bus ownership is being transferred.
14.9 Start-Up/Boot Process

The EBU pins will be held in a tri-state condition while the memory controller is in reset.
After reset is removed, the EBU will configure itself for no bus mode and wait for
configuration by software. The PORTS logic also needs to be configured by software to
allow the EBU to control its related pins.
14.10 Standard Access Phases

Accesses to asynchronous devices are composed of a number of standard access
phases (according to the type of device and the type of access).
There are six access phases defined:
Address Phase AP (mandatory for read and write cycles of both device types)

XMC4500
XMC4000 Family
Command Delay Phase CD (optional)

Command Phase CP (mandatory for read and write cycles of asynchronous device
types)
Data Hold Phase DH (optional, only applies to write cycles)
Recovery Phase RP (optional)
Throughout the remainder of this document, a short-hand notation is adopted to
represent any clock cycle in any phase. This notation consists of two or three letters
followed by a number. The letters identify the access phase within which the clock cycle
is located (e.g. AP for Address Phase). The number denotes the number of EBU_CLK
clock cycles within the phase (i.e. 1 = first, etc.). In the case of delays that can be
extended by external control inputs the lower case letters e and i are inserted
following the two letter phase identifier to differentiate between internally (i) and
externally (e) generated delays. For example, AP2 identifies the second clock in the
Address Phase. CPe3 identifies the third clock in the Command Phase which is being
extended by external wait-states.
14.10.1 Address Phase (AP)

The Address Phase is mandatory. It always consists of at least one or more EBU_CLK
cycles. The phase can be optionally extended to accommodate slower devices.
At the start of the Address Phase, the EBU:
Selects the device to be accessed by asserting the appropriate CSx signal,
Issues the address which is to be accessed on the address bus,
Asserts the ADV signal low,1)
Asserts the appropriate BCx signals if these are programmed to be asserted with the
CSx signal,
At the end of the Address Phase the EBU returns the ADV signal to high.
The length (number of EBU_CLK cycles) of the Address Phase is programmed via the
BUSAPx.ADDRC bit field parameter.
14.10.2 Address Hold Phase (AH)

The Address Hold Phase is optional. It consists of zero or more EBU_CLK cycles. It is
intended to provide hold time for the multiplexed address bits after the ADV signal has
returned to the inactive state.
At the end of the address hold phase, the multiplexed address can be removed from the
bus:
During a read access, the multiplexed address/data bus can return to the high
impedance condition to allow the read data to be driven by the external memory
1) If an active high, ALE, signal is required, the polarity of the ADV output can be inverted by setting the ALE field
of the MODCON register.

XMC4500
XMC4000 Family
During a write access, the write data can be driven onto the multiplexed address/data
bus
14.10.3 Command Delay Phase (CD)

The Command Delay phase is optional. This means that it can also be programmed for
a length of zero EBU_CLK clock cycles. The CD phase allows for the insertion of a delay
between Address Phase (or optional Address Hold phase) and Command Phase(s).
This phase accommodates devices that are not fast enough to receive commands
immediately after getting the address or multiplexed devices which require a bus
turnaround delay on reads.
The length (number of EBU_CLK cycles) of the Command Delay phase is programmed
via the BUSAPx.CMDDELAY bit field. This parameter makes it possible to select
between zero to seven Command Delay phases.
14.10.4 Command Phase (CP)

The Command Phase is mandatory for asynchronous devices. It always consists of at
least one or more EBU_CLK cycles. The phase can optionally be extended to
accommodate slower devices.
The length (number of EBU_CLK cycles) of the Command Phase is separately
programmable for read and write accesses. Bit field BUSAPx.WAITRDC determines the
basic length of Command Phases during read cycles and bit field BUSAPx.WAITWRC
determines the basic length of Command Phases during write cycles.
Additionally, when accessing asynchronous devices, a Command Phase can also be
extended externally using the WAIT signal when the region being accessed is
programmed for external command delay control via bit BUSCONx.WAIT or
EMUBC.WAIT.
The Command Phase is further subdivided into:
CPi (= internally-programmed Command Phase)
CPe (= externally-prolonged Command Phase, i.e. prolonged by the assertion of the
WAIT signal).
At the start of the Command Phase, the EBU:
Asserts the appropriate control signal RD or RD/WR low according to the access type
(read or write),
Issues the data to be written on the data bus AD[15:0] (in the case of a write cycle),
Asserts the appropriate BCx low (in the case where BCx is programmed to be
asserted with the RD or RD/WR signals).
At the end of the Command Phase during an asynchronous access, the EBU:
Returns the appropriate control signal RD or RD/WR high according to the type of
access type (read or write),

XMC4500
XMC4000 Family
Latches the data from the data bus AD[15:0] (in the case of a read cycle),
Returns the appropriate BCx high (in the case where BCx is programmed to be
asserted with the RD or RD/WR signals).
14.10.5 Data Hold Phase (DH)

The Data Hold phase is optional. This means that it can also be programmed for a length
of zero EBU_CLK clock cycles. Furthermore, it is only available for asynchronous write
accesses. The Data Hold phase extends the amount of time for which data is still held
on the bus after the rising edge of the RD/WR signal occurred. The Data Hold phase is
used to accommodate external devices that require a data hold time after the rising edge
of the RD/WR signal. The length (number of EBU_CLK cycles) of the Data Hold phase
is programmed via the BUSAPx.DATAC bit field.
14.10.6 Burst Phase (BP)

The Burst Phase is mandatory during burst accesses. At the end of the Burst Phase the
EBU reads data from the data bus or updates the write data. During a burst access, Burst
Phases are repeated as many times as required in order to read or write the required
amount of data from or to the external memory device.
The first burst phase of an access will always start on arising edge of BFCLKO. If
necessary, the length of the previous phase will be extended to ensure that this happens.
At the end of the last Burst Phase during a burst read access, the EBU:
Returns the CSx signal high,
Returns the RD signal high.
During accesses to Burst Flash devices the length of the Burst Phase must be
programmed such that the end of the Burst Phase always coincides with a positive edge
of the appropriate BFCLKO (Burst Flash Clock) signal.
A Burst Phase is always at least one clock cycle in length. When BUSRCONx.AGEN is
not equal to 1101B, Demuxed Burst Type External Memory (DDR flash protocol), then
the length of each Burst Phase (i.e. the number of EBU_CLK cycles) is derived from the
value of the EXTCLOCK and EXTDATA fields in the BUSAPx register. The length of the
burst phase will be either be:
one period of BFCLKO if EXTDATA is 00B,
two periods of BFCLKO if EXTDATA is 01B.
four periods of BFCLKO if EXTDATA is 10B.
eight periods of BFCLKO if EXTDATA is 11B.
If BUSCON.AGEN is equal to 1101B, then the length of the burst phase will be controlled
by the EXTDATA field only and the burst phase length will be equal to EXTDATA+1. This
allows the external clock period to be an integer multiple of the burst phase length. This
will allow support for devices which return data on both edges of the device clock. (e.g.
setting EXTDATA to 00B and EXTCLOCK to 01B will support a DDR style flash device)

XMC4500
XMC4000 Family
14.10.7 Recovery Phase (RP)

The Recovery Phase is optional (although for access types which would cause a bus
contention a single cycle of recovery is normally forced by the memory controller logic).
This means that it can also be programmed for a length of zero EBU_CLK clock cycles.
This phase allows the insertion of a delay following an external bus access that delays
the start of the Address Phase for the next external bus access. This permits flexible
adjustment of the delay between accesses to the various external devices. The following
individually programmable delays are provided on a region by region basis for the
following conditions:
Bit fields BUSAPx.RDRECOVC determine the basic length of the Recovery Phase
after a read access.
Bit fields BUSAPx.WRRECOVC determine the basic length of the Recovery Phase
after a write access.
Bit fields BUSAPx.DTACS determine the length (basic number of EBU_CLK clock
cycles) of the Recovery Phase after a read/write access of one region that is followed
by a read/write access of another region or a read to one region is followed by a write
to the same region (BUSRAPx.DTACS) or a write to one region is followed by a read
to the same region (BUSWAPx.DTACS).
The EBU implements a highest wins algorithm to ensure that the longest applicable
recovery delay is always used between consecutive accesses to the external bus.
Table 14-18 shows the scheme for determining this delay for all possible circumstances.
For example, if a read access to a region associated with CS1 is followed by a write to
a region associated with CS2, the delay will be the highest of BUSRAP1.DTACS and
BUSRAP1.RDRECOVC. In this case, if BUSRAP1.DTACS is greater than
BUSRAP1.RDRECOVC, then the number of recovery cycles between the two accesses
is BUSRAP1.DTACS clock cycles (minimum).

XMC4500
XMC4000 Family
Table 14-18 Parameters for Recovery Phase

Case Parameter(s) used to calculate
Region Current Next Highest Wins Recovery Phase
Access Access
Same CSn Read Read RDRECOVC
Write Write WRRECOVC
Read Write BUSRAPx.DTACS
Write Read BUSWAPx.DTACS
Different CSn Read Read BUSRAPx.DTACS, RDRECOVC
Write Write BUSWAPx.DTACS, WRRECOVC
Read Write BUSRAPx.DTACS, RDRECOVC
Write Read BUSWAPx.DTACS, WRRECOVC
14.11 Asynchronous Read/Write Accesses

Asynchronous read/write access of the EBU support the following features:
EBU_CLK clock-synchronous signal generation
Support for 16-bit and 32-bit bus width
Performing an AHB access with a data width greater than that of the external device
automatically triggers a sequence of the appropriate number of external accesses to
match the AHB access width.
Demultiplexed address/data lines
Programmable access parameters
Internal control of command delay cycles
External and/or internal control of wait states
Variable data hold cycles for write operation (to allow flexible hold time adjustment)
Variable inactive/recovery cycles when:
Switching between different memory regions (CS),
Switching between read and write operations,
After each read cycle,
After each write cycle.
Software driver routines are required in order to support Nand Flash devices using
asynchronous device accesses. A single Nand Flash access sequence is performed by
generating the appropriate sequence of discrete asynchronous device accesses in
software.
The EBU does not provide support 8-bit bus width. When 8-bit SRAM devices are used,
they must be used in pairs to implement a 16-bit wide memory region.

XMC4500
XMC4000 Family
14.11.1 Signal List

The following signals of the EBU are used for asynchronous accesses:
Table 14-19 Asynchronous Mode Signal List

Signal/Pin Type Function
AD[31:0] I/O Address/Data bus lines 0-31
A[24:16] O Address bus lines 16-24
CS[3:0] O Chip select 0-3
RD O Read control line
RD/WR O Write control line
BC[3:0] O Byte control lines 0-3
WAIT I Wait input
14.11.2 Standard Asynchronous Access Phases

Accesses to asynchronous devices are composed of a subset of the standard access
phases which are detailed in Section 14.10. The standard access phases for
asynchronous devices are:
AP: Address Phase (compulsory - see Section 14.10.1)
CD: Command Delay Phase (optional - see Section 14.10.3)
CP: Command Phase (compulsory - see Section 14.10.4)
DH: Data Hold Phase (optional - see Section 14.10.5)
RP: Recovery Phase (optional - see Section 14.10.7)
14.11.3 Control of ADV & CS Delays During Asynchronous Accesses

For asynchronous accesses, the Memory Controller output signals: ADV, CS, RD,
RD/WR, BC and AD signals can be delayed with respect to the start of the access
phases they are asserted in. The amount by which the signal is delayed depends on the
setting of the EXTCLOCK field of BUSAPx:-
When EXTCLOCK is set to 00B, signals are asserted on the negative edge of
EBU_CLK (i.e. it is in effect delayed by 1/2 an Memory Controller clock cycle with
respect to the other signals).
When EXTCLOCK is not set to 00B, control signals are asserted on the next positive
edge of EBU_CLK (i.e. it is in effect delayed by an EBU_CLK cycle with respect to
the other signals).
Memory Controller allows these delays to be removed independently via user
programmable bits. The default setting after reset has the delay enabled

XMC4500
XMC4000 Family
Table 14-20 ADV and Chip Select Signal Timing

EXTCLOCK is set Delay Disabled1) Delay Enabled
to
00B Start of AP1 Middle of AP1
01B, 10B, 11B Start of AP1 End of AP1
1) See Figure 14-24 for details of this signal positioning.
This function is controlled by the register bits BUSCONx.EBSE for ADV and
BUSCONCx.ECSE for the other control signals.
Note: If CS is delayed a recovery phase must be used to prevent conflicts between chip
selects as the rising edge of chip select will be delayed past the end of the burst
phases. Also, for muxed devices, the write data will be delayed into the address
phase of the next access, resulting in the valid address being driven one clock
after ADV is asserted.
14.11.4 Programmable Parameters

Table 14-21 lists the programmable parameters for asynchronous accesses. These
parameters only apply to asynchronous devices when BUSCONx.AGEN = 000B. Note
that emulation registers EMU include parameters that control the emulator chip
select region (CSEMU output), while BUSx registers include parameters that control
the four CS[3:0] chip select regions x. The equivalent registers contain identical bits and
bit fields.
Table 14-21 Asynchronous Access Programmable Parameters

(Bit/Bit field)
BUSAPx ADDRC Number of cycles in address phase
CMDDELAY Number of programmed command delay cycles.
WAITRDC Number of programmed wait states for read
accesses.
WAITWRC Number of programmed wait states for write
accesses.
DATAC Number of Data Hold cycles.

XMC4500
XMC4000 Family
Table 14-21 Asynchronous Access Programmable Parameters (contd)

(Bit/Bit field)
BUSAPx RDRECOVC Number of minimum recovery cycles after a read
access.
WRRECOVC Number of minimum recovery cycles after a write
access.
DTARDWR Number of minimum recovery cycles between a
read access and a write access.
DTACS Number of minimum recovery cycles when the next
access going to a different memory region.
BUSCONx WAIT External Wait State control (OFF, asynchronous,
synchronous)
WAITINV Reversed polarity at WAIT: active low or active high

XMC4500
XMC4000 Family
14.11.5 Accesses to Multiplexed Devices
INT_CLK
new
AP1 AP2 AH1 CDi1 CPi1 CPi2 RP1 RP2 RP3
AP1
AD(15:0) Address data in
ADV
CSx
RD
A(MAX:16) address X
(a) Read Access
INT_CLK
new
AP1 AP2 AH1 CDi1 CPi1 CPi2 DH1 DH2 RP1
AP1
AD(15:0) address data out
ADV
CSx
WR
A(MAX:16) address X
(b) Write Access
Figure 14-17 Multiplexed External Bus Access Cycles

Figure 14-17 shows an example of a read access to a multiplexed device. This type of
access cycle consists of two to six phases as follows:
Address Phase (compulsory)
Address Hold Phase (optional)
Command Delay Phase (optional)

XMC4500
XMC4000 Family
Command Phase (compulsory)

Data Hold Phase (optional)
Recovery Phase (optional)
14.11.6 Dynamic Command Delay and Wait State Insertion

In general, there are two critical phases during asynchronous device accesses. These
phases are:
Command Delay Phase (see Section 14.10.3).
Command Phase (see Section 14.10.4).
In the EBU, internal length programming for the Command Delay Phase is available via
bit fields BUSAPx.CMDDELAY.
The equivalent control capability for the Command Phase is available for bit fields
BUSRAPx.WAITRDC and BUSWAPx.WAITWRC.
14.11.6.1 External Extension of the Command Phase by WAIT

The WAIT input can be used to cause the EBU to extend the Command Phase by
inserting additional cycles prior to deactivation of the RD and RD/WR lines. This signal
can be programmed separately for each region to be ignored or sampled either
synchronously or asynchronously (selected via the BUSCONx.WAIT bit field).
Additionally, the polarity of WAIT can be programmed for active low (default after reset)
or active high function via bit BUSCONx.WAITINV. The signal will only take effect after
the programmed number of Command Phase cycles has passed. This means that the
signal can only be used to extend the phase, not to shorten it.
When programmed for synchronous operation, WAIT is sampled on every rising edge of
EBU_CLK during the Command Phase. The sampled value is then used on the next
rising edge of EBU_CLK to decide whether to prolong the Command Phase or to start
the next phase. Figure 14-18 shows an example of WAIT used in Synchronous Mode.
Note: Due to the one-cycle delay in Synchronous Mode between the sampling of the
WAIT input and its evaluation by the EBU, the Command Phase must always be
programmed to be at least one EBU_CLK cycle (via BUSAPx.WAITRDC or
BUSAPx.WAITWRC) in this mode.
When programmed for asynchronous operation, WAIT is also sampled at each rising
edge of EBU_CLK during the Command Phase. However, an extra synchronization
cycle is inserted prior to the use of the sampled value. This means that the sampled
value is not used until the second following rising edge of EBU_CLK. Figure 14-19
shows an example of WAIT used in Asynchronous Mode.
Note: Due to the two-cycle delay in Asynchronous Mode between the sampling of the
WAIT input and its evaluation by the EBU, the Command Phase must always be

XMC4500
XMC4000 Family
programmed to be at least two EBU_CLK cycles (via BUSAPx.WAITRDC or

BUSAP.WAITWRC) in this mode.
Figure 14-18 shows an example of the extension of the Command Phase through the
WAIT input in synchronous mode:
At EBU_CLK edge 1 (at the end of the Address Phase), the EBU samples the WAIT
input as low and starts the first cycle of the Command Phase (CPi1 - internally
programmed).
At EBU_CLK edge 2, the EBU samples the WAIT input as low and starts an
additional Command Phase cycle (CPe2 - externally generated) as a result of the
WAIT input sampled as low at EBU_CLK edge 1.
At EBU_CLK edge 3, the EBU samples the WAIT input as high and starts an
Finally at EBU_CLK edge 4, as a result of the WAIT input sampled as high at point
3, the EBU terminates the Command Phase, reads the input data from D[31:0] and
starts the Recovery Phase.
Note: Synchronous operation means that even though access to the device may be
asynchronous, the control logic generating the control signals must meet setup
and hold time requirements with respect to EBU_CLK.
LMBCLK
AP CPi1 CPi2 CPe3 RP1
A[23:0] Address
CSx
ADV
RD
AD[15:0] Address Data in
WAIT
(active low)
1 2 3 4
Figure 14-18 External Wait Insertion (Synchronous Mode)

Figure 14-19 shows an example of the extension of the Command Phase through the
WAIT input in asynchronous mode:

XMC4500
XMC4000 Family
At EBU_CLK edge 1 (at the end of the Address Phase), the EBU samples the WAIT
input as low and starts the first cycle of the Command Phase (CPi1 - internally
programmed).
At EBU_CLK edge 2, the EBU samples the WAIT input as low and starts the second
cycle of the Command Phase (CPi2 - internally programmed).
At EBU_CLK edge 3, the EBU samples the WAIT input as high and starts an
At EBU_CLK edge 4, the EBU starts an additional Command Phase cycle (CPe4 -
externally generated) as a result of the WAIT input sampled as low at EBU_CLK
edge 2.
Finally at EBU_CLK edge 5, as a result of the WAIT input sampled as high at
EBU_CLK edge 3, the EBU terminates the Command Phase, reads the input data
from AD[15:0],and starts the Recovery Phase.
LMBCLK
AP CPi1 CPi2 CPe3 CPe4 RP1
A[20:16] Address
CSx
ADV
RD
AD[15:0] Address Data in
WAIT
(active low)
1 2 3 4 5
Figure 14-19 External Wait Insertion (Asynchronous Mode)
14.11.7 Interfacing to Nand Flash Devices

The memory controller provides limited support for specific Nand Flash devices. The
required access sequences (read or write) are generated by connecting the Nand Flash
device as an Asynchronous Device and using appropriate processor generated access
sequences to emulate the NAND flash commands. Figure 14-20 Shows an example of
Memory Controller connected to a Nand Flash device:-

XMC4500
XMC4000 Family
AD(15:0) I/O(1:8)
A(17) CLE
A(16) ALE
CS CE
RD RE
WR WE
WAIT R/B
Memory
Interface Nand Flash
Figure 14-20 Example of interfacing a Nand Flash device to the Memory Controller
The R/B input from the NAND flash is connected to the memory controller WAIT input
and is available as the MODCON.STS. This enables a NAND flash to be driven by
software from the processor.
As shown above only two address lines are connected to the Nand Flash, and rather
than being connected to address inputs, they are connected to control inputs. This allows
access to three registers in the Nand Flash as follows:-
Table 14-22 Nand Flash Registers

AHB Address Register Comment
Base + 00000H Data Register Read/Write: Used to read data from and write
data to the device.
Base + 20000H Address Register Write only: Used to write the required access
address to the device.
Base + 40000H Command Register Write only: Used to write the required
command to the device.
Note: AHB addresses are byte addresses and addresses on the external bus are 16 bit
word addresses. Therefore [AHB address(18)]->[external address(17)] and [AHB
address(17)]->[external address(16)].

XMC4500
XMC4000 Family
Note that the Memory Controller does not directly support byte wide devices. Writes to
8 bit, NAND Flash devices must therefore be done as 16-bit word writes with the valid
byte in the lower part and the upper-byte padded.
14.11.7.1 NAND flash page mode

NAND flash memories are page oriented devices capable of extended read operations
with a single setup phase for command signals at the beginning of the access. The
asynchronous controller of the Memory Controller will split a large transfer into multiple
accesses to external memory but each of these accesses will have the overhead of the
initial setup phase. Enabling page mode, using the AGEN field in BUSCONx will cause
the standard flow of the controller to be modified as follows:
For a read, if data remains to be fetched at the end of a command phase, the
controller will start a new command delay phase, instead of a new address phase or
recovery phase and the address will not be incremented. If BUSRAPx.cmddelay is
set to zero, the command delay phase will have a duration of one clock cycle but in
this case the command delay phase is mandatory to ensure that the RD and RD/WR
signals return to the high state.
For a write, if data remains to be written at the end of a data hold phase (or command
phase if the length of data hold is zero), the controller will start a new command
phase, instead of a new address phase or recovery phase and the address will not
be incremented. If BUSWAPx.datac is set to zero, the data hold phase will have a
duration of one clock cycle as in this case the data hold phase is mandatory to ensure
that the RD and RD/WR signals return to the high state. The command phase will be
forced to have a minimum length of two clocks.
See Figure 14-21 for example waveforms.

XMC4500
XMC4000 Family
INT_CLK
AP1 AP2 AH1 CDi1 CPi1 CPi2 CDi1 CPi1 CPi2 CDi1
AD(15:0) data in data in
ADV
CSx
RD
ALE/CLE A(17:16)
(a) Read Access
INT_CLK
AP1 AP2 AH1 CDi1 CPi1 CPi2 DH1 DH2 CPi1 CPi2
AD(15:0) data out data out
ADV
CSx
RD/WR
ALE/CLE A(17:16)
(b) Write Access
Figure 14-21 NAND Flash Page Mode Accesses
Example Nand Flash Read Sequence

Figure 14-22 shows an example of how the processor can generate a Nand Flash read
access sequence given this configuration:-

XMC4500
XMC4000 Family
Nand Flash Pins
CLE (A(17))
ALE (A(16))
CE (CS2)
WE (WR)
RE (RD)
R/B (WAIT)
read address address address 1st
I/O(8:1) command (high byte) (middle byte) (low byte) data
1 2 3 4 5
Figure 14-22 Example of an Memory Controller Nand Flash access sequence

(read)
1. In the cycle marked 1 in Figure 14-22 the processor initiates a read sequence by
writing the Read Command value to address NAND_FLASH_BASE + 0x40000.
This generates a write sequence with CLE (A(17)) driven high and ALE (A(16)) driven
low.
2. In the cycle marked 2 the processor loads the most significant byte of the read
address by writing to address NAND_FLASH_BASE + 0x20000. This generates a
write sequence with CLE (A(17)) driven low and ALE (A(16)) driven high.
3. In the cycle marked 3 the processor loads the middle significant byte of the read
address by repeating the access specified in 2 above.
4. In the cycle marked 4 the processor loads the least significant byte of the read
address by repeating the access specified in 2 above. The Nand Flash responds to
this final address byte by driving its R/B output low. The processor monitors this pin
(using the MODCON.sts bit) until the Nand Flash has completed its internal data
fetch.
5. In the cycle marked 5 the processor reads the first byte of data by reading address
NAND_FLASH_BASE + 0x00000. The processor can subsequently read any
additionally required (sequential) data bytes by repeating cycle 5.
Note: A similar scheme can be used to generate write access sequences.
14.12 Synchronous Read/Write Accesses

The Memory Controller is designed to generate waveforms compatible with the burst
modes of:
1. INTEL and compatible burst flash devices
2. SPANSION and compatible burst flash devices
3. INFINEON and MICRON cellular RAM

XMC4500
XMC4000 Family
4. Fujitsu and Compatible FCRAM/uTRAM/CosmoRAM

5. Samsung OneNAND burst capable NAND flash and compatible devices
6. M-Systems DiskOnchipG3 and compatible devices
7. GSI SSRAM
Note: Not all of the supported synchronous memory types are known to be available in
automotive grade
Features
The Synchronous Access Controller is primarily designed to perform burst mode read
cycles for an external instruction memory and read and write cycles for an external
Cellular RAM or FCRAM data memory. In general, the features are:-
Fully synchronous timing with flexible programmable timing parameters (address
cycles, read wait cycles, data cycles).
Programmable WAIT function.
Programmable burst (mode and length)
16-bit device width.
32-bit device width
Page mode read accesses.
Resynchronisation of read data to a feedback clock to maximize the frequency of
operation (optional).
14.12.1 Signals
The following signals are used for the Burst FLASH interface:-
Table 14-23 Burst Flash Signal List

Signal Type Function
AD(31:0) I/O Multiplexed Address/Data bus
RD O Read control
WR O Write control
A(24:16) O Most Significant Part of Address bus
ADV O Address valid strobe
WAIT I Wait/terminate burst control
CS(3:0) O Chip select
BFCLKO O Burst FLASH Clock, running equal to, 1/2, 1/3 or 1/4 of the
frequency of EBU_CLK.

XMC4500
XMC4000 Family
Table 14-23 Burst Flash Signal List (contd)

BFCLKI I Burst FLASH Clock Feedback.
STS I Burst FLASH Status Input (Optional, value of WAIT pin
available through status register)
14.12.2 Support for four Burst FLASH device types

Support is provided for a maximum of four different Burst FLASH configurations on the
external bus - i.e. one on each external chip select.
Bit-fields BUSCONx.EBSE, BUSCONx.ECSE, BUSCONx.wait, BUSCONx.FBBMSEL,
BUSCONx.BFCMSEL and BUSCONx.FETBLEN are used to configure specific
characteristics for burst access cycles.
14.12.3 Typical Burst Flash Connection

The figure below shows a typical burst flash connection.
AD(15:0) DQ(15:0)
A(n:16) A(n:0)
AD(31:16)
CSx CE
RD OE
RD/WR WE
ADV ADV
WAIT WAIT
BFCLKO CLK
BFCLKI
Memory Burst FLASH

Interface memory
Figure 14-23 Typical Burst Flash Connection

XMC4500
XMC4000 Family
14.12.4 Burst Flash Clock

Since the EBU_CLK can run too fast for clocking Burst FLASH devices, the Memory
Controller provides an additional clock source (BFCLKO). This signal is generated by a
programmable clock divider driven by EBU_CLK and allows EBU_CLK to BFCLKO
ratios of 1:1, 2:1, 3:1 and 4:1 to be selected. The frequency of the signal is determined
by bit-field BUSRP.EXTCLOCK. Note that it is possible to set a different clock rate for
synchronous writes to the same device by programming BUSWP.EXTCLOCK to a
different value.
If a continuously running BFCLKO is required, then the BUSRCONx.BFCMSEL field can
be used to enable an ungated flash clock. This bit is normally set to 1B in all the
BUSRCONx registers after reset. If cleared, the related BUSRAPx.EXTCLOCK field will
be used to generate a stable BFCLKO. If multiple BUSRCONx.BFCMSEL fields are set
to 0B, then the highest priority (lowest index) BUSRAPx.EXTCLOCK field will be used.
During a burst access to a synchronous device, BFCLKO will generate correctly aligned
clock edges as shown in Figure 14-24. The BFCLKO signal is gated to ensure that it is
low (zero) at all other times (including asynchronous read/writes of/to synchronous
devices). This provides power savings and ensures correct asynchronous accesses to
Burst FLASH device(s).
The start of the address and burst phases are synchronized, by hardware, to the rising
edge of BFCLKO. Exiting from a phase extended by the WAIT input will also be
synchronized to the rising edge of BFCLKO.
Note: The length of the standard accesses phases during Burst FLASH accesses are
programmed as a multiple of EBU_CLK independent of the BFCLKO frequency. It
is the users responsibility to program the access phases to ensure that the
sampling of data by Memory Controller guarantees valid sampling of the data from
the Burst FLASH device.
The EBU uses the EBU_CLK clock to generate all external bus access sequences.
Table 14-24 EXTCLOCK to clock ratio mapping

EXTCLOCK value BFCLKO divide ratio
00 1:1
01 1:2
10 1:3
11 1:4
Unless documented elsewhere, all outputs to the external bus are generated of the rising
edge of EBU_CLK.
The BFCLKO phase is controlled so that control signal changes will normally occur at
the rising edge of BFCLKO unless configured otherwise by register settings.

XMC4500
XMC4000 Family
14.12.5 Standard Access Phases

Accesses to burst FLASH devices are composed of a number of Standard Access
Phases (which are detailed in Section 14.10). The Standard Access Phases for Burst
FLASH devices are:-
AP: Address Phase (compulsory - see Section 14.10.1).
AH: Address Hold Phase (optional see Section 14.10.2).
CD: Command Delay Phase (optional - see Section 14.10.3).
CP: Command Phase (compulsory - see Section 14.10.4).
BP: Burst Phase (compulsory - see Section 14.10.6).
RP: Recovery Phase (optional - see Section 14.10.7).
Note: During a burst access the Burst Phase (BP) is repeated the required number of
times to complete the burst length.
14.12.6 Burst Length Control

The maximum number of valid data samples that can be generated by a flash device in
a single read access is set by the BUSCONx.FBBMSEL bit and the
BUSCONx.FETBLEN bit field.
The BUSCONx.FBBMSEL bit is used to select Continuous Burst Mode where there is
no limit to the number of data samples in a burst read access.
The BUSCONx.FBBMSEL and BUSCONx.FETBLEN bit-fields are used to select the
maximum number of data samples in a single access. Where an AHB request exceeds
the amount of data that can be fetched or stored by the programmed number of data
samples, the EBU will automatically generate the appropriate number of burst accesses
to transfer the required amount of data.
Note: Selection of Continuous Burst Mode (by use of the FBBMSEL bit) overrides the
maximum burst setting (specified by the FETBLEN bit-field).
14.12.7 Control of ADV & CS Delays During Burst FLASH Access

By default the Memory Controller output signals: ADV, CS, RD, RD/WR, BC and AD
signals are delayed with respect to the other clock. The amount by which the signal is
delayed depends on the ratio of EBU_CLK to the Burst FLASH clock as follows:-
When the ratio of EBU_CLK to BFCLKO is 1:1, signals are asserted on the negative
edge of EBU_CLK (i.e. it is in effect delayed by 1/2 an Memory Controller clock cycle
with respect to the other signals).
When the ratio of EBU_CLK to BFCLKO is 1:2 or 1:3, control signals are asserted on
the next positive edge of EBU_CLK (i.e. it is in effect delayed by an EBU_CLK cycle
with respect to the other signals).

XMC4500
XMC4000 Family
When the ratio of EBU_CLK to BFCLKO is 1:4, control signals are asserted on the
negative edge of BFCLK (i.e. it is in effect delayed by two EBU_CLK cycles with
respect to the other signals).
The default setting after reset has the delay enabled
If the delay is disabled, then the signals will not be delayed in 1:1 mode (except for ADV
which will be guaranteed to be after the edge of BFCLKO). In 2:1, 3:1 and 4:1 mode, the
signals will be delayed by half of an EBU_CLK cycle from the start of the cycle in which
they are asserted.
Table 14-25 ADV and Chip Select Signal Timing

EBU_CLK:BFCLKO Ratio Delay Disabled1) Delay Enabled
1:1 Start of AP1 Middle of AP1
2:1, 3:1 half clock cycle after End of AP1
start of AP1
4:1 half clock cycle after End of AP2
start of AP1
1) See Figure 14-24 for details of this signal positioning.
This function is controlled by the register bits BUSCONx.EBSE for the ADVsignal and by
BUSCON.ECSE for the CS, RD/WR and write data signals
Note: If CS is delayed a recovery phase must be used to prevent conflicts between chip
selects as the rising edge of chip select will be delayed past the end of the burst
phases. Also, for muxed devices, the write data will be delayed into the address
phase of the next access, resulting in the valid address being driven one clock
after ADV is asserted.
14.12.8 Burst Flash Clock Feedback

The Memory Controller can be configured to use clock feedback to optimize the
operating frequency for a given flash device. This is enabled by setting the
BUSCONx.FDBKEN bit to one. With this bit enabled the first sampling stage for read
data has its own clock (PD_BFCLKFEEDBK_I). This will be derived from the BFCLKO
output by using a second pad (BFCLKI) to monitor the BFCLKO signal after the output
pad delay.
Clock feedback should be used whenever possible as it allows the best possible
performance
In addition the number of synchronization stages (one or two) used to transfer the read-
data into the EBU_CLK domain can also be selected via the EBUCON_BUSAPx.BFSSS
bit.

XMC4500
XMC4000 Family
When using two synchronization stages (default) the data is initially resynchronized to
PD_BFCLKFEEDBK_I and then is additionally internally resynchronized to BFCLKO
before being passed to the normal logic. In this mode PD_BFCLKFEEDBK_I can
therefore be skewed by almost an entire BFCLK cycle relative to the EBU_CLK clock
without losing data integrity. A side effect of using this mode is an increase in data
latency of two cycles of BFCLK (compared to not using clock feedback).
When using a single synchronization stage the data is resynchronized to
PD_BFCLKFEEDBK_I before being passed to the normal logic. This provides a
compromise setting for operating frequency and latency for 1:1 clocking mode where the
second resynchronisation stage offers no advantage.
Note: If EBU_CLK:BFCLKO = 1:1, then the second and third resynchronisation stages
have identical clock signals. There is therefore no advantage to having the second
resynchronisation stage and it can be bypassed without loss of performance.
As above, a side effect of using this mode is an increase in data latency. In this case
addition of one BFCLK cycle (compared to not using clock feedback).
Note: Clock feedback will be automatically disabled for burst writes as the additional
latency on the WAIT input cannot be tolerated
14.12.9 Asynchronous Address Phase

As operating frequency increases, it becomes increasingly hard to avoid violating some
timing parameters. The asynchronous address phase allows the address to be latched
into the flash memory using the ADV signal before the clock is enabled. This is only
possible if explicitly allowed by the flash data sheet
If the BUSCONx.AAP is set, then the clock will not start until the end of the address hold
phase of the access. The rising edge of the clock will always be co-incident with the
transition from the address hold phase. If the address hold phase has zero length then
the first rising edge of the clock will coincide with the transition from the address phase.
If this mode is enabled a recovery phase of one BFCLK period will be enforced at the
end of the previous transaction to ensure that the clock has time to turn off before the
start of the next access.
Setting this mode for any region will force the clocks on all synchronous accesses to be
disabled in the recovery phase. Only one clock pulse will occur during the recovery
phase.
AAP mode is incompatible with the continuous clock mode and will be disabled
automatically is continuous clocking is enabled by setting any BUSRCONx.BFCMSEL
bit to 0B.

XMC4500
XMC4000 Family
14.12.10 Page Mode Support

If page mode support is enabled using the correct setting of the AGEN field in
BUSRCONx or BUSWCONx then the address on the dedicated address bus pins,
A(24:0), will be incremented at the end of every burst phase and the clock will not run for
the duration of the access.
The page size of the attached device should be programmed using the FETBLEN and
FBBMSEL fields of the BUSCONx register to ensure that the address is not incremented
past the page end of the memory device. 16 bit devices with a page size of 16 words
should be configured for continuous burst.
Note: The cache line fill will use an AHB, BTR4 transfer. This translates to a 16 word
burst for a 16 bit device and is the largest AHB transfer supported by the memory
controller as a single transfer on the external bus. The memory controller supports
a 16 word burst using the continuous burst setting for FBBMSEL.
Page mode devices do not support WAIT and the relevant BUSRCONx.WAIT and
BUSWCONx.WAIT should be set to b00.
Note: This mode can only be used with devices that have a separate address and data
bus. Use with devices with muxed address/data connections will not return correct
data
14.12.11 Critical Word First Read Accesses

In the default case, the memory controller will always start a burst at the lowest address
possible and wrapping of the burst data is handled internally to the memory controller.
However, some burst devices implement a wrapping feature which is compatible with the
wrapped bursts used by the processor cache fill requests. If this is the case, there is an
advantage to using the wrapping mode in the device as the instruction required by the
processor (the critical word) can be fetched first from the external memory.
The mode is enabled by setting the BUSCONx.dba bit for the appropriate region. Once
enabled, the memory controller will not align the start address for the burst and the
device will be relied on to return data in the correct order. The memory controller must
fetch all the data in a single burst. If the transaction is split into multiple accesses on the
external bus by use of the FETBLEN field, the issued addresses will be incorrect.
Note: The cache line fill will use an AHB, BTR4 transfer. This translates to a 16 word
burst for a 16 bit device. The device must therefore support a 16 word wrap
setting. A 32 bit memory must support a 8 word wrap setting. The memory
controller supports a 16 word burst using the continuous burst setting for
FBBMSEL. Other BTR opcodes must not be generated for accesses to the
external memory by the system if this mode is enabled, otherwise data corruption
will occur.

XMC4500
XMC4000 Family
14.12.12 Example Burst Flash Access Cycle

The figure below shows an example burst flash access.
INT_CLK
BFCLKO
new
AP1 AP2 AP3 AH1 CDi1 CDi2 CPi1 CPi2 BP1 BP2 BP1 BP2 BP1 BP2 BP1 BP2 RP1 RP2
AP1
A(MAX:0) address X
ADV
CSx
RD
AD(15:0) data in data in data in

address data in (address 0)
(address 2) (address 4) (address 6)
(16 bit wide)
Data Next Data

Latched by Value Issued
EBU on +ve by FLASH in
edge of response to
INT_CLK +ve edge of
BFCLKO
Figure 14-24 Burst FLASH Read without Clock Feedback (burst length of 4)
Note:
4. The start of the cycle is synchronised to a +ve edge of the BFCLKO signal
5. The BFCLKO signal is used to clock the Burst FLASH devices
6. BFCLKO to Internal Clock frequency ratio can be programmed to 1:1, 1:2, 1:3 or 1:4.
Each BFCLKO +ve edge is generated from a +ve edge of internal clock
7. Addresses show are byte addresses
8. ADV signal positioning is programmable via the EBSE bitfield in the BUSCON
registers
Figure 14-24 shows an example of a burst read access (burst length of four) to a Burst
FLASH device with WAIT and clock feedback functions disabled.
Programmability of the length of the Address, Command Delay and Command phases
allows flexible configuration to meet the initial read access time of a Burst FLASH device.
Data is sampled at the end of each Burst Phase cycle. The Burst Phase is repeated the
appropriate number of times for the programmed burst length (programmable for lengths
of 1, 2, 4 or 8 via the BUSCONx.FETBLEN bit-field).
Figure 14-24 shows an access cycle with the following settings:-
Clock Feedback disabled.
Address Phase length = 3 EBU_CLK cycles (see ADDRC and Section 14.10.1).

XMC4500
XMC4000 Family
Command Delay Phase length = 3 EBU_CLK cycles (see CMDDELAY and

Section 14.10.3).
Command Phase length = 2 EBU_CLK cycles (see WAITRDC and Section 14.10.4).
Burst Phase length = 2 EBU_CLK cycles (see EXTCLOCK, EXTDATA and
Section 14.10.6).
Recovery Phase length = 2 EBU_CLK cycles (see Section 14.10.7).
Burst Length = 4 (see FETBLEN).
BFCLKO frequency = 1/2 of EBU_CLK frequency (see EXTCLOCK).
14.12.13 External Cycle Control via the WAIT Input

Memory Controller provides control of the Burst FLASH device via the WAIT input. This
allows Memory Controller to support operation of Burst FLASH while crossing Burst
FLASH page boundaries. During a Burst FLASH access the WAIT input operates in one
of four modes:-
Disabled
Early Wait for Page Load.
Wait for Page Load.
Abort and Retry Access.
Selection of the mode in which the WAIT input operates during Burst FLASH reads is
selected via the BUSCONx.wait bits.
Note: Selection of Disabled via the wait bit-field prevents the WAIT input having any
effect on a Burst FLASH access cycle
Wait for Page Load Mode

This mode supports devices which assert a WAIT output for the duration of clock cycles
in which the data output by the device is invalid or, alternatively, one clock cycle earlier
than the data output is invalid. This includes Intel and AMD Burst FLASH devices (and
compatibles) configured for Early Wait Generation Mode (BUSCONX.wait=01B) and
standard wait generation (BUSCONx.wait=10B).
In operation, the burst flash controller loads a counter with the required number of
samples at the start of each burst. At the end of each burst phase, the burst flash
controller samples the WAIT input and the data bus at the end of each Burst phase. If
WAIT is inactive, the sample is valid, the sample counter is decremented and the
sampled data is passed to the datapath of the Memory Controller. This synchronous
sampling means that the validity of the sample can not be determined until the clock
cycle after the end of the burst phase. The Burst Flash controller will therefore overrun
and generate extra burst phases until the sample counter is decremented to zero. Extra
data samples returned after the sample counter is zero will be discarded.
The only difference if early wait is used is that the validity of data in burst phase "n" is
determined by the value of WAIT in burst phase "n-1".

XMC4500
XMC4000 Family
This mode of operation is compatible with the use of clock feedback as, with feedback
enabled, WAIT is fed through the same resynchronisation signals as the data bus. The
only effect on operation is that the number of overrun cycles will increase as the
decrementing of the sample counter will be lagged by the resynchronisation stages.
During the initial phases of an access, WAIT is sampled on every edge of EBU_CLK.
This is so the first burst phase is working with an accurate value for the WAIT signal. To
ensure this is the case, the command phase should be of sufficient length to allow the
device to drive WAIT and for the signal to propagate to the controller.
14.12.14 Flash Non-Array Access Support

Several types of flash memories will assert WAIT permanently during an access which
is not directed to the memory array. An example of this would be polling the status
register to check if a programming operation has completed. If the BUSRCON[3:0].NAA
field is set, then an access to the region with AHB A(26) set will proceed as if the
appropriate wait field in BUSRCON[3:0] or BUSWCON[3:0] was set to 00B and WAIT
was disabled. When set, this field affects both read and write accesses.
14.12.15 Termination of a Burst Access

A burst read operation is terminated by de-asserting CSx signal followed by the
appropriate length Recovery Phase. Figure 14-25 shows an example of termination of
a burst access following the read of two locations (i.e. two Burst Phases) from a 16-bit
non-multiplexed Burst FLASH device.
AP2 CPi1 CPi2 BP1 BP2 BP1 BP2 RP1 RP2
INT_CLK
BFCLKO
A(MAX:0) address
ADV
CSx
RD
AD(15:0) data 1 data 2
Figure 14-25 Terminating a Burst by de-asserting CS

XMC4500
XMC4000 Family
14.12.16 Burst Flash Device Programming Sequences

Command sequences for some Burst Flash devices must not be interrupted by other
read/write operations to the same device. If this applies to an attached device, the AHB
bus master initiating the command sequence must ensure that no accesses are allowed
from another AHB bus master until the command sequence has completed.
14.12.17 Cellular RAM

Cellular RAM devices have been designed to meet the growing memory and bandwidth
demands of modern cellular phone designs. The devices have been designed with a
multi-protocol interface to allow use of the devices with existing memory interfaces (i.e.
by re-use of existing memory protocols). The supported interface protocols supported by
Cellular RAM devices are:-
1. SRAM (Asynchronous Read and Write).
2. NOR Flash (Synchronous Burst Read, Asynchronous Write).
3. Synchronous (Synchronous Burst Read and Write).
In principle, when using previous versions of Memory Controller, the first two of the
above modes (1 and 2 above) provided Cellular RAM support. For maximum
performance, the Memory Controller now supports Synchronous Mode (3 above) for
Cellular RAM (Synchronous Burst Read and Write).
As Cellular RAM Synchronous Mode consists of a Burst FLASH compatible Burst Read
access, Cellular RAM support has been provided by enhancing the Burst FLASH
interface by the inclusion of a Burst Write capability. For this reason Cellular RAM is
treated as a special type of Burst FLASH device.
Cellular RAM support is selected by programming the desired region as cellular RAM via
the BUSCONx.AGEN bit-field.
Synchronous Read Access

A Synchronous Cellular RAM Burst Read Access is compatible with a Burst FLASH
Burst Read Access. As a result preceding sections applying to Burst FLASH devices
apply and should be consulted for details of Cellular RAM Burst Read Accesses.

XMC4500
XMC4000 Family
Synchronous Write Access
INT_CLK
BFCLKO
BP1 BP2 new

AP1 AP2 AH1 AH2 CP1 CP2 BPi1 BPi2 BP1 BP2 BP1 BP2 BP1 BP2 RP1 RP2
AP1
A(MAX:16) -
muxed
address X
A(MAX:0) - non-
muxed
ADV
CSx
WR
WAIT
AD(15:0) address data out data out data out data out
(16 bit) (addr 0) (addr 2) (addr 4) (addr 6)
1 2 3 4 5
Data Latched Next Data

by CRAM in Value Issued
response to on +ve edge
+ve edge of of INT_CLK
BFCLKO
Figure 14-26 Burst Cellular RAM Burst Write Access (burst length of 4)
Note:
9. The start of the cycle is synchronised to a +ve edge of the BFCLKO signal
10. The BFCLKO signal is used to clock the Cellular RAM devices
11. BFCLKO to Internal Clock frequency ratio can be programmed to 1:1, 1:2, 1:3 or 1:4.
Each BFCLKO +ve edge is generated from a +ve edge of internal clock
12. Addresses show are byte addresses
13. ADV signal positioning is programmable via the EBSE bitfield in the BUSCON
registers
Figure 14-26 shows an example of a Cellular RAM burst write access.
Note: Figure 14-26 shows operation with a BFCLKO to EBU_CLK ratio of 1:2.
The Start of the access cycle is the same as for a Synchronous Read access (see
Figure 14-24) except that the WR signal is treated as an address phase signal (i.e. it is
asserted active during the Address Phase and Address Hold Phase and is then
deasserted). See Fujitsu FCRAM Support (burst write with WR active during data
phase) on Page 14-64 for alternative WR timing during burst write.
The remaining sequence is as follows (with reference to the figure above):-
1. At the positive edge of EBU_CLK labelled as 1 above the first Burst Phase starts.
As the state machine is currently in the command phase, the interface samples the
WAIT input. This is sampled as active. By coincidence, in this example, the Cellular

XMC4500
XMC4000 Family
RAM also deasserts its WAIT output as a response to this clock edge to signal that
it will start to take the data from the data bus on the BFCLKO rising clock edge after
the next (i.e. the rising edge of BFCLKO labelled as 5 above) - this need not be the
case.
2. At the positive edge of EBU_CLK labelled as 2 above the second programmed
EBU_CLK period of the Burst Phase begins.
3. At the positive edge of EBU_CLK labelled as 3 above the Burst FLASH evaluates
the WAIT sample from 1 above. As this sample was active the write data is not
updated. As this clock edge is coincident with the end of a burst phase the WAIT input
is resampled. The value of this new WAIT sample is inactive.
4. At the positive edge of EBU_CLK labelled as 5 above the Burst FLASH again
evaluates the WAIT sample from 3 above. As this sample was in-active, and the
edge is coincident with the end of a burst phase, the next data value is issued to the
AD(15:0) pins and the next Burst Phase is started.
This process continues until all the data is written.
Fujitsu FCRAM Support (burst write with WR active during data phase)
The FCRAM device type can be supported in two ways. Later FCRAMs have a
compatibility bit in the device configuration register which programmes the device to
expect the WR signal to be active with the address and to be latched with the ADV signal.
In this mode, FCRAM can be treated as an Infineon/Micron cellular RAM.
Alternatively, if a write is attempted to a region configured as a burst flash, the memory
controller will generate a burst write with the WR signal asserted with the write data. This
should be directly compatible with an FCRAM operating in its native mode.

The following table lists the programmable parameters for burst flash accesses. These
parameters only apply when the BUSCONx.AGEN parameter for a particular memory
region is set for access to synchronous burst devices (page mode or otherwise).
Table 14-26 Burst Flash Access Programmable Parameters

Parameter Function Register
ADDRC Number of cycles in Address Phase. BUSAPx
AHOLDC Number of cycles in Address Hold. BUSAPx
CMDDELAY Number of programmed Command BUSAPx
Delay cycles.
WAITRDC Number of programmed wait states BUSAPx
for read accesses.

XMC4500
XMC4000 Family
Table 14-26 Burst Flash Access Programmable Parameters (contd)

WAITWRC Number of programmed wait states BUSWAPx
for write accesses.
EXTDATA Extended data BUSAPx
RDRECOVC Number of minimum recovery cycles BUSRAPx
after a read access when the next
access is to the same region.
WRRECOVC Number of minimum recovery cycles BUSWAPx
after a write access when the next
access is to the same region.
RDDTACS Number of minimum recovery cycles BUSRAPx
after a read access when the next
access is to a different region.
WRDTACS Number of minimum recovery cycles BUSWAPx
after a write access when the next
access is to a different region.
WAIT Sampling of WAIT input: BUSCONx
OFF, SYNCHRONOUS,
ASYNCHRONOUS or
WAIT_CELLULAR_RAM
FBBMSEL Flash synchronous burst mode: BUSCONX
CONTINUOUS or DEFINED (as in
FETBLEN)
FETBLEN Synchronous burst length: BUSCONx
SINGLE, BURST2, BURST4 or
BURST8
BFCMSEL Flash Clock Mode, continuous or BUSRCONx
gated
EXTCLOCK Frequency of external clock at pin BUSCONx
BFCLKO:
equal, 1/2, 1/3 or 1/4 of EBU_CLK
EBSE delay ADV output to improve hold BUSCONx
margin
ECSE delay CS, WR and write data outputs BUSCONx
to improve hold margin
LOCKCS enable locked write sequences for BUSWCONx
this region

XMC4500
XMC4000 Family
Table 14-26 Burst Flash Access Programmable Parameters (contd)

FDBKEN enable clock feedback to improve BUSRCONx
read data margins
BFSSS disable second pipeline stage for BUSRCONx
clock feedback
DBA disable alignment of read bursts on BUSRCONx
external bus
AAP enable the "asynchronous address BUSCONx
phase" mode.
PORTW memory port width BUSRCONx
Note: datac is not used for burst write accesses
14.13 SDRAM Interface

The SDRAM interface supports:-
64 MBit (organized as 4 banks x 1M x 16)
128 MBit (as 4 banks x 2M x16)
256 MBit (as 4 banks x 4M x16) SDRAMs.
512 MBit (as 4 banks x 16M x16) SDRAMs.
The Memory Controller can support a single SDRAM region. To enable SDRAM support
the AGEN fields of a single register pair of BUSRCON and BUSWCON must be set to
"1000b".
Note: Programming the AGEN fields of multiple regions for SDRAM and connecting
multiple SDRAMs will result in data corruption as the "page open" tags in the
SDRAM controller will be applied indiscriminately to all connected devices.
14.13.1 Features
Compatible with mobile PC133/PC100 memories at 100 MHz (if maximum bus load
is not exceeded).
Mobile SDRAM support.
Multibank support.
Interleaved access support.
Support for 64, 128, 256 and 512 MBit SDRAM devices.
Auto-refresh mode support for power-down mode.
Data types (16-bit bus): byte and half-word for single reads/writes and half-word for
burst reads/writes.

XMC4500
XMC4000 Family
Power-on/mode-set sequence triggered by AHB write to SDRAM configuration

register.
Programmable refresh rate.
Programmable timing parameters (row-to-column delay, row-precharge time, mode-
register setup time, initialization refresh cycles, refresh periods).
14.13.2 Signal List

The following signals are used for the SDRAM interface:-
Table 14-27 SDRAM Signal List (16 bit support)

AD(15:0) I/O Data bus
AD(31:16) O Address bus
RD/WR O Read and write control
CKE O Clock enable
CS(3:0) O Chip select
SDCLK0 O/I External SDRAM Clock.
SDCLKI I External SDRAM Clock Feedback
RAS O Row Address Strobe for SDRAM accesses.
CAS O Column Address Strobe for SDRAM accesses.
DQM(1:0) O Data Qualifiers (output on BC(1:0))
14.13.3 External Interface

The external interface can be directly connected to DRAM chips without any glue-logic.
Special board layout and timing constraints may apply when additional
memory/peripherals (in addition to SDRAM devices) are directly connected to the bus.

XMC4500
XMC4000 Family
FLASH
SRAM
AD(15:0) D(15:0) ROM
AD(31:16) A(15:0)
CS[m] CS
SDRAM #1
CS
MEMCTRL other CS lines

CS
CS
Figure 14-27 Connectivity for 16 bit SDRAM
14.13.4 External Bus Clock Generation

The Memory Controller uses the EBU_CLK clock to generate all external bus access
sequences.
SDCLKO is required by SDRAM memories and the frequency of this output is controlled
by the BUSRAP.EXTCLOCK field of the highest priority (lowest region number) region
which has BUSRCON.AGEN set to "0b1000" which is the value used to select SDRAM.
BUWAP.EXTCLOCK has no effect for SDRAM.
Unless documented elsewhere, all outputs to the external bus are generated of the rising
edge of EBU_CLK. The SDCLKO signal (in 1:1 mode) is antiphase to EBU_CLK. This
means that the SDRAM memory device sees control signal changes occur on the
negative clock edge. The clock generation logic is constructed so that this relationship is
maintained for the other clock ratios.
Table 14-28 EXTCLOCK to clock ratio mapping

EXTCLOCK value SDCLKO divide ratio
00 1:1
01 1:2
10 1:4
11 1:4

XMC4500
XMC4000 Family
14.13.5 SDRAM Characteristics

SDRAMs are synchronous DRAMs with burst read/write capability which are controlled
by a set of commands at the pins CS, RAS, CAS, WE, DQM and A10. As for standard
DRAMs, a periodic refresh must be performed.
SDRAM devices are subdivided into banks. Each bank is subdivided into a number of
rows1). Each row is, in turn, subdivided into a number of columns. The number of
banks and the size of a row varies from one SDRAM device to another. A specific
location (half-word) within a device is specified by supplying a bank, row and column
address. Devices supported by Memory Controller must conform to the following
criteria:-
Number of Banks: 2 or 4 only.
Row Size: 256, 512 or 1024 only.
SDRAM devices produce high speed data transfer rates by use of the bank and row
architecture. When an initial access is made to a specific row within a specific bank then
Memory Controller must issue a row address to specify which row in which bank is to
accessed. In response to this the SDRAM device loads the entire row to a local (high
speed) buffer area. At this point (i.e. when the local buffer associated with a bank
contains data from the main SDRAM array) the bank is said to be open. Memory
Controller then issues a column address to specify which location(s) within the row are
to be accessed. Subsequent accesses to locations within the same row can then be
performed at high speed (with Memory Controller supplying only a column address)
since the appropriate data is already contained within the local buffer and there is no
requirement for the SDRAM to fetch data from the main SDRAM array. Prior to
accessing a location in a different row Memory Controller must issue a precharge
command so that the local buffer is written back to the main SDRAM array.
An SDRAM device provides a local buffer for each bank within the device, thus it is
simultaneously possible for each of the banks to be open, this is termed Multibanking.
Multibanking is supported in order to allow interleaved bank accesses. Comparison of
banks is done prior to initiating external memory accesses (see Section 14.13.13).
14.13.6 Supported SDRAM commands

Table 14-29 lists the supported SDRAM commands, how they are triggered and which
signals are activated:-
1) Previous Memory Controller documentation uses the term page to refer to a row. Where possible this has
been changed to reflect the more commonly used term row.

XMC4500
XMC4000 Family
Table 14-29 Supported SDRAM commands

See Table 14-41 for
Memory Controller pins
Command Event CKE CKE CS RAS CAS RD/ A121) A10 A BA
(n-1) (n) WR A11 (9:0) (1:0)
Device region H - H - - - - - - -
deselect not
selted
Nop idle H - L H H H - - - -
Bank activate open a H - L L H H valid address
closed
bank
Read read H - L H L H valid L valid
access addr address
Write write H - L H L L valid L valid
access addr address
Read with read H - L H L H valid H valid
autoprecharge access addr address
Write with write H - L H L L valid H valid
autoprecharge access addr address
Precharge bank H - L L H L - L - bank
selective or row
miss
Precharge all refresh H - L L H L - H - -
is due
or
going
into
power
down
Autorefresh refresh H H L L L H - - - -
is due,
after
precha
rge all
is done

XMC4500
XMC4000 Family
Table 14-29 Supported SDRAM commands (contd)

See Table 14-41 for
Memory Controller pins
Command Event CKE CKE CS RAS CAS RD/ A121) A10 A BA
(n-1) (n) WR A11 (9:0) (1:0)
Self refresh going H L L L L H - - - -
entry into
power
down
after
precha
rge all
is done
Self refresh exit coming L H H - - - - - - -
out of
power
down
Mode register during H - L L L L valid mode (see 00B
set initializ register SDRMOD)
ation
Extended Mode during H - L L L L valid mode (see 10B2)
register set initializ register SDRMOD)
ation
1) A12 is required by larger memories
2) 10B is default value for SDRAM. This can be changed using the SDRMCON.XBA field
14.13.7 SDRAM device size

Memory Controller supports SDRAMs with the following sizes:-
Size1): 64MBit, 128MBit, 256MBit and 512MBit.
14.13.8 Power Up Sequence

During power-up the SDRAM should be initialized with the proper sequence. This
includes the requirement of bringing up the VDD, VDDQ and the stable clock (minimum
200 s before any accesses to SDRAM) and CS remains inactive.
1) In addition verified support is limited to specific SDRAM device geometries (number of banks and row size).
Support for other sizes/geometries may be possible but this has not been verified.

XMC4500
XMC4000 Family
14.13.9 Initialization sequence

SDRAMs must be initialized before being used. Application of power must be followed
by 200 s pause (timed by software) with a stable clock. Then a Precharge All Banks
command must be issued. Following this, the device must go through Auto Refresh
Cycles (the number of refresh commands is programmable through Crfsh in SDRMCON
registers and the number of NOP cycles in between is programmable through Crc). At
the end of it, the Mode Register must be programmed through the address lines.
Following that some number of NOP cycles programmable through Crsc in SDRMCON.
Note: This sequence will be referred to as a "cold start",and is necessary when both the
memory and the memory controller have just had power applied. Conversely a
"warm start" will be required when the memory controller has just been powered
up but data has been retained in the external memory by the use of self refresh
mode.
The SDRAM controller will power up with the SDRAM clock set to gated mode and CKE
high. However until an EBU region is configured for SDRAM by setting
BUSRCON.AGEN the SDRAM clock and CKE pins will be allocated for GPIO.
Care must be taken during software configuration of Memory Controller to ensure the
correct SDRAM initialization sequence is generated for both cold start and warm start.
The recommended sequence for Memory Controller register initialization after a cold
start when using SDRAM devices is as follows:-
1. Write to SDRMREF to set CKE high. (SELFREX = 1) but leave all refresh fields at
0 to disable auto refresh. This will maintain CKE high when BUSRCON is written in
the next step
2. Write to BUSRCON to define which region has SDRAM connected and the required
divide ratio for the SDRAM clock.
3. Write to SDRMCON to configure the controller for the attached SDRAM device(s)
and to enable the SDRAM clock. (SDCMSEL=0.)
4. All other Memory Controller registers except SDRAM specific registers (i.e. other
than those listed below).
5. Wait for 200s (or the appropriate initialization delay required by the attached device)
6. Write to SDRMOD with the "COLDSTART" bit set to write the mode register values
to the SDRAM mode register.
7. Write to SDRMREF to configure refresh rate.
The recommended sequence for Memory Controller register initialization after a warm
start when using SDRAM devices is as follows:-
1. Write to BUSCON to define which region has SDRAM connected and the required
divide ratio for the SDRAM clock.
2. Write to SDRMCON to configure the controller for the attached SDRAM device(s)
and to enable the SDRAM clock. (SDCMSEL=0.)

XMC4500
XMC4000 Family
3. Write to SDRMREF to set CKE high. (SELFREX=1) but leave all refresh fields at 0
to disable
4. All other Memory Controller registers except SDRAM specific registers (i.e. other
than those listed below).
5. Write to SDRMOD with the "COLDSTART" bit cleared to update the mode register
values.
6. Write to SDRMREF to configure refresh rate.
Figure 14-28 SDRAM Initialization

The sequence is triggered by a write to the SDRAM mode register SDRMOD. A region
having AGEN in BUSCONx set to 1000B will be configured with the mode from
SDRMOD. While this sequence is being executed, sdrmbusy flag in the SDRMSTAT
status register will be set accordingly.

XMC4500
XMC4000 Family
Note: As no other accesses are permitted in the current implementation while the
SDRAM initialization sequence is running, it will not be possible to poll the
sdrmbusy bit at 1 unless there has been a failure in the controller logic.
The user has to make sure that the SDRAM is programmed in the following way:
Table 14-30 SDRAM Mode Register Setting

Field Value Meaning SDRMOD Corresponding
Position Address Pins
Burst length "100" bursts of length 16 burstl[2:0] A[2:0]
011 bursts of length 8
"000" bursts of length 1
Burst type 0 sequential bursts btyp[3] A[3]
CAS latency 001 reserved caslat[6:4] A[6:4]
010 latency 2
011 latency 3
1xx reserved
Operation Mode all 0 burst read and burst opmode [13:7] A[12:7]
write
The Memory Controller uses the CAS latency value and burst length to adjust the burst
read timing. All other fields have no influence on the Memory Controller, which means
only single value is accepted for those fields.
The complete initialization sequence described will only be issued on the first write (since
reset) to the SDRMOD register with the COLDSTART field set to logic 1. On
subsequent writes with the COLDSTART field set to logic 1, the SDRAM device does
not need to be initialized, so a simple mode register set command can be issued to
refresh the contents of the registers in the SDRAM. A precharge-all command needs to
be issued to the SDRAM before this can happen.
An initialization sequence will write to both the mode register and the extended mode
register (if the extended mode register has been enabled).
A write to the SDRMOD register with the COLDSTART cleared will update the EBU
register and will also write to the configuration registers of the SDRAM but will not
execute the refresh cycles which are part of the full initialization required at cold start.

XMC4500
XMC4000 Family
14.13.10 Mobile SDRAM Support

Mobile SDRAMs include an Extended Mode Register. This is accessed using a similar
mechanism to the existing PC-133 Mode Register but with an additional select code on
the SDRAM device BA pins.
The SDRMOD.XBA bits are used to select Mobile SDRAM support for each of the
SDRAM devices. If this field is non-zero, then the Extended Mode Register will be
automatically written during the Initialization phase (immediately after the standard
Mode Register write). In addition writes to the Extended Mode Register(s) will be
triggered by writes to the SDRMOD register (i.e. whenever the standard Mode Register
is written). The SDRMOD.XOPM bit-field is used to program the value that is to be
written to the Extended Mode Register. The SDRMOD.XBA bit-field is used to program
the logic levels asserted on the device BA(1:0) pins (i.e. to program the specific
command used to access the extended mode register).
The XBA field contains four bits even though there are only two bank address
connections to SDRAM devices. This is because, for normal accesses, the Memory
Controller assumes that the SDRAM bank address lines are connected to the least-
significant, available address lines (see Table 14-41 for details). This means that the
bank address inputs to the SDRAM can be connected to either A[13:12], A[14:13] or
A[15:14] depending on the number of rows in the connected SDRAM. The XBA field
value will be output on A[15:12] and the XOPM field will be output on A[11:0] allowing all
possible SDRAM connections to be handled correctly.
Note: In order to cater for possible future device variations the Memory Controller allows
the user to select the logic levels issued on the BA(1:0) pins during an Extended
Mode Register. Care should be taken in programming this bit field since it is
possible to generate an unwanted standard Mode Register write by use of this
bit field.
14.13.11 Burst Accesses
SDR Operation
The Memory Controller supports burst lengths of 1, 2, 4, 8 and 16. Bursts of other lengths
are supported but are implemented using data-masking. Burst length 16 is currently not
supported by available SDR memories.

XMC4500
XMC4000 Family
14.13.12 Short Burst Accesses
SDR Operation
The Memory Controller can be configured to generate SDRAM bursts lengths of either
one, four or eight via the SDRMOD.BURSTL bit fields. When configured for burst lengths
of four or eight the interface will use data masking to support shorter write accesses.
However, when configured for a burst length of one data masking is not used.
Figure 14-29 shows how short burst write accesses are handled. During the write
access data masking is activated (with zero clock latency) to prevent unwanted write
operation. Data masking is activated through the BCx outputs (connected to DQM)
during a write cycle.
Figure 14-29 Short Burst Write Access through Data Masking

The figure shows how a two beat burst write is translated to an eight beat burst write with
data masking. During the first two data cycles (C5 and C6) the BC0 and BC1 outputs are
driven low to cause the SDRAM device to write the required data. In cycle C7 the BC0
and BC1 outputs are driven high to mask subsequent data writes.
14.13.13 Multibanking Operation

The design supports up to 4 banks being simultaneously open for an SDRAM region.
This means that for each bank Memory Controller must track the status of the bank
(open or closed) and the last row address issued to that bank. This allows the Memory
Controller to determine whether each access is a row hit or a row miss.
A row hit means that the access can be serviced by data which is already in the
SDRAM local data buffer of the specified bank (i.e. the bank is open and the last row
address that was issued to the bank matches the row address for the current access
- see Section 14.13.5). In this case Memory Controller can then proceed with one of
the access commands without having to close the specified bank.

XMC4500
XMC4000 Family
A row miss means that the access cannot be serviced from the SDRAM local data
buffer (i.e. the specified bank is closed, or the last row address that was issued to the
bank does not match the row address of the current access). In this case Memory
Controller must close the specified bank and then re-open it with the new row
address.
The Memory Controller must be configured so that it can detect row hits and row
misses for different SDRAM configurations (number of banks/row size). This allows the
Memory Controller to properly issue the appropriate SDRAM commands to allow up to
four SDRAM rows to be kept open simultaneously (i.e. one row open in each bank
assuming a four bank device). To perform this Memory Controller maintains two items of
data for each bank:-
1. Bank status (1 bit): open or closed (upon reset all of these bits are preloaded with
closed).
2. Last row address (up to 18 bits).
These two items are referred to as a bank tag. In order to maintain these bank tags The
Memory Controller must be made aware of:-
The AHB address range that defines which bank is being accessed.
The AHB address range that defines which row is being accessed.
These AHB address ranges change according to the geometry of an SDRAM device.
Table 14-41 shows some examples of how banks and rows are determined from the
address bits. This configuration is performed by means of the Bank Mask and Row
Mask. For example, if the SDRAM is configured as:-
16-bit wide
4 banks in the device
8192 rows
row size of 512
The bank to be accessed is determined by bits 24 and 23 of the address
(Address[24:23]). Each open bank has an associated open row, and for our example the
row tag is Address[22:10].
Each time there is a new AHB request, the address is compared against the appropriate
bank tag. After one clock cycle there will be two decisions to make. If the current access
is targeted to an SDRAM region(s) then Memory Controller must determine whether the
requested address is a row hit or row miss.
14.13.14 Bank Mask

The "SDRMCON.BANKM" (bank mask) bit-field must be set to the appropriate value to
set the AHB address bit range used to detect which bank is being accessed. The value
to be written to this bit-field is determined by the device size setting (see SDRAM
device size on Page 14-71) and the number of banks in the device.

XMC4500
XMC4000 Family
When the device has 2 banks then the "BANKM" value must be set to include the
most significant address bit of the AHB address range occupied by the SDRAM
device (i.e. region) - see Table 14-41.
When the device has 4 banks then the "bankm" value must be set to include the most
significant two address bits of the AHB address range occupied by the SDRAM
device (i.e. region) - see Table 14-41.
The following settings should be used:-
Table 14-31 BANKM Selection

BANKM AHB Comment
setting Address Bits
used to
determine
bank hit/miss
0 none Reserved - do not use (default after reset).
1 AAHB[21 to 20] Bank Size = 8MBit

6 AAHB[26 to 25] Bank Size = 256MBit.
7 AAHB[27 to 26] not supported for SDRAM/DDRAM
14.13.15 Row Mask

The "SDRMCON.ROWM" bit-field must be set to the appropriate value to set the AHB
address range used to detect row hit/miss. The value to be written to this bit-field is
determined by the device size setting (see above), the number of banks in the device
and the number of rows in the device.
The following ROWM settings should be used:-

XMC4500
XMC4000 Family
Table 14-32 ROWM Selection

ROWM AHB Address Bits Comment
setting used to determine
row hit/miss
0 none Reserved - do not use (default after reset)
(Always generate row miss, may cause invalid
SDRAM command sequences).
1 AAHB[n to 9] Row size = 256 x 16-bit.
2 AAHB[n to 10] Row size = 512 x 16-bit, 256 x 32 bit.
3 AAHB[n to 11] Row size = 1024 x 16-bit, 512 x 32 bit.
4 AAHB[n to 12] Row size = 1024 x 32 bit.
5 AAHB[n to 13] Not appropriate.
6 reserved;
7 reserved;
It can be seen that the ROWM bit-field only has an effect on the low-end of the address
range used to determine the row address (i.e. for use in comparison of the AHB address
with the address stored in the bank tag). The upper end of the comparison is determined
by the BANKM setting. "n" is therefore (BANKM+18)
Decisions over row hit

When a row hit occurs, Memory Controller can continue the access operation without
updating the stored bank tag.
A row miss unfortunately can result in several other activities.
If the row miss is due to the bank being closed then Memory Controller does not have
to issue a precharge operation but can activate the bank, update the appropriate
bank tag to reflect the new bank status (i.e. to open with the specified row address)
and continue the access operation.
If the row miss occurs on an open bank then Memory Controller has to close the
current bank, (i.e. do a precharge). This is then followed by (re-)activating the bank,
updating the appropriate bank tag to reflect the new bank status (i.e. remaining
open with the new row address) and continuing the access operation.
Table 14-33 lists the activities on a cycle by cycle basis.

XMC4500
XMC4000 Family
Table 14-33 Cycle by cycle activities of multibanking operation

Cycle n Cycle n+1 Cycle n+2 Cycle n+3
Comparing the row_hit:
AHB address with Continue with read or not relevant not relevant
the stored bank write command.
tags.
row_miss and bank_open:
Issue Precharge to the Insert idle Continue with
specific bank and change cycles bank
the bank tag to reflect the (repeatable) to activate
new row address. satisfy tRP. command, etc.
row_miss and bank_closed:
Issue Bank Activate to
the specific bank and
change the bank tag to not relevant not relevant
reflect the new status
(open) and row address.
14.13.16 Banks Precharge

The system is required to precharge a bank under one of the following conditions:
1. When the next access to a bank is to a different row to the previous access within the
bank.
2. When an AHB request cannot be completed before the row active time tRAS max is due,
then the bank must explicitly be closed and opened again for the current request.
Since tRAS max (of the order of 100 s) is usually much greater compared to the refresh
period (distributed refresh is in order of 15 s for 4096 rows) this is generally fulfilled
by systematically carrying out refresh to the SDRAMs (see d below).
3. Accompanying a row miss is also naturally a selective bank precharge operation, as
mentioned previously.
4. All banks must also be pre-charged, when a refresh cycle is due as explained next.
See Section 14.13.17.
5. All banks must also be pre-charged, prior to issuing Self Refresh Entry command.
Activities in (1) and (3) are carried out as a result of the address comparison explained
in Section 14.13.13. Activity (2) and (4) are covered by refresh timer.
14.13.17 Refresh Cycles

It is required within certain time limit that the devices must be refreshed. Prior to being
refreshed the devices must be pre-charged as mentioned above.

XMC4500
XMC4000 Family
Figure 14-30 SDRAM Refresh

This sequence is periodically triggered by an internal refresh counter with programmable
rate set using the ERFSHC and refreshc fields in the SDRMREF register. These fields
are combined to create an eight bit value (ERFSHC as MSBs). This value is then
multiplied by 64 and used as the number of EBU_CLK cycles between refresh
operations being requested.
All SDRAM banks will be pre-charged before the refresh sequence can be started. The
specific refresh command being issued is Auto Refresh (CBR) command, in which the
device keeps track of the row addresses to be refreshed. The number of this command
being issued for each refresh operation is programmable through refreshr in
SDRMREF.
A refresh request has precedence over a AHB access to SDRAM, i.e. if both occur at the
same time the refresh sequence is entered and the AHB access is delayed. A refresh
error occurs when a previous refresh request has not been satisfied yet and another
refresh request occurs and an error flag (referr) in the SDRSTAT status register will be

XMC4500
XMC4000 Family
set accordingly. This error flag can be cleared by writing to SDRMCON respective to the
appropriate address region.
14.13.18 Self-Refresh Mode

SDRAM devices provide a Self-Refresh Mode. In this mode the SDRAM automatically
performs internal refresh sequences in response to an on-chip timer. Self Refresh Mode
is entry command is asserted with RAS, CAS, and CKE low and WE high. In Self-
Refresh Mode all external control signals except CKE (but including the clock) are
disabled). Returning CKE to high enables the clock and initiates the Self-Refresh Mode
exit operation. After the exit command, at least one tRC delay is required prior to any
access command.
Low Power SDRAMs provide additional power saving features such as:-
Programmable refresh period of the on-chip timer such that the refresh period can be
optimized (maximized) by taking the device operating temperature in to account.
Partial array self-refresh mode such that only selected banks will be refreshed. Data
written to the non-selected banks will be lost (due to lack of refresh to the bank) after a
period defined by tREF.
These additional features are programmed by issuing an Extended Mode Register write
(see Section 14.13.10).
To activate Self-Refresh Mode, software must write 1 to bit selfren in SDRMREF
register. Memory Controller will then:
1. precharge all the banks, and
2. issue a self refresh command (see Table 14-29) to all SDRAM devices (regardless
whether the device belongs to access type0 or type1).
In completion of this command all SDRAM devices will ignore all inputs but CKE signal.
The read-only bit selfrenst reflects the status of issuing this command. When the
command is completed, power-down can be safely entered. The devices would perform
low-current self refresh during the power down. When exiting from power-down and
before doing any accesses to SDRAM, software must write 1 to bit selfrex in
SDRMREF registers. Memory Controller will then assert the CKE signal for all the
SDRAM devices to get out of the self-refresh mode. The read-only bit selfrexst reflects
the completion of this command, upon which an access to SDRAMs can be performed.
As the SDRAM controller has CKE set low after reset a 1 must be written to SELFREX
as part of the initialization sequence to enable CKE. See Section 14.13.9.
Two additional fields affect the method the memory controller uses to exit self refresh.
1. After CKE is taken high (self refresh exit command), a single NOP cycle is generated.
The SDRMREF.ARFSH field is checked. If set to one a single auto refresh command
is output to the memory.
2. After step 1, the SDRMREF.SELFREX_DLY field is checked. If the field is non-zero,
the value in the field is used to generate a sequence of NOP instructions to the

XMC4500
XMC4000 Family
memory. This allows between 1 and 255 NOPs to be inserted before the device sees
a non-null command.
For predictable operation of the device during warm start, both the SDRMREF.ARFSH
and SDRMREF.SELFREX_DLY fields should be set to 0.
14.13.19 SDRAM Addressing Scheme

SDRAM devices use a multiplexed address issued as bank, row and column
addresses. The column address determines which location is being accessed within a
row. The row address determines which row is being accessed within a bank. Since row
sizes can differ from one SDRAM device to another it is necessary to provide a
programmable address multiplexing scheme. Selection of the multiplexing scheme is via
the "SDRMCON.AWIDTH" bit-field.
The "SDRMCOM.AWIDTH" bit-field must be set to the appropriate value to set the
address multiplexing (i.e. row/column) to be used to issue the address (and command)
to the SDRAM. The value to be written to this bit-field is determined by the device row
size.
Table 14-34 Selection of address multiplexing

AWIDTH Row size 16 bit DRAM
00B Reserved; do not use -
01B 256 words AAHB(8:0)
When performing byte writes, byte selection is handled via the BC(3:0) signals which
used to generate DQM signals during an SDRAM access.
Row Address Multiplexing

When a row address is issued (with the above specified settings):-
The most significant Memory Controller address outputs not required by the SDRAM
(A[24:16]) are driven with '0' (zero).
The least significant sixteen address outputs (AD[31:16]) are driven with the
(correctly aligned) row address. This address alignment is performed according to
the device row size specified by the "awidth" bit-field (see Table 14-35).
During the issue of a row address the following address multiplexing is used:-

XMC4500
XMC4000 Family
Table 14-35 Row address generation for 16 bit SDRAM

AWIDTH 16 bit, PORTW="01" Comment
Address Generation
(at Memory Controller pins)
01B A[24:16] = 0 Row size is 256 words.
AD[31:16] = AAHB[24:9]
AD[31:16] = AAHB[25:10]
AD[31:16] = AAHB[26:11]
Column Address Multiplexing

When a column address is issued (with the above specified settings):-
The most significant Memory Controller address outputs (A[24:16]) are driven with '0'
(zero).
The least significant ten address outputs (A[9:0]) are driven with the (correctly
aligned) column address. This address alignment is a one bit right shift of the AHB
address if the SDRAM is 16 bit or a two bit shift if the SDRAM is 32 bit.
Address output ten (A[10]) is driven with a command value (used by the SDRAM in
conjunction with the other control signals to determine which command is to be
executed.
The remaining address outputs (A[15:11]) are driven with the appropriate AHB
addresses (matching the multiplexing scheme for these pins during a row address
shown in Table 14-35 above) to ensure that consistent row selection is achieved (i.e.
the row information must be the same regardless of whether a row or column address
is being issued).
During the issue of a column address the following address multiplexing is used:-

XMC4500
XMC4000 Family
Table 14-36 Column Address Generation for 16 bit SDRAM

AWIDTH 16 bit, PORTW="01"Address Generation
(at Memory Controller pins)
01B A[24:16] = 0
A[15:11] = AAHB[24:20]
A[10] = Command
A[9:0] = AAHB[10:1]
10B A[24:16] = 0
A[15:11] = AAHB[25:21]
A[10] = Command
A[9:0] = AAHB[10:1]
11B A[24:16] = 0
A[15:11] = AAHB[26:22]
A[10] = Command
A[9:0] = AAHB[10:1]
Bank Address Multiplexing

A bank address is always issued whenever either a row or column address is issued. As
a result the Bank Address multiplexing must be the same regardless of whether a row or
column address is being issued. From Table 14-35 and Table 14-36 it can be see that,
with the same awidth value, the address multiplexing for the address output pins
A[15:11] is the same regardless of the type of address being issued.
Note: Memory Controller uses its address output pins to select the bank being accessed
(rather than having dedicated Bank Select outputs).
The SDRAM Bank Select pin(s) (BA0 and BA1) must be connected to the appropriate
Memory Controller A[15:11] address pins to ensure that they are driven by the
appropriate AHB Address (according to the SDRAM geometry). In practice this means
that BA0 and BA1 (if present) must be wired to the sequential Memory Controller
address outputs above those which are connected to the highest SDRAM address input.
As a result, since Memory Controller only supports devices with more rows than
columns, this can be determined directly from the number of rows in the device as
follows:-
Table 14-37 Bank Address to Memory Controller Address Pin Connection

Number of BA0 BA11)
Rows
2048 A[11] A[12]
4096 A[12] A[13]

XMC4500
XMC4000 Family
Table 14-37 Bank Address to Memory Controller Address Pin Connection (contd)
Number of BA0 BA11)
Rows
8192 A[13] A[14]
16384 A[14] A[15]
1) For devices with four banks only.
The following table shows all the multiplexing schemes discussed in the previous
sections:
Table 14-38 SDRAM Address Multiplexing Scheme

Port Address Pin Usage Mode
Width Type
column Memory Controller Pins A(9:0) := AAHB(10:1) all modes
address Memory Controller Pins A(10) := CMD
Memory Controller Pins A(15:11) := AAHB (26:22) awidth = 11
16-bit Memory Controller Pins A(15:11) := AAHB (25:21) awidth = 10

(PORTW Memory Controller Pins A(15:11) := AAHB (24:20) awidth = 01
= 01B) row Memory Controller Pins A(15:0) := AAHB(26:11) awidth = 11
address Memory Controller Pins A(15:0) := AAHB(25:10) awidth = 10
Memory Controller Pins A(15:0) := AAHB(24:9) awidth = 01
The Memory Controller requires the SDRAM to be configured to read / write bursts of
length 1, 4 or 8. A burst shorter than the programmed burst (e.g. a single access) can be
generated by masking the excess data phases with DQM. Due to the wrap around
feature of the SDRAMs a burst has to start at certain addresses to prevent the wrap
around (a burst must not cross an address modulo 8*4). This guarantees also that the
internal row boundaries of the SDRAMs will not be crossed by any burst access. For
bursts that are 16-bit wide transfers, AHB address A[0] of any burst address must be 0.
For bursts that are 16-bit wide transfers, AHB address A[1:0] of any burst address must
be 0. This restriction is currently enforced by the AHB interface logic which will split any
unsupported bursts into 32 bit transfers

XMC4500
XMC4000 Family
Table 14-39 16-bit Burst Address Restrictions, A[0] = "0"

Burst AHB Address A[4:1] SDRAM Burst Address Generation
Length
1 any single access
2 "--0" 0 -> 1
4 "--00" 0 -> 1 -> 2 -> 3
8 -000 (0) 0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7
16 "0000" 0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 ->
8 -> 9 -> 10 -> 11 -> 12 - 13 -> 14 -> 15
Table 14-40 32-bit Burst Address Restrictions, A(1:0) = "00"

Burst AHB Address A(4:2) SDRAM Burst Address Generation
Length
1 any single access
2 "--0" 0 -> 1
4 "-00" 0 -> 1 -> 2 -> 3
8 000 (0) 0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7
The following SDRAM types can be connected to Memory Controller:
Table 14-41 Supported Configurations for 16-bit wide data bus (Part 1)
SDRAM Memory Controller Pins
portw = 01B (16-bit) A(15) A(14) A(13) A(12) A(11) A(10) A(9:0)
1GBit SDRAM Pins BA(1) BA(0) A(13) A(12) A(11) A(10) A(9:0)
64Mx row RA(15) RA(14) RA(13) RA(12) RA(11) RA(10) RA(9:0)
16 col /BA(1) / BA(0) CMD CA(9:0)
512MBit SDRAM Pins BA(1) BA(0) A(12) A(11) A(10) A(9:0)
32Mx row RA(14) RA(13) RA(12) RA(11) RA(10) RA(9:0)
16 col / BA(1) / BA(0) CMD CA(9:0)
256MBit SDRAM Pins BA(1) BA(0) A(12) A(11) A(10) A(9:0)

16Mx row RA(14) RA(13) RA(12) RA(11) RA(10) RA(9:0)
16 col / BA(1) / BA(0) CMD CA(8:0)

XMC4500
XMC4000 Family
Table 14-41 Supported Configurations for 16-bit wide data bus (Part 1) (contd)
SDRAM Memory Controller Pins
portw = 01B (16-bit) A(15) A(14) A(13) A(12) A(11) A(10) A(9:0)
128MBit SDRAM Pins BA(1) BA(0) A(11) A(10) A(9:0)
8Mx row RA(13) RA(12) RA(11) RA(10) RA(9:0)
16 col / BA(1) / BA(0) CMD CA(8:0)
64MBit SDRAM Pins BA(1) BA(0) A(11) A(10) A(9:0)
4 col / BA(1) / BA(0) CMD CA(9:0)
8Mx8 row RA(13) RA(12) RA(11) RA(10) RA(9:0)
col / BA(1) / BA(0) CMD CA(8:0)
16 col / BA(1) / BA(0) CMD CA(7:0)
16MBit SDRAM Pins BS A(10) A(9:0)
4Mx4 row RA(11) RA(10) RA(9:0)
col / BA(0) CMD CA(9:0)
2Mx8 row RA(11) RA(10) RA(9:0)
col / BA(0) CMD CA(8:0)
1Mx row RA(11) RA(10) RA(9:0)
16 col / BA(0) CMD CA(7:0)
Table 14-42 Supported Configurations for 16-bit wide data bus (Part 2)
SDRAM Multiplexed AWIDTH
portw = 01B (16-bit) AHB Address setting
1GBit SDRAM Pins
64Mx row A(26:11) 11
16 col A(26:25), A(10:1)
512MBit SDRAM Pins
32Mx row A(25:11) 11
16 col A(25:23), A(10:1)

XMC4500
XMC4000 Family
Table 14-42 Supported Configurations for 16-bit wide data bus (Part 2) (contd)
SDRAM Multiplexed AWIDTH
portw = 01B (16-bit) AHB Address setting
256MBit SDRAM Pins
16Mx row A(24:10) 10
16 col A(24:23), A(9:1)
128MBit SDRAM Pins
8Mx row A(23:10) 10
16 col A(23:22), A(9:1)
64MBit SDRAM Pins
16Mx row A(24:11) 11
4 col A(24:23), A(10:1)
8Mx8 row A(23:10) 10
col A(23:22), A(9:1)
4Mx row A(22:9) 01
16 col A(22:21), A(8:1)
16MBit SDRAM Pins
4Mx4 row A(22:11) 11
col A(22), A(10:1)
2Mx8 row A(21:10) 10
col A(21), A(9:1)
1Mx row A(20:9) 01
16 col A(20), A(8:1)
Notes:
RA: row address
BA: bank select (MSB of row address)
CA: column address
CMD: auto pre-charge command is currently not supported
Areas in shades are not recommended for SDRAM configurations, in order to
minimize loads on the pads.
14.13.20 Power Down Mode

In order to reduce standby power consumption SDRAM devices provide a Power Down
Mode. All banks can optionally be precharged before the device enters Power Down

XMC4500
XMC4000 Family
mode. Once Power Down mode is initiated by holding CKE low, all receiver circuits
except for CLK and CKE are gated off. Power Down mode does not perform any refresh
operations, therefore to prevent loss of data, the device must not remain in Power Down
mode longer than the Refresh period (tREF) of the device. Exit from this mode is
performed by taking CKE high. One clock delay is required for power down mode entry
and exit.
The Memory Controller provides automatic support for Power Down Mode via the
SDRMCON.SDCMSEL (SDRAM clock mode select) bit. When this bit is 0 Power Down
mode will not be used and the SDRAM clock will always be present at the SDCLKO pin.
When the bit is 1 the device will automatically be placed into Power Down Mode when
there are no SDRAM accesses pending. In this case the SDRAM clock will only be
present during an Memory Controller-generated SDRAM access (data, refresh,
bank/row open etc.) and will be gated off at all other times.
When a refresh is required (at the programmed rate) Memory Controller will
automatically take the device out of Power Down Mode, issue the required refresh and
will then return the device to Power Down Mode (providing no other SDRAM accesses
are pending following the refresh).
By default, the Memory Controller automatically issues the Pre-Charge All command
sequence and closes all pages prior to entry into Power Down Mode
(SDRMCON.PWR_MODE set to 00B).
The memory controller can also be configured to use the auto-precharge option when
running a command (SDRMCON.PWR_MODE set to 01B) or not to precharge banks at
all (active power down mode) with SDRMCON.PWR_MODE set to 10B.
As a final option, "clock stop" power down mode is also supported. In this case, the clock
is disabled between accesses with no preparatory command cycles
(SDRMCON.PWR_MODE set to 11B).
The default reset state of Memory Controller is Power Down Mode enabled
(SDRMCON.SDCMSEL = 1).
Note: The programmer should be very careful about the use of this feature as external
devices may require this clock to be running in some modes. There are restrictions
within the PC-133 specification about when the clock can be disabled, especially
if the SDRAMs are operated in self-refresh mode.
A separate field SDRMCON.RES_DLY is provided to allow a delay to be programmed
after exiting the power down mode. This field is the delay, in external clock cycles
(NOPs), after CKE is taken high on exiting power down mode before another command
is permitted.
An additional bit SDRMCON.CLKDIS is provided to allow the clock output to be
completely disabled. The projected use for this bit is for DDR cold start where CKE
should be high before the clock is enabled. Setting this bit will allow a self refresh exit to
be performed to enable CKE without starting the clock.

XMC4500
XMC4000 Family
14.13.21 SDRAM Recovery Phases
Recovery after SDRAM Command

A recovery phase can be programmed to increase the minimum gap between an SDR
access and an access to another connected memory.
For write cycles, the minimum value for this gap is two periods of the internal clock
between last command/data driven and the next access starting (for DDR the gap for
data is one cycle). This can be increased by setting the BUSWAP.WRDTACS field to the
required number of internal clock cycles.
For read accesses, the gap can also be increased using the BUSRAP.RDDTACS field
in the same way. However, the counter is started when the last read command is issued
by the controller and the controller does not permit another device to be accessed until
two clock cycles after the last data has been read into the read buffers. As the read data
is significantly delayed by the latency through the read synchronization logic (minimum
latency is 2 clock cycles CAS latency plus 2 clock cycles internal latency), setting this for
read accesses is unlikely to make a significant difference unless very large values are
used.

The following table lists programmable parameters for SDRAM accesses. These
parameters only matter when parameter AGEN (in BUSCONx registers) for a particular
memory region is set to "1000b".
Table 14-43 SDRAM Access Programmable Parameters

refreshr Number of refresh commands SDRMREF
issued during each refresh
operation.
ERFSHC & Number of cycles (multiplied by 64) SDRMREF
refreshc between refresh operations:
0 : no refresh needed
1 - 255 : refresh period defined
ARFSH execute auto refresh on exit from self SDRMREF
refresh when set to one
SELFREX_DLY delay after exiting self refresh before SDRMREF
permitting any command other than
NOP

XMC4500
XMC4000 Family
Table 14-43 SDRAM Access Programmable Parameters (contd)

bankm To select one pattern for bank mask. SDRMCON
rowm To select one pattern for row mask SDRMCON
Crc Number of NOP cycles between SDRMCON
refresh commands.
Crcd Number of NOP cycles between a SDRMCON
row and column address
awidth Number of address bits to be used SDRMCON
for column address
Crp Number of NOP cycles after a SDRMCON
precharge command
Crsc Number of NOP cycles after a mode SDRMCON
register set command
Crfsh Number of refresh commands during SDRMCON
initialization
Cras Number of cycles between row SDRMCON
activate and a precharge command
opmode To specify write operation mode: SDRMOD
only BURST_WRITE is recognized
caslat To specify CAS latency: 2 or 3 clocks SDRMOD
btyp To specify burst operation mode: SDRMOD
SEQUENTIAL
burstl To specify burst length: 1,2,4, 8 or 16 SDRMOD
XOPM Value to be written to the extended SDRMOD
mode register
XBA Bank Address value to be used for SDRMOD
extended mode register write
sdrmbusy Indicate the busy status of SDRAM SDRSTAT
referr Indicate a refresh error SDRSTAT
SDERR Indicates an error has occurred on SDRSTAT
and SDRAM read
selfren To kick-off a self refresh entry SDRMREF
command
selfrenst Status of self refresh entry command SDRMREF

XMC4500
XMC4000 Family
Table 14-43 SDRAM Access Programmable Parameters (contd)

selfrex To kick-off a self refresh exit SDRMREF
command
selfrexst Status of self refresh exit command SDRMREF
autoselfr To activate automatic self refresh SDRMREF
entry/exit
RDDTACS recovery time after read command BUSRAP
before accessing another region
WRDTACS recovery time after write command BUSWAP
before accessing another region
EXTCLOCK ratio between internal clock and BUSRAP
external memory clock for SDRAM
accesses (no effect for DDR.
External clock always runs at
internal clock frequency)
14.14 Debug Behavior

The EBU will lock the external bus arbitration with the EBU owning the external bus to
allow the debug system unrestricted access to external memories if the debug suspend
input becomes active.
The entry into debug mode is controlled via the halted signal triggered by the CPU.
14.15.1 Clocks
The EBU receives two clocks from the system:
AHB bus clock
dedicated EBU clock
The dedicated EBU clock is allowed to be asynchronous to AHB clock. Therefore it is
also possible to run the EBU at a higher clock rate than the AHB. This mode is suitable
for higher performance applications.
If higher EBU performance is not required it is recommended to operate the EBU on the
AHB bus clock because this will save resynchronisation cycles.
The dedicated EBU clock is described on the SCU (System Control Unit) chapter as fEBU.
The AHB bus clock for the EBU block is described on the SCU chapter as fCPU.

XMC4500
XMC4000 Family
It is possible to program the fEBU frequency via the EBUCLKR register on the SCU.
The EBU clock, fEBU, can also be enabled or disabled via the CLKSET.EBUCEN and
CLKR.EBUCDI bitfields, respectively (see the SCU chapter for a complete description).
14.15.2 Module Reset

The EBU is configured so that its port control lines are going to be in the nobus state
during and after reset. In this state the EBU will still take control over the ports. It is not
wanted that this nobus state control is applied to the external pins until the EBU is
explicitly programmed by the user. Therefore the default state of the PORTS logic must
be so that EBU hardware control is ignored.
The assertion or deassertion of the EBU reset is controlled via the PRSET3.EBU and
PRCLR3.EBU bitfields, respectively (this fields are described on the SCU chapter).
14.15.3 Power
The EBU is inside the power core domain, therefore no special considerations about
power up or power down sequences need to be taken. For an explanation about the
different power domains, please address the SCU (System Control Unit) chapter.
An internal power down mode for the EBU, can be achieved by disabling the clock
provided to it. For this one should disable the clock via the specific SCU bitfield
(CLKR.EBUCDI).
14.16 System Dependencies

Following features are made available in the different packages.
Table 14-44 Supported operating modes per package

Mode 100 pins 144 pins
16-bit MUX Yes Yes
Twin 16-bit MUX No Yes
32-bit MUX No Yes
16-bit DEMUX, No Yes
Burst Flash
16-bit SDRAM No Yes

XMC4500
XMC4000 Family
14.17 Registers
This section describes the registers and programmable parameters of the EBU. All these
registers can be read in User Mode, but can only be written in Supervisor Mode.
All registers are reset by the module reset.

EBU 5800 8000H 5800 BFFFH -
Table 14-46 Registers Overview EBU Control Registers

CLC EBU Clock Control 0000H U, PV, PV, Page 14-97
Register 32 32
MODCON EBU Configuration 0004H U, PV, PV, Page 14-99
Register 32 32
ID EBU Module ID 0008H U, PV, PV, Page 14-123
Register 32 32
USERCON EBU Test/Control 000CH U, PV, PV, Page 14-122
Configuration Register 32 32
Reserved Reserved 0010H nBE nBE
ADDRSEL0 EBU Address Select 0018H U, PV, PV, Page 14-101
Register 0 32 32
ADDRSEL1 EBU Address Select 001CH U, PV, PV, Page 14-101
Register 1 32 32
Register 2 32 32
Register 3 32 32
BUSRCON0 EBU Bus Configuration 0028H U, PV, PV, Page 14-102
Register 0 32 32
BUSRAP0 EBU Bus Access 002CH U, PV, PV, Page 14-109
Parameter Register 0 32 32

XMC4500
XMC4000 Family
Table 14-46 Registers Overview EBU Control Registers (contd)

BUSWCON0 EBU Bus Configuration 0030H U, PV, PV, Page 14-106
Register 0 32 32
BUSWAP0 EBU Bus Access 0034H U, PV, PV, Page 14-111
Register 1 32, 46 32
Register 1 32 32
Register 2 32 32
Register 2 32 32
Register 3 32 32
Register 3 32 32
SDRMCON EBU, SDRAM Control 0068H U, PV, PV, Page 14-114
Register 32 32
SDRMOD EBU, SDRAM Mode 006CH U, PV, PV, Page 14-117
Register 32 32

XMC4500
XMC4000 Family
Table 14-46 Registers Overview EBU Control Registers (contd)

SDRMREF EBU, SDRAM Refresh 0070H U, PV, PV, Page 14-119
SDRSTAT EBU, SDRAM Status 0074H U, PV, PV, Page 14-121
Register 32 32
BFFCH
Access Restrictions
Note: The EBU registers are accessible only through word accesses. Half-word and byte
accesses on EBU registers will generate a bus error. Writes to unused address
space will not cause an error but be ignored.
14.17.1 Clock Control Register, CLC
CLC
EBU Clock Control Register (000H) Reset Value: 0011 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SYN
EBUDIVA DIV2 SYN
0 CAC EBUDIV DIV2
CK ACK C
K
r r r r rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 DISS DISR
r r rw

DISR 0 rw EBU Disable Request Bit
This bit is used for enable/disable control of the EBU.
0B EBU disable is not requested
1B EBU disable is requested

XMC4500
XMC4000 Family

DISS 1 r EBU Disable Status Bit
DISS is always read as 0, as accessing the register in
the EBU will cause the EBU to be automatically
enabled.
0B EBU is enabled (default after reset)
1B EBU is disabled
SYNC 16 rw EBU Clocking Mode
0B request EBU to run asynchronously to AHB bus
clock and use separate clock source
1B request EBU to run synchronously to ARM
processor (default after reset)
DIV2 17 rw DIV2 Clocking Mode
0B standard clocking mode. clock input selected
by SYNC bitfield (default after reset).
1B request EBU to run off AHB bus clock divided
by 2.
EBUDIV [19:18] rw EBU Clock Divide Ratio
00B request EBU to run off input clock
(default after reset)
01B request EBU to run off input clock divided by 2
SYNCACK 20 r EBU Clocking Mode Status
0B the EBU is asynchronous to the AHB bus clock
and is using a separate clock source
1B EBU is synchronous to the AHB bus clock
DIV2ACK 21 r DIV2 Clocking Mode Status
0B EBU is using standard clocking mode. clock
input selected by SYNC bitfield (default after
reset).
1B EBU is running off AHB bus clock divided by 2.
EBUDIVACK [23:22] r EBU Clock Divide Ratio Status
00B EBU is running off input clock
01B EBU is running off input clock divided by 2

XMC4500
XMC4000 Family

Note: While the DISR bit is implemented in the EBU, it connects to the standby logic
which will disable the clock tree. Standby mode will be exited automatically when
an attempt is made to access the EBU. This register can be Endinit-protected after
initialization. Writing to this register in this state will cause the EBU to generate an
AHB Error.
14.17.2 Configuration Register, MODCON
MODCON
EBU Configuration Register (004H)
Reset Value: 0000 0020H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ACC
ACC
ALE 0 SINH GLOBALCS LOCKTIMEOUT
SINH
ACK
rw r r rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ARB EXT LCK
ARBMOD SDT
TIMEOUTC SYN LOC 0 ABR STS
E RI
C K T
rw rw rw rw r rw r r

STS 0 r Memory Status Bit
Software access to the WAIT input pin to the EBU.
LCKABRT 1 r Lock Abort
Reserved, will read as 0

XMC4500
XMC4000 Family

SDTRI 2 rw SDRAM Tristate
The signals affected by this setting are CKE,
SDCLKO, CAS and RAS
0B SDRAM control signals are driven by the EBU
when the EBU does not own the external bus.
SDRAM cannot be shared.
1B SDRAM control signals are tri-stated by the
EBU when the EBU does not own the external
bus. The SDRAM can be shared.
EXTLOCK 4 rw External Bus Lock Control
0B External bus is not locked after the EBU gains
ownership
1B External bus is locked after the EBU gains
ownership
ARBSYNC 5 rw Arbitration Signal Synchronization Control
0B Arbitration inputs are synchronous
1B Arbitration inputs are asynchronous
ARBMODE [7:6] rw Arbitration Mode Selection
00B No Bus arbitration mode selected
01B Arbiter Mode arbitration mode selected
10B Participant arbitration mode selected
11B Sole Master arbitration mode selected
TIMEOUTC [15:8] rw Bus Time-out Control
This bit field determines the number of inactive cycles
leading to a bus time-out after the EBU gains
ownership.
00H Time-out is disabled.
01H Time-out is generated after 1 8 clock cycles.

FFH Time-out is generated after 255 8 clock
cycles.
LOCKTIMEOU [23:16] rw Lock Timeout Counter Preload
T Reserved, must be written with 0
GLOBALCS [27:24] rw Global Chip Select Enable
No effect, should be written with 0
ACCSINH 28 rw Access Inhibit request
Reserved, must be written with 0

XMC4500
XMC4000 Family

ACCSINHACK 29 r Access inhibit acknowledge
Reserved, will always read 0
ALE 31 rw ALE Mode
Switch the ADV output to be an active high ALE signal
instead of active low ADV.
0B Output is ADV
1B Output is ALE
0 3, 30 r Reserved
14.17.3 Address Select Register, ADDRSELx
ADDRSELx (x = 0-3)
EBU Address Select Register x (018H+x*4H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ALT REG
WPR
0 ENA ENA
OT
B B
r rw rw rw

REGENAB 0 rw Memory Region Enable
0B Memory region is disabled (default after reset).
1B Memory region is enabled.
ALTENAB 1 rw Alternate Region Enable
0B Memory region is disabled (default after reset).
1B Memory region is enabled.
WPROT 2 rw Memory Region Write Protect
0B Region is enabled for write accesses
1B Region is write protected.
0 [31:3] r Reserved

XMC4500
XMC4000 Family
14.17.4 Bus Configuration Register, BUSRCONx
BUSRCONx (x = 0-3)
EBU Bus Configuration Register (028H+x*10H)
Reset Value: 00D3 0040H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
WAI EBS ECS
AGEN 0 AAP WAIT PORTW BCGEN DBA
TINV E E
rw r rw rw rw rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BFC FBB
FDB BFS
0 NAA MSE MSE FETBLEN
KEN SS
L L
r rw rw rw rw rw rw

FETBLEN [2:0] rw Burst Length for Synchronous Burst
Defines maximum number of burst data cycles which
are executed by Memory Controller during a burst
access to a Synchronous Burst device.
000B 1 data access (default after reset).
001B 2 data accesses.
1xxB reserved.
FBBMSEL 3 rw Synchronous burst buffer mode select
0B Burst buffer length defined by value in
FETBLEN (default after reset).
1B Continuous mode. All data required for
transaction is transferred in a single burst.
BFSSS 4 rw Read Single Stage Synchronization:
The second read-data synchronization stage in the
pad-logic can be bypassed. Reduces access latency
at the expense of the maximum achievable operating
frequency.
0B Two stages of synchronization used. (maximum
margin)
1B One stage of synchronization used. (minimum
latency)

XMC4500
XMC4000 Family

FDBKEN 5 rw Burst FLASH Clock Feedback Enable
0B BFCLK feedback not used.
1B Incoming data and control signals (from the
Burst FLASH device) are re-synchronized to
the BFCLKI input.
BFCMSEL 6 rw Burst Flash Clock Mode Select
0B Burst Flash Clock runs continuously with values
selected by this register
1B Burst Flash Clock is disabled between
accesses
NAA 7 rw Enable flash non-array access workaround
set to logic one to enable workaround when region is
accessed with address bit 28 set. See
Section 14.12.14
ECSE 16 rw Early Chip Select for Synchronous Burst
0B CS is delayed.
1B CS is not delayed.
Note: (see Section 14.11.3 and
Section 14.12.7)
EBSE 17 rw Early Burst Signal Enable for Synchronous Burst
0B ADV is delayed.
1B ADV is not delayed.
Section 14.12.7)

XMC4500
XMC4000 Family

DBA 18 rw Disable Burst Address Wrapping
0B Memory Controller automatically re-aligns any
non-aligned synchronous burst access so that
data can be fetched from the device in a single
burst transaction.
1B Memory Controller always starts any burst
access to a synchronous burst device at the
address specified by the AHB request. Any
required address wrapping must be
automatically provided by the Burst FLASH
device.
Note: Care must be taken with the use of this
feature. The Burst capable device must
be programmed to wrap at the
appropriate address boundary prior to
selection of this mode. Section 14.12.11
WAITINV 19 rw Reversed polarity at WAIT
0B OFF, input at WAIT pin is active low (default
after reset).
1B Polarity reversed, input at WAIT pin is active
high.
Note: This bit has no effect when using Burst
FLASH Data Handshake Mode
BCGEN [21:20] rw Byte Control Signal Control
This bit field selects the timing mode of the byte
control signals.
00B Byte control signals follow chip select timing.
01B Byte control signals follow control signal timing
(RD, RD/WR) (default after reset).
10B Byte control signals follow write enable signal
timing (RD/WR only).
11B Reserved.
PORTW [23:22] rw Device Addressing Mode
See Table 14-11 and Table 14-13

XMC4500
XMC4000 Family

WAIT [25:24] rw External Wait Control
Function of the WAIT input. This is specific to the
device type (i.e. the AGEN field).
For Asynchronous Devices:
0D OFF (default after reset).
1D Asynchronous input at WAIT.
2D Synchronous input at WAIT.
3D reserved.
Note: See Section 14.11.6.1
For Synchronous Burst Devices:
1D Wait for page load (Early WAIT).
2D Wait for page load (WAIT with data).
3D Abort and retry access.
Note: See Section 14.12.13
AAP 26 rw Asynchronous Address phase:
Enables an access mode for synchronous memories
where the clock is not started until after the address
hold phase.
0B Clock is enabled at beginning of access.
1B Clock is enabled at after address phase.
AGEN [31:28] rw Device Type for Region
See Section 14.7.3

XMC4500
XMC4000 Family
14.17.5 Bus Write Configuration Register, BUSWCONx
BUSWCONx (x = 0-3)
EBU Bus Write Configuration Register(030H+x*10H)
Reset Value: 00D3 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
LOC WAI EBS ECS
AGEN AAP WAIT PORTW BCGEN 0
KCS TINV E E
rw rw rw rw r rw rw r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FBB
0 NAA 0 MSE FETBLEN
L
r r r rw rw

FETBLEN [2:0] rw Burst Length for Synchronous Burst
Defines maximum number of burst data cycles which
are executed by Memory Controller during a burst
access to a Synchronous Burst device.
000B 1 data access (default after reset).
1xxB reserved.
FBBMSEL 3 rw Synchronous burst buffer mode select
0B Burst buffer length defined by value in
FETBLEN (default after reset).
1B Continuous mode. All data required for
transaction transferred in single burst
NAA 7 r Enable flash non-array access workaround
When set to logic one workaround for non-array is
access when region is accessed with address bit 28
set is enabled. See Section 14.12.14. Mirror of
equivalent field in BUSRCON register. To set write to
equivalent field in BUSRCON register
0 [15:8] r Reserved
00H Reserved Value

XMC4500
XMC4000 Family

ECSE 16 rw Early Chip Select for Synchronous Burst
0B CS is delayed.
1B CS is not delayed.
Section 14.12.7)
EBSE 17 rw Early Burst Signal Enable for Synchronous Burst
0B ADV is delayed.
1B ADV is not delayed.
Section 14.12.7)
WAITINV 19 rw Reversed polarity at WAIT
0B OFF, input at WAIT pin is active low (default
after reset).
1B Polarity reversed, input at WAIT pin is active
high.
Note: This bit has no effect when using Burst
FLASH Data Handshake Mode
BCGEN [21:20] rw Byte Control Signal Control
This bit field selects the timing mode of the byte
control signals.
00B Byte control signals follow chip select timing.
01B Byte control signals follow control signal timing
(RD, RD/WR) (default after reset).
10B Byte control signals follow write enable signal
timing (RD/WR only).
11B Reserved.
PORTW [23:22] r Device Addressing Mode
See Table 14-11 and Table 14-12

XMC4500
XMC4000 Family

WAIT [25:24] rw External Wait Control
Function of the WAIT input. This is specific to the
device type (i.e. the AGEN field).
For Asynchronous Devices:
1D Asynchronous input at WAIT.
2D Synchronous input at WAIT.
3D reserved.
Note: See Section 14.11.6.1
For Synchronous Burst Devices:
1D Wait for page load (Early WAIT).
2D Wait for page load (WAIT with data).
3D Abort and retry access.
AAP 26 rw Asynchronous Address phase:
Enables an access mode for synchronous memories
where the clock is not started until after the address
hold phase.
0B Clock is enabled at beginning of access.
1B Clock is enabled at after address phase.
LOCKCS 27 rw Lock Chip Select
Enable Chip Select for Automatic Locking in the event
of a write access
0B Chip Select cannot be locked (default after
reset).
1B Chip Select will be automatically locked when
written to from the processor data port.
AGEN [31:28] rw Device Type for Region
See Section 14.7.3
0 [6:4], r Reserved
18

XMC4500
XMC4000 Family
14.17.6 Bus Read Access Parameter Register, BUSRAPx
BUSRAPx (x = 0-3)
EBU Bus Read Access Parameter Register
(02CH+x*10H) Reset Value: FFFF FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
EXTCLOC
ADDRC AHOLDC CMDDELAY EXTDATA
K
rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DATAC WAITRDC RDRECOVC RDDTACS
rw rw rw rw

RDDTACS [3:0] rw Recovery Cycles between Different Regions
This bit field determines the number of clock cycles of
the Recovery Phase between consecutive accesses
directed to different regions or different types of
access. See Section 14.10.7.
0000B No Recovery Phase clock cycles available.
0001B 1 clock cycle selected.

1110B 14 clock cycles selected.
RDRECOVC [6:4] rw Recovery Cycles after Read Accesses
This bit field determines the basic number of clock
cycles of the Recovery Phase at the end of read
accesses.


XMC4500
XMC4000 Family

WAITRDC [11:7] rw Programmed Wait States for read accesses
Number of programmed wait states for read
accesses. For synchronous accesses, this will always
be adjusted so that the phase exits on a rising edge
of the external clock.
00000B1 wait state.
00001B1 wait states.
00010B2 wait state.
...
DATAC [15:12] rw Data Hold Cycles for Read Accesses
This bit field determines the basic number of Data
Hold phase clock cycles during read accesses. It has
no effect in the current implementation
EXTCLOCK [17:16] rw Frequency of external clock at pin BFCLKO
00B Equal to INT_CLK frequency.
01B 1/2 of INT_CLK frequency.
11B 1/4 of INT_CLK frequency (default after reset).
Note: See Section 14.12.4.
EXTDATA [19:18] rw Extended data
See Section 14.10.6
00B external memory outputs data every BFCLK
cycle
01B external memory outputs data every two
BFCLK cycles
10B external memory outputs data every four
BFCLK cycles
11B external memory outputs data every eight
BFCLK cycles
CMDDELAY [23:20] rw Command Delay Cycles
This bit field determines the basic number of
Command Delay phase clock cycles.
0000B0 clock cycle selected.

1110B14 clock cycles selected.

XMC4500
XMC4000 Family

AHOLDC [27:24] rw Address Hold Cycles
the address hold phase.
0000B0 clock cycle selected
...
1110B14 clock cycles selected
ADDRC [31:28] rw Address Cycles
the address phase.
...
14.17.7 Bus Write Access Parameter Register, BUSWAPx
BUSWAPx (x = 0-3)
EBU Bus Write Access Parameter Register
(034H+x*10H) Reset Value: FFFF FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
EXTCLOC
ADDRC AHOLDC CMDDELAY EXTDATA
K
rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DATAC WAITWRC WRRECOVC WRDTACS
rw rw rw rw

XMC4500
XMC4000 Family

WRDTACS [3:0] rw Recovery Cycles between Different Regions
the Recovery Phase between consecutive accesses
directed to different regions or different types of
access. See Section 14.10.7

WRRECOVC [6:4] rw Recovery Cycles after Write Accesses
This bit field determines the basic number of clock
cycles of the Recovery Phase at the end of write
accesses.

WAITWRC [11:7] rw Programmed Wait States for write accesses
Number of programmed wait states for write
accesses. For synchronous accesses, this will always
be adjusted so that the phase exits on a rising edge
of the external clock.
00000B1 wait state.
00010B2 wait state.
...
DATAC [15:12] rw Data Hold Cycles for Write Accesses
This bit field determines the basic number of Data
Hold phase clock cycles during write accesses.


XMC4500
XMC4000 Family

EXTCLOCK [17:16] rw Frequency of external clock at pin BFCLKO
00B Equal to INT_CLK frequency.
11B 1/4 of INT_CLK frequency (default after reset).
EXTDATA [19:18] rw Extended data
00B external memory outputs data every BFCLK
cycle
01B external memory outputs data every two
BFCLK cycles
10B external memory outputs data every four
BFCLK cycles
11B external memory outputs data every eight
BFCLK cycles
CMDDELAY [23:20] rw Command Delay Cycles
This bit field determines the basic number of
Command Delay phase clock cycles.

AHOLDC [27:24] rw Address Hold Cycles
the address hold phase.
...
ADDRC [31:28] rw Address Cycles
the address phase.
...

XMC4500
XMC4000 Family
14.17.8 SDRAM Control Register, SDRMCON
SDRAM Control Register
SDRMCON
EBU SDRAM Control Register (068H) Reset Value: 8000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SDC
PWR_MO CLK
MSE CRCE BANKM ROWM CRC
DE DIS
L
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CRCD AWIDTH CRP CRSC CRFSH CRAS
rw rw rw rw rw rw

SDCMSEL 31 rw SDRAM clock mode select
1B clock disabled between accesses
0B clock continuously runs
Note: (see Section 14.13.20)
PWR_MODE [30:29] rw Power Save Mode used for gated clock mode
0H precharge before clock stop (default after reset)
1H auto-precharge before clock stop
2H active power down (stop clock without
precharge)
3H clock stop power down
CLKDIS 28 rw Disable SDRAM clock output
0B clock enabled
1B clock disabled
CRCE [27:25] rw Row cycle time counter extension
Extends the range of the Crc bit field (see below).

XMC4500
XMC4000 Family

BANKM [24:22] rw Mask for bank tag
AHB address bits to be used for determining bank
number.
0H Reserved; (default after reset)
1H Address bit 21 to 20
7H Address bit 26
ROWM [21:19] rw Mask for row tag
Number of address bits from bit 26 to be used for
comparing row tags.
0H reserved; (default after reset)
6H reserved
7H reserved
CRC [18:16] rw Row cycle time counter
Number of NOP cycles following a refresh command
before another command (other than a NOP) can be
issued to the SDRAM. Combined with the CRCE bit
as follows: Insert (CRCE * 8) + CRC + 1 NOP cycles.
CRCD [15:14] rw Row to column delay counter
Number of NOP cycles between a row address and a
column address: Insert CRCD + 1 NOP cycles
(default after reset CRCD is 0).

XMC4500
XMC4000 Family

AWIDTH [13:12] rw Width of column address
Number of address bits from bit 0 to be used for
column address. See also Section 14.13.19.
e.g. for 16 bit DRAMs
0H reserved, do not use
1H Address(8:0)
2H Address(9:0)
3H Address(10:0)
CRP [11:10] rw Row precharge time counter
Number of NOP cycles inserted after a precharge
command. The actual number performed can be
greater due to CAS latency and burst length. Insert
CRP + 1 NOP cycles (default after reset CRP is 0)
CRSC [9:8] rw Mode register set-up time
Number of NOP cycles after a mode register set
command. Insert CRSC + 1 NOP cycles (default after
reset CRSC is 0)
CRFSH [7:4] rw Initialization refresh commands counter
Number of refresh commands issued during power-
up initialization sequence. Perform CRFSH + 1
refresh cycles (default after reset CRFSH is 0)
CRAS [3:0] rw Row to precharge delay counter
Number of clock cycles between row activate
command and a precharge command. Minimum
CRAS + 1 clock cycles (default after reset CRAS is 0)

XMC4500
XMC4000 Family
14.17.9 SDRAM Mode Register, SDRMOD
SDRAM Mode Register
SDRMOD
EBU SDRAM Mode Register (6CH) Reset Value: 0000 0020H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
XBA XOPM
rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
COL
BTY
DST 0 OPMODE CASLAT BURSTL
P
ART
w r rw rw rw rw

XBA [31:28] rw Extended Operation Bank Select
Value to be written to the bank select pins of a
Mobile SDRAM device during an extended mode
register write operation. Control of these bits is
provided to allow support of future enhanced Mobile
SDRAM devices. See Section 14.13.10
Note: Care must be taken when programming these
bits to ensure that a valid extended mode
register access occurs (e.g. it is possible to
generate an extra unwanted standard mode
register write by incorrect programming of
these bits).
14. Consult the appropriate SDRAM documentation
for the function of these bits.

XMC4500
XMC4000 Family

XOPM [27:16] rw Extended Operation Mode
Value to be written to the extended mode register of
a Mobile SDRAM device. This value is issued to the
SDRAM via its address inputs during an extended
mode register write. This field is wider than current
extended mode registers to allow support of future
enhanced Mobile SDRAM devices.
Note: Consult the appropriate SDRAM
documentation for the function of these bits.
15. The Memory Controller provides a 13-bit wide bit-
field for the extended mode register to cater for
devices that could theoretically use an additional
control bit (in comparison to currently available
devices).
COLDSTART 15 w SDRAM coldstart
This bit will always read 0.
If a write to the SDRMOD register takes place with
this bit set, the SDRAM device mode register will be
updated to match the data written to the register. See
Section 14.13.9
OPMODE [13:7] rw Operation Mode
Memory Controller only supports burst write standard
operation.
000000BOnly this value must be written (default after
reset)
Note: Other values reserved.
CASLAT [6:4] rw CAS latency
Number of clocks between a READ command and
the availability of data.
2D Two clocks (default after reset)
3D Three clocks
BTYP 3 rw Burst type
Memory Controller only supports sequential burst.
0B Only this value should be written (default after
reset)
1B Reserved

XMC4500
XMC4000 Family

BURSTL [2:0] rw Burst length
Number of locations can be accessed with a single
command.
0D 1 (default after reset)
1D 2
2D 4
3D 8
4D 16
0 14 r Reserved
14.17.10 SDRAM Refresh Control Register, SDRMREF
SDRAM Refresh Control Register
SDRMREF
EBU SDRAM Refresh Control Register(070H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ARF
0 RES_DLY SELFREX_DLY
SH
r rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
AUT SEL SEL SEL SEL
ERFSHC OSE FRE FRE FRE FRE REFRESHR REFRESHC
LFR N NST X XST

RES_DLY [27:25] rw Delay on Power Down Exit
Number of NOPs after the SDRAM controller exits
power down before an active command is permitted.

XMC4500
XMC4000 Family

ARFSH 24 rw Auto Refresh on Self refresh Exit
If set to one, an auto refresh cycle will be performed
on exiting self refresh before the self refresh exit
delay. If set to zero, no refresh will be performed.
SELFREX_DLY [23:16] rw Self Refresh Exit Delay
Number of NOP cycles inserted after a self refresh
exit before a command is permitted to the
SDRAM/DDRAM.
ERFSHC [15:14] rw Extended Refresh Counter Period
This field is used to increase the range of the refreshc
field from 6 bits to 8 bits with ERFSHC being used as
bits 7 and 6 of the extended field and refreshc as bit
5 to 0.
AUTOSELFR 13 rw Automatic Self Refresh
When this bit is set to 1, Memory Controller will
automatically issue the Self Refresh Entry command
to all SDRAM devices when it gives up control of the
external bus, and will automatically issue Self
Refresh Exit when it regains control of the bus.
SELFREN 12 rw Self Refresh Entry
When this bit is written with 1 the Self Refresh Entry
command is issued to all SDRAM devices,
regardless whether they are attached to type 0 or
type 1.
SELFRENST 11 r Self Refresh Entry Status.
If this bit is set to 1, it means the Self Refresh Entry
command has been successfully issued. This bit is
reset when bit SELFREX is set to 1 or a reset takes
place.
SELFREX 10 rw Self Refresh Exit (Power Up).
When this bit is written with 1 the Self Refresh Exit
command is issued to all SDRAM devices,
regardless whether they are attached to type 0 or
type 1.

XMC4500
XMC4000 Family

SELFREXST 9 r Self Refresh Exit Status.
If this bit is set to 1, it means the Self Refresh Exit
command has been successfully issued. This bit is
reset when bit SELFREN is set to 1 or a reset takes
place.
REFRESHR [8:6] rw Number of refresh commands
The number of additional refresh commands issued
to SDRAM each time a refresh is due. Number of
refresh commands to use is REFRESHR + 1
REFRESHC [5:0] rw Refresh counter period
Number of clock cycles between refresh operations.
Refresh period is REFRESHC x 64 clock cycles.
14.17.11 SDRAM Status Register, SDRSTAT
SDRAM Status Register
SDRSTAT
EBU SDRAM Status Register (074H) Reset Value: 0001 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SDR
SDE REF
0 MBU
RR ERR
SY
r r r r

XMC4500
XMC4000 Family

SDERR 2 r SDRAM read error
SDRAM controller has detected an error when
returning read data
0B Reads running successfully
1B Read error condition has been detected
Note: This bit is reset by a write access to
SDRMCON.
SDRMBUSY 1 r SDRAM Busy
The status of power-up initialization sequence.
0B Power-up initialization sequence is not running
1B Power-up initialization sequence is running
REFERR 0 r SDRAM Refresh Error
Unsuccessful previous refresh request collides with a
new request.
This bit is reset by a write access to SDRMCON.
0B No refresh error.
1B Refresh error occurred.
0 [31:3] r Reserved
14.17.12 Test/Control Configuration Register, USERCON
USERCON
EBU Test/Control Configuration Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ADVI
0 ADDIO
O
r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 DIP
r rw

XMC4500
XMC4000 Family

DIP 0 rw Disable Internal Pipelining
Reserved, must be set to 0B
ADDIO [24:16] rw Address Pins to GPIO Mode
Individual Control Bits for Address Bus Bits 24 down
to 16 respectively.
0B Address Bit is required for addressing memory
1B Address Bit is available for GPIO function
ADVIO 25 rw ADV Pin to GPIO Mode
Control Bit for the ADV/ALE output
0B ADV pin is required for controlling memory
1B ADV pin is available for GPIO function
ID
EBU Module Identification Register (08H) Reset Value: 0014 C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
r r r

MOD_NUMBER [31:16 r Module Number
] Indicates the module identification number

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15 Ethernet MAC (ETH)

The Ethernet MAC (ETH) is a major communication peripheral that supports 10/100
MBit/s data transfer rates in compliance with the IEEE 802.3-2002 standard. The ETH
may be used to impliment Internet connected applications using IPv4 and IPv6. The ETH
also includes support for IEEE1588 time synchronisation to allow implimentation of Real
Time Ethernet protocols.
ETH Ethernet MAC Peripheral
MTL MAC Transaction Layer
PHY Physical Layer Interface
MMC MAC Management Counters
SMI Station Management Interface
COE Checksum Offload Engine
PMT Power Management
MII Media Independent Interface
RMII Reduced media Independent interface
The following document is reprinted with permission of Synopsys Inc.

No disclosure of Databook to Synopsys' Competitors without Synopsys consent. List of
Competitors is available from Infineon Technologies AG or Synopsys Inc.
15.1 Overview
The ETH peripheral is comprised of five major functional units. The ETH-Core takes user
provided data frames and formats them for transmission to an external PHY via an MII
or RMII interface. The ETH MAC Transaction Layer (MTL) acts as a bridge between the
application and the ETH Core. The MTL provides two 2K byte FIFOs to buffer the
transmit and receive frames. The application may write data frames directly to the MTL
(cut through mode) or more normally will use the dedicated ETH DMA unit. The ETH
DMA allows the application to define a region of RAM to be used as transmit and receive
buffers. DMA transfers are initiated by DMA descriptors which are also held in RAM. The
ETH also includes a system time module which allows timestamping of transmit and
receive frames. The ETH also includes an extensive set of MAC Mangement counters
which provide detailed bus statistics.
The ETH includes the following features, listed by category.

ETH, V1.1 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.1.1 ETH Core Features
Supports 10/100-Mbit/s data transfer rates with the following PHY interfaces
IEEE 802.3-compliant RMII/MII (default) interface to communicate with an external
Fast Ethernet PHY
Supports both full-duplex and half-duplex operation
Supports CSMA/CD Protocol for half-duplex operation
Supports IEEE 802.3x flow control for full-duplex operation
Optional forwarding of received pause control frames to the user application in
full-duplex operation
Back-pressure support for half-duplex operation
Automatic transmission of zero-quanta pause frame on deassertion of flow control
input in full-duplex operation
Preamble and start-of-frame data (SFD) insertion in Transmit, and deletion in
Receive paths
Automatic CRC and pad generation controllable on a per-frame basis
Options for Automatic Pad/CRC Stripping on receive frames
Programmable frame length to support Standard or Jumbo Ethernet frames with
sizes up to 16 KB
Programmable InterFrameGap (40-96 bit times in steps of 8)
Supports a variety of flexible address filtering modes:
Up to 3 additional 48-bit perfect (DA) address filters with masks for each byte
Up to 3 48-bit SA address comparison check with masks for each byte
64-bit Hash filter for multicast and uni-cast (DA) addresses
Option to pass all multicast addressed frames
Promiscuous mode support to pass all frames without any filtering for network
monitoring
Passes all incoming packets (as per filter) with a status report
Separate 32-bit status returned for transmission and reception packets
Supports IEEE 802.1Q VLAN tag detection for reception frames
Separate transmission, reception, and control interfaces to the Application
Supports 32-bit data transfer interface on the system-side
Complete network statistics with RMON/MIB Counters (RFC1757/RFC2819 /
RFC2665). It is completely under control of higher protocol level (SW) to make use
of these counters.
MDIO Master interface for PHY device configuration and management, e.g. for
switching the PHY in external loopback mode.
Detection of LAN wake-up frames and AMD Magic Packet frames
Enhanced Receive module for checking IPv4 header checksum and TCP, UDP, or
ICMP checksum encapsulated in IPv4 or IPv6 datagrams.
Module to support Ethernet frame time stamping as described in IEEE 1588-2008.
Sixty-four-bit time stamps are given in each frames transmit or receive status.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.1.2 DMA Block Features

The DMA block exchanges data between the MTL block and the XMC4500 memory. A
set of registers (DMA CSR) to control DMA operation is accessible by the XMC4500.
DMA features include:
32-bit data transfers
Single-channel Transmit and Receive engines
Fully synchronous design operating on a single system clock (except for CSR
module, when a separate CSR clock is configured)
Optimization for packet-oriented DMA transfers with frame delimiters
Byte-aligned addressing for data buffer support
Dual-buffer (ring) or linked-list (chained) descriptor chaining
Descriptor architecture, allowing large blocks of data transfer with minimum CPU
intervention; each descriptor can transfer up to 8 KB of data
Comprehensive status reporting for normal operation and transfers with errors
Individual programmable burst size for Transmit and Receive DMA Engines for
optimal bus utilization
Programmable interrupt options for different operational conditions
Per-frame Transmit/Receive complete interrupt control
Round-robin or fixed-priority arbitration between Receive and Transmit engines
Start/Stop modes
Separate ports for CPU CSR access and data interface
15.1.3 Transaction Layer (MTL) Features

The MTL block consists of two sets of FIFOs: a Transmit FIFO with programmable
threshold capability, and a Receive FIFO with a configurable threshold (default of
64 bytes).
MTL features include:
32--bit Transaction Layer block providing a bridge between the application and the -
CORE
Single-channel Transmit and Receive engines
Data transfers executed using simple FIFO-protocol
Synchronization for all clocks in the design (Transmit, Receive and system clocks)
Optimization for packet-oriented transfers with frame delimiters
Four Separate ports for system-side and -CORE-side transmission and reception
Two RAM-based asynchronous FIFOs of 2K Bytes depth with
synchronous/asynchronous Read and Write operation with respect to the Read and
Write clocks (one for transmission and one for reception)
Receive Status vectors inserted into the Receive FIFO after the EOF transfer enables
multiple-frame storage in the Receive FIFO without requiring another FIFO to store
those frames Receive Status.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Configurable Receive FIFO threshold (default fixed at 64 bytes) in Cut-Through

mode
Option to filter all error frames on reception and not forward them to the application
in Store-and-Forward mode
Option to forward under-sized good frames
Supports statistics by generating pulses for frames dropped or corrupted (due to
overflow) in the Receive FIFO
Supports Store and Forward mechanism for transmission to the core
Supports threshold control for transmit buffer management
Supports configurable number of frames to be stored in FIFO at any time. The default
is up to 8 frames in -MTL configuration.
Automatic generation of PAUSE frame control or backpressure signal to the -core
based on Receive FIFO-fill (threshold configurable) level.
Handles automatic retransmission of Collision frames for transmission
Discards frames on late collision, excessive collisions, excessive deferral and
underrun conditions
Software control to flush Tx FIFO
Data FIFO RAM chip-select disabled when inactive, to reduce power consumption
module to calculate and insert IPv4 header checksum and TCP, UDP, or ICMP
checksum in frames transmitted in Store-and-Forward mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.1.4 Monitoring, Test, and Debugging Support Features
Supports internal loopback on the MII for debugging

External loopback is supported via the integrated MDIO controlling the PHY
DMA states (Tx and Rx) given as status bits
Debug status register that gives status of FSMs in Transmit and Receive data-paths
and FIFO fill-levels.
Application Abort status bits
MMC (RMON) module in the core
Current Tx/Rx Buffer pointer as status registers
Current Tx/Rx Descriptor pointer as status registers

A block diagram of the ETHs major system configurations is provided in Figure 15-1.
TxFIFO R xFIFO
(Mem) (Mem)
AH B/AXI
Master D MA TxFC R xFC Optional
Interface PH Y
Interface
(RGMII/
GMAC RTBI/TBI/
SGMII/
RMII)
D MA OMR MAC
AH B/AXI Select
C SR R egister CSR
Slave (G)MII
Interface
GMAC-CORE
GMAC-MTL
GMAC-DMA
GMAC-AHB or GMAC-AXI
Figure 15-1 ETH Block Diagram

This chapter describes the structure and programming requirements of the features
within the ETH subsystem. Each significant programming feature is discussed in a
seperate section.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.2.1 ETH Core

The ETH core supports two interfaces towards the PHY chip, MII and RMII. The PHY
interface can be selected only once after reset. The ETH core communicates with the
application side with the MAC Transmit Interface (MTI), MAC Receive Interface (MRI)
and the MAC Control Interface (MCI).
15.2.1.1 Transmission
Transmission is initiated when the MTL Application pushes in data with the SOF . When
the SOF signal is detected, the ETH accepts the data and begins transmitting to the MII.
The time required to transmit the frame data to the RMII/MII after the Application initiates
transmission is variable, depending on delay factors like IFG delay, time to transmit
preamble/SFD, and any back-off delays for Half-Duplex mode. Until then, the ETH does
not accept the data received from MTL.
After the EOF is transferred to the ETH Core, the core complete normal transmission and
then gives the Status of Transmission back to the MTL. If a normal collision (in Half-
duplex mode) occurs during transmission, the ETH core makes valid the Transmit Status
to the MTL. It then accepts and drops all further data until the next SOF is received. The
MTL block should retransmit the same frame from SOF on observing a Retry request (in
the Status) from the ETH.
The ETH issues an underflow status if the MTL is not able to provide the data
continuously during the transmission. During the normal transfer of a frame from MTL, if
the ETH receives a SOF without getting an EOF for the previous frame, then it (the SOF)
is ignored and the new frame is considered as continuation of the previous frame.
The following six modules constitute the transmission function of the ETH:
Transmit Bus Interface Module (TBU)
Transmit Frame Controller Module (TFC)
Transmit Protocol Engine Module (TPE)
Transmit Scheduler Module (STX)
Transmit CRC Generator Module (CTX)
Transmit Flow Control Module (FTX)
Transmit Bus Interface Module

This module interfaces the transmit path of the ETH core with the external frame with a
FIFO interface.
This module also outputs the (32-bit) Transmit Status to the application at the end of
normal transmission or collision.
Additionally, this module outputs the Transmit Snapshot register value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Transmit Frame Controller Module

The Transmit Frame Controller (TFC) consists of two registers to hold data, byte
enables, and the last data control received from the TBU. The register provides a buffer
between the Application and the TPE to regulate data flow as well as converts the input
data into an 8-bit bus towards the TPE.
When the number of bytes received from the Application falls below 60
(DA+SA+LT+DATA), the state machine that interfaces with the TBU automatically
appends zeros to the transmitting frame to make the data length exactly 46 bytes to meet
the minimum data field requirement of IEEE 802.3. The ETH can be programmed not to
append any padding.
The cyclic redundancy check (CRC) for the Frame Check Sequence (FCS) field is
calculated before transmission to the TPE module. This value is computed by CTX
module. The TFC module receives the computed CRC and appends it to the data being
transmitted to the TPE module. When the ETH is programmed to not append the CRC
value to the end of Ethernet frames, the TFC module ignores the computed CRC and
transmits only the data received from the TBU module to the TPE module. An exception
to this rule is that when the ETH is programmed to append pads for frames
(DA+SA+LT+DATA) less than 60 bytes sent by the TBU module, the TFC module will
append the CRC at the end of padded frame.
The TFC converts the data received from the TBU into 8-bit data for the TPE module.
Transmit Protocol Engine Module

The Transmit Protocol Engine (TPE) module consists of a transmit state machine that
controls the operation of Ethernet frame transmission. The modules transmit state
machine performs the following functions to meet the IEEE 802.3 specifications.
Generates preamble and SFD
Generates jam pattern in Half-Duplex mode
Jabber timeout
Flow control for Half-Duplex mode (back pressure)
Generates transmit frame status
Contains time stamp snapshot logic for IEEE 1588 support
When a new frame transmission from the TFC is requested, the transmit state machine
sends out the preamble and SFD, followed by the data received. The preamble is
defined as 7 bytes of 10101010B pattern, and the SFD is defined as 1 byte of 10101011B
pattern.
The collision window is defined as 1 slot time (512 bit times for 10/100 Mbit/s Ethernet ).
The jam pattern generation is applicable only to Half-Duplex mode, not to Full-Duplex
mode. In Full-Duplex mode, the transmit state machine ignores the collision signal from
the PHY.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
In MII mode, if a collision occurs any time from the beginning of the frame to the end of
the CRC field, the transmit state machine sends a 32-bit jam pattern of 55555555H on
the MII to inform all other stations that a collision has occurred. If the collision is seen
during the preamble transmission phase, the transmit state machine completes the
transmission of preamble and SFD and then sends the jam pattern.
If the collision occurs after the collision window and before the end of the FCS field (or
the end of Burst if the Frame Burst mode is enabled), the transmit state machine sends
a 32-bit jam pattern and sets the late collision bit in the transmit frame status.
The TPE module maintains a jabber timer to cut off the transmission of Ethernet frames
if the TFC module transfers more than 2048 (default) bytes. The time-out is changed to
10240 bytes when the Jumbo frame is enabled.
The Transmit state machine uses the deferral mechanism for the flow control (Back
Pressure) in Half-Duplex mode. When the Application requests to stop receiving frames,
the Transmit state machine sends a JAM pattern of 32 bytes whenever it senses a
reception of a frame, provided the transmit flow control is enabled. This will result in a
collision and the remote station will back off. The Application requests the flow control by
setting ETH0_FLOW_CONTROL.FCA_BPA bit. If the application requests a frame to be
transmitted, then it will be scheduled and transmitted even when the backpressure is
activated. Note that if the backpressure is kept activated for a long time (and more than
16 consecutive collision events occur) then the remote stations will abort their
transmissions due to excessive collisions.
If IEEE 1588 time stamping is enabled for the transmit frame, this block takes a snapshot
of the system time when the SFD is put onto the transmit MII bus. The system time
source is either an external input or internally generated, according to the configuration
selected.
Transmit Scheduler Module

The Transmit Scheduler (STX) module is responsible for scheduling the frame
transmission on the MII. The two major functions of this module are to maintain the inter-
frame gap between two transmitted frames and to follow the Truncated Binary
Exponential Back-off algorithm for Half-Duplex mode. This module provides an enable
signal to the TPE module after satisfying the IFG and Back-off delays.
The STX module maintains an idle period of the configured inter-frame gap
(ETH0_MAC_CONFIGURATION.IFG bits) between any two transmitted frames. If
frames from the TFC arrive at the TPE module sooner than the configured IFG time, the
TPE module waits for the enable signal from the STX module before starting the
transmission on the MII. The STX module starts its IFG counter as soon as the carrier
signal of the MII goes inactive. At the end of programmed IFG value, the module issues
an enable signal to the TPE module in Full-Duplex mode. In Half-Duplex mode and when
IFG is configured for 96 bit times, the STX module follows the rule of deference specified
in Section 4.2.3.2.1 of the IEEE 802.3 specification. The module resets its IFG counter

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
if a carrier is detected during the first two-thirds (64-bit times for all IFG values) of the
IFG interval. If the carrier is detected during the final one third of the IFG interval, the STX
module continues the IFG count and enables the transmitter after the IFG interval.
The STX module implements the Truncated Binary Exponential Back-off algorithm when
it operates in Half-Duplex mode.
Transmit CRC Generator Module

The Transmit CRC Generator (CTX) module interfaces with the TFC module to generate
CRC for the FCS field of the Ethernet frame. The TFC module sends the frame data and
any necessary padding to the CTX module through an 8-bit interface.
This module calculates the 32-bit CRC for the FCS field of the Ethernet frame. The
encoding is defined by the following generating polynomial.
G (x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
The module gets the Ethernet frames byte data from the TFC module (DA + SA + LT +
DATA + PAD) qualified with a Data Valid signal. The TFC also indicates to the CTX when
to reset the previously calculated CRC and to start the new CRC calculation for the
coming frame. The TFC module issues the start command before sending the new frame
data for calculation. The calculated CRC is valid on the next clock after the data is
received.
Transmit Flow Control Module

The Transmit Flow Control (FTX) module generates Pause frames and transmit them to
the TFC module as necessary, in Full-Duplex mode. The TFC module receives the
Pause frame from the FTX module, appends the calculated CRC, and sends the frame
to the TPE module. Pause frame generation can be initiated in two ways. The Application
can request the FTX module to send a Pause frame either by setting the
ETH0_FLOW_CONTROL.FCB bit or in response to the receive FIFO full conditions
(packet buffer).
If the Application has requested the flow control by setting the FLOW_CONTROL.FCB
bit of, the FTX module will generate and transmit a single Pause frame to the TFC
module. The value of the Pause Time in the generated frame contains the programmed
Pause Time value in the FLOW_CONTROL Register. To extend the pause or end the
pause prior to the time specified in the previously transmitted Pause frame, the
application must request another Pause frame transmission after programming the
Pause Time register with appropriate value.
If the Application has requested the flow control by asserting the mti_flowctrl_i signal, the
FTX module will generate and transmit a Pause frame to the TFC module. The value of
the Pause Time in the generated frame contains the programmed Pause Time value in
the FLOW_CONTROL Register. The FTX module monitors the MTI Flow Control Signal
. If it remains asserted at a configurable number of slot-times (FLOW_CONTROL.PLT

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
bits ) before this Pause-time runs-out, a second Pause frame will be transmitted to the
TFC module. The process will be repeated as long as the MTI flow control signal remains
asserted.
If the MTI flow control signal goes inactive prior to the sampling time, the FTX module
will transmit a Pause frame with zero Pause Time to indicate to the remote end that the
receive buffer is ready to receive new data frames.
15.2.1.2 MAC Transmit Interface Protocol

The MAC Transmit Interface (MTI) connects the application with the MTL in the ETH to
provide the Ethernet data for transmission.
The application initiates the Ethernet frame transmission by writing the first data of the
frame to the ETH, provided the ETH is ready to accept data . The Application can push-
in data as long as the ETH core is ready to accept it.
If the frame transmission is not successful (due to underflow, collision, jabber timeout,
excessive deferral events), the ETH core will assert the transmit status even before the
EOF is received. The Application will have to take the appropriate action as per the
status. The ETH will drop all further data input to it until the next SOF.
15.2.1.3 Reception
A receive operation is initiated when the ETH detects an SFD on the MII. The core strips
the preamble and SFD before proceeding to process the frame. The header fields are
checked for the filtering and the FCS field used to verify the CRC for the frame. The
received frame is stored in a shallow buffer until the address filtering is performed. The
frame is dropped in the core if it fails the address filter.
The following are the functional blocks in the Receive path of the ETH core.
Receive Protocol Engine Module (RPE)
Receive CRC Module (CRX)
Receive Frame Controller Module (RFC)
Receive Flow Control Module (FRX)
Receive IP Checksum checker (IPC)
Receive Bus Interface Unit Module (RBU)
Address Filtering Module (AFM)
Receive Protocol Engine Module

The RPE consists of the receive state machine which strips the preamble SFD. Once the
external PHY detects ethernet traffic, the RPEs receive state machine begins hunting
for the SFD field from the receive modifier logic. Until then, the state machine drops the
receiving preambles. Once the SFD is detected, the state machine begins sending the
data of the Ethernet frame to the RFC module, beginning with the first byte following the
SFD (destination address).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
If IEEE 1588 time stamping is enabled, the RPE takes a snapshot of the system time
when any frame's SFD is detected on the MII. Unless the MAC filters out and drops the
frame, this time stamp is passed on to the application.
In MII mode, the RPE converts the received nibble data into bytes, then forwards the
valid frame data to the RFC module
The receive state machine of the RPE module decodes the Length/Type field of the
receiving Ethernet frame. If the Length/Type field is less than 600 (hex) and if the MAC
is programmed for the auto crc/pad stripping option, the state machine sends the data of
the frame up to the count specified in the Length/Type field, then starts dropping bytes
(including the FCS field). The state machine of the RPE module decodes the
Length/Type field and checks for the Length interpretation.
If the Length/Type field is greater than or equal to 600 (hex), the RPE module will send
all received Ethernet frame data to the RFC module, irrespective of the value on the
programmed auto-CRC strip option.
As a default, the ETH is programmed for watchdog timer to be enabled, that is, frames
above 2.048 (10.240 if Jumbo Frame is enabled) bytes (DA + SA + LT + DATA + PAD +
FCS) are cut off at the RPE module. This feature can be disabled by programming the
ETH0_MAC_CONFIGURATION.WD bit. However even if the watchdog timer is
disabled, frames greater than 16 KB in size are cut off and a watchdog time-out status
is given.
The ETH supports loopback of transmitted frames onto its receiver. As a default, the
ETH loopback function is disabled, but this feature can be enabled by programming the
ETH Configuration register, Loopback bit. The transmit and receive clocks can have an
asynchronous timing relationship, so an asynchronous FIFO is used to make the
loopback path of the PHY transmit path connected onto the receive path. The
asynchronous FIFO is 6 bits wide to accommodate the PHY transmit,receive and enable
signals. The FIFO is nine words deep and free-running to write on the write clock and
read on every read clock.
The write and read pointers gets re-initialized to have an offset of 4 at the start of each
frame read out of the FIFO. This helps to avoid overflow/underflow during the transfer of
a frame, and ensures that the overflow/underflow occurs only during the IFG period
between the frames. Please note that the FIFO depth of nine is sufficient to prevent data
corruption for frame sizes up to 9.022 bytes with a difference of 200 ppm between the
MII Transmit and Receive clock frequencies. Hence, bigger frames should not be looped
back, as they may get corrupted in this loopback FIFO.
At the end of every received frame, the RPE module generates received frame status
and sends it to the RFC module. Control, missed frame, and filter fail status are added
to the receive status in the RFC module.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Receive CRC Module

The Receive CRC (CRX) interfaces to the RPE module to check for any CRC error in the
receiving frame.
This module calculates the 32-bit CRC for the received frame that includes the
Destination address field through the FCS field. The encoding is defined by the following
generating polynomial.
G (x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
The module gets the data from the RPE module (DA+SA+LT+DATA+PAD+FCS). The
RPE module also sends a control signal that indicates the validity of the data.
Irrespective of the auto pad/CRC strip, the CRX module receives the entire frame to
compute the CRC check for received frame. As a note on the auto pad/CRC strip
settings, the entire frame is not transferred between the RPE and RFC 8-bit interface.
Receive Checksum Offload Engine

The Receive Checksum Offload engine can detect both IPv4 and IPv6 frames in the
received ethernet packets. Once an IP frame is detected it is processed for data integrity.
The Receive Checksum Offload engine is enabled by setting the
ETH0_MAC_CONFIGURATION.IPC bit. The ETH receiver identifies IPv4 or IPv6
frames by checking for value 0800H or 86DDH, respectively, in the received Ethernet
frames Type field. This identification applies to VLAN-tagged frames as well.
The Receive Checksum Offload engine calculates IPv4 header checksums and checks
that they match the received IPv4 header checksums. The result of this operation (pass
or fail) is given to the RFC module for insertion into the receive status word. The IP
Header Error bit is set for any mismatch between the indicated payload type (Ethernet
Type field) and the IP header version, or when the received frame does not have enough
bytes, as indicated by the IPv4 headers Length field (or when fewer than 20 bytes are
available in an IPv4 or IPv6 header).
This engine also identifies a TCP, UDP or ICMP payload in the received IP datagrams
(IPv4 or IPv6) and calculates the checksum of such payloads properly, as defined in the
TCP, UDP, or ICMP specifications. This engine includes the TCP/UDP/ICMPv6 pseudo-
header bytes for checksum calculation and checks whether the received checksum field
matches the calculated value. The result of this operation is given as a Payload
Checksum Error bit in the receive status word. This status bit is also set if the length of
the TCP, UDP, or ICMP payload does not tally to the expected payload length given in
the IP header.
As mentioned in TCP/UDP/ICMP Checksum Engine, this engine bypasses the payload
of fragmented IP datagrams, IP datagrams with security features, IPv6 routing headers,
and payloads other than TCP, UDP or ICMP.
In this configuration, the core does not append any payload checksum bytes to the
received Ethernet frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Receive Frame Controller Module

The Receive Frame Controller (RFC) receives the Ethernet frame data and status from
the RPE module. The RFC module consists of a FIFO of parameterized depth (default
set to 4 deep and 37 bits wide) and two state machines for writing and reading the FIFO.
The FIFO holds the received Ethernet frame data and byte enables, along with a control
bit to indicate the last data. The state machines manage the FIFO and provide a frame
buffering for the receiving Ethernet frame from the RPE module. The main functions of
the RFC module are:
Data path conversion, which converts the 8-bit data to 32-bit data to the RBU module.
Frame filtering
Attaching the calculated IP Checksum input from IPC.
Update the Receive Status and forward to RBU.
If the ETH0_MAC_FRAME_FILTER.RA bit is set, the RFC module initiates the data
transfer to the RBU module as soon as 4 bytes of Ethernet data are received from the
RPE module. At the end of the data transfer, the RFC module sends out the received
frame status that includes the frame filter bits (MAC_FRAME_FILTER.SA Filterfail and
MAC_FRAME_FILTER.DA Filterfail) and status from the RFC module. These bits are
generated based on the filter-fail signals from the AFM module. This status bit indicates
to the Application whether the received frame has passed the filter controls (both
address filter and Frame Filter controls from CSR). The RFC module will not drop any
frame on its own in this mode.
If the MAC_FRAME_FILTER.RA bit is reset, the RFC module performs frame filtering
based on the destination/source address (the Application still needs to perform another
level of filtering if it decides not to receive any bad frames like runt, CRC error frames,
etc. The RFC module waits to receive the first 14 bytes of received data (type field) from
the RPE module. Until then, the module will not initiate any transfers to the RBU module.
After receiving the destination/source address bytes, the RFC checks the filter-fail signal
from the AFM module for an address match. On detecting a filter-fail from AFB, the frame
is dropped at the RFC module and not transferred to the Application.
On a delayed filter response from the AFM (this can only occur if you change the AFM
logic), the RFC module waits until the FIFO is full, and then proceeds with the frame
transfer to the RBU module. However, it will still take the delayed response from the AFM
module and if it is a (DA/SA) filter failure, then it will drop the rest of the frame and send
the Rx Status Word (with zero frame-length, CRC Error and Runt Error bits set)
immediately indicating the filter-fail. If there is no response from the AFM until the end of
frame is transmitted, the filter fail status in the Rx Status Word is updated accordingly.
When the PMT module is configured for power-down mode, all received frames are
dropped by this block, and are not forwarded to the application.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Receive Flow Control Module

The Receive Flow Controller (FRX) detects the receiving Pause frame and pauses the
frame transmission for the delay specified within the received Pause frame. The FRX
module is enabled only in Full-Duplex mode. The Pause frame detection function can be
enabled or disabled with the ETH0_FLOW_CONTROL.RFE bit.
Once the receive flow control is enabled, the FRX module begins monitoring the
received frame destination address for any match with the multicast address of the
control frame (0180C2000001H). If a match is detected, the FRX module indicates to the
RFC module, that the destination address of the received frame matches the reserved
control frame destination address. The RFC module then decides whether or not to
transfer the received control frame to the Application, based on the
ETH0_MAC_FRAME_FILTER.PCF bit .
The FRX module also decodes the Type, Op-code, and Pause Timer field of the
receiving control frame. At the end of received frame, the FRX module gets the received
frame status from RPE. If the byte count of the status indicates 64 bytes, and if there is
no CRC error, the FRX module requests the MAC transmitter to pause the transmission
of any data frame for the duration of the decoded Pause Time value, multiplied by the
slot time (64 byte times). Meanwhile, if another Pause frame is detected with a zero
Pause Time value, the FRX module resets the Pause Time and gives another pause
request to the Transmitter. If the received control frame matches neither the Type field
(8808H), Opcode (00001H), nor byte length (64 bytes), or if there is a CRC error, the FRX
module does not generate a Pause request to Transmitter.
In the case of a pause frame with a multicast destination address, the RFC filters the
frame based on the address match from the FRX module. For a pause frame with a
unicast destination address, the filtering in the FRX module depends on whether the DA
matched the contents of the MAC Address Register 0 and the
ETH0_FLOW_CONTROL.UP bit is set (detecting a pause frame even with a unicast
destination address). The MAC_FRAME_FILTER.PCF register bits control the filtering
for control frames in addition to the Address filter module.
Receive Bus Interface Unit Module

The Receive Bus Interface Unit (RBU) converts the 32-bit data received from the RFC
module into a 32-bit FIFO protocol on the Application side. The RBU module interfaces
with the Application through the MAC receive interface (MRI).
If IEEE 1588 time stamping is enabled, the RBU also outputs the time stamp captured
from the received frame.
Address Filtering Module

The Address Filtering (AFM) module performs the destination and source address
checking function on all received frames and reports the address filtering status to the

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RFC module. The address checking is based on different parameters (Frame Filter
register) chosen by the Application. These parameters are inputs to the AFM module as
control signals, and the AFM module reports the status of the address filtering based on
the combination of these inputs. The AFM module does not filter the receive frames by
itself, but reports the status of the address filtering (whether to drop the frame or not) to
the RFC module. The AFM module also reports whether the receiving frame is a
multicast frame or a broadcast frame, as well as the address filter status.
The AFM module probes the 8-bit receive data path between the RPE module and the
RFC module and checks the destination and source address field of each incoming
packet. In MII mode the module takes 14/26 clocks (from the start of frame) to compare
the destination/ source address of the receiving frame. The AFM module gets the
stations physical (MAC) address and the Multicast Hash table from CSR module for
address checking. The CSR module provides the Frame Filter register parameters to
AFM.
Unicast Destination Address Filter

The AFM supports up to 4 MAC addresses for unicast perfect filtering. If perfect filtering
is selected (HUC bit of Frame Filter register is reset), the AFM compares all 48 bits of
the received unicast address with the programmed MAC address for any match. Default
MacAddr0 is always enabled, other addresses MacAddr1MacAddr3 are selected with
an individual enable bit. Each byte of these other addresses (MacAddr1MacAddr3) can
be masked during comparison with the corresponding received DA byte by setting the
corresponding Mask Byte Control bit in the register. This helps group address filtering for
the DA.
In Hash filtering mode (When HUC bit is set), the AFM performs imperfect filtering for
unicast addresses using a 64-bit Hash table. For hash filtering, the AFM uses the upper
6 bits CRC of the received destination address to index the content of the Hash table. A
value of 000000 selects Bit 0 of the selected register, and a value of 111111 selects Bit
63 of the Hash Table register. If the corresponding bit (indicated by the 6-bit CRC) is set
to 1, the unicast frame is said to have passed the Hash filter; otherwise, the frame has
failed the Hash filter.
Multicast Destination Address Filter

The ETH can be programmed to pass all multicast frames by setting the
ETH0_MAC_FRAME_FILTER.PM bit. If the MAC_FRAME_FILTER.PM bit is reset, the
AFM performs the filtering for multicast addresses based on the
MAC_FRAME_FILTER.HMC bit. In Perfect Filtering mode, the multicast address is
compared with the programmed MAC Destination Address registers (131). Group
address filtering is also supported.
In Hash filtering mode, the AFM performs imperfect filtering using a 64-bit Hash table.
For hash filtering, the AFM uses the upper 6 bits CRC of the received multicast address

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
to index the content of the Hash table. A value of 000000B selects Bit 0 of the selected
register and a value of 111111B selects Bit 63 of the Hash Table register.
If the corresponding bit is set to 1, then the multicast frame is said to have passed the
Hash filter; otherwise, the frame has failed the Hash filter.
Hash or Perfect Address Filter

The DA filter can be configured to pass a frame when its DA matches either the Hash
filter or the Perfect filter by setting the MAC_FRAME_FILTER.HPF bit and setting the
corresponding ETH0_MAC_FRAME_FILTER.HUC or MAC_FRAME_FILTER.HMC
bits. This configuration applies to both unicast and multicast frames. If the HPF bit is
reset, only one of the filters (Hash or Perfect) is applied to the received frame.
Broadcast Address Filter

The AFM doesnt filter any broadcast frames in the default mode. However, if the ETH is
programmed to reject all broadcast frames by setting the MAC_FRAME_FILTER.DBF
bit, the DAF module asserts the Filter fail signal to RFC, whenever a broadcast frame is
received. This will tell the RFC module to drop the frame.
Unicast Source Address Filter

The ETH can also perform a perfect filtering based on the source address field of the
received frames. By default, the AFM compares the SA field with the values programmed
in the SA registers. The MAC Address registers [1:3] can be configured to contain SA
instead of DA for comparison, by setting Bit 30 of the corresponding Register. Group
filtering with SA is also supported. The frames that fail the SA Filter are dropped by the
ETH if the MAC_FRAME_FILTER.SAF bit of Frame Filter register is set.
When MAC_FRAME_FILTER.SAF bit is set, the result of SA Filter and DA filter is
ANDed to decide whether the frame needs to be forwarded. This means that either of
the filter fail result will drop the frame and both filters have to pass in-order to forward the
frame to the application.
Inverse Filtering Operation

For both Destination and Source address filtering, there is an option to invert the filter-
match result at the final output. These are controlled by the DAIF and SAIF bits of the
Frame Filter register respectively. The MAC_FRAME_FILTER.DAIF bit is applicable for
both Unicast and Multicast DA frames. The result of the unicast/multicast destination
address filter is inverted in this mode. Similarly, when the MAC_FRAME_FILTER.SAIF
bit is set, the result of unicast SA filter is reversed.
Table 15-2 and Table 15-3 summarize the Destination and Source Address filtering
based on the type of frames received.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-2 Destination Address Filtering Table

Frame PR HPF HUC DAIF HMC PM DB DA Filter Operation
Type
Broadcast 1 X X X X X X Pass
0 X X X X X 0 Pass
0 X X X X X 1 Fail
Unicast 1 X X X X X X Pass all frames.
0 X 0 0 X X X Pass on Perfect/Group
filter match.
0 X 0 1 X X X Fail on Perfect/Group filter
match.
0 0 1 0 X X X Pass on Hash filter match.
0 0 1 1 X X X Fail on Hash filter match.
0 1 1 0 X X X Pass on Hash or
Perfect/Group filter match.
0 1 1 1 X X X Fail on Hash or
Perfect/Group filter match.
Multicast 1 X X X X X X Pass all frames.
X X X X X 1 X Pass all frames.
0 X X 0 0 0 X Pass on Perfect/Group
filter match and drop
PAUSE control frames if
PCF = 0x.
0 0 X 0 1 0 X Pass on Hash filter match
and drop PAUSE control
frames if PCF = 0x.
0 1 X 0 1 0 X Pass on Hash or
Perfect/Group filter match
frames if PCF = 0x.
0 X X 1 0 0 X Fail on Perfect/Group filter
match and drop PAUSE
control frames if PCF = 0x.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-2 Destination Address Filtering Table (contd)

Frame PR HPF HUC DAIF HMC PM DB DA Filter Operation
Type
0 0 X 1 1 0 X Fail on Hash filter match
frames if PCF = 0x.
0 1 X 1 1 0 X Fail on Hash or
Perfect/Group filter match
frames if PCF = 0x.
Table 15-3 Source Address Filtering Table

Frame PR SAIF SAF SA Filter Operation
Type
Unicast 1 X X Pass all frames.
0 0 0 Pass status on Perfect/Group filter match but do not
drop frames that fail.
0 1 0 Fail status on Perfect/Group filter match but do not drop
frame.
0 0 1 Pass on Perfect/Group filter match and drop frames that
fail.
0 1 1 Fail on Perfect/Group filter match and drop frames that
fail.
15.2.2 MAC Transaction Layer (MTL)

The MAC Transaction Layer provides FIFO memory to buffer and regulate the frames
between the application system memory and the ETH core. It also enables the data to
be transferred between the application clock domain and the ETH clock domains. The
MTL layer has 2 data paths, namely the Transmit path and the Receive Path. The data
path for both directions is 32-bit wide and operates with a simple FIFO protocol.
The ETH-MTL communicates with the application side with the Application Transmit
Interface (ATI), Application Receive Interface (ARI), and the MAC Control Interface
(MCI).
15.2.2.1 Transmit Path

DMA controls all transactions for the transmit path through the ATI. Ethernet frames read
from the system memory is pushed into the FIFO by the DMA. The frame is then popped

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
out and transferred to the ETH core when triggered. When the end-of-frame is
transferred, the status of the transmission is taken from the ETH core and transferred
back to the DMA.
The Transmit FIFO has a depth of 22K bytes. A 2 FIFO-fill level is indicated to the DMA
so that it can initiate a data fetch in required bursts from the system memory, using the
Bus interface. The data from the Bus Master interface is pushed into the FIFO with the
appropriate byte lanes qualified by the DMA. The DMA also indicates the start-of-frame
(SOF) and end-of-frame (EOF) transfers along with a few signals controlling the pad-
insertion/CRC generation for that frame in the ETH core.
Per-frame control bits, such as Automatic Pad/CRC Stripping disable, time stamp
capture, and so forth are taken as control inputs on the ATI, stored in a separate register
FIFO, and passed on to the core transmitter when the corresponding frame data is read
from the Transmit FIFO.
There are two modes of operation for popping data towards the ETH core. In Threshold
mode, as soon as the number of bytes in the FIFO crosses the configured threshold level
(or when the end-of-frame is written before the threshold is crossed), the data is ready
to be popped out and forwarded to the ETH core. The threshold level is configured using
the TTC bits of DMA ETH0_BUS_MODE Register. In store-and-forward mode, the MTL
pops the frame towards the ETH core only when one or more of the following conditions
are true:
When a complete frame is stored in the FIFO
When the TX FIFO becomes almost full
When the ATI watermark becomes low. The watermark becomes low when the
requested FIFO does not have space to accommodate the requested burst-length on
the ATI.
Therefore, the MTL never stops in the store-and-forward mode even if the Ethernet
frame length is bigger than the Tx FIFO depth.
The application can flush the Transmit FIFO of all contents by setting the
ETH0_OPERATION_MODE.FTF bit. This bit is self-clearing and initializes the FIFO
pointers to the default state. If the FTF bit is set during a frame transfer from the MTL to
the ETH core, then the MTL stops further transfer as the FIFO is considered to be empty.
Hence an underflow event occurs at the ETH transmitter and the corresponding Status
word is forwarded to the DMA.
Initialization through Transmit Status Word detail initialization and transmit operations
for the MTL Layer.
Initialization
Upon reset, the MTL is ready to manage the flow of data to and from the DMA and the
ETH .

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
There are no requirements for enabling the MTL. However, the ETH block and the DMA
controller must be enabled individually through their respective CSRs.
Single-Packet Transmit Operation

During a transmit operation, the MTL block is slaved to the DMA controller. The general
sequence of events for a transmit operation is as follows.
1. If the system has data to be transferred, the DMA controller, if enabled, fetches data
from the XMC4500 RAM through the Bus Master interface and starts forwarding it to
the MTL. The MTL pushes the data received from the DMA into the FIFO. It continues
to receive the data until the end-of frame of the frame is transferred.
2. The data is taken out of the FIFO and sent to the MAC by the FIFO controller engine.
When the threshold level is crossed or a full packet of data is received into the FIFO,
the MTL pops out the frame data and drives them to the ETH core. The engine
continues to transfer data from the FIFO until a complete packet has been transferred
to the MAC. Upon completion of the frame, the MTL receives the Status from the ETH
and then notifies the DMA controller
Transmit OperationTwo Packets in the Buffer
1. Because the DMA must update the descriptor status before releasing it to the CPU,
there can be at the most two frames inside a transmit FIFO. The second frame will
be fetched by the DMA and put into the FIFO only if the OSF (Operate on Second
Frame bit is set). If this bit is not set, the next frame will be fetched from the memory
only after the MAC has completely processed the frame and the DMA has released
the descriptors.
2. If the OSF bit is set, the DMA starts fetching the second frame immediately after
completing the transfer of the first frame to the FIFO. It does not wait for the status to
be updated. The MTL, in the meantime, receives the second frame into the FIFO
while transmitting the first frame. As soon as the first frame has been transferred and
the status is received from the MAC, the MTL pushes it to the DMA. If the DMA has
already completed sending the second packet to the MTL, it must wait for the status
of the first packet before proceeding to the next frame.
Transmit OperationMultiple Packets in Buffer

In ETH -MTL configuration, the transmit FIFO can be configured to accept more than 2
packets at a time. This option limits the number of status words that can be stored in the
MTL before it is transferred to the DMA/CPU. By default, this number is limited to 2 but
can be configured for 4 or 8 as well. Once the MTL FIFO accepts the number of frames
equal to the status FIFO depth, it will stop accepting further frames unless the transmit
Status that is given out and accepted by the CPU/DMA thus freeing up the space in this
small FIFO.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Retransmission During Collision

While a frame is being transferred from the MTL to the ETH , a collision event occurs on
the ETH line interface in Half-Duplex mode. The ETH then indicates a retry attempt to
the MTL by giving the status even before the end-of-frame is transferred from MTL. Then
the MTL will enable the retransmission by popping out the frame again from the FIFO.
After more than 96 bytes are popped towards the ETH core, the FIFO controller frees up
that space and makes it available to the DMA to push in more data. This means that the
retransmission is not possible after this threshold is crossed or when the ETH core
indicates a late-collision event.
Transmit FIFO Flush Operation

The ETH provides a control signal to the software to flush the Transmit FIFO in the MTL
layer through the use of the ETH0_OPERATION_MODE.FTF bit. The Flush operation is
immediate and the MTL clears the Tx FIFO and the corresponding pointers to the initial
state even if it is in the middle of transferring a frame to the ETH Core. The data which
is already accepted by the MAC transmitter will not be flushed. It will be scheduled for
transmission and will result in underflow as TxFIFO does not complete the transfer of
rest of the frame. As in all underflow conditions, a runt frame will be transmitted and
observed on the line. The status of such a frame will be marked with both Underflow and
Frame Flush events (TDES0RAM bits 13 and 1).
The MTL layer also stops accepting any data from the application (DMA) during the
Flush operation. It will generate and transfer Transmit Status Words to the application
for the number of frames that is flushed inside the MTL (including partial frames). Frames
that are completely flushed in the MTL will have the Frame Flush Status bit (TDES0
13RAM) set. The MTL completes the Flush operation when the application (DMA) accepts
all of the Status Words for the frames that were flushed, and then clears the Transmit
FIFO Flush control register bit. At this point, the MTL starts accepting new frames from
the application (DMA).
Transmit Status Word

At the end of transfer of the Ethernet frame to the ETH core and after the core completes
the transmission of the frame, the MTL outputs the transmit status to the application.The
detailed description of the Transmit Status is the same as for bits [23:0] of TDES0RAM,
given in Table 15-9.
If IEEE 1588 time stamping is enabled, the MTL returns specific frames 64-bit time
stamp, along with the ATIs transmit status.
Transmit Checksum Offload Engine

Communication protocols such as TCP and UDP implement checksum fields, which help
determine the integrity of data transmitted over a network. Because the most widespread

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
use of Ethernet is to encapsulate TCP and UDP over IP datagrams, the ETH has an
Checksum Offload Engine (COE) to support checksum calculation and insertion in the
transmit path, and error detection in the receive path. This section explains the operation
of the Checksum Offload Engine for transmitted frames.
Note: The checksum for TCP, UDP, or ICMP is calculated over a complete frame, then
inserted into its corresponding header field. Due to this requirement, this function
is enabled only when the Transmit FIFO is configured for Store-and-Forward
mode (that is, when the ETH0_OPERATION_MODE.TSF bit is set . ). If the core
is configured for Threshold (cut-through) mode, the Transmit COE is bypassed.
Note: You must make sure that the Transmit FIFO is deep enough to store a complete
frame before that frame is transferred to the ETH Core transmitter. The reason
being that when space is not available to accept the programmed burst length of
the data, then the MTL TxFIFO starts reading to avoid dead-lock. Once reading
starts, then checksum insertion engine fails and consequently all succeeding
frames may get corrupted due to improper recovery. Therefore, you must enable
the checksum insertion only in the frames that are less than the following number
of bytes in size (even in the store-and-forward mode):
FIFO Depth PBL 3 FIFO Locations
The ETH0_BUS_MODE.PBL is the programmed burst-length.
This checksum engine can be controlled for each frame by setting the CIC bits (Bits
28:27 of TDES1RAM, described in Transmit Descriptor 1).
Note: See IETF specifications RFC 791, RFC 793, RFC 768, RFC 792, RFC 2460, and
RFC 4443 for IPv4, TCP, UDP, ICMP, IPv6, and ICMPv6 packet header
specifications, respectively.
IP Header Checksum Engine
In IPv4 datagrams, the integrity of the header fields is indicated by the 16-bit Header
Checksum field (the eleventh and twelfth bytes of the IPv4 datagram). The COE detects
an IPv4 datagram when the Ethernet frames Type field has the value 0800H and the IP
datagrams Version field has the value 4H. The input frames checksum field is ignored
during calculation and replaced with the calculated value.
IPv6 headers do not have a checksum field; thus, the COE does not modify IPv6 header
fields.
The result of this IP header checksum calculation is indicated by the IP Header Error
status bit in the Transmit status (Bit 16 in Table 15-9). This status bit is set whenever the
values of the Ethernet Type field and the IP headers Version field are not consistent, or
when the Ethernet frame does not have enough data, as indicated by the IP header
Length field.
In other words, this bit is set when an IP header error is asserted under the following
circumstances:

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
For IPv4 datagrams

The received Ethernet type is 0800H, but the IP headers Version field does not equal
4H
The IPv4 Header Length field indicates a value less than 5H (20 bytes)
The total frame length is less than the value given in the IPv4 Header Length field
For IPv6 datagrams

The Ethernet type is 86DDH but the IP header Version field does not equal 6H
The frame ends before the IPv6 header (40 bytes) or extension header (as given in
the corresponding Header Length field in an extension header) is completely
received.
Even when the COE detects such an IP header error, it inserts an IPv4 header checksum
if the Ethernet Type field indicates an IPv4 payload.
TCP/UDP/ICMP Checksum Engine
The TCP/UDP/ICMP Checksum Engine processes the IPv4 or IPv6 header (including
extension headers) and determines whether the encapsulated payload is TCP, UDP, or
ICMP.
Note: For non-TCP, -UDP, or -ICMP/ICMPv6 payloads, this checksum engine is
bypassed and nothing further is modified in the frame.
Note: Fragmented IP frames (IPv4 or IPv6), IP frames with security features (such as an
authentication header or encapsulated security payload), and IPv6 frames with
routing headers are not processed by this engine, and therefore must be
bypassed. In other words, payload checksum insertion must not be enabled for
such frames.
The checksum is calculated for the TCP, UDP, or ICMP payload and inserted into its
corresponding field in the header. This engine can work in the following two modes:
In the first mode, the TCP, UDP, or ICMPv6 pseudo-header is not included in the
checksum calculation and is assumed to be present in the input frames Checksum
field. This engine includes the Checksum field in the checksum calculation, then
replaces the Checksum field with the final calculated checksum.
In the second mode, the engine ignores the Checksum field, includes the TCP, UDP,
or ICMPv6 pseudo-header data into the checksum calculation, and overwrites the
checksum field with the final calculated value.
Note: For ICMP-over-IPv4 packets, the Checksum field in the ICMP packet must always
be 16'h0000 in both modes, because pseudo-headers are not defined for such
packets. If it does not equal 16h0000, an incorrect checksum may be inserted into
the packet.
The result of this operation is indicated by the Payload Checksum Error status bit in the
Transmit Status vector (Bit 12 in Table 15-9). This engine sets the Payload Checksum

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Error status bit when it detects that the frame has been forwarded to the MAC
Transmitter engine in Store-and-Forward mode without the end-of-frame being written to
the FIFO, or when the packet ends before the number of bytes indicated by the Payload
Length field in the IP Header is received. When the packet is longer than the indicated
payload length, the COE ignores them as stuff bytes, and no error is reported. When this
engine detects the first type of error, it does not modify the TCP, UDP, or ICMP header.
For the second error type, it still inserts the calculated checksum into the corresponding
header field.
15.2.2.2 Receive Path

This module receives the frames given out by the ETH core and pushes them into the
Rx FIFO. The status (fill level) of this FIFO is indicated to the DMA once it crosses the
configured Receive threshold (ETH0_OPERATION_MODE.RTC bits). The MTL also
indicates the FIFO fill level so that the DMA can initiate pre-configured burst transfers
towards the Bus interface.
Receive Operation through Receive Status Word detail receive operations for the MTL
Layer.
Receive Operation
During an Rx operation, the MTL is slaved to the ETH. The general sequence of Receive
operation events is as follows:
1. When the ETH receives a frame, it pushes in data along with byte enables. The ETH
also indicates the SOF and EOF. The MTL accepts the data and pushes it into the
Rx FIFO. After the EOF is transferred, the ETH drives the status word, which is also
pushed into the same Rx FIFO by the MTL.
2. When IEEE 1588 time stamping is enabled and the 64-bit time stamp is available
along with the receive status, it is appended to the frame received from the ETH and
is pushed into the RxFIFO before the corresponding receive status word is written.
Thus, two additional locations per frame are taken for storing the time stamp in the
RxFIFO.
3. The MTL_RX engine takes the data out of the FIFO and sends it to the DMA. In the
default Cut-Through mode, when 64 bytes (configured with the
ETH0_OPERATION_MODE.RTC bits or a full packet of data are received into the
FIFO, the MTL_RX engine pops out the data and indicates its availability to the DMA.
Once the DMA initiates the transfer to the Bus interface, the MTL_RX engine
continues to transfer data from the FIFO until a complete packet has been
transferred. Upon completion of the EOF frame transfer, the MTL pops out the status
word and sends it to the DMA controller.
4. In Rx FIFO Store-and-Forward mode (configured by the Operation Mode.RSF bit), a
frame is read out only after being written completely into the Receive FIFO. In this
mode, all error frames are dropped (if the core is configured to do so) such that only

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
valid frames are read out and forwarded to the application. In Cut-Through mode,
some error frames are not dropped, because the error status is received at the end-
of-frame, by which time the start of that frame has already been read out of the FIFO.
Note: The time-stamp transfer takes two clock cycles and the lower 32-bit of the time-
stamp is given out first. The status also may be extended to two cycles when
Advanced Time-stamp feature is enabled.
Receive Operation Multiframe Handling

Since the status is available immediately following the data, the MTL is capable of storing
any number of frames into the FIFO, as long as it is not full.
Error Handling
If the MTL Rx FIFO is full before it receives the EOF data from the ETH, an overflow is
declared, the whole frame (including the status word) is dropped, and the overflow
counter in the DMA
(ETH0_MISSED_FRAME_AND_BUFFER_OVERFLOW_COUNTER Register) is
incremented. This is true even if the Forward Error Frame
(ETH0_OPERATION_MODE.FEF bit) is set. If the start address of such a frame has
already been transferred to the Read Controller, the rest of the frame is dropped and a
dummy EOF is written to the FIFO along with the status word. The status will indicate a
partial frame due to overflow. In such frames, the Frame Length field is invalid.
The MTL Rx Control logic can filter error and undersized frames, if enabled (using the
Operation Mode.FEF and Operation Mode.FUF bits). If the start address of such a frame
has already been transferred to the Rx FIFO Read Controller, that frame is not filtered.
The start address of the frame is transferred to the Read Controller after the frame
crosses the receive threshold (set by the Operation Mode.RTC bits).
If the MTL Receive FIFO is configured to operate in Store-and-Forward mode, all error
frames can be filtered and dropped.
Receive Status Word

At the end of the transfer of the Ethernet frame to the XMC4500 RAM, the MTL outputs
the receive status to the Application. The detailed description of the receive status is the
same as for Bits[31:0] of RDES0RAM, given in Table 15-4, except that Bits 31, 14, 9, and
8 are reserved and have a reset of 0 by default. When the status of a partial frame due
to overflow is given out, the Frame Length field in the status word is not valid.
Note: When Advanced Time Stamp feature is enabled, the status is composed of two
parts - normal (default [31:0]), and extended. The extended status[63:32] gives the
information about the received ethernet payload when it is carrying PTP packets
or TCP/UDP/ICMP over IP packets. These are transferred over two clock cycles.
The detailed description of the receive status is the same as described in RDES0

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
and RDES4 in Receive Descriptor, except that bits 31, 14, 9, and 8 of normal
status is reserved and have a reset value of 0B. When the status of a partial frame
due to overflow is given out, the Frame Length field in the status word is not valid.
15.2.3 DMA Controller

The DMA has independent Transmit and Receive engines, and a CSR space. The
Transmit Engine transfers data from system memory to the device port (MTL), while the
Receive Engine transfers data from the device port to system memory. The controller
utilizes descriptors to efficiently move data from source to destination with minimal CPU
intervention. The DMA is designed for packet-oriented data transfers such as frames in
Ethernet. The controller can be programmed to interrupt the CPU for situations such as
Frame Transmit and Receive transfer completion, and other normal/error conditions.
The DMA and the CPU driver communicate through two data structures:
Control and Status registers (CSR)
Descriptor lists and data buffers
Control and Status registers are described in detail in Chapter 15.6. Descriptors are
described in detail in DMA Descriptors.
The DMA descriptors are held in ram. To avoid confusion with the ETH registers the
DMA descriptors use the subscript RAM for example RDES0[0]RAM.
The DMA transfers data frames received by the core to the Receive Buffer in the
XMC4500 memory, and Transmit data frames from the Transmit Buffer in the XMC4500
memory. Descriptors that reside in the XMC4500 memory act as pointers to these
buffers.
There are two descriptor lists; one for reception, and one for transmission. The base
address of each list is written into DMA RECEIVE_DESCRIPTOR_LIST_ADDRESS
Register and TRANSMIT_DESCRIPTOR_LIST_ADDRESS Register, respectively. A
descriptor list is forward linked (either implicitly or explicitly). The last descriptor may
point back to the first entry to create a ring structure. Explicit chaining of descriptors is
accomplished by setting the second address chained in both Receive and Transmit
descriptors (RDES1[24]RAM and TDES1[24]RAM). The descriptor lists resides in the
XMC4500 physical memory address space. Each descriptor can point to a maximum of
two buffers. This enables two buffers to be used, physically addressed, rather than
contiguous buffers in memory.
A data buffer resides in the XMC4500 physical memory space, and consists of an entire
frame or part of a frame, but cannot exceed a single frame. Buffers contain only data,
buffer status is maintained in the descriptor. Data chaining refers to frames that span
multiple data buffers. However, a single descriptor cannot span multiple frames. The
DMA will skip to the next frame buffer when end-of-frame is detected. Data chaining can
be enabled or disabled.
The descriptor ring and chain structure is shown in Figure 15-2.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Ring Structure Chain Structure
Buffer 1 Buffer 1
Descriptor 0 Descriptor 0
Buffer 2
Buffer 1
Descriptor 1
Buffer 2
Buffer 1
Descriptor 1
Buffer 1
Descriptor 2
Buffer 2
Buffer 1
Descriptor 2
Buffer 1
Descriptor n
Buffer 2
Next Descriptor
Descriptor_Ring_and_Chain_Structure.vsd
Figure 15-2 Descriptor Ring and Chain Structure
15.2.3.1 Initialization
Initialization for the ETH is as follows.
1. Write to ETH0_BUS_MODE Register to set XMC4500 bus access parameters.
2. Write to ETH0_INTERRUPT_ENABLE Register to mask unnecessary interrupt
causes.
3. The software driver creates the Transmit and Receive descriptor lists. Then it writes
to both DMA ETH0_RECEIVE_DESCRIPTOR_LIST_ADDRESS Register and DMA
ETH0_TRANSMIT_DESCRIPTOR_LIST_ADDRESS Register, providing the DMA
with the starting address of each list.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
4. Write to ETH Registers ETH0_TRANSMIT_POLL_DEMAND,

ETH0_RECEIVE_POLL_DEMAND, and Receive Descriptor List Aaddress for
desired filtering options.
5. Write to ETH0_MAC_CONFIGURATION Register to configure and enable the
Transmit and Receive operating modes. The ETH0_MAC_CONFIGURATION.DM
bit is set based on the auto-negotiation result (read from the PHY).
6. Write to ETH0_OPERATION_MODE.ST and ETH0_OPERATION_MODE.SR bits
start transmission and reception.
7. The Transmit and Receive engines enter the Running state and attempt to acquire
descriptors from the respective descriptor lists. The Receive and Transmit engines
then begin processing Receive and Transmit operations. The Transmit and Receive
processes are independent of each other and can be started or stopped separately.
XMC4500 Bus Burst Access

The DMA will attempt to execute fixed-length Burst transfers on the Bus Master interface
if configured to do so ( ETH0_BUS_MODE.FB Register). The maximum Burst length is
indicated and limited by the PBL field ( Bus Mode.PBL Register ). The Receive and
Transmit descriptors are always accessed in the maximum possible (limited by PBL or
(16 * 8)/32) burst-size for the 16-bytes to be read.
The Transmit DMA will initiate a data transfer only when sufficient space to
accommodate the configured burst is available in MTL Transmit FIFO or the number of
bytes till the end of frame (when it is less than the configured burst-length). The DMA will
indicate the start address and the number of transfers required to the Bus Master
Interface. When the Bus Interface is configured for fixed-length burst, then it will transfer
data using the best combination of INCR4/8 and SINGLE transactions.
The Receive DMA will initiate a data transfer only when sufficient data to accommodate
the configured burst is available in MTL Receive FIFO or when the end of frame (when
it is less than the configured burst-length) is detected in the Receive FIFO. The DMA will
indicate the start address and the number of transfers required to the Bus Master
Interface. When the Bus Interface is configured for fixed-length burst, then it will transfer
data using the best combination of INCR4/8 and SINGLE transactions. If the end-of
frame is reached before the fixed-burst ends on the Bus interface, then dummy transfers
are performed in-order to complete the fixed-burst.
When the Bus interface is configured for address-aligned beats, both DMA engines
ensure that the first burst transfer the Bus initiates is less than or equal to the size of the
configured PBL. Thus, all subsequent beats start at an address that is aligned to the
configured PBL. The DMA can only align the address for beats up to size (for PBL > ),
because the Bus interface does not support more than INCR8/16.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
XMC4500 Data Buffer Alignment

The Transmit and Receive data buffers do not have any restrictions on start address
alignment. For example, the start address for the buffers can be aligned to any of the four
bytes. However, the DMA always initiates transfers with address aligned to the bus width
with dummy data for the byte lanes not required. This typically happens during the
transfer of the beginning or end of an Ethernet frame.
Example - Buffer Read

If the Transmit buffer address is 00000FF2H, and 15 bytes need to be transferred, then
the DMA will read five full words from address 00000FF0H, but when transferring data to
the MTL Transmit FIFO, the extra bytes (the first two bytes) will be dropped or ignored.
Similarly, the last 3 bytes of the last transfer will also be ignored. The DMA always
ensures it transfers a full 32-bit data to the MTL Transmit FIFO, unless it is the end-of-
frame.
Buffer Size Calculations

The DMA does not update the size fields in the Transmit and Receive descriptors. The
DMA updates only the status fields (RDESRAM and TDESRAM ) of the descriptors. The driver
has to perform the size calculations.
The transmit DMA transfers to the ETH the exact number of bytes (indicated by buffer
size field of TDES1RAM ) towards the ETH core. If a descriptor is marked as first (FS bit of
TDES1RAM is set), then the DMA marks the first transfer from the buffer as the start of
frame. If a descriptor is marked as last (LS bit of TDES1RAM ), then the DMA marks the
last transfer from that data buffer as the end-of frame to the MTL.
The Receive DMA transfers data to a buffer until the buffer is full or the end-of frame is
received from the MTL. If a descriptor is not marked as last (LS bit of RDES0RAM ), then
the descriptors corresponding buffer(s) are full and the amount of valid data in a buffer
is accurately indicated by its buffer size field minus the data buffer pointer offset when
the FS bit of that descriptor is set. The offset is zero when the data buffer pointer is
aligned to the data bus width. If a descriptor is marked as last, then the buffer may not
be full (as indicated by the buffer size in RDES1RAM ). To compute the amount of valid data
in this final buffer, the driver must read the frame length (FL bits of RDES0[29:16]RAM ) and
subtract the sum of the buffer sizes of the preceding buffers in this frame. The Receive
DMA always transfers the start of next frame with a new descriptor.
Note: Even when the start address of a receive buffer is not aligned to a word boundary,
the system should allocate a receive buffer aligned to a word boundary. For
example, if the system allocates a 1024-byte (1 KB) receive buffer starting from
address 1000H, the software can program the buffer start address in the Receive
descriptor to have a 1002H offset. The Receive DMA writes the frame to this buffer
with dummy data in the first two locations (1000H and 1001H). The actual frame is
written from location 1002H. Thus, the actual useful space in this buffer is 1022

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
bytes, even though the buffer size is programmed as 1024 bytes, due to the start
address offset.
DMA Arbiter
The arbiter inside the DMA module performs the arbitration between the Transmit and
Receive channel accesses to the Bus Master interface. Two types of arbitrations are
possible: round-robin, and fixed-priority.
When round-robin arbitration is selected (ETH0_BUS_MODE.DA bit is reset), the arbiter
allocates the data bus in the ratio set by the Bus Mode.PR Bits , when both Transmit and
Receive DMAs are requesting for access simultaneously. When the DA bit is set, the
Receive DMA always gets priority over the Transmit DMA for data access.
15.2.3.2 Transmission
The Transmit DMA engine has two operating modes, default and Opertate Second
Frame (OSF). Both these modes are described below.
TxDMA Operation: Default (Non-OSF) Mode

The Transmit DMA engine in default mode proceeds as follows:
1. The CPU sets up the transmit descriptor (TDES0RAM -TDES3RAM ) and sets the Own bit
(TDES0[31]RAM ) after setting up the corresponding data buffer(s) with Ethernet Frame
data.
2. Once the ETH0_OPERATION_MODE.ST bit is set, the DMA enters the Run state.
3. While in the Run state, the DMA polls the Transmit Descriptor list for frames requiring
transmission. After polling starts, it continues in either sequential descriptor ring order
or chained order. If the DMA detects a descriptor flagged as owned by the CPU, or if
an error condition occurs, transmission is suspended and both the Transmit Buffer
Unavailable (ETH0_STATUS.TU) and Normal Interrupt Summary (STATUS.NIS
Register) bits are set. The Transmit Engine proceeds to Step 8.
4. If the acquired descriptor is flagged as owned by DMA (TDES0[31]RAM = 1B), the DMA
decodes the Transmit Data Buffer address from the acquired descriptor.
5. The DMA fetches the Transmit data from the XMC4500 memory and transfers the
data to the MTL for transmission.
6. If an Ethernet frame is stored over data buffers in multiple descriptors, the DMA
closes the intermediate descriptor and fetches the next descriptor. Steps Step 2,
Step 3 and Step 4 are repeated until the end-of-Ethernet-frame data is transferred to
the MTL.
7. When frame transmission is complete, if IEEE 1588 time stamping was enabled for
the frame (as indicated in the transmit status) the time-stamp value obtained from
MTL is written to the transmit descriptor (TDES2RAM and TDES3RAM ) that contains the
end-of-frame buffer. The status information is then written to this transmit descriptor
(TDES0RAM ). Because the Own bit is cleared during this step, the CPU now owns this

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
descriptor. If time stamping was not enabled for this frame, the DMA does not alter
the contents of TDES2RAM and TDES3RAM .
8. Transmit Interrupt (ETH0_STATUS.TI ) is set after completing transmission of a
frame that has Interrupt on Completion (TDES1[31]RAM ) set in its Last Descriptor. The
DMA engine then returns to Step 2.
9. In the Suspend state, the DMA tries to re-acquire the descriptor (and thereby return
to Step 2) when it receives a Transmit Poll demand and the Underflow Interrupt
Status bit is cleared.
The TxDMA transmission flow in default mode is shown in Figure 15-3.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Star t TxD MA St art Stop TxDMA
(R e-) fetch next

descri ptor
Poll demand (AHB)

err or? Yes
No
TxDM A suspended Own

No
bit set?
Ye s
Tr ansfer data from

buffer( s)
(AHB)
Yes
err or?
No
Fram e xfer
No
com plete?
Yes
Close inter mediate

Wait for Tx status
descr iptor
Time stamp Wri te ti me stamp to

Yes
present? TDES2 and TDES3
No
W rite status wor d (AHB)

No Yes
to TD ES0 err or?
(AHB)
No Yes
err or?
T xD M A_ Operation _in_D efault_M ode.vsd
Figure 15-3 TxDMA Operation in Default Mode
TxDMA Operation: OSF Mode

While in the Run state, the transmit process can simultaneously acquire two frames
without closing the Status descriptor of the first if ETH0_OPERATION_MODE.OSF is
set. As the transmit process finishes transferring the first frame, it immediately polls the

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Transmit Descriptor list for the second frame. If the second frame is valid, the transmit
process transfers this frame before writing the first frames status information.
In OSF mode, the Run state Transmit DMA operates in the following sequence:
1. The DMA operates as described in Step 1Step 5 of the TxDMA (default mode).
2. Without closing the previous frames last descriptor, the DMA fetches the next
descriptor.
3. If the DMA owns the acquired descriptor, the DMA decodes the transmit buffer
address in this descriptor. If the DMA does not own the descriptor, the DMA goes into
Suspend mode and skips to Step 6.
4. The DMA fetches the Transmit frame from the XMC4500 memory and transfers the
frame to the MTL until the End-of-Frame data is transferred, closing the intermediate
descriptors if this frame is split across multiple descriptors.
5. The DMA waits for the previous frames frame transmission status and time stamp.
Once the status is available, the DMA writes the time stamp to TDES2RAM and
TDES3RAM , if such time stamp was captured (as indicated by a status bit). The DMA
then writes the status, with a cleared Own bit, to the corresponding TDES0RAM , thus
closing the descriptor. If time stamping was not enabled for the previous frame, the
DMA does not alter the contents of TDES2RAM and TDES3RAM .
6. If enabled, the Transmit interrupt is set, the DMA fetches the next descriptor, then
proceeds to Step 2 (when Status is normal). If the previous transmission status
shows an underflow error, the DMA goes into Suspend mode (Step 6).
7. In Suspend mode, if a pending status and time stamp are received from the MTL, the
DMA writes the time stamp (if enabled for the current frame) to TDES2RAM and
TDES3RAM , then writes the status to the corresponding TDES0RAM . It then sets relevant
interrupts and returns to Suspend mode.
8. The DMA can exit Suspend mode and enter the Run state (go to Step 1 or Step 2
depending on pending status) only after receiving a Transmit Poll demand (
ETH0_TRANSMIT_POLL_DEMAND Register).
Note: As the DMA fetches the next descriptor in advance before closing the current
descriptor, the descriptor chain should have more than 2 different descriptors for
correct and proper operation.
The basic flow is charted in Figure 15-4.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Start T xDMA S tart Stop TxDMA
( Re-)fetch next
descriptor
(AH B)
Po ll Ye s
er ror ?
d em an d
No
TxD MA suspended Own

No
bi t set?
Ye s
P re vio us fra me Transfer data from

sta tus a vailable
buffer(s)
Time stamp (AH B)

Yes
present? er ror ?
No No
Ye s
No Frame xfer Second

Write time stamp to compl ete? Yes
frame?
TDES2 & TDES3
for previous frame No
Yes
C lose interm ediate Wait for previous

descr iptor fram es Tx status
(AHB) Wr ite time stamp to

Ye s Tim e stam p TDES2 & TDES3
error? Ye s
present? for previous frame
No
No
W rite status word to W rite status word to (AH B)

No Ye s
prev. fram es TDES0 prev. fram es TDES0 error ?
(AHB) (AH B)
No error? No
er ror ?
Yes
Yes
Tx D M A_Operation _in _OSF_M ode.vs d
Figure 15-4 TxDMA Operation in OSF Mode
Transmit Frame Processing

The Transmit DMA expects that the data buffers contain complete Ethernet frames,
excluding preamble, pad bytes, and FCS fields. The DA, SA, and Type/Len fields must
contain valid data. If the Transmit Descriptor indicates that the MAC core must disable
CRC or PAD insertion, the buffer must have complete Ethernet frames (excluding
preamble), including the CRC bytes.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Frames can be data-chained and can span several buffers. Frames must be delimited
by the First Descriptor (TDES1[29]RAM ) and the Last Descriptor (TDES1[30]RAM ),
respectively.
As transmission starts, the First Descriptor must have (TDES1[29]RAM ) set. When this
occurs, frame data transfers from the XMC4500 RAM buffer to the MTL Transmit FIFO.
Concurrently, if the current frame has the Last Descriptor (TDES1[30]RAM ) clear, the
Transmit Process attempts to acquire the Next Descriptor. The Transmit Process
expects this descriptor to have TDES1[29]RAM clear. If TDES1[30]RAM is clear, it indicates
an intermediary buffer. If TDES1[30]RAM is set, it indicates the last buffer of the frame.
After the last buffer of the frame has been transmitted, the DMA writes back the final
status information to the Transmit Descriptor 0 (TDES0RAM ) word of the descriptor that
has the last segment set in Transmit Descriptor 1 (TDES1[30]RAM ). At this time, if Interrupt
on Completion (TDES1[31]RAM) was set, Transmit Interrupt (ETH0_STATUS.TI) is set, the
Next Descriptor is fetched, and the process repeats.
Actual frame transmission begins after the MTL Transmit FIFO has reached either a
programmable transmit threshold (ETH0_OPERATION_MODE.TTC ), or a full frame is
contained in the FIFO. There is also an option for Store and Forward Mode (Operation
Mode.TSF ). Descriptors are released (Own bit TDES0[31]RAM clears) when the DMA
finishes transferring the frame.
Transmit Polling Suspended

Transmit polling can be suspended by either of the following conditions:
The DMA detects a descriptor owned by the CPU (TDES0[31]RAM =0). To resume, the
driver must give descriptor ownership to the DMA and then issue a Poll Demand
command.
A frame transmission is aborted when a transmit error due to underflow is detected.
The appropriate Transmit Descriptor 0 (TDES0RAM ) bit is set.
If the second condition occurs, both Abnormal Interrupt Summary (STATUS.AIS) and
Transmit Underflow bits (STATUS.TU ) are set, and the information is written to Transmit
Descriptor 0, causing the suspension. If the DMA goes into SUSPEND state due to the
first condition, then both Normal Interrupt Summary (STATUS.NIS ) and Transmit Buffer
Unavailable (STATUS.TU ) are set.
In both cases, the position in the Transmit List is retained. The retained position is that
of the descriptor following the Last Descriptor closed by the DMA.
The driver must explicitly issue a Transmit Poll Demand command after rectifying the
suspension cause.
15.2.3.3 Reception
The Receive DMA engines reception sequence is depicted in Figure 15-5 and proceeds
as follows:

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
1. The CPU sets up Receive descriptors (RDES0RAM -RDES3RAM ) and sets the Own bit
(RDES0[31RAM ).
2. Once the ETH0_OPERATION_MODE.SR bit is set, the DMA enters the Run state.
While in the Run state, the DMA polls the Receive Descriptor list, attempting to
acquire free descriptors. If the fetched descriptor is not free (is owned by the CPU),
the DMA enters the Suspend state and jumps to Step 8.
3. The DMA decodes the receive data buffer address from the acquired descriptors.
4. Incoming frames are processed and placed in the acquired descriptors data buffers.
5. When the buffer is full or the frame transfer is complete, the Receive engine fetches
the next descriptor.
6. If the current frame transfer is complete, the DMA proceeds to Step 6. If the DMA
does not own the next fetched descriptor and the frame transfer is not complete (EOF
is not yet transferred), the DMA sets the Descriptor Error bit in the RDES0 (unless
flushing is disabled). The DMA closes the current descriptor (clears the Own bit) and
marks it as intermediate by clearing the Last Segment (LS) bit in the RDES0 value
(marks it as Last Descriptor if flushing is not disabled), then proceeds to Step 7. If the
DMA does own the next descriptor but the current frame transfer is not complete, the
DMA closes the current descriptor as intermediate and reverts to Step 3.
7. If IEEE 1588 time stamping is enabled, the DMA writes the time stamp (if available)
to the current descriptors RDES2RAM and RDES3RAM. It then takes the receive frames
status from the MTL and writes the status word to the current descriptors RDES0RAM,
with the Own bit cleared and the Last Segment bit set.
8. The Receive engine checks the latest descriptors Own bit. If the CPU owns the
descriptor (Own bit is 1'b0) the Receive Buffer Unavailable bit ( ETH0_STATUS.RU
) is set and the DMA Receive engine enters the Suspended state (Step 8). If the DMA
owns the descriptor, the engine returns to Step 3 and awaits the next frame.
9. Before the Receive engine enters the Suspend state, partial frames are flushed from
the Receive FIFO (You can control flushing using Operation Mode.DFF ).
10. The Receive DMA exits the Suspend state when a Receive Poll demand is given or
the start of next frame is available from the MTLs Receive FIFO. The engine
proceeds to Step 1 and refetches the next descriptor.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Start RxDMA Start Stop RxDMA
Poll demand/ (Re-)Fetch next

new frame available descriptor
(AHB)
RxDMA suspended Yes
error?
No
Yes
Frame transfer
No Own bit set?
complete?
No Yes
Frame data
Yes Flush disabled? No
available?
No Yes
Flush the
Write data to buffer(s) Wait for frame data
remaining frame
(AHB)
Yes
error?
No
Fetch next descriptor
(AHB)
Yes
error?
No
Flush Own bit set Frame transfer

No No
disabled? for next desc? complete?
No
Yes Yes Yes
Close RDES0 as Time stamp Write time stamp to

Set descriptor error Yes
intermediate descriptor present? RDES2 & RDES3
No
Close RDES0 as last (AHB)

No Yes
descriptor error?
(AHB)
No
error?
Yes
RxDMA.vsd
Figure 15-5 Receive DMA Operation

The DMA does not acknowledge accepting the status from the MTL until it has
completed the time stamp write-back and is ready to perform status write-back to the
descriptor.
If software has enabled time stamping through CSR, when a valid time stamp value is
not available for the frame (for example, because the receive FIFO was full before the
time stamp could be written to it), the DMA writes all-ones to RDES2RAM and RDES3RAM.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Otherwise (that is, if time stamping is not enabled), the RDES2RAM and RDES3RAM remain
unchanged.
Receive Descriptor Acquisition

The Receive Engine always attempts to acquire an extra descriptor in anticipation of an
incoming frame. Descriptor acquisition is attempted if any of the following conditions is
satisfied:
The receive Start/Stop bit (ETH0_OPERATION_MODE.SR) has been set
immediately after being placed in the Run state.
The data buffer of current descriptor is full before the frame ends for the current
transfer.
The controller has completed frame reception, but the current Receive Descriptor is
not yet closed.
The receive process has been suspended because of a CPU-owned buffer
(RDES0[31]RAM = 0) and a new frame is received.
A Receive poll demand has been issued.
Receive Frame Processing

The ETH transfers the received frames to the XMC4500 memory only when the frame
passes the address filter and frame size is greater than or equal to configurable
threshold bytes set for the Receive FIFO of the MTL, or when the complete frame is
written to the FIFO in Store-and-Forward mode.
If the frame fails the address filtering, it is dropped in the ETH block itself (unless Receive
All ETH0_MAC_FRAME_FILTER.RA is set). Frames that are shorter than 64 bytes,
because of collision or premature termination, can be purged from the MTL Receive
FIFO.
After 64 (configurable threshold) bytes have been received, the MTL block requests the
DMA block to begin transferring the frame data to the Receive Buffer pointed to by the
current descriptor. The DMA sets the First Descriptor bit (RDES0[9]RAM) after the DMA
CPU Interface becomes ready to receive a data transfer (if DMA is not fetching transmit
data from the XMC4500 RAM), to delimit the frame. The descriptors are released when
the Own (RDES[31]RAM) bit is reset to 1b0, either as the Data buffer fills up or as the last
segment of the frame is transferred to the Receive buffer. If the frame is contained in a
single descriptor, both Last Descriptor bit(RDES[8]RAM) and First Descriptor bit
(RDES[9]RAM) are set.
The DMA fetches the next descriptor, sets the Last Descriptor (RDES[8]RAM) bit, and
releases the RDES0RAM status bits in the previous frame descriptor. Then the DMA sets
Receive Interrupt flag (ETH0_STATUS.RI). The same process repeats unless the DMA
encounters a descriptor flagged as being owned by the CPU. If this occurs, the Receive
Process sets Receive Buffer Unavailable (STATUS.RU) and then enters the Suspend
state. The position in the receive list is retained.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Receive Process Suspended

If a new Receive frame arrives while the Receive Process is in Suspend state, the DMA
refetches the current descriptor in the XMC4500 memory. If the descriptor is now owned
by the DMA, the Receive Process re-enters the Run state and starts frame reception. If
the descriptor is still owned by the CPU, by default, the DMA discards the current frame
at the top of the MTL Rx FIFO and increments the missed frame counter. If more than
one frame is stored in the MTL Rx FIFO, the process repeats.
The discarding or flushing of the frame at the top of the MTL Rx FIFO can be avoided by
setting ETH0_OPERATION_MODE.DFF bit. In such conditions, the receive process
sets the Receive Buffer Unavailable status and returns to the Suspend state.
15.2.3.4 Interrupts
Interrupts can be generated as a result of various events. The ETH0_STATUS Register
contains all the bits that might cause an interrupt. The ETH0_INTERRUPT_ENABLE
Register contains an enable bit for each of the events that can cause an interrupt.
There are two groups of interrupts, Normal and Abnormal, as described in the STATUS
Register. Interrupts are cleared by writing 1B to the corresponding bit position. When all
the enabled interrupts within a group are cleared, the corresponding summary bit is
cleared. When both the summary bits are cleared, the interrupt signal to the NVIC is
deasserted. If the ETH core is the cause for assertion of the interrupt, then any of the
ELI, EMI, or EPI bits of DMA STATUS Register will be set high.
Note: The interrupt signal to the NVIC will be asserted due to any event in the DMA
STATUS register only if the corresponding interrupt enable bit is set in DMA
Interrupt Enable Register.
Interrupts are not queued and if the interrupt event occurs before the driver has
responded to it, no additional interrupts are generated. For example, Receive Interrupt
(STATUS.RI) indicates that one or more frames was transferred to the XMC4500 RAM
buffer. The driver must scan all descriptors, from the last recorded position to the first
one owned by the DMA.
An interrupt is generated only once for simultaneous, multiple events. The driver must
scan the STATUS Register for the cause of the interrupt. The interrupt is not generated
again unless a new interrupting event occurs, after the driver has cleared the appropriate
bit in the STATUS Register . For example, the controller generates a Receive interrupt
(DMA STATUS.RI) and the driver begins reading the STATUS Register. Next, Receive
Buffer Unavailable ( STATUS Register ) occurs. The driver clears the Receive interrupt.
Even then, the DMA interupt signal to the NVIC is not deasserted, due to the active or
pending Receive Buffer Unavailable interrupt.
An interrupt timer ( ETH0_RECEIVE_INTERRUPT_WATCHDOG_TIMER) is given for
flexible control of Receive Interrupt (STATUS.RI). When this Interrupt timer is
programmed with a non-zero value, it will get activated as soon as the RxDMA

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
completes a transfer of a received frame to system memory without asserting the

Receive Interrupt because it is not enabled in the corresponding Receive Descriptor
(RDES1[31]RAM in Table 7-3). When this timer runs out as per the programmed value, RI
bit is set and the interrupt is asserted if the corresponding
ETH0_INTERRUPT_ENABLE.RI bit is enabled. This timer gets disabled before it runs
out, when a frame is transferred to memory and the ETH0_STATUS.RI is set because it
is enabled for that descriptor.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.2.4 DMA Descriptors

This chapter describes the descriptor format used by the ETH DMA.The ETH DMA
descriptors are held in RAM. To avoid confusion with the ETH registers the DMA
descriptors use the subscript ]RAM for example RDES0[0]RAM.
15.2.4.1 Descriptor Formats

The DMA in the Ethernet subsystem transfers data based on a linked list of descriptors,
as explained in DMA Controller. The default descriptor formats (common for both
Receive and Transmit Descriptors) are shown in Figure 15-6, and field descriptions are
provided in Chapter to Chapter .
Note:
16. Changes to the default descriptor format when IEEE1588 time stamping is enabled
are described in Chapter Descriptor Format With IEEE 1588 Time Stamping
Enabled on Page 15-53.
Each descriptor contains two buffers, two byte-count buffers, and two address pointers,
which enable the adapter port to be compatible with various types of memory
management schemes.
The descriptor addresses must be aligned to 32 bit word boundaries .
Figure 15-6 show the descriptor format .
31 23 15 7 0
O
W Status [30:0]
DES0
N
DES1 Control Bits [9:0] Byte Count Buffer2 [10:0] Byte Count Buffer1[10:0]
DES2 Buffer1 Address[31:0]
Buffer2 Address [31:0] /

DES3
Next Descriptor Address [31:0]
Figure 15-6 Rx/Tx Descriptors
Receive Descriptor
The ETH Subsystem requires at least two descriptors when receiving a frame. The
Receive state machine of the DMA (in the ETH Subsystem) always attempts to acquire
an extra descriptor in anticipation of an incoming frame. (The size of the incoming frame

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
is unknown). Before the RxDMA closes a descriptor, it will attempt to acquire the next
descriptor even if no frames are received.
In a single descriptor (receive) system, the subsystem will generate a descriptor error if
the receive buffer is unable to accommodate the incoming frame and the next descriptor
is not owned by the DMA. Thus, the CPU is forced to increase either its descriptor pool
or the buffer size. Otherwise, the subsystem starts dropping all incoming frames.
31 0
O
RDES0 W Status
N
Control Byte Count Byte Count

RDES1 Bits Buffer 2 Buffer 1
RDES2 Buffer 1 Address
RDES3 Buffer 2 Address / Next Descriptor Address
Receive_Descriptor_ Format_in Little_Endian _Mode_32_bit.vsd
Figure 15-7 Receive Descriptor Format

Receive Descriptor 0 (RDES0RAM)
RDES0RAM contains the received frame status, the frame length, and the descriptor
ownership information.The format of the descriptor is given in tables Table 15-4 through
Table 15-12.
Table 15-4 Receive Descriptor 0

Bit Description
31 OWN: Own Bit
When set, this bit indicates that the descriptor is owned by the DMA of the ETH
Subsystem. When this bit is reset, this bit indicates that the descriptor is owned
by the CPU. The DMA clears this bit either when it completes the frame reception
or when the buffers that are associated with this descriptor are full.
30 AFM: Destination Address Filter Fail
When set, this bit indicates a frame that failed in the DA Filter in the ETH Core.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-4 Receive Descriptor 0 (contd)

Bit Description
29:1 FL: Frame Length
6 These bits indicate the byte length of the received frame that was transferred to
XMC4500 memory (including CRC). This field is valid when Last Descriptor
(RDES0[8]RAM is set and either the Descriptor Error (RDES0[14]RAM) or Overflow
Error bits are are reset. The frame length also includes the two bytes appended
to the Ethernet frame when IP checksum calculation (Type 1) is enabled and the
received frame is not a MAC control frame.
This field is valid when Last Descriptor (RDES0[8]RAM) is set. When the Last
Descriptor and Error Summary bits are not set, this field indicates the
accumulated number of bytes that have been transferred for the current frame.
15 ES: Error Summary
Indicates the logical OR of the following bits:
RDES0[0]RAM: Payload Checksum Error
RDES0[1]RAM: CRC Error
RDES0[3]RAM: Receive Error
RDES0[4]RAM: Watchdog Timeout
RDES0[6]RAM: Late Collision
RDES0[7]RAM: IPC Checksum (Type 2) / Giant Frame
RDES0[11]RAM: Overflow Error
RDES0[14]RAM: Descriptor Error
This field is valid only when the Last Descriptor (RDES0[8]RAM) is set.
14 DE: Descriptor Error
When set, this bit indicates a frame truncation caused by a frame that does not
fit within the current descriptor buffers, and that the DMA does not own the Next
Descriptor. The frame is truncated. This field is valid only when the Last
Descriptor (RDES0[8]RAM) is set.
13 SAF: Source Address Filter Fail
When set, this bit indicates that the SA field of frame failed the SA Filter in the
ETH Core.
12 LE: Length Error
When set, this bit indicates that the actual length of the frame received and that
the Length/ Type field does not match. This bit is valid only when the Frame Type
(RDES0[5]RAM) bit is reset. Length error status is not valid when CRC error is
present.
11 OE: Overflow Error
When set, this bit indicates that the received frame was damaged due to buffer
overflow in MTL.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

Bit Description
10 VLAN: VLAN Tag
When set, this bit indicates that the frame pointed to by this descriptor is a VLAN
frame tagged by the ETH Core.
9 FS: First Descriptor
When set, this bit indicates that this descriptor contains the first buffer of the
frame. If the size of the first buffer is 0, the second buffer contains the beginning
of the frame. If the size of the second buffer is also 0, the next Descriptor contains
the beginning of the frame.
8 LS: Last Descriptor
When set, this bit indicates that the buffers pointed to by this descriptor are the
last buffers of the frame
7 IPC Checksum Error/Giant Frame
This bit indicates an error in the IPv4 or IPv6 header. This error can be due to
inconsistent Ethernet Type field and IP header Version field values, a header
checksum mismatch in IPv4, or an Ethernet frame lacking the expected number
of IP header bytes. Refer to Table 15-5 for more details.
6 LC: Late Collision
When set, this bit indicates that a late collision has occurred while receiving the
frame in Half-Duplex mode.
5 FT: Frame Type
When set, this bit indicates that the Receive Frame is an Ethernet-type frame (the
LT field is greater than or equal to 0600H). When this bit is reset, it indicates that
the received frame is an IEEE802.3 frame. This bit is not valid for Runt frames
less than 14 bytes. Refer to Table 15-5 for more details.
4 RWT: Receive Watchdog Timeout
When set, this bit indicates that the Receive Watchdog Timer has expired while
receiving the current frame and the current frame is truncated after the Watchdog
Timeout.
3 RE: Receive Error
When set, this bit indicates that the MII Receive Error signal is asserted while
Carrier Sense signal is asserted during frame reception. This error also includes
carrier extension error in MII and Half-duplex mode. Error can be of less/no
extension, or error (rxd 0f) during extension.
2 DE: Dribble Bit Error
When set, this bit indicates that the received frame has a non-integer multiple of
bytes (odd nibbles). This bit is valid only in MII Mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

Bit Description
1 CE: CRC Error
When set, this bit indicates that a Cyclic Redundancy Check (CRC) Error
occurred on the received frame. This field is valid only when the Last Descriptor
(RDES0[8]RAM) is set.
0 Payload Checksum Error
When set, indicates the TCP, UDP, or ICMP checksum the core calculated does
not match the received encapsulated TCP, UDP, or ICMP segments Checksum
field. This bit is also set when the received number of payload bytes does not
match the value indicated in the Length field of the encapsulated IPv4 or IPv6
datagram in the received Ethernet frame. Refer to Table 15-5 for more details.
The permutations of bits 5, 7, and 0 reflect the conditions discussed in Table 15-5.
Table 15-5 Receive Descriptor 0 When COE (Type 2) Is Enabled

Bit 5: Bit 7: Bit 0: Frame Status
Frame IPC Payload
Type Checks Checks
um um
Error Error
0 0 0 IEEE 802.3 Type frame (Length field value is less than
0600H)
1 0 0 IPv4/IPv6 Type frame, no checksum error detected
1 0 1 IPv4/IPv6 Type frame with a payload checksum error
(as described for PCE) detected
1 1 0 IPv4/IPv6 Type frame with an IP header checksum
error (as described for IPC CE) detected
1 1 1 IPv4/IPv6 Type frame with both IP header and payload
checksum errors detected
0 0 1 IPv4/IPv6 Type frame with no IP header checksum
error and the payload check bypassed, due to an
unsupported payload
0 1 1 A Type frame that is neither IPv4 or IPv6 (the
Checksum Offload engine bypasses checksum
completely.)
0 1 0 Reserved

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RDES1RAM contains the buffer sizes and other bits that control the descriptor chain/ring.
Note: See Buffer Size Calculations for further detail on calculating buffer sizes.

Bit Description
31 Disable Interrupt on Completion
When set, this bit will prevent the setting of the ETH0_STATUS.RI bit of the
Status Register for the received frame that ends in the buffer pointed to by this
descriptor. This, in turn, will disable the assertion of the interrupt to the CPU due
to RI for that frame.
30:26 Reserved
25 RER: Receive End of Ring
When set, this bit indicates that the descriptor list reached its final descriptor.
The DMA returns to the base address of the list, creating a Descriptor Ring.
24 RCH: Second Address Chained
When set, this bit indicates that the second address in the descriptor is the Next
Descriptor address rather than the second buffer address. When RDES1[24]RAM
is set, RBS2RAM (RDES1[21-11]RAM) is a dont care value. RDES1[25]RAM takes
precedence over RDES1[24]RAM.
23:22 Reserved
21:11 RBS2: Receive Buffer 2 Size
These bits indicate the second data buffer size in bytes. The buffer size must
be a multiple of 4 , even if the value of RDES3RAM (buffer2 address pointer) is not
aligned to bus width. In the case where the buffer size is not a multiple of 4, the
resulting behavior is undefined. This field is not valid if RDES1[24]RAM is set.
10:0 RBS1: Receive Buffer 1 Size
Indicates the first data buffer size in bytes. The buffer size must be a multiple of
4, even if the value of RDES2RAM (buffer1 address pointer) is not aligned. In the
case where the buffer size is not a multiple of 4/8/16, the resulting behavior is
undefined. If this field is 0, the DMA ignores this buffer and uses Buffer 2 or next
descriptor depending on the value of RCH (Bit 24).

RDES2RAM contains the address pointer to the first data buffer in the descriptor.
Note: See XMC4500 Data Buffer Alignment for further detail on buffer address
alignment.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-7 Receive Descriptor 2 (Default Operation)

Bit Description
31:0 Buffer 1 Address Pointer
These bits indicate the physical address of Buffer 1. There are no limitations on
the buffer address alignment except for the following condition: The DMA uses
the configured value for its address generation when the RDES2 value is used to
store the start of frame. Note that the DMA performs a write operation with the
RDES2[3/2/1:0]RAM bits as 0 during the transfer of the start of frame but the frame
data is shifted as per the actual Buffer address pointer. The DMA ignores
RDES2[3/2/1:0]RAM if the address pointer is to a buffer where the middle or last part
of the frame is stored.

RDES3RAM contains the address pointer either to the second data buffer in the descriptor
or to the next descriptor.

Bit Description
31:0 Buffer 2 Address Pointer (Next Descriptor Address)
These bits indicate the physical address of Buffer 2 when a descriptor ring
structure is used. If the Second Address Chained (RDES1[24]RAM) bit is set, this
address contains the pointer to the physical memory where the Next Descriptor
is present.
If RDES1[24]RAM is set, the buffer (Next Descriptor) address pointer must be bus
width-aligned (RDES3[3, 2, or 1:0]RAM = 0, corresponding to a bus width of 128, 64,
or 32. LSBs are ignored internally.) However, when RDES1[24]RAM is reset, there
are no limitations on the RDES3RAM value, except for the following condition: The
DMA uses the configured value for its buffer address generation when the RDES3
value is used to store the start of frame. The DMA ignores RDES3[3, 2, or 1:0]RAM
if the address pointer is to a buffer where the middle or last part of the frame is
stored.
Transmit Descriptor
The descriptor addresses must be aligned to the 32 bit word boundary . Figure 15-8
shows the transmit descriptor format.
Each descriptor is provided with two buffers, two byte-count buffers, and two address
pointers, which enable the adapter port to be compatible with various types of memory-
management schemes.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
31 0
O
TDES0 W Status
N
Control Byte Count Byte Count

TDES1 Bits Buffer 2 Buffer 1
TDES2 Buffer 1 Address
TDES3 Buffer 2 Address / Next Descriptor Address
Transmit_Descriptor _Format_Little_Endian _32_bit.vsd
Figure 15-8 Transmit Descriptor Format

Transmit Descriptor 0 (TDES0RAM)
TDES0RAM contains the transmitted frame status and the descriptor ownership
information.
Table 15-9 Transmit Descriptor 0

Bit Description
31 OWN: Own Bit
When set, this bit indicates that the descriptor is owned by the DMA. When this
bit is reset, this bit indicates that the descriptor is owned by the CPU. The DMA
clears this bit either when it completes the frame transmission or when the
buffers allocated in the descriptor are empty. The ownership bit of the First
Descriptor of the frame should be set after all subsequent descriptors belonging
to the same frame have been set. This avoids a possible race condition between
fetching a descriptor and the driver setting an ownership bit.
30:18 Reserved

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-9 Transmit Descriptor 0 (contd)

Bit Description
17 TTSS: Tx Time Stamp Status
This status bit indicates that a time stamp has been captured for the
corresponding transmit frame. When this bit is set, TDES2RAM and TDES3RAM have
time stamp values that were captured for the transmit frame. This field is valid
only when the Last Segment control bit (TDES1[30]RAM) in a descriptor is set. This
bit is valid only when IEEE1588 time stamping feature is enabled; otherwise, it
is reserved.
16 IHE: IP Header Error
When set, this bit indicates that the Checksum Offload engine detected an IP
header error and consequently did not modify the transmitted frame for any
checksum insertion.
15 ES: Error Summary
Indicates the logical OR of the following bits:
TDES0[14]RAM: Jabber Timeout
TDES0[13]RAM: Frame Flush
TDES0[11]RAM: Loss of Carrier
TDES0[10]RAM: No Carrier
TDES0[9]RAM: Late Collision
TDES0[8]RAM: Excessive Collision
TDES0[2]RAM: Excessive Deferral
TDES0[1]RAM: Underflow Error
14 JT: Jabber Timeout
When set, this bit indicates the ETH transmitter has experienced a jabber time-
out. This bit is only set when the ETH configuration registers JD bit is not set.
13 FF: Frame Flushed
When set, this bit indicates that the DMA/MTL flushed the frame due to a SW
flush command given by the CPU.
12 PCE: Payload Checksum Error
This bit, when set, indicates that the Checksum Offload engine had a failure and
did not insert any checksum into the encapsulated TCP, UDP, or ICMP payload.
This failure can be either due to insufficient bytes, as indicated by the IP
Headers Payload Length field, or the MTL starting to forward the frame to the
MAC transmitter in Store-and-Forward mode without the checksum having been
calculated yet. This second error condition only occurs when the Transmit FIFO
depth is less than the length of the Ethernet frame being transmitted: to avoid
deadlock, the MTL starts forwarding the frame when the FIFO is full, even in
Store-and-Forward mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

Bit Description
11 LC: Loss of Carrier
When set, this bit indicates that Loss of Carrier occurred during frame
transmission . This is valid only for the frames transmitted without collision and
when the ETH operates in Half-Duplex Mode.
10 NC: No Carrier
When set, this bit indicates that the carrier sense signal form the PHY was not
asserted during transmission.
9 LC: Late Collision
When set, this bit indicates that frame transmission was aborted due to a
collision occurring after the collision window (64 byte times including Preamble
in MII Mode ). Not valid if Underflow Error is set.
8 EC: Excessive Collision
When set, this bit indicates that the transmission was aborted after 16
successive collisions while attempting to transmit the current frame. If the DR
(Disable Retry) bit in the ETH Configuration Register is set, this bit is set after
the first collision and the transmission of the frame is aborted.
7 VF: VLAN Frame
When set, this bit indicates that the transmitted frame was a VLAN-type frame.
6:3 CC: Collision Count
This 4-bit counter value indicates the number of collisions occurring before the
frame was transmitted. The count is not valid when the Excessive Collisions bit
(TDES0[8]RAM) is set.
2 ED: Excessive Deferral
When set, this bit indicates that the transmission has ended because of
excessive deferral of over 24,288 bit times (155,680 bits times in 1000 Mbit/s
mode, or in Jumbo Frame enabled mode) if the Deferral Check (DC) bit is set
high in the ETH Control Register.
1 UF: Underflow Error
When set, this bit indicates that the ETH aborted the frame because data arrived
late from the XMC4500 memory. Underflow Error indicates that the DMA
encountered an empty Transmit Buffer while transmitting the frame. The
transmission process enters the suspended state and sets both STATUS.TU
and STATUS.TI.
0 DB: Deferred Bit
When set, this bit indicates that the ETH defers before transmission because of
the presence of carrier. This bit is valid only in Half-Duplex mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TDES1RAM contains the buffer sizes and other bits which control the descriptor chain/ring
and the frame being transferred.
Note: See Buffer Size Calculations for further detail on calculating buffer sizes.

Bit Description
31 IC: Interrupt on Completion
When set, this bit sets Transmit Interrupt, STATUS.TI bit after the present frame
has been transmitted.
30 LS: Last Segment
When set, this bit indicates that the buffer contains the last segment of the
frame.
29 FS: First Segment
When set, this bit indicates that the buffer contains the first segment of a frame.
28:27 CIC: Checksum Insertion Control
These bits control the insertion of checksums in Ethernet frames that
encapsulate TCP, UDP, or ICMP over IPv4 or IPv6 as described below.
00: Do nothing. Checksum Engine is bypassed
01: Insert IPv4 header checksum. Use this value to insert IPv4 header
checksum when the frame encapsulates an IPv4 datagram.
10: Insert TCP/UDP/ICMP checksum. The checksum is calculated over the
TCP, UDP, or ICMP segment only and the TCP, UDP, or ICMP pseudo-
header checksum is assumed to be present in the corresponding input
frames Checksum field. An IPv4 header checksum is also inserted if the
encapsulated datagram conforms to IPv4.
11: Insert a TCP/UDP/ICMP checksum that is fully calculated in this engine.
In other words, the TCP, UDP, or ICMP pseudo-header is included in the
checksum calculation, and the input frames corresponding Checksum field
has an all-zero value. An IPv4 Header checksum is also inserted if the
encapsulated datagram conforms to IPv4.
The Checksum engine detects whether the TCP, UDP, or ICMP segment is
encapsulated in IPv4 or IPv6 and processes its data accordingly.
26 DC: Disable CRC
When set, the ETH does not append the Cyclic Redundancy Check (CRC) to
the end of the transmitted frame. This is valid only when the first segment
(TDES1[29]RAM) bit is set.
25 TER: Transmit End of Ring
When set, this bit indicates that the descriptor list reached its final descriptor.
The returns to the base address of the list, creating a descriptor ring.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

Bit Description
24 TCH: Second Address Chained
When set, this bit indicates that the second address in the descriptor is the Next
Descriptor address rather than the second buffer address. When TDES1[24]RAM
is set, TBS2 (TDES1[2111]RAM) are dont care values. TDES1[25]RAM takes
precedence over TDES1[24]RAM.
23 DP: Disable Padding
When set, the ETH does not automatically add padding to a frame shorter than
64 bytes. When this bit is reset, the DMA automatically adds padding and CRC
to a frame shorter than 64 bytes and the CRC field is added despite the state of
the DC (TDES1[26]RAM) bit. This is valid only when the first segment
(TDES1[29]RAM) is set.
22 TTSE: Transmit Time Stamp Enable
When set, this bit enables IEEE1588 hardware time stamping for the transmit
frame referenced by the descriptor. This field is valid only when the First
Segment control bit (TDES1[29]RAM) is set.
21:11 TBS2: Transmit Buffer 2 Size
These bits indicate the Second Data Buffer in bytes. This field is not valid if
TDES1[24]RAM is set.
10:0 TBS1: Transmit Buffer 1 Size
These bits indicate the First Data Buffer byte size. If this field is 0, the DMA
ignores this buffer and uses Buffer 2 or next descriptor depending on the value
of TCH (Bit 24).
Transmit Descriptor 2 (TDES2)

TDES2 contains the address pointer to the first buffer of the descriptor.

Bit Description
31:0 Buffer 1 Address Pointer
These bits indicate the physical address of Buffer 1. There is no limitation on the
buffer address alignment. See XMC4500 Data Buffer Alignment for further
detail on buffer address alignment.

TDES3RAM contains the address pointer either to the second buffer of the descriptor or the
next descriptor.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

Bit Description
31:0 Buffer 2 Address Pointer (Next Descriptor Address)
Indicates the physical address of Buffer 2 when a descriptor ring structure is
used. If the Second Address Chained (TDES1[24]RAM) bit is set, this address
contains the pointer to the physical memory where the Next Descriptor is
present. The buffer address pointer must be aligned to the bus width only when
TDES1[24]RAM is set. (LSBs are ignored internally.)
Descriptor Format With IEEE 1588 Time Stamping Enabled

The default descriptor format (as described in Receive Descriptor on Page 15-55
and Transmit Descriptor on Page 15-47), and field descriptions remain unchanged
when created by software (Own bit is set in DES0RAM). However, if the software has
enabled IEEE 1588 functionality, the DES2RAM and DES3RAM descriptor fields (see
Figure 15-9) take on a different meaning when the DMA closes the descriptor (own bit
in DES0RAM is cleared).
The DMA updates the DES2RAM and DES3RAM with the time stamp value before clearing
the Own bit in DES0RAM.
DES2RAM is updated with the lower 32 time stamp bits (the Sub-Second field, called TSL
in subsequent sections) and DES3RAM is updated with the upper 32 time stamp bits (the
Seconds field, called TSH in subsequent sections).
31 1
DES0
DES1
DES2 Tim e Stamp Low[31:0]
DES3 Time Stamp H igh[31:0]
R eceive_D escriptor_ F ields.vsd
Figure 15-9 Receive Descriptor Fields When DMA Clears the Own Bit

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
The following sections describe the details specific to receive and transmit descriptors in
this mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Receive Descriptor
Receive Time Stamp

The tables below describe the fields that have different meaning for RDES2RAM and
RDES3RAM when the receive descriptor is closed and time stamping is enabled.
Note: When software disables the time stamping feature (the
ETH0_TIMESTAMP_CONTROL.TSENA bit is low), the DMA does not update the
descriptors RDES2RAM/RDES3RAM fields before closing the RDES0RAM.
Table 15-13 Receive Descriptor Fields (RDES2)

Bit Description
31:0 RTSL: Receive Frame Time Stamp Low
The DMA updates this field with the least significant 32 bits of the time stamp
captured for the corresponding receive frame. The DMA updates this field only
for the last descriptor of the receive frame indicated by Last Descriptor status bit
(RDES0[8]RAM). When this field and the RTSH field in RDES3RAM show an all-
ones value, the time stamp must be treated as corrupt.
Table 15-14 Receive Descriptor Fields (RDES3)

Bit Description
31:0 RTSH: Receive Frame Time Stamp High
The DMA updates this field with the most significant 32 bits of the time stamp
captured for the corresponding receive frame. The DMA updates this field only
for the last descriptor of the receive frame indicated by Last Descriptor status bit
(RDES0[8]RAM).
When this field and RDES2RAMs RTSL field show all-ones values, the time
stamp must be treated as corrupt.
Transmit Descriptor
In addition to the changes described in Descriptor Format With IEEE 1588 Time
Stamping Enabled on Page 15-53, the Transmit descriptor has additional control and
status bits (TTSE and TTSS, respectively) for time stamping, as shown in Figure 15-10.
Software sets the TTSE bit (when the Own bit is set), instructing the core to generate a
time stamp for the corresponding Ethernet frame being transmitted. The DMA sets the
TTSS bit if the time stamp has been updated in the TDES2RAM and TDES3RAM fields when
the descriptor is closed (Own bit is cleared).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Transmit_Descriptor_Fields_Normal_Format.vsd
Figure 15-10 Transmit Descriptor Fields
Transmit Time Stamp Control and Status Fields

The value of this field ishall be preserved by the DMA at the time of closing the
descriptor.
Updates to Table 15-8 and Table 15-9 are described below.
Table 15-15 Transmit Time Stamp Status Normal Descriptor Format Case
(TDES0RAM)
Bit Description
17 TTSS: Transmit Time Stamp Status
This field is a status bit indicating that a time stamp was captured for the
corresponding transmit frame. When this bit is set, both TDES2RAM and
TDES3RAM have a time stamp value that was captured for the transmit frame.
This field is valid only when the Last Segment control bit (TDES1[30]RAM in the
descriptor) is set.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-16 Transmit Time Stamp Control Normal Descriptor Format Case
(TDES1RAM)
Bit Description
22 TTSE: Transmit Time Stamp Enable
When set, this field enables IEEE1588 hardware time stamping for the transmit
frame described by the descriptor.
This field is valid only when the First Segment control bit (TDES1[29]RAM in the
descriptor) is set.
Transmit Time Stamp Field

The transmit descriptor format and field descriptions remain unchanged when they are
created by software (when the Own bit is set). However, when the DMA closes the last
descriptor and IEEE 1588 functionality is enabled (the Own bit is cleared), the TDES2RAM
and TDES3 descriptor fields are updated with the time stamp, if taken, for that frame.
Table 15-17 and Table 15-18 describe the fields that have a different meaning when the
descriptor is closed.
Table 15-17 Transmit Descriptor Fields (TDES2RAM)

Bit Description
31:0 TTSL: Transmit Frame Time Stamp Low
This field is updated by DMA with the least significant 32 bits of the time stamp
captured for the corresponding transmit frame. This field has the time stamp
only if the Last Segment control bit (LS) in the descriptor is set.
Table 15-18 Transmit Descriptor Fields (TDES3)

Bit Description
31:0 TTSH: Transmit Frame Time Stamp High
This field is updated by DMA with the most significant 32 bits of the time stamp
captured for the corresponding transmit frame. This field has the time stamp
only if the Last Segment control bit (LS) in the descriptor is set.
15.2.5 MAC Management Counters

The MMC module maintains a set of registers for gathering statistics on the received and
transmitted frames. These include a control register for controlling the behavior of the
registers, two 32-bit registers containing interrupts generated (receive and transmit), and
two 32-bit registers containing masks for the Interrupt register (receive and transmit).
These registers are accessible from the Application through the MAC Control Interface

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
(MCI). Each register is 32 bits wide. Non-32-bit accesses are allowed as long as the
address is word-aligned.
The organization of these registers is shown in Table 15-27. The MMCs are accessed
using transactions, in the same way the CSR address space is accessed. The following
sections in the chapter describe the various counters and list the address for each of the
statistics counters. This address will be used for Read/Write accesses to the desired
transmit/receive counter.
The Receive MMC counters are updated for frames that are passed by the Address Filter
(AFM) block. Statistics of frames that are dropped by the AFM module are not updated
unless they are runt frames of less than 6 bytes (DA bytes are not received fully).
The MMC module gathers statistics on encapsulated IPv4, IPv6, TCP, UDP, or ICMP
payloads in received Ethernet frames. The address map of the corresponding registers,
0200H02FCH, is given in Table 15-27.
15.2.6 Power Management Block

This section describes the power management (PMT) mechanisms supported by the
ETH. PMT supports the reception of network (remote) wake-up frames and Magic
Packet frames. PMT does not perform the clock gate function, but generates interrupts
for wake-up frames and Magic Packets received by the ETH. The PMT block sits on the
receiver path of the ETH and is enabled with remote wake-up frame enable and Magic
Packet enable. These enables are in the PMT_CONTROL_STATUS register and are
programmed by the Application.
PMT registers are accessed in the same manner as with ETH-CSR registers. Refer to
Figure 15-27 for mapping information.
When the power down mode is enabled in the PMT, then all received frames are dropped
by the core and they are not forwarded to the application. The core comes out of the
power down mode only when either a Magic Packet or a Remote Wake-up frame is
received and the corresponding detection is enabled.
15.2.6.1 PMT Block Description
PMT Control and Status Register

The PMT CSR program the request wake-up events and monitor the wake-up
events.See ETH0_PMT_CONTROL_STATUS register for a full description
Remote Wake-Up Frame Filter Register

The Remote Wake up Frame Filter consists of eight words which are programed via the
ETH0_REMOTE_WAKE_UP_FRAME_FILTER Register. The eight words of the

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Remote Wake Up Frame Filter must be written sequentially to the

REMOTE_WAKE_UP_FRAME_FILTER Register. The structure of the Remote Wake
Up Frame Filter is described below. The Remote Wake Up Frame Filter values must be
loaded sequentially starting with wkupfmfilter0 through to wkupfmfilter7. The
REMOTE_WAKE_UP_FRAME_FILTER Register is read in the same way.
Note: The internal counter to access the appropriate wkupfmfilter_reg is incremented
when lane3 is accessed by the CPU. This should be kept in mind if you are
accessing these registers in byte or half-word mode.
wkupfmfilter_reg0 Filter 0 Byte Mask
Filter 3 Filter 2 Filter 1 Filter 0

wkupfmfilter_reg4 RSVD RSVD RSVD RSVD
Command Command Command Command
wkupfmfilter_reg5 Filter 3 Offset Filter 2 Offset Filter 1 Offset Filter 0 Offset
wkupfmfilter_reg6 Filter 1 CRC - 16 Filter 0 CRC - 16
wkupfmfilter_reg7 Filter 3 CRC - 16 Filter 2 CRC - 16
Wake-_Up_Frame_Filter_Register .vsd
Figure 15-11 Wake-Up Frame Filter Register
Filter i Byte Mask

This register defines which bytes of the frame are examined by filter i (0, 1, 2, and 3) in
order to determine whether or not the frame is a wake-up frame. The Most Significant Bit
(thirty-first bit) must be zero. Bit j [30:0] is the Byte Mask. If bit j (byte number) of the Byte
Mask is set, then Filter i Offset + j of the incoming frame is processed by the CRC block;
otherwise Filter i Offset + j is ignored.
Filter i Command
This 4-bit command controls the filter i operation. Bit 3 specifies the address type,
defining the patterns destination address type. When the bit is set, the pattern applies
to only multicast frames; when the bit is reset, the pattern applies only to unicast frame.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Bit 2 and Bit 1 are reserved. Bit 0 is the enable for filter i; if Bit 0 is not set, filter i is
disabled.
Filter i Offset
This register defines the offset (within the frame) from which the frames are examined
by filter i. This 8-bit pattern-offset is the offset for the filter i first byte to examined. The
minimum allowed is 12, which refers to the 13th byte of the frame (offset value 0 refers
to the first byte of the frame).
Filter i CRC-16
This register contains the CRC_16 value calculated from the pattern, as well as the byte
mask programmed to the wake-up filter register block.
15.2.6.2 Remote Wake-Up Frame Detection

When the ETH is in sleep mode and the remote wake-up bit is enabled in PMT Control
and Status register , normal operation is resumed after receiving a remote wake-up
frame. The Application writes all eight wake-up filter registers, by performing a sequential
Write to ETH0_REMOTE_WAKE_UP_FRAME_FILTER Register. The Application
enables remote wake-up by setting ETH0_PMT_CONTROL_STATUS.PWRDWN.
PMT supports four programmable filters that allow support of different receive frame
patterns. If the incoming frame passes the address filtering of Filter Command, and if
Filter CRC-16 matches the incoming examined pattern, then the wake-up frame is
received.
Filter_offset (minimum value 12, which refers to the 13th byte of the frame) determines
the offset from which the frame is to be examined. Filter Byte Mask determines which
bytes of the frame must be examined. The thirty-first bit of Byte Mask must be set to zero.
The remote wake-up CRC block determines the CRC value that is compared with Filter
CRC-16. The wake-up frame is checked only for length error, FCS error, dribble bit error,
MII error, collision, and to ensure that it is not a runt frame. Even if the wake-up frame is
more than 512 bytes long, if the frame has a valid CRC value, it is considered valid.
Wake-up frame detection is updated in the PMT_Control _Status register for every
remote Wake-up frame received. A PMT interrupt to the Application triggers a Read to
the PMT_CONTROL_STATUS register to determine reception of a wake-up frame.
15.2.6.3 Magic Packet Detection

The Magic Packet frame is based on a method that uses Advanced Micro Devices
Magic Packet technology to power up the sleeping device on the network. The ETH
receives a specific packet of information, called a Magic Packet, addressed to the node
on the network.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Only Magic Packets that are addressed to the device or a broadcast address will be
checked to determine whether they meet the wake-up requirements. Magic Packets that
pass the address filtering (unicast or broadcast) will be checked to determine whether
they meet the remote Wake-on-LAN data format of 6 bytes of all ones followed by a ETH
Address appearing 16 times.
The application enables Magic Packet wake-up by writing a 1 to Bit 1 of the
ETH0_PMT_CONTROL_STATUS register. The PMT block constantly monitors each
frame addressed to the node for a specific Magic Packet pattern. Each frame received
is checked for a FFFF FFFF FFFFH pattern following the destination and source address
field. The PMT block then checks the frame for 16 repetitions of the ETH address without
any breaks or interruptions. In case of a break in the 16 repetitions of the address, the
FFFF FFFF FFFFH pattern is scanned for again in the incoming frame. The 16 repetitions
can be anywhere in the frame, but must be preceded by the synchronization stream
(FFFF FFFF FFFFH). The device will also accept a multicast frame, as long as the 16
duplications of the ETH address are detected.
If the MAC address of a node is 0011 2233 4455H, then the ETH scans for the data
sequence:
Destination Address Source Address .. FF FF FF FF FF FF
00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33
44 55
00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33
44 55
00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33
44 55
00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33
44 55
CRC
Magic Packet detection is updated in the PMT_CONTROL_STATUS register for Magic
Packet received. A PMT interrupt to the Application triggers a read to the PMT CSR to
determine whether a Magic Packet frame has been received.
15.2.6.4 System Considerations During Power-Down

The ETH neither gates nor stops clocks when Power-Down mode is enabled. Power
saving by clock gating must be done outside the core by the application. The receive
data path must is clocked during Power-Down mode, because it is involved in magic
packet/wake-on-LAN frame detection. However, the transmit path and the application
path clocks can be gated off during Power-Down mode.
The power management interrupt signal is asserted when a valid wake-up frame is
received. This signal is generated in the receive clock domain.
The recommended power-down and wake-up sequence is as follows.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
1. Disable the Transmit DMA (if applicable) and wait for any previous frame
transmissions to complete. These transmissions can be detected when Transmit
Interrupt, ETH0_STATUS.TI is received.
2. Disable the MAC transmitter and MAC receiver by clearing the appropriate bits in the
ETH0_MAC_CONFIGURATION register.
3. Wait until the Receive DMA empties all the frames from the Rx FIFO (a software timer
may be required).
4. Enable Power-Down mode by appropriately configuring the PMT registers.
5. Enable the MAC Receiver and enter Power-Down mode.
6. Gate the application and transmit clock inputs to the core (and other relevant clocks
in the system) to reduce power and enter Sleep mode.
7. On receiving a valid wake-up frame, the ETH asserts the power management
interrupt signal and exits Power-Down mode.
8. On receiving the interrupt, the system must enable the application and transmit clock
inputs to the core.
9. Read the ETH0_PMT_CONTROL_STATUS register to clear the interrupt, then
enable the other modules in the system and resume normal operation.
15.2.7 PHY Interconnect

The ETH supports two external interconnects to external PHY devices. The ETH
peripheral may be connected to the external PHY by either a Media Independent
Interface (MII) or by a Reduced Media Independent Interface (RMII). Additionally a
Station Management Interface (SMI) provides a two wire serial interface between the
external PHY and the ETH. The SMI allows the ETH to program the internal PHY
configuration registers. The SMI supports connection of up to 32 external PHY devices.
15.2.7.1 PHY Interconnect selection

Selection of the external interconnect configuration between MII or RMII is made by the
ETH0_CON.INFSEL register. This must be done while the ETH peripheral is held in
reset. Once the PHY interconnect has been configured it may not be changed without
placing the ETH back into reset.
15.2.8 Station Management Interface

The Station Management Agent (SMA) module allows the Application to access any
PHY registers through a 2-wire Station Management interface (SMI). The PHY
interconnect supports accessing up to 32 PHYs.
The application can select one of the 32 PHYs and one of the 32 registers within any
PHY and send control data or receive status information. Only one register in one PHY
can be addressed at any given time. For more details on the communication from the
Application to the PHYs, refer to the Reconciliation Sublayer and Media Independent
Interface Specifications section of the IEEE 802.3z specification, 1000BASE Ethernet.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
The application sends the control data to the PHY and receives status information from
the PHY through the SMA module, as shown in Figure 15-12.
MCI CSR Module SMA Module MIM
SMA_Interface_Block.vsd
Figure 15-12 SMA Interface Block
15.2.8.1 Station Management Functions

The ETH initiates the Management Write/Read operation. The MDC clock is a divided
clock from the ETH MAC clock . The divide factor depends on the clock range setting in
the MII Address register. Clock range is set as follows:
Selection ETH MAC Clock MDC Clock

0000 60-100 MHz ETH Clock/42
0001 100-150 MHz ETH Clock/62
0010 20-35 MHz ETH Clock/16
0011 35-60 MHz ETH Clock/26
0100 150-250 MHz ETH Clock/102
0101 250-300 MHz ETH Clock/124
0110, 0111 Reserved
The frame structure on the MDIO line is shown below.
PHY REG
IDLE PREAMBLE START OPCODE TA DATA IDLE
ADDR ADDR
Frame_MDIO.vsd
IDLE The mdio line is Tri-state; there is no clock on mdc

PREAMBLE 32 continuous bits of value 1
START Start-of-frame is 01B
OPCODE 10B for Read and b01B for Write
PHY ADDR 5-bit address select for one of 32 PHYs
REG ADDR Register address in the selected PHY

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TA Turnaround is Z0B for Read and 10B for Write

DATA Any 16-bit value. In a Write operation, the ETH drives
mdio; in a Read
operation, PHY drives it.
15.2.8.2 Station Management Write Operation

When the user sets the MII Write and Busy bits (ETH0_GMII_ADDRESS.MW and
GMII_ADDRESS.MB) the ETH CSR module transfers the PHY address, the register
address in PHY, and the write data to the SMA to initiate a Write operation into the PHY
registers. At this point, the SMA module starts a Write operation on the MII Management
Interface using the Management Frame Format specified in the MII specifications
(Section 22.2.4.5 of IEEE Standard). The application should not change the
GMII_ADDRESS register contents or the GMII_DATA register while the transaction is
ongoing. Write operations to the GMII_ADDRESS register or the ETH0_GMII_DATA
Register during this period are ignored (the Busy bit is high), and the transaction is
completed without any error on the MCI interface.
After the Write operation has completed, the SMA indicates this to the CSR which then
resets the Busy bit. The SMA module divides the CSR (Application) clock with the clock
divider programmed (CR bits of MII Address Register) to generate the MDC clock for this
interface. The ETH drives the MDIO line for the complete duration of the frame. The
frame format for the Write operation is as follows:
IDLE PREAMBLE START OPCODE PHY REG TA DATA IDLE

ADDR ADDR
Z 1111...11 01 01 AAAAA RRRRR 10 DDD . . . Z
.DDD
Management _Write_Operation .vsd
Figure 15-13 Management Write Operation

Figure 15-13 is a reference for the Write operation.
15.2.8.3 Station Management Read Operation

When the user sets the MII Busy bit (ETH0_GMII_ADDRESS.MB) with the MII Write bit
(GMII_ADDRESS.WB) as 0, the ETH CSR module transfers the PHY address and the
register address in PHY to the SMA to initiate a Read operation in the PHY registers. At

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
this point, the SMA module starts a Read operation on the MII Management Interface
using the Management Frame Format specified in the MII specifications (Section
22.2.4.5 of IEEE Standard). The application should not change the GMII_ADDRESS
register contents or the GMII_DATA register while the transaction is ongoing. Write
operations to the GMII_ADDRESS register or ETH0_GMII_DATA Register during this
period are ignored (the Busy bit is high) and the transaction completed without any error
on the MCI interface.
After the Read operation has completed, the SMA indicates this to the CSR, which then
resets the Busy bit and updates the GMII_DATA register with the data read from the
PHY. The SMA module divides the CSR (Application) clock with the clock divider
programmed (GMII_ADDRESS.CR bits) to generate the MDC clock for this interface.
The ETH drives the MDIO line for the complete duration of the frame except during the
Data fields when the PHY is driving the MDIO line. The frame format for the Read
operation is as follows:
IDLE PREAMBLE START OPCODE PHY REG TA DATA IDLE

ADDR ADDR
Z 1111...11 01 10 AAAAA RRRRR Z0 DDD . . . Z
.DDD
Figure 15-14 is a reference for the read operation.
Management _Read_Operation .vsd
Figure 15-14 Management Read Operation
15.2.9 Media Independent interface

The Media Independent Interface (MII) provides an interconnect to external PHY devices
standerdised by IEEE 802.3u. The MII interconnect consists of 16 pins for data and
control. The MII interconnect provides two seperate nibble wide busses for transmit and
receive each with a dedicated clock running at 2.5Mhz for 10Mbit/s and 25Mhz for
100Mbit/s speeds. Transmit and receive control signals consist of a TX Enable (TX_EN)
that allows the ETH to present data to the PHY and a Receive Data Valid (RX_DV) that
allows the PHY to present data to the ETH. A Receive Error (RX_ER) signal is also
provided that allows the PHY signal the ETH when an error was detected somewhere in

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
the current received packet. The two remaining control signals are MII collision detect
(MII_COL) which is asserted by the PHY when an arbitration collision occurs and MII
carrier sense (MII_CRS) which is asserted by the PHY when either Transmit or Recive
are not idle.
MII_TXD[3:0]
MII_RXD[3:0]
MII_TX_EN
MII_RX_DV
ETHMAC MII MII_RX_ERR
CLK_MII_TX
CLK_MII_RX
MIII_CRS
MII_COL
eth_MII.vsd
Figure 15-15 Media Independent Interface
15.2.10 Reduced Media Independent Interface

The Reduced Media Independent Interface (RMII) specification reduces the pin count
between Ethernet PHYs and Switch ASICs . According to the IEEE 802.3u standard, an
MII contains 16 pins for data and control. In devices incorporating multiple MAC or PHY
interfaces (such as switches), the number of pins adds significant cost with increase in
port count. The RMII specification addresses this problem by reducing the pin count to
7 for each port a 62.5% decrease in pin count.
The RMII module is instantiated between the ETH and the PHY. This helps
translation of the MACs MII into the RMII. The RMII block has the following
characteristics:
Supports 10 Mbit/s and 100 Mbit/s operating rates.
Two clock references are sourced externally, providing independent, 2-bit wide
transmit and receive paths.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.2.10.1 RMII Block Diagram

Figure 15-16 shows the position of the RMII block relative to the ETH and RMII PHY.
The RMII block is placed in front of the ETH to translate the MII signals to RMII signals.
GMAC Block MII RMII Block RMII RMII PHY Block
Management _Read_Operation .vsd
Figure 15-16 RMII Block Diagram
15.2.10.2 RMII Block Overview

The following list describes the RMIIs hardware components, which are shown in
Figure 15-17. Each of these blocks is briefly described in the following sections.
MII-RMII Transmit (MRT) Block: This block translates all MII transmit signals to RMII
transmit signals.
MII-RMII Receive (MRR) Block: This block translates all RMII receive signals to MII
receive signals.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
rst_clk_rmii_n
rst_clk_rx_n MRT
Block rmii_txen (phy_txen_o)
clk_rx_i
rmii_txd (phy_txd[1:0])
clk_rmii_i
mii_rxd
mii_txen
mii_rxdv
mii_txd
mii_crs
mac_speed_i
MRR mii_col
rmii_rxd_i (phy_rxd_i[1:0]) Block
rmii_rxdv (phy_rxdv_i)
RMII_Pinout .vsd
Figure 15-17 RMII Pinout

Note: The MAC Configuration.FES bit configures the RMII to operate at 10 Mbit/s or
100 Mbit/s.
15.2.10.3 Transmit Bit Ordering

Each nibble from the MII must be transmitted on the RMII a di-bit at a time with the order
of di-bit transmission shown in Figure 15-18. The lower order bits (D1 and D0) are
transmitted first followed by higher order bits (D2 and D3).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
rmii_txd[1:0]
LSB MSB
D0 D1 Di-Bit Stream
LSB D0
D1
mii_txd[3:0]
D2
MSB D3
Nibble Stream Transmission_Bit_Ordering.vsd
Figure 15-18 Transmission Bit Ordering
15.2.10.4 RMII Transmit Timing Diagrams

Figure 15-19 through Figure 15-22 show MII-to-RMII transaction timing.
Figure 15-19 shows the start of MII transmission and the following RMII transmission in
100 Mbit/s mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
clk_rx_i
mii_txen
mii_txd[3:0]
clk_rmii_i
rmii_txen (phy_txen_o)
rmii_txd_o (phy_txd_o)[1:0]
Start_MII_and_RMII_Transmission_in_100_Mbs.vsd
Figure 15-19 Start of MII and RMII Transmission in 100 Mbit/s Mode
Figure 15-20 shows the end of frame transmission for MII and RMII in 100 Mbit/s mode.
clk_rx_i
mii_txen
mii_txd[3:0]
clk_rmii_i
xen (phy_txen_o)
(phy_txd_o)[1:0]
End_MII_RMII_Transmission_100 Mbs. vsd
Figure 15-20 End of MII and RMII Transmission in 100 Mbit/s Mode
Figure 15-21 shows the start of MII transmission and the following RMII transmission in
10 Mbit/s mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
clk_rx_i
mii_txen
mii_txd[3:0]
clk_rmii_i
mii_txen (phy_txen_o)
xd_o (phy_txd_o)[1:0]
Start_ MI_RMII_Transmission_10 Mbs.vsd
Figure 15-21 Start of MII and RMII Transmission in 10 Mbit/s Mode

Figure 15-22 shows the end of MII transmission and RMII transmission in 10 Mbit/s
mode.
clk_rx_i
mii_txen
mii_txd[3:0]
clk_rmii_i
rmii_txen (phy_txen_o)
_txd_o (phy_txd_o)[1:0]
End_ MI_RMII_Transmission_10 Mbs.vsd
Figure 15-22 End of MII and RMII Transmission in 10 Mbit/s Mode
Receive Bit Ordering

Each nibble is transmitted to the MII from the di-bit received from the RMII in the nibble
transmission order shown in Figure 15-23. The lower order bits (D0 and D1) are
received first, followed by the higher order bits (D2 and D3).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
rmii_rxd[1:0]
LSB MSB
D0 D1 Di-Bit Stream
LSB D0
D1
mii_rxd[3:0]
D2
MSB D3
Receive_Bit_Ordering.vsd
Nibble Stream
Figure 15-23 Receive Bit Ordering
15.2.11 IEEE 1588-2002 Overview

The IEEE 1588 standard defines a protocol enabling precise synchronization of clocks
in measurement and control systems implemented with technologies such as network
communication, local computing, and distributed objects. The protocol applies to
systems communicating by local area networks supporting multicast messaging,
including (but not limited to) Ethernet. This protocol enables heterogeneous systems that
include clocks of varying inherent precision, resolution, and stability to synchronize. The
protocol supports system-wide synchronization accuracy in the sub-microsecond range
with minimal network and local clock computing resources.
The messaged-based protocol, named Precision Time Protocol (PTP), is transported
over UDP/IP. The system or network is classified into Master and Slave nodes for
distributing the timing/clock information. The protocols technique for synchronizing a
slave node to a master node by exchanging PTP messages is depicted in Figure 15-24.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Networked _Time_Synchronization .vsd
Figure 15-24 Networked Time Synchronization

1. The master broadcasts PTP Sync messages to all its nodes. The Sync message
contains the masters reference time information. The time at which this message
leaves the masters system is t1 and must, for Ethernet ports, be captured at the MII.
2. A slave receives the Sync message and also captures the exact time, t2, using its
timing reference.
3. The master then sends the slave a Follow_up message, which contains t1
information for later use.
4. The slave sends the master a Delay_Req message, noting the exact time, t3, at
which this frame leaves the MII.
5. The master receives this message, capturing the exact time, t4, at which it enters its
system.
6. The master sends the t4 information to the slave in the Delay_Resp message.
7. The slave uses the four values of t1, t2, t3, and t4 to synchronize its local timing
reference to the masters timing reference.
Most of the protocol implementation occurs in the software, above the UDP layer. As
described above, however, hardware support is required to capture the exact time when
specific PTP packets enter or leave the Ethernet port at the MII. This timing information
must be captured and returned to the software for the proper implementation of PTP with
high accuracy.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.2.11.1 Reference Timing Source

To get a snapshot of the time, the core requires a reference time in 64-bit format (split
into two 32-bit channels, with the upper 32-bits providing time in seconds, and the lower
32-bits indicating time in nanoseconds) as defined in the IEEE 1588 specification.
Internal Reference Time

This takes only the reference clock input and uses it to generate the Reference time (also
called the System Time) internally and use it to capture time stamps. The generation,
update, and modification of the System Time are described in System Time Register
Module.
15.2.11.2 Transmit Path Functions

When a frames SFD is output on the MII, a time stamp is captured. Frames for which
capturing a time stamp is required are controllable on a per-frame basis. In other words,
each transmit frame can be marked to indicate whether or not a time stamp must be
captured for that frame.
No snooping or processing of the transmitted frames is performed to identify PTP
frames. Framewise control is exercised through control bits in the transmit descriptor (as
described in Descriptor Format With IEEE 1588 Time Stamping Enabled).
Captured time stamps are returned to the application in a manner similar to that in which
status is provided for frames. time stamp is returned to software inside the corresponding
transmit descriptor, thus connecting the time stamp automatically to the specific PTP
frame. The 64-bit time stamp information is written back to the TDES2RAMand
TDES3RAMfields, with TDES2 holding the time stamps 32 least significant bits, except as
described in Transmit Time Stamp Field.
Note: When the alternate (enhanced) descriptor is selected, the 64-bit time-stamp is
written in TDES6RAMand TDES7RAM, respectively
15.2.11.3 Receive Path Functions

When the IEEE 1588 time-stamping feature is selected and enabled, the Ethernet MAC
captures the time stamp of all frames received on the MII. No snooping or processing of
the received frames is performed to identify PTP frames in the default mode (Advanced
Time Stamp feature is not selected).
The core returns the time-stamp to the software in the corresponding receive descriptor.
The 64-bit time stamp information is written back to the RDES2 and RDES3 fields, with
RDES2 holding the time stamps 32 least significant bits, except as mentioned in
Receive Time Stamp The time stamp is only written to the receive descriptor for which
the Last Descriptor status field has been set to 1 (the EOF marker). When the time stamp
is not available (for example, due to an RxFIFO overflow) an all-ones pattern is written

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
to the descriptors (RDES2 and RDES3), indicating that time stamp is not correct. If the
software uses a control register bit to disable time stamping, the DMA does not alter
RDES2 or RDES3.
Note: When the alternate (enhanced) descriptor is selected, the 64-bit time-stamp is
written in RDES6 and RDES7, respectively. RDES0[7] will indicate whether the
time-stamp is updated in RDES6/7 or not.
15.2.11.4 Time Stamp Error Margin

According to the IEEE 1588 specifications, the time stamp must be captured at the SFD
of transmitted and received frames at the MII interface. Since the reference timing
source is different from the MII clocks, a small error margin is introduced, due to the
transfer of information across asynchronous clock domains.
In the transmit path, the captured and reported time stamp has a maximum error margin
of 2 PTP clocks. In other words, the captured time stamp has the value of the reference
time source given within 2 clocks after the SFD has been transmitted on the MII.
Similarly, on the receive path, the error margin is 3 MII clocks, plus up to 2 PTP clocks.
You can ignore the error margin due to the 3 MII clocks by assuming that this constant
delay is present in the system (or link) before the SFD data reaches the ETHs MII
interface.
15.2.11.5 Frequency Range of Reference Timing Clock

Because asynchronous logic is in place for time stamp information transfers across clock
domain, a minimum delay is required between two consecutive time stamp captures.
This delay is 3 clock cycles of both the MII and PTP clocks. If the gap is shorter, the ETH
does not take a time stamp snapshot for the second frame.
The maximum PTP clock frequency is limited by the maximum resolution of the
reference time and the timing constraints achievable for logic operating on the PTP
clock. Another factor to consider is that the resolution, or granularity, of the reference
time source determines the accuracy of the synchronization. Hence, a higher PTP clock
frequency gives better system performance. The minimum PTP clock frequency
depends on the time required between two consecutive SFD bytes. Because the MII
clock frequency is fixed by IEEE specification, the minimum PTP clock frequency
required for proper operation depends on the cores operating mode and operating
speed.
For example, in 100 Mbit/s full-duplex operation, the minimum gap between two SFDs is
160 MII clocks (128 clocks for a 64-byte frame + 24 clocks of min IFG + 8 clocks of
preamble).
In the example, (3 PTP) + (3 MII) 160 MII; thus, the minimum PTP clock
frequency is about 0.5 MHz ((160 3) 40 ns 3 = 2.093 ns period)

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.2.11.6 Advanced Time Stamp Feature Support

In addition to the basic features for time stamp mentioned in Receive Time Stamp, the
advanced time stamp option has the following features.
Support for the IEEE 1588-2008 (Version 2) timestamp format.
Option to take snapshot for all frames or for PTP type frames.
Option for taking snapshot for event messages only.
Option to take the snapshot based on the clock type (ordinary, boundary, end-to-end
and peer-to-peer)
Option to select the node to be a Master or Slave for ordinary and boundary clock.
Identification of PTP message type, version, and PTP payload sent directly over
Ethernet given as status.
Option to measure time in digital or binary format.
15.2.11.7 Peer-to-Peer PTP (Pdelay) Transparent Clock (P2P TC) Message

Support
The IEEE 1588-2008 version supports Pdelay message in addition to SYNC, Delay
Request, Follow-up and Delay Response messages. Figure 15-25 shows the method to
calculate the propagation delay in clocks supporting peer-to-peer path correction.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Propagation _Delay_Calculation_in_Clocks_Supporting _Peer _to_Pee _ Path _Correction.vsd
Figure 15-25 Propagation Delay Calculation in Clocks Supporting Peer-to-Peer

Path Correction
The link delay measurement starts with port-1 issuing a Pdelay_Req message and
generating a timestamp, for the Pdelay_Req message. Port-2 receives the
Pdelay_Req message and generates a timestamp, t2, for this message. Port-2 returns
a Pdelay_Resp message and generates a timestamp, t3, for this message. To minimize
errors due to any frequency offset between the two ports, Port-2 returns the
Pdelay_Resp message as quickly as possible after the receipt of the Pdelay_Req
message.
Port-2 either:
Returns the difference between the timestamps t2 and t3 in the Pdelay_Resp
message,
Returns the difference between the timestamps t2 and t3 in a
Pdelay_Resp_Follow_Up message, or
Returns the timestamps t2 and t3 in the Pdelay_Resp and Pdelay_Resp_Follow_Up
messages respectively.
Port-1 generates a timestamp, t4, upon receiving the Pdelay_Resp message. Port-1
then uses these four timestamps to compute the mean link delay.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.2.11.8 Clock Types

The type of clock nodes supported in IEEE 1588-2008 is described in this section. The
corresponding support provided by the advanced time stamp feature for each of the
clock type is also mentioned.
1. Ordinary clock support: In this type the clock can be a grandmaster or a slave clock.
This clock has a single PTP state.
Table 15-19 shows the messages for which time-stamp snapshot is taken on the
receive side for Master and Slave nodes.
The ordinary clock in the domain supports a single copy of the protocol and has a
single PTP state and will typically be a single physical port. In typical industrial
automation applications, an ordinary clock is associated with an application device
such as sensors and actuators. In telecom applications, the ordinary clock may be
associated with a timing demarcation device.
Typically for ordinary clock, you will need to take snapshot for only one type of PTP
messages. For e.g. you will require supporting either version 1 or 2 PTP messages,
not both.
The following features are supported.
a) Sends and receives PTP messages. The time stamp snapshot can be controlled
as described by the ETH0_TIMESTAMP_CONTROL Register.
b) Maintains the data sets (e.g., time stamp values).
2. Boundary clock support: This type of clock is similar to the ordinary clock except for
the following.
Hence the features of ordinary clock holds good for the boundary clock also.
The boundary clock typically has several physical ports communicating with the
network. The messages related to synchronization, master-slave hierarchy and
signaling terminate in the protocol engine of the boundary clock and are not
forwarded. The PTP message type status given by the core (refer to Receive Path
Functions) will help you to quickly identify the type of message and take appropriate
action.
a) The clock data sets are common to all ports of the boundary clock
b) The local clock is common to all ports of the boundary clock.
3. End to end transparent clock support: The end-to-end transparent clock forwards all
messages like normal bridge, router or repeater. The resident time needs to be
computed to update the correctionField. Hence snapshot needs to be taken for the
messages mentioned in Table 15-20.
In the end-to-end transparent clock, the residence times are accumulated in a special
field (correctionField) of the PTP event (SYNC) message or the associated Follow-up
(FOLLOW_UP) Message. Hence it is important to take a snapshot for these
messages alone. This can be quickly done by setting the control bit (TSEVNTENA),
which enables snapshot to be taken for event messages and also selecting the type
of clock in the ETH0_TIMESTAMP_CONTROL Register.
The residence time is also corrected for Delay_Req messages (but snapshot of the

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
timestamp is not required). The message type statuses provided helps you to quickly
identity the message and update the correctionField.
The message type status provided will also help in taking appropriate action
depending on the type of PTP message received.
4. Peer to peer transparent clock support: In this type of clock the computation of the
link delay is based on an exchange of Pdelay_Req, Pdelay_Resp and
Pdelay_Resp_Follow_Up messages with the link peer. Hence support for taking
snapshot for the event messages related to Pdelay is added. Table 15-21.
The transparent clock corrects only the SYNC and Follow-up message. As discussed
earlier this can be achieved using the message status provided.
The type of clock to be implemented will be configurable through
ETH0_TIMESTAMP_CONTROL register. To ensure that the snapshot is taken only
for the messages indicated in the table for the corresponding clock type, the
ETH0_TIMESTAMP_CONTROL.TSEVNTENA bit has to be set.
Table 15-19 PTP Messages for which Snapshot is Taken on Receive Side for
Ordinary Clock
Master Slave
Delay_Req SYNC
Table 15-20 PTP Messages for which Snapshot is Taken for Transparent Clock
Implementation
SYNC
FOLLOW_UP
Table 15-21 PTP Messages for which Snapshot is Taken for Peer-to-Peer
Transparent Clock Implementation
SYNC
Pdelay_Req
Pdelay_Resp
15.2.11.9 PTP Processing and Control

The common message header for PTP messages is shown below. This format is taken
from IEEE standard 1588-2008 (Revision of IEEE Std. 1588-2002).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-22 Message Format Defined in IEEE 1588-2008

BITS OCTETS OFFSET
transportSpecific messageType 1 0
Reserved versionPTP 1 1
messageLength 2 2
domainNumber 1 4
Reserved 1 5
flagField 2 6
correctionField 8 8
Reserved 4 16
sourcePortIdentity 10 20
sequenceId 2 30
controlField1) 1 32
logMessageInterva 1 33
1) controlField is used in version 1. For version 2, messageType field will be used for detecting different
message types.
There are some fields in the PTP frame that are used to detect the type and control the
snapshot to be taken. This is different for PTP frames sent directly over Ethernet, PTP
frames sent over UDP / IPv4 and PTP frames that are sent over UDP / IPv6. The
following sections provide information on the fields that are used to control taking the
snapshot.
PTP Frame Over IPv4

Table 15-23 gives the details of the fields that will be matched to control snapshot for
PTP packets over UDP over IPv4 for IEEE 1588 version 1 and 2. Note that the octet
positions for tagged frames will be offset by 4. This is based on Appendix-D of the IEEE
1588-2008 standard and the message format defined in Table 15-22.
Table 15-23 IPv4-UDP PTP Frame Fields Required for Control and Status
Field Matched Octet Matched Value Description
Position
MAC Frame type 12, 13 0800H IPv4 datagram
IP Version and 14 45H IP version is IPv4
Header Length
Layer-4 protocol 23 11H UDP

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-23 IPv4-UDP PTP Frame Fields Required for Control and Status (contd)
Position
IP Multicast address 30, 31, 32, E0H,00H, Multicast IPv4 addresses
(IEEE 1588 version 33 01H,81H allowed.
1) (or 82H or 83H or 224.0.1.129
84H) 224.0.1.130
224.0.1.131
224.0.1.132
IP Multicast address 30, 31, 32, E0H, 00H, 01H, PTP-primary multicast address:
(IEEE 1588 version 33 81H 224.0.1.129
2) E0H, 00H, 00H, PTP-Pdelay multicast address:
6BH 224.0.0.107
UDP destination 36, 37 013FH, 013FH PTP event message1)
port 0140H 0140H PTP general messages
PTP control field 74 00H/01H/02H/03H 00H SYNC,
(IEEE version 1) /04H 01H Delay_Req,
02H Follow_Up
03H Delay_Resp
04H Management
PTP Message Type 42 (nibble) 0H/1H/2H/3H/8H/9 0H SYNC
Field (IEEE version H/BH/CH/DH 1H Delay_Req
2) 2H Pdelay_Req
3H Pdelay_Resp
8H Follow_Up
9H Delay_Resp
AH Pdelay_Resp_Follow_Up
BH Announce
CH Signaling
DH - Management
PTP version field 43 (nibble) 1H or 2H 1 Supports PTP version 1
2 Supports PTP version 2
1) PTP event messages are SYNC, Delay_Req (IEEE 1588 version 1 and 2) or Pdelay_Req, Pdelay_Resp (IEEE
1588 version 2 only).
PTP Frame Over IPv6

PTP packets over UDP over IPv6 for IEEE 1588 version 1 and 2. Note that the octet
positions for tagged frames will be offset by 4. This is based on Appendix-E of the IEEE
1588-2008 standard and the message format defined in Table 15-22.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-24 IPv6-UDP PTP Frame Fields Required for Control and Status
Position
MAC Frame type 12, 13 86DDH IP datagram
IP version 14 (bits 6H IP version is IPv6
[7:4])
Layer-4 protocol 201) 11H UDP
PTP Multicast 38 53 FF0:0:0:0:0:0:0:1 PTP primary multicast
address 81H address:
FF02:0:0:0:0:0:0: FF0:0:0:0:0:0:0:0:0:181H
6BH PTP Pdelay multicast
address:
FF02:0:0:0:0:0:0:0:0:6BH
UDP destination 56, 57 013FH, 140H 013FH PTP event message
port (*) 0140H PTP general messages
PTP control field 93 (*) 00H/01H/02H/03H/ 00H SYNC,
(IEEE 1588 Version 04H 01H Delay_Req,
1) 02H Follow_Up
03H Delay_Resp
04H Management (version1)
PTP Message Type 74 (*) 0H/1H/2H/3H/8H/9 0H SYNC
Field (IEEE version (nibble) H/BH/CH/DH 1H Delay_Req
2) 2H Pdelay_Req
3H Pdelay_Resp
8H Follow_Up
9H Delay_Resp
AH Pdelay_Resp_Follow_Up
BH Announce
CH Signaling
DH - Management
PTP version field 75 (nibble) 1H or 2H 1H Supports PTP version 1
2H Supports PTP version 2
1) The Extension Header is not defined for PTP packets.
PTP Frame Over Ethernet

PTP packets over Ethernet for IEEE 1588 version 1 and 2. Note that the octet positions

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
for tagged frames will be offset by 4. This is based on Appendix-E of the IEEE 1588-2008
standard and the message format defined in Table 15-22.
Table 15-25 Ethernet PTP Frame Fields Required for Control And Status
Position
MAC Frame type 12, 13 88F7H PTP Ethernet frame.
PTP control field 45 00H/01H/02H/ 00H SYNC
(IEEE Version 1) 03H/04H 01H Delay_Req
02H Follow_Up
03H Delay_Resp
04H Management
PTP Message Type 14 (nibble) 0H/1H/2H/3H/8H/9H/B 0H SYNC
Field (IEEE version H/ CH/DH 1H Delay_Req
2) 2H Pdelay_Req
3H Pdelay_Resp
8H Follow_Up
9H Delay_Resp
AH
Pdelay_Resp_Follow_Up
BH Announce
CH Signaling
DH Management
MAC Destination 0-5 01-1B-19-00-00- All except peer delay
multicast address1) 00H messages - 01-1B-19-00-00-
01-80-C2-00-00- 00H
0EH Pdelay messages - 01-80-
C2-00-00-0EH
PTP version field 15 (nibble) 1H or 2H 1H Supports PTP version 1
2H Supports PTP version 2
1) In addition, the address match of destination addresses (DA) programmed in MAC address 1 to 31 will be
used, if the control bit 18 (TSENMACADDR: Enable MAC address for PTP frame filtering) of the Time Stamp
Control register is set.
15.2.11.10Reference Timing Source (for Advance Timestamp Feature)

The updated functionality for advanced timestamp support is mentioned in the following
points.
1. The IEEE 1588-2008 standard defines the seconds field of the time to be 48 bits
wide. The fields to time-stamp will be the following.
a) UInteger48- seconds field

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
b) UInteger32-nanoseconds field
The seconds field is the integer portion of the timestamp in units of seconds. The
nanoseconds field is the fractional portion of the timestamp in units of
nanoseconds. E.g. 2.000000001 seconds is represented as secondsField = 0000
0000 0002H and nanoSeconds = 0000 0001H. Thus the maximum value in
nanoseconds field in this format will be 3B9A C9FFH value (i.e (10e9-1) nano-
seconds). This is defined as digital rollover mode of operation. It will also support
the older mode in which the nano-seconds field will roll-over and increment the
seconds field after the value of 7FFF FFFFH. (Accuracy is ~0.466 ns per bit). This
is defined as the binary rollover mode. The modes can be controlled using the
ETH0_TIMESTAMP_CONTROL.TSCTRLSSR bit.
2. When the Advanced IEEE 1588 time-stamp feature is selected time maintained in the
core will still be 64-bit wide, as the overflow to the upper 16-bits of seconds register
happens once in 130 years. The value of the upper 16-bits of the seconds field can
only be obtained from the CSR register.
3. There is also a pulse-per-second output given to indicate 1 second interval (default).
Option is provided to change the interval in the ETH0_PPS_CONTROL Register.
4.
15.2.11.11Transmit Path Functions

There are no changes in the transmit path functions for ETH-CORE and ETH-MTL
configuration for the Advanced time stamp option.
structure of the descriptor changes when Advanced IEEE 1588 version support is
enabled. The IEEE 1588 timestamp feature is supported using Alternate (Enhanced)
descriptors format only. The descriptor is 32-bytes long (8 DWORDS) and the snapshot
of the timestamp is written in descriptor 6 and 7.
15.2.11.12Receive Path Functions

When the advanced time stamp feature is selected, processing of the received frames
to identify valid PTP frames is done. The snapshot of the time to be sent to the
application can be controlled.
The following options are provided in the TIMESTAMP_CONTROL register to control the
snapshot.
1. Option to enable snapshot for all frames.
2. Enable snapshot for IEEE 1588 version 2 or version 1 time stamp.
3. Enable snapshot for PTP frames transmitted directly over Ethernet or
UDP-IP-Ethernet.
4. Enable time stamp snapshot for the received frame for IPv4 or IPv6.
5. Enable time stamp snapshot for EVENT messages (SYNC, DELAY_REQ,
PDELAY_REQ or PDELAY_RESP) only.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
6. Enable the node to be a Master or Slave. This will control the type of messages for
which snap-shot will be taken (this depends on the type of clock that is selected and
is valid for ordinary or boundary clock only).
Note that PTP messages over VLAN frames are also supported.
15.2.12 System Time Register Module

A system time clock is maintained in this module. A 64 bit timer is incremented using the
PTP clock as refference. This time is the source for taking snapshots (time stamps) of
Ethernet frames being transmitted or received at the MII.
The System Time counter can be initialized or corrected using the coarse correction
method. In this method, the initial value or the offset value is written to the Time Stamp
Update register. For initialization, the System Time
counter(ETH0_SYSTEM_TIME_SECONDS and
ETH0_SYSTEM_TIME_NANOSECONDS) is written with the value in the Time Stamp
Update registers (ETH0_SYSTEM_TIME_SECONDS_UPDATE and
ETH0_SYSTEM_TIME_NANOSECONDS_UPDATE) , while for system time correction,
the offset value is added to or subtracted from the system time.
In the fine correction method, a slave clocks frequency drift with respect to the master
clock (as defined in IEEE 1588) is corrected over a period of time instead of in one clock,
as in coarse correction. This helps maintain linear time and does not introduce drastic
changes (or a large jitter) in the reference time between PTP Sync message intervals. In
this method, an accumulator sums up the contents of the Addend register, as shown in
Figure 15-26. The arithmetic carry that the accumulator generates is used as a pulse to
increment the system time counter. The accumulator and the addend are 32-bit
registers. Here, the accumulator acts as a high-precision frequency multiplier or divider.
This algorithm is depicted in Figure 15-26:

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
addend_val[31:0]
addend_updt
Addend register
Accumulator register
Constant value
incr_sub_sec_reg
+
Sub-second register
incr_sec_reg
Second register
System_Time_Update_Using_Fine_Method.vsd
Figure 15-26 System Time Update Using Fine Method

The System Time Update logic requires a 50-MHz clock frequency to achieve 20-ns
accuracy. The frequency division is the ratio of the reference clock frequency to the
required clock frequency. Hence, if the reference clock is, for example, 66 MHz, this
ratio is calculated as 66 MHz / 50 MHz = 1.32. Hence, the default addend value to be set
in the register is 232 / 1.32, 0C1F07C1FH.
If the reference clock drifts lower, to 65 MHz for example, the ratio is 65 / 50, or 1.3 and
the value to set in the addend register is 232 / 1.30, or 0C4EC4EC4H. If the clock drifts
higher, to 67 MHz for example, the addend register must be set to 0BF0B7672H. When
the clock drift is nil, the default addend value of 0C1F07C1FH (232 / 1.32) must be
programmed.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
In Figure 15-26, the constant value used to accumulate the sub-second register is
decimal 43, which achieves an accuracy of 20 ns in the system time (in other words, it is
incremented in 20-ns steps). Two different methods are used to update the System Time
register, depending on which configuration you choose (See Block Diagram).
The software must calculate the drift in frequency based on the Sync messages and
update the Addend register accordingly.
Initially, the slave clock is set with FreqCompensationValue0 in the Addend register. This
value is as follows:
FreqCompensationValue0 = 232 / FreqDivisionRatio
If MasterToSlaveDelay is initially assumed to be the same for consecutive Sync
messages, the algorithm described below must be applied. After a few Sync cycles,
frequency lock occurs. The slave clock can then determine a precise
MasterToSlaveDelay value and re-synchronize with the master using the new value.
The algorithm is as follows:
At time MasterSyncTimen the master sends the slave clock a Sync message. The
slave receives this message when its local clock is SlaveClockTimen and computes
MasterClockTimen as:
MasterClockTimen = MasterSyncTimen + MasterToSlaveDelayn
The master clock count for current Sync cycle, MasterClockCountn is given by:
MasterClockCountn = MasterClockTimen MasterClockTimen 1 (assuming that
MasterToSlaveDelay is the same for Sync cycles n and n 1)
The slave clock count for current Sync cycle, SlaveClockCountn is given by:
SlaveClockCountn = SlaveClockTimen SlaveClockTimen 1
The difference between master and slave clock counts for current Sync cycle,
ClockDiffCountn is given by:
ClockDiffCountn = MasterClockCountn SlaveClockCountn
The frequency-scaling factor for slave clock, FreqScaleFactorn is given by:
FreqScaleFactorn = (MasterClockCountn + ClockDiffCountn) / SlaveClockCountn
The frequency compensation value for Addend register, FreqCompensationValuen is
given by:
FreqCompensationValuen = FreqScaleFactorn * FreqCompensationValuen 1
In theory, this algorithm achieves lock in one Sync cycle; however, it may take several
cycles, due to changing network propagation delays and operating conditions.
This algorithm is self-correcting: if for any reason the slave clock is initially set to a value
from the master that is incorrect, the algorithm will correct it at the cost of more Sync
cycles.
15.2.13 Application BUS Interface

In the ETH core, the DMA Controller interfaces with the CPU through the Bus Interface.
The Bus Master Interface controls data transfers while the Bus Slave interface accesses

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
CSR space. The DMA can be used in applications where DMA is required to optimize
data transfer between the ETH and system memory.
The Bus Master interface converts the internal DMA request cycles into Bus cycles.
Characteristics of this interface include the following:
You can choose fixed burst length of SINGLE, INCR4, INCR8 by programming the
ETH0_BUS_MODE.MB bits
When transfering fixed burst length data , the Bus master always initiates a burst
with SINGLE or INCR4/8type. But when such a burst is responded with
SPLIT/RETRY/early burst termination, the Bus master will re-initiate the pending
transfers of the burst with INCR or SINGLE burst-length type. It will terminate such
INCR bursts when the original requested fixed-burst is transferred. In Fixed
Burst-Length mode, if the DMA requests a burst transfer that is not equal to
INCR4/8, the Bus interface splits the transfer into multiple burst transactions. For
example, if the DMA requests a 15-beat burst transfer, the Bus interface splits it
into multiple transfers of INCR8 and INCR4 and 3 SINGLE transactions.
Takes care of Bus SPLIT, RETRY, and ERROR conditions. Any ERROR response
will halt all further transactions for that DMA, and indicate the error as fatal through
the CSR and interrupt. The application must give a hard or soft reset to the module
to restart the operation.
Takes care of Bus 1K boundary breaking
Handles all data transfers, except for Descriptor Status Write accesses (which are
always 32-bit). In any burst data transfer, the address bus value is always aligned to
the data bus width and need not be aligned to the beat size.
All Bus burst transfers can be aligned to an address value by enabling the
ETH0_BUS_MODE.AAL bit. If both the FB and AAL bits are set to 1, the Bus
interface and the DMA together ensure that all initiated beats are aligned to the
address, completing the frame transfer in the minimum number of required beats.
For example, if a data buffer transfers start address is F000 0008H and the DMA is
configured for a maximum beat size of, the Bus transfers occur in the following
sequence:
2 SINGLE transfers at addresses F000 0008H and F000 000CH
1 INCR4 transfer at address F000 0010H
The DMA Controller requests an Bus Burst Read transfer only when it can accept the
received burst data completely. Data read from the Bus is always pushed into the
DMA without any delay or BUSY cycles.
The DMA requests an Bus Burst Write transfer only when it has the sufficient data to
transfer the burst completely. The Bus interface always assumes that it has data
available to push into the bus. However, the DMA can prematurely indicate end-of-
valid data (due to the transfer of end-of-frame of an Ethernet frame) during the burst.
The Bus Master interface continues the burst with dummy data until the specified
length is completed.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
The Bus 32-bit Slave interface provides access to the DMA and ETH CSR space.
Characteristics of this interface include the following:
Supports single and INCR4/8transfers
Supports busy and early terminations
Supports 32-bit, 16-bit, and 8-bit write/read transfers to the CSR; 32-bit access to the
CSR are recommended to avoid any SW synchronization problems.
Generates OKAY only response; does not generate SPLIT, RETRY, or ERROR
responses.

Service requests can be generated from the ETH core as a result of various events in
the modules within the ETH peripheral. There are four sources of service request, the
ETH DMA, The Power Management module, the System timer module and the MAC
management counters. Each of the events raised by these modules are ORed together
and connected to an ETH Service Request line which is connected to the NVIC. The
events are not queued and the application software must check all the status bits t
ensure all events are serviced. Before exiting the service request routine the application
software must ensure all status bits are de asserted or spurious service requests will be
generated
Transmit
Transmit Buffer Unavailable
Receive AND
Early Receive
Normal Interrupt Enable
Transmit Process stopped
Transmit Jabber Timeout
Receive Overflow
Transmit Underflow
Receive Buffer Unavailable AND
Receive process Stopped Interrupt Mask Register
Receive Watchdog Timeout
Early Transmit Abnormal Interrupt Enable
PMT Interrupt Mask
Fatal Bus Error
Interrupt Enable Register
Magic Packet AND

OR NVIC
AND
Wake Up Frame
PMT Control and Status Register
Timestamp Trigger
Timestamp Control Register AND
Timestamp Interrupt Mask

MMC Transmit counters x 26
MMC Transmit Interrupt Mask Register
MMC Receive counters x 26

MMC Receive Interrupt Mask Register
Figure 15-27 ETH Core Service Request Structure

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.3.1 DMA Service Requests

The ETH DMA has two groups of Service Request, Normal and Abnormal requests.
Each Service Request source is enabled in theETH0_INTERRUPT_ENABLE register.
Each group of Service Requests must also be enabled by setting the Normal Interrupt
enable and Abnormal Interrupt enable bits in the same register. When a service request
is raised the matching Service request bits will be set in the ETH0_STATUS register.
Global summary bits for the Power management MAC management counters and
system time module are also provided in the status register.
15.3.2 Power Management Service Requests

The power management module provides two Service Requests, Wake up Frame and
Magic packet. Both of these service requests may be enabled and monitored in the
PMT_CONTROL_STATUS Register. To enable any power management service
request is it also necessary to clear the INTERRUPT_MASK.PMTIM bit. The
INTERRUPT_STATUS.PMTIS bit provides a global status bit for power management
service requests.
15.3.3 System Time Module

The system time module provides a single Timestamp trigger service request which can
be enabled in the timestanp control register. The INTERRUPT_MASK.TSIM bit must
also be cleared to enable the timestamp trigger Service request.The
INTERRUPT_STATUS.TSIS is set when a system time module service request occurs.
15.3.4 MAC Management Counter Service Requests

Each of the MAC Management Counters can generate a service request. The service
requests are split into two groups of transmit and receive counters. Each counter may
be individually enabled in either the MMC_RECEIVE_INTERRUPT_MASK register or
the MMC_TRANSMIT_INTERRUPT_MASK register. When a MMC service request is
generated status bits for each counter are set in the MMC_RECEIVE_INTERRUPT
register or the MMC_TRANSMIT_INTERRUPT register.Two global status bits for the
transmit and receive counters are provided in the INTERRUPT_STATUS register

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.4 Debug
Module specific debug behaviour TBD
In addition the ETH has a number of intrinsic features to assist debugging, these are
described below.
The DEBUG register provides flags which indicate the operating status of the ETH
MAC and MTL.
The STATUS register provides information on the operating status of the DMA.
The MAC Management Counters provide extensive information about the Received
and transmitted Ethernet frames.
The MAC_CONFIGURATION.LM bit places the ETH in internal loopback mode for
self test and debug
External loopback is supported via the integrated MDIO controlling the PHY
TheCURRENT_HOST_TRANSMIT_DESCRIPTOR and
CURRENT_HOST_RECEIVE_DESCRIPTOR provide pointers to the current
location of the transmit and receive frame buffers held in RAM
15.5 Power Reset and Clock
The module, including all registers, can be reset to its default state by a system reset or
a software reset triggered through the setting of corresponding bits in PRSETx
registers.
The module has the following input clocks:
clk_eth_ahb : The module clock

clk_eth_sram : A seperate clock for the module internal RAM
Important
After the XMC4500 is released from reset the ETH module remains held in reset. While
the ETH is held in reset the software driver must select the PHY interconnect see
Section 15.2.7.1 . Once the PHY interconnect has been selected ETH reset line must
be deasserted by setting PRCLR2.ETH0RS in the system control unit.
The clk_eth_ahb has a minumum frequency of 50Mhz.

The clk_eth_sram frequency must be 2 x the clk_eth_ahb and has a minumum
frequency of 100Mhz.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.6 ETH Registers

The application controls the ETH by reading from and writing to the Control and Status
Registers (CSRs) through the BUS Slave interface. These registers are 32 bits wide and
the addresses are 32-bit block aligned
15.6.1 Register Description
ETH Register Map

Table 15-27 provides the address map of the ETH core registers.
0000 H
ETH Core
00DCH
Reserved
0100 H
ETH MAC
Management
Counters
0288 H
Reserved
0700 H
IEEE1588
System time
module
07FCH
Reserved
1000 H
ETH DMA
1058 H
eth_Memory_map.vsd
Figure 15-28 ETH Register memory Map
Table 15-26 Registers Address Space - ETH Module

ETH0 5000 C000H 5000 FFFFH -

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.6.2 Registers Overview
Table 15-27 ETH Registers Overview

Addr.1) Read Write See
MAC Configuration Registers
MAC_CONFIGURAT MAC Configuration 0000H U,PV U,PV Page 15-11
ION Register 0
MAC_FRAME_FILTE MAC Frame Filter 0004H U,PV U,PV Page 15-11

R Register 7
Hash Table High 0008H U,PV U,PV Page 15-12
HASH_TABLE_HIGH Register 2
HASH_TABLE_LOW Hash Table Low 000CH U,PV U,PV Page 15-12
Register 4
GMII_ADDRESS MII Address Register 0010H U,PV U,PV Page 15-12

5
GMII_DATA MII Data Register 0014H U,PV U,PV Page 15-12
8
FLOW_CONTROL Flow Control Register 0018H U,PV U,PV Page 15-12
9
VLAN_TAG VLAN Tag Register 001CH U,PV U,PV Page 15-13
3
VERSION Version Register 0020H U,PV NC Page 15-13
5
DEBUG Debug Register 0024H U,PV U,PV Page 15-13

6
REMOTE_WAKE_U Remote Wake Up 0028H U,PV U,PV Page 15-13

P_FRAME_FILTER Frame Filter Register 9
PMT_CONTROL_ST PMT Control Status 002CH U,PV U,PV Page 15-14
ATUS Register 0
Do not use Do not use 0030H - nBE nBE Do not use
0034H

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-27 ETH Registers Overview (contd)

INTERRUPT_STATU Interrupt Status Register 0038H U,PV U,PV Page 15-14
S 2
INTERRUPT_MASK Interrupt Mask Register 003CH U,PV U,PV Page 15-14
4]
MAC_ADDRESS0_H MAC Address 0 High 0040H U,PV U,PV Page 15-14
IGH Register 5
MAC Address0 Low 0044H U,PV U,PV Page 15-14
MAC_ADDRESS0_L Register 6]
OW
MAC Address1 High 0048H U,PV U,PV Page 15-14
MAC_ADDRESS1_H Register 7
IGH
MAC_ADDRESS1_L MAC Address1 Low 004CH U,PV U,PV Page 15-14

OW Register 9
MAC_ADDRESS2_H MAC Address High 0050H U,PV U,PV Page 15-15
IGH Register 0
MAC_ADDRESS2_L MAC Address1 Low 0054H U,PV U,PV Page 15-15

OW Register 2
MAC_ADDRESS3_H MAC Address High 0058H U,PV U,PV Page 15-15
IGH Register 3
MAC_ADDRESS3_L MAC Address1 Low 005CH U,PV U,PV Page 15-15

OW Register 5
Do not use Do not use 00DCH nBE nBE Do not use
-
00FCH
MAC Mangement Counters
MMC_CONTROL MMC Control 0100H U,PV U,PV Page 15-15
6
MMC_RECEIVE_IN MMC Receive Interrupt 0104H U,PV U,PV Page 15-15
TERRUPT 8

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

MMC_TRANSMIT_I MMC Transmit Interrupt 0108H U,PV U,PV Page 15-16
NTERRUPT 3
MMC_RECEIVE_IN MMC Receive Interrupt 010CH U,PV U,PV Page 15-16
TERRUPT_MASK mask 8
MMC_TRANSMIT_I MMC Transmit Interrupt 0110H U,PV U,PV Page 15-17
NTERRUPT_MASK Mask 3
TX_OCTET_COUN Number of bytes 0114H U,PV U,PV Page 15-17
T_GOOD_BAD transmitted, exclusive of 8
preamble and retried
bytes, in good and bad
frames.
TX_FRAME_COUN Number of good and 0118H U,PV U,PV Page 15-17
T_GOOD_BAD bad frames transmitted, 9
exclusive of retried
frames.
TX_BROADCAST_F Number of good 011CH U,PV U,PV Page 15-18
RAMES_GOOD broadcast frames 0
transmitted.
TX_MULTICAST_F Number of good 0120H U,PV U,PV Page 15-18
RAMES_GOOD multicast frames 1
transmitted.
TX_64OCTETS_FR Number of good and 0124H U,PV U,PV Page 15-18
AMES_GOOD_BAD bad frames transmitted 2
with length 64 bytes,
exclusive of preamble
and retried frames.
TX_65TO127OCTE Number of good and 0128H U,PV U,PV Page 15-18
TS_FRAMES_GOO bad frames transmitted 3
D_BAD with length between 65
and 127 (inclusive)
bytes, exclusive of
frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TX_128TO255OCT Number of good and 012CH U,PV U,PV Page 15-18
ETS_FRAMES_GO bad frames transmitted 4
OD_BAD with length between 128
and 255 (inclusive)
bytes, exclusive of
frames.
TX_256TO511OCT Number of good and 0130H U,PV U,PV Page 15-18
and 511 (inclusive)
bytes, exclusive of
frames.
TX_512TO1023OCT Number of good and 0134H U,PV U,PV Page 15-18
and 1.023 (inclusive)
bytes, exclusive of
frames.
TX_1024TOMAXOC Number of good and 0138H U,PV U,PV Page 15-18
TETS_FRAMES_G bad frames transmitted 7
OOD_BAD with length between .
1.024 and maxsize
(inclusive) bytes,
and retried frames.
TX_UNICAST_FRA Number of good and 013CH U,PV U,PV Page 15-18
MES_GOOD_BAD bad unicast frames 8
transmitted.
TX_MULTICAST_F Number of good and 0140H U,PV U,PV Page 15-18
RAMES_GOOD_BA bad multicast frames 9
D transmitted.
TX_BROADCAST_F Number of good and 0144H U,PV U,PV Page 15-19
RAMES_GOOD_BA bad broadcast frames 0
D transmitted.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TX_UNDERFLOW_ Number of frames 0148H U,PV U,PV Page 15-19
ERROR_FRAMES aborted due to frame 1
underflow error.
TX_SINGLE_COLLI Number of successfully 014CH U,PV U,PV Page 15-19
SION_GOOD_FRA transmitted frames after 2
MES a single collision in Half-
duplex mode.
TX_MULTIPLE_CO Number of successfully 0150H U,PV U,PV Page 15-19
LLISION_GOOD_F transmitted frames after 3
RAMES more than a single
collision in Half-duplex
mode.
TX_DEFERRED_FR Number of successfully 0154H U,PV U,PV Page 15-19
AMES transmitted frames after 4
a deferral in Half-duplex
mode.
TX_LATE_COLLISI Number of frames 0158H U,PV U,PV Page 15-19
ON_FRAMES aborted due to late 5
collision error.
TX_EXCESSIVE_C Number of frames 015CH U,PV U,PV Page 15-19
OLLISION_FRAME aborted due to 6
S excessive (16) collision
errors.
TX_CARRIER_ERR Number of frames 0160H U,PV U,PV Page 15-19
OR_FRAMES aborted due to carrier 7
sense error (no carrier
or loss of carrier).
TX_OCTET_COUN Number of bytes 0164H U,PV U,PV Page 15-19
T_GOOD transmitted, exclusive of 8
preamble, in good
frames only.
TX_FRAME_COUN Number of good frames 0168H U,PV U,PV Page 15-19
T_GOOD transmitted. 9

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TX_EXCESSIVE_D Number of frames 016CH U,PV U,PV Page 15-20
EFERRAL_ERROR aborted due to 0
excessive deferral error
(deferred for more than
two max-sized frame
times).
TX_PAUSE_FRAME Number of good PAUSE 0170H U,PV U,PV Page 15-20
S frames transmitted. 1
TX_VLAN_FRAMES Number of good VLAN 0174H U,PV U,PV Page 15-20

_GOOD frames transmitted, 2
frames.
TX_OSIZE_FRAME Number of transmitted 0178H U,PV U,PV Page 15-20
S_GOOD good Oversize frames, 3
frames.
Reserved 017CH nBE nBE
RX_FRAMES_COU Number of good and 0180H U,PV U,PV Page 15-20
NT_GOOD_BAD bad frames received. 4
RX_OCTET_COUN Number of bytes 0184H U,PV U,PV Page 15-20
T_GOOD_BAD received, exclusive of 5
preamble, in good and
bad frames.
RX_OCTET_COUN Number of bytes 0188H U,PV U,PV Page 15-20
T_GOOD received, exclusive of 6
preamble, only in good
frames.
RX_BROADCAST_ Number of good 018CH U,PV U,PV Page 15-20
FRAMES_GOOD broadcast frames 7
received.
RX_MULTICAST_F Number of good 0190H U,PV U,PV Page 15-20
RAMES_GOOD multicast frames 8
received.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RX_CRC_ERROR_ Number of frames 0194H U,PV U,PV Page 15-20
FRAMES received with CRC 9
error.
RX_ALIGNMENT_E Number of frames 0198H U,PV U,PV Page 15-21
RROR_FRAMES received with alignment 0
(dribble) error.
RX_RUNT_ERROR Number of frames 019CH U,PV U,PV Page 15-21
_FRAMES received with runt (<64 1
bytes and CRC error)
error.
RX_JABBER_ERRO Number of giant frames 01A0H U,PV U,PV Page 15-21
R_FRAMES received with length 2
(including CRC) greater
than 1.518 bytes (1.522
bytes for VLAN tagged)
and with CRC error. If
Jumbo Frame mode is
enabled, then frames of
length greater than
9,018 bytes (9,022 for
VLAN tagged) are
considered as giant
frames.
RX_UNDERSIZE_F Number of frames 01A4H U,PV U,PV Page 15-21
RAMES_GOOD received with length less 3
than 64 bytes, without
any errors.
RX_OVERSIZE_FR Number of frames 01A8H U,PV U,PV Page 15-21
AMES_GOOD received with length 4
greater than the
maxsize (1.518 or 1.522
for VLAN tagged
frames), without errors.
RX_64OCTETS_FR Number of good and 01ACH U,PV U,PV Page 15-21
AMES_GOOD_BAD bad frames received 5
with length 64 bytes,
exclusive of preamble.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RX_65TO127OCTE Number of good and 01B0H U,PV U,PV Page 15-21
TS_FRAMES_GOO bad frames received 6
D_BAD with length between 65
and 127 (inclusive)
bytes, exclusive of
preamble.
RX_128TO255OCT Number of good and 01B4H U,PV U,PV Page 15-21
ETS_FRAMES_GO bad frames received 7
and 255 (inclusive)
bytes, exclusive of
preamble.
RX_256TO511OCT Number of good and 01B8H U,PV U,PV Page 15-21
ETS_FRAMES_GO bad frames received 8
and 511 (inclusive)
bytes, exclusive of
preamble.
RX_512TO1023OC Number of good and 01BCH U,PV U,PV Page 15-21
TETS_FRAMES_G bad frames received 9
OOD_BAD with length between 512
and 1.023 (inclusive)
bytes, exclusive of
preamble.
RX_1024TOMAXOC Number of good and 01C0H U,PV U,PV Page 15-22
TETS_FRAMES_G bad frames received 0
OOD_BAD with length between
1.024 and maxsize
(inclusive) bytes,
and retried frames.
RX_UNICAST_FRA Number of good unicast 01C4H U,PV U,PV Page 15-22
MES_GOOD frames received. 1

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RX_LENGTH_ERR Number of frames 01C8H U,PV U,PV Page 15-22
OR_FRAMES received with length 2
error (Length type field
frame size), for all
frames with valid length
field.
RX_OUT_OF_RAN Number of frames 01CCH U,PV U,PV Page 15-22
GE_TYPE_FRAME received with length 3
S field not equal to the
valid frame size (greater
than 1.500 but less than
1.536).
RX_PAUSE_FRAM Number of good and 01D0H U,PV U,PV Page 15-22
ES valid PAUSE frames 4
received.
RX_FIFO_OVERFL Number of missed 01D4H U,PV U,PV Page 15-22
OW_FRAMES received frames due to 5
FIFO overflow.
RX_VLAN_FRAMES Number of good and 01D8H U,PV U,PV Page 15-22
_GOOD_BAD bad VLAN frames 6
received.
RX_WATCHDOG_E Number of frames 01DCH U,PV U,PV Page 15-22
RROR_FRAMES received with error due 7
to watchdog timeout
error (frames with a data
load larger than 2.048
bytes).
RX_RECEIVE_ERR Number of frames 01E0H U,PV U,PV Page 15-22
OR_FRAMES received with error 8
because of the MII
RXER error.
RX_CONTROL_FR Number of god control 01E4H U,PV U,PV Page 15-22
AMES_GOOD frames received. 9
Reserved 01E8H nBE nBE

01FCH

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

MMC_IPC_RECEIV MMC IPC Receive 0200H U,PV U,PV Page 15-23
E_INTERRUPT_MA Checksum Offload 0
SK Interrupt Mask
maintains the mask for
the interrupt generated
from the receive IPC
statistic counters.
Reserved 0204H nBE nBE
MMC_IPC_RECEIV MMC Receive 0208H U,PV U,PV Page 15-23
E_INTERRUPT Checksum Offload 5
Interrupt maintains the
interrupt that the receive
IPC statistic counters
generate.
Reserved 020CH nBE nBE
RXIPV4_GOOD_FR Number of good IPv4 0210H U,PV U,PV Page 15-24
AMES datagrams received with 0
the TCP, UDP, or ICMP
payload
RXIPV4_HEADER_ Number of IPv4 0214H U,PV U,PV Page 15-24
ERROR_FRAMES datagrams received with 1
header (checksum,
length, or version
mismatch) errors
RXIPV4_NO_PAYL Number of IPv4 0218H U,PV U,PV Page 15-24
OAD_FRAMES datagram frames 2
received that did not
have a TCP, UDP, or
ICMP payload
processed by the
Checksum engine
RXIPV4_FRAGMEN Number of good IPv4 021CH U,PV U,PV Page 15-24
TED_FRAMES datagrams with 3
fragmentation

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXIPV4_UDP_CHE Number of good IPv4 0220H U,PV U,PV Page 15-24
CKSUM_DISABLED datagrams received that 4
_FRAMES had a UDP payload with
checksum disabled
RXIPV6_GOOD_FR Number of good IPv6 0224H U,PV U,PV Page 15-24
AMES datagrams received with 5
TCP, UDP, or ICMP
payloads
RXIPV6_HEADER_ Number of IPv6 0228H U,PV U,PV Page 15-24
ERROR_FRAMES datagrams received with 6
header errors (length or
version mismatch)
RXIPV6_NO_PAYL Number of IPv6 022CH U,PV U,PV Page 15-24
OAD_FRAMES datagram frames 7
received that did not
have a TCP, UDP, or
ICMP payload. This
includes all IPv6
datagrams with
fragmentation or
security extension
headers
RXUDP_GOOD_FR Number of good IP 0230H U,PV U,PV Page 15-24
AMES datagrams with a good 8
UDP payload. This
counter is not updated
when the
RXIPV4_UDP_CHECK
SUM_DISABLED_FRA
MES counter is
incremented.
RXUDP_ERROR_F Number of good IP 0234H U,PV U,PV Page 15-24
RAMES datagrams whose UDP 9
payload has a
checksum error

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXTCP_GOOD_FR Number of good IP 0238H U,PV U,PV Page 15-25
AMES datagrams with a good 0
TCP payload
RXTCP_ERROR_F Number of good IP 023CH U,PV U,PV Page 15-25
RAMES datagrams whose TCP 1
payload has a
checksum error
RXICMP_GOOD_F Number of good IP 0240H U,PV U,PV Page 15-25
RAMES datagrams with a good 2
ICMP payload
RXICMP_ERROR_F Number of good IP 0244H U,PV U,PV Page 15-25
RAMES datagrams whose ICMP 3
payload has a
checksum error

024CH
RXIPV4_GOOD_OC Number of bytes 0250H U,PV U,PV Page 15-25
TETS received in good IPv4 4
datagrams
encapsulating TCP,
UDP, or ICMP data.
(Ethernet header, FCS,
pad, or IP pad bytes are
not included in this
counter or in the octet
counters listed below).
RXIPV4_HEADER_ Number of bytes 0254H U,PV U,PV Page 15-26
ERROR_OCTETS received in IPv4 0
datagrams with header
errors (checksum,
length, version
mismatch). The value in
the Length field of IPv4
header is used to
update this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXIPV4_NO_PAYL Number of bytes 0258H U,PV U,PV Page 15-25
OAD_OCTETS received in IPv4 6
datagrams that did not
have a TCP, UDP, or
ICMP payload. The
value in the IPv4
headers Length field is
used to update this
counter.
RXIPV4_FRAGMEN Number of bytes 025CH U,PV U,PV Page 15-25
TED_OCTETS received in fragmented 7
IPv4 datagrams. The
value in the IPv4
used to update this
counter.
RXIPV4_UDP_CHE Number of bytes 0260H U,PV U,PV Page 15-25
CKSUM_DISABLE_ received in a UDP 8
OCTETS segment that had the
UDP checksum
disabled. This counter
does not count IP
Header bytes.
RXIPV6_GOOD_OC Number of bytes 0264H U,PV U,PV Page 15-25
TETS received in good IPv6 9
datagrams
encapsulating TCP,
UDP or ICMPv6 data
RXIPV6_HEADER_ Number of bytes 0268H U,PV U,PV Page 15-26
ERROR_OCTETS received in IPv6 0
datagrams with header
errors (length, version
mismatch). The value in
the IPv6 headers
Length field is used to

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXIPV6_NO_PAYL Number of bytes 026CH U,PV U,PV Page 15-26
OAD_OCTETS received in IPv6 1
datagrams that did not
have a TCP, UDP, or
ICMP payload. The
value in the IPv6
used to update this
counter.
RXUDP_GOOD_OC Number of bytes 0270H U,PV U,PV Page 15-26
TETS received in a good UDP 2
segment. This counter
(and the counters
below) does not count
IP header bytes.
RXUDP_ERROR_O Number of bytes 0274H U,PV U,PV Page 15-26
CTETS received in a UDP 3
segment that had
checksum errors
RXTCP_GOOD_OC Number of bytes 0278H U,PV U,PV Page 15-26
TETS received in a good TCP 4
segment
RXTCP_ERROR_O Number of bytes 027CH U,PV U,PV Page 15-26
CTETS received in a TCP 5
segment with checksum
errors
RXICMP_GOOD_O Number of bytes 0280H U,PV U,PV Page 15-26
CTETS received in a good ICMP 6
segment
RXICMP_ERROR_ Number of bytes 0284H U,PV U,PV Page 15-26
OCTETS received in an ICMP 7
segment with checksum
errors

02FCH

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

06FCH
System Time Registers
Timestamp Controlic 0700H U,PV U,PV Page 15-26
TIMESTAMP_CONT Register 8
ROL.
Sub Second Increment 0704H U,PV U,PV Page 15-27
SUB_SECOND_INC Register 2
REMENT
System Time Seconds 0708H U,PV U,PV Page 15-27
SYSTEM_TIME_SE Register 3
CONDS
SYSTEM_TIME_NA System Time 070CH U,PV U,PV Page 15-27
NOSECONDS Nanoseconds Register 4
SYSTEM_TIME_SE System Time Seconds 0710H U,PV U,PV Page 15-27

CONDS_UPDATE Update Register 5
SYSTEM_TIME_NA System Time 0714H U,PV U,PV Page 15-27
NOSECONDS_UPD Nanoseconds Update 6
ATE Register
TIMESTAMP_ADDE Timestamp Addend 0718H U,PV U,PV Page 15-27
ND Register 7
TARGET_TIME_SEC Target Time Seconds 071CH U,PV U,PV Page 15-27

ONDS Register 8
TARGET_TIME_NA Target Time 0720H U,PV U,PV Page 15-27
NOSECONDS Nanoseconds Register 9
SYSTEM_TIME_HIG System Time Higher 0724H U,PV U,PV Page 15-28
HER_WORD_SECO Word Seconds Register 1
NDS
TIMESTAMP_STAT Timestamp Status 0728H U,PV U,PV Page 15-28
US Register 2
PPS_CONTROL PPS Control Register 072CH U,PV U,PV Page 15-28
5

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

07FCH
07FCH
DMA Registers
BUS_MODE BUS Mode Register 1000H U,PV U,PV Page 15-28
9
TRANSMIT_POLL_D Transmit Poll Demand 1004H U,PV U,PV Page 15-29
EMAND Register 4
RECEIVE_POLL_DE Receive Poll Demand 1008H U,PV U,PV Page 15-29
MAND Register 5
RECEIVE_DESCRIP Receive Descriptor List 100CH U,PV U,PV Page 15-29
TOR_LIST_ADDRES Address Register 6
S
TRANSMIT_DESCRI Transmit Descriptor List 1010H U,PV U,PV Page 15-29
PTOR_LIST_ADDRE Address Register 7
SS
STATUS Status Register 1014H U,PV U,PV Page 15-29
8
OPERATION_MODE Operation Mode 1018H U,PV U,PV Page 15-30
Register 4
Interrupt Enable Regist U,PV U,PV Page 15-31
INTERRUPT_ENABL Register er101C 0
E H
MISSED_FRAME_A Missed Frame 1020H U,PV U,PV Page 15-31
ND_BUFFER_OVER And_Buffer Overflow 3
FLOW_COUNTER Counter Register
RECEIVE_INTERRU Receive Interrupt 1024H U,PV U,PV Page 15-31
PT_WATCHDOG_TI Watchdog Timer 4
MER Register
1028H U,PV U,PV
Do not use Do not use 102CH nBE nBE Do not use
Do not use Do not use 1030H- nBE nBE Do not use
1044H

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

CURRENT_HOST_T Current Host Transmit 1048H U,PV U,PV Page 15-31
RANSMIT_DESCRIP Descriptor Register 6
TOR
CURRENT_HOST_R Current Host Receive 104CH U,PV U,PV Page 15-31
ECEIVE_DESCRIPT Descriptor Register 7
OR
CURRENT_HOST_T Current Host Transmit 1050H U,PV U,PV Page 15-31
RANSMIT_BUFFER_ Buffer Address Register 8
ADDRESS
CURRENT_HOST_R Current Host Receive 1054H U,PV U,PV Page 15-31
ECEIVE_BUFFER_A Buffer Address Register 9
DDRESS
HW_FEATURE HW Feature Register 1058H U,PV NC Page 15-32
0
Module Base Address + Offset Address (shown in this column)

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
15.6.2.1 Registers Description
MAC_CONFIGURATION
The MAC Configuration register establishes receive and transmit operating modes.
ETH0_MAC_CONFIGURATION
MAC Configuration Register (0H) Reset Value: 0000 8000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Rese Rese
2KP DCR
rved SARC rved CST TC WD JD BE JE IFG
E S
_31 _26
r r rw r rw r rw rw r rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Rese
Rese
FES DO LM DM IPC DR rved ACS BL DC TE RE PRELEN
rved
_8
r rw rw rw rw rw rw r rw rw rw rw rw rw

PRELEN [1:0] rw Preamble Length for Transmit Frames
These bits control the number of preamble bytes that are
added to the beginning of every Transmit frame. The
preamble reduction occurs only when the MAC is
operating in the full-duplex mode.
* 00B: 7 bytes of preamble
* 01B: 5 byte of preamble
* 10B: 3 bytes of preamble
* 11B: reserved
RE 2 rw Receiver Enable
When this bit is set, the receiver state machine of the
MAC is enabled for receiving frames from the MII. When
this bit is reset, the MAC receive state machine is
disabled after the completion of the reception of the
current frame, and does not receive any further frames
from the MII.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TE 3 rw Transmitter Enable
When this bit is set, the transmit state machine of the
MAC is enabled for transmission on the MII. When this
bit is reset, the MAC transmit state machine is disabled
after the completion of the transmission of the current
frame, and does not transmit any further frames.
DC 4 rw Deferral Check
When this bit is set, the deferral check function is
enabled in the MAC. The MAC issues a Frame Abort
status, along with the excessive deferral error bit set in
the transmit frame status, when the transmit state
machine is deferred for more than 24,288 bit times . If
the Jumbo frame mode is enabled in the 10 or 100 Mbps
mode, the threshold for deferral is 155,680 bits times.
Deferral begins when the transmitter is ready to
transmit, but is prevented because of an active carrier
sense signal (CRS) on the MII. Defer time is not
cumulative. When the transmitter defers for 10,000 bit
times, it transmits, collides, backs off, and then defers
again after completion of back-off. The deferral timer
resets to 0 and restarts.
When this bit is reset, the deferral check function is
disabled and the MAC defers until the CRS signal goes
inactive. This bit is applicable only in the half-duplex
mode and is reserved (RO) in the full-duplex-only
configuration.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

BL [6:5] rw Back-Off Limit
The Back-Off limit determines the random integer
number (r) of slot time delays ( 512 bit times for 10/100
Mbps) for which the MAC waits before rescheduling a
transmission attempt during retries after a collision. This
bit is applicable only in the half-duplex mode and is
reserved (RO) in the full-duplex-only configuration.
* 00B: k = min (n, 10)
* 01B: k = min (n, 8)
* 10B: k = min (n, 4)
* 11B: k = min (n, 1)
where n = retransmission attempt. The random

integer r takes the value in the
range 0 <= r < kth power of 2
ACS 7 rw Automatic Pad or CRC Stripping
When this bit is set, the MAC strips the Pad or FCS field
on the incoming frames only if the value of the length
field is less than 1,536 bytes. All received frames with
length field greater than or equal to 1,536 bytes are
passed to the application without stripping the Pad or
FCS field.
When this bit is reset, the MAC passes all incoming
frames, without modifying them, to the XMC4500
Memory.
Reserved_ 8 r Reserved
8
DR 9 rw Disable Retry
When this bit is set, the MAC attempts only one
transmission. When a collision occurs on the MII
interface, the MAC ignores the current frame
transmission and reports a Frame Abort with excessive
collision error in the transmit frame status.
When this bit is reset, the MAC attempts retries based
on the settings of the BL field (Bits [6:5]). This bit is
applicable only in the half-duplex mode and is reserved
(RO with default value) in the full-duplex-only
configuration.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

IPC 10 rw Checksum Offload
When this bit is set, the MAC calculates the 16-bit ones
complement of the ones complement sum of all received
Ethernet frame payloads. It also checks whether the
IPv4 Header checksum (assumed to be bytes 2526 or
2930 (VLAN-tagged) of the received Ethernet frame) is
correct for the received frame and gives the status in the
receive status word. The MAC also appends the 16-bit
checksum calculated for the IP header datagram
payload (bytes after the IPv4 header) and appends it to
the Ethernet frame transferred to the application (when
Type 2 COE is deselected).
When this bit is reset, this function is disabled.
When Type 2 COE is selected, this bit, when set,
enables the IPv4 header checksum checking and IPv4
or IPv6 TCP, UDP, or ICMP payload checksum
checking. When this bit is reset, the COE function in the
receiver is disabled and the corresponding PCE and IP
HCE status bits are always cleared.
DM 11 rw Duplex Mode
When this bit is set, the MAC operates in the full-duplex
mode where it can transmit and receive simultaneously.
LM 12 rw Loopback Mode
When this bit is set, the MAC operates in the loopback
mode using the MII. The MII Receive clock input is
required for the loopback to work properly, because the
Transmit clock is not looped-back internally.
DO 13 rw Disable Receive Own
When this bit is set, the MAC disables the reception of
frames in the half-duplex mode.
When this bit is reset, the MAC receives all packets that
are given by the PHY while transmitting.
This bit is not applicable if the MAC is operating in the
full-duplex mode.
FES 14 rw Speed
This bit selects the speed in the MII or RMII:
* 0B: 10 Mbps
* 1B: 100 Mbps
This bit generates link speed encoding when TC (Bit 24)
is set in the RMII mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

Reserved 15 r Reserved
DCRS 16 rw Disable Carrier Sense During Transmission
When set high, this bit makes the MAC transmitter
ignore the MII CRS signal during frame transmission in
the half-duplex mode. This request results in no errors
generated because of Loss of Carrier or No Carrier
during such transmission. When this bit is low, the MAC
transmitter generates such errors because of Carrier
Sense and can even abort the transmissions.
IFG [19:17] rw Inter-Frame Gap
These bits control the minimum IFG between frames
during transmission.
* 000B: 96 bit times
* ...
In the half-duplex mode, the minimum IFG can be
configured only for 64 bit times (IFG = 100B). Lower
values are not considered.
JE 20 rw Jumbo Frame Enable
When this bit is set, the MAC allows Jumbo frames of
9,018 bytes (9,022 bytes for VLAN tagged frames)
without reporting a giant frame error in the receive frame
status.
BE 21 r Frame Burst Enable
When this bit is set, the MAC allows frame bursting
during transmission in the MII half-duplex mode. This bit
is reserved (and RO) in the 10/100 Mbps only or full-
duplex-only configurations.
JD 22 rw Jabber Disable
When this bit is set, the MAC disables the jabber timer
on the transmitter. The MAC can transfer frames of up to
16,384 bytes.
When this bit is reset, the MAC cuts off the transmitter if
the application sends out more than 2,048 bytes of data
(10,240 if JE is set high) during transmission.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

WD 23 rw Watchdog Disable
When this bit is set, the MAC disables the watchdog
timer on the receiver. The MAC can receive frames of up
to 16,384 bytes.
When this bit is reset, the MAC does not allow more than
2,048 bytes (10,240 if JE is set high) of the frame being
received. The MAC cuts off any bytes received after
2,048 bytes.
TC 24 r Transmit Configuration in RMII
When set, this bit enables the transmission of duplex
mode, link speed, and link up or down information to the
PHY in RMII. When this bit is reset, no such information
is driven to the PHY.
CST 25 rw CRC Stripping of Type Frames
When set, the last 4 bytes (FCS) of all frames of Ether
type (type field greater than 0600H) are stripped and
dropped before forwarding the frame to the application.
This function is not valid when the IP Checksum Engine
(Type 1) is enabled in the MAC receiver.
26
2KPE 27 rw IEEE 802.3as support for 2K packets Enable
When set, the MAC considers all frames, with up to
2,000 bytes length, as normal packets. When Bit 20
(Jumbo Enable) is not set, the MAC considers all
received frames of size more than 2K bytes as Giant
frames.
When this bit is reset and Bit 20 (Jumbo Enable) is not
set, the MAC considers all received frames of size more
than 1,518 bytes (1,522 bytes for tagged) as Giant
frames.
When Bit 20 (Jumbo Enable) is set, setting this bit has
no effect on Giant Frame status.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

SARC [30:28] r Source Address Insertion or Replacement Control
This field controls the source address insertion or
replacement for all transmitted frames. Bit 30 specifies
which MAC Address register (0 or 1) is used for source
address insertion or replacement based on the values of
Bits [29:28]:
* 10B:
- If Bit 30 is set to 0, the MAC inserts the content of the
MAC Address 0 registers
(ETH0_MAC_ADDRESS0_HIGH and
ETH0_MAC_ADDRESS0_LOW ) in the SA field of all
transmitted frames.
- If Bit 30 is set to 1 the MAC inserts the content of the
ETH0_MAC_ADDRESS1_LOW) in the SA field of all
transmitted frames.
* 11B:
- If Bit 30 is set to 0, the MAC replaces the content of the
transmitted frames.
- If Bit 30 is set to 1 and the Enable MAC Address
Register 1 option is selected during core configuration,
the MAC replaces the content of the MAC Address 1
registers (ETH0_MAC_ADDRESS1_HIGH and
transmitted frames.
Note:
- Changes to this field take effect only on the start of a
frame. If you write this register field when a frame is
being transmitted, only the subsequent frame can use
the updated value, that is, the current frame does not
use the updated value.
31

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MAC_FRAME_FILTER
The MAC Frame Filter register contains the filter controls for receiving frames. Some of
the controls from this register go to the address check block of the MAC, which performs
the first level of address filtering. The second level of filtering is performed on the
incoming frame, based on other controls such as Pass Bad Frames and Pass Control
Frames.
ETH0_MAC_FRAME_FILTER
MAC Frame Filter (4H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DNT VTF
RA Reserved_30_22 IPFE Reserved_19_17
U E
rw r r r r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved_15_11 HPF SAF SAIF PCF DBF PM DAIF HMC HUC PR

PR 0 rw Promiscuous Mode
When this bit is set, the Address Filter module passes all
incoming frames regardless of its destination or source
address. The SA or DA Filter Fails status bits of the
Receive Status Word are always cleared when PR is
set.
HUC 1 rw Hash Unicast
When set, MAC performs destination address filtering of
unicast frames according to the hash table.
When reset, the MAC performs a perfect destination
address filtering for unicast frames, that is, it compares
the DA field with the values programmed in DA registers.
If Hash Filter is not selected during core configuration,
this bit is reserved (and RO).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

HMC 2 rw Hash Multicast
When set, MAC performs destination address filtering of
received multicast frames according to the hash table.
When reset, the MAC performs a perfect destination
address filtering for multicast frames, that is, it compares
the DA field with the values programmed in DA registers.
If Hash Filter is not selected during core configuration,
this bit is reserved (and RO).
DAIF 3 rw DA Inverse Filtering
When this bit is set, the Address Check block operates
in inverse filtering mode for the DA address comparison
for both unicast and multicast frames.
When reset, normal filtering of frames is performed.
PM 4 rw Pass All Multicast
When set, this bit indicates that all received frames with
a multicast destination address (first bit in the
destination address field is '1') are passed.
When reset, filtering of multicast frame depends on
HMC bit.
DBF 5 rw Disable Broadcast Frames
When this bit is set, the AFM module filters all incoming
broadcast frames. In addition, it overrides all other filter
settings.
When this bit is reset, the AFM module passes all
received broadcast frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

PCF [7:6] rw Pass Control Frames
These bits control the forwarding of all control frames
(including unicast and multicast PAUSE frames).
* 00B: MAC filters all control frames from reaching the
application.
* 01B: MAC forwards all control frames except PAUSE
control frames to application even if they fail the Address
filter.
* 10B: MAC forwards all control frames to application
even if they fail the Address Filter.
* 11B: MAC forwards control frames that pass the
Address Filter.
The following conditions should be true for the PAUSE
control frames processing:
* Condition 1: The MAC is in the full-duplex mode and
flow control is enabled by setting
FLOW_CONTROL.RFE.
* Condition 2: The destination address (DA) of the
received frame matches the special multicast address or
the MAC Address 0 when FLOW_CONTROL.UP is set.
* Condition 3: The Type field of the received frame is
8808H and the OPCODE field is 0001H.
Note:
This field should be set to 01 only when the Condition 1
is true, that is, the MAC is programmed to operate in the
full-duplex mode and the RFE bit is enabled. Otherwise,
the PAUSE frame filtering may be inconsistent. When
Condition 1 is false, the PAUSE frames are considered
as generic control frames. Therefore, to pass all control
frames (including PAUSE control frames) when the full-
duplex mode and flow control is not enabled, you should
set the PCF field to 10 or 11 (as required by the
application).
SAIF 8 rw SA Inverse Filtering
When this bit is set, the Address Check block operates
in inverse filtering mode for the SA address comparison.
The frames whose SA matches the SA registers are
marked as failing the SA Address filter.
When this bit is reset, frames whose SA does not match
the SA registers are marked as failing the SA Address
filter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

SAF 9 rw Source Address Filter Enable
When this bit is set, the MAC compares the SA field of
the received frames with the values programmed in the
enabled SA registers. If the comparison matches, then
the SA Match bit of RxStatus Word is set high. When this
bit is set high and the SA filter fails, the MAC drops the
frame.
When this bit is reset, the MAC forwards the received
frame to the application and with the updated SA Match
bit of the RxStatus depending on the SA address
comparison.
HPF 10 rw Hash or Perfect Filter
When this bit is set, it configures the address filter to
pass a frame if it matches either the perfect filtering or
the hash filtering as set by the HMC or HUC bits.
When this bit is low and the HUC or HMC bit is set, the
frame is passed only if it matches the Hash filter.
Reserved_ [15:11] r Reserved
15_11
VTFE 16 rw VLAN Tag Filter Enable
When set, this bit enables the MAC to drop VLAN
tagged frames that do not match the VLAN Tag
comparison.
When reset, the MAC forwards all frames irrespective of
the match status of the VLAN Tag.
19_17
IPFE 20 r Layer 3 and Layer 4 Filter Enable
When set, this bit enables the MAC to drop frames that
do not match the enabled Layer 3 and Layer 4 filters. If
Layer 3 or Layer 4 filters are not enabled for matching,
this bit does not have any effect.
When reset, the MAC forwards all frames irrespective of
the match status of the Layer 3 and Layer 4 fields.
If the Layer 3 and Layer 4 Filtering feature is not selected
during core configuration, this bit is reserved (RO with
default value).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

DNTU 21 r Drop non-TCP/UDP over IP Frames
When set, this bit enables the MAC to drop the non-TCP
or UDP over IP frames. The MAC forward only those
frames that are processed by the Layer 4 filter.
When reset, this bit enables the MAC to forward all non-
TCP or UDP over IP frames.
30_22
RA 31 rw Receive All
When this bit is set, the MAC Receiver module passes
all received frames, irrespective of whether they pass
the address filter or not, to the Application. The result of
the SA or DA filtering is updated (pass or fail) in the
corresponding bits in the Receive Status Word.
When this bit is reset, the Receiver module passes only
those frames to the Application that pass the SA or DA
address filter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
HASH_TABLE_HIGH
The 64-bit Hash table is used for group address filtering. For hash filtering, the contents
of the destination address in the incoming frame is passed through the CRC logic, and
the upper 6 bits of the CRC register are used to index the contents of the Hash table.
The most significant bit determines the register to be used (Hash Table High or Hash
Table Low), and the other 5 bits determine which bit within the register. A hash value of
00000B selects Bit 0 of the selected register, and a value of 11111B selects Bit 31 of the
selected register. The hash value of the destination address is calculated in the following
way:
1. Calculate the 32-bit CRC for the DA (See IEEE 802.3, Section 3.2.8 for the steps to
calculate CRC32).
2. Perform bitwise reversal for the value obtained in Step 1.
3. Take the upper 6 bits from the value obtained in Step 2.
For example, if the DA of the incoming frame is received as 1F52 419C B6AFH (1FH is
the first byte received on MII interface), then the internally calculated 6-bit Hash value is
2CH and Bit 12 of Hash Table High register is checked for filtering. If the DA of the
incoming frame is received as A00A 9800 0045H, then the calculated 6-bit Hash value
is 07H and Bit 7 of Hash Table Low register is checked for filtering. Note: To help you
program the hash table, a sample C routine that generates a DA's 6-bit hash is included
in the /sample_codes/ directory of your workspace. If the corresponding bit value of the
register is 1, the frame is accepted. Otherwise, it is rejected. If the PM (Pass All Multicast)
bit is set in the MAC Frame Filter Register, then all multicast frames are accepted
regardless of the multicast hash values. If the Hash Table register is configured to be
double-synchronized to the MII clock domain, the synchronization is triggered only when
Bits[31:24] (in little-endian mode) of the Hash Table High or Low registers are written.
Consecutive writes to these register should be performed only after at least four clock
cycles in the destination clock domain when double-synchronization is enabled. The
Hash Table High register contains the higher 32 bits of the Hash table.
ETH0_HASH_TABLE_HIGH
Hash Table High Register (8H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
HTH
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
HTH
rw

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

HTH [31:0] rw Hash Table High
This field contains the upper 32 bits of the Hash table.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
HASH_TABLE_LOW
The Hash Table Low register contains the lower 32 bits of the Hash table. Both Register
2 and Register 3 are reserved if the Hash Filter Function is disabled or the 128-bit or 256-
bit Hash Table is selected during core configuration.
ETH0_HASH_TABLE_LOW
Hash Table Low Register (CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
HTL
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
HTL
rw

HTL [31:0] rw Hash Table Low
This field contains the lower 32 bits of the Hash table.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
GMII_ADDRESS
The MII Address register controls the management cycles to the external PHY through
the management interface.
ETH0_GMII_ADDRESS
MII Address Register (10H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_31_16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PA MR CR MW MB
rw rw rw rw rw

MB 0 rw MII Busy
This bit should read logic 0 before writing to the MII
Address and Data registers. During a PHY register
access, the software sets this bit to 1 to indicate that a
Read or Write access is in progress.
The MII Data Register is invalid until this bit is cleared by
the MAC. Therefore the MII Data Register should be
kept valid until the MAC clears this bit during a PHY
Write operation. Similarly for a read operation, the
contents of the MII Data Register are not valid until this
bit is cleared.
The subsequent read or write operation should happen
only after the previous operation is complete. Because
there is no acknowledgment from the PHY to MAC after
a read or write operation is completed, there is no
change in the functionality of this bit even when the PHY
is not present.
MW 1 rw MII Write
When set, this bit indicates to the PHY that this is a Write
operation using the MII Data register. If this bit is not set,
it indicates that this is a Read operation, that is, placing
the data in the MII Data register.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

CR [5:2] rw CSR Clock Range
The CSR Clock Range selection determines the
frequency of the MDC clock according to the ETH Clock
frequency used in your design. The suggested range of
ETH Clock frequency applicable for each value (when
Bit[5] = 0) ensures that the MDC clock is approximately
between the frequency range 1.0 MHz - 2.5 MHz.
- 0000B: The frequency of the ETH Clock is 60-100 MHz
and the MDC clock is ETH Clock /42.
- 0001B: The frequency of the ETH Clock is 100-150
MHz and the MDC clock is ETH Clock /62.
- 0110B and 0111B: Reserved
When Bit 5 is set, you can achieve MDC clock of

frequency higher than the IEEE 802.3 specified
frequency limit of 2.5 MHz and program a clock divider
of lower value. For example, when the ETH Clock is of
100 MHz frequency and you program these bits as
1010B, then the resultant MDC clock is of 12.5 MHz
which is outside the limit of IEEE 802.3 specified range.
Program the following values only if the interfacing chips
support faster MDC clocks:
- 1000: ETH Clock /4
- 1011: ETH Clock /10
- 1100: ETH Clock /12
- 1101: ETH Clock /14
- 1110: ETH Clock /16
- 1111:ETH Clock /18
MR [10:6] rw MII Register
These bits select the desired MII register in the selected
PHY device.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

PA [15:11] rw Physical Layer Address
This field indicates which of the 32 possible PHY
devices are being accessed.

31_16

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
GMII_DATA
The MII Data register stores Write data to be written to the PHY register located at the
address specified in the MII Address Register. This register also stores the Read data
from the PHY register located at the address specified by the MII Address Register.
ETH0_GMII_DATA
MII Data Register (14H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_31_16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MD
rw

MD [15:0] rw MII Data
This field contains the 16-bit data value read from the
PHY or RevMII after a Management Read operation or
the 16-bit data value to be written to the PHY before a
Management Write operation.
31_16

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
FLOW_CONTROL
The Flow Control register controls the generation and reception of the Control (Pause
Command) frames by the MAC's Flow control module. A Write to a register with the Busy
bit set to '1' triggers the Flow Control block to generate a Pause Control frame. The fields
of the control frame are selected as specified in the 802.3x specification, and the Pause
Time value from this register is used in the Pause Time field of the control frame. The
Busy bit remains set until the control frame is transferred onto the cable. The CPU must
make sure that the Busy bit is cleared before writing to the register.
ETH0_FLOW_CONTROL
Flow Control Register (18H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PT
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Rese FCA
DZP
Reserved_15_8 rved PLT UP RFE TFE _BP
Q
_6 A
r rw r rw rw rw rw rw

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

FCA_BPA 0 rw Flow Control Busy or Backpressure Activate
This bit initiates a Pause Control frame in the full-duplex
mode and activates the backpressure function in the
half-duplex mode if the TFE bit is set.
In the full-duplex mode, this bit should be read as 0
before writing to the Flow Control register. To initiate a
Pause control frame, the Application must set this bit to
1. During a transfer of the Control Frame, this bit
continues to be set to signify that a frame transmission
is in progress. After the completion of Pause control
frame transmission, the MAC resets this bit to 1'b0. The
Flow Control register should not be written to until this bit
is cleared.
In the half-duplex mode, when this bit is set (and TFE is
set), then backpressure is asserted by the MAC. During
backpressure, when the MAC receives a new frame, the
transmitter starts sending a JAM pattern resulting in a
collision.When the MAC is configured for the full-duplex
mode, the BPA is automatically disabled.
TFE 1 rw Transmit Flow Control Enable
In the full-duplex mode, when this bit is set, the MAC
enables the flow control operation to transmit Pause
frames. When this bit is reset, the flow control operation
in the MAC is disabled, and the MAC does not transmit
any Pause frames.
In half-duplex mode, when this bit is set, the MAC
enables the back-pressure operation. When this bit is
reset, the back-pressure feature is disabled.
RFE 2 rw Receive Flow Control Enable
When this bit is set, the MAC decodes the received
Pause frame and disables its transmitter for a specified
(Pause) time. When this bit is reset, the decode function
of the Pause frame is disabled.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

UP 3 rw Unicast Pause Frame Detect
When this bit is set, then in addition to the detecting
Pause frames with the unique multicast address, the
MAC detects the Pause frames with the station's unicast
address specified in the MAC Address0 High Register
and MAC Address0 Low Register. When this bit is reset,
the MAC detects only a Pause frame with the unique
multicast address specified in the 802.3x standard.
PLT [5:4] rw Pause Low Threshold
This field configures the threshold of the PAUSE timer at
which the input flow control signal is checked for
automatic retransmission of PAUSE Frame.
The threshold values should be always less than the
Pause Time configured in Bits[31:16]. For example, if PT
= 100H (256 slot-times), and PLT = 01, then a second
PAUSE frame is automatically transmitted if the flow
control signal is asserted at 228 (256 - 28) slot times
after the first PAUSE frame is transmitted.
The following list provides the threshold values for
different values:
- 00B: The threshold is Pause time minus 4 slot times
(PT - 4 slot times).
The slot time is defined as the time taken to transmit 512
bits (64 bytes) on the MII interface.
6
DZPQ 7 rw Disable Zero-Quanta Pause
When this bit is set, it disables the automatic generation
of the Zero-Quanta Pause Control frames on the de-
assertion of the flow-control signal from the FIFO layer
When this bit is reset, normal operation with automatic
Zero-Quanta Pause Control frame generation is
enabled.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

15_8
PT [31:16] rw Pause Time
This field holds the value to be used in the Pause Time
field in the transmit control frame. If the Pause Time bits
is configured to be double-synchronized to the MII clock
domain, then consecutive writes to this register should
be performed only after at least four clock cycles in the
destination clock domain.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
VLAN_TAG
The VLAN Tag register contains the IEEE 802.1Q VLAN Tag to identify the VLAN
frames. The MAC compares the 13th and 14th bytes of the receiving frame
(Length/Type) with 8100H, and the following two bytes are compared with the VLAN tag.
If a match occurs, the MAC sets the received VLAN bit in the receive frame status. The
legal length of the frame is increased from 1,518 bytes to 1,522 bytes. If the VLAN Tag
register is configured to be double-synchronized to the MII clock domain, then
consecutive writes to these register should be performed only after at least four clock
cycles in the destination clock domain.
ETH0_VLAN_TAG
VLAN Tag Register (1CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
VTH ESV
Reserved_31_20 VTIM ETV
M L
r r rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VL
rw

VL [15:0] rw VLAN Tag Identifier for Receive Frames
This field contains the 802.1Q VLAN tag to identify the
VLAN frames and is compared to the 15th and 16th
bytes of the frames being received for VLAN frames.
The following list describes the bits of this field:
* Bits [15:13]: User Priority
* Bit 12: Canonical Format Indicator (CFI) or Drop
Eligible Indicator (DEI)
* Bits[11:0]: VLAN tag's VLAN Identifier (VID) field
When the ETV bit is set, only the VID (Bits[11:0]) is used
for comparison.
If VL (VL[11:0] if ETV is set) is all zeros, the MAC does
not check the fifteenth and 16th bytes for VLAN tag
comparison, and declares all frames with a Type field
value of 8100H or 88A8H as VLAN frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

ETV 16 rw Enable 12-Bit VLAN Tag Comparison
When this bit is set, a 12-bit VLAN identifier is used for
comparing and filtering instead of the complete 16-bit
VLAN tag. Bits 11-0 of VLAN tag are compared with the
corresponding field in the received VLAN-tagged frame.
Similarly, when enabled, only 12 bits of the VLAN tag in
the received frame are used for hash-based VLAN
filtering.
When this bit is reset, all 16 bits of the 15th and 16th
bytes of the received VLAN frame are used for
comparison and VLAN hash filtering.
VTIM 17 rw VLAN Tag Inverse Match Enable
When set, this bit enables the VLAN Tag inverse
matching. The frames that do not have matching VLAN
Tag are marked as matched.
When reset, this bit enables the VLAN Tag perfect
matching. The frames with matched VLAN Tag are
marked as matched.
ESVL 18 rw Enable S-VLAN
When this bit is set, the MAC transmitter and receiver
also consider the S-VLAN (Type = 88A8H) frames as
valid VLAN tagged frames.
VTHM 19 r VLAN Tag Hash Table Match Enable
When set, the most significant four bits of the VLAN tags
CRC are used to index the content of Register 354
[VLAN Hash Table Register]. A value of 1 in the VLAN
Hash Table register, corresponding to the index,
indicates that the frame matched the VLAN hash table.
When Bit 16 (ETV) is set, the CRC of the 12-bit VLAN
Identifier (VID) is used for comparison whereas when
ETV is reset, the CRC of the 16-bit VLAN tag is used for
comparison.
When reset, the VLAN Hash Match operation is not
performed.
31_20

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
VERSION
The VERSION registers identifies the version of the ETH. This register contains two
bytes: one that Synopsys uses to identify the core release number, and the other that
you set during core configuration.
ETH0_VERSION
Version Register (20H) Reset Value: 0000 1037H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_31_16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
USERVER SNPSVER
r r

SNPSVER [7:0] r Synopsys-defined Version (3.7)
USERVER [15:8] r User-defined Version (Configured with the
coreConsultant)
31_16

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
DEBUG
The DEBUG register gives the status of all main modules of the transmit and receive
data-paths and the FIFOs. An all-zero status indicates that the MAC is in idle state (and
FIFOs are empty) and no activity is going on in the data-paths.
ETH0_DEBUG
Debug Register (24H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXS Rese TXP
TXF TWC TPE
Reserved_31_26 TSF rved TRCSTS AUS TFCSTS
STS STS STS
STS _23 ED
r r r r r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Rese Rese
RWC RFCFCST RPE
Reserved_15_10 RXFSTS rved RRCSTS rved
STS S STS
_7 _3
r r r r r r r r

RPESTS 0 r MAC MII Receive Protocol Engine Status
When high, this bit indicates that the MAC MII receive
protocol engine is actively receiving data and not in IDLE
state.
RFCFCST [2:1] r MAC Receive Frame Controller FIFO Status
S When high, this field indicates the active state of the
small FIFO Read and Write controllers of the MAC
Receive Frame Controller Module.
3
RWCSTS 4 r MTL Rx FIFO Write Controller Active Status
When high, this bit indicates that the MTL Rx FIFO Write
Controller is active and is transferring a received frame
to the FIFO.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RRCSTS [6:5] r MTL Rx FIFO Read Controller State
This field gives the state of the Rx FIFO read Controller:
* 00B: IDLE state
* 01B: Reading frame data
* 10B: Reading frame status (or timestamp)
* 11B: Flushing the frame data and status
7
RXFSTS [9:8] r MTL Rx FIFO Fill-level Status
This field gives the status of the fill-level of the Rx FIFO:
* 00B: Rx FIFO Empty
* 01B: Rx FIFO fill level is below the flow-control
deactivate threshold
* 10B: Rx FIFO fill level is above the flow-control
activate threshold
* 11B: Rx FIFO Full
15_10
TPESTS 16 r MAC MII Transmit Protocol Engine Status
When high, this bit indicates that the MAC MII transmit
protocol engine is actively transmitting data and is not in
the IDLE state.
TFCSTS [18:17] r MAC Transmit Frame Controller Status
This field indicates the state of the MAC Transmit Frame
Controller module:
* 00B: IDLE state
* 01B: Waiting for Status of previous frame or IFG or
backoff period to be over
* 10B: Generating and transmitting a PAUSE control
frame (in the full-duplex mode)
* 11B: Transferring input frame for transmission
TXPAUSE 19 r MAC transmitter in PAUSE
D When high, this bit indicates that the MAC transmitter is
in the PAUSE condition (in the full-duplex only mode)
and hence does not schedule any frame for
transmission.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TRCSTS [21:20] r MTL Tx FIFO Read Controller Status
This field indicates the state of the Tx FIFO Read
Controller:
* 00B: IDLE state
* 01B: READ state (transferring data to MAC
transmitter)
* 10B: Waiting for TxStatus from MAC transmitter
* 11B: Writing the received TxStatus or flushing the Tx
FIFO
TWCSTS 22 r MTL Tx FIFO Write Controller Active Status
When high, this bit indicates that the MTL Tx FIFO Write
Controller is active and transferring data to the Tx FIFO.
23
TXFSTS 24 r MTL Tx FIFO Not Empty Status
When high, this bit indicates that the MTL Tx FIFO is not
empty and some data is left for transmission.
TXSTSFS 25 r MTL TxStatus FIFO Full Status
TS When high, this bit indicates that the MTL TxStatus FIFO
is full. Therefore, the MTL cannot accept any more
frames for transmission. This bit is reserved in the ETH-
AHB and ETH-DMA configurations.
31_26

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
REMOTE_WAKE_UP_FRAME_FILTER
This is the address through which the application writes or reads the remote wake-up
frame filter registers (wkupfmfilter_reg). The wkupfmfilter_reg register is a pointer to
eight wkupfmfilter_reg registers. The wkupfmfilter_reg register is loaded by sequentially
loading the eight register values. Eight sequential writes to this address (0028H) writes
all wkupfmfilter_reg registers. Similarly, eight sequential reads from this address
(0028H) read all wkupfmfilter_reg registers. This register contains the higher 16 bits of
the seventh MAC address.
ETH0_REMOTE_WAKE_UP_FRAME_FILTER
Remote Wake Up Frame Filter Register (28H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
WKUPFRMFTR
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
WKUPFRMFTR
rw

WKUPFR [31:0] rw Remote Wake-Up Frame Filter
MFTR

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
PMT_CONTROL_STATUS
ETH0_PMT_CONTROL_STATUS
PMT Control and Status Register (2CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RWK
FILT Reserved_30_10
RST
rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
GLB RWK MGK RWK MGK
Reserved_ Reserved_ PWR
Reserved_30_10 LUC PRC PRC PKT PKT
8_7 4_3 DWN
AST VD VD EN EN
r rw r r r r rw rw rw

PWRDWN 0 rw Power Down
When set, the MAC receiver drops all received frames
until it receives the expected magic packet or wake-up
frame. This bit is then self-cleared and the power-down
mode is disabled. The Software can also clear this bit
before the expected magic packet or wake-up frame is
received. The frames, received by the MAC after this bit
is cleared, are forwarded to the application. This bit must
only be set when the Magic Packet Enable, Global
Unicast, or Wake-Up Frame Enable bit is set high.
Note:
You can gate-off the CSR clock during the power-down
mode. However, when the CSR clock is gated-off, you
cannot perform any read or write operations on this
register. Therefore, the Software cannot clear this bit.
MGKPKTE 1 rw Magic Packet Enable
N When set, enables generation of a power management
event because of magic packet reception.
RWKPKTE 2 rw Wake-Up Frame Enable
N When set, enables generation of a power management
event because of wake-up frame reception.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

4_3
MGKPRC 5 r Magic Packet Received
VD When set, this bit indicates that the power management
event is generated because of the reception of a magic
packet. This bit is cleared by a Read into this register.
RWKPRC 6 r Wake-Up Frame Received
VD When set, this bit indicates the power management
event is generated because of the reception of a wake-
up frame. This bit is cleared by a Read into this register.
8_7
GLBLUCA 9 rw Global Unicast
ST When set, enables any unicast packet filtered by the
MAC (DAF) address recognition to be a wake-up frame.
30_10
RWKFILT 31 rw Wake-Up Frame Filter Register Pointer Reset
RST When set, resets the remote wake-up frame filter
register pointer to 000B. It is automatically cleared after
1 clock cycle.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
INTERRUPT_STATUS
The Interrupt Status register identifies the events in the MAC that can generate
interrupt.
ETH0_INTERRUPT_STATUS
Interrupt Register (38H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_31_11
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Rese Rese MMC
MMC MMC MMC PMTI
Reserved_31_11 rved TSIS rved RXIP Reserved_2_0
TXIS RXIS IS S
_10 _8 IS
r r r r r r r r r r

2_0
PMTIS 3 r PMT Interrupt Status
This bit is set when a Magic packet or Wake-on-LAN
frame is received in the power-down mode. This bit is
cleared when both
PMT_CONTROL_STATUS.MGKPRC
VD and PMT_CONTROL_STATUS.RWKPRCVD are
cleared because of a read operation to the PMT Control
and Status register.
MMCIS 4 r MMC Interrupt Status
This bit is set high when any of the Bits MMCRXIS,
MMCTXIS or MMCRXIPIS is set high and cleared only
when all of these bits are low.
MMCRXIS 5 r MMC Receive Interrupt Status
This bit is set high when an interrupt is generated in the
MMC Receive Interrupt Register. This bit is cleared
when all the bits in this interrupt register are cleared.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

MMCTXIS 6 r MMC Transmit Interrupt Status
This bit is set high when an interrupt is generated in the
MMC Transmit Interrupt Register. This bit is cleared
when all the bits in this interrupt register are cleared.
MMCRXIPI 7 r MMC Receive Checksum Offload Interrupt Status
S This bit is set high when an interrupt is generated in the
MMC Receive Checksum Offload Interrupt Register.
This bit is cleared when all the bits in this interrupt
register are cleared.
8
TSIS 9 r Timestamp Interrupt Status
When the Advanced Timestamp feature is enabled, this
bit is set when any of the following conditions is true:
* The system time value equals or exceeds the value
specified in the Target Time High and Low registers.
* There is an overflow in the seconds register.
This bit is cleared on reading Timestamp

STATUS.TSSOVF Register.
If default Timestamping is enabled, when set, this bit
indicates that the system time value is equal to or
exceeds the value specified in the Target Time registers.
In this mode, this bit is cleared after the completion of the
read of this bit. In all other modes, this bit is reserved.
10
31_11

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
INTERRUPT_MASK
The Interrupt Mask Register bits enable you to mask the interrupt signal because of the
corresponding event in the Interrupt Status Register.
ETH0_INTERRUPT_MASK
Interrupt Mask Register (3CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_31_10
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PMTI
Reserved_31_10 TSIM Reserved_8_4 Reserved_2_0
M
r rw r rw r

2_0
PMTIM 3 rw PMT Interrupt Mask
When set, this bit disables the assertion of the interrupt
signal because of the setting of PMT Interrupt Status bit
INTERRUPT_STATUS.PMTIS.
8_4
TSIM 9 rw Timestamp Interrupt Mask
When set, this bit disables the assertion of the interrupt
signal because of the setting of Timestamp Interrupt
Status bit INTERRUPT_STATUS.TSIS.
This bit is valid only when IEEE1588 timestamping is
enabled. In all other modes, this bit is reserved.
31_10

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MAC_ADDRESS0_HIGH
The MAC Address0 High register holds the upper 16 bits of the first 6-byte MAC
address of the station. The first DA byte that is received on the MII interface corresponds
to the LS byte (Bits [7:0]) of the MAC Address Low register. For example, if 1122 3344
5566H is received (11H in lane 0 of the first column) on the MII as the destination
address, then the MacAddress0 Register [47:0] is compared with 6655 4433 2211H. If
the MAC address registers are configured to be double-synchronized to the MII clock
domains, then the synchronization is triggered only when Bits[31:24] of the MAC
Address0 Low Register are written. For proper synchronization updates, the consecutive
writes to this Address Low Register should be performed after at least four clock cycles
in the destination clock domain.
ETH0_MAC_ADDRESS0_HIGH
MAC Address0 High Register (40H) Reset Value: 8000 FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
AE Reserved_30_16
r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADDRHI
rw

ADDRHI [15:0] rw MAC Address0 [47:32]
This field contains the upper 16 bits (47:32) of the first 6-
byte MAC address. The MAC uses this field for filtering
the received frames and inserting the MAC address in
the Transmit Flow Control (PAUSE) Frames.
30_16
AE 31 r Address Enable
This bit is always set to 1.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MAC_ADDRESS0_LOW
The MAC Address0 Low register holds the lower 32 bits of the first 6-byte MAC address
of the station.
ETH0_MAC_ADDRESS0_LOW
MAC Address0 Low Register (44H) Reset Value: FFFF FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ADDRLO
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADDRLO
rw

ADDRLO [31:0] rw MAC Address0 [31:0]
This field contains the lower 32 bits of the first 6-byte
MAC address. This is used by the MAC for filtering the
received frames and inserting the MAC address in the
Transmit Flow Control (PAUSE) Frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
32-bit Register - MAC_ADDRESS1_HIGH

The MAC Address1 High register holds the upper 16 bits of the second 6-byte MAC
address of the station. If the MAC address registers are configured to be double-
synchronized to the MII clock domains, then the synchronization is triggered only when
Bits[31:24] of the MAC Address1 Low Register are written. For proper synchronization
updates, the consecutive writes to this Address Low Register should be performed after
at least four clock cycles in the destination clock domain.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
AE SA MBC Reserved_23_16
rw rw rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADDRHI
rw

This field contains the upper 16 bits (47:32) of the
second 6-byte MAC address.
23_16

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

MBC [29:24] rw Mask Byte Control
These bits are mask control bits for comparison of each
of the MAC Address bytes. When set high, the MAC
does not compare the corresponding byte of received
DA or SA with the contents of MAC Address1 registers.
Each bit controls the masking of the bytes as follows:
* Bit 29: MAC_ADDRESS1_HIGH [15:8]
* Bit 27: MAC_ADDRESS1_LOW [31:24]
* ...
You can filter a group of addresses (known as group
address filtering) by masking one or more bytes of the
address.
SA 30 rw Source Address
When this bit is set, the MAC Address1[47:0] is used to
compare with the SA fields of the received frame.
When this bit is reset, the MAC Address1[47:0] is used
to compare with the DA fields of the received frame.
AE 31 rw Address Enable
When this bit is set, the address filter module uses the
second MAC address for perfect filtering.
When this bit is reset, the address filter module ignores
the address for filtering.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MAC_ADDRESS1_LOW
The MAC Address1 Low register holds the lower 32 bits of the second 6-byte MAC
address of the station.
MAC Address1 Low Register (4CH) Reset Value: FFFF FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ADDRLO
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADDRLO
rw

This field contains the lower 32 bits of the second 6-byte
MAC address. The content of this field is undefined until
loaded by the Application after the initialization process.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MAC_ADDRESS2_HIGH
The MAC Address2 High register holds the upper 16 bits of the third 6-byte MAC
Bits[31:24] (in little-endian mode) or Bits[7:0] (in big-endian mode) of the MAC Address2
Low Register are written. For proper synchronization updates, consecutive writes to this
MAC Address2 Low Register must be performed after at least four clock cycles in the
destination clock domain.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
rw rw rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADDRHI
rw

This field contains the upper 16 bits (47:32) of the third
6-byte MAC address.
23_16
* ...

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

third MAC address for perfect filtering.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MAC_ADDRESS2_LOW
The MAC Address2 Low register holds the lower 32 bits of the third 6-byte MAC address
of the station.
MAC Address2 Low Register (54H) Reset Value: FFFF FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ADDRLO
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADDRLO
rw

This field contains the lower 32 bits of the third 6-byte

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MAC_ADDRESS3_HIGH
The MAC Address3 High register holds the upper 16 bits of the fourth 6-byte MAC
Bits[31:24] of the MAC Address3 Low Register are written. For proper synchronization
updates, consecutive writes to this MAC Address3 Low Register must be performed after
at least four clock cycles in the destination clock domain.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
rw rw rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADDRHI
rw

This field contains the upper 16 bits (47:32) of the fourth
6-byte MAC address.
23_16
* ...

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

fourth MAC address for perfect filtering.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MAC_ADDRESS3_LOW
The MAC Address3 Low register holds the lower 32 bits of the fourth 6-byte MAC
address of the station.
MAC Address3 Low Register (5CH) Reset Value: FFFF FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ADDRLO
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADDRLO
rw

This field contains the lower 32 bits of the fourth 6-byte

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MMC_CONTROL
The MMC Control register establishes the operating mode of the management counters.
Note: The bit 0 (Counters Reset) has higher priority than bit 4 (Counter Preset).
Therefore, when the Software tries to set both bits in the same write cycle, all counters
are cleared and the bit 4 is not set.
ETH0_MMC_CONTROL
MMC Control Register (100H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_31_9
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CNT
CNT CNT RST CNT
UCD Reserved_ PRS CNT
Reserved_31_9 PRS FRE ONR STO
BC 7_6 TLV RST
T EZ D PRO
L
r rw r rw rw rw rw rw rw

CNTRST 0 rw Counters Reset
When this bit is set, all counters are reset. This bit is
cleared automatically after one clock cycle.
CNTSTOP 1 rw Counters Stop Rollover
RO When this bit is set, after reaching maximum value, the
counter does not roll over to zero.
RSTONRD 2 rw Reset on Read
When this bit is set, the MMC counters are reset to zero
after Read (self-clearing after reset). The counters are
cleared when the least significant byte lane (bits[7:0]) is
read.
CNTFREE 3 rw MMC Counter Freeze
Z When this bit is set, it freezes all MMC counters to their
current value. Until this bit is reset to 0, no MMC counter
is updated because of any transmitted or received
frame. If any MMC counter is read with the Reset on
Read bit set, then that counter is also cleared in this
mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

CNTPRST 4 rw Counters Preset
When this bit is set, all counters are initialized or preset
to almost full or almost half according to bit 5. This bit is
cleared automatically after 1 clock cycle. This bit, along
with bit 5, is useful for debugging and testing the
assertion of interrupts because of MMC counter
becoming half-full or full.
CNTPRST 5 rw Full-Half Preset
LVL When low and bit 4 is set, all MMC counters get preset
to almost-half value. All octet counters get preset to
7FFF F800H (half - 2KBytes) and all frame-counters
gets preset to 7FFF FFF0H (half - 16).
When this bit is high and bit 4 is set, all MMC counters
get preset to almost-full value. All octet counters get
preset to FFFF F800H (full - 2KBytes) and all frame-
counters gets preset to FFFF FFF0H (full - 16).
For 16-bit counters, the almost-half preset values are
7800H and 7FF0H for the respective octet and frame
counters. Similarly, the almost-full preset values for the
16-bit counters are F800H and FFF0H.
7_6
UCDBC 8 rw Update MMC Counters for Dropped Broadcast
Frames
When set, this bit enables MAC to update all the related
MMC Counters for Broadcast frames dropped due to
setting of MAC_Filter.DBF bit.
When reset, MMC Counters are not updated for dropped
Broadcast frames.
31_9

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MMC_RECEIVE_INTERRUPT
The MMC Receive Interrupt register maintains the interrupts that are generated when
the following happens: * Receive statistic counters reach half of their maximum values
(8000 0000H for 32-bit counter and 8000H for 16-bit counter). * Receive statistic
counters cross their maximum values (FFFF FFFFH for 32-bit counter and FFFFH for
16-bit counter). When the Counter Stop Rollover is set, then interrupts are set but the
counter remains at all-ones. The MMC Receive Interrupt register is a 32-bit wide register.
An interrupt bit is cleared when the respective MMC counter that caused the interrupt is
read. The least significant byte lane (Bits[7:0]) of the respective counter must be read in
order to clear the interrupt bit.
ETH0_MMC_RECEIVE_INTERRUPT
MMC Receive Interrupt Register (104H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RX1
RXR RXV RXO
RXC RXW RXF RXP RXL RXU 024T
CVE LAN RAN
Reserved_31_26 TRL DOG OVFI AUS ENE CGFI MAX
RRFI GBFI GEFI
FIS FIS S FIS RFIS S OCT
S S S GBFI
r r r r r r r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RX5 RX2 RX1 RX6
RX6 RXA
12T1 56T5 28T2 5T12 RXO RXU RXJ RXR RXC RXM RXB RXG RXG RXG
4OC LGN
023O 11O 55O 7OC SIZE SIZE ABE UNT RCE CGFI CGFI OCTI BOC BFR
TGB ERFI
CTG CTG CTG TGB GFIS GFIS RFIS FIS RFIS S S S TIS MIS
FIS S
BFIS BFIS BFIS FIS
r r r r r r r r r r r r r r r r

RXGBFRM 0 r MMC Receive Good Bad Frame Counter Interrupt
IS Status
This bit is set when the rxframecount_bg counter
reaches half of the maximum value or the maximum
value.
RXGBOCT 1 r MMC Receive Good Bad Octet Counter Interrupt
IS Status
This bit is set when the rxoctetcount_bg counter reaches
half of the maximum value or the maximum value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXGOCTI 2 r MMC Receive Good Octet Counter Interrupt Status.
S This bit is set when the RX_OCTET_COUNT_GOOD
counter reaches half of the maximum value or the
maximum value.
RXBCGFI 3 r MMC Receive Broadcast Good Frame Counter
S Interrupt Status.
This bit is set when the
RX_BROADCAST_FRAMES_GOOD counter reaches
RXMCGFI 4 r MMC Receive Multicast Good Frame Counter
S Interrupt Status
RX_MULTICAST_FRAMES_GOOD counter reaches
RXCRCER 5 r MMC Receive CRC Error Frame Counter Interrupt
FIS Status
This bit is set when the RX_CRC_ERROR_FRAMES
maximum value.
RXALGNE 6 r MMC Receive Alignment Error Frame Counter
RFIS Interrupt Status
RX_ALIGNMENT_ERROR_FRAMES counter reaches
RXRUNTFI 7 r MMC Receive Runt Frame Counter Interrupt Status
S This bit is set when the RX_RUNT_ERROR_FRAMES
maximum value.
RXJABER 8 r MMC Receive Jabber Error Frame Counter Interrupt
FIS Status
RX_JABBER_ERROR_FRAMES counter reaches half
of the maximum value or the maximum value.
RXUSIZE 9 r MMC Receive Undersize Good Frame Counter
GFIS Interrupt Status
RX_UNDERSIZE_FRAMES_GOOD counter reaches

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXOSIZE 10 r MMC Receive Oversize Good Frame Counter
GFIS Interrupt Status
RX_OVERSIZE_FRAMES_GOOD counter reaches half
RX64OCT 11 r MMC Receive 64 Octet Good Bad Frame Counter
GBFIS Interrupt Status
RX_64OCTETS_FRAMES_GOOD_BAD counter
value.
RX65T127 12 r MMC Receive 65 to 127 Octet Good Bad Frame
OCTGBFI Counter Interrupt Status
S This is set when the
RX_65TO127OCTETS_FRAMES_GOOD_BAD
maximum value.
5OCTGBFI Counter Interrupt Status
S This bit is set when the
maximum value.
maximum value.
23OCTGB Counter Interrupt Status
FIS This bit is set when the
maximum value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RX1024TM 16 r MMC Receive 1024 to Maximum Octet Good Bad
AXOCTGB Frame Counter Interrupt Status
RX_1024TOMAXOCTETS_FRAMES_GOOD_BAD
maximum value.
RXUCGFI 17 r MMC Receive Unicast Good Frame Counter
S Interrupt Status
This bit is set when the rxunicastframes_gb counter
value.
RXLENER 18 r MMC Receive Length Error Frame Counter Interrupt
FIS Status
RX_LENGTH_ERROR_FRAMES counter reaches half
RXORAN 19 r MMC Receive Out Of Range Error Frame Counter
GEFIS Interrupt Status
RX_OUT_OF_RANGE_TYPE_FRAMES counter
value.
RXPAUSFI 20 r MMC Receive Pause Frame Counter Interrupt Status
S This bit is set when the rxpauseframe counter reaches
RXFOVFIS 21 r MMC Receive FIFO Overflow Frame Counter
Interrupt Status
RX_FIFO_OVERFLOW_FRAMES counter reaches half
RXVLANG 22 r MMC Receive VLAN Good Bad Frame Counter
BFIS Interrupt Status
RX_VLAN_FRAMES_GOOD_BAD counter reaches

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXWDOG 23 r MMC Receive Watchdog Error Frame Counter
FIS Interrupt Status
RX_WATCHDOG_ERROR_FRAMES counter reaches
RXRCVER 24 r MMC Receive Error Frame Counter Interrupt Status
RFIS This bit is set when the rxrcverror counter reaches half
RXCTRLFI 25 r MMC Receive Control Frame Counter Interrupt
S Status
This bit is set when the rxctrlframes_g counter reaches
31_26

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MMC_TRANSMIT_INTERRUPT
The MMC Transmit Interrupt register maintains the interrupts generated when transmit
statistic counters reach half of their maximum values (8000 0000H for 32-bit counter and
8000H for 16-bit counter), and the maximum values (FFFF FFFFH for 32-bit counter and
FFFFH for 16-bit counter). When Counter Stop Rollover is set, then interrupts are set but
the counter remains at all-ones. The MMC Transmit Interrupt register is a 32-bit wide
register. An interrupt bit is cleared when the respective MMC counter that caused the
interrupt is read. The least significant byte lane (Bits[7:0]) of the respective counter must
be read in order to clear the interrupt bit.
ETH0_MMC_TRANSMIT_INTERRUPT
MMC Transmit Interrupt Register (108H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXL
TXO TXV TXP TXE TXG TXG TXC TXE TXD
ATC
Reserved_31_26 SIZE LAN AUS XDE FRMI OCTI ARE XCO EFFI
OLFI
GFIS GFIS FIS FFIS S S RFIS LFIS S
S
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TX10 TX51 TX25 TX12 TX65
TXU TX64
TXM TXS TXB TXM TXU 24T 2T10 6T51 8T25 T127 TXM TXB TXG TXG
FLO OCT
COL COL CGB CGB CGB MAX 23O 1OC 5OC OCT CGFI CGFI BFR BOC
WER GBFI
GFIS GFIS FIS FIS FIS OCT CTG TGB TGB GBFI S S MIS TIS
FIS S
GBFI BFIS FIS FIS S

TXGBOCT 0 r MMC Transmit Good Bad Octet Counter Interrupt
IS Status
TX_OCTET_COUNT_GOOD_BAD counter reaches
TXGBFRM 1 r MMC Transmit Good Bad Frame Counter Interrupt
IS Status
TX_FRAME_COUNT_GOOD_BAD counter reaches

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TXBCGFIS 2 r MMC Transmit Broadcast Good Frame Counter
Interrupt Status
TX_BROADCAST_FRAMES_GOOD counter reaches
TXMCGFI 3 r MMC Transmit Multicast Good Frame Counter
S Interrupt Status
TX_MULTICAST_FRAMES_GOOD counter reaches
TX64OCT 4 r MMC Transmit 64 Octet Good Bad Frame Counter
GBFIS Interrupt Status.
TX_64OCTETS_FRAMES_GOOD_BAD counter
value.
TX65T127 5 r MMC Transmit 65 to 127 Octet Good Bad Frame
OCTGBFI Counter Interrupt Status
TX_65TO127OCTETS_FRAMES_GOOD_BAD
maximum value.
maximum value.
maximum value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

23OCTGB Counter Interrupt Status
maximum value.
TX1024TM 9 r MMC Transmit 1024 to Maximum Octet Good Bad
AXOCTGB Frame Counter Interrupt Status
TX_1024TOMAXOCTETS_FRAMES_GOOD_BAD
maximum value.
TXUCGBF 10 r MMC Transmit Unicast Good Bad Frame Counter
IS Interrupt Status
TX_UNICAST_FRAMES_GOOD_BAD counter reaches
TXMCGBF 11 r MMC Transmit Multicast Good Bad Frame Counter
IS Interrupt Status
TX_MULTICAST_FRAMES_GOOD_BAD counter
value.
TXBCGBF 12 r MMC Transmit Broadcast Good Bad Frame Counter
IS Interrupt Status
TX_BROADCAST_FRAMES_GOOD_BAD counter
value.
TXUFLOW 13 r MMC Transmit Underflow Error Frame Counter
ERFIS Interrupt Status
TX_UNDERFLOW_ERROR_FRAMES counter reaches

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TXSCOLG 14 r MMC Transmit Single Collision Good Frame Counter
TX_SINGLE_COLLISION_GOOD_FRAMES counter
value.
TXMCOLG 15 r MMC Transmit Multiple Collision Good Frame
FIS Counter Interrupt Status
TX_MULTIPLE_COLLISION_GOOD_FRAMES counter
value.
TXDEFFIS 16 r MMC Transmit Deferred Frame Counter Interrupt
Status
This bit is set when the TX_DEFERRED_FRAMES
maximum value.
TXLATCO 17 r MMC Transmit Late Collision Frame Counter
LFIS Interrupt Status
TX_LATE_COLLISION_FRAMES counter reaches half
TXEXCOL 18 r MMC Transmit Excessive Collision Frame Counter
This bit is set when the txexcesscol counter reaches half
TXCARER 19 r MMC Transmit Carrier Error Frame Counter Interrupt
FIS Status
TX_CARRIER_ERROR_FRAMES counter reaches half
TXGOCTI 20 r MMC Transmit Good Octet Counter Interrupt Status
S This bit is set when the TX_OCTET_COUNT_GOOD
maximum value.
TXGFRMI 21 r MMC Transmit Good Frame Counter Interrupt Status
S This bit is set when the TX_FRAME_COUNT_GOOD
maximum value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TXEXDEF 22 r MMC Transmit Excessive Deferral Frame Counter
TX_EXCESSIVE_DEFERRAL_ERROR counter
value.
TXPAUSFI 23 r MMC Transmit Pause Frame Counter Interrupt
S Status
This bit is set when the txpauseframeserror counter
value.
TXVLANG 24 r MMC Transmit VLAN Good Frame Counter Interrupt
FIS Status
This bit is set when the TX_VLAN_FRAMES_GOOD
maximum value.
TXOSIZEG 25 r MMC Transmit Oversize Good Frame Counter
This bit is set when the txoversize_g counter reaches
31_26

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MMC_RECEIVE_INTERRUPT_MASK
ETH0_MMC_RECEIVE_INTERRUPT_MASK
MMC Reveive Interrupt Mask Register (10CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RX1
RXR RXV RXO
RXC RXW RXF RXP RXL RXU 024T
CVE LAN RAN
Reserved_31_26 TRL DOG OVFI AUS ENE CGFI MAX
RRFI GBFI GEFI
FIM FIM M FIM RFIM M OCT
M M M
GBFI
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RX5 RX2 RX1 RX6
RX6 RXO RXU RXA
12T1 56T5 28T2 5T12 RXJ RXR RXC RXM RXB RXG RXG RXG
4OC SIZE SIZE LGN
023O 11O 55O 7OC ABE UNT RCE CGFI CGFI OCTI BOC BFR
TGB GFI GFI ERFI
CTG CTG CTG TGB RFIM FIM RFIM M M M TIM MIM
FIM M M M
BFIM BFIM BFIM FIM
rw rw rw rw rw rw rw rw rw rw rw rw rw rw rw rw

RXGBFRM 0 rw MMC Receive Good Bad Frame Counter Interrupt
IM Mask
Setting this bit masks the interrupt when the
RX_FRAMES_COUNT_GOOD_BAD counter reaches
RXGBOCT 1 rw MMC Receive Good Bad Octet Counter Interrupt
IM Mask
RX_OCTET_COUNT_GOOD_BAD counter reaches
RXGOCTI 2 rw MMC Receive Good Octet Counter Interrupt Mask
M Setting this bit masks the interrupt when the
RX_OCTET_COUNT_GOOD counter reaches half of
the maximum value or the maximum value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXBCGFI 3 rw MMC Receive Broadcast Good Frame Counter
M Interrupt Mask
RX_BROADCAST_FRAMES_GOOD counter reaches
RXMCGFI 4 rw MMC Receive Multicast Good Frame Counter
M Interrupt Mask
RX_MULTICAST_FRAMES_GOOD counter reaches
RXCRCER 5 rw MMC Receive CRC Error Frame Counter Interrupt
FIM Mask
RX_CRC_ERROR_FRAMES counter reaches half of
RXALGNE 6 rw MMC Receive Alignment Error Frame Counter
RFIM Interrupt Mask
RX_ALIGNMENT_ERROR_FRAMES counter reaches
RXRUNTFI 7 rw MMC Receive Runt Frame Counter Interrupt Mask
RX_RUNT_ERROR_FRAMES counter reaches half of
RXJABER 8 rw MMC Receive Jabber Error Frame Counter Interrupt
FIM Mask
RX_JABBER_ERROR_FRAMES counter reaches half
RXUSIZE 9 rw MMC Receive Undersize Good Frame Counter
GFIM Interrupt Mask
RX_UNDERSIZE_FRAMES_GOOD counter reaches
RXOSIZE 10 rw MMC Receive Oversize Good Frame Counter
GFIM Interrupt Mask
RX_OVERSIZE_FRAMES_GOOD counter reaches half

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RX64OCT 11 rw MMC Receive 64 Octet Good Bad Frame Counter
GBFIM Interrupt Mask
RX_64OCTETS_FRAMES_GOOD_BAD counter
value.
RX65T127 12 rw MMC Receive 65 to 127 Octet Good Bad Frame
OCTGBFI Counter Interrupt Mask
maximum value.
5OCTGBFI Counter Interrupt Mask
maximum value.
maximum value.
23OCTGB Counter Interrupt Mask
FIM Setting this bit masks the interrupt when the
maximum value.
RX1024TM 16 rw MMC Receive 1024 to Maximum Octet Good Bad
AXOCTGB Frame Counter Interrupt Mask
maximum value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXUCGFI 17 rw MMC Receive Unicast Good Frame Counter
M Interrupt Mask
RX_UNICAST_FRAMES_GOOD counter reaches half
RXLENER 18 rw MMC Receive Length Error Frame Counter Interrupt
FIM Mask
RX_LENGTH_ERROR_FRAMES counter reaches half
RXORAN 19 rw MMC Receive Out Of Range Error Frame Counter
GEFIM Interrupt Mask
RX_OUT_OF_RANGE_TYPE_FRAMES counter
value.
RXPAUSFI 20 rw MMC Receive Pause Frame Counter Interrupt Mask
RX_PAUSE_FRAMES counter reaches half of the
maximum value or the maximum value.
RXFOVFI 21 rw MMC Receive FIFO Overflow Frame Counter
M Interrupt Mask
RX_FIFO_OVERFLOW_FRAMES counter reaches half
RXVLANG 22 rw MMC Receive VLAN Good Bad Frame Counter
BFIM Interrupt Mask
RX_VLAN_FRAMES_GOOD_BAD counter reaches
RXWDOG 23 rw MMC Receive Watchdog Error Frame Counter
FIM Interrupt Mask
Setting this bit masks the interrupt when the rxwatchdog
maximum value.
RXRCVER 24 rw MMC Receive Error Frame Counter Interrupt Mask
RFIM Setting this bit masks the interrupt when the rxrcverror
error counter reaches half the maximum value, and also
when it reaches the maximum value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXCTRLFI 25 rw MMC Receive Control Frame Counter Interrupt Mask
M Setting this bit masks the interrupt when the rxctrlframes
counter reaches half the maximum value, and also when
it reaches the maximum value.
31_26

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MMC_TRANSMIT_INTERRUPT_MASK
The MMC Transmit Interrupt Mask register maintains the masks for the interrupts
generated when the transmit statistic counters reach half of their maximum value or
maximum value. This register is 32-bits wide.
ETH0_MMC_TRANSMIT_INTERRUPT_MASK
MMC Transmit Interrupt Mask Register (110H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXO TXV TXL
TXP TXE TXG TXG TXC TXE TXD
SIZE LAN ATC
Reserved_31_26 AUS XDE FRMI OCTI ARE XCO EFFI
GFI GFI OLFI
FIM FFIM M M RFIM LFIM M
M M M
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TX10 TX51 TX25 TX12 TX65
TXM TXS TXU TX64
TXB TXM TXU 24T 2T10 6T51 8T25 T127 TXM TXB TXG TXG
COL COL FLO OCT
CGB CGB CGB MAX 23O 1OC 5OC OCT CGFI CGFI BFR BOC
GFI GFI WER GBFI
FIM FIM FIM OCT CTG TGB TGB GBFI M M MIM TIM
M M FIM GBFI BFIM FIM M
FIM M

TXGBOCT 0 rw MMC Transmit Good Bad Octet Counter Interrupt
IM Mask
TX_OCTET_COUNT_GOOD_BAD counter reaches
TXGBFRM 1 rw MMC Transmit Good Bad Frame Counter Interrupt
IM Mask
TX_FRAME_COUNT_GOOD_BAD counter reaches
TXBCGFI 2 rw MMC Transmit Broadcast Good Frame Counter
M Interrupt Mask
TX_BROADCAST_FRAMES_GOOD counter reaches

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TXMCGFI 3 rw MMC Transmit Multicast Good Frame Counter
M Interrupt Mask
TX_MULTICAST_FRAMES_GOOD counter reaches
TX64OCT 4 rw MMC Transmit 64 Octet Good Bad Frame Counter
GBFIM Interrupt Mask
TX_64OCTETS_FRAMES_GOOD_BAD counter
value.
TX65T127 5 rw MMC Transmit 65 to 127 Octet Good Bad Frame
OCTGBFI Counter Interrupt Mask
maximum value.
maximum value.
maximum value.
23OCTGB Counter Interrupt Mask
maximum value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TX1024TM 9 rw MMC Transmit 1024 to Maximum Octet Good Bad
AXOCTGB Frame Counter Interrupt Mask
maximum value.
TXUCGBF 10 rw MMC Transmit Unicast Good Bad Frame Counter
IM Interrupt Mask
TX_UNICAST_FRAMES_GOOD_BAD counter reaches
TXMCGBF 11 rw MMC Transmit Multicast Good Bad Frame Counter
IM Interrupt Mask
TX_MULTICAST_FRAMES_GOOD_BAD counter
value.
TXBCGBF 12 rw MMC Transmit Broadcast Good Bad Frame Counter
IM Interrupt Mask
TX_BROADCAST_FRAMES_GOOD_BAD counter
value.
TXUFLOW 13 rw MMC Transmit Underflow Error Frame Counter
ERFIM Interrupt Mask
TX_UNDERFLOW_ERROR_FRAMES counter reaches
TXSCOLG 14 rw MMC Transmit Single Collision Good Frame Counter
FIM Interrupt Mask
TX_SINGLE_COLLISION_GOOD_FRAMES counter
value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TXMCOLG 15 rw MMC Transmit Multiple Collision Good Frame
FIM Counter Interrupt Mask
TX_MULTIPLE_COLLISION_GOOD_FRAMES counter
value.
TXDEFFIM 16 rw MMC Transmit Deferred Frame Counter Interrupt
Mask
TX_DEFERRED_FRAMES counter reaches half of the
TXLATCO 17 rw MMC Transmit Late Collision Frame Counter
LFIM Interrupt Mask
TX_LATE_COLLISION_FRAMES counter reaches half
TXEXCOL 18 rw MMC Transmit Excessive Collision Frame Counter
FIM Interrupt Mask
Setting this bit masks the interrupt when the txexcesscol
maximum value.
TXCARER 19 rw MMC Transmit Carrier Error Frame Counter Interrupt
FIM Mask
TX_CARRIER_ERROR_FRAMES counter reaches half
TXGOCTI 20 rw MMC Transmit Good Octet Counter Interrupt Mask
TX_OCTET_COUNT_GOOD counter reaches half of
TXGFRMI 21 rw MMC Transmit Good Frame Counter Interrupt Mask
TX_FRAME_COUNT_GOOD counter reaches half of

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TXEXDEF 22 rw MMC Transmit Excessive Deferral Frame Counter
FIM Interrupt Mask
TX_EXCESSIVE_DEFERRAL_ERROR counter
value.
TXPAUSFI 23 rw MMC Transmit Pause Frame Counter Interrupt Mask
TX_PAUSE_FRAMES counter reaches half of the
TXVLANG 24 rw MMC Transmit VLAN Good Frame Counter Interrupt
FIM Mask
TX_VLAN_FRAMES_GOOD counter reaches half of
TXOSIZEG 25 rw MMC Transmit Oversize Good Frame Counter
FIM Interrupt Mask
txoversize_g counter reaches half of the maximum value
or the maximum value.
31_26

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_OCTET_COUNT_GOOD_BAD
This register maintains the number of bytes transmitted in good and bad frames
exclusive of preamble and retried bytes.
ETH0_TX_OCTET_COUNT_GOOD_BAD
Transmit Octet Count for Good and Bad Frames Register (114H) Reset Value:
0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXOCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXOCTGB

TXOCTGB [31:0] r This field indicates the number of bytes transmitted
in good and bad frames exclusive of preamble and
retried bytes.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_FRAME_COUNT_GOOD_BAD
This register maintains the number of good and bad frames transmitted, exclusive of
retried frames.
ETH0_TX_FRAME_COUNT_GOOD_BAD
Transmit Frame Count for Goodand Bad Frames Register (118H) Reset Value:
0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXFRMGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXFRMGB

TXFRMGB [31:0] r This field indicates the number of good and bad
frames transmitted, exclusive of retried frames

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_BROADCAST_FRAMES_GOOD
This register maintains the number of transmitted good broadcast frames.
ETH0_TX_BROADCAST_FRAMES_GOOD
Transmit Frame Count for Good Broadcast Frames (11CH) Reset Value: 0000
0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXBCASTG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXBCASTG

TXBCAST [31:0] r This field indicates the number of transmitted good
G broadcast frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_MULTICAST_FRAMES_GOOD
This register maintains the number of transmitted good multicast frames.
ETH0_TX_MULTICAST_FRAMES_GOOD
Transmit Frame Count for Good Multicast Frames (120H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXMCASTG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXMCASTG

TXMCAST [31:0] r This field indicates the number of transmitted good
G multicast frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_64OCTETS_FRAMES_GOOD_BAD
This register maintains the number of transmitted good and bad frames with length of
64 bytes, exclusive of preamble and retried frames.
ETH0_TX_64OCTETS_FRAMES_GOOD_BAD
Transmit Octet Count for Good and Bad 64 Byte Frames (124H) Reset Value: 0000
0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TX64OCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TX64OCTGB

TX64OCT [31:0] r This field indicates the number of transmitted good
GB and bad frames with length of 64 bytes, exclusive of
preamble and retried frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
This register maintains the number of transmitted good and bad frames with length
between 65 and 127 (inclusive) bytes, exclusive of preamble and retried frames.
ETH0_TX_65TO127OCTETS_FRAMES_GOOD_BAD
Transmit Octet Count for Good and Bad 65 to 127 Bytes Frames ( 128H)Reset
Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TX65_127OCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TX65_127OCTGB

TX65_127 [31:0] r This field indicates the number of transmitted good
OCTGB and bad frames with length between 65 and 127
(inclusive) bytes, exclusive of preamble and retried
frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Transmit Octet Count for Good and Bad 128 to 255 Bytes Frames (12CH) Reset
Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TX128_255OCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TX128_255OCTGB

5OCTGB and bad frames with length between 128 and 255
frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Transmit Octet Count for Good and Bad 256 to 511 Bytes Frames(130H) Reset
Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TX256_511OCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TX256_511OCTGB

1OCTGB and bad frames with length between 256 and 511
frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
between 512 and 1,023 (inclusive) bytes, exclusive of preamble and retried frames.
Transmit Octet Count for Good and Bad 512 to 1023 Bytes Frames(134H) Reset
Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TX512_1023OCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TX512_1023OCTGB

23OCTGB and bad frames with length between 512 and 1,023
frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
between 1,024 and maxsize (inclusive) bytes, exclusive of preamble and retried frames.
ETH0_TX_1024TOMAXOCTETS_FRAMES_GOOD_BAD
Transmit Octet Count for Good and Bad 1024 to Maxsize Bytes Frames(138H)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TX1024_MAXOCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TX1024_MAXOCTGB

TX1024_M [31:0] r This field indicates the number of good and bad
AXOCTGB frames transmitted with length between 1,024 and
maxsize (inclusive) bytes, exclusive of preamble
and retried frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_UNICAST_FRAMES_GOOD_BAD
This register maintains the number of transmitted good and bad unicast frames.
ETH0_TX_UNICAST_FRAMES_GOOD_BAD
Transmit Frame Count for Good and Bad Unicast Frames (13CH) Reset Value:
0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXUCASTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXUCASTGB

TXUCAST [31:0] r This field indicates the number of transmitted good
GB and bad unicast frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_MULTICAST_FRAMES_GOOD_BAD
This register maintains the number of transmitted good and bad multicast frames.
ETH0_TX_MULTICAST_FRAMES_GOOD_BAD
Transmit Frame Count for Good and Bad Multicast Frames(140H) Reset Value:
0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXMCASTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXMCASTGB

TXMCAST [31:0] r This field indicates the number of transmitted good
GB and bad multicast frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_BROADCAST_FRAMES_GOOD_BAD
This register maintains the number of transmitted good and bad broadcast frames.
ETH0_TX_BROADCAST_FRAMES_GOOD_BAD
Transmit Frame Count for Good and Bad Broadcast Frames(144H) Reset Value:
0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXBCASTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXBCASTGB

TXBCAST [31:0] r This field indicates the number of transmitted good
GB and bad broadcast frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_UNDERFLOW_ERROR_FRAMES
This register maintains the number of frames aborted because of frame underflow error.
ETH0_TX_UNDERFLOW_ERROR_FRAMES
Transmit Frame Count for Underflow Error Frames (148H) Reset Value: 0000
0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXUNDRFLW
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXUNDRFLW

TXUNDRF [31:0] r This field indicates the number of frames aborted
LW because of frame underflow error.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_SINGLE_COLLISION_GOOD_FRAMES
This register maintains the number of successfully transmitted frames after a single
collision in the half-duplex mode.
ETH0_TX_SINGLE_COLLISION_GOOD_FRAMES
Transmit Frame Count for Frames Transmitted after Single Collision(14CH) Reset
Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXSNGLCOLG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXSNGLCOLG

TXSNGLC [31:0] r This field indicates the number of successfully
OLG transmitted frames after a single collision in the
half-duplex mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_MULTIPLE_COLLISION_GOOD_FRAMES
This register maintains the number of successfully transmitted frames after multiple
collisions in the half-duplex mode.
ETH0_TX_MULTIPLE_COLLISION_GOOD_FRAMES
Transmit Frame Count for Frames Transmitted after Multiple Collision(150H)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXMULTCOLG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXMULTCOLG

TXMULTC [31:0] r This field indicates the number of successfully
OLG transmitted frames after multiple collisions in the
half-duplex mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_DEFERRED_FRAMES
This register maintains the number of successfully transmitted frames after a deferral in
the half-duplex mode.
ETH0_TX_DEFERRED_FRAMES
Tx Deferred Frames Register (154H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXDEFRD
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXDEFRD

TXDEFRD [31:0] r This field indicates the number of successfully
transmitted frames after a deferral in the half-duplex
mode.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_LATE_COLLISION_FRAMES
This register maintains the number of frames aborted because of late collision error.
ETH0_TX_LATE_COLLISION_FRAMES
Transmit Frame Count for Late Collision Error Frames(158H) Reset Value: 0000
0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXLATECOL
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXLATECOL

TXLATEC [31:0] r This field indicates the number of frames aborted
OL because of late collision error.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_EXCESSIVE_COLLISION_FRAMES
This register maintains the number of frames aborted because of excessive (16)
collision error.
ETH0_TX_EXCESSIVE_COLLISION_FRAMES
Transmit Frame Count for Excessive Collision Error Frames(15CH) Reset Value:
0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXEXSCOL
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXEXSCOL

TXEXSCO [31:0] r This field indicates the number of frames aborted
L because of excessive (16) collision error.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_CARRIER_ERROR_FRAMES
This register maintains the number of frames aborted because of carrier sense error (no
carrier or loss of carrier).
ETH0_TX_CARRIER_ERROR_FRAMES
Transmit Frame Count for Carrier Sense Error Frames(160H) Reset Value: 0000
0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXCARR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXCARR

TXCARR [31:0] r This field indicates the number of frames aborted
because of carrier sense error (no carrier or loss of
carrier).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_OCTET_COUNT_GOOD
This register maintains the number of bytes transmitted, exclusive of preamble, in good
frames.
ETH0_TX_OCTET_COUNT_GOOD
Tx Octet Count Good Register (164H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXOCTG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXOCTG

TXOCTG [31:0] r This field indicates the number of bytes transmitted,
exclusive of preamble, in good frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_FRAME_COUNT_GOOD
This register maintains the number of transmitted good frames, exclusive of preamble.
ETH0_TX_FRAME_COUNT_GOOD
Tx Frame Count Good Register (168H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXFRMG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXFRMG

TXFRMG [31:0] r This field indicates the number of transmitted good
frames, exclusive of preamble.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_EXCESSIVE_DEFERRAL_ERROR
This register maintains the number of frames aborted because of excessive deferral
error, that is, frames deferred for more than two max-sized frame times.
ETH0_TX_EXCESSIVE_DEFERRAL_ERROR
Transmit Frame Count for Excessive Deferral Error Frames(16CH) Reset Value:
0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXEXSDEF
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXEXSDEF

TXEXSDE [31:0] r This field indicates the number of frames aborted
F because of excessive deferral error, that is, frames
deferred for more than two max-sized frame times.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_PAUSE_FRAMES
This register maintains the number of transmitted good PAUSE frames.
ETH0_TX_PAUSE_FRAMES
Transmit Frame Count for Good PAUSE Frames(170H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXPAUSE
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXPAUSE

TXPAUSE [31:0] r This field indicates the number of transmitted good
PAUSE frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_VLAN_FRAMES_GOOD
This register maintains the number of transmitted good VLAN frames, exclusive of
retried frames.
ETH0_TX_VLAN_FRAMES_GOOD
Transmit Frame Count for Good VLAN Frames(174H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXVLANG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXVLANG

TXVLANG [31:0] r This register maintains the number of transmitted
good VLAN frames, exclusive of retried frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TX_OSIZE_FRAMES_GOOD
This register maintains the number of transmitted good Oversize frames, exclusive of
retried frames.
ETH0_TX_OSIZE_FRAMES_GOOD
Transmit Frame Count for Good Oversize Frames(178H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TXOSIZG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TXOSIZG

TXOSIZG [31:0] r This field indicates the number of frames
transmitted without errors and with length greater
than the maxsize (1,518 or 1,522 bytes for VLAN
tagged frames; 2000 bytes if enabled by setting MAC
Configuration.2KPE).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_FRAMES_COUNT_GOOD_BAD
This register maintains the number of received good and bad frames.
ETH0_RX_FRAMES_COUNT_GOOD_BAD
Receive Frame Count for Good and Bad Frames(180H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXFRMGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXFRMGB

RXFRMGB [31:0] r This field indicates the number of received good and
bad frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_OCTET_COUNT_GOOD_BAD
This register maintains the number of bytes received, exclusive of preamble, in good
and bad frames.
ETH0_RX_OCTET_COUNT_GOOD_BAD
Receive Octet Count for Good and Bad Frames(184H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXOCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXOCTGB

RXOCTGB [31:0] r This field indicates the number of bytes received,
exclusive of preamble, in good and bad frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_OCTET_COUNT_GOOD
This register maintains the number of bytes received, exclusive of preamble, only in
good frames.
ETH0_RX_OCTET_COUNT_GOOD
Rx Octet Count Good Register (188H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXOCTG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXOCTG

RXOCTG [31:0] r This field indicates the number of bytes received,
exclusive of preamble, only in good frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_BROADCAST_FRAMES_GOOD
This register maintains the number of received good broadcast frames.
ETH0_RX_BROADCAST_FRAMES_GOOD
Receive Frame Count for Good Broadcast Frames(18CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXBCASTG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXBCASTG

RXBCAST [31:0] r This field indicates the number of received good
G broadcast frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_MULTICAST_FRAMES_GOOD
This register maintains the number of received good multicast frames.
ETH0_RX_MULTICAST_FRAMES_GOOD
Receive Frame Count for Good Multicast Frames(190H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXMCASTG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXMCASTG

RXMCAST [31:0] r This field indicates the number of received good
G multicast frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_CRC_ERROR_FRAMES
This register maintains the number of frames received with CRC error.
ETH0_RX_CRC_ERROR_FRAMES
Receive Frame Count for CRC Error Frames(194H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXCRCERR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXCRCERR

RXCRCER [31:0] r This field indicates the number of frames received
R with CRC error.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_ALIGNMENT_ERROR_FRAMES
This register maintains the number of frames received with alignment (dribble) error.
ETH0_RX_ALIGNMENT_ERROR_FRAMES
Receive Frame Count for Alignment Error Frames(198H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXALGNERR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXALGNERR

RXALGNE [31:0] r This field indicates the number of frames received
RR with alignment (dribble) error.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_RUNT_ERROR_FRAMES
This register maintains the number of frames received with runt error(<64 bytes and
CRC error).
ETH0_RX_RUNT_ERROR_FRAMES
Receive Frame Count for Runt Error Frames(19CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXRUNTERR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXRUNTERR

RXRUNTE [31:0] r This field indicates the number of frames received
RR with runt error(<64 bytes and CRC error).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_JABBER_ERROR_FRAMES
This register maintains the number of giant frames received with length (including CRC)
greater than 1,518 bytes (1,522 bytes for VLAN tagged) and with CRC error. If Jumbo
Frame mode is enabled, then frames of length greater than 9,018 bytes (9,022 for VLAN
tagged) are considered as giant frames.
ETH0_RX_JABBER_ERROR_FRAMES
Receive Frame Count for Jabber Error Frames(1A0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXJABERR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXJABERR

RXJABER [31:0] r This field indicates the number of giant frames
R received with length (including CRC) greater than
1,518 bytes (1,522 bytes for VLAN tagged) and with
CRC error. If Jumbo Frame mode is enabled, then
frames of length greater than 9,018 bytes (9,022 for
VLAN tagged) are considered as giant frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_UNDERSIZE_FRAMES_GOOD
This register maintains the number of frames received with length less than 64 bytes
and without errors.
ETH0_RX_UNDERSIZE_FRAMES_GOOD
Receive Frame Count for Undersize Frames(1A4H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXUNDERSZG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXUNDERSZG

RXUNDER [31:0] r This field indicates the number of frames received
SZG with length less than 64 bytes and without errors.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_OVERSIZE_FRAMES_GOOD
This register maintains the number of frames received with length greater than the
maxsize (1,518 or 1,522 for VLAN tagged frames) and without errors.
ETH0_RX_OVERSIZE_FRAMES_GOOD
Rx Oversize Frames Good Register (1A8H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXOVERSZG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXOVERSZG

RXOVERS [31:0] r This field indicates the number of frames received
ZG without errors, with length greater than the maxsize
(1,518 or 1,522 for VLAN tagged frames; 2,000 bytes
if enabled by setting MAC Configuration.2KPE).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_64OCTETS_FRAMES_GOOD_BAD
This register maintains the number of received good and bad frames with length 64
bytes, exclusive of preamble.
ETH0_RX_64OCTETS_FRAMES_GOOD_BAD
Receive Frame Count for Good and Bad 64 Byte Frames(1ACH) Reset Value: 0000
0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RX64OCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RX64OCTGB

RX64OCT [31:0] r This field indicates the number of received good and
GB bad frames with length 64 bytes, exclusive of
preamble.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
This register maintains the number of received good and bad frames received with
length between 65 and 127 (inclusive) bytes, exclusive of preamble.
ETH0_RX_65TO127OCTETS_FRAMES_GOOD_BAD
Receive Frame Count for Good and Bad 65 to 127 Bytes Frames(1B0H) Reset
Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RX65_127OCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RX65_127OCTGB

RX65_127 [31:0] r This field indicates the number of received good and
OCTGB bad frames received with length between 65 and 127
(inclusive) bytes, exclusive of preamble.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
This register maintains the number of received good and bad frames with length
between 128 and 255 (inclusive) bytes, exclusive of preamble.
Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RX128_255OCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RX128_255OCTGB

5OCTGB bad frames with length between 128 and 255

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
between 256 and 511 (inclusive) bytes, exclusive of preamble.
Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RX256_511OCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RX256_511OCTGB

1OCTGB bad frames with length between 256 and 511

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
between 512 and 1,023 (inclusive) bytes, exclusive of preamble.
Receive Frame Count for Good and Bad 512 to 1,023 Bytes Frames(1BCH) Reset
Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RX512_1023OCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RX512_1023OCTGB

23OCTGB bad frames with length between 512 and 1,023

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
between 1,024 and maxsize (inclusive) bytes, exclusive of preamble.
ETH0_RX_1024TOMAXOCTETS_FRAMES_GOOD_BAD
Receive Frame Count for Good and Bad 1,024 to Maxsize Bytes Frames(1C0H)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RX1024_MAXOCTGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RX1024_MAXOCTGB

RX1024_M [31:0] r This field indicates the number of received good and
AXOCTGB bad frames with length between 1,024 and maxsize
frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_UNICAST_FRAMES_GOOD
This register maintains the number of received good unicast frames.
ETH0_RX_UNICAST_FRAMES_GOOD
Receive Frame Count for Good Unicast Frames(1C4H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXUCASTG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXUCASTG

RXUCAST [31:0] r This field indicates the number of received good
G unicast frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_LENGTH_ERROR_FRAMES
This register maintains the number of frames received with length error (Length type
field not equal to frame size) for all frames with valid length field.
ETH0_RX_LENGTH_ERROR_FRAMES
Receive Frame Count for Length Error Frames(1C8H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXLENERR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXLENERR

RXLENER [31:0] r This field indicates the number of frames received
R with length error (Length type field not equal to
frame size) for all frames with valid length field.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_OUT_OF_RANGE_TYPE_FRAMES
This register maintains the number of received frames with length field not equal to the
valid frame size (greater than 1,500 but less than 1,536).
ETH0_RX_OUT_OF_RANGE_TYPE_FRAMES
Receive Frame Count for Out of Range Frames(1CCH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXOUTOFRNG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXOUTOFRNG

RXOUTOF [31:0] r This field indicates the number of received frames
RNG with length field not equal to the valid frame size
(greater than 1,500 but less than 1,536).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_PAUSE_FRAMES
This register maintains the number of received good and valid PAUSE frames.
ETH0_RX_PAUSE_FRAMES
Receive Frame Count for PAUSE Frames(1D0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXPAUSEFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXPAUSEFRM

RXPAUSE [31:0] r This field indicates the number of received good and
FRM valid PAUSE frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_FIFO_OVERFLOW_FRAMES
This register maintains the number of received frames missed because of FIFO
overflow.
ETH0_RX_FIFO_OVERFLOW_FRAMES
Receive Frame Count for FIFO Overflow Frames(1D4H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXFIFOOVFL
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXFIFOOVFL

RXFIFOO [31:0] r This field indicates the number of received frames
VFL missed because of FIFO overflow.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_VLAN_FRAMES_GOOD_BAD
This register maintains the number of received good and bad VLAN frames.
ETH0_RX_VLAN_FRAMES_GOOD_BAD
Receive Frame Count for Good and Bad VLAN Frames(1D8H) Reset Value: 0000
0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXVLANFRGB
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXVLANFRGB

RXVLANF [31:0] r This field indicates the number of received good and
RGB bad VLAN frames.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_WATCHDOG_ERROR_FRAMES
This register maintains the number of frames received with error because of the
watchdog timeout error (frames with more than 2,048 bytes data load).
ETH0_RX_WATCHDOG_ERROR_FRAMES
Receive Frame Count for Watchdog Error Frames(1DCH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXWDGERR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXWDGERR

RXWDGE [31:0] r This field indicates the number of frames received
RR with error because of the watchdog timeout error
(frames with more than 2,048 bytes data load).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_RECEIVE_ERROR_FRAMES
This register maintains the number of frames received with error because of the MII
RXER error.
ETH0_RX_RECEIVE_ERROR_FRAMES
Receive Frame Count for Receive Error Frames(1E0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXRCVERR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXRCVERR

RXRCVER [31:0] r This field indicates the number of frames received
R with error because of the watchdog timeout error

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RX_CONTROL_FRAMES_GOOD
This register maintains the number of godd control frames received.
ETH0_RX_CONTROL_FRAMES_GOOD
Receive Frame Count for Good Control Frames Frames(1E4H) Reset Value: 0000
0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXCTRLG
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXCTRLG

RXCTRLG [31:0] r This field indicates the number of frames received
with error because of the watchdog timeout error

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MMC_IPC_RECEIVE_INTERRUPT_MASK
This register maintains the mask for the interrupt generated from the receive IPC
statistic counters. This register is 32-bits wide.
ETH0_MMC_IPC_RECEIVE_INTERRUPT_MASK
MMC Receive Checksum Offload Interrupt Mask Register(200H) Reset Value: 0000
0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIP RXIP RXIP
RXIC RXT RXU RXIP RXIP RXIP
RXIC RXT RXU V6N RXIP V4U V4N RXIP
Reserved_ MPE CPE DPE V6H V4F V4H
MPG CPG DPG OPA V6G DSB OPA V4G
31_30 ROI ROI ROI EROI RAG EROI
OIM OIM OIM YOI OIM LOI YOI OIM
M M M M OIM M
M M M
r rw rw rw rw rw rw rw rw rw rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIP RXIP RXIP RXIP RXIP RXIP
RXIC RXIC RXT RXT RXU RXU RXIP RXIP
Reserved_ V6N V6H V4U V4F V4N V4H
MPE MPG CPE CPG DPE DPG V6G V4G
15_14 OPA ERFI DSB RAG OPA ERFI
RFIM FIM RFIM FIM RFIM FIM FIM FIM
YFIM M LFIM FIM YFIM M
r rw rw rw rw rw rw rw rw rw rw rw rw rw rw

RXIPV4GF 0 rw MMC Receive IPV4 Good Frame Counter Interrupt
IM Mask
RXIPV4_GOOD_FRAMES counter reaches half of the
RXIPV4HE 1 rw MMC Receive IPV4 Header Error Frame Counter
RFIM Interrupt Mask
RXIPV4_HEADER_ERROR_FRAMES counter reaches
RXIPV4NO 2 rw MMC Receive IPV4 No Payload Frame Counter
PAYFIM Interrupt Mask
RXIPV4_NO_PAYLOAD_FRAMES counter reaches

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXIPV4FR 3 rw MMC Receive IPV4 Fragmented Frame Counter
AGFIM Interrupt Mask
RXIPV4_FRAGMENTED_FRAMES counter reaches
RXIPV4UD 4 rw MMC Receive IPV4 UDP Checksum Disabled Frame
SBLFIM Counter Interrupt Mask
RXIPV4_UDP_CHECKSUM_DISABLED_FRAMES
maximum value.
RXIPV6GF 5 rw MMC Receive IPV6 Good Frame Counter Interrupt
IM Mask
RXIPV6_GOOD_FRAMES counter reaches half of the
RXIPV6HE 6 rw MMC Receive IPV6 Header Error Frame Counter
RFIM Interrupt Mask
RXIPV6NO 7 rw MMC Receive IPV6 No Payload Frame Counter
PAYFIM Interrupt Mask
RXUDPGF 8 rw MMC Receive UDP Good Frame Counter Interrupt
IM Mask
RXUDP_GOOD_FRAMES counter reaches half of the
RXUDPER 9 rw MMC Receive UDP Error Frame Counter Interrupt
FIM Mask
RXUDP_ERROR_FRAMES counter reaches half of the

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXTCPGFI 10 rw MMC Receive TCP Good Frame Counter Interrupt
M Mask
RXTCP_GOOD_FRAMES counter reaches half of the
RXTCPER 11 rw MMC Receive TCP Error Frame Counter Interrupt
FIM Mask
RXTCP_ERROR_FRAMES counter reaches half of the
RXICMPG 12 rw MMC Receive ICMP Good Frame Counter Interrupt
FIM Mask
RXICMP_GOOD_FRAMES counter reaches half of the
RXICMPE 13 rw MMC Receive ICMP Error Frame Counter Interrupt
RFIM Mask
RXICMP_ERROR_FRAMES counter reaches half of
15_14
RXIPV4G 16 rw MMC Receive IPV4 Good Octet Counter Interrupt
OIM Mask
RXIPV4_GOOD_OCTETS counter reaches half of the
RXIPV4HE 17 rw MMC Receive IPV4 Header Error Octet Counter
ROIM Interrupt Mask
RXIPV4_HEADER_ERROR_OCTETS counter reaches
RXIPV4NO 18 rw MMC Receive IPV4 No Payload Octet Counter
PAYOIM Interrupt Mask
RXIPV4_NO_PAYLOAD_OCTETS counter reaches

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXIPV4FR 19 rw MMC Receive IPV4 Fragmented Octet Counter
AGOIM Interrupt Mask
RXIPV4_FRAGMENTED_OCTETS counter reaches
RXIPV4UD 20 rw MMC Receive IPV4 UDP Checksum Disabled Octet
SBLOIM Counter Interrupt Mask
RXIPV4_UDP_CHECKSUM_DISABLE_OCTETS
maximum value.
RXIPV6G 21 rw MMC Receive IPV6 Good Octet Counter Interrupt
OIM Mask
RXIPV6_GOOD_OCTETS counter reaches half of the
RXIPV6HE 22 rw MMC Receive IPV6 Header Error Octet Counter
ROIM Interrupt Mask
Setting this bit masks interrupt when the
RXIPV6NO 23 rw MMC Receive IPV6 No Payload Octet Counter
PAYOIM Interrupt Mask
RXUDPGO 24 rw MMC Receive UDP Good Octet Counter Interrupt
IM Mask
RXUDP_GOOD_OCTETS counter reaches half of the
RXUDPER 25 rw MMC Receive UDP Error Octet Counter Interrupt
OIM Mask
RXUDP_ERROR_OCTETS counter reaches half of the

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXTCPGO 26 rw MMC Receive TCP Good Octet Counter Interrupt
IM Mask
RXTCP_GOOD_OCTETS counter reaches half of the
RXTCPER 27 rw MMC Receive TCP Error Octet Counter Interrupt
OIM Mask
RXTCP_ERROR_OCTETS counter reaches half of the
RXICMPG 28 rw MMC Receive ICMP Good Octet Counter Interrupt
OIM Mask
RXICMP_GOOD_OCTETS counter reaches half of the
RXICMPE 29 rw MMC Receive ICMP Error Octet Counter Interrupt
ROIM Mask
RXICMP_ERROR_OCTETS counter reaches half of the
31_30

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MMC_IPC_RECEIVE_INTERRUPT
This register maintains the interrupt that the receive IPC statistic counters generate.
ETH0_MMC_IPC_RECEIVE_INTERRUPT
MMC Receive Checksum Offload Interrupt Register(208H)Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
31_30 OPA EROI DSB RAG OPA EROI
ROIS OIS ROIS OIS ROIS OIS OIS OIS
YOIS S LOIS OIS YOIS S
r r r r r r r r r r r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
15_14 OPA ERFI DSB RAG OPA ERFI
RFIS FIS RFIS FIS RFIS FIS FIS FIS
YFIS S LFIS FIS YFIS S
r r r r r r r r r r r r r r r

RXIPV4GF 0 r MMC Receive IPV4 Good Frame Counter Interrupt
IS Status
This bit is set when the RXIPV4_GOOD_FRAMES
maximum value.
RXIPV4HE 1 r MMC Receive IPV4 Header Error Frame Counter
RXIPV4NO 2 r MMC Receive IPV4 No Payload Frame Counter
PAYFIS Interrupt Status
RXIPV4FR 3 r MMC Receive IPV4 Fragmented Frame Counter
AGFIS Interrupt Status
RXIPV4_FRAGMENTED_FRAMES counter reaches

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXIPV4UD 4 r MMC Receive IPV4 UDP Checksum Disabled Frame
SBLFIS Counter Interrupt Status
maximum value.
RXIPV6GF 5 r MMC Receive IPV6 Good Frame Counter Interrupt
IS Status
This bit is set when the RXIPV6_GOOD_FRAMES
maximum value.
RXIPV6HE 6 r MMC Receive IPV6 Header Error Frame Counter
RXIPV6NO 7 r MMC Receive IPV6 No Payload Frame Counter
PAYFIS Interrupt Status
RXUDPGF 8 r MMC Receive UDP Good Frame Counter Interrupt
IS Status
This bit is set when the RXUDP_GOOD_FRAMES
maximum value.
RXUDPER 9 r MMC Receive UDP Error Frame Counter Interrupt
FIS Status
This bit is set when the RXUDP_ERROR_FRAMES
maximum value.
RXTCPGFI 10 r MMC Receive TCP Good Frame Counter Interrupt
S Status
This bit is set when the RXTCP_GOOD_FRAMES
maximum value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXTCPER 11 r MMC Receive TCP Error Frame Counter Interrupt
FIS Status
This bit is set when the RXTCP_ERROR_FRAMES
maximum value.
RXICMPG 12 r MMC Receive ICMP Good Frame Counter Interrupt
FIS Status
This bit is set when the RXICMP_GOOD_FRAMES
maximum value.
RXICMPE 13 r MMC Receive ICMP Error Frame Counter Interrupt
RFIS Status
This bit is set when the RXICMP_ERROR_FRAMES
maximum value.
15_14
RXIPV4G 16 r MMC Receive IPV4 Good Octet Counter Interrupt
OIS Status
This bit is set when the RXIPV4_GOOD_OCTETS
maximum value.
RXIPV4HE 17 r MMC Receive IPV4 Header Error Octet Counter
ROIS Interrupt Status
RXIPV4NO 18 r MMC Receive IPV4 No Payload Octet Counter
PAYOIS Interrupt Status
RXIPV4FR 19 r MMC Receive IPV4 Fragmented Octet Counter
AGOIS Interrupt Status
RXIPV4_FRAGMENTED_OCTETS counter reaches

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXIPV4UD 20 r MMC Receive IPV4 UDP Checksum Disabled Octet
SBLOIS Counter Interrupt Status
maximum value.
RXIPV6G 21 r MMC Receive IPV6 Good Octet Counter Interrupt
OIS Status
This bit is set when the RXIPV6_GOOD_OCTETS
maximum value.
RXIPV6HE 22 r MMC Receive IPV6 Header Error Octet Counter
ROIS Interrupt Status
RXIPV6NO 23 r MMC Receive IPV6 No Payload Octet Counter
PAYOIS Interrupt Status
RXUDPGO 24 r MMC Receive UDP Good Octet Counter Interrupt
IS Status
This bit is set when the RXUDP_GOOD_OCTETS
maximum value.
RXUDPER 25 r MMC Receive UDP Error Octet Counter Interrupt
OIS Status
This bit is set when the RXUDP_ERROR_OCTETS
counter reaches half the maximum value or the
maximum value.
RXTCPGO 26 r MMC Receive TCP Good Octet Counter Interrupt
IS Status
This bit is set when the RXTCP_GOOD_OCTETS
counter reaches half the maximum value or the
maximum value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RXTCPER 27 r MMC Receive TCP Error Octet Counter Interrupt
OIS Status
This bit is set when the RXTCP_ERROR_OCTETS
maximum value.
RXICMPG 28 r MMC Receive ICMP Good Octet Counter Interrupt
OIS Status
This bit is set when the RXICMP_GOOD_OCTETS
maximum value.
RXICMPE 29 r MMC Receive ICMP Error Octet Counter Interrupt
ROIS Status
This bit is set when the RXICMP_ERROR_OCTETS
maximum value.
31_30

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV4_GOOD_FRAMES
This register maintains the number of good IPv4 datagrams received with the TCP,
UDP, or ICMP payload.
ETH0_RXIPV4_GOOD_FRAMES
RxIPv4 Good Frames Register (210H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV4GDFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV4GDFRM

RXIPV4GD [31:0] r This field indicates the number of good IPv4
FRM datagrams received with the TCP, UDP, or ICMP
payload.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV4_HEADER_ERROR_FRAMES
This register maintains the number of IPv4 datagrams received with header errors
(checksum, length, or version mismatch).
ETH0_RXIPV4_HEADER_ERROR_FRAMES
Receive IPV4 Header Error Frame Counter Register(214H)Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV4HDRERRFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV4HDRERRFRM

RXIPV4HD [31:0] r This field indicates the number of IPv4 datagrams
RERRFRM received with header errors (checksum, length, or
version mismatch).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV4_NO_PAYLOAD_FRAMES
This register maintains the number of received IPv4 datagram frames without a TCP,
UDP, or ICMP payload processed by the Checksum engine.
ETH0_RXIPV4_NO_PAYLOAD_FRAMES
Receive IPV4 No Payload Frame Counter Register(218H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV4NOPAYFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV4NOPAYFRM

RXIPV4NO [31:0] r This field indicates the number of IPv4 datagram
PAYFRM frames received that did not have a TCP, UDP, or
ICMP payload processed by the Checksum engine.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV4_FRAGMENTED_FRAMES
This register maintains the number of good IPv4 datagrams received with
fragmentation.
ETH0_RXIPV4_FRAGMENTED_FRAMES
Receive IPV4 Fragmented Frame Counter Register(21CH)Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV4FRAGFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV4FRAGFRM

RXIPV4FR [31:0] r This field indicates the number of good IPv4
AGFRM datagrams received with fragmentation.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
This register maintains the number of received good IPv4 datagrams which have the
UDP payload with checksum disabled.
ETH0_RXIPV4_UDP_CHECKSUM_DISABLED_FRAMES
Receive IPV4 UDP Checksum Disabled Frame Counter Register(220H) Reset
Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV4UDSBLFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV4UDSBLFRM

RXIPV4UD [31:0] r This field indicates the number of received good
SBLFRM IPv4 datagrams which have the UDP payload with
checksum disabled.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV6_GOOD_FRAMES
This register maintains the number of good IPv6 datagrams received with TCP, UDP,
or ICMP payloads.
ETH0_RXIPV6_GOOD_FRAMES
RxIPv6 Good Frames Register (224H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV6GDFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV6GDFRM

RXIPV6GD [31:0] r This field indicates the number of good IPv6
FRM datagrams received with TCP, UDP, or ICMP
payloads.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV6_HEADER_ERROR_FRAMES
This register maintains the number of IPv6 datagrams received with header errors
(length or version mismatch).
ETH0_RXIPV6_HEADER_ERROR_FRAMES
Receive IPV6 Header Error Frame Counter Register(228H)Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV6HDRERRFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV6HDRERRFRM

RXIPV6HD [31:0] r This field indicates the number of IPv6 datagrams
RERRFRM received with header errors (length or version
mismatch).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV6_NO_PAYLOAD_FRAMES
This register maintains the number of received IPv6 datagram frames without a TCP,
UDP, or ICMP payload. This includes all IPv6 datagrams with fragmentation or security
extension headers.
ETH0_RXIPV6_NO_PAYLOAD_FRAMES
Receive IPV6 No Payload Frame Counter Register(22CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV6NOPAYFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV6NOPAYFRM

RXIPV6NO [31:0] r This field indicates the number of IPv6 datagram
PAYFRM frames received that did not have a TCP, UDP, or
ICMP payload. This includes all IPv6 datagrams with
fragmentation or security extension headers.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXUDP_GOOD_FRAMES
This register maintains the number of good IP datagrams with a good UDP payload. This
counter is not updated when the counter is incremented.
ETH0_RXUDP_GOOD_FRAMES
RxUDP Good Frames Register (230H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXUDPGDFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXUDPGDFRM

RXUDPGD [31:0] r This field indicates the number of good IP
FRM datagrams with a good UDP payload. This counter is
not updated when the counter is incremented.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXUDP_ERROR_FRAMES
This register maintains the number of good IP datagrams whose UDP payload has a
checksum error.
ETH0_RXUDP_ERROR_FRAMES
RxUDP Error Frames Register (234H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXUDPERRFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXUDPERRFRM

RXUDPER [31:0] r This field indicates the number of good IP
RFRM datagrams whose UDP payload has a checksum
error.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXTCP_GOOD_FRAMES
This register maintains the number of good IP datagrams with a good TCP payload.
ETH0_RXTCP_GOOD_FRAMES
RxTCP Good Frames Register (238H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXTCPGDFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXTCPGDFRM

RXTCPGD [31:0] r This field indicates the number of good IP
FRM datagrams with a good TCP payload.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXTCP_ERROR_FRAMES
This register maintains the number of good IP datagrams whose TCP payload has a
checksum error.
ETH0_RXTCP_ERROR_FRAMES
RxTCP Error Frames Register (23CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXTCPERRFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXTCPERRFRM

RXTCPER [31:0] r This field indicates the number of good IP
RFRM datagrams whose TCP payload has a checksum
error.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXICMP_GOOD_FRAMES
This register maintains the number of good IP datagrams with a good ICMP payload.
ETH0_RXICMP_GOOD_FRAMES
RxICMP Good Frames Register (240H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXICMPGDFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXICMPGDFRM

RXICMPG [31:0] r This field indicates the number of good IP
DFRM datagrams with a good ICMP payload.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXICMP_ERROR_FRAMES
This register maintains the number of good IP datagrams whose ICMP payload has a
checksum error.
ETH0_RXICMP_ERROR_FRAMES
RxICMP Error Frames Register (244H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXICMPERRFRM
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXICMPERRFRM

RXICMPE [31:0] r This field indicates the number of good IP
RRFRM datagrams whose ICMP payload has a checksum
error.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV4_GOOD_OCTETS
This register maintains the number of bytes received in good IPv4 datagrams
encapsulating TCP, UDP, or ICMP data.
ETH0_RXIPV4_GOOD_OCTETS
RxIPv4 Good Octets Register (250H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV4GDOCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV4GDOCT

RXIPV4GD [31:0] r This field indicates the number of bytes received in
OCT good IPv4 datagrams encapsulating TCP, UDP, or
ICMP data. The Ethernet header, FCS, pad, or IP pad
bytes are not included in this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV4_HEADER_ERROR_OCTETS
This register maintains the number of bytes received in IPv4 datagrams with header
errors (checksum, length, or version mismatch). The value in the Length field of the IPv4
header is used to update this counter.
ETH0_RXIPV4_HEADER_ERROR_OCTETS
Receive IPV4 Header Error Octet Counter Register(254H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV4HDRERROCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV4HDRERROCT

RXIPV4HD [31:0] r This field indicates the number of bytes received in
RERROCT the IPv4 datagrams with header errors (checksum,
length, or version mismatch). The value in the
Length field of IPv4 header is used to update this
counter.
The Ethernet header, FCS, pad, or IP pad bytes are not
included in this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV4_NO_PAYLOAD_OCTETS
This register maintains the number of bytes received in IPv4 datagrams that did not have
a TCP, UDP, or ICMP payload. The value in the IPv4 headers Length field is used to
ETH0_RXIPV4_NO_PAYLOAD_OCTETS
Receive IPV4 No Payload Octet Counter Register(258H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV4NOPAYOCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV4NOPAYOCT

RXIPV4NO [31:0] r This field indicates the number of bytes received in
PAYOCT IPv4 datagrams that did not have a TCP, UDP, or
ICMP payload. The value in the IPv4 headers Length
field is used to update this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV4_FRAGMENTED_OCTETS
This register maintains the number of bytes received in fragmented IPv4 datagrams.
The value in the IPv4 headers Length field is used to update this counter.
ETH0_RXIPV4_FRAGMENTED_OCTETS
Receive IPV4 Fragmented Octet Counter Register(25CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV4FRAGOCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV4FRAGOCT

RXIPV4FR [31:0] r This field indicates the number of bytes received in
AGOCT fragmented IPv4 datagrams. The value in the IPv4
headers Length field is used to update this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
This register maintains the number of bytes received in a UDP segment that had the
UDP checksum disabled.
ETH0_RXIPV4_UDP_CHECKSUM_DISABLE_OCTETS
Receive IPV4 Fragmented Octet Counter Register(260H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV4UDSBLOCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV4UDSBLOCT

RXIPV4UD [31:0] r This field indicates the number of bytes received in
SBLOCT a UDP segment that had the UDP checksum
disabled. This counter does not count the IP Header
bytes. The Ethernet header, FCS, pad, or IP pad
bytes are not included in this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV6_GOOD_OCTETS
This register maintains the number of bytes received in good IPv6 datagrams
encapsulating TCP, UDP or ICMPv6 data.
ETH0_RXIPV6_GOOD_OCTETS
RxIPv6 Good Octets Register (264H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV6GDOCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV6GDOCT

RXIPV6GD [31:0] r Thsi field indicates the number of bytes received in
OCT good IPv6 datagrams encapsulating TCP, UDP or
ICMPv6 data.
This counter does not count the IP Header bytes. The
Ethernet header, FCS, pad, or IP pad bytes are not

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV6_HEADER_ERROR_OCTETS
This register maintains the number of bytes received in IPv6 datagrams with header
errors (length or version mismatch).
ETH0_RXIPV6_HEADER_ERROR_OCTETS
Receive IPV6 Header Error Octet Counter Register(268H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV6HDRERROCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV6HDRERROCT

RXIPV6HD [31:0] r This field indicates the number of bytes received in
RERROCT IPv6 datagrams with header errors (length or
version mismatch). The value in the IPv6 headers
Length field is used to update this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXIPV6_NO_PAYLOAD_OCTETS
This register maintains the number of bytes received in IPv6 datagrams that did not have
a TCP, UDP, or ICMP payload.
ETH0_RXIPV6_NO_PAYLOAD_OCTETS
Receive IPV6 No Payload Octet Counter Register(26CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXIPV6NOPAYOCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXIPV6NOPAYOCT

RXIPV6NO [31:0] r This field indicates the number of bytes received in
PAYOCT IPv6 datagrams that did not have a TCP, UDP, or
ICMP payload. The value in the IPv6 headers Length
field is used to update this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXUDP_GOOD_OCTETS
This register maintains the number of bytes received in a good UDP segment.
ETH0_RXUDP_GOOD_OCTETS
Receive UDP Good Octets Register (270H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXUDPGDOCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXUDPGDOCT

RXUDPGD [31:0] r This field indicates the number of bytes received in
OCT a good UDP segment. This counter does not count
IP header bytes. The Ethernet header, FCS, pad, or
IP pad bytes are not included in this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXUDP_ERROR_OCTETS
This register maintains the number of bytes received in a UDP segment with checksum
errors.
ETH0_RXUDP_ERROR_OCTETS
Receive UDP Error Octets Register (274H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXUDPERROCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXUDPERROCT

RXUDPER [31:0] r This field indicates the number of bytes received in
ROCT a UDP segment with checksum errors. This counter
does not count the IP Header bytes. The Ethernet
header, FCS, pad, or IP pad bytes are not included in
this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXTCP_GOOD_OCTETS
This register maintains the number of bytes received in a good TCP segment.
ETH0_RXTCP_GOOD_OCTETS
Receive TCP Good Octets Register (278H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXTCPGDOCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXTCPGDOCT

RXTCPGD [31:0] r This field indicates the number of bytes received in
OCT a good TCP segment. This counter does not count
the IP Header bytes. The Ethernet header, FCS, pad,
or IP pad bytes are not included in this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXTCP_ERROR_OCTETS
This register maintains the number of bytes received in a TCP segment with checksum
errors.
ETH0_RXTCP_ERROR_OCTETS
Receive TCP Error Octets Register (27CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXTCPERROCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXTCPERROCT

RXTCPER [31:0] r Thsi field indicates the number of bytes received in
ROCT a TCP segment with checksum errors. This counter
does not count the IP Header bytes. The Ethernet
header, FCS, pad, or IP pad bytes are not included in
this counter.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXICMP_GOOD_OCTETS
This register maintains the number of bytes received in a good ICMP segment.
ETH0_RXICMP_GOOD_OCTETS
Receive ICMP Good Octets Register (280H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXICMPGDOCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXICMPGDOCT

RXICMPG [31:0] r This field indicates the number of bytes received in
DOCT a good ICMP segment. This counter does not count
the IP Header bytes. The Ethernet header, FCS, pad,

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RXICMP_ERROR_OCTETS
This register maintains the number of bytes received in a ICMP segment with checksum
errors. This counter does not count the IP Header bytes. The Ethernet header, FCS, pad,
ETH0_RXICMP_ERROR_OCTETS
Receive ICMP Error Octets Register (284H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RXICMPERROCT
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RXICMPERROCT

RXICMPE [31:0] r Number of bytes received in an ICMP segment with
RROCT checksum errors

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TIMESTAMP_CONTROL
This register controls the operation of the System Time generator and the processing of
PTP packets for timestamping in the Receiver. Note: * Bits[19:8] are reserved and read-
only when Advanced Timestamp feature is not enabled.
ETH0_TIMESTAMP_CONTROL
Timestamp Control Register (700H) Reset Value: 0000 2000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TSE
NMA SNAPTYP
Reserved_23_19
CAD SEL
DR
r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TSM TSE TSIP TSIP TSV TSC TSE TSA TSC
TSIP Reserved_ TST TSU TSIN TSE
STR VNT V4E V6E ER2 TRL NAL DDR FUP
ENA 7_6 RIG PDT IT NA
ENA ENA NA NA ENA SSR L EG DT
rw rw rw rw rw rw rw rw r rw rw rw rw rw rw

TSENA 0 rw Timestamp Enable
When set, the timestamp is added for the transmit and
receive frames. When disabled, timestamp is not added
for the transmit and receive frames and the Timestamp
Generator is also suspended. You need to initialize the
Timestamp (system time) after enabling this mode.
On the receive side, the MAC processes the 1588
frames only if this bit is set.
TSCFUPD 1 rw Timestamp Fine or Coarse Update
T When set, this bit indicates that the system times update
should be done using the fine update method. When
reset, it indicates the system timestamp update should
be done using the Coarse method.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TSINIT 2 rw Timestamp Initialize
When set, the system time is initialized (overwritten) with
the value specified in the
SYSTEM_TIME_SECONDS_UPDATE Register and
SYSTEM_TIME_NANOSECONDS_UPDATE Register.
This bit should be read zero before updating it. This bit
is reset when the initialization is complete.
TSUPDT 3 rw Timestamp Update
When set, the system time is updated (added or
subtracted) with the value specified in System
Time_Seconds_Update Register and
SYSTEM_TIME_NANOSECONDS_UPDATE Register.
This bit should be read zero before updating it. This bit
is reset when the update is completed in hardware.
TSTRIG 4 rw Timestamp Interrupt Trigger Enable
When set, the timestamp interrupt is generated when
the System Time becomes greater than the value written
in the Target Time register. This bit is reset after the
generation of the Timestamp Trigger Interrupt.
TSADDRE 5 rw Addend Reg Update
G When set, the content of the TIMESTAMP_ADDEND
register is updated in the PTP block for fine correction.
This is cleared when the update is completed. This
register bit should be zero before setting it.
7_6
TSENALL 8 rw Enable Timestamp for All Frames
When set, the timestamp snapshot is enabled for all
frames received by the MAC.
TSCTRLS 9 rw Timestamp Digital or Binary Rollover Control
SR When set, the Timestamp Low register rolls over after
3B9A C9FFH value (that is, 1 nanosecond accuracy)
and increments the timestamp (High) seconds. When
reset, the rollover value of sub-second register is 7FFF
FFFFH. The sub-second increment has to be
programmed correctly depending on the PTP reference
clock frequency and the value of this bit.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TSVER2E 10 rw Enable PTP packet Processing for Version 2 Format
NA When set, the PTP packets are processed using the
1588 version 2 format. Otherwise, the PTP packets are
processed using the version 1 format.
TSIPENA 11 rw Enable Processing of PTP over Ethernet Frames
When set, the MAC receiver processes the PTP packets
encapsulated directly in the Ethernet frames. When this
bit is clear, the MAC ignores the PTP over Ethernet
packets.
TSIPV6EN 12 rw Enable Processing of PTP Frames Sent Over IPv6-
A UDP
When set, the MAC receiver processes PTP packets
encapsulated in UDP over IPv6 packets. When this bit is
clear, the MAC ignores the PTP transported over UDP-
IPv6 packets.
TSIPV4EN 13 rw Enable Processing of PTP Frames Sent over IPv4-
A UDP
When set, the MAC receiver processes the PTP packets
encapsulated in UDP over IPv4 packets. When this bit is
clear, the MAC ignores the PTP transported over UDP-
IPv4 packets. This bit is set by default.
TSEVNTE 14 rw Enable Timestamp Snapshot for Event Messages
NA When set, the timestamp snapshot is taken only for
event messages (SYNC, Delay_Req, Pdelay_Req, or
Pdelay_Resp). When reset, the snapshot is taken for all
messages except Announce, Management, and
Signaling.
TSMSTRE 15 rw Enable Snapshot for Messages Relevant to Master
NA When set, the snapshot is taken only for the messages
relevant to the master node. Otherwise, the snapshot is
taken for the messages relevant to the slave node.
SNAPTYP [17:16] rw Select PTP packets for Taking Snapshots
SEL These bits along with Bits 15 and 14 decide the set of
PTP packet types for which snapshot needs to be taken.
TSENMAC 18 rw Enable MAC address for PTP Frame Filtering
ADDR When set, the DA MAC address (that matches any MAC
Address register) is used to filter the PTP frames when
PTP is directly sent over Ethernet.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

23_19

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
SUB_SECOND_INCREMENT
This register is present only when the IEEE 1588 timestamp feature is selected without
an external timestamp input. In the Coarse Update mode
(TIMESTAMP_CONTROL.TSCFUPDT bit), the value in this register is added to the
system time every clock cycle of the PTP refference clock. In the Fine Update mode, the
value in this register is added to the system time whenever the Accumulator gets an
overflow.
ETH0_SUB_SECOND_INCREMENT
Sub-Second Increment Register (704H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_31_8
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved_31_8 SSINC
r rw

SSINC [7:0] rw Sub-second Increment Value
The value programmed in this field is accumulated every
clock cycle of the PTP refference clock with the contents
of the sub-second register. For example, when PTP
clock is 50 MHz (period is 20 ns), you should program
20 (14H) when the System Time-Nanoseconds register
has an accuracy of 1 ns
(TIMESTAMP_CONTROL.TSCTRLSSR bit is set).
When Timestamp.Control.TSCTRLSSR is clear, the
Nanoseconds register has a resolution of ~0.465ns. In
this case, you should program a value of 43 (2BH) that
is derived by 20ns/0.465.
31_8

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
SYSTEM_TIME_SECONDS
The System Time -Seconds register, along with System-TimeNanoseconds register,
indicates the current value of the system time maintained by the MAC. Though it is
updated on a continuous basis, there is some delay from the actual time because of
clock domain transfer latencies .
ETH0_SYSTEM_TIME_SECONDS
System Time - Seconds Register (708H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TSS
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TSS

TSS [31:0] r Timestamp Second
The value in this field indicates the current value in
seconds of the System Time maintained by the MAC.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
SYSTEM_TIME_NANOSECONDS
The value in this field has the sub second representation of time, with an accuracy of
0.46 ns. When TIMESTAMP_CONTROL.TSCTRLSSR is set, each bit represents 1 ns
and the maximum value is 3B9A C9FFH, after which it rolls-over to zero.
ETH0_SYSTEM_TIME_NANOSECONDS
System Time Nanoseconds Register (70CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Rese
rved TSSS
_31
r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TSSS

TSSS [30:0] r Timestamp Sub Seconds
The value in this field has the sub second representation
of time, with an accuracy of 0.46 ns. When
TIMESTAMP_CONTROL.TSCTRLSSR is set, each bit
represents 1 ns and the maximum value is 3B9A
C9FFH, after which it rolls-over to zero.
31

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
SYSTEM_TIME_SECONDS_UPDATE
The System Time - Seconds Update register, along with the System_Time_
Nanoseconds_Update register, initializes or updates the system time maintained by the
MAC. You must write both of these registers before setting the
TIMESTAMP_CONTROL.TSINIT or TIMESTAMP_CONTROL.TSUPDT bits.
ETH0_SYSTEM_TIME_SECONDS_UPDATE
System Time - Seconds Update Register(710H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TSS
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TSS
rw

TSS [31:0] rw Timestamp Second
The value in this field indicates the time in seconds to be
initialized or added to the system time.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
SYSTEM_TIME_NANOSECONDS_UPDATE
.
ETH0_SYSTEM_TIME_NANOSECONDS_UPDATE
System Time Nanoseconds Update Register(714H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ADD
TSSS
SUB
rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TSSS
rw

TSSS [30:0] rw Timestamp Sub Second
The value in this field has the sub second representation
of time, with an accuracy of 0.46 ns. When
TIMESTAMP_CONTROL.TSCTRLSSR is set, each bit
represents 1 ns and the programmed value should not
exceed 3B9A C9FFH.
ADDSUB 31 rw Add or subtract time
When this bit is set, the time value is subtracted with the
contents of the update register. When this bit is reset,
the time value is added with the contents of the update
register.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
32-bit Register - TIMESTAMP_ADDEND

This register is present only when the IEEE 1588 Timestamp feature is selected without
external timestamp input. This register value is used only when the system time is
configured for Fine Update mode using TIMESTAMP_CONTROL.TSCFUPDT bit. This
register content is added to a 32-bit accumulator in every clock cycle of the PTP
refference clock and the system time is updated whenever the accumulator overflows.
ETH0_TIMESTAMP_ADDEND
Timestamp Addend Register (718H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TSAR
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TSAR
rw

TSAR [31:0] rw Timestamp Addend Register
This field indicates the 32-bit time value to be added to
the Accumulator register to achieve time
synchronization.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TARGET_TIME_SECONDS
The Target Time Seconds register, along with Target Time Nanoseconds register, is
used to schedule an interrupt event triggered by the TimestampStatus.TSTARGT bit
when Advanced Timestamping is enabled; otherwise, the INTERRUPT_STATUS.TSIS
will trigger the interrupt when the system time exceeds the value programmed in these
registers. This register is present only when the IEEE 1588 Timestamp feature is
selected without external timestamp input.
ETH0_TARGET_TIME_SECONDS
Target Time Seconds Register (71CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TSTR
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TSTR
rw

TSTR [31:0] rw Target Time Seconds Register
This register stores the time in seconds. When the
timestamp value matches or exceeds both Target
Timestamp registers, then based on
PPS_CONTROL.TRGTMODSEL0, the MAC starts or
stops the PPS signal output and generates an interrupt
(if enabled).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TARGET_TIME_NANOSECONDS
This register is present only when the IEEE 1588 Timestamp feature is selected without
external timestamp input.
ETH0_TARGET_TIME_NANOSECONDS
Target Time Nanoseconds Register (720H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TRG
TBU TTSLO
SY
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TTSLO
rw

TTSLO [30:0] rw Target Timestamp Low Register
This register stores the time in (signed) nanoseconds.
When the value of the timestamp matches the both
Target Timestamp registers, then based on the
PPS_CONTROL.TPPSRGTMODSEL0 field , the MAC
starts or stops the PPS signal output and generates an
interrupt (if enabled).
This value should not exceed 3B9A C9FFH when
TIMESTAMP_CONTROL.TSCTRLSSR is set . The
actual start or stop time of the PPS signal output may
have an error margin up to one unit of sub-second
increment value.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TRGTBUS 31 r Target Time Register Busy
Y The MAC sets this bit when the
PPS_CONTROL.PPSCMD field is programmed to
010B or 011B. Programming the PPSCMD field to 010B
or 011B, instructs the MAC to synchronize the Target
Time Registers to the PTP clock domain.
The MAC clears this bit after synchronizing the Target
Time Registers to the PTP clock domain The application
must not update the Target Time Registers when this bit
is read as 1. Otherwise, the synchronization of the
previous programmed time gets corrupted. This bit is
reserved when the Enable Flexible Pulse-Per-Second
Output feature is not selected.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
SYSTEM_TIME_HIGHER_WORD_SECONDS
This register is present only when the IEEE 1588 Advanced Timestamp feature is
selected without an external timestamp input.
ETH0_SYSTEM_TIME_HIGHER_WORD_SECONDS
System Time - Higher Word Seconds Register (724H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_31_16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TSHWR
rw

TSHWR [15:0] rw Timestamp Higher Word Register
This field contains the most significant 16-bits of the
timestamp seconds value. The register is directly written
to initialize the value. This register is incremented when
there is an overflow from the 32-bits of the
SYSTEM_TIME_SECONDS register.
31_16

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TIMESTAMP_STATUS
All bits except Bits[27:25] gets cleared when the CPU reads this register.
ETH0_TIMESTAMP_STATUS
Timestamp Status Register (728H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Rese
Reserved_
Reserved_29_25 rved Reserved_23_20 Reserved_19-16
31_30
_24
r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TST TST TST
TST TST TST TST Rese TST
RGT RGT RGT TSS
Reserved_15_10 ARG ARG ARG RGT rved ARG
ERR ERR ERR OVF
T3 T2 T1 ERR _2 T
3 2 1

TSSOVF 0 r Timestamp Seconds Overflow
When set, this bit indicates that the seconds value of the
timestamp (when supporting version 2 format) has
overflowed beyond FFFF_FFFFH.
TSTARGT 1 r Timestamp Target Time Reached
When set, this bit indicates that the value of system time
is greater or equal to the value specified in the
Target_Time_ Seconds Register and Target Time
Nanoseconds Register.
2
TSTRGTE 3 r Timestamp Target Time Error
RR This bit is set when the target time, being programmed
in Target Time Registers, is already elapsed. This bit is
cleared when read by the application.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TSTARGT 4 r Timestamp Target Time Reached for Target Time
1 PPS1
is greater than or equal to the value specified in PPS1_
Target_Time_High Register and
PPS1_Target_Time_Low Register.
RR1 This bit is set when the target time, being programmed
in Register 480 and Register 481, is already elapsed.
This bit is cleared when read by the application.
2 PPS2
is greater than or equal to the value specified in Register
488 [PPS2 Target Time High Register] and Register 489
[PPS2 Target Time Low Register].
3 PPS3
is greater than or equal to the value specified in Register
496 [PPS3 Target Time High Register] and Register 497
[PPS3 Target Time Low Register].
15_10
19-16
23_20
24

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

29_25
31_30

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
PPS_CONTROL
Note: * Bits[30:24] are valid only when four Flexible PPS outputs are selected. *
Bits[22:16] are valid only when three or more Flexible PPS outputs are selected. *
Bits[14:8] are valid only when two or more Flexible PPS outputs are selected. * Bits[6:4]
are valid only when Flexible PPS feature is selected.
ETH0_PPS_CONTROL
PPS Control Register (72CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Rese Rese
TRGTMOD Reserved_ TRGTMOD Reserved_
rved PPSCMD3 rved PPSCMD2
SEL3 28_27 SEL2 20_19
_31 _23
r r r r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Rese Rese
TRGTMOD Reserved_ TRGTMOD PPS
rved PPSCMD1 rved PPSCTRL_PPSCMD
SEL1 12_11 SEL0 EN0
_15 _7
r r r r r r r rw

PPSCTRL [3:0] rw PPSCTRL0 or PPSCMD0
_PPSCMD PPSCTRL0: PPS0 Output Frequency Control
This field controls the frequency of the PPS0 output
(ptp_pps_o[0]) signal. The default value of PPSCTRL is
0000, and the PPS output is 1 pulse (of width clk_ptp_i)
every second. For other values of PPSCTRL, the PPS
output becomes a generated clock of following
frequencies:
-0001B: The binary rollover is 2 Hz, and the digital
rollover is 1 Hz.
rollover is 2 Hz.
rollover is 4 Hz.
rollover is 8 Hz.
-...
-1111B: The binary rollover is 32.768 KHz, and the
digital rollover is 16.384 KHz.
See also 1)

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

PPSEN0 4 r Flexible PPS Output Mode Enable
When set low, Bits[3:0] function as PPSCTRL
(backward compatible). When set high, Bits[3:0]
function as PPSCMD.
TRGTMOD [6:5] r Target Time Register Mode for PPS0 Output
SEL0 This field indicates the Target Time registers (register
455 and 456) mode for PPS0 output signal:
* 00B: Indicates that the Target Time registers are
programmed only for generating the interrupt event.
* 01B: Reserved
programmed for generating the interrupt event and
starting or stopping the generation of the PPS0 output
signal.
programmed only for starting or stopping the generation
of the PPS0 output signal. No interrupt is asserted.
7
PPSCMD1 [10:8] r Flexible PPS1 Output Control
This field controls the flexible PPS1 output
(ptp_pps_o[1]) signal. This field is similar to
PPSCMD0[2:0] in functionality.
12_11
480 and 481) mode for PPS1 output signal.
This field is similar to the TRGTMODSEL0 field.
15
20_19

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

23
28_27
31

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
1) In the binary rollover mode, the PPS output (ptp_pps_o) has a duty cycle of 50 percent with these frequencies.
In the digital rollover mode, the PPS output frequency is an average number. The actual clock is of different
frequency that gets synchronized every second. For example:
* When PPSCTRL = 0001, the PPS (1 Hz) has a low period of 537 ms and a high period of 463 ms
* When PPSCTRL = 0010, the PPS (2 Hz) is a sequence of:
- One clock of 50 percent duty cycle and 537 ms period
- Second clock of 463 ms period (268 ms low and 195 ms high)
* When PPSCTRL = 0011, the PPS (4 Hz) is a sequence of:
- Three clocks of 50 percent duty cycle and 268 ms period
- Fourth clock of 195 ms period (134 ms low and 61 ms high
This behavior is because of the non-linear toggling of bits in the digital rollover mode in System Time -
Nanoseconds Register].
Flexible PPS0 Output Control
Programming these bits with a non-zero value instructs the MAC to initiate an event. Once the command is
transferred or synchronized to the PTP clock domain, these bits get cleared automatically. The Software
should ensure that these bits are programmed only when they are all-zero. The following list describes the
values of PPSCMD0:
* 0000: No Command
* 0001: START Single Pulse
This command generates single pulse rising at the start point defined in Target Time Registers
(TARGET_TIME_SECONDS and TARGET_TIME_NANOSECONDS) and of a duration defined in the PPS0
Width Register.
* 0010: START Pulse Train
This command generates the train of pulses rising at the start point defined in the Target Time Registers and of
a duration defined in the PPS0 Width Register and repeated at interval defined in the PPS Interval Register.
By default, the PPS pulse train is free-running unless stopped by 'STOP Pulse train at time' or 'STOP Pulse
Train immediately' commands.
* 0011: Cancel START 
This command cancels the START Single Pulse and START Pulse Train commands if the system time has not
crossed the programmed start time.
* 0100: STOP Pulse train at time
This command stops the train of pulses initiated by the START Pulse Train command (PPSCMD = 0010) after the
time programmed in the Target Time registers elapses.
* 0101: STOP Pulse Train immediately
This command immediately stops the train of pulses initiated by the START Pulse Train command (PPSCMD =
0010).
* 0110: Cancel STOP Pulse train
This command cancels the STOP pulse train at time command if the programmed stop time has not elapsed. The
PPS pulse train becomes free-running on the successful execution of this command.
* 0111-1111: Reserved

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
BUS_MODE
The Bus Mode register establishes the bus operating modes for the DMA.
ETH0_BUS_MODE
Bus Mode Register (1000H) Reset Value: 0002 0101H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_ TXP 8xP
PRWG MB AAL USP RPBL FB
31_30 R BL
r r rw rw rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Rese
PR PBL rved DSL DA SWR
_7
rw rw rw rw rw rw

SWR 0 rw Software Reset
When this bit is set, the MAC DMA Controller resets the
logic and all internal registers of the MAC. It is cleared
automatically after the reset operation has completed in
all of the DWC_ETH clock domains. Before
reprogramming any register of the DWC_ETH, you
should read a zero (0) value in this bit .
Note:
* The reset operation is completed only when all resets
in all active clock domains are de-asserted. Therefore, it
is essential that all the PHY inputs clocks (applicable for
the selected PHY interface) are present for the software
reset completion.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

DA 1 rw DMA Arbitration Scheme
This bit specifies the arbitration scheme between the
transmit and receive paths of Channel 0.
* 0: Weighted round-robin with Rx:Tx or Tx:Rx.
The priority between the paths is according to the priority
specified in BUS_MODE.PR and priority weights
specified in BUS_MODE.TXPR.
* 1: Fixed priority.
The transmit path has priority over receive path when
BUS_MODE.TXPR is set. Otherwise, receive path has
priority over the transmit path.
DSL [6:2] rw Descriptor Skip Length
This bit specifies the number of Words to skip between
two unchained descriptors. The address skipping starts
from the end of current descriptor to the start of next
descriptor. When the DSL value is equal to zero, then
the descriptor table is taken as contiguous by the DMA
in Ring mode.
Reserved_ 7 rw Reserved
7

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

PBL [13:8] rw Programmable Burst Length
These bits indicate the maximum number of beats to be
transferred in one DMA transaction. This is the
maximum value that is used in a single block Read or
Write. The DMA always attempts to burst as specified in
PBL each time it starts a Burst transfer on the bus. PBL
can be programmed with permissible values of 1, 2, 4, 8,
16, and 32. Any other value results in undefined
behavior. When BUS_MODE.USP is set high, this
BUS_MODE.PBL value is applicable only for Tx DMA
transactions.
If the number of beats to be transferred is more than 32,
then perform the following steps:
1. Set the 8xPBL mode.
2. Set the PBL.
For example, if the maximum number of beats to be
transferred is 64, then first set 8xPBL to 1 and then set
PBL to 8. The PBL values have the following limitation:
The maximum number of possible beats (PBL) is limited
by the size of the Tx FIFO and Rx FIFO in the MTL layer
and the data bus width on the DMA. The FIFO has a
constraint that the maximum beat supported is half the
depth of the FIFO, except when specified.
For different data bus widths and FIFO sizes, the valid
PBL range (including x8 mode) is provided in the
following list. If the PBL is common for both transmit and
receive DMA, the minimum Rx FIFO and Tx FIFO
depths must be considered.
Note: In the half-duplex mode, the valid PBL range
specified in the following list is applicable only for Tx
FIFO.
PR [15:14] rw Priority Ratio
These bits control the priority ratio in the weighted
round-robin arbitration between the Rx DMA and Tx
DMA. These bits are valid only when Bit 1 (DA) is reset.
The priority ratio is Rx:Tx or Tx:Rx depending on
whether Bit 27 (TXPR) is reset or set.
* 00B: The Priority Ratio is 1:1.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

FB 16 rw Fixed Burst
This bit controls whether the Bus Master interface
performs fixed burst transfers or not. When set, the AHB
interface uses only SINGLE, INCR4, INCR8, or INCR16
during start of the normal burst transfers. When reset,
the AHB interface uses SINGLE and INCR burst transfer
operations.
RPBL [22:17] rw Rx DMA PBL
This field indicates the maximum number of beats to be
transferred in one Rx DMA transaction. This is the
maximum value that is used in a single block Read or
Write.
The Rx DMA always attempts to burst as specified in the
RPBL bit each time it starts a Burst transfer on the bus.
You can program RPBL with values of 1, 2, 4, 8, 16, and
32. Any other value results in undefined behavior.
This field is valid and applicable only when USP is set
high.
USP 23 rw Use Seperate PBL
When set high, this bit configures the Rx DMA to use the
value configured in Bits[22:17] as PBL. The
BUS_MODE. PBL value is applicable only to the Tx
DMA operations.
When reset to low, the BUS_MODE.PBL value is
applicable for both DMA engines.
8xPBL 24 rw 8xPBL Mode
When set high, this bit multiplies the programmed PBL
value (Bits[22:17] and Bits[13:8]) eight times. Therefore,
the DMA transfers the data in 8, 16, 32, 64, 128, and 256
beats depending on the BUS_MODE.PBL value.
AAL 25 rw Address Aligned Beats
When this bit is set high and the BUS_MODE.FB bit is
equal to 1, the AHB interface generates all bursts
aligned to the start address LS bits. If the
BUS_MODE.FB bit is equal to 0, the first burst
(accessing the data buffer's start address) is not aligned,
but subsequent bursts are aligned to the address.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

MB 26 rw Mixed Burst
When this bit is set high and the BUS_MODE.FB bit is
low, the Bus Master interface starts all bursts of length
more than 16 with INCR (undefined burst) whereas it
reverts to fixed burst transfers (INCRx and SINGLE) for
burst length of 16 and less.
TXPR 27 rw Transmit Priority
When set, this bit indicates that the transmit DMA has
higher priority than the receive DMA during arbitration
for the system-side bus.
PRWG [29:28] r Channel Priority Weights
This field sets the priority weights for Channel 0 during
the round-robin arbitration between the DMA channels
for the system bus.
* 00B: The priority weight is 1.
31_30

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TRANSMIT_POLL_DEMAND
The Transmit Poll Demand register enables the Tx DMA to check whether or not the
DMA owns the current descriptor. The Transmit Poll Demand command is given to wake
up the Tx DMA if it is in the Suspend mode. The Tx DMA can go into the Suspend mode
because of an Underflow error in a transmitted frame or the unavailability of descriptors
owned by it. You can give this command anytime and the Tx DMA resets this command
when it again starts fetching the current descriptor from the XMC4500 memory.
ETH0_TRANSMIT_POLL_DEMAND
Transmit Poll Demand Register (1004H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TPD
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TPD
rw

TPD [31:0] rw Transmit Poll Demand
When these bits are written with any value, the DMA
reads the current descriptor pointed to by the Current
Host Transmit Descriptor Register. If that descriptor is
not available (owned by the CPU), the transmission
returns to the Suspend state and STATUS.TU is
asserted. If the descriptor is available, the transmission
resumes.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RECEIVE_POLL_DEMAND
The Receive Poll Demand register enables the receive DMA to check for new
descriptors. This command is used to wake up the Rx DMA from the SUSPEND state.
The RxDMA can go into the SUSPEND state only because of the unavailability of
descriptors it owns.
ETH0_RECEIVE_POLL_DEMAND
Receive Poll Demand Register (1008H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RPD
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RPD
rw

RPD [31:0] rw Receive Poll Demand
When these bits are written with any value, the DMA
reads the current descriptor pointed to by the Current
Host Receive Descriptor Register. If that descriptor is
not available (owned by the CPU), the reception returns
to the Suspended state and STATUS.RU is not
asserted. If the descriptor is available, the Rx DMA
returns to the active state.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RECEIVE_DESCRIPTOR_LIST_ADDRESS
The Receive Descriptor List Address register points to the start of the Receive
Descriptor List. The descriptor lists reside in the XMC4500's physical memory space and
must be Word-aligned . The DMA internally converts it to bus width aligned address by
making the corresponding LS bits low. Writing to this register is permitted only when
reception is stopped. When stopped, this register must be written to before the receive
Start command is given. You can write to this register only when Rx DMA has stopped,
that is, Bit 1 (SR) is set to zero in the Operation Mode Register. When stopped, this
register can be written with a new descriptor list address. When you set the SR bit to 1,
the DMA takes the newly programmed descriptor base address. If this register is not
changed when the SR bit is set to 0, then the DMA takes the descriptor address where
it was stopped earlier.
ETH0_RECEIVE_DESCRIPTOR_LIST_ADDRESS
Receive Descriptor Address Register (100CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RDESLA_32bit
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved_
RDESLA_32bit
1_0
rw r

1_0
RDESLA_ [31:2] rw Start of Receive List
32bit This field contains the base address of the first
descriptor in the Receive Descriptor list. The LSB bits
(1:0) for 32-bit bus width are ignored and internally taken
as all-zero by the DMA. Therefore, these LSB bits are
read-only (RO).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
TRANSMIT_DESCRIPTOR_LIST_ADDRESS
The Transmit Descriptor List Address register points to the start of the Transmit
Descriptor List. The descriptor lists reside in the XMC4500's physical memory space and
must be Word-aligned . The DMA internally converts it to bus width aligned address by
making the corresponding LSB to low. You can write to this register only when the Tx
DMA has stopped, that is, OPERATION_MODE.ST is set to zero. When stopped, this
register can be written with a new descriptor list address. When you set the
OPERATION_MODE.ST bit to 1, the DMA takes the newly programmed descriptor base
address. If this register is not changed when the ST bit is set to 0, then the DMA takes
the descriptor address where it was stopped earlier.
ETH0_TRANSMIT_DESCRIPTOR_LIST_ADDRESS
Transmit descripter Address Register (1010H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TDESLA_32bit
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved_
TDESLA_32bit
1_0
rw r

1_0
TDESLA_ [31:2] rw Start of Transmit List
32bit This field contains the base address of the first
descriptor in the Transmit Descriptor list. The LSB bits
(1:0) are ignored and are internally taken as all-zero by
the DMA. Therefore, these LSB bits are read-only (RO).

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
STATUS
The STATUS register contains all status bits that the DMA reports to the CPU. The
Software driver reads this register during an interrupt service routine or polling. Most of
the fields in this register cause the CPU to be interrupted. The bits of this register are not
cleared when read. Writing 1 to (unreserved) Bits[16:0] of this register clears these bits
and writing 0 has no effect. Each field (Bits[16:0]) can be masked by masking the
appropriate bit in the Interrupt Enable Register.
ETH0_STATUS
Status Register (1014H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Rese Rese Rese
rved rved TTI EPI EMI rved EB TS RS NIS
_31 _30 _26
r r r r r r r r r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved_
AIS ERI FBI ETI RWT RPS RU RI UNF OVF TJT TU TPS TI
12_11
rw rw rw r rw rw rw rw rw rw rw rw rw rw rw

TI 0 rw Transmit Interrupt
This bit indicates that the frame transmission is
complete. When transmission is complete, the Bit 31
(Interrupt on Completion) of TDES1 is reset in the first
descriptor, and the specific frame status information is
updated in the descriptor.
TPS 1 rw Transmit Process Stopped
This bit is set when the transmission is stopped.
TU 2 rw Transmit Buffer Unavailable
This bit indicates that the CPU owns the Next Descriptor
in the Transmit List and the DMA cannot acquire it.
Transmission is suspended. The TS bit field explains
the Transmit Process state transitions.
To resume processing Transmit descriptors, the CPU
should change the ownership of the descriptor by setting
TDES0[31] and then issue a Transmit Poll Demand
command.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TJT 3 rw Transmit Jabber Timeout
This bit indicates that the Transmit Jabber Timer
expired, which happens when the frame size exceeds
2,048 (10,240 bytes when the Jumbo frame is enabled).
When the Jabber Timeout occurs, the transmission
process is aborted and placed in the Stopped state. This
causes the Transmit Jabber Timeout TDES0[14] flag to
assert.
OVF 4 rw Receive Overflow
This bit indicates that the Receive Buffer had an
Overflow during frame reception. If the partial frame is
transferred to the application, the overflow status is set
in RDES0[11].
UNF 5 rw Transmit Underflow
This bit indicates that the Transmit Buffer had an
Underflow during frame transmission. Transmission is
suspended and an Underflow Error TDES0[1] is set.
RI 6 rw Receive Interrupt
This bit indicates that the frame reception is complete.
When reception is complete, the Bit 31 of RDES1
(Disable Interrupt on Completion) is reset in the last
Descriptor, and the specific frame status information is
updated in the descriptor.
The reception remains in the Running state.
RU 7 rw Receive Buffer Unavailable
This bit indicates that the CPU owns the Next Descriptor
in the Receive List and the DMA cannot acquire it. The
Receive Process is suspended. To resume processing
Receive descriptors, the CPU should change the
ownership of the descriptor and issue a Receive Poll
Demand command. If no Receive Poll Demand is
issued, the Receive Process resumes when the next
recognized incoming frame is received. This bit is set
only when the previous Receive Descriptor is owned by
the DMA.
RPS 8 rw Receive Process Stopped
This bit is asserted when the Receive Process enters
the Stopped state.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

RWT 9 rw Receive Watchdog Timeout
This bit is asserted when a frame with length greater
than 2,048 bytes is received (10, 240 when Jumbo
Frame mode is enabled).
ETI 10 rw Early Transmit Interrupt
This bit indicates that the frame to be transmitted is fully
transferred to the MTL Transmit FIFO.
12_11
FBI 13 rw Fatal Bus Error Interrupt
This bit indicates that a bus error occurred, as described
in the EB bit field. When this bit is set, the corresponding
DMA engine disables all of its bus accesses.
ERI 14 rw Early Receive Interrupt
This bit indicates that the DMA had filled the first data
buffer of the packet. STATUS.RI automatically clears
this bit.
AIS 15 rw Abnormal Interrupt Summary
Abnormal Interrupt Summary bit value is the logical OR
of the following when the corresponding interrupt bits
are enabled in Interrupt Enable Register:
* STATUS.TPS: Transmit Process Stopped
* STATUS.TJT: Transmit Jabber Timeout
* STATUS.OVF : Receive FIFO Overflow
* STATUS.UNF: Transmit Underflow
* STATUS.RU: Receive Buffer Unavailable
* STATUS.RPS: Receive Process Stopped
* STATUS.RWT: Receive Watchdog Timeout
* STATUS.ETI: Early Transmit Interrupt
* STATUS.FBI: Fatal Bus Error
Only unmasked bits affect the Abnormal Interrupt
Summary bit.
This is a sticky bit and must be cleared each time a
corresponding bit, which causes AIS to be set, is
cleared.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

NIS 16 rw Normal Interrupt Summary
Normal Interrupt Summary bit value is the logical OR of
the following when the corresponding interrupt bits are
enabled in the Interrupt Enable Register:
* STATUS.TI: Transmit Interrupt
* STATUS.TU: Transmit Buffer Unavailable
* STATUS.RI: Receive Interrupt
* STATUS.ERI: Early Receive Interrupt
Only unmasked bits (interrupts for which interrupt
enable is set in Register 7) affect the Normal Interrupt
Summary bit.
This is a sticky bit and must be cleared (by writing 1 to
this bit) each time a corresponding bit, which causes NIS
to be set, is cleared.
RS [19:17] r Received Process State
This field indicates the Receive DMA FSM state. This
field does not generate an interrupt.
* 000B: Stopped: Reset or Stop Receive Command
issued
* 001B: Running: Fetching Receive Transfer Descriptor
* 010B: Reserved for future use
* 011B: Running: Waiting for receive packet
* 100B: Suspended: Receive Descriptor Unavailable
* 101B: Running: Closing Receive Descriptor
* 110B: TIME_STAMP write state
* 111B: Running: Transferring the receive packet data
from receive buffer to the XMC4500s memory

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TS [22:20] r Transmit Process State
This field indicates the Transmit DMA FSM state. This
field does not generate an interrupt.
* 000B: Stopped; Reset or Stop Transmit Command
issued
* 001B: Running; Fetching Transmit Transfer Descriptor
* 010B: Running; Waiting for status
* 011B: Running; Reading Data from the memory buffer
and queuing it to transmit buffer (Tx FIFO)
* 100B: TIME_STAMP write state
* 101B: Reserved for future use
* 110B: Suspended; Transmit Descriptor Unavailable or
Transmit Buffer Underflow
* 111B: Running; Closing Transmit Descriptor
EB [25:23] r Error Bits
This field indicates the type of error that caused a Bus
Error, for example, error response on the AHB interface.
This field is valid only when Bit 13 (FBI) is set. This field
does not generate an interrupt.
* Bit 23
- 1: Error during data transfer by the Tx DMA
- 0: Error during data transfer by the Rx DMA
* Bit 24
- 1: Error during read transfer
- 0: Error during write transfer
* Bit 25
- 1: Error during descriptor access
- 0: Error during data buffer access
26
EMI 27 r ETH MMC Interrupt
This bit reflects an interrupt event in the MMC module of
the DWC_ETH. The software must read the
corresponding registers in the DWC_ETH to get the
exact cause of interrupt and clear the source of interrupt
to make this bit as 0. The interrupt signal from the
DWC_ETH subsystem is high when this bit is high.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

EPI 28 r ETH PMT Interrupt
This bit indicates an interrupt event in the PMT module
of the ETH. The software must read the PMT Control
and STATUS Register in the MAC to get the exact cause
of interrupt and clear its source to reset this bit to 0. The
interrupt signal from the ETH subsystem is high when
this bit is high.
Note: This interrupt is different from the Power
Management interrupt.
TTI 29 r Timestamp Trigger Interrupt
This bit indicates an interrupt event in the Timestamp
Generator block of ETH. The software must read the
corresponding registers in the ETH to get the exact
cause of interrupt and clear its source to reset this bit to
0. When this bit is high, the interrupt signal from the ETH
subsystem is high.
30
31

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
OPERATION_MODE
The Operation Mode register establishes the Transmit and Receive operating modes
and commands. This register should be the last CSR to be written as part of the DMA
initialization.
ETH0_OPERATION_MODE
Operation Mode Register (1018H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_
Reserved_31_27 DT RSF DFF TSF FTF Reserved_19_17 TTC
23_22
r rw rw rw r rw rw r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Rese Rese
TTC ST Reserved_12_8 FEF FUF rved RTC OSF SR rved
_5 _0
rw rw r rw rw r rw rw rw r

0

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

SR 1 rw Start or Stop Receive
When this bit is set, the Receive process is placed in the
Running state. The DMA attempts to acquire the
descriptor from the Receive list and processes the
incoming frames. The descriptor acquisition is
attempted from the current position in the list, which is
the address set by Receive Descriptor List Address
Register or the position retained when the Receive
process was previously stopped. If the DMA does not
own the descriptor, reception is suspended and
STATUS.RU is set. The Start Receive command is
effective only when the reception has stopped. If the
command is issued before setting Receive Descriptor
List Address Register, the DMA behavior is
unpredictable.
When this bit is cleared, the Rx DMA operation is
stopped after the transfer of the current frame. The next
descriptor position in the Receive list is saved and
becomes the current position after the Receive process
is restarted. The Stop Receive command is effective
only when the Receive process is in either the Running
(waiting for receive packet) or in the Suspended state.
OSF 2 rw Operate on Second Frame
When this bit is set, it instructs the DMA to process the
second frame of the Transmit data even before the
status for the first frame is obtained.
RTC [4:3] rw Receive Threshold Control
These two bits control the threshold level of the MTL
Receive FIFO. Transfer (request) to DMA starts when
the frame size within the MTL Receive FIFO is larger
than the threshold. In addition, full frames with length
less than the threshold are transferred automatically.
The value of 11 is not applicable if the configured
Receive FIFO size is 128 bytes. These bits are valid only
when the RSF bit is zero, and are ignored when the RSF
bit is set to 1.
* 00B: 64
* 01B: 32
* 10B: 96
* 11B: 128

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

5
FUF 6 rw Forward Undersized Good Frames
When set, the Rx FIFO forwards Undersized frames
(frames with no Error and length less than 64 bytes)
including pad-bytes and CRC.
When reset, the Rx FIFO drops all frames of less than
64 bytes, unless a frame is already transferred because
of the lower value of Receive Threshold, for example,
RTC = 01B.
FEF 7 rw Forward Error Frames
When this bit is reset, the Rx FIFO drops frames with
error status (CRC error, collision error, MII_ER, giant
frame, watchdog timeout, or overflow). However, if the
start byte (write) pointer of a frame is already transferred
to the read controller side (in Threshold mode), then the
frame is not dropped.
In the ETH-MTL configuration in which the Frame
Length FIFO is also enabled during core configuration,
the Rx FIFO drops the error frames if that frame's start
byte is not transferred (output) on the ARI bus.
When the FEF bit is set, all frames except runt error
frames are forwarded to the DMA. If the RSF bit is set
and the Rx FIFO overflows when a partial frame is
written, then the frame is dropped irrespective of the
FEF bit setting. However, if the RSF bit is reset and the
Rx FIFO overflows when a partial frame is written, then
a partial frame may be forwarded to the DMA.
12_8

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

ST 13 rw Start or Stop Transmission Command
When this bit is set, transmission is placed in the
Running state, and the DMA checks the Transmit List at
the current position for a frame to be transmitted.
Descriptor acquisition is attempted either from the
current position in the list, which is the Transmit List
Base Address set by Register 4 [Transmit Descriptor
List Address Register], or from the position retained
when transmission was stopped previously. If the DMA
does not own the current descriptor, transmission enters
the Suspended state and Bit 2 (Transmit Buffer
Unavailable) of Register 5 [STATUS Register] is set.
The Start Transmission command is effective only when
transmission is stopped. If the command is issued
before setting Register 4 [Transmit Descriptor List
Address Register], then the DMA behavior is
unpredictable.
When this bit is reset, the transmission process is placed
in the Stopped state after completing the transmission of
the current frame. The Next Descriptor position in the
Transmit List is saved, and it becomes the current
position when transmission is restarted. To change the
list address, you need to program Register 4 [Transmit
Descriptor List Address Register] with a new value when
this bit is reset. The new value is considered when this
bit is set again. The stop transmission command is
effective only when the transmission of the current frame
is complete or the transmission is in the Suspended
state.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TTC [16:14] rw Transmit Threshold Control
These bits control the threshold level of the MTL
Transmit FIFO. Transmission starts when the frame size
within the MTL Transmit FIFO is larger than the
threshold. In addition, full frames with a length less than
the threshold are also transmitted. These bits are used
only when Bit 21 (TSF) is reset.
* 000B: 64
* 001B: 128
* 010B: 192
* 011B: 256
* 100B: 40
* 101B: 32
* 110B: 24
* 111B: 16
19_17
FTF 20 rw Flush Transmit FIFO
When this bit is set, the transmit FIFO controller logic is
reset to its default values and thus all data in the Tx FIFO
is lost or flushed. This bit is cleared internally when the
flushing operation is completed. The Operation Mode
register should not be written to until this bit is cleared.
The data which is already accepted by the MAC
transmitter is not flushed. It is scheduled for
transmission and results in underflow and runt frame
transmission.
Note: The flush operation is complete only when the Tx
FIFO is emptied of its contents and all the pending
Transmit Status of the transmitted frames are accepted
by the CPU. To complete this flush operation, the PHY
transmit clock is required to be active.
TSF 21 rw Transmit Store and Forward
When this bit is set, transmission starts when a full frame
resides in the MTL Transmit FIFO. When this bit is set,
the TTC values specified in Bits[16:14] are ignored. This
bit should be changed only when the transmission is
stopped.
23_22

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

DFF 24 rw Disable Flushing of Received Frames
When this bit is set, the Rx DMA does not flush any
frames because of the unavailability of receive
descriptors or buffers as it does normally when this bit is
reset.
RSF 25 rw Receive Store and Forward
When this bit is set, the MTL reads a frame from the Rx
FIFO only after the complete frame has been written to
it, ignoring the RTC bits. When this bit is reset, the Rx
FIFO operates in the cut-through mode, subject to the
threshold specified by the RTC bits.
DT 26 rw Disable Dropping of TCP/IP Checksum Error Frames
When this bit is set, the MAC does not drop the frames
which only have errors detected by the Receive
Checksum Offload engine. Such frames do not have any
errors (including FCS error) in the Ethernet frame
received by the MAC but have errors only in the
encapsulated payload. When this bit is reset, all error
frames are dropped if the FEF bit is reset.
31_27

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
INTERRUPT_ENABLE
The Interrupt Enable register enables the interrupts reported by ETH0_STATUS
Register. Setting a bit to 1 enables a corresponding interrupt. After a hardware or
software reset, all interrupts are disabled.
ETH0_INTERRUPT_ENABLE
Interrupt Enable Register (101CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_31_17 NIE
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved_
AIE ERE FBE ETE RWE RSE RUE RIE UNE OVE TJE TUE TSE TIE
12_11
rw rw rw r rw rw rw rw rw rw rw rw rw rw rw

TIE 0 rw Transmit Interrupt Enable
When this bit is set with Normal Interrupt Summary
Enable (Bit 16), the Transmit Interrupt is enabled. When
this bit is reset, the Transmit Interrupt is disabled.
TSE 1 rw Transmit Stopped Enable
When this bit is set with Abnormal Interrupt Summary
Enable (Bit 15), the Transmission Stopped Interrupt is
enabled. When this bit is reset, the Transmission
Stopped Interrupt is disabled.
TUE 2 rw Transmit Buffer Unvailable Enable
Enable (Bit 16), the Transmit Buffer Unavailable
Interrupt is enabled. When this bit is reset, the Transmit
Buffer Unavailable Interrupt is disabled.
TJE 3 rw Transmit Jabber Timeout Enable
Enable (Bit 15), the Transmit Jabber Timeout Interrupt is
enabled. When this bit is reset, the Transmit Jabber
Timeout Interrupt is disabled.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

OVE 4 rw Overflow Interrupt Enable
Enable (Bit 15), the Receive Overflow Interrupt is
enabled. When this bit is reset, the Overflow Interrupt is
disabled.
UNE 5 rw Underflow Interrupt Enable
Enable (Bit 15), the Transmit Underflow Interrupt is
enabled. When this bit is reset, the Underflow Interrupt
is disabled.
RIE 6 rw Receive Interrupt Enable
Enable (Bit 16), the Receive Interrupt is enabled. When
this bit is reset, the Receive Interrupt is disabled.
RUE 7 rw Receive Buffer Unavailable Enable
Enable (Bit 15), the Receive Buffer Unavailable Interrupt
is enabled. When this bit is reset, the Receive Buffer
Unavailable Interrupt is disabled.
RSE 8 rw Receive Stopped Enable
Enable (Bit 15), the Receive Stopped Interrupt is
enabled. When this bit is reset, the Receive Stopped
Interrupt is disabled.
RWE 9 rw Receive Watchdog Timeout Enable
Enable (Bit 15), the Receive Watchdog Timeout
Interrupt is enabled. When this bit is reset, the Receive
Watchdog Timeout Interrupt is disabled.
ETE 10 rw Early Transmit Interrupt Enable
When this bit is set with an Abnormal Interrupt Summary
Enable (Bit 15), the Early Transmit Interrupt is enabled.
When this bit is reset, the Early Transmit Interrupt is
disabled.
12_11

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

FBE 13 rw Fatal Bus Error Enable
Enable (Bit 15), the Fatal Bus Error Interrupt is enabled.
When this bit is reset, the Fatal Bus Error Enable
Interrupt is disabled.
ERE 14 rw Early Receive Interrupt Enable
Enable (Bit 16), the Early Receive Interrupt is enabled.
When this bit is reset, the Early Receive Interrupt is
disabled.
AIE 15 rw Abnormal Interrupt Summary Enable
When this bit is set, abnormal interrupt summary is
enabled. When this bit is reset, the abnormal interrupt
summary is disabled. This bit enables the following
interrupts in STATUS Register:
* Transmit Process Stopped
* Transmit Jabber Timeout
* Receive Overflow
* Transmit Underflow
* Receive Buffer Unavailable
* Receive Process Stopped
* Receive Watchdog Timeout
* Early Transmit Interrupt
* Fatal Bus Error
NIE 16 rw Normal Interrupt Summary Enable
When this bit is set, normal interrupt summary is
enabled. When this bit is reset, normal interrupt
summary is disabled. This bit enables the following
interrupts in Register 5 [STATUS Register]:
* Transmit Interrupt
* Transmit Buffer Unavailable
* Receive Interrupt
* Early Receive Interrupt
31_17

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
MISSED_FRAME_AND_BUFFER_OVERFLOW_COUNTER
The DMA maintains two counters to track the number of frames missed during
reception. This register reports the current value of the counter. The counter is used for
diagnostic purposes. Bits[15:0] indicate missed frames because of the RAM buffer being
unavailable. Bits[27:17] indicate missed frames because of buffer overflow conditions
(MTL and MAC) and runt frames (good frames of less than 64 bytes) dropped by the
MTL.
ETH0_MISSED_FRAME_AND_BUFFER_OVERFLOW_COUNTER
Missed Frame and Buffer Overflow Counter Register (1020H) Reset Value: 0000
0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
OVF MIS
Reserved_31_29 CNT OVFFRMCNT CNT
OVF OVF
r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MISFRMCNT

MISFRMC [15:0] r This field indicates the number of frames missed by
NT the controller because of the RAM Receive Buffer
being unavailable. This counter is incremented each
time the DMA discards an incoming frame. The
counter is cleared when this register is read.
MISCNTO 16 r Overflow bit for Missed Frame Counter
VF
OVFFRMC [27:17] r This field indicates the number of frames missed by
NT the application. The counter is cleared when this
register is read.
OVFCNTO 28 r Overflow bit for FIFO Overflow Counter
VF
31_29

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
RECEIVE_INTERRUPT_WATCHDOG_TIMER
This register, when written with non-zero value, enables the watchdog timer for the
Receive Interrupt (Bit 6) of STATUS Register]
ETH0_RECEIVE_INTERRUPT_WATCHDOG_TIMER
Receive Interrupt Watchdog Timer Register (1024H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_31_8
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved_31_8 RIWT
r rw

RIWT [7:0] rw RI Watchdog Timer Count
This bit indicates the number of system clock cycles
multiplied by 256 for which the watchdog timer is set.
The watchdog timer gets triggered with the programmed
value after the Rx DMA completes the transfer of a
frame for which the RI status bit is not set because of the
setting in the corresponding descriptor RDES1[31].
When the watchdog timer runs out, the RI bit is set and
the timer is stopped. The watchdog timer is reset when
the RI bit is set high because of automatic setting of RI
as per RDES1[31] of any received frame.
31_8

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
AHB_Status
This register provides the active status of the AHB master interface. This register is
useful for debugging purposes. In addition, this register is valid only in the Channel 0
DMA when multiple channels are present in the AV mode.
ETH0_AHB_Status
AHB Status Register (102CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved_31_2
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Rese
AHB
Reserved_31_2 rved
MS
_1
r r r

AHBMS 0 r AHB Master Status
When high, it indicates that the AHB master interface
FSMs are in the non-idle state.
1
31_2

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
CURRENT_HOST_TRANSMIT_DESCRIPTOR
The Current Host Transmit Descriptor register points to the start address of the current
Transmit Descriptor read by the DMA.
ETH0_CURRENT_HOST_TRANSMIT_DESCRIPTOR
Current Host Transmit Descriptor Register (1048H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CURTDESAPTR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CURTDESAPTR

CURTDES [31:0] r Host Transmit Descriptor Address Pointer
APTR Cleared on Reset. Pointer updated by the DMA during
operation.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
CURRENT_HOST_RECEIVE_DESCRIPTOR
The Current Host Receive Descriptor register points to the start address of the current
Receive Descriptor read by the DMA.
ETH0_CURRENT_HOST_RECEIVE_DESCRIPTOR
Current Host Receive Descriptor Register (104CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CURRDESAPTR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CURRDESAPTR

CURRDES [31:0] r Host Receive Descriptor Address Pointer
operation.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
CURRENT_HOST_TRANSMIT_BUFFER_ADDRESS
The Current Host Transmit Buffer Address register points to the current Transmit Buffer
Address being read by the DMA.
ETH0_CURRENT_HOST_TRANSMIT_BUFFER_ADDRESS
Current Host Transmit Buffer Address Register (1050H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CURTBUFAPTR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CURTBUFAPTR

CURTBUF [31:0] r Host Transmit Buffer Address Pointer
operation.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
CURRENT_HOST_RECEIVE_BUFFER_ADDRESS
The Current Host Receive Buffer Address register points to the current Receive Buffer
address being read by the DMA.
ETH0_CURRENT_HOST_RECEIVE_BUFFER_ADDRESS
Current Host Receive Buffer Address Register (1054H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CURRBUFAPTR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CURRBUFAPTR

CURRBUF [31:0] r Host Receive Buffer Address Pointer
operation.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
HW_FEATURE
This register indicates the presence of the optional features or functions of the
DWC_ETH. The software driver can use this register to dynamically enable or disable
the programs related to the optional blocks. Note: All bits are set or reset as per the
selection of features during the DWC_ETH configuration.
ETH0_HW_FEATURE
HW Feature Register (1058H) Reset Value: 0305 2F35H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Rese SAV FLE ENH RXFI RXT RXT TXC
INTT
rved ACTPHYIF LANI XIPP DES TXCHCNT RXCHCNT FOSI YP2 YP1 OES
SEN
_31 NS SEN SEL ZE COE COE EL
r r r r r r r r rw r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADD
TSV TSV L3L4 HAS EXT
AVS EEE MMC MGK RWK SMA PCS MAC HDS GMII MIIS
ER2 ER1 FLT HSE HAS
EL SEL SEL SEL SEL SEL SEL ADR EL SEL EL
SEL SEL REN L HEN
SEL

MIISEL 0 r 10 or 100 Mbps support
GMIISEL 1 r 1000 Mbps support
HDSEL 2 r Half-Duplex support
EXTHASH 3 r Expanded DA Hash Filter
EN
HASHSEL 4 r HASH Filter
ADDMAC 5 r Multiple MAC Address Registers
ADRSEL
PCSSEL 6 r PCS registers (TBI, SGMII, or RTBI PHY interface)
L3L4FLTR 7 r Layer 3 and Layer 4 Filter Feature
EN
SMASEL 8 r SMA (MDIO) Interface
RWKSEL 9 r PMT Remote Wakeup
MGKSEL 10 r PMT Magic Packet
MMCSEL 11 r RMON Module

XMC4500
XMC4000 Family
Ethernet MAC (ETH)

TSVER1S 12 r Only IEEE 1588-2002 Timestamp
EL
TSVER2S 13 r IEEE 1588-2008 Advanced Timestamp
EL
EEESEL 14 r Energy Efficient Ethernet
AVSEL 15 r AV Feature
TXCOESE 16 r Checksum Offload in Tx
L
RXTYP1C 17 r IP Checksum Offload (Type 1) in Rx
OE
RXTYP2C 18 r IP Checksum Offload (Type 2) in Rx
OE
RXFIFOSI 19 rw Rx FIFO > 2,048 Bytes
ZE
RXCHCNT [21:20] r Number of additional Rx channels
TXCHCNT [23:22] r Number of additional Tx channels
ENHDESS 24 r Alternate (Enhanced Descriptor)
EL
INTTSEN 25 r Timestamping with Internal System Time
FLEXIPPS 26 r Flexible Pulse-Per-Second Output
EN
SAVLANI 27 r Source Address or VLAN Insertion
NS
ACTPHYIF [30:28] r Active or Selected PHY interface
When you have multiple PHY interfaces in your
configuration, this field indicates the sampled value of
phy_intf_sel_i during reset de-assertion
* 0000: MII
* 0001: RMII
* All Others: Reserved
31
15.7 Interconnects
The tables that refer to the global pins are the ones that contain the inputs/outputs of
the ETH.

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
The GPIO connections are available in the Ports chapter.
15.7.1 ETH Pins
Table 15-28 ETH Pin Connectionsfor MIII

Global I/O Connected To Description
Inputs/Outputs
Control Signals
ETH0.CRS(A) I/O PORT Carrier Sense
ETH0.CRS(B) I/O PORT Carrier Sense
ETH0.CRS(C) I/O PORT Carrier Sense
ETH0.CRS(D) I/O PORT Carrier Sense
ETH0.COL(A) I/O PORT Collision Detect
ETH0.COL(B) I/O PORT Collision Detect
ETH0.COL(C) I/O PORT Collision Detect
ETH0.COL(D) I/O PORT Collision Detect
ETH0.RXDV(A) I/O PORT Receive Data Valid
ETH0.RXDV(B) I/O PORT Receive Data Valid
ETH0.RXDV(C) I/O PORT Receive Data Valid
ETH0.RXDV(D) I/O PORT Receive Data Valid
ETH0.RXER(A) I/O PORT Receive error
ETH0.RXER(B) I/O PORT Receive error
ETH0.RXER(C) I/O PORT Receive error
ETH0.RXER(D) I/O PORT Receive error
Data Bus
ETH0.RXD0(A) I/O PORT Recieve data line
ETH0.RXD0(B) I/O PORT Recieve data line
ETH0.RXD0(C) I/O PORT Recieve data line
ETH0.RXD0(D) I/O PORT Recieve data line

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-28 ETH Pin Connectionsfor MIII (contd)

Inputs/Outputs
ETH0.RXD3(A) I/O PORT Receive data line
ETH0.RXD3(B) I/O PORT Receive data line
ETH0.RXD3(C) I/O PORT Receive data line
ETH0.RXD3(D) I/O PORT Receive data line
ETH0.TXEN(A) I/O PORT Transmit enable
ETH0.TXEN(B) I/O PORT Transmit enable
ETH0.TXEN(C) I/O PORT Transmit enable
ETH0.TXEN(D) I/O PORT Transmit enable
ETH0.TXER(A) I/O PORT Transmit error
ETH0.TXER(B) I/O PORT Transmit error
ETH0.TXER(C) I/O PORT Transmit error
ETH0.TXER(D) I/O PORT Transmit error
ETH0.TXD0(A) I/O PORT Transmit Data Line
ETH0.TXD0(B) I/O PORT Transmit Data Line
ETH0.TXD0(C) I/O PORT Transmit Data Line
ETH0.TXD0(D) I/O PORT Transmit Data Line
ETH0.TXD1(A) I/O PORT Transmit data line
ETH0.TXD1(B) I/O PORT Transmit data line
ETH0.TXD1(C) I/O PORT Transmit data line
ETH0.TXD1(D) I/O PORT Transmit data line

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-28 ETH Pin Connectionsfor MIII (contd)

Inputs/Outputs
PHY Clocks
ETH0.CLKTX(A) I PORT PHY transmit clock
ETH0.CLKTX(B) I PORT PHY transmit clock
ETH0.CLKTX(C) I PORT PHY transmit clock
ETH0.CLKTX(D) I PORT PHY transmit clock
ETH0.CLKRX(A) I PORT PHY receive clock
ETH0.CLKRX(B) I PORT PHY receive clock
ETH0.CLKRX(C) I PORT PHY receive clock
ETH0.CLKRX(D) I PORT PHY receive clock
Table 15-29 ETH Pin Connectionsfor RMIII

Inputs/Outputs
Control Signals
ETH0.CRS_DV(A) I/O PORT Carrier Sense Data Valid
ETH0.CRS_DV(B) I/O PORT Carrier Sense Data Valid
ETH0.CRS_DV(C) I/O PORT Carrier Sense Data Valid
ETH0.CRS_DV(D) I/O PORT Carrier Sense Data Valid
ETH0.RXER(A) I/O PORT Receive error
ETH0.RXER(B) I/O PORT Receive error
ETH0.RXER(C) I/O PORT Receive error
ETH0.RXER(D) I/O PORT Receive error
Data Bus

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-29 ETH Pin Connectionsfor RMIII (contd)

Inputs/Outputs
ETH0.TXEN(A) I/O PORT Transmit enable
ETH0.TXEN(B) I/O PORT Transmit enable
ETH0.TXEN(C) I/O PORT Transmit enable
ETH0.TXEN(D) I/O PORT Transmit enable
PHY Clocks
ETH0.CLK_RMII(A) I PORT PHY Clock
ETH0.CLK_RMII(B) I PORT PHY Clock
ETH0.CLK_RMII(C) I PORT PHY Clock
ETH0.CLK_RMII(D) I PORT PHY Clock
Table 15-30 ETH Pin Connectionsfor MDIO

Inputs/Outputs
Clock
ETH0.MDC(A) O PORT Management Data Clock
ETH0.MDC(B) O PORT Management Data Clock
ETH0.MDC(C) O PORT Management Data Clock

XMC4500
XMC4000 Family
Ethernet MAC (ETH)
Table 15-30 ETH Pin Connectionsfor MDIO (contd)

Inputs/Outputs
ETH0.MDC(D) O PORT Management Data Clock
Data
ETH0.MDIO(A) I/O PORT Management Data I/O
ETH0.MDIO(B) I/O PORT Management Data I/O
ETH0.MDIO(C) I/O PORT Management Data I/O
ETH0.MDIO(D) I/O PORT Management Data I/O

XMC4500
XMC4000 Family
16 Universal Serial Bus (USB)

The USB module is a Dual-Role Device (DRD) controller that supports both device and
host functions and complies fully with the On-The-Go Supplement to the USB 2.0
Specification, Revision 1.3. It can also be configured as a host-only or device-only
controller, fully compliant with the USB 2.0 Specification.
The USB core's USB 2.0 configurations support full-speed (12-Mbps) transfers.
The USB core is optimized for the following applications and systems:
Portable electronic devices
Point-to-point applications (direct connection to FS device)
References:
[15] USB 2.0 specification (April 27, 2000).
[16] On-The-Go Supplement to the USB 2.0 specification (Revision 1.3, December 5,
2006).
16.1 Overview
This section describes the features and provides a block diagram of the USB module.
16.1.1 Features
The USB module includes the following features:
Complies with the USB 2.0 Specification
Complies with the On-The-Go Supplement to the USB 2.0 Specification (Revision
1.3)
Configurable as Device only, Host only or as an OTG Dual Role Device
Support for the Full-Speed (12-Mbps) mode
Provides a USB OTG FS PHY interface
Supports up to 7 bidirectional endpoints, including control endpoint 0
Supports up to 14 Host channels
Supports Session Request Protocol (SRP).
Supports Host Negotiation Protocol (HNP).
Supports SOFs in Full-Speed modes.
Supports clock gating for power saving
Supports USB suspend/resume
Supports DMA mode in:
Descriptor-Based Scatter/Gather DMA operation
Buffer DMA operation
Dedicated transmit FIFO for each of the device IN endpoints in Slave and DMA
modes. Each FIFO can hold multiple packets.

USB, V1.2 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Supports packet-based, Dynamic FIFO memory allocation for endpoints for small
FIFOs and flexible, efficient use of RAM.
Provides support to change an endpoints FIFO memory size during transfers.
Supports endpoint FIFO sizes that are not powers of 2, to allow the use of contiguous
memory locations.

Figure 16-1 shows the USB module block diagram.
clk_ahbm VBUS
PHY
Clock
Inter-
Control clk_usb face DP
USB
PHY DM
USB
Address Core ID
Decoder P0.9 / ID
Port P0.1 / DRIVEVBUS

DRIVEVBUS Control
Interrupt
Control P3.2 / DRIVEVBUS
Figure 16-1 USB Module Block Diagram

XMC4500
XMC4000 Family

This chapter describes the operation modes and the FIFO architecture of the USB
module.
16.2.1 OTG Dual-Role Device (DRD)

The OTG DRD provides both Host and Device functions and supports the Host
Negotiation Protocol (HNP) and Session Request Protocol (SRP). It is able to detect
whether an A- or B-device is connected by sampling the ID input signal.
To drive the VBUS as an A-device, the OTG DRD requires an external charge pump,
which is enabled through the output signal DRIVEBUS.
Figure 16-2 shows the connections of the DRD.
VDD
DRIVEBUS External
Charge
Pump
V BUS VBUS
USB
USB AB-connector
Module in DM DM
DRD
DP DP
Configuration
ID ID
VSS
Figure 16-2 OTG DRD Connections
16.2.2 USB Host

The USB Host supports up to 14 Host channels, each configurable for the transfer type
(Control, Bulk, Interrupt, or Isochronous) and direction (IN or OUT). To drive the VBUS,
it requires an external charge pump, which is enabled through the output signal
DRIVEBUS.
Figure 16-3 shows the connections of the USB Host.

XMC4500
XMC4000 Family
VDD
DRIVEBUS External
Charge
Pump
USB VBUS VBUS
USB A-connector
Module in
Host DM DM
Configuration DP DP
VSS
Figure 16-3 USB Host Connections
16.2.3 USB Device

The USB Device supports Control transfers through the bidirectional endpoint 0, and
Bulk, Interrupt or Isochronous tranfers configurable from within the other 6 bidrectional
endpoints. Being a self-powered device, it does not require an additional external voltage
regulator.
Figure 16-4 shows the connections of the USB Device.

XMC4500
XMC4000 Family
USB VBUS VBUS
USB B-connector
Module in
Device DM DM
Configuration DP DP
VSS
Figure 16-4 USB Device Connections
16.2.4 FIFO Architecture

This section describes the FIFO architecture in a USB Host and Device.
16.2.4.1 Host FIFO Architecture

The host uses one transmit FIFO for all non-periodic OUT transactions and one transmit
FIFO for all periodic OUT transactions (periodic FIFOs 2 to n are only used in Device
mode, where n is number of periodic IN endpoints in Device mode). These transmit
FIFOs are used as transmit buffers to hold the data (payload of the transmit packet) to
be transmitted over USB. The host pipes the USB transactions through Request queues
(one for periodic and one for non-periodic). Each entry in the Request queue holds the
IN or OUT channel number along with other information to perform a transaction on the
USB. The order in which the requests are written into the queue determines the
sequence of transactions on the USB. The host processes the periodic Request queue
first, followed by the non-periodic Request queue, at the beginning of each frame.
The host uses one receive FIFO for all periodic and non-periodic transactions. The FIFO
is used as a receive buffer to hold the received data (payload of the received packet)
from the USB until it is transferred to the system memory. The status of each packet
received also goes into the FIFO. The status entry holds the IN channel number along
with other information, such as received byte count and validity status, to perform a
transaction on the AHB.

XMC4500
XMC4000 Family
16.2.4.2 Device FIFO Architecture

This section describes the USB device FIFO architecture.
Dedicated Transmit FIFO Operation

The core uses individual transmit FIFOs for each IN endpoint.
The core internally handles underrun condition during transmit and corrupts the packet
(inverts the CRC) on the USB. If packet transmission results in an underrun condition
(eventually resulting in packet corruption on the USB), the host can time out the endpoint
after three consecutive errors.
Single Receive FIFO

The OTG device uses a single receive FIFO to receive the data for all the OUT
endpoints. The receive FIFO holds the status of the received data packet, such as byte
count, data PID and the validity of the received data. The DMA or the application reads
the data out of the receive FIFO as it is received.

XMC4500
XMC4000 Family
16.3 Programming Model

This chapter describes the programming requirements for the USB core in Host and
Device modes.
16.3.1 Core Initialization

Each significant programming feature of the USB core is discussed in a separate
section.
The application must perform the core initialization sequence. If the cable is connected
during power-up, the Current Mode of Operation bit in the Core Interrupt register
(GINTSTS.CurMod) reflects the mode. The USB core enters Host mode when an "A"
plug is connected, or Device mode when a "B" plug is connected.
This section explains the initialization of the USB core after power-on. The application
must follow the initialization sequence irrespective of Host or Device mode operation.
1. Program the following fields in the Global AHB Configuration (GAHBCFG) register.
a) DMA Mode bit
b) AHB Burst Length field
c) Global Interrupt Mask bit = 1
d) RxFIFO Non-Empty (GINTSTS.RxFLvl) (applicable only when the core is
operating in Slave mode)
e) Non-periodic TxFIFO Empty Level (can be enabled only when the core is operating
in Slave mode as a host.)
f) Periodic TxFIFO Empty Level (can be enabled only when the core is operating in
Slave mode)
2. Program the following fields in GUSBCFG register.
a) HNP Capable bit
b) SRP Capable bit
c) FS Time-Out Calibration field
d) USB Turnaround Time field
3. The software must unmask the following bits in the GINTMSK register.
a) OTG Interrupt Mask
b) Mode Mismatch Interrupt Mask
4. The software can read the GINTSTS.CurMod bit to determine whether the USB core
is operating in Host or Device mode. The software then follows either the Host
Initialization on Page 16-13 or Device Initialization on Page 16-69 sequence.
Note: The core is designed to be interrupt-driven. Polling interrupt mechanism is not
recommended: this may result in undefined resolutions.
16.3.2 Modes of Operation

XMC4500
XMC4000 Family
16.3.2.1 Overview: DMA/Slave modes

The application can operate the core in either of two modes:
In DMA Mode the core fetches the data to be transmitted or updates the received
data on the AHB.
In Slave Mode the application initiates the data transfers for data fetch and store.
The application cannot operate the core using a combination of DMA and Slave
simultaneously. The application can operate the DMA in:
Scatter/Gather mode (a Descriptor-Based mode).
Buffer-pointer based mode.
After the option is selected for Scatter/Gather DMA with configuration-time
programming, the mode can be controlled with the bit DescDMA, as described in
Device Configuration Register (DCFG) on Page 16-289.
Note: The DescDMA field must be modified only once after a reset.
16.3.2.2 DMA Mode

In this mode, the OTG host uses the AHB master Interface for transmit packet data fetch
(AHB to USB) and receive data update (USB to AHB). The AHB master uses the
programmed DMA address (HCDMAx register in host mode and
DIEPDMAx/DOEPDMAx register in device mode) to access the data buffers. When
Scatter/Gather DMA is enabled in device mode DIEPDMAx/DOEPDMAx registers are
used to access the base descriptor.
Transfer-Level Operation
In DMA mode, the application is interrupted only after the programmed transfer size is
transmitted or received (provided the USB core detects no NAK/NYET/Timeout/Error
response in Host mode, or Timeout/CRC Error in Device mode). The application must
handle all transaction errors. In Device mode with dedicated FIFOs, all the USB errors
are handled by the core itself.
Transaction-Level Operation
This mode is similar to transfer-level operation with the programmed transfer size equal
to one packet size (either maximum packet size, or a short packet size). When
Scatter/Gather DMA is enabled, the transfer size is extracted from the descriptors.
16.3.2.3 Slave Mode

In Slave mode, the application can operate the USB core either in transaction-level
(packet-level) operation or in pipelined transaction-level operation.

XMC4500
XMC4000 Family
Transaction-Level Operation
The application handles one data packet at a time per channel/endpoint in transaction-
level operations. Based on the handshake response received on the USB, the
application determines whether to retry the transaction or proceed with the next, until the
end of the transfer. The application is interrupted on completion of every packet. The
application performs transaction-level operations for a channel/endpoint for a
transmission (host: OUT/ device: IN) or reception (host: IN / device: OUT) as shown in
Figure 16-5 and Figure 16-6.
Transaction-Level Operation: Host Mode

For an OUT transaction, the application enables the channel and writes the data packet
into the corresponding (Periodic or Non-periodic) transmit FIFO. The USB core
automatically writes the channel number into the corresponding (Periodic or Non-
periodic) Request Queue, along with the last DWORD write of the packet. For an IN
transaction, the application enables the channel and the USB core automatically writes
the channel number into the corresponding Request queue. The application must wait
for the packet received interrupt, then empty the packet from the receive FIFO.
Transaction-Level Operation: Device Mode

For an IN transaction, the application enables the endpoint, writes the data packet into
the corresponding transmit FIFO, and waits for the packet completion interrupt from the
core. For an OUT transaction, the application enables the endpoint, waits for the packet
received interrupt from the core, then empties the packet from the receive FIFO.
Note: The application has to finish writing one complete packet before switching to a
different channel/endpoint FIFO. Violating this rule results in an error

XMC4500
XMC4000 Family
Figure 16-5 Transmit Transaction-Level Operation in Slave Mode

XMC4500
XMC4000 Family
Figure 16-6 Receive Transaction-Level Operation in Slave Mode

XMC4500
XMC4000 Family
Pipelined Transaction-Level Operation

The application can pipeline more than one transaction (IN or OUT) with pipelined
transaction-level operation, which is analogous to Transfer mode in DMA mode. In
pipelined transaction-level operation, the application can program the core to perform
multiple transactions. The advantage of this mode compared to transaction-level
operation is that the application is not interrupted on a packet basis.
Pipelined Transaction-Level Operation: Host Mode

For an OUT transaction, the application sets up a transfer and enables the channel. The
application can write multiple packets back-to-back for the same channel into the
transmit FIFO, based on the space availability. It can also pipeline OUT transactions for
multiple channels by writing into the HCHARn register, followed by a packet write to that
channel. The core writes the channel number, along with the last DWORD write for the
packet, into the Request queue and schedules transactions on the USB in the same
order.
For an IN transaction, the application sets up a transfer and enables the channel, and
the USB core writes the channel number into the Request queue. The application can
schedule IN transactions on multiple channels, provided space is available in the
Request queue. The core initiates an IN token on the USB only when there is enough
space to receive at least of one maximum-packet-size packet of the channel in the top
of the Request queue.
Pipelined Transaction-Level Operation: Device Mode

For an IN transaction, the application sets up a transfer and enables the endpoint. The
application can write multiple packets back-to-back for the same endpoint into the
transmit FIFO, based on available space. It can also pipeline IN transactions for multiple
channels by writing into the DIEPCTLx register followed by a packet write to that
endpoint. The core writes the endpoint number, along with the last DWORD write for the
packet into the Request queue. The core transmits the data in the transmit FIFO when
an IN token is received on the USB.
For an OUT transaction, the application sets up a transfer and enables the endpoint. The
core receives the OUT data into the receive FIFO, when it has available space. As the
packets are received into the FIFO, the application must empty data from it.
From this point on in this chapter, the terms "Pipelined Transaction mode" and "Transfer
mode" are used interchangeably.
16.4 Host Programming Model

XMC4500
XMC4000 Family
16.4.1 Host Initialization

To initialize the core as host, the application must perform the following steps.
1. Program GINTMSK.PrtIntMsk to unmask.
2. Program the HCFG register to select full-speed host.
3. Program the HPRT.PrtPwr bit to 1B. This drives VBUS on the USB.
4. Wait for the HPRT.PrtConnDet interrupt. This indicates that a device is connected to
the port.
5. Program the HPRT.PrtRst bit to 1B. This starts the reset process.
6. Wait at least 10 ms for the reset process to complete.
7. Program the HPRT.PrtRst bit to 0B.
8. Wait for the HPRT.PrtEnChng interrupt.
9. Read the HPRT.PrtSpd field to get the enumerated speed.
10. Program the HFIR register with a value corresponding to the selected PHY clock.1)
11. Program the GRXFSIZ register to select the size of the receive FIFO.
12. Program the GNPTXFSIZ register to select the size and the start address of the Non-
periodic Transmit FIFO for non-periodic transactions.
13. Program the HPTXFSIZ register to select the size and start address of the Periodic
Transmit FIFO for periodic transactions.
To communicate with devices, the system software must initialize and enable at least
one channel as described in Channel Initialization on Page 16-13".
16.4.2 Channel Initialization

The application must initialize one or more channels before it can communicate with
connected devices. To initialize and enable a channel, the application must perform the
following steps.
1. Program the GINTMSK register to unmask the following:
2. Channel Interrupt
a) Non-periodic Transmit FIFO Empty for OUT transactions (applicable for Slave
mode that operates in pipelined transaction-level with the Packet Count field
programmed with more than one).
b) Non-periodic Transmit FIFO Half-Empty for OUT transactions (applicable for Slave
mode that operates in pipelined transaction-level with the Packet Count field
programmed with more than one).
3. Program the HAINTMSK register to unmask the selected channels' interrupts.
4. Program the HCINTMSK register to unmask the transaction-related interrupts of
interest given in the Host Channel Interrupt register.
5. Program the selected channel's HCTSIZx register.
Note that this step is not applicable in Scatter/Gather DMA mode. Program the
1) At this point, the host is up and running and the port register begins to report device disconnects, etc. The
port is active with SOFs occurring down the enabled port.

XMC4500
XMC4000 Family
register with the total transfer size, in bytes, and the expected number of packets,
including short packets. The application must program the PID field with the initial
data PID (to be used on the first OUT transaction or to be expected from the first IN
transaction).
6. Program the selected channels' HCDMAx register(s) with the buffer start address
(Scatter/Gather DMA mode only).
7. Program the HCCHARx register of the selected channel with the device's endpoint
characteristics, such as type, speed, direction, and so forth. (The channel can be
enabled by setting the Channel Enable bit to 1B only when the application is ready to
transmit or receive any packet).
Repeat steps 1-7 for other channels.
Note: De-allocate channel means after the transfer has completed, the channel is
disabled. When the application is ready to start the next transfer, the application
re-initializes the channel by following these steps.
16.4.3 Halting a Channel

The application can disable any channel by programming the HCCHARx register with
the HCCHARx.ChDis and HCCHARx.ChEna bits set to 1B. This enables the USB host
to flush the posted requests (if any) and generates a Channel Halted interrupt. The
application must wait for the HCINTx.ChHltd interrupt before reallocating the channel for
other transactions. The USB host does not interrupt the transaction that has been
already started on USB.
In Slave mode operation, before disabling a channel, the application must ensure that
there is at least one free space available in the Non-periodic Request Queue (when
disabling a non-periodic channel) or the Periodic Request Queue (when disabling a
periodic channel). The application can simply flush the posted requests when the
Request queue is full (before disabling the channel), by programming the HCCHARx
register with the HCCHARx.ChDis bit set to 1B, and the HCCHARx.ChEna bit reset to 0B.
The core generates a RxFLvl interrupt when there is an entry in the queue. The
application must read/pop the GRXSTSP register to generate the Channel Halted
interrupt.
To disable a channel in DMA mode operation, the application need not check for space
in the Request queue. The USB host checks for space in which to write the Disable
request on the disabled channel's turn during arbitration. Meanwhile, all posted requests
are dropped from the Request queue when the HCCHARx.ChDis bit is set to 1B.
The application is expected to disable a channel under any of the following conditions:
1. When a HCINTx.XferCompl interrupt is received during a non-periodic IN transfer or
high- bandwidth interrupt IN transfer (Slave mode only)
2. When a HCINTx.STALL, HCINTx.XactErr, HCINTx.BblErr, or HCINTx.DataTglErr
interrupt is received for an IN or OUT channel (Slave mode only). For high-bandwidth

XMC4500
XMC4000 Family
interrupt INs in Slave mode, once the application has received a DataTglErr interrupt
it must disable the channel and wait for a Channel Halted interrupt. The application
must be able to receive other interrupts (DataTglErr, Nak, Data, XactErr, BabbleErr)
for the same channel before receiving the halt.
3. When a GINTSTS.DisconnInt (Disconnect Device) interrupt is received. The
application must check for the HPRT.PrtConnSts, because when the device directly
connected to the host is disconnected, HPRT.PrtConnSts is reset. The software must
issue a soft reset to ensure that all channels are cleared. When the device is
reconnected, the host must issue a USB Reset.
4. When the application aborts a transfer before normal completion (Slave and DMA
modes).
Note
In buffer DMA mode, the following guidelines must be considered:
Channel disable must not be programmed for non-split periodic channels. At the end
of the next frame (in the worst case), the core generates a channel halted and
disables the channel automatically.
For split enabled channels (both non-periodic and periodic), channel disable must not
be programmed randomly. However, channel disable can be programmed for
specific scenarios such as NAK and FrmOvrn as defined in the Host programming
model.
16.4.4 Selecting the Queue Depth

Choose the Periodic and Non-periodic Request Queue depths carefully to match the
number of periodic/non-periodic endpoints accessed.
The Non-periodic Request Queue depth affects the performance of non-periodic
transfers. The deeper the queue (along with sufficient FIFO size), the more often the
core is able to pipeline non-periodic transfers. If the queue size is small, the core is able
to put in new requests only when the queue space is freed up.
The core's Periodic Request Queue depth is critical to performing periodic transfers as
scheduled. Select the periodic queue depth, based on the number of periodic transfers
scheduled in a frame. In Slave mode, however, the application must also take into
account the disable entry that must be put into the queue. So, if there are two non-high-
bandwidth periodic endpoints, the Periodic Request Queue depth must be at least 4. If
at least one high-bandwidth endpoint supported, the queue depth must be 8. If the
Periodic Request Queue depth is smaller than the periodic transfers scheduled in a
frame, a frame overrun condition results.

XMC4500
XMC4000 Family
16.4.5 Handling Babble Conditions

USB core handles two cases of babble: packet babble and port babble. Packet babble
occurs if the device sends more data than the maximum packet size for the channel. Port
babble occurs if the core continues to receive data from the device at EOF2 (the end of
frame 2, which is very close to SOF).
When USB core detects a packet babble, it stops writing data into the Rx buffer and waits
for the end of packet (EOP). When it detects an EOP, it flushes already-written data in
the Rx buffer and generates a Babble interrupt to the application.
When USB core detects a port babble, it flushes the RxFIFO and disables the port. The
core then generates a Port Disabled Interrupt (GINTSTS.PrtInt, HPRT.PrtEnChng). On
receiving this interrupt, the application must determine that this is not due to an
overcurrent condition (another cause of the Port Disabled interrupt) by checking
HPRT.PrtOvrCurrAct, then perform a soft reset. The core does not send any more
tokens after it has detected a port babble condition.
16.4.6 Handling Disconnects

If the device is disconnected suddenly, a GINTSTS.DisconnInt interrupt is generated.
When the application receives this interrupt, it must issue a soft reset by programming
the GRSTCTL.CSftRst bit.
16.4.7 Host Programming Operations

Table 16-1 provides links to the programming sequence for the different types of USB
transactions.
Table 16-1 Host Programming Operations

Mode IN OUT/SETUP
Control
Slave Bulk and Control IN Bulk and Control OUT/SETUP
Transactions in Host Slave Transactions in Host Slave
Mode on Page 16-23 Mode on Page 16-20
Buffer DMA Bulk and Control IN Bulk and Control OUT/SETUP
Transactions in DMA Mode Transactions in Host DMA
on Page 16-31 Mode on Page 16-25
Scatter Gather Asynchronous Transfers on Asynchronous Transfers on
DMA Mode Page 16-62" Page 16-62
Bulk

XMC4500
XMC4000 Family
Table 16-1 Host Programming Operations (contd)

Mode IN OUT/SETUP
Slave Bulk and Control IN Bulk and Control OUT/SETUP
Transactions in Host Slave Transactions in Host Slave
Mode on Page 16-23 Mode on Page 16-20
Buffer DMA Bulk and Control IN Bulk and Control OUT/SETUP
Transactions in DMA Mode Transactions in Host DMA
on Page 16-31 Mode on Page 16-25
Scatter Gather Asynchronous Transfers on Asynchronous Transfers on
DMA Mode Page 16-62" Page 16-62
Interrupt
Slave Interrupt IN Transactions in Interrupt OUT Transactions
Slave Mode on Page 16-36 in Slave Mode on Page 16-33
Buffer DMA Interrupt IN Transactions in Interrupt OUT Transactions
DMA Mode on Page 16-41 in DMA Mode on Page 16-38
Scatter Gather Periodic Transfers on Periodic Transfers on
DMA Mode Page 16-64 Page 16-64
Isochronous
Slave Isochronous IN Transactions Isochronous OUT
in Slave Mode on Page 16-46 Transactions in Slave Mode
on Page 16-43
Buffer DMA Isochronous IN Transactions Isochronous OUT
in Host DMA Mode on Transactions in DMA Mode
Page 16-50 on Page 16-48
Scatter Gather Periodic Transfers on Periodic Transfers on
DMA Mode Page 16-64 Page 16-64

XMC4500
XMC4000 Family
16.4.7.1 Writing the Transmit FIFO in Slave Mode

Figure 16-7 shows the flow diagram for writing to the transmit FIFO in Slave mode. The
USB host automatically writes an entry (OUT request) to the Periodic/Non-periodic
Request Queue, along with the last DWORD write of a packet. The application must
ensure that at least one free space is available in the Periodic/Non-periodic Request
Queue before starting to write to the transmit FIFO. The application must always write to
the transmit FIFO in DWORDs. If the packet size is non-DWORD aligned, the application
must use padding. The USB host determines the actual packet size based on the
programmed maximum packet size and transfer size.
Figure 16-7 Transmit FIFO Write Task in Slave Mode

XMC4500
XMC4000 Family
16.4.7.2 Reading the Receive FIFO in Slave Mode

Figure 16-8 shows the flow diagram for reading the receive FIFO in Slave mode. The
application must ignore all packet statuses other than IN Data Packet (0010B).
Figure 16-8 Receive FIFO Read Task in Slave Mode

XMC4500
XMC4000 Family
16.4.7.3 Control Transactions in Host Slave Mode

Setup, Data, and Status stages of a control transfer must be performed as three
separate transfers. Setup-, Data- or Status-stage OUT transactions are performed
similarly to the bulk OUT transactions explained in Bulk and Control OUT/SETUP
Transactions in Host Slave Mode on Page 16-20. Data- or Status-stage IN
transactions are performed similarly to the bulk IN transactions explained in Bulk and
Control IN Transactions in Host Slave Mode on Page 16-23. For all three stages,
the application is expected to set the HCCHAR1.EPType field to Control. During the
Setup stage, the application is expected to set the HCTSIZ1.PID field to SETUP.
16.4.7.4 Bulk and Control OUT/SETUP Transactions in Host Slave Mode

A typical bulk or control OUT/SETUP pipelined transaction-level operation in Slave mode
is shown in Figure 16-9. See channel 1 (ch_1). Two bulk OUT packets are transmitted.
A control SETUP transaction operates the same way but has only one packet. The
assumptions are:
The application is attempting to send two maximum-packet-size packets (transfer
size = 1,024 bytes).
The Non-periodic Transmit FIFO can hold two packets (128 bytes for FS).
The Non-periodic Request Queue depth = 4.
Normal Bulk and Control OUT/SETUP Operations

The sequence of operations in Figure 16-9 (channel 1) is as follows:
1. Initialize channel 1 as explained in Channel Initialization on Page 16-13.
2. Write the first packet for channel 1.
3. Along with the last DWORD write, the core writes an entry to the Non-periodic
Request Queue.
4. As soon as the non-periodic queue becomes non-empty, the core attempts to send
an OUT token in the current frame.
5. Write the second (last) packet for channel 1.
6. The core generates the XferCompl interrupt as soon as the last transaction is
completed successfully.
7. In response to the XferCompl interrupt, de-allocate the channel for other transfers

XMC4500
XMC4000 Family
Figure 16-9 Normal Bulk/Control OUT/SETUP and Bulk/Control IN Transactions

in Slave Mode

XMC4500
XMC4000 Family
Handling Interrupts
The channel-specific interrupt service routine for bulk and control OUT/SETUP
transactions in Slave mode is shown in the following code samples.
Interrupt Service Routine for Bulk/Control OUT/SETUP Transactions in Slave

Mode
Bulk/Control OUT/SETUP
Unmask (NAK/XactErr/NYET/STALL/XferCompl)
if (XferCompl)
{
Reset Error Count
Mask ACK
De-allocate Channel
}
else if (STALL)
{
Transfer Done = 1
Unmask ChHltd
Disable Channel
}
else if (NAK or XactErr or NYET)
{
Rewind Buffer Pointers
Unmask ChHltd
Disable Channel
if (XactErr)
{
Increment Error Count
Unmask ACK
}
else
{
Reset Error Count
}
}
else if (ChHltd)
{
Mask ChHltd
if (Transfer Done or (Error_count == 3))

XMC4500
XMC4000 Family
{
De-allocate Channel
}
else
{
Re-initialize Channel
}
}
else if (ACK)
{
Reset Error Count
Mask ACK
}
The application is expected to write the data packets into the transmit FIFO when space
is available in the transmit FIFO and the Request queue. The application can make use
of GINTSTS.NPTxFEmp interrupt to find the transmit FIFO space.
The application is expected to write the requests as and when the Request queue space
is available and until the XferCompl interrupt is received.
The application must clear and never modify the DoPing bit after enabling the channel
and until the XferCompl or ChHltd interrupt is received. The core uses the DoPing bit to
flush the excessive IN requests after receiving the last or short packet.
16.4.7.5 Bulk and Control IN Transactions in Host Slave Mode

A typical bulk or control IN pipelined transaction-level operation in Slave mode is shown
in Figure 16-9. See channel 2 (ch_2). The assumptions are:
The application is attempting to receive two maximum-sized packets (transfer size =
1,024 bytes).
The receive FIFO can contain at least one maximum-packet-size packet and two
status DWORDs per packet (72 bytes for FS).
Normal Bulk and Control IN Operations

1. Initialize channel 2 as explained in Channel Initialization on Page 16-13.
2. Set the HCCHAR2.ChEna bit to write an IN request to the Non-periodic Request
Queue.
3. The core attempts to send an IN token after completing the current OUT transaction.
4. The core generates an RxFLvl interrupt as soon as the received packet is written to
the receive FIFO.

XMC4500
XMC4000 Family
5. In response to the RxFLvl interrupt, mask the RxFLvl interrupt and read the received
packet status to determine the number of bytes received, then read the receive FIFO
accordingly. Following this, unmask the RxFLvl interrupt.
6. The core generates the RxFLvl interrupt for the transfer completion status entry in the
receive FIFO.
7. The application must read and ignore the receive packet status when the receive
packet status is not an IN data packet (GRXSTSR.PktSts! = 0010B).
8. The core generates the XferCompl interrupt as soon as the receive packet status is
read.
9. In response to the XferCompl interrupt, disable the channel (see Halting a
Channel on Page 16-14) and stop writing the HCCHAR2 register for further
requests. The core writes a channel disable request to the non-periodic request
queue as soon as the HCCHAR2 register is written.
10. The core generates the RxFLvl interrupt as soon as the halt status is written to the
receive FIFO.
11. Read and ignore the receive packet status.
12. The core generates a ChHltd interrupt as soon as the halt status is popped from the
receive FIFO.
13. In response to the ChHltd interrupt, de-allocate the channel for other transfers.
Note: For Bulk/Control IN transfers, the application must write the requests when the
Request queue space is available, and until the XferCompl interrupt is received.
Handling Interrupts
The channel-specific interrupt service routine for bulk and control IN transactions in
Slave mode is shown in the following code samples.
Interrupt Service Routine for Bulk/Control IN Transactions in Slave Mode

Unmask (XactErr/XferCompl/BblErr/STALL/DataTglErr)
if (XferCompl)
{
Reset Error Count
Unmask ChHltd
Disable Channel
Reset Error Count
Mask ACK
}
else if (XactErr or BblErr or STALL)
{
Unmask ChHltd
Disable Channel
if (XactErr)
{

XMC4500
XMC4000 Family

Unmask ACK
}
}
else if (ChHltd)
{
Mask ChHltd
if (Transfer Done or (Error_count == 3
{
De-allocate Channel
}
else
{
}
}
else if (ACK)
{
Reset Error Count
Mask ACK
}
else if (DataTglErr)
{
Reset Error Count
}
16.4.7.6 Control Transactions in Host DMA Mode

Setup, Data, and Status stages of a control transfer must be performed as three
separate transfers. Setup- and Data- or Status-stage OUT transactions are performed
similarly to the bulk OUT transactions explained in Bulk and Control OUT/SETUP
Transactions in Host DMA Mode on Page 16-25. Data- or Status-stage IN
transactions are performed similarly to the bulk IN transactions explained in Bulk and
Control IN Transactions in DMA Mode on Page 16-31. For all three stages, the
application is expected to set the HCCHAR1.EPType field to Control. During the Setup
stage, the application is expected to set the HCTSIZ1.PID field to SETUP.
16.4.7.7 Bulk and Control OUT/SETUP Transactions in Host DMA Mode

This section discusses the following topics:
Overview
NAK and NYET Handling With Internal DMA

XMC4500
XMC4000 Family
Handling Interrupts
Overview
The application is attempting to send two maximum-packet-size packets (transfer

The Non-periodic Transmit FIFO can hold two packets (128 bytes for FS).

1. Initialize and enable channel 1 as explained in Channel Initialization on
Page 16-13.
2. The USB host starts fetching the first packet as soon as the channel is enabled. For
internal DMA mode, the USB host uses the programmed DMA address to fetch the
packet.
3. After fetching the last DWORD of the second (last) packet, the USB host masks
channel 1 internally for further arbitration.
4. The USB host generates a ChHltd interrupt as soon as the last packet is sent.
transactions in DMA mode is shown in Handling Interrupts on Page 16-29.
NAK and NYET Handling With Internal DMA
1. The USB Host sends a Bulk OUT Transaction.

2. The Device responds with NAK or NYET.
3. If the application has unmasked NAK or NYET, the core generates the corresponding
interrupt(s) to the application.
The application is not required to service these interrupts, since the core takes care
of rewinding of buffer pointers and re-initializing the Channel without application
intervention.
4. The core automatically issues a ping token.
5. When the Device returns an ACK, the core continues with the transfer.
Note: The application must use the Do Ping bit to set the ping bit (HCTSIZ0[31]) for the
next transfer and not rely on the NYET status. This ensures that the last response
sent from the device (NYET/ACK) does not matter for a new transfer.
Optionally, the application can utilize these interrupts. If utilized by the application:
The NAK or NYET interrupt is masked by the application.

XMC4500
XMC4000 Family
The core does not generate a separate interrupt when NAK or NYET is received by
the Host functionality.
Application Programming Flow

1. The application programs a channel to do a bulk transfer for a particular data size in
each transaction.
a) Packet Data size can be up to 512KBytes
b) Zero-length data must be programmed as a separate transaction.
2. Program the transfer size register with:
a) Transfer size
b) Packet Count
3. Program the DMA address.
4. Program the HCCHAR to enable the channel.
5. The application is not required to set the HCCHARx.DoPng bit for NAK/NYET
responses. The core sends a Ping token automatically when the device responds
with a NAK/NYET for OUT transfers. The core keeps sending the Ping token until an
ACK response is received.
6. The Interrupt handling by the application is as depicted in the flow diagram.
Note: The NAK/NYET interrupts are still generated internally. The application can mask
off these interrupts from reaching it. The application can use these interrupts
optionally

XMC4500
XMC4000 Family
Figure 16-10 Normal Bulk/Control OUT/SETUP and Bulk/Control IN Transactions

in DMA Mode

XMC4500
XMC4000 Family
Handling Interrupts
transactions in DMA mode is shown in the following code samples.
Figure 16-11 Interrupt Service Routine for Bulk/Control OUT Transaction in DMA
Mode

XMC4500
XMC4000 Family
In Figure 16-11 that the Interrupt Service Routine is not required to handle NAK or NYET
responses. The core internally sets the HCCHARx.DoPng bit once a NAK/NYET is
received. The HCCHARx.DoPng is cleared only when the Ping token receives an ACK
response. The application is not required to set the HCCHARx.DoPng bit for NAK/NYET
scenarios. This is the difference of proposed flow with respect to current flow. Similar
flow is applicable for Control flow also.
The NAK/NYET status bits in HCINTx registers are updated. The application can
unmask these interrupts when it requires the core to generate an interrupt for
NAK/NYET. The NAK/NYET status is updated because during Xact_err scenarios, this
status provides a means for the application to determine whether the Xact_err occurred
three times consecutively or there were NAK/NYET responses in between two Xact_err.
This provides a mechanism for the application to reset the error counter accordingly. The
application must read the NAK / NYET /ACK along with the xact_err. If NAK / NYET/ ACK
is not set, the Xact_err count must be incremented otherwise application must initialize
the Xact_err count to 1.
Bulk/Control OUT/SETUP
Unmask (ChHltd)
if (ChHltd)
{
if (XferCompl or STALL)
{
Reset Error Count (Error_count=1)
Mask ACK
De-allocate Channel
}
else if (XactErr)
{
if (Nak/Nyet/Ack)
{
Error_count = 1
Rewind Buffer Pointers }
}
else
{
Error_count = Error_count + 1
if (Error_count == 3)
{
De allocate channel
}
else

XMC4500
XMC4000 Family
{
}
}
}
}
else if (ACK)
{
Reset Error Count (Error_count=1)
Mask ACK
}
As soon as the channel is enabled, the core attempts to fetch and write data packets, in
multiples of the maximum packet size, to the transmit FIFO when space is available in
the transmit FIFO and the Request queue. The core stops fetching as soon as the last
packet is fetched.
While continuing the transfer to a high-speed device, the application must set the DoPing
bit before enabling the channel if the previous transaction ended with XacrErr response.
In this case, the core starts with the ping protocol, then automatically switches to Data
Transfer mode.
16.4.7.8 Bulk and Control IN Transactions in DMA Mode

A typical bulk or control IN operation in DMA mode is shown in Figure 16-10. See
channel 2 (ch_2).
The assumptions are:

The application is attempting to receive two maximum-packet-size packets (transfer
The receive FIFO can hold at least one maximum-packet-size packet and two status
DWORDs per packet (72 bytes for FS).
Normal Bulk and Control IN Operations

Page 16-13.
2. The USB host writes an IN request to the Request queue as soon as channel 2
receives the grant from the arbiter. (Arbitration is performed in a round-robin fashion,
with fairness.).

XMC4500
XMC4000 Family
3. The USB host starts writing the received data to the system memory as soon as the
last byte is received with no errors.
4. When the last packet is received, the USB host sets an internal flag to remove any
extra IN requests from the Request queue.
5. The USB host flushes the extra requests.
6. The final request to disable channel 2 is written to the Request queue. At this point,
channel 2 is internally masked for further arbitration.
7. The USB host generates the ChHltd interrupt as soon as the disable request comes
to the top of the queue.
Handling Interrupts
The channel-specific interrupt service routine for bulk and control IN transactions in DMA
mode is shown in the following flow:
Interrupt Service Routines for Bulk/Control Bulk/Control IN Transactions in DMA

Mode
Bulk/Control IN
Unmask (ChHltd)
if (ChHltd) {
if (XferCompl or STALL or BblErr) {
Reset Error Count Mask ACK De-allocate Channel }
else if (XactErr) {
if (Error_count == 2) {
De-allocate Channel
}
else {
Unmask ACK
Unmask NAK
Unmask DataTglErr
Increment Error
Count Re-initialize Channel
}
}
}
else if (ACK or NAK or DataTglErr) {
Reset Error Count
Mask ACK
Mask NAK Mask DataTglErr

XMC4500
XMC4000 Family
}
The application must clear and never modify the DoPing bit after enabling the channel
and until the ChHltd interrupt is received. The core uses the DoPing excessive IN
requests after receiving the last or short packet.
16.4.7.9 Interrupt OUT Transactions in Slave Mode

A typical interrupt OUT operation in Slave mode is shown in Figure 16-12. See channel
1 (ch_1). The assumptions are:
The application is attempting to send one packet in every frame (up to 1 maximum
packet size), starting with the odd frame (transfer size = 1,024 bytes).
The Periodic Transmit FIFO can hold one packet (1 KB for FS).
Periodic Request Queue depth = 4.
Normal Interrupt OUT Operation

Page 16-13. The application must set the HCCHAR1.OddFrm bit.
2. Write the first packet for channel 1. For a high-bandwidth interrupt transfer, the
application must write the subsequent packets up to MC (maximum number of
packets to be transmitted in the next frame times before switching to another
channel).
3. Along with the last DWORD write of each packet, the USB host writes an entry to the
Periodic Request Queue.
4. The USB host attempts to send an OUT token in the next (odd) frame.
5. The USB host generates an XferCompl interrupt as soon as the last packet is
transmitted successfully.
6. In response to the XferCompl interrupt, reinitialize the channel for the next transfer.
Handling Interrupts
The channel-specific interrupt service routine for Interrupt OUT transactions in Slave

XMC4500
XMC4000 Family
Figure 16-12 Normal Interrupt OUT/IN Transactions in Slave Mode

Interrupt Service Routine for Interrupt OUT Transactions in Slave Mode

XMC4500
XMC4000 Family
Interrupt OUT
Unmask (NAK/XactErr/STALL/XferCompl/FrmOvrun)
if (XferCompl)
{
Reset Error Count
Mask ACK
De-allocate Channel
}
else if (STALL or FrmOvrun)
{
Mask ACK
Unmask ChHltd
Disable Channel
if ( STALL)
{
Transfer Done = 1
}
}
else if (NAK or XactErr)
{
Reset Error Count
Mask ACK
Unmask ChHltd
Disable Channel
}
else if (ChHltd)
{
Mask ChHltd
{
De-allocate Channel
}
else
{
Re-initialize Channel (in next b_interval - 1
uF/F)
}
}
else if (ACK)
{
Reset Error Count

XMC4500
XMC4000 Family
Mask ACK
}
The application is expected to write the data packets into the transmit FIFO when the
space is available in the transmit FIFO and the Request queue up to the count specified
in the MC field before switching to another channel. The application uses the
GINTSTS.NPTxFEmp interrupt to find the transmit FIFO space.
16.4.7.10 Interrupt IN Transactions in Slave Mode

A typical interrupt-IN operation in Slave mode is shown in Figure 16-12. See channel 2
(ch_2). The assumptions are:
The application is attempting to receive one packet (up to 1 maximum packet size) in
every frame, starting with odd. (transfer size = 1,024 bytes).
DWORDs per packet (1,031 bytes for FS).
Normal Interrupt IN Operation

1. Initialize channel 2 as explained in Channel Initialization on Page 16-13. The
application must set the HCCHAR2.OddFrm bit.
2. Set the HCCHAR2.ChEna bit to write an IN request to the Periodic Request Queue.
For a high- bandwidth interrupt transfer, the application must write the HCCHAR2
register MC (maximum number of expected packets in the next frame) times before
switching to another channel.
3. The USB host writes an IN request to the Periodic Request Queue for each
HCCHAR2 register write with a ChEna bit set.
4. The USB host attempts to send an IN token in the next (odd) frame.
5. As soon as the IN packet is received and written to the receive FIFO, the USB host
generates an RxFLvl interrupt.
6. In response to the RxFLvl interrupt, read the received packet status to determine the
number of bytes received, then read the receive FIFO accordingly. The application
must mask the RxFLvl interrupt before reading the receive FIFO, and unmask after
reading the entire packet.
7. The core generates the RxFLvl interrupt for the transfer completion status entry in the
receive FIFO. The application must read and ignore the receive packet status when
the receive packet status is not an IN data packet (GRXSTSR.PktSts! = 0010B).
8. The core generates an XferCompl interrupt as soon as the receive packet status is
read.
9. In response to the XferCompl interrupt, read the HCTSIZ2.PktCnt field. If
HCTSIZ2.PktCnt!= 0, disable the channel (as explained in Halting a Channel on
Page 16-14) before re-initializing the channel for the next transfer, if any). If

XMC4500
XMC4000 Family
HCTSIZ2.PktCnt == 0, reinitialize the channel for the next transfer. This time, the
application must reset the HCCHAR2.OddFrm bit.
Handling Interrupts
The channel-specific interrupt service routine for an interrupt IN transaction in Slave
mode is as follows.
Interrupt IN
Unmask (NAK/XactErr/XferCompl/BblErr/STALL/FrmOvrun/DataTglErr)
if (XferCompl)
{
Reset Error Count
Mask ACK
if (HCTSIZx.PktCnt == 0)
{
De-allocate Channel
}
else
{
Transfer Done = 1
Unmask ChHltd
Disable Channel
}
}
else if (STALL or FrmOvrun or NAK or DataTglErr or BblErr)
{
Mask ACK
Unmask ChHltd
Disable Channel
if (STALL or BblErr)
{
Reset Error Count
Transfer Done = 1
}
else if (!FrmOvrun)
{
Reset Error Count
}
}
else if (XactErr)
{

XMC4500
XMC4000 Family
Unmask ACK
Unmask ChHltd
Disable Channel
}
else if (ChHltd)
{
Mask ChHltd
{
De-allocate Channel
}
else Re-initialize Channel (in next b_interval - 1
uF/F)
}
}
else if (ACK)
{
Reset Error Count
Mask ACK
}
The application is expected to write the requests for the same channel when the Request
queue space is available up to the count specified in the MC field before switching to
another channel (if any).
16.4.7.11 Interrupt OUT Transactions in DMA Mode

A typical interrupt OUT operation in DMA mode is shown in Figure 16-13. See channel
The application is attempting to transmit one packet in every frame (up to 1 maximum
packet size of 1,024 bytes).
Normal Interrupt OUT Operation

Page 16-13.
2. The USB host starts fetching the first packet as soon the channel is enabled and
writes the OUT request along with the last DWORD fetch. In high-bandwidth
transfers, the USB host continues fetching the next packet (up to the value specified
in the MC field) before switching to the next channel.
3. The USB host attempts to send the OUT token in the beginning of the next odd frame.

XMC4500
XMC4000 Family
4. After successfully transmitting the packet, the USB host generates a ChHltd interrupt.
5. In response to the ChHltd interrupt, reinitialize the channel for the next transfer.
Figure 16-13 Normal Interrupt OUT/IN Transactions in DMA Mode

XMC4500
XMC4000 Family
Handling Interrupts
The following code sample shows the channel-specific ISR for an interrupt OUT
transaction in DMA mode.
Interrupt Service Routine for Interrupt OUT Transactions in DMA Mode
Interrupt OUT
Unmask (ChHltd)
if (ChHltd)
{
if (XferCompl)
{
Reset Error Count
Mask ACK
if (Transfer Done)
{
De-allocate Channel
}
else
{
Re-initialize Channel (in next b_interval -
1 uF/F)
}
}
else if (STALL)
{
Transfer Done = 1
Reset Error Count
Mask ACK
De-allocate Channel
}
else if (NAK or FrmOvrun)
{
Mask ACK
uF/F)
if (NAK)
{
Reset Error Count

XMC4500
XMC4000 Family
}
}
else if (XactErr)
{
{
De-allocate Channel
}
else
{
Unmask ACK
uF/F)
}
}
}
else if (ACK)
{
Reset Error Count
Mask ACK
}
As soon as the channel is enabled, the core attempts to fetch and write data packets, in
maximum packet size multiples, to the transmit FIFO when the space is available in the
transmit FIFO and the Request queue. The core stops fetching as soon as the last
packet is fetched (the number of packets is determined by the MC field of the HCCHARx
register).
16.4.7.12 Interrupt IN Transactions in DMA Mode

A typical interrupt IN operation in DMA mode is shown in Figure 16-13. See channel 2
(ch_2). The assumptions are:
The application is attempting to receive one packet in every frame (up to 1 maximum
Normal Interrupt IN Operation

The sequence of operations in Figure 16-13 on Page 16-39 (channel 2) is as follows:

XMC4500
XMC4000 Family

Page 16-13.
2. The USB host writes an IN request to the Request queue as soon as the channel 2
gets the grant from the arbiter (round-robin with fairness). In high-bandwidth
transfers, the USB host writes consecutive writes up to MC times.
3. The USB host attempts to send an IN token at the beginning of the next (odd) frame.
4. As soon the packet is received and written to the receive FIFO, the USB host
generates a ChHltd interrupt.
Handling Interrupts
The channel-specific interrupt service routine for Interrupt IN transactions in DMA mode
is as follows.
Interrupt Service Routine for Interrupt IN Transactions in DMA Mode

Unmask (ChHltd)
if (ChHltd)
{
if (XferCompl)
{
Reset Error Count
Mask ACK
if (Transfer Done)
{
De-allocate Channel
}
else
{
Re-initialize Channel (in next b_interval -
1 uF/F)
}
}
else if (STALL or BblErr)
{
Reset Error Count
Mask ACK
De-allocate Channel
}
else if (NAK or DataTglErr or FrmOvrun)
{
Mask ACK
Re-initialize Channel (in next b_interval - 1 uF/F)

XMC4500
XMC4000 Family
if (DataTglErr or NAK)
{
Reset Error Count
}
}
else if (XactErr)
{
{
De-allocate Channel
}
else
{
Unmask ACK
uF/F)
}
}
}
else if (ACK)
{
Reset Error Count
Mask ACK
As soon as the channel is enabled, the core attempts to write the requests into the
Request queue when the space is available up to the count specified in the MC field.
16.4.7.13 Isochronous OUT Transactions in Slave Mode

A typical isochronous OUT operation in Slave mode is shown in Figure 16-14. See
channel 1 (ch_1). The assumptions are:
The application is attempting to send one packet every frame (up to 1 maximum
packet size), starting with an odd frame. (transfer size = 1,024 bytes).
Normal Isochronous OUT Operation

Page 16-13. The application must set the HCCHAR1.OddFrm bit.
2. Write the first packet for channel 1. For a high-bandwidth isochronous transfer, the
application must write the subsequent packets up to MC (maximum number of

XMC4500
XMC4000 Family
packets to be transmitted in the next frame) times before switching to another

channel.
3. Along with the last DWORD write of each packet, the USB host writes an entry to the
Periodic Request Queue.
4. The USB host attempts to send the OUT token in the next frame (odd).
5. The USB host generates the XferCompl interrupt as soon as the last packet is
transmitted successfully.
6. In response to the XferCompl interrupt, reinitialize the channel for the next transfer.

XMC4500
XMC4000 Family
Handling Interrupts
The channel-specific interrupt service routine for isochronous OUT transactions in Slave
Figure 16-14 Normal Isochronous OUT/IN Transactions in Slave Mode

XMC4500
XMC4000 Family
Interrupt Service Routine for Isochronous OUT Transactions in Slave Mode
Isochronous OUT
Unmask (FrmOvrun/XferCompl)
if (XferCompl)
{
De-allocate Channel
}
else if (FrmOvrun)
{
Unmask ChHltd
Disable Channel
}
else if (ChHltd)
{
Mask ChHltd
De-allocate Channel
}
16.4.7.14 Isochronous IN Transactions in Slave Mode

A typical isochronous IN operation in Slave mode is shown in Figure 16-14. See channel
The application is attempting to receive one packet (up to 1 maximum packet size) in
every frame starting with the next odd frame. (transfer size = 1,024 bytes).
Normal Isochronous IN Operation

1. Initialize channel 2 as explained in Channel Initialization on Page 16-13. The
application must set the HCCHAR2.OddFrm bit.
2. Set the HCCHAR2.ChEna bit to write an IN request to the Periodic Request Queue.
For a high- bandwidth isochronous transfer, the application must write the HCCHAR2
register MC (maximum number of expected packets in the next frame) times before
switching to another channel.
3. The USB host writes an IN request to the Periodic Request Queue for each
HCCHAR2 register write with the ChEna bit set.
4. The USB host attempts to send an IN token in the next odd frame.

XMC4500
XMC4000 Family
5. As soon as the IN packet is received and written to the receive FIFO, the USB host
generates an RxFLvl interrupt.
6. In response to the RxFLvl interrupt, read the received packet status to determine the
number of bytes received, then read the receive FIFO accordingly. The application
must mask the RxFLvl interrupt before reading the receive FIFO, and unmask it after
reading the entire packet.
7. The core generates an RxFLvl interrupt for the transfer completion status entry in the
receive FIFO. This time, the application must read and ignore the receive packet
status when the receive packet status is not an IN data packet (GRXSTSR.PktSts!=
0010B).
8. The core generates an XferCompl interrupt as soon as the receive packet status is
read.
9. In response to the XferCompl interrupt, read the HCTSIZ2.PktCnt field. If
HCTSIZ2.PktCnt!= 0, disable the channel (as explained in Halting a Channel on
Page 16-14) before re-initializing the channel for the next transfer, if any. If
HCTSIZ2.PktCnt == 0, reinitialize the channel for the next transfer. This time, the
application must reset the HCCHAR2.OddFrm bit.
Handling Interrupts
The channel-specific interrupt service routine for an isochronous IN transaction in Slave
mode is as follows.
Isochronous IN
Unmask (XactErr/XferCompl/FrmOvrun/BblErr)
if ( XferCompl or FrmOvrun)
{
if (XferCompl and (HCTSIZx.PktCnt == 0))
{
Reset Error Count
De-allocate Channel
}
else
{
Unmask ChHltd
Disable Channel
}
}
else if (XactErr or BblErr)
{
Unmask ChHltd
Disable Channel

XMC4500
XMC4000 Family
}
else if (ChHltd)
{
Mask ChHltd
{
De-allocate Channel
}
else
{
}
}
16.4.7.15 Isochronous OUT Transactions in DMA Mode

A typical isochronous OUT operation in DMA mode is shown in Figure 16-15. See
channel 1 (ch_1). The assumptions are:
The application is attempting to transmit one packet every frame (up to 1 maximum
Normal Isochronous OUT Operation

Page 16-13.
2. The USB host starts fetching the first packet as soon as the channel is enabled, and
writes the OUT request along with the last DWORD fetch. In high-bandwidth
transfers, the USB host continues fetching the next packet (up to the value specified
in the MC field) before switching to the next channel.
3. The USB host attempts to send an OUT token in the beginning of the next (odd)
frame.
4. After successfully transmitting the packet, the USB host generates a ChHltd interrupt.

XMC4500
XMC4000 Family
Handling Interrupts
The channel-specific interrupt service routine for Isochronous OUT transactions in DMA
Figure 16-15 Normal Isochronous OUT/IN Transactions in DMA Mode

XMC4500
XMC4000 Family
Interrupt Service Routine for Isochronous OUT Transactions in DMA Mode
Isochronous OUT
Unmask (ChHltd)
if (ChHltd)
{
if (XferCompl or FrmOvrun)
{
De-allocate Channel
}
}
16.4.7.16 Isochronous IN Transactions in Host DMA Mode

A typical isochronous IN operation in DMA mode is shown in Figure 16-15. See channel
The application is attempting to receive one packet in every frame (up to 1 maximum
DWORDS per packet (1,032 bytes for FS).
Normal Isochronous IN Operation

Page 16-13.
2. The USB host writes an IN request to the Request queue as soon as the channel 2
gets the grant from the arbiter (round-robin with fairness). In high-bandwidth
transfers, the USB host performs consecutive writes up to MC times.
3. The USB host attempts to send an IN token at the beginning of the next (odd) frame.
4. As soon the packet is received and written to the receive FIFO, the USB host
generates a ChHltd interrupt.
Handling Interrupts
The channel-specific interrupt service routine for an isochronous IN transaction in DMA
mode is as follows.
Isochronous IN
Unmask (ChHltd)
if (ChHltd)

XMC4500
XMC4000 Family
{
if ( XferCompl or FrmOvrun)
{
if (XferCompl and (HCTSIZx.PktCnt == 0))
{
Reset Error Count
De-allocate Channel
}
else
{
De-allocate Channel
}
}
else if (XactErr or BblErr)
{
{
De-allocate Channel
}
else
{
Re-enable Channel (in next b_interval - 1 uF/F)
}
}
}

XMC4500
XMC4000 Family
16.5 Host Scatter-Gather DMA Mode
16.5.1 Overview
Note the following points when the host scatter-gather DMA mode is used:
USB core supports non-DWORD aligned address access in Scatter/Gather DMA in
Host mode only
NAK/NYET scenario is handled by USB core in Scatter/Gather DMA mode without
the application's intervention.
CONCAT mode is not supported for any of the flows, that is, a single packet cannot
span more than one descriptor.
16.5.2 SPRAM Requirements

For each channel, the current descriptor pointer and descriptor status are cached to
avoid additional requests to system memory. These are stored in the SPRAM. In
addition, the HCDMAx registers are also implemented in the SPRAM.
16.5.3 Descriptor Memory Structures

In Scatter/Gather DMA mode, the core implements a true scatter-gather memory
distribution in which data buffers are scattered over the system memory. However, the
descriptors themselves are continuous. Each channel memory structure is implemented
as a contiguous list of descriptors; each descriptor points to a data buffer of predefined
size. In addition to the buffer pointer (1 DWORD), the descriptor also has a status quadlet
(1 DWORD). When the list is implemented as a ring buffer, the list processor switches to
the first element of the list when it encounters last bit. All channels (control, bulk,
interrupt, and isochronous) implement these structures in memory.
Note: The descriptors are stored in continuous locations. For example, descriptor 1 is
stored in 32'h0000_0000, descriptor 2 is stored in 32'h0000_0008, descriptor 3 in
32'h0000_0010 and so on. The descriptors are always DWORD aligned.

XMC4500
XMC4000 Family
The descriptor memory structures are displayed in Figure 16-16.
Figure 16-16 Descriptor Memory Structures

All channels must implement the following memory structure:
Each channel has one memory structure
Each data buffer must have a descriptor associated with it to provide the status of the
buffer. The buffer itself contains only raw data.
Each buffer descriptor is two quadlets in length. When the descriptor is ready, the
DMA fetches and processes its data buffer. The buffers to which the descriptor points
hold packet data for non- isochronous channels and packet data corresponding to the
frame data for isochronous channels.
The handshake between the application and core is accomplished by the Active Bit
field in the status quadlet of the descriptor as described below:
A=1 indicates that the descriptor is ready.
A=0 indicates that the descriptor is not ready.

XMC4500
XMC4000 Family
The IN and OUT data memory structures are shown in Figure 16-17. The figure shows
the definition of status quadlet bits for non-ISO and ISO channels.
Figure 16-17 Memory Structure

XMC4500
XMC4000 Family
In addition, a Frame list in memory for Isochronous and Interrupt channels contains
information on the channels that need to be scheduled in a frame. For periodic channels,
USB core reads the list corresponding to the frame number and schedules the channel
that has Ch_sch=1 in the appropriate frame. Figure 16-18 shows the frame list for
periodic channels.
Figure 16-18 Frame List for Periodic Channels

XMC4500
XMC4000 Family
16.5.4 IN Memory Structure

All channels that support IN direction transactions (channels that receive data from the
USB device) must implement a memory structure with the following characteristics:
Each buffer descriptor is two quadlets in length. Table 16-2 displays the IN Data
Memory Structure fields.
Table 16-2 IN Data Memory Structure Values

Bit Bit ID Description
A[31] Active Bit This 1 -bit value indicates whether the descriptor is ready.
For non-isochronous channels, this bit indicates the following:
0B Descriptor is not ready
1B Descriptor is ready. USB core can start processing the
descriptor.
For Isochronous channels, this bit indicates the following:
0B Isochronous channel is not scheduled for the corresponding
frame/fame.
frame/fame.
The application sets this bit when the descriptor is ready. USB
core resets this bit while closing the descriptor. The application
needs to set this bit as a last step after the entire descriptor is
ready. The core resets this bit as a final step of processing the
descriptor. This bit is accessed by both the core and the
application.
Rx Sts Receive This 2-bit field describes the status of the received data. The core
[29:28] Status updates this field when the descriptor is closed. PKTERR is set
by the core when there was an error while receiving the packet.
When updated with PKTERR, it is an indication that IN data has
been received with errors. The error includes Xact_err scenarios.
BUFERR is set by the core when AHB error is encountered
during buffer access. The possible combinations are:
00B Success, No AHB or packet errors
01B PKTERR.
10B Reserved
11B Reserved
This field has to be initialized to 00B by the application and
updated by the core subsequently.

XMC4500
XMC4000 Family
Table 16-2 IN Data Memory Structure Values (contd)

EoL [26] End of For Non Isochronous, it indicates that this is the last descriptor in
List the list, if set. The core does not generate a BNA interrupt for the
next descriptor, if it is unavailable.
For Isochronous, this field is reserved. This field is controlled by
the application.
IOC [25] Interrupt Set by the application, this bit indicates that the core must
On generate a transfer complete interrupt (XferCompl) after this
complete descriptor is finished.
[24] Varies Non Isochronous Reserved Isochronous
[23] Varies Non Isochronous IN Bit: [24:23]
Bit: [23] Bit ID: R: Reserved
Bit ID: AQTD_VALID
Alternate Queue Transfer Descriptor
Valid. When set by the application, if
a Short packet is received, the core
jumps to a new descriptor in the
same list. The new descriptor
address is obtained by replacing the
CTD value of the corresponding
channel with the AQTD value. When
the application resets this bit, the
core ignores AQTD.
[22:17] Varies Non Isochronous IN Isochronous IN Bit
Bit: [23] Bit: [22:12]
Bit ID: AQTD_VALID Bit ID: R Reserved
Alternate Queue Transfer Descriptor
Valid.
This is valid only if AQTD_VALID is
set.
This field gives the offset value in
DWORDS. The core will use this
offset to jump to a new descriptor
address in the same list.

XMC4500
XMC4000 Family

[16:12] Varies Non Isochronous IN
[11] Varies Bit: [16:0] Isochronous IN
Bit ID: Total bytes to transfer Bit: 11:0
This 17-bit value can take values Bit ID: Received
from 0 to 128K-1 bytes, depending on
[10:0] Varies the transfer size of data received Isochronous IN
from the USB device. Bit: [11:0]
Bit ID: Total bytes to
The application programs the transfer
expected transfer size. When the This 11-bit value can take
descriptor is closed, this indicates values from 0 to 4K bytes,
remainder of the transfer size. This depending on the packet
field must be in multiple of MPS for size of data received from
the corresponding end point. the USB host. The
application programs the
The MPS for the various packet types expected transfer size.
are as follows: When the descriptor is
Control - closed, it indicates
LS - 8 bytes remainder of the transfer
FS - 8,16,32,64 bytes size. The maximum
Bulk payload size of each ISO
FS - 8,16,32,64 bytes packet as per USB
Interrupt specification 2.0 is as
LS - up to 8 bytes follows.
FS up to 64 bytes FS - up to 1023 bytes
Note: Note: A value of 0
indicates zero
bytes of data, 1
indicates 1 byte of
data, and so on.
Table 16-3 displays the out buffer pointer field description.
Table 16-3 IN Buffer Pointer

Buf Addr[31:0] Buffer The Buffer pointer field in the descriptor is 32 bits wide and
Address contains the address where the received data is to be
stored in the system memory. The buffer address does not
need to be aligned with DWORD.

XMC4500
XMC4000 Family
16.5.5 OUT Memory Structure

All channels that support OUT direction transactions (channels that transmit data to the
USB device) must implement the following memory structure:
Each buffer must have a descriptor associated with it.
The application fills the data buffer, updates its status in the descriptor, and enables
the channel.
The DMA fetches this descriptor and processes it, moving on in this manner until it
reaches the end of the descriptor chain.
The buffer to which the descriptor points to holds packet data for non-isochronous
channels and frame data for isochronous channels.
Table 16-4 displays the OUT Data Memory Structure fields. Bits that are not present are
reserved to be set to zero by the application for writes and ignored during reads.

XMC4500
XMC4000 Family
Table 16-4 OUT Data Memory Structure Values

A[31] Active Bit This 1 -bit value indicates whether the descriptor is ready.
For non-isochronous channels, this bit indicates the following:
0B Descriptor is not ready
1B Descriptor is ready. USB core can start processing the
descriptor.
For Isochronous channels, this bit indicates the following:
frame.
frame.
The application sets this bit when the descriptor is ready. USB
core resets this bit while closing the descriptor. The application
needs to set this bit as a last step after the entire descriptor is
ready. The core resets this bit as a final step of processing the
descriptor.
Tx Sts Transmit The status of the transmitted data. This reflects if the OUT data
[29:28] Status has been transmitted correctly or with errors. BUFERR is set by
core when there is a AHB error during buffer access along with
asserting AHBERR interrupt (HCINTx register) for the
corresponding channel.
PKTERR is set by the core when there was an error while
transmitting the packet. The
error includes Xact_err scenarios.
The possible combinations are as follows:
00B Success, No AHB errors
01B PKTERR
10B Reserved
11B Reserved
This field has to be initialized to 00B by the application and
updated by the core subsequently.
EoL End of For Non Isochronous, it indicates that this is the last descriptor in
[26] List the list, if set. The core does not generate a BNA interrupt for the
next descriptor, if it is unavailable.
For Isochronous, this field is reserved. This field is controlled by
the application.
IOC[25] Interrupt Set by the application, this bit indicates that the core must
On generate a transfer complete interrupt after this descriptor is
complete finished.

XMC4500
XMC4000 Family
Table 16-4 OUT Data Memory Structure Values (contd)

[24]1) SuP Non Isochronous OUT Isochronous
Setup Packet Reserved: [24:12]
When set, it indicates that the buffer
data pointed by this descriptor is a
setup packet of 8 bytes
[23]1) R Non Isochronous OUT
Setup Packet
Bit: Reserved [23]
Bit ID: Reserved
[22:17]1 Varies Non Isochronous OUT Bit Reserved:
)
[22:17] Bit ID: Reserved
[16:12]1 Varies Non Isochronous OUT OUT Isochronous
)
Bit: [16:0] Bit [11:0]
[11:0]1) Varies Bit ID: Total bytes to transfer. Bit ID: Total bytes to
This 17-bit value can take values transfer.
from 0 to 128K-1 bytes, indicating This 12-bit value can take
the number of bytes of data to be values from 0 to 4K bytes,
transmitted to the USB device. Note: indicating the number of
A Value of 0 indicates zero bytes of bytes of data to be trvValue
data, 1 indicates 1 byte of data and of 0 indicates zero bytes of
so on data, 1 indicates 1 byte of
data, and so on.
1) The meaning of this field varies. See description.

Buf Addr[31:0] Buffer The Buffer pointer field in the descriptor is 32 bits wide and
Address contains the address where the transmit data is to be
stored in the system memory. The buffer address does not
need to be aligned with DWORD.

XMC4500
XMC4000 Family
16.5.6 Host Scatter-Gather DMA Mode Programming Model

This section describes the programming requirements for the USB core operating in
descriptor DMA host mode. It describes how to initialize the channel and provides
information on asynchronous transfers (bulk and control) and periodic transfers
(isochronous and interrupt).
16.5.6.1 Channel Initialization

The application must initialize one or more channels before it can communicate with
connected devices. To initialize and enable a channel, the application must perform the
following steps.
Program the periodic frame list array (for periodic channels).
Program the HFLBAddr register with the base address of the periodic frame list array
(for periodic channels).
Program the HCFG register with PerSchedEn bit set.
Program at least one transfer descriptor in the system memory.
Program the HCDMAx with the pointer to the corresponding descriptor.
Program the GINTMSK register to unmask the Channel Interrupts.
Program the HAINTMSK register to unmask the selected channels' interrupts.
Program the HCINTMSK register to unmask the ChHalt, XferCompl, and BNA.
Program the HCTSIZx register with initial data PID and SCHED_INFO (for periodic
channels). In addition, depending on the number of transfer descriptors, program the
NTD field.
Program the HCCHARx register with the device's endpoint characteristics, such as
type, speed, direction, and so on (The channel can be enabled by setting the channel
enable bit to 1B only when the application is ready to transmit or receive any packet).
16.5.6.2 Asynchronous Transfers

When the application enables an asynchronous (Bulk and Control) channel by writing
into the HCCHARx register, the host controller begins servicing the asynchronous
channel. It reads the referenced (CTD) transfer descriptor qTDn (pointed to by the
HCDMAx register). If the read qTDn is active, the host controller caches the qTDn and
then schedules a transaction. If the read qTDn is inactive, the host controller disables the
channel and generates a Buffer Not Available (BNA) interrupt.
If multiple asynchronous channels are enabled simultaneously, the host controller
caches the referenced transfer descriptor of the entire enabled channels. The host
controller schedules transactions for each enabled channel in round-robin fashion.
When the host controller completes the transfer for a channel, it updates the status
quadlet of the processed qTDn in the system memory.

XMC4500
XMC4000 Family
For a normal completion, the host controller updates the status of the qTDn with no
errors. The host controller completes a transfer normally if one of the following events
occurs:
Short or zero length packet is received for an IN channel.
The allocated buffer is fulfilled with the received data packets for an IN channel.
The allocated buffer is fully transferred to the device for an OUT channel.
When a transfer is completed normally, the host controller attempts to process the next
qTDn from the descriptor list, if the End of List (EOL) bit is not set in the completed qTDn.
where m = AQTD (if IN channel with AQTD_VLD=1 received a short packet) or m = (n +
1) mod (NTD + 1)
If EOL is set, the host controller disables the channel and generates a Channel Halt
interrupt. The transfer complete interrupt is generated for the following conditions.
IOC is set.
EOL is set.
For an abnormal completion, the host controller updates the status of the qTDn with
PKT_ERR. The host controller completes a transfer abnormally if one of the following
events occurs:
STALL response is received from the device.
Excessive transaction errors occurred.
Babble detected.
When a transfer is completed abnormally, the host controller disables the channel and
then generates a Channel Halt interrupt with the appropriate status in HCINT register.
Asynchronous Transfer Descriptor

The application must use separate qTD for different stages of control transfers. A three
stage control transfer uses three qTDs. The same qTD can be reused for performing
different stages of control transfer. The combination of EPType, EPDir fields of the
HCCHARx register, and the SuP flag of the qTD decides the stage of the control transfer.
See Table 16-6.
Table 16-6 Asynchronous Transfer Descriptor

HCCHARx.EP HCCHARx.EP qTD.SuP Control Stage
Type Dir
00B 0 1 SETUP
00B 0 0 Data stage OUT / Status stage OUT
00B 1 0 Data stage IN / Status stage IN
00B 1 1 Invalid

XMC4500
XMC4000 Family
The host controller executes a zero-length OUT transaction if the "Num bytes to
transmit" field of the qTD is initialized to zero for an OUT channel. For an IN channel, the
"Num of bytes received" field of the qTD must be always initialized to an integer multiple
of the maximum packet size.
The application can use one or multiple qTDs for bulk IN and OUT transfers. The number
of qTDs depends on the available consecutive data buffer space and the size of the
transfer. Each qTD can support up to 64KB of consecutive data buffer space.
16.5.6.3 Periodic Transfers

The periodic schedule is used to manage all isochronous and interrupt transfer streams.
The base of the periodic schedule is the periodic frame list. The periodic schedule is
referenced from the register space using the HFLBAddrBase and the HFNUM registers.
The periodic schedule is based on an array of scheduled channels called the periodic
frame list. The periodic frame list implements a sliding window of transactions over time.
When the application enables the periodic schedule (PerSchedEna) in the HCFG
register, the host controller attempts to read an entry from the frame list that corresponds
to the next running frame number at the beginning of each frame.
The periodic frame list can be programmed to 8, 16, 32, or 64 elements. The size of the
periodic frame list should be large enough to support the required b-interval of the least
frequent channel. The least significant bits [15:0] in the periodic frame list elements are
used to identify the scheduled periodic channels (0 through 15) for that corresponding
frame. For example if channel 2 and 6 are periodic channels scheduled for a frame then
the corresponding entry in the periodic frame list will be 0000_0044H.
The host controller should program the SCHED_INFO to 1111_1111B when operating in
Full Speed for all the enabled periodic channels.
Isochronous Transactions
When the application enables an isochronous channel by writing into the HCCHARx
register, the host controller begins servicing the isochronous channel based on the
programmed scheduling (periodic frame list and SCHED_INFO). The application must
use separate qTD for each frame. Each qTD handles a frame of transactions. The
application is expected to allocate a qTD with Active bit zero even if no transaction is
scheduled for a frame. The position of the active qTD determines the b-interval of the
isochronous channel.
The host controller supports high-bandwidth isochronous transfer via the multi-count
(MC) field of the HCCHARx register. The Multi Count represents a transaction count per
frame for the endpoint. If the multi- count is zero, the operation of the host controller is
undefined. Multi-count greater than one is not applicable for the FS host.
For OUT transfers, the value of the "Num bytes to transmit" field represents the total
bytes to be sent during the frame. The application is expected to program the Mult count

XMC4500
XMC4000 Family
field to be the maximum number of packets to be sent in any frame. The host controller
automatically selects the number of packets and its data PID based on the programmed
Xfer Size.
For IN transfers, the host controller issues Mult count transactions. The application is
expected to initialize the "Num bytes received" field to (MC * MaxPktSize).
The host controller does not execute all Multi-count transactions if:
The channel is an OUT and the "Num bytes to transmit" goes to zero before all the
Multi-count transactions have executed (ran out of transmit data) or
The channel is an IN and the endpoint delivers a short packet, or an error occurs on
a transaction before all the Multi-count transaction have been executed.
The channel is an IN and the endpoint delivers a packet with DATA0 PID before all
the Multi-count transaction have been executed.
Each transfer descriptor (qTD) describes one frame of transactions. The host controller
will cache one transfer descriptor in a frame prior to the scheduled frame.
When the application is adding new isochronous transactions to the schedule, it always
performs a read of the HFNUM register to determine the current frame and frame the
host is currently executing. Because there is no information about where in the frame the
host controller is, a constant uncertainty factor of one frame for FS is assumed.
The end of frame (FS) may occur before all of the transaction opportunities are executed.
When this happens, the host controller closes the corresponding descriptor and
proceeds to processing the next scheduled descriptor. If the scheduled descriptor is not
fetched by the host controller due to high system latency, the host controller does not
execute any transaction for that scheduled frame and will skip the descriptor without any
update (that is, without clearing the Active bit).
When a transfer is completed normally, the host controller generates the transfer
complete interrupt only if IOC is set in the completed qTD.
When a transfer is completed abnormally (STALL response or Babble), the host
controller disables the channel and then generates a Channel Halt interrupt with the
appropriate status in HCINT register. The host controller updates the status of the qTD
with PKT_ERR if one of the following conditions occurs:
STALL response is received from the device
Error packet received
Babble detected
Unable to complete all the transactions in the scheduled frame
An example for the FS isochronous scheduling is shown in Figure 16-19. In this figure,
channels 2 and 15 are isochronous channels with b-interval 1ms and 4ms respectively.
The host controller fetches only the qTDs that corresponds to the scheduled frame
(Periodic Frame List entry). The host controller initiates the qTD fetch in the frame prior
to the scheduled frame. If the qTD is active and belongs to an OUT channel, the host

XMC4500
XMC4000 Family
controller also fetches the corresponding data in the previous frame. If this qTD is not
active, the host controller ignores the qTD and does not generate any BNA interrupt.
Figure 16-19 Full Speed Isochronous Transfer Scheduling

XMC4500
XMC4000 Family
Interrupt Transactions
When the application enables an interrupt channel by writing into the HCCHARx register,
the host controller begins servicing the interrupt channel based on the programmed
scheduling (periodic frame list and SCHLD_INFO). It reads the referenced (CTD)
transfer descriptor qTDn (pointed by the HCDMAx register) in the frame prior to the
scheduled frame.
If the read qTDn is active, the host controller caches the qTDn and then schedules a
transaction. If the read qTDn is inactive, the host controller disables the channel and
generates a Buffer Not Available (BNA) interrupt.
When the host controller completes the transfer, it updates the status quadlet of the
processed qTDn in the system memory.
For a normal completion, the host controller updates the status of the qTDn with no
errors. The host controller completes a transfer normally if one of the following events
occurs:
The allocated buffer is fulfilled with the received data packets for an IN channel.
The allocated buffer is fully transferred to the device for an OUT channel.
When a transfer is completed normally, the host controller attempts to process the next
qTDm from the descriptor list if the End of List (EOL) bit is not set in the completed qTDn.
Where m = (n + 1) mod (NTD + 1)
If EOL is set, the host controller disables the channel and generates Channel Halt
interrupt. The transfer complete interrupt will be generated for the following conditions.
IOC is set.
EOL is set.
For an abnormal completion, the host controller updates the status of the qTDn with
PKT_ERR. The host controller completes a transfer abnormally if one of the following
events occurs:
STALL response is received from the device.
Excessive transaction errors occurred.
Babble detected.
When a transfer is completed abnormally, the host controller disables the channel and
then generates a Channel Halt interrupt with the appropriate status in the HCINT
register.
The host controller supports high-bandwidth interrupt transfer through the Multi-count
(MC) field of HCCHARx register. The Multi-count represents a transaction count per
frame for the endpoint. If the Multi-count is zero, the operation of the host controller is
undefined. Multi-count greater than one is not applicable for FS host.
The host controller does not execute all Multi-count transactions in a frame if:

XMC4500
XMC4000 Family
The channel is an OUT and the "Num bytes to transmit" goes to zero before all the
Multi-count transactions have executed (ran out of transmit data) or
The channel is an IN and the endpoint delivers a short packet, or an error occurs on
a transaction before all the Multi-count transaction have been executed.
The channel is an IN and the "Num bytes received" goes to zero before all the Multi-
count transaction are executed (ran out of receive buffer space).

XMC4500
XMC4000 Family
16.6 Device Programming Model
16.6.1 Device Initialization

The application must perform the following steps to initialize the core at device on, power
on, or after a mode change from Host to Device.
1. Program the following fields in DCFG register.
a) DescDMA bit
b) Device Speed
c) NonZero Length Status OUT Handshake
d) Periodic Frame Interval (If Periodic Endpoints are supported)
2. Program the GINTMSK register to unmask the following interrupts.
a) USB Reset
b) Enumeration Done
c) Early Suspend
d) USB Suspend
e) SOF
3. Wait for the GINTSTS.USBReset interrupt, which indicates a reset has been
detected on the USB and lasts for about 10 ms. On receiving this interrupt, the
application must perform the steps listed in Initialization on USB Reset on
Page 16-69.
4. Wait for the GINTSTS.EnumerationDone interrupt. This interrupt indicates the end of
reset on the USB. On receiving this interrupt, the application must read the DSTS
register to determine the enumeration speed and perform the steps listed in
Initialization on Enumeration Completion on Page 16-70.
At this point, the device is ready to accept SOF packets and perform control transfers on
control endpoint 0.
16.6.2 Endpoint Initialization
16.6.2.1 Initialization on USB Reset
1. Set the NAK bit for all OUT endpoints

a) DOEPCTLx.SNAK = 1 (for all OUT endpoints)
2. Unmask the following interrupt bits:
a) DAINTMSK.INEP0 = 1 (control 0 IN endpoint)
b) DAINTMSK.OUTEPO = 1 (control 0 OUT endpoint)
c) DOEPMSK.SETUP = 1
d) DOEPMSK.XferCompl = 1

XMC4500
XMC4000 Family
e) DIEPMSK.XferCompl = 1
f) DIEPMSK.TimeOut = 1
3. To transmit or receive data, the device must initialize more registers as specified in
Device DMA/Slave Mode Initialization on Page 16-72
4. Set up the Data FIFO RAM for each of the FIFOs
a) Program the GRXFSIZ Register, to be able to receive control OUT data and setup
data. At a minimum, this must be equal to 1 max packet size of control endpoint 0
+ 2 DWORDs (for the status of the control OUT data packet) + 10 DWORDs (for
setup packets).
b) Program the dedicated FIFO size register (depending on the FIFO number
chosen) in Dedicated FIFO operation, to be able to transmit control IN data. At a
minimum, this must be equal to 1 max packet size of control endpoint 0.
5. (This step is not required if the Scatter/Gather DMA mode is used.) Program the
following fields in the endpoint-specific registers for control OUT endpoint 0 to receive
a SETUP packet
a) DOEPTSIZ0.SetUP Count = 3 (to receive up to 3 back-to-back SETUP packets)
b) In DMA mode, DOEPDMAO register with a memory address to store any SETUP
packets received
At this point, all initialization required to receive SETUP packets is done, except for
enabling control OUT endpoint 0 in DMA mode.
16.6.2.2 Initialization on Enumeration Completion
1. On the Enumeration Done interrupt (GINTSTS.EnumDone, read the DSTS register

to determine the enumeration speed.
2. Program the DIEPCTLO.MPS field to set the maximum packet size. This step
configures control endpoint 0. The maximum packet size for a control endpoint
depends on the enumeration speed.
3. In DMA mode, program the DOEPCTLO register to enable control OUT endpoint O,
to receive a SETUP packet. In Scatter/Gather DMA mode, the descriptors must be
set up in memory before enabling the endpoint.
a) DOEPCTLO. EPEna = 1
At this point, the device is ready to receive SOF packets and is configured to perform
control transfers on control endpoint O.
16.6.2.3 Initialization on SetAddress Command

This section describes what the application must do when it receives a SetAddress
command in a SETUP packet.
1. Program the DCFG register with the device address received in the SetAddress
command

XMC4500
XMC4000 Family
2. Program the core to send out a status IN packet.
16.6.2.4 Initialization on SetConfiguration/SetInterface Command

This section describes what the application must do when it receives a SetConfiguration
or SetInterface command in a SETUP packet.
1. When a SetConfiguration command is received, the application must program the
endpoint registers to configure them with the characteristics of the valid endpoints in
the new configuration.
2. When a SetInterface command is received, the application must program the
endpoint registers of the endpoints affected by this command.
3. Some endpoints that were active in the prior configuration or alternate setting are not
valid in the new configuration or alternate setting. These invalid endpoints must be
deactivated.
4. For details on a particular endpoint's activation or deactivation, see Endpoint
Activation on Page 16-71 and Endpoint Deactivation on Page 16-72.
5. Unmask the interrupt for each active endpoint and mask the interrupts for all inactive
endpoints in the DAINTMSK register.
6. Set up the Data FIFO RAM for each FIFO. See Data FIFO RAM Allocation on
Page 16-201 for more detail.
7. After all required endpoints are configured, the application must program the core to
send a status IN packet.
At this point, the device core is configured to receive and transmit any type of data
packet.
16.6.2.5 Endpoint Activation

This section describes the steps required to activate a device endpoint or to configure
an existing device endpoint to a new type.
1. Program the characteristics of the required endpoint into the following fields of the
DIEPCTLx register (for IN or bidirectional endpoints) or the DOEPCTLx register (for
OUT or bidirectional endpoints).
a) Maximum Packet Size
b) USB Active Endpoint = 1
c) Endpoint Start Data Toggle (for interrupt and bulk endpoints)
d) Endpoint Type
e) TxFIFO Number
2. Once the endpoint is activated, the core starts decoding the tokens addressed to that
endpoint and sends out a valid handshake for each valid token received for the
endpoint.

XMC4500
XMC4000 Family
16.6.2.6 Endpoint Deactivation

This section describes the steps required to deactivate an existing endpoint.
1. In the endpoint to be deactivated, clear the USB Active Endpoint bit in the DIEPCTLx
register (for IN or bidirectional endpoints) or the DOEPCTLx register (for OUT or
bidirectional endpoints).
2. Once the endpoint is deactivated, the core ignores tokens addressed to that
endpoint, resulting in a timeout on the USB.
16.6.2.7 Device DMA/Slave Mode Initialization

The application must meed the following conditions to set up the device core to handle
traffic.
In Slave mode, GINTMSK.NPTxFEmpMsk, and GINTMSK.RxFLvlMsk must be
unset.
In DMA mode, the aforementioned interrupts must be masked.

XMC4500
XMC4000 Family
16.6.3 Device Programming Operations (Non-Descriptor DMA Mode)

Table 16-7 provides links to the programming sequence for different USB transaction
types.
Table 16-7 Device Programming Operations

Device IN SETUP OUT
Mode
Control
Slave Generic Non-Periodic OUT Data Transfers Generic Non-
(Bulk and Control) IN in Device Slave and Isochronous OUT Data
Data Transfers on Buffer DMA Modes on Transfers in DMA and
Page 16-111 Page 16-76 Slave Modes on
Page 16-88
DMA Generic Non-Periodic OUT Data Transfers Generic Non-
(Bulk and Control) IN in Device Slave and Isochronous OUT Data
Data Transfers on Buffer DMA Modes on Transfers in DMA and
Page 16-111 Page 16-76 Slave Modes on
Page 16-88
Bulk
Slave Generic Non-Periodic - Generic Non-
(Bulk and Control) IN Isochronous OUT Data
Data Transfers on Transfers in DMA and
Page 16-111 Slave Modes on
Page 16-88
DMA Generic Non-Periodic - Generic Non-
(Bulk and Control) IN Isochronous OUT Data
Data Transfers on Transfers in DMA and
Page 16-111 Slave Modes on
Page 16-88

XMC4500
XMC4000 Family
Table 16-7 Device Programming Operations (contd)

Device IN SETUP OUT
Mode
Interrupt
Slave Generic Periodic IN - Generic Non-
(Interrupt and Isochronous OUT Data
Isochronous) Data Transfers in DMA and
Transfers on Slave Modes on
Page 16-118 Page 16-88
Generic Periodic IN Generic Interrupt

Data Transfers Using OUT Data Transfers
the Periodic Transfer Using Periodic
Interrupt Feature on Transfer Interrupt
Page 16-120 Feature on
Page 16-93
DMA Generic Periodic IN - Generic Non-
(Interrupt and Isochronous OUT Data
Isochronous) Data Transfers in DMA and
Transfers on Slave Modes on
Page 16-118 Page 16-88
Generic Periodic IN Generic Interrupt

Data Transfers Using OUT Data Transfers
the Periodic Transfer Using Periodic
Interrupt Feature on Transfer Interrupt
Page 16-120 Feature on
Page 16-93

XMC4500
XMC4000 Family
Table 16-7 Device Programming Operations (contd)

Device IN SETUP OUT
Mode
Isochronous
Slave Generic Periodic IN - Generic Isochronous
(Interrupt and OUT Data Transfer in
Isochronous) Data DMA and Slave
Transfers on Modes on Page 16-92
Page 16-118
Incomplete
Isochronous OUT Data
Transfers in DMA and
Slave Modes on
Page 16-100
DMA Generic Periodic IN - Generic Isochronous
(Interrupt and OUT Data Transfer in
Isochronous) Data DMA and Slave
Transfers on Modes on Page 16-92
Page 16-118
Incomplete
Generic Periodic IN Isochronous OUT Data
Data Transfers Using Transfers in DMA and
the Periodic Transfer Slave Modes on
Interrupt Feature on Page 16-100
Page 16-120

XMC4500
XMC4000 Family
16.6.3.1 OUT Data Transfers in Device Slave and Buffer DMA Modes
This section describes the internal data flow and application-level operations during data
OUT transfers and setup transactions.
Control Setup Transactions

This section describes how the core handles SETUP packets and the application's
sequence for handling setup transactions. To initialize the core after power-on reset, the
application must follow the sequence in Core Initialization on Page 16-7. Before it
can communicate with the host, it must initialize an endpoint as described in Endpoint
Initialization on Page 16-69. See Packet Read from FIFO in Slave Mode on
Page 16-84.
Application Requirements
1. To receive a SETUP packet, the DOEPTSIZx.SUPCnt field in a control OUT endpoint
must be programmed to a non-zero value. When the application programs the
SUPCnt field to a non-zero value, the core receives SETUP packets and writes them
to the receive FIFO, irrespective of the DOEPCTLx.NAK status and
DOEPCTLx.EPEna bit setting. The SUPCnt field is decremented every time the
control endpoint receives a SETUP packet. If the SUPCnt field is not programmed to
a proper value before receiving a SETUP packet, the core still receives the SETUP
packet and decrements the SUPCnt field, but the application possibly is not be able
to determine the correct number of SETUP packets received in the Setup stage of a
control transfer.
a) DOEPTSIZx.SUPCnt = 3
2. In DMA mode, the OUT endpoint must also be enabled, to transfer the received
SETUP packet data from the internal receive FIFO to the external memory.
a) DOEPCTLx.EPEna = 1B
3. The application must always allocate some extra space in the Receive Data FIFO, to
be able to receive up to three SETUP packets on a control endpoint.
a) The space to be Reserved is (4 * n) + 6 DWORDs, where n is the number of control
endpoints supported by the device. Three DWORDs are required for the first
SETUP packet, 1 DWORD is required for the Setup Stage Done DWORD, and 6
DWORDs are required to store two extra SETUP packets among all control
endpoints.
b) 3 DWORDs per SETUP packet are required to store 8 bytes of SETUP data and
4 bytes of SETUP status (Setup Packet Pattern). The core reserves this space in
the receive data
c) FIFO to write SETUP data only, and never uses this space for data packets.
4. In Slave mode, the application must read the 2 DWORDs of the SETUP packet from
the receive FIFO. In DMA mode, the core writes the 2 DWORDs of SETUP data to
the memory.

XMC4500
XMC4000 Family
5. The application must read and discard the Setup Stage Done DWORD from the
receive FIFO.
Internal Data Flow

1. When a SETUP packet is received, the core writes the received data to the receive
FIFO, without checking for available space in the receive FIFO and irrespective of the
endpoint's NAK and Stall bit settings.
a) The core internally sets the IN NAK and OUT NAK bits for the control IN/OUT
endpoints on which the SETUP packet was received.
2. For every SETUP packet received on the USB, 3 DWORDs of data is written to the
receive FIFO, and the SUPCnt field is decremented by 1.
a) The first DWORD contains control information used internally by the core
b) The second DWORD contains the first 4 bytes of the SETUP command
c) The third DWORD contains the last 4 bytes of the SETUP command
3. When the Setup stage changes to a Data IN/OUT stage, the core writes an entry
(Setup Stage Done DWORD) to the receive FIFO, indicating the completion of the
Setup stage.
4. On the AHB side, SETUP packets are emptied either by the DMA or the application.
In DMA mode, the SETUP packets (2 DWORDs) are written to the memory location
programmed in the DOEPDMAx register, only if the endpoint is enabled. If the
endpoint is not enabled, the data remains in the receive FIFO until the enable bit is
set.
5. When either the DMA or the application pops the Setup Stage Done DWORD from
the receive FIFO, the core interrupts the application with a DOEPINTx.SETUP
interrupt, indicating it can process the received SETUP packet.
a) The core clears the endpoint enable bit for control OUT endpoints.
Application Programming Sequence

1. Program the DOEPTSIZx register.
a) DOEPTSIZx.SUPCnt = 3
2. In DMA mode, program the DOEPDMAx register and DOEPCTLx register with the
endpoint characteristics and set the Endpoint Enable bit (DOEPCTLx. EPEna).
a) Endpoint Enable = 1
3. In Slave mode, wait for the GINTSTS.RxFLvl interrupt and empty the data packets
from the receive FIFO, as explained in Packet Read from FIFO in Slave Mode on
Page 16-84. This step can be repeated many times.
4. Assertion of the DOEPINTx.SETUP interrupt marks a successful completion of the
SETUP Data Transfer.
a) On this interrupt, the application must read the DOEPTSIZx register to determine
the number of SETUP packets received and process the last received SETUP
packet.

XMC4500
XMC4000 Family
b) In DMA mode, the application must also determine if the interrupt bit
DOEPINTx.Back2BackSETup is set. This bit is set if the core has received more
than three back- to-back SETUP packets. If this is the case, the application must
ignore the DOEPTSIZx.SUPCnt value and use the DOEPDMAx directly to read
out the last SETUP packet received. DOEPDMAx-8 provides the pointer to the last
valid SETUP data.
Note: If the application has not enabled EP0 before the host sends the SETUP packet,
the core ACKs the SETUP packet and stores it in the FIFO, but does not write to
the memory until EP0 is enabled. When the application enables the EP0 (first
enable) and clears the NAK bit at the same time the Host sends DATA OUT, the
DATA OUT is stored in the RxFIFO. The OTG core then writes the setup data to
the memory and disables the endpoint. Though the application expects a Transfer
Complete interrupt for the Data OUT phase, this does not occur, because the
SETUP packet, rather than the DATA OUT packet, enables EP0 the first time.
Thus, the DATA OUT packet is still in the RxFIFO until the application re-enables
EP0. The application must enable EP0 one more time for the core to process the
DATA OUT packet.
Figure 16-20 charts this flow.

XMC4500
XMC4000 Family
Figure 16-20 Processing a SETUP Packet
Handling More Than Three Back-to-Back SETUP Packets

Per the USB 2.0 specification, normally, during a SETUP packet error, a host does not
send more than three back-to-back SETUP packets to the same endpoint. However, the
USB 2.0 specification does not limit the number of back-to-back SETUP packets a host

XMC4500
XMC4000 Family
can send to the same endpoint. When this condition occurs, the USB core generates an
interrupt (DOEPINTx.Back2BackSETup). In DMA mode, the core also rewinds the DMA
address for that endpoint (DOEPDMAx) and overwrites the first SETUP packet in system
memory with the fourth, second with the fifth, and so on. If the Back2BackSETup
interrupt is asserted, the application must read the OUT endpoint DMA register
(DOEPDMAx) to determine the final SETUP data in system memory.
In DMA mode, the application can mask the Back2BackSETup interrupt, but after
receiving the DOEPINT.SETUP interrupt, the application can read the
DOEPINT.Back2BackSETup interrupt bit. In Slave mode, the application can use the
GINTSTS.RxFLvl interrupt to read out the SETUP packets from the FIFO whenever the
core receives the SETUP packet.

XMC4500
XMC4000 Family
16.6.3.2 Control Transfers in Device Mode

This section describes the various types of control transfers.
Control Write Transfers (SETUP, Data OUT, Status IN)

This section describes control write transfers.

1. Assertion of the DOEPINTx.SETUP Packet interrupt indicates that a valid SETUP
packet has been transferred to the application. See OUT Data Transfers in Device
Slave and Buffer DMA Modes on Page 16-76 for more details. At the end of the
Setup stage, the application must reprogram the DOEPTSIZx.SUPCnt field to 3 to
receive the next SETUP packet.
2. If the last SETUP packet received before the assertion of the SETUP interrupt
indicates a data OUT phase, program the core to perform a control OUT transfer as
explained in Generic Non-Isochronous OUT Data Transfers in DMA and Slave
Modes on Page 16-88.
In DMA mode, the application must reprogram the DOEPDMAx register to receive a
control OUT data packet to a different memory location.
3. In a single OUT data transfer on control endpoint 0, the application can receive up to
64 bytes. If the application is expecting more than 64 bytes in the Data OUT stage,
the application must re-enable the endpoint to receive another 64 bytes, and must
continue to do so until it has received all the data in the Data stage.
4. Assertion of the DOEPINTx.Transfer Compl interrupt on the last data OUT transfer
indicates the completion of the data OUT phase of the control transfer.
5. On completion of the data OUT phase, the application must do the following.
a) To transfer a new SETUP packet in DMA mode, the application must re-enable the
control OUT endpoint as explained in section in section "OUT Data Transfers in
Device Slave and Buffer DMA Modes on Page 16-76.
- DOEPCTLx.EPEna = 1B
b) To execute the received Setup command, the application must program the
required registers in the core. This step is optional, based on the type of Setup
command received.
6. For the status IN phase, the application must program the core as described in
Generic Non-Periodic (Bulk and Control) IN Data Transfers on Page 16-111 to
perform a data IN transfer.
7. Assertion of the DIEPINTx.Transfer Compl interrupt indicates completion of the
status IN phase of the control transfer.
Control Read Transfers (SETUP, Data IN, Status OUT)

This section describes control write transfers.

XMC4500
XMC4000 Family

1. Assertion of the DOEPINTx.SETUP Packet interrupt indicates that a valid SETUP
packet has been transferred to the application. See "OUT Data Transfers in
Device Slave and Buffer DMA Modes on Page 16-76 for more details. At the end
of the Setup stage, the application must reprogram the DOEPTSIZx.SUPCnt field to
3 to receive the next SETUP packet.
2. If the last SETUP packet received before the assertion of the SETUP interrupt
indicates a data IN phase, program the core to perform a control IN transfer as
explained in Generic Non-Periodic (Bulk and Control) IN Data Transfers on
Page 16-111.
3. On a single IN data transfer on control endpoint 0, the application can transmit up to
64 bytes. To transmit more than 64 bytes in the Data IN stage, the application must
re-enable the endpoint to transmit another 64 bytes, and must continue to do so, until
it has transmitted all the data in the Data stage.
4. The DIEPINTx.Transfer Compl interrupt on the last IN data transfer marks the
completion of the control transfer's Data stage.
5. To perform a data OUT transfer in the status OUT phase, the application must
program the core as described in "OUT Data Transfers in Device Slave and
Buffer DMA Modes on Page 16-76.
a) The application must program the DCFG.NZStsOUTHShk handshake field to a
proper setting before transmitting an data OUT transfer for the Status stage.
b) In DMA mode, the application must reprogram the DOEPDMAx register to receive
the control OUT data packet to a different memory location.
6. Assertion of the DOEPINTx.Transfer Compl interrupt indicates completion of the
status OUT phase of the control transfer. This marks the successful completion of the
control read transfer.
control OUT endpoint as explained in "OUT Data Transfers in Device Slave and
Buffer DMA Modes on Page 16-76.
Two-Stage Control Transfers (SETUP/Status IN)

This section describes two-stage control transfers.

1. Assertion of the DOEPINTx.SetUp interrupt indicates that a valid SETUP packet has
been transferred to the application. See "OUT Data Transfers in Device Slave and
Buffer DMA Modes on Page 16-76 for more detail. To receive the next SETUP
packet, the application must reprogram the DOEPTSIZx.SUPCnt field to 3 at the end
of the Setup stage.

XMC4500
XMC4000 Family
2. Decode the last SETUP packet received before the assertion of the SETUP interrupt.
If the packet indicates a two-stage control command, the application must do the
following.
control OUT endpoint. See "OUT Data Transfers in Device Slave and Buffer
DMA Modes on Page 16-76 for details.
b) Depending on the type of Setup command received, the application can be
required to program registers in the core to execute the received Setup command.
3. For the status IN phase, the application must program the core described in
Generic Non-Periodic (Bulk and Control) IN Data Transfers on Page 16-111 to
perform a data IN transfer.
4. Assertion of the DIEPINTx.Transfer Compl interrupt indicates the completion of the
status IN phase of the control transfer.
Example: Two-Stage Control Transfer

These notes refer to Figure 16-21.
1. SETUP packet #1 is received on the USB and is written to the receive FIFO, and the
core responds with an ACK handshake. This handshake is lost and the host detects
a timeout.
2. The SETUP packet in the receive FIFO results in a GINTSTS.RxFLvl interrupt to the
application, causing the application to empty the receive FIFO.
3. SETUP packet #2 on the USB is written to the receive FIFO, and the core responds
with an ACK handshake.
4. The SETUP packet in the receive FIFO sends the application the GINTSTS.RxFLvl
interrupt and the application empties the receive FIFO.
5. After the second SETUP packet, the host sends a control IN token for the status
phase. The core issues a NAK response to this token, and writes a Setup Stage Done
entry to the receive FIFO. This entry results in a GINTSTS.RxFLvl interrupt to the
application, which empties the receive FIFO. After reading out the Setup Stage Done
DWORD, the core asserts the DOEPINTx.SetUp packet interrupt to the application.
6. On this interrupt, the application processes SETUP Packet #2, decodes it to be a two-
stage control command, and clears the control IN NAK bit.
a) DIEPCTLx.CNAK = 1
7. When the application clears the IN NAK bit, the core interrupts the application with a
DIEPINTx.INTknTXFEmp. On this interrupt, the application enables the control IN
endpoint with a DIEPTSIZx.XferSize of 0 and a DIEPTSIZx.PktCnt of 1. This results
in a zero-length data packet for the status IN token on the USB.
8. At the end of the status IN phase, the core interrupts the application with a
DIEPINTx.XferCompl interrupt.

XMC4500
XMC4000 Family
Figure 16-21 Two-Stage Control Transfer
Packet Read from FIFO in Slave Mode

This section describes how to read packets (OUT data and SETUP packets) from the
receive FIFO in Slave mode.
1. On catching a GINTSTS.RxFLvl interrupt, the application must read the Receive
Status Pop register (GRXSTSP).
2. The application can mask the GINTSTS.RxFLvl interrupt by writing to
GINTMSK.RxFLvl = 0B, until it has read the packet from the receive FIFO.

XMC4500
XMC4000 Family
3. If the received packet's byte count is not 0, the byte count amount of data is popped
from the receive Data FIFO and stored in memory. If the received packet byte count
is 0, no data is popped from the Receive Data FIFO.
4. The receive FIFO's packet status readout indicates one of the following.
5. Global OUT NAK Pattern: PktSts = Global OUT NAK, BCnt = 11'h000, EPNum =
Dont Care (4'h0), DPID = Dont Care (00B). This data indicates that the global OUT
NAK bit has taken effect.
a) SETUP Packet Pattern: PktSts = SETUP, BCnt = 11'h008, EPNum = Control EP
Num, DPID = D0. This data indicates that a SETUP packet for the specified
endpoint is now available for reading from the receive FIFO.
b) Setup Stage Done Pattern: PktSts = Setup Stage Done, BCnt = 11'h0, EPNum =
Control EP Num, DPID = Don't Care (00B). This data indicates that the Setup stage
for the specified endpoint has completed and the Data stage has started. After this
entry is popped from the receive FIFO, the core asserts a Setup interrupt on the
specified control OUT endpoint.
c) Data OUT Packet Pattern: PktSts = DataOUT, BCnt = size of the Received data
OUT packet (0 < BCnt <1,024), EPNum = EPNum on which the packet was
received, DPID = Actual Data PID.
d) Data Transfer Completed Pattern: PktSts = Data OUT Transfer Done, BCnt =
11'h0, EPNum = OUT EP Num on which the data transfer is complete, DPID =
Dont Care (00B). This data indicates that a OUT data transfer for the specified OUT
endpoint has completed. After this entry is popped from the receive FIFO, the core
asserts a Transfer Completed interrupt on the specified OUT endpoint.
The encoding for the PktSts is listed in Receive Status Debug Read/Status
Read and Pop Registers (GRXSTSR/GRXSTSP) on Page 16-246.
6. After the data payload is popped from the receive FIFO, the GINTSTS.RxFLvl
interrupt must be unmasked.
7. Steps 1-5 are repeated every time the application detects assertion of the interrupt
line due to GINTSTS.RxFLvl. Reading an empty receive FIFO can result in undefined
core behavior.

XMC4500
XMC4000 Family
Figure 16-22 provides a flow chart of this procedure.
Figure 16-22 Receive FIFO Packet Read in Slave Mode
Setting the Global OUT NAK
Internal Data Flow

1. When the application sets the Global OUT NAK (DCTL.SGOUTNak), the core stops
writing data, except SETUP packets, to the receive FIFO. Irrespective of the space
availability in the receive FIFO, non-isochronous OUT tokens receive a NAK
handshake response, and the core ignores isochronous OUT data packets
2. The core writes the Global OUT NAK pattern to the receive FIFO. The application
must reserve enough receive FIFO space to write this data pattern. See Data FIFO
RAM Allocation on Page 16-201.
3. When either the core (in DMA mode) or the application (in Slave mode) pops the
Global OUT NAK pattern DWORD from the receive FIFO, the core sets the
GINTSTS.GOUTNakEff interrupt.

XMC4500
XMC4000 Family
4. Once the application detects this interrupt, it can assume that the core is in Global
OUT NAK mode. The application can clear this interrupt by clearing the
DCTL.SGOUTNak bit.

1. To stop receiving any kind of data in the receive FIFO, the application must set the
Global OUT NAK bit by programming the following field.
a) DCTL.SGOUTNak = 1B
2. Wait for the assertion of the interrupt GINTSTS.GOUTNakEff. When asserted, this
interrupt indicates that the core has stopped receiving any type of data except
SETUP packets.
3. The application can receive valid OUT packets after it has set DCTL.SGOUTNak and
before the core asserts the GINTSTS.GOUTNakEff interrupt.
4. The application can temporarily mask this interrupt by writing to the
GINTMSK.GINNakEffMsk bit.
a) GINTMSK.GINNakEffMsk = 0B
5. Whenever the application is ready to exit the Global OUT NAK mode, it must clear
the DCTL.SGOUTNak bit. This also clears the GINTSTS.GOUTNakEff interrupt.
a) DCTL.CGOUTNak = 1B
6. If the application has masked this interrupt earlier, it must be unmasked as follows:
a) GINTMSK.GINNakEffMsk = 1B
Disabling an OUT Endpoint

The application must use this sequence to disable an OUT endpoint that it has enabled.

1. Before disabling any OUT endpoint, the application must enable Global OUT NAK
mode in the core, as described in Setting the Global OUT NAK on Page 16-86.
a) DCTL.DCTL.SGOUTNak = 1B
2. Wait for the GINTSTS.GOUTNakEff interrupt
3. Disable the required OUT endpoint by programming the following fields.
a) DOEPCTLx.EPDisable = 1B
b) DOEPCTLx.SNAK = 1B
4. Wait for the DOEPINTx.EPDisabled interrupt, which indicates that the OUT endpoint
is completely disabled. When the EPDisabled interrupt is asserted, the core also
clears the following bits.
a) DOEPCTLx.EPDisable = 0B
b) DOEPCTLx.EPEnable = 0B
5. The application must clear the Global OUT NAK bit to start receiving data from other
non-disabled OUT endpoints.
a) DCTL.SGOUTNak = 0B

XMC4500
XMC4000 Family
Stalling a Non-Isochronous OUT Endpoint

This section describes how the application can stall a non-isochronous endpoint.
1. Put the core in the Global OUT NAK mode, as described in Setting the Global OUT
NAK on Page 16-86.
2. Disable the required endpoint, as described in Disabling an OUT Endpoint on
Page 16-87.
a) When disabling the endpoint, instead of setting the DOEPCTL.SNAK bit, set
DOEPCTL.STALL = 1.
- The Stall bit always takes precedence over the NAK bit.
3. When the application is ready to end the STALL handshake for the endpoint, the
DOEPCTLx.STALL bit must be cleared.
4. If the application is setting or clearing a STALL for an endpoint due to a
SetFeature.Endpoint Halt or ClearFeature.Endpoint Halt command, the Stall bit must
be set or cleared before the application sets up the Status stage transfer on the
control endpoint.
Generic Non-Isochronous OUT Data Transfers in DMA and Slave Modes

This section describes a regular non-isochronous OUT data transfer (control, bulk, or
interrupt).
1. Before setting up an OUT transfer, the application must allocate a buffer in the
memory to accommodate all data to be received as part of the OUT transfer, then
program that buffer's size and start address (in DMA mode) in the endpoint-specific
registers.
2. For OUT transfers, the Transfer Size field in the endpoint's Transfer Size register
must be a multiple of the maximum packet size of the endpoint, adjusted to the
DWORD boundary.
a) transfer size[epnum] = n * (mps[epnum] + 4 - (mps[epnum] mod 4))
b) packet count[epnum] = n
c) n > 0
3. In DMA mode, the core stores a received data packet in the memory, always starting
on a DWORD boundary. If the maximum packet size of the endpoint is not a multiple
of 4, the core inserts byte pads at end of a maximum-packet-size packet up to the
end of the DWORD.
4. On any OUT endpoint interrupt, the application must read the endpoint's Transfer
Size register to calculate the size of the payload in the memory. The received payload
size can be less than the programmed transfer size.
a) Payload size in memory = application-programmed initial transfer size - core
updated final transfer size

XMC4500
XMC4000 Family
b) Number of USB packets in which this payload was received = application-

programmed initial packet count - core updated final packet count
Internal Data Flow

1. The application must set the Transfer Size and Packet Count fields in the endpoint-
specific registers, clear the NAK bit, and enable the endpoint to receive the data.
2. Once the NAK bit is cleared, the core starts receiving data and writes it to the receive
FIFO, as long as there is space in the receive FIFO. For every data packet received
on the USB, the data packet and its status are written to the receive FIFO. Every
packet (maximum packet size or short packet) written to the receive FIFO
decrements the Packet Count field for that endpoint by 1.
a) OUT data packets received with Bad Data CRC are flushed from the receive FIFO
automatically.
b) After sending an ACK for the packet on the USB, the core discards non-
isochronous OUT data packets that the host, which cannot detect the ACK, re-
sends. The application does not detect multiple back-to-back data OUT packets
on the same endpoint with the same data PID. In this case the packet count is not
decremented.
c) If there is no space in the receive FIFO, isochronous or non-isochronous data
packets are ignored and not written to the receive FIFO. Additionally, non-
isochronous OUT tokens receive a NAK handshake reply.
d) In all the above three cases, the packet count is not decremented because no data
is written to the receive FIFO.
3. When the packet count becomes 0 or when a short packet is received on the
endpoint, the NAK bit for that endpoint is set. Once the NAK bit is set, the isochronous
or non-isochronous data packets are ignored and not written to the receive FIFO, and
non-isochronous OUT tokens receive a NAK handshake reply.
4. After the data is written to the receive FIFO, either the application (in Slave mode) or
the core's DMA engine (in External or Internal DMA mode), reads the data from the
receive FIFO and writes it to external memory, one packet at a time per endpoint.
5. At the end of every packet write on the AHB to external memory, the transfer size for
the endpoint is decremented by the size of the written packet.
6. The OUT Data Transfer Completed pattern for an OUT endpoint is written to the
receive FIFO on one of the following conditions.
a) The transfer size is 0 and the packet count is 0
b) The last OUT data packet written to the receive FIFO is a short packet (0 ^packet
size < maximum packet size)
7. When either the application or the DMA pops this entry (OUT Data Transfer
Completed), a Transfer Completed interrupt is generated for the endpoint and the
endpoint enable is cleared.

XMC4500
XMC4000 Family

1. Program the DOEPTSIZx register for the transfer size and the corresponding packet
count. Additionally, in DMA mode, program the DOEPDMAx register.
2. Program the DOEPCTLx register with the endpoint characteristics, and set the
Endpoint Enable and ClearNAK bits.
a) DOEPCTLx.EPEna = 1
b) DOEPCTLx.CNAK = 1
3. In Slave mode, wait for the GINTSTS.Rx StsQ level interrupt and empty the data
packets from the receive FIFO as explained in Packet Read from FIFO in Slave
Mode on Page 16-84.
a) This step can be repeated many times, depending on the transfer size.
4. Asserting the DOEPINTx.XferCompl interrupt marks a successful completion of the
non- isochronous OUT data transfer.
5. Read the DOEPTSIZx register to determine the size of the received data payload.

XMC4500
XMC4000 Family
Slave Mode Bulk OUT Transaction

Figure 16-23 depicts the reception of a single bulk OUT data packet from the USB to the
AHB and describes the events involved in the process.
Figure 16-23 Slave Mode Bulk OUT Transaction

After a SetConfiguration/SetInterface command, the application initializes all OUT
endpoints by setting DOEPCTLx.CNAK = 1 and DOEPCTLx.EPEna = 1, and setting a
suitable XferSize and PktCnt in the DOEPTSIZx register.
1. Host attempts to send data (OUT token) to an endpoint.
2. When the core receives the OUT token on the USB, it stores the packet in the
RxFIFO because space is available there.
3. After writing the complete packet in the RxFIFO, the core then asserts the
GINTSTS.RxFLvl interrupt.
4. On receiving the PktCnt number of USB packets, the core sets the NAK bit for this
endpoint internally to prevent it from receiving any more packets.
5. The application processes the interrupt and reads the data from the RxFIFO.

XMC4500
XMC4000 Family
6. When the application has read all the data (equivalent to XferSize), the core
generates a DOEPINTx.XferCompl interrupt.
7. The application processes the interrupt and uses the setting of the
DOEPINTx.XferCompl interrupt bit to determine that the intended transfer is
complete.
Generic Isochronous OUT Data Transfer in DMA and Slave Modes

This section describes a regular isochronous OUT data transfer.
1. All the application requirements for non-isochronous OUT data transfers also apply
to isochronous OUT data transfers
2. For isochronous OUT data transfers, the Transfer Size and Packet Count fields must
always be set to the number of maximum-packet-size packets that can be received
in a single frame and no more. Isochronous OUT data transfers cannot span more
than 1 frame.
a) 1 <= packet count[epnum] <= 3
3. In Slave mode, when isochronous OUT endpoints are supported in the device, the
application must read all isochronous OUT data packets from the receive FIFO (data
and status) before the end of the periodic frame (GINTSTS.EOPF interrupt). In DMA
mode, the application must guarantee enough bandwidth to allow emptying the
isochronous OUT data packet from the receive FIFO before the end of each periodic
frame.
4. To receive data in the following frame, an isochronous OUT endpoint must be
enabled after the GINTSTS.EOPF and before the GINTSTS.SOF.
Internal Data Flow

1. The internal data flow for isochronous OUT endpoints is the same as that for non-
isochronous OUT endpoints, but for a few differences.
2. When an isochronous OUT endpoint is enabled by setting the Endpoint Enable and
clearing the NAK bits, the Even/Odd frame bit must also be set appropriately. The
core receives data on a isochronous OUT endpoint in a particular frame only if the
following condition is met.
a) DOEPCTLx.Even/Odd frame = DSTS.SOFFN[0]
3. When either the application or the external/internal DMA completely reads an
isochronous OUT data packet (data and status) from the receive FIFO, the core
updates the DOEPTSIZx.Received DPID field with the data PID of the last
isochronous OUT data packet read from the receive FIFO.

XMC4500
XMC4000 Family

1. Program the DOEPTSIZx register for the transfer size and the corresponding packet
count. When in DMA mode, also program the DOEPDMAx register.
2. Program the DOEPCTLx register with the endpoint characteristics and set the
Endpoint Enable, ClearNAK, and Even/Odd frame bits.
a) Endpoint Enable = 1
b) CNAK=1
c) Even/Odd frame = (0: Even/1: Odd)
3. In Slave mode, wait for the GINTSTS.Rx StsQ level interrupt and empty the data
packets from the receive FIFO as explained in Packet Read from FIFO in Slave
Mode on Page 16-84.
a) This step can be repeated many times, depending on the transfer size.
4. The assertion of the DOEPINTx.XferCompl interrupt marks the completion of the
isochronous OUT data transfer. This interrupt does not necessarily mean that the
data in memory is good.
5. This interrupt can not always be detected for isochronous OUT transfers. Instead, the
application can detect the GINTSTS.incomplete Isochronous OUT data interrupt.
See Incomplete Isochronous OUT Data Transfers in DMA and Slave Modes
on Page 16-100, for more details
6. Read the DOEPTSIZx register to determine the size of the received transfer and to
determine the validity of the data received in the frame. The application must treat the
data received in memory as valid only if one of the following conditions is met.
a) DOEPTSIZx.RxDPID = D0 and the number of USB packets in which this payload
was received = 1
b) DOEPTSIZx.RxDPID = D1 and the number of USB packets in which this payload
was received = 2
c) DOEPTSIZx.RxDPID = D2 and the number of USB packets in which this payload
was received = 3
7. The number of USB packets in which this payload was received = App Programmed
Initial Packet Count - Core Updated Final Packet Count
The application can discard invalid data packets.
Generic Interrupt OUT Data Transfers Using Periodic Transfer Interrupt Feature
This section describes a regular INTR OUT data transfer with the Periodic Transfer
Interrupt feature.
1. Before setting up a periodic OUT transfer, the application must allocate a buffer in the
memory to accommodate all data to be received as part of the OUT transfer, then
program that buffer's size and start address in the endpoint-specific registers.

XMC4500
XMC4000 Family
2. For Interrupt OUT transfers, the Transfer Size field in the endpoint's Transfer Size
register must be a multiple of the maximum packet size of the endpoint, adjusted to
the DWORD boundary. The Transfer Size programmed can span across multiple
frames based on the periodicity after which the application want to receive the
DOEPINTx.XferCompl interrupt
3. transfer size[epnum] = n * (mps[epnum] + 4 - (mps[epnum] mod 4))
4. packet count[epnum] = n
5. n > 0 (Higher value of n reduces the periodicity of the DOEPINTx.XferCompl
interrupt)
6. 1 < packet count[epnum] < n (Higher value of n reduces the periodicity of the
DOEPINTx.XferCompl interrupt)
end of the DWORD. The application will not be informed about the frame number on
which a specific packet has been received.
8. On DOEPINTx.XferCompl interrupt, the application must read the endpoint's
Transfer Size register to calculate the size of the payload in the memory. The
received payload size can be less than the programmed transfer size.
9. Payload size in memory = application-programmed initial transfer size - core updated
final transfer size
10. Number of USB packets in which this payload was received = application-
programmed initial packet count - core updated final packet count.
11. If for some reason, the host stops sending tokens, there are no interrupts to the
application, and the application must timeout on its own.
interrupt OUT data transfer. This interrupt does not necessarily mean that the data in
memory is good.
13. Read the DOEPTSIZx register to determine the size of the received transfer and to
determine the validity of the data received in the frame.
Internal Data Flow

specific registers, clear the NAK bit, and enable the endpoint to receive the data.
2. The application must mask the GINTSTS.incompISOOUT.
3. The application must enable the DCTL.IgnrFrmNum
4. When an interrupt OUT endpoint is enabled by setting the Endpoint Enable and
clearing the NAK bits, the Even/Odd frame will be ignored by the core.

XMC4500
XMC4000 Family
6. OUT data packets received with Bad Data CRC or any packet error are flushed from
the receive FIFO automatically.
7. Interrupt packets with PID errors are not passed to application. Core discards the
packet, sends ACK and does not decrement packet count.
8. If there is no space in the receive FIFO, interrupt data packets are ignored and not
written to the receive FIFO. Additionally, interrupt OUT tokens receive a NAK
handshake reply.
endpoint, the NAK bit for that endpoint is set. Once the NAK bit is set, the isochronous
or interrupt data packets are ignored and not written to the receive FIFO, and
interrupt OUT tokens receive a NAK handshake reply.
10. After the data is written to the receive FIFO, the core's DMA engine reads the data
from the receive FIFO and writes it to external memory, one packet at a time per
endpoint.
13. The transfer size is 0 and the packet count is 0.
14. The last OUT data packet written to the receive FIFO is a short packet (0 < packet
size < maximum packet size)
15. When either the application or the DMA pops this entry (OUT Data Transfer
Completed), a Transfer Completed interrupt is generated for the endpoint and the
endpoint enable is cleared.
Generic Isochronous OUT Data Transfers Using Periodic Transfer Interrupt

Feature
This section describes a regular isochronous OUT data transfer with the Periodic
Transfer Interrupt feature.
1. Before setting up ISOC OUT transfers spanned across multiple frames, the
application must allocate buffer in the memory to accommodate all data to be
received as part of the OUT transfers, then program that buffer's size and start
address in the endpoint-specific registers.
a) The application must mask the GINTSTS.incomp ISO OUT.
b) The application must enable the DCTL.IgnrFrmNum
2. For ISOC transfers, the Transfer Size field in the DOEPTSIZx.XferSize register must
be a multiple of the maximum packet size of the endpoint, adjusted to the DWORD
boundary. The Transfer Size programmed can span across multiple frames based on

XMC4500
XMC4000 Family
the periodicity after which the application wants to receive the DOEPINTx.XferCompl
interrupt
a) transfer size[epnum] = n * (mps[epnum] + 4 - (mps[epnum] mod 4))
b) packet count[epnum] = n
c) n > 0 (Higher value of n reduces the periodicity of the DOEPINTx.XferCompl
interrupt)
d) 1 =< packet count[epnum] =< n (Higher value of n reduces the periodicity of the
DOEPINTx.XferCompl interrupt).
end of the DWORD. The application will not be informed about the frame number and
the PID value on which a specific OUT packet has been received.
isochronous OUT data transfer. This interrupt does not necessarily mean that the
data in memory is good.
a) On DOEPINTx.XferCompl, the application must read the endpoint's Transfer Size
register to calculate the size of the payload in the memory.
b) Payload size in memory = application-programmed initial transfer size - core
c) Number of USB packets in which this payload was received = application-
d) If for some reason, the host stop sending tokens, there will be no interrupt to the
application, and the application must timeout on its own.
5. The assertion of the DOEPINTx.XferCompl can also mark a packet drop on USB due
to unavailability of space in the RxFifo or due to any packet errors.
a) The application must read the DOEPINTx.PktDrpSts (DOEPINTx.Bit[11] is now
used as the DOEPINTx.PktDrpSts) register to differentiate whether the
DOEPINTx.XferCompl was generated due to the normal end of transfer or due to
dropped packets. In case of packets being dropped on the USB due to
unavailability of space in the RxFifo or due to any packet errors the endpoint
enable bit is cleared.
b) In case of packet drop on the USB application must re-enable the endpoint after
recalculating the values DOEPTSIZx.XferSize and DOEPTSIZx.PktCnt.
c) Payload size in memory = application-programmed initial transfer size - core
d) Number of USB packets in which this payload was received = application-
Note: Due to application latencies it is possible that DOEPINT.XferComplete interrupt is
generated without DOEPINT.PktDrpSts being set, This scenario is possible only
if back-to-back packets are dropped for consecutive frames and the PktDrpSts is
merged, but the XferSize and PktCnt values for the endpoint are nonzero. In this

XMC4500
XMC4000 Family
case, the application must proceed further by programming the PktCnt and
XferSize register for the next frame, as it would if PktDrpSts were being set.

XMC4500
XMC4000 Family
Figure 16-24 gives the application flow for Isochronous OUT Periodic Transfer Interrupt
feature.
Figure 16-24 ISOC OUT Application Flow for Periodic Transfer Interrupt Feature

XMC4500
XMC4000 Family
Internal Data Flow

1. The application must set the Transfer Size, Packets to be received in a frame and
Packet Count Fields in the endpoint-specific registers, clear the NAK bit, and enable
the endpoint to receive the data.
endpoint, the NAK bit for that endpoint is set. Once the NAK bit is set, the ISOC
packets are ignored and not written to the receive FIFO.
5. After the data is written to the receive FIFO, the core's DMA engine, reads the data
from the receive FIFO and writes it to external memory, one packet at a time per
endpoint.
a) The transfer size is 0 and the packet count is 0
b) The last OUT data packet written to the receive FIFO is a short packet (0 < packet
size < maximum packet size).
8. When the DMA pops this entry (OUT Data Transfer Completed), a Transfer
Completed interrupt is generated for the endpoint or the endpoint enable is cleared.
9. OUT data packets received with Bad Data CRC or any packet error are flushed from
the receive FIFO automatically.
a) In these two cases, the packet count and transfer size registers are not
decremented because no data is written to the receive FIFO.

XMC4500
XMC4000 Family
Figure 16-25 Isochronous OUT Core Internal Flow for Periodic Transfer Interrupt
Feature
Incomplete Isochronous OUT Data Transfers in DMA and Slave Modes

This section describes the application programming sequence when isochronous OUT
data packets are dropped inside the core.
Internal Data Flow

1. For isochronous OUT endpoints, the DOEPINTx.XferCompl interrupt possibly is not
always asserted. If the core drops isochronous OUT data packets, the application
could fail to detect the DOEPINTx.XferCompl interrupt under the following
circumstances.
a) When the receive FIFO cannot accommodate the complete ISO OUT data packet,
the core drops the received ISO OUT data.

XMC4500
XMC4000 Family
b) When the isochronous OUT data packet is received with CRC errors
c) When the isochronous OUT token received by the core is corrupted
d) When the application is very slow in reading the data from the receive FIFO
2. When the core detects an end of periodic frame before transfer completion to all
isochronous OUT endpoints, it asserts the GINTSTS.incomplete Isochronous OUT
data interrupt, indicating that a DOEPINTx.XferCompl interrupt is not asserted on at
least one of the isochronous OUT endpoints. At this point, the endpoint with the
incomplete transfer remains enabled, but no active transfers remains in progress on
this endpoint on the USB.
3. This step is applicable only if the OTG core is operating in slave mode. Application
Programming Sequence
4. This step is applicable only if the OTG core is operating in slave mode. Asserting the
GINTSTS.incomplete Isochronous OUT data interrupt indicates that in the current
frame, at least one isochronous OUT endpoint has an incomplete transfer.
5. If this occurs because isochronous OUT data is not completely emptied from the
endpoint, the application must ensure that the DMA or the application empties all
isochronous OUT data (data and status) from the receive FIFO before proceeding.
a) When all data is emptied from the receive FIFO, the application can detect the
DOEPINTx.XferCompl interrupt. In this case, the application must re-enable the
endpoint to receive isochronous OUT data in the next frame, as described in
Generic Isochronous OUT Data Transfer in DMA and Slave Modes on
Page 16-92.
6. When it receives a GINTSTS.incomplete Isochronous OUT data interrupt, the
application must read the control registers of all isochronous OUT endpoints
(DOEPCTLx) to determine which endpoints had an incomplete transfer in the current
frame. An endpoint transfer is incomplete if both the following conditions are met.
a) DOEPCTLx.Even/Odd frame bit = DSTS.SOFFN[0]
b) DOEPCTLx.Endpoint Enable = 1
7. The previous step must be performed before the GINTSTS.SOF interrupt is detected,
to ensure that the current frame number is not changed.
8. For isochronous OUT endpoints with incomplete transfers, the application must
discard the data in the memory and disable the endpoint by setting the
DOEPCTLx.Endpoint Disable bit.
9. Wait for the DOEPINTx.Endpoint Disabled interrupt and enable the endpoint to
receive new data in the next frame as explained in Generic Isochronous OUT Data
Transfer in DMA and Slave Modes on Page 16-92.
a) Because the core can take some time to disable the endpoint, the application
possibly is not able to receive the data in the next frame after receiving bad
isochronous data.

XMC4500
XMC4000 Family
16.6.3.3 IN Data Transfers in Device Slave and Buffer DMA Modes

This section describes the internal data flow and application-level operations during IN
data transfers.
Packet Write in Slave Mode
Setting IN Endpoint NAK
IN Endpoint Disable
Bulk IN Stall
Incomplete Isochronous IN Data Transfers
Stalling Non-Isochronous IN Endpoints
Non-Periodic IN Endpoint Sequencing
Worst-Case Response Time
Choosing the Value of GUSBCFG.USBTrdTim
Handling Babble Conditions
Generic Non-Periodic (Bulk and Control) IN Data Transfers
Examples
Generic Periodic IN (Interrupt and Isochronous) Data Transfers
Generic Periodic IN Data Transfers Using the Periodic Transfer Interrupt
Feature
Packet Write in Slave Mode

This section describes how the application writes data packets to the endpoint FIFO in
Slave mode with dedicated transmit FIFOs.
1. The application can either choose polling or interrupt mode.
a) In polling mode, application monitors the status of the endpoint transmit data FIFO,
by reading the DTXFSTSx register, to determine, if there is enough space in the
data FIFO.
b) In interrupt mode, application waits for the DIEPINTx.TxFEmp interrupt and then
reads the DTXFSTSx register, to determine, if there is enough space in the data
FIFO.
c) To write a single non-zero length data packet, there must be space to write the
entire packet is the data FIFO.
d) For writing zero length packet, application must not look for FIFO space.
2. Using one of the above mentioned methods, when the application determines that
there is enough space to write a transmit packet, the application must first write into
the endpoint control register, before writing the data into the data FIFO. The
application, typically must do a read modify write on the DIEPCTLx, to avoid
modifying the contents of the register, except for setting the Endpoint Enable bit.
The application can write multiple packets for the same endpoint, into the transmit FIFO,
if space is available. For periodic IN endpoints, application must write packets only for
one frame. It can write packets for the next periodic transaction, only after getting
transfer complete for the previous transaction.

XMC4500
XMC4000 Family
Setting IN Endpoint NAK
Internal Data Flow

1. When the application sets the IN NAK for a particular endpoint, the core stops
transmitting data on the endpoint, irrespective of data availability in the endpoint's
transmit FIFO.
2. Non-isochronous IN tokens receive a NAK handshake reply
a) Isochronous IN tokens receive a zero-data-length packet reply
3. The core asserts the DIEPINTx.IN NAK Effective interrupt in response to the
DIEPCTL.Set NAK bit.
4. Once this interrupt is seen by the application, the application can assume that the
endpoint is in IN NAK mode. This interrupt can be cleared by the application by
setting the DIEPCTLx. Clear NAK bit.

1. To stop transmitting any data on a particular IN endpoint, the application must set the
IN NAK bit. To set this bit, the following field must be programmed.
a) DIEPCTLx.SetNAK = 1B
2. Wait for assertion of the DIEPINTx.NAK Effective interrupt. This interrupt indicates
the core has stopped transmitting data on the endpoint.
3. The core can transmit valid IN data on the endpoint after the application has set the
NAK bit, but before the assertion of the NAK Effective interrupt.
4. The application can mask this interrupt temporarily by writing to the DIEPMSK.NAK
Effective bit.
a) DIEPMSK.NAK Effective = 0B
5. To exit Endpoint NAK mode, the application must clear the DIEPCTLx.NAK status.
This also clears the DIEPINTx.NAK Effective interrupt.
a) DIEPCTLx.ClearNAK = 1B
6. If the application masked this interrupt earlier, it must be unmasked as follows:
a) DIEPMSK.NAK Effective = 1B
IN Endpoint Disable
Use the following sequence to disable a specific IN endpoint (periodic/non-periodic) that
has been previously enabled in dedicated FIFO operation.
Application Programming Sequence:

1. In Slave mode, the application must stop writing data on the AHB, for the IN endpoint
to be disabled.
2. The application must set the endpoint in NAK mode. See Setting IN Endpoint
NAK on Page 16-103.

XMC4500
XMC4000 Family
a) DIEPCTLx.SetNAK = 1B
3. Wait for DIEPINTx.NAK Effective interrupt.
4. Set the following bits in the DIEPCTLx register for the endpoint that must be disabled.
a) DIEPCTLx.Endpoint Disable = 1
b) DIEPCTLx.SetNAK = 1
5. Assertion of DIEPINTx.Endpoint Disabled interrupt indicates that the core has
completely disabled the specified endpoint. Along with the assertion of the interrupt,
the core also clears the following bits.
a) DIEPCTLx.EPEnable = 0B
b) DIEPCTLx.EPDisable = 0B
6. The application must read the DIEPTSIZx register for the periodic IN EP, to calculate
how much data on the endpoint was transmitted on the USB.
7. The application must flush the data in the Endpoint transmit FIFO, by setting the
following fields in the GRSTCTL register.
a) GRSTCTL.TxFIFONum = Endpoint Transmit FIFO Number
b) GRSTCTL.TxFFlush = 1
The application must poll the GRSTCTL register, until the TxFFlush bit is cleared by the
core, which indicates the end of flush operation. To transmit new data on this endpoint,
the application can re-enable the endpoint at a later point.

XMC4500
XMC4000 Family
Bulk IN Stall
1. The application has scheduled an IN transfer on receiving the DIEPINTx.InTknRcvd
When TxFIFO Empty interrupt.
2. When the transfer is in progress, the application must force a STALL on the endpoint.
This could be because the application has received a SetFeature.Endpoint Halt
command. The application sets the Stall bit, disables the endpoint and waits for the
DIEPINTx.Endpoint Disabled interrupt. This generates STALL handshakes for the
endpoint on the USB.
3. On receiving the interrupt, the application flushes the Non-periodic Transmit FIFO
and clears the DCTL.GlobalINNPNAK bit.
4. On receiving the ClearFeature.Endpoint Halt command, the application clears the
Stall bit.
5. The endpoint behaves normally and the application can re-enable the endpoint for
new transfers

XMC4500
XMC4000 Family
Figure 16-26 Bulk IN Stall

XMC4500
XMC4000 Family
Incomplete Isochronous IN Data Transfers

This section describes what the application must do on an incomplete isochronous IN
data transfer.
Internal Data Flow

1. An isochronous IN transfer is treated as incomplete in one of the following conditions.
a) The core receives a corrupted isochronous IN token on at least one isochronous
IN endpoint. In this case, the application detects a GINTSTS.incomplete
Isochronous IN Transfer interrupt.
b) The application or DMA is slow to write the complete data payload to the transmit
FIFO and an IN token is received before the complete data payload is written to
the FIFO. In this case, the application detects a DIEPINTx.IN Tkn Rcvd When
TxFIFO Empty interrupt. The application can ignore this interrupt, as it eventually
results in a GINTSTS.incomplete Isochronous IN Transfer interrupt at the end of
periodic frame.
- The core transmits a zero-length data packet on the USB in response to the
received IN token.
2. In either of the aforementioned cases, in Slave mode, the application must stop
writing the data payload to the transmit FIFO as soon as possible.
3. The application must set the NAK bit and the disable bit for the endpoint. In DMA
mode, the core automatically stops fetching the data payload when the endpoint
disable bit is set.
4. The core disables the endpoint, clears the disable bit, and asserts the Endpoint
Disable interrupt for the endpoint.

1. The application can ignore the DIEPINTx.IN Tkn Rcvd When TxFIFO empty interrupt
on any isochronous IN endpoint, as it eventually results in a GINTSTS.incomplete
Isochronous IN Transfer interrupt.
2. Assertion of the GINTSTS.incomplete Isochronous IN Transfer interrupt indicates an
incomplete isochronous IN transfer on at least one of the isochronous IN endpoints.
3. The application must read the Endpoint Control register for all isochronous IN
endpoints to detect endpoints with incomplete IN data transfers.
4. In Slave mode, the application must stop writing data to the Periodic Transmit FIFOs
associated with these endpoints on the AHB.
5. In both modes of operation, program the following fields in the DIEPCTLx register to
disable the endpoint. See IN Endpoint Disable on Page 16-103 for more details.
a) DIEPCTLx.SetNAK = 1
b) DIEPCTLx.Endpoint Disable = 1
6. The DIEPINTx.Endpoint Disabled interrupt's assertion indicates that the core has
disabled the endpoint.

XMC4500
XMC4000 Family
a) At this point, the application must flush the data in the associated transmit FIFO or
overwrite the existing data in the FIFO by enabling the endpoint for a new transfer
in the next frame. To flush the data, the application must use the GRSTCTL
register.
Stalling Non-Isochronous IN Endpoints

This section describes how the application can stall a non-isochronous endpoint.

1. Disable the IN endpoint to be stalled. See IN Endpoint Disable on Page 16-103
for more details. Set the Stall bit as well.
2. DIEPCTLx.Endpoint Disable = 1, when the endpoint is already enabled
a) DIEPCTLx.STALL = 1
b) The Stall bit always takes precedence over the NAK bit
3. Assertion of the DIEPINTx.Endpoint Disabled interrupt indicates to the application
that the core has disabled the specified endpoint.
4. The application must flush the Non-periodic or Periodic Transmit FIFO, depending on
the endpoint type. In case of a non-periodic endpoint, the application must re-enable
the other non-periodic endpoints, which do not need to be stalled, to transmit data.
5. Whenever the application is ready to end the STALL handshake for the endpoint, the
DIEPCTLx.STALL bit must be cleared.
6. If the application sets or clears a STALL for an endpoint due to a
SetFeature.Endpoint Halt command or ClearFeature.Endpoint Halt command, the
Stall bit must be set or cleared before the application sets up the Status stage transfer
on the control endpoint.
Special Case: Stalling the Control IN/OUT Endpoint

The core must stall IN/OUT tokens if, during the Data stage of a control transfer, the host
sends more IN/OUT tokens than are specified in the SETUP packet. In this case, the
application must to enable DIEPINTx.INTknTXFEmp and DOEPINTx.OUTTknEPdis
interrupts during the Data stage of the control transfer, after the core has transferred the
amount of data specified in the SETUP packet. Then, when the application receives this
interrupt, it must set the STALL bit in the corresponding endpoint control register, and
clear this interrupt.
Non-Periodic IN Endpoint Sequencing

In DMA mode, the DIEPCTLx.NextEp value programmed controls the order in which the
core fetches non- periodic data for IN endpoints.
If application requires the core to fetch data for the non-periodic IN endpoints in a certain
endpoint order, it must program the DIEPCTLx.NextEP field accordingly before enabling
the endpoints. To enable a single endpoint enabled at a time the application must set the

XMC4500
XMC4000 Family
DIEPCTLx.NextEP field to the endpoint number itself. The core uses the NextEP field
irrespective of the DIEPCTLx.EPEna bit.
Worst-Case Response Time

When the USB core acts as a device, there is a worst case response time for any tokens
that follow an isochronous OUT. This worst case response time depends on the AHB
clock frequency.
The core registers are in the AHB domain, and the core does not accept another token
before updating these register values. The worst case is for any token following an
isochronous OUT, because for an isochronous transaction, there is no handshake and
the next token could come sooner. This worst case value is 7 PHY clocks when the AHB
clock is the same as the PHY clock. When AHB clock is faster, this value is smaller.
If this worst case condition occurs, the core responds to bulk/ interrupt tokens with a NAK
and drops isochronous and SETUP tokens. The host interprets this as a timeout
condition for SETUP and retries the SETUP packet. For isochronous transfers, the
incomplISOCIN and incomplISOCOUT interrupts inform the application that isochronous
IN/OUT packets were dropped.
Choosing the Value of GUSBCFG.USBTrdTim

The value in GUSBCFG.USBTrdTim is the time it takes for the MAC, in terms of PHY
clocks after it has received an IN token, to get the FIFO status, and thus the first data
from PFC (Packet FIFO Controller) block. This time involves the synchronization delay
between the PHY and AHB clocks. The worst case delay for this is when the AHB clock
is the same as the PHY clock. In this case, the delay is 5 clocks. If the PHY clock is
running at 60 MHz and the AHB is running at 30 MHz, this value is 9 clocks.
Once the MAC receives an IN token, this information (token received) is synchronized to
the AHB clock by the PFC (the PFC runs on the AHB clock). The PFC then reads the
data from the SPRAM and writes it into the dual clock source buffer. The MAC then reads
the data out of the source buffer (4 deep).
If the AHB is running at a higher frequency than the PHY, the application can use a
smaller value for GUSBCFG.USBTrdTim. Figure 16-27 explains the 5-clock delay. This
diagram has the following signals:
tkn_rcvd: Token received information from MAC to PFC
dynced_tkn_rcvd: Doubled sync tkn_rcvd, from pclk to hclk domain
spr_read: Read to SPRAM
spr_addr: Address to SPRAM
spr_rdata: Read data from SPRAM
srcbuf_push: Push to the source buffer
srcbuf_rdata: Read data from the source buffer. Data seen by MAC

XMC4500
XMC4000 Family
The application can use the following formula to calculate the value of
GUSBCFG.USBTrdTim:
4 * AHB Clock + 1 PHY Clock
= (2 clock sync + 1 clock memory address + 1 clock memory data from sync RAM) + (1
PHY Clock (next PHY clock MAC can sample the 2-clock FIFO output)
Figure 16-27 USBTrdTim Max Timing Case
Handling Babble Conditions

If USB core receives a packet that is larger than the maximum packet size for that
endpoint, the core stops writing data to the Rx buffer and waits for the end of packet
(EOP). When the core detects the EOP, it flushes the packet in the Rx buffer and does
not send any response to the host.
If the core continues to receive data at the EOF2 (the end of frame 2, which is very close
to SOF), the core generates an early_suspend interrupt (GINTSTS.ErlySusp). On
receiving this interrupt, the application must check the erratic_error status bit
(DSTS.ErrticErr). If this bit is set, the application must take it as a long babble and
perform a soft reset.

XMC4500
XMC4000 Family
Generic Non-Periodic (Bulk and Control) IN Data Transfers

This section describes a regular non-periodic IN data transfer.
1. Before setting up an IN transfer, the application must ensure that all data to be
transmitted as part of the IN transfer is part of a single buffer, and must program the
size of that buffer and its start address (in DMA mode) to the endpoint-specific
registers.
2. For IN transfers, the Transfer Size field in the Endpoint Transfer Size register denotes
a payload that constitutes multiple maximum-packet-size packets and a single short
packet. This short packet is transmitted at the end of the transfer.
a) To transmit a few maximum-packet-size packets and a short packet at the end of
the transfer:
b) Transfer size[epnum] = n * mps[epnum] + sp
(where n is an integer > 0, and 0 <sp < mps[epnum])
- If (sp > 0), then packet count[epnum] = n + 1.
Otherwise, packet count[epnum] = n
c) To transmit a single zero-length data packet:
- Transfer size[epnum] = 0
- Packet count[epnum] = 1
d) To transmit a few maximum-packet-size packets and a zero-length data packet at
the end of the transfer, the application must split the transfer in two parts. The first
sends maximum-packet- size data packets and the second sends the zero-length
data packet alone.
- First transfer: transfer size[epnum] = n * mps[epnum]; packet count = n;
- Second transfer: transfer size[epnum] = 0; packet count = 1;
3. In DMA mode, the core fetches an IN data packet from the memory, always starting
at a DWORD boundary. If the maximum packet size of the IN endpoint is not a
multiple of 4, the application must arrange the data in the memory with pads inserted
at the end of a maximum-packet-size packet so that a new packet always starts on a
DWORD boundary.
4. Once an endpoint is enabled for data transfers, the core updates the Transfer Size
register. At the end of IN transfer, which ended with an Endpoint Disabled interrupt,
the application must read the Transfer Size register to determine how much data
posted in the transmit FIFO was already sent on the USB.
5. Data fetched into transmit FIFO = Application-programmed initial transfer size - core-
a) Data transmitted on USB = (application-programmed initial packet count - Core
updated final packet count) * mps[epnum]
b) Data yet to be transmitted on USB = (Application-programmed initial transfer size
- data transmitted on USB)

XMC4500
XMC4000 Family
Internal Data Flow

specific registers and enable the endpoint to transmit the data.
2. In Slave mode, the application must also write the required data to the transmit FIFO
for the endpoint. In DMA mode, the core fetches the data from memory according to
the application setting for the endpoint.
3. Every time a packet is written into the transmit FIFO, either by the core's internal DMA
(in DMA mode) or the application (in Slave Mode), the transfer size for that endpoint
is decremented by the packet size. The data is fetched from the memory (DMA/
Application), until the transfer size for the endpoint becomes 0. After writing the data
into the FIFO, the "number of packets in FIFO" count is incremented (this is a 3-bit
count, internally maintained by the core for each IN endpoint transmit FIFO. The
maximum number of packets maintained by the core at any time in an IN endpoint
FIFO is eight). For zero-length packets, a separate flag is set for each FIFO, without
any data in the FIFO.
4. Once the data is written to the transmit FIFO, the core reads it out upon receiving an
IN token. For every non-isochronous IN data packet transmitted with an ACK
handshake, the packet count for the endpoint is decremented by one, until the packet
count is zero. The packet count is not decremented on a TIMEOUT.
5. For zero length packets (indicated by an internal zero length flag), the core sends out
a zero-length packet for the IN token and decrements the Packet Count field.
6. If there is no data in the FIFO for a received IN token and the packet count field for
that endpoint is zero, the core generates a IN Tkn Rcvd When FIFO Empty Interrupt
for the endpoint, provided the endpoint NAK bit is not set. The core responds with a
NAK handshake for non-isochronous endpoints on the USB.
7. In Dedicated FIFO operation, the core internally rewinds the FIFO pointers and no
timeout interrupt is generated except for Control IN endpoint.
8. When the transfer size is 0 and the packet count is 0, the transfer complete interrupt
for the endpoint is generated and the endpoint enable is cleared.

1. Program the DIEPTSIZx register with the transfer size and corresponding packet
count. In DMA mode, also program the DIEPDMAx register.
2. Program the DIEPCTLx register with the endpoint characteristics and set the CNAK
and Endpoint Enable bits.
In DMA mode, ensure that the NextEp field is programmed so that the core fetches
the data for IN endpoints in the correct order. See Non-Periodic IN Endpoint
Sequencing on Page 16-108 for details.
3. When using dedicated FIFO operation in slave mode, when transmitting non-zero
length data packet, the application must poll the DTXFSTSx register (where n is the
FIFO number associated with that endpoint) to determine whether there is enough

XMC4500
XMC4000 Family
space in the data FIFO. The application can optionally use DIEPINTx.TxFEmp before
writing the data.
Examples
Slave Mode Bulk IN Transaction

1. The host attempts to read data (IN token) from an endpoint.
2. On receiving the IN token on the USB, the core returns a NAK handshake, because
no data is available in the transmit FIFO.
3. To indicate to the application that there was no data to send, the core generates a
DIEPINTx.IN Token Rcvd When TxFIFO Empty interrupt.
4. When data is ready, the application sets up the DIEPTSIZx register with the Transfer
Size and Packet Count fields.
5. The application writes one maximum packet size or less of data to the Non-periodic
TxFIFO.
6. The host reattempts the IN token.
7. Because data is now ready in the FIFO, the core now responds with the data and the
host ACKs it.
8. Because the XferSize is now zero, the intended transfer is complete. The device core
generates a DIEPINTx.XferCompl interrupt.
DIEPINTx.XferCompl interrupt bit to determine that the intended transfer is complete.

XMC4500
XMC4000 Family
Figure 16-28 Slave Mode Bulk IN Transaction
Slave Mode Bulk IN Transfer (Pipelined Transaction)

1. The host attempts to read data (IN token) from an endpoint.
no data is available in the transmit FIFO.
3. To indicate that there was no data to send, the core generates an DIEPINTx.InTkn
Rcvd When TxFIFO Empty interrupt.
4. When data is ready, the application sets up the DIEPTSIZx register with the transfer
size and packet count.
5. The application writes one maximum packet size or less of data to the Non-periodic
TxFIFO.
6. The host reattempts the IN token.
7. Because data is now ready in the FIFO, the core responds with the data, and the host
ACKs it.

XMC4500
XMC4000 Family
8. When the TxFIFO level falls below the halfway mark, the core generates a
GINTSTS.NonPeriodic TxFIFO Empty interrupt. This triggers the application to start
writing additional data packets to the FIFO.
9. A data packet for the second transaction is ready in the TxFIFO.
10. A data packet for third transaction is ready in the TxFIFO while the data for the
second packet is being sent on the bus.
11. The second data packet is sent to the host.
12. The last short packet is sent to the host.
13. Because the last packet is sent and XferSize is now zero, the intended transfer is
complete. The core generates a DIEPINTx.XferCompl interrupt.
DIEPINTx.XferCompl interrupt bit to determine that the intended transfer is complete
Figure 16-29 Slave Mode Bulk IN Transfer (Pipelined Transaction

XMC4500
XMC4000 Family
Slave Mode Bulk IN Two-Endpoint Transfer

1. The host attempts to read data (IN token) from endpoint 1.
no data is available in the transmit FIFO for endpoint 1, and generates a
DIEPINTl.InTkn Rcvd When TxFIFO Empty interrupt.
3. The application processes the interrupt and initializes DIEPTSIZ1 register with the
Transfer Size and Packet Count fields. The application starts writing the transaction
data to the transmit FIFO.
4. The application writes one maximum packet size or less of data for endpoint 1 to the
Non-periodic TxFIFO.
5. Meanwhile, the host attempts to read data (IN token) from endpoint 2.
no data is available in the transmit FIFO for endpoint 2, and the core generates a
DIEPINT2.InTkn Rcvd When TxFIFO Empty interrupt.
7. Because the application has completed writing the packet for endpoint 1, it initializes
the DIEPTSIZ2 register with the Transfer Size and Packet Count fields. The
application starts writing the transaction data into the transmit FIFO for endpoint 2.
8. The host repeats its attempt to read data (IN token) from endpoint 1.
9. Because data is now ready in the TxFIFO, the core returns the data, which the host
ACKs.
10. Meanwhile, the application has initialized the data for the next two packets in the
TxFIFO (ep2.xact1 and ep1.xact2, in order).
12. Because endpoint 2's data is ready, the core responds with the data (ep2.xact_1),
which the host ACKs.
13. Meanwhile, the application has initialized the data for the next two packets in the
TxFIFO (ep2.xact2 and ep1.xact3, in order). The application has finished initializing
data for the two endpoints involved in this scenario.
15. Because data is now ready in the FIFO, the core responds with the data, which the
host ACKs.
17. With data now ready in the FIFO, the core responds with the data, which the host
ACKs.
18. With the last packet for endpoint 2 sent and its XferSize now zero, the intended
transfer is complete. The core generates a DIEPINT2.XferCompl interrupt for this
endpoint.
DIEPINT2.XferCompl interrupt bit to determine that the intended transfer on endpoint
2 is complete.
20. The host repeats its attempt to read data (IN token) from endpoint 1 (last transaction).

XMC4500
XMC4000 Family
21. With data now ready in the FIFO, the core responds with the data, which the host
ACKs.
22. Because the last endpoint one packet has been sent and XferSize is now zero, the
intended transfer is complete. The core generates a DIEPINT1.XferCompl interrupt
for this endpoint.
DIEPINT1.XferCompl interrupt bit to determine that the intended transfer on endpoint
1 is complete.
Figure 16-30 Slave Mode Bulk IN Two-Endpoint Transfer

XMC4500
XMC4000 Family
Generic Periodic IN (Interrupt and Isochronous) Data Transfers

This section describes a typical periodic IN data transfer.
1. Application requirements 1, 2, 3, and 4 of Generic Non-Periodic (Bulk and
Control) IN Data Transfers on Page 16-111 also apply to periodic IN data
transfers, except for a slight modification of Requirement 2.
a) The application can only transmit multiples of maximum-packet-size data packets
or multiples of maximum-packet-size packets, plus a short packet at the end. To
transmit a few maximum- packet-size packets and a short packet at the end of the
transfer, the following conditions must be met.
- transfer size[epnum] = n * mps[epnum] + sp
(where n is an integer > 0, and 0 <sp < mps[epnum])
- If (sp > 0), packet count[epnum] = n + 1
Otherwise, packet count[epnum] = n;
- mc[epnum] = packet count[epnum]
b) The application cannot transmit a zero-length data packet at the end of transfer. It
can transmit a single zero-length data packet by it self. To transmit a single zero-
length data packet,
c) transfer size[epnum] = 0
- packet count[epnum] = 1
2. The application can only schedule data transfers 1 frame at a time.
a) (DIEPTSIZx.MC - 1) * DIEPCTLx.MPS <DIEPTSIZx.XferSiz <DIEPTSIZx.MC *
DIEPCTLx.MPS
b) DIEPTSIZx. PktCnt = DIEPTSIZx.MC
c) If DIEPTSIZx.XferSiz < DIEPTSIZx.MC * DIEPCTLx.MPS, the last data packet of
the transfer is a short packet.
3. This step is not applicable for isochronous data transfers, only for interrupt transfers.
The application can schedule data transfers for multiple frames, only if multiples of
max packet sizes (up to 3 packets), must be transmitted every frame. This is can be
done, only when the core is operating in DMA mode. This is not a recommended
mode though.
a) ((n*DIEPTSIZx.MC) - 1)*DIEPCTLx.MPS <= DIEPTSIZx.Transfer Size <=
n*DIEPTSIZx.MC*DIEPCTLx.MPS
b) DIEPTSIZx.Packet Count = n*DIEPTSIZx.MC
c) n is the number of frames for which the data transfers are scheduled
Data Transmitted per frame in this case would be

DIEPTSIZx.MC*DIEPCTLx.MPS, in all the frames except the last one. In the frame
"n", the data transmitted would be (DIEPTSIZx.TransferSize -
(n-1)*DIEPTSIZx.MC*DIEPCTLx.MPS)

XMC4500
XMC4000 Family
4. For Periodic IN endpoints, the data must always be prefetched 1 frame ahead for
transmission in the next frame. This can be done, by enabling the Periodic IN
endpoint 1 frame ahead of the frame in which the data transfer is scheduled.
5. The complete data to be transmitted in the frame must be written into the transmit
FIFO (either by the application or the DMA), before the Periodic IN token is received.
Even when 1 DWORD of the data to be transmitted per frame is missing in the
transmit FIFO when the Periodic IN token is received, the core behaves as when the
FIFO was empty. When the transmit FIFO is empty,
6. A zero data length packet would be transmitted on the USB for ISO IN endpoints
a) A NAK handshake would be transmitted on the USB for INTR IN endpoints
7. For a High Bandwidth IN endpoint with three packets in a frame, the application can
program the endpoint FIFO size to be 2*max_pkt_size and have the third packet load
in after the first packet has been transmitted on the USB.
Internal Data Flow

2. In Slave mode, the application must also write the required data to the associated
transmit FIFO for the endpoint. In DMA mode, the core fetches the data for the
endpoint from memory, according to the application setting.
3. Every time either the core's internal DMA (in DMA mode) or the application (in Slave
mode) writes a packet to the transmit FIFO, the transfer size for that endpoint is
decremented by the packet size. The data is fetched from DMA or application
memory until the transfer size for the endpoint becomes 0.
4. When an IN token is received for an periodic endpoint, the core transmits the data in
the FIFO, if available. If the complete data payload (complete packet, in dedicated
FIFO mode) for the frame is not present in the FIFO, then the core generates an IN
Tkn Rcvd When TxF Empty Interrupt for the endpoint.
a) A zero-length data packet is transmitted on the USB for isochronous IN endpoints
b) A NAK handshake is transmitted on the USB for interrupt IN endpoints
5. The packet count for the endpoint is decremented by 1 under the following
conditions:
a) For isochronous endpoints, when a zero- or non-zero-length data packet is
transmitted
b) For interrupt endpoints, when an ACK handshake is transmitted
c) When the transfer size and packet count are both 0, the Transfer Completed
interrupt for the endpoint is generated and the endpoint enable is cleared.
6. At the "Periodic frame Interval" (controlled by DCFG.PerFrint), when the core finds
non-empty any of the isochronous IN endpoint FIFOs scheduled for the current frame
non-empty, the core generates a GINTSTS.incompISOIN interrupt.

XMC4500
XMC4000 Family
Application Programming Sequence (Transfer Per Frame)

1. Program the DIEPTSIZx register. In DMA mode, also program the DIEPDMAx
register.
2. Program the DIEPCTLx register with the endpoint characteristics and set the CNAK
and Endpoint Enable bits.
3. In Slave mode, write the data to be transmitted in the next frame to the transmit FIFO
as described in Packet Write in Slave Mode on Page 16-102.
4. Asserting the DIEPINTx.In Token Rcvd When TxF Empty interrupt indicates that
either the DMA or application has not yet written all data to be transmitted to the
transmit FIFO.
5. If the interrupt endpoint is already enabled when this interrupt is detected, ignore the
interrupt. If it is not enabled, enable the endpoint so that the data can be transmitted
on the next IN token attempt.
a) If the isochronous endpoint is already enabled when this interrupt is detected, see
Incomplete Isochronous IN Data Transfers on Page 16-107 for more details.
6. The core handles timeouts internally, without application intervention.
7. Asserting the DIEPINTx.XferCompl interrupt with no DIEPINTx.In Tkn Rcvd When
TxF Empty interrupt indicates the successful completion of an isochronous IN
transfer. A read to the DIEPTSIZx register must indicate transfer size = 0 and packet
count = 0, indicating all data is transmitted on the USB.
8. Asserting the DIEPINTx.XferCompl interrupt, with or without the DIEPINTx.In Tkn
Rcvd When TxF Empty interrupt, indicates the successful completion of an interrupt
IN transfer. A read to the DIEPTSIZx register must indicate transfer size = 0 and
packet count = 0, indicating all data is transmitted on the USB.
9. Asserting the GINTSTS.incomplete Isochronous IN Transfer interrupt with none of
the aforementioned interrupts indicates the core did not receive at least 1 periodic IN
token in the current frame.
10. For isochronous IN endpoints, see Incomplete Isochronous IN Data Transfers
on Page 16-107, for more details.
Generic Periodic IN Data Transfers Using the Periodic Transfer Interrupt Feature
This section describes a typical Periodic IN (ISOC / INTR) data transfer with the Periodic
Transfer Interrupt feature.
1. Before setting up an IN transfer, the application must ensure that all data to be
transmitted as part of the IN transfer is part of a single buffer, and must program the
size of that buffer and its start address (in DMA mode) to the endpoint-specific
registers.
a) The application must mask the GINTSTS.incompISOIN.
2. For IN transfers, the Transfer Size field in the Endpoint Transfer Size register denotes
a payload that constitutes multiple maximum-packet-size packets and a single short
packet. This short packet is transmitted at the end of the transfer.

XMC4500
XMC4000 Family
a) To transmit a few maximum-packet-size packets and a short packet at the end of

the transfer:
- Transfer size[epnum] = n * mps[epnum] + sp
(where n is an integer > 0, and 0 < sp < mps[epnum]. A higher value of n reduces
the periodicity of the DOEPINTx.XferCompl interrupt)
- If (sp > 0), then packet count[epnum] = n + 1. Otherwise, packet count[epnum] = n
b) To transmit a single zero-length data packet:
- Transfer size[epnum] = 0
- Packet count[epnum] = 1
c) To transmit a few maximum-packet-size packets and a zero-length data packet at
the end of the transfer, the application must split the transfer in two parts. The first
sends maximum-packet- size data packets and the second sends the zero-length
data packet alone.
- First transfer: transfer size[epnum] = n * mps[epnum]; packet count = n;
- Second transfer: transfer size[epnum] = 0; packet count = 1;
d) The application can only transmit multiples of maximum-packet-size data packets
or multiples of maximum-packet-size packets, plus a short packet at the end. To
transmit a few maximum- packet-size packets and a short packet at the end of the
transfer, the following conditions must be met.
- transfer size[epnum] = n * mps[epnum] + sp (where n is an integer > 0, and 0 <
sp < mps[epnum])
- If (sp > 0), packet count[epnum] = n + 1 Otherwise, packet count[epnum] = n;
- mc[epnum] = number of packets to be sent out in a frame.
e) The application cannot transmit a zero-length data packet at the end of transfer. It
can transmit a single zero-length data packet by itself. To transmit a single zero-
length data packet,
- transfer size[epnum] = 0
- packet count[epnum] = 1
3. In DMA mode, the core fetches an IN data packet from the memory, always starting
at a DWORD boundary. If the maximum packet size of the IN endpoint is not a
multiple of 4, the application must arrange the data in the memory with pads inserted
at the end of a maximum-packet-size packet so that a new packet always starts on a
DWORD boundary.
4. Once an endpoint is enabled for data transfers, the core updates the Transfer Size
register. At the end of IN transfer, which ended with an Endpoint Disabled interrupt,
the application must read the Transfer Size register to determine how much data
posted in the transmit FIFO was already sent on the USB.
a) Data fetched into transmit FIFO = Application-programmed initial transfer size -
core-updated final transfer size
b) Data transmitted on USB = (application-programmed initial packet count - Core
updated final packet count) * mps[epnum]

XMC4500
XMC4000 Family
c) Data yet to be transmitted on USB = (Application-programmed initial transfer size

- data transmitted on USB)
5. The application can schedule data transfers for multiple frames, only if multiples of
max packet sizes (up to 3 packets), must be transmitted every frame. This is can be
done, only when the core is operating in DMA mode.
a) ((n*DIEPTSIZx.MC) - 1)*DIEPCTLx.MPS <= DIEPTSIZx.Transfer Size <=
n*DIEPTSIZx.MC*DIEPCTLx.MPS
b) DIEPTSIZx.Packet Count = n*DIEPTSIZx.MC
c) n is the number of frames for which the data transfers are scheduled. Data
Transmitted per frame in this case is DIEPTSIZx.MC*DIEPCTLx.MPS in all frames
except the last one. In frame n, the data transmitted is (DIEPTSIZx.TransferSize -
(n - 1) * DIEPTSIZx.MC * DIEPCTLx.MPS)
6. For Periodic IN endpoints, the data must always be prefetched 1 frame ahead for
transmission in the next frame. This can be done, by enabling the Periodic IN
endpoint 1 frame ahead of the frame in which the data transfer is scheduled.
7. The complete data to be transmitted in the frame must be written into the transmit
FIFO, before the Periodic IN token is received. Even when 1 DWORD of the data to
be transmitted per frame is missing in the transmit FIFO when the Periodic IN token
is received, the core behaves as when the FIFO was empty. When the transmit FIFO
is empty,
a) A zero data length packet would be transmitted on the USB for ISOC IN endpoints
b) A NAK handshake would be transmitted on the USB for INTR IN endpoints
c) DIEPTSIZx.PktCnt is not decremented in this case.
8. For a High Bandwidth IN endpoint with three packets in a frame, the application can
program the endpoint FIFO size to be 2 * max_pkt_size and have the third packet
load in after the first packet has been transmitted on the USB.

XMC4500
XMC4000 Family
Figure 16-31 Periodic IN Application Flow for Periodic Transfer Interrupt Feature

XMC4500
XMC4000 Family
Internal Data Flow

a) The application must mask the GINTSTS.incompISOOUT.
b) The application must enable the DCTL.IgnrFrmNum
a) Subsequently the core updates the Even / Odd bit on its own
3. Every time either the core's internal DMA writes a packet to the transmit FIFO, the
transfer size for that endpoint is decremented by the packet size. The data is fetched
from DMA or application memory until the transfer size for the endpoint becomes 0.
4. When an IN token is received for a periodic endpoint, the core transmits the data in
the FIFO, if available. If the complete packet for the frame is not present in the FIFO,
then the core generates an IN Tkn Rcvd When TxFifo Empty Interrupt for the
endpoint.
a) A zero-length data packet is transmitted on the USB for isochronous IN endpoints
b) A NAK handshake is transmitted on the USB for interrupt IN endpoints
5. If an IN token comes for an endpoint on the bus, and if the corresponding TxFIFO for
that endpoint has at least 1 packet available, and if the DIEPCTLx.NAK bit is not set,
and if the internally maintained even/odd bit match with the bit 0 of the current frame
number, then the core will send this data out on the USB. The core will also
decrement the packet count. Core also toggles the MultCount in DIEPCTLx register
and based on the value of MultCount the next PID value is sent.
a) If the IN token results in a timeout (core did not receive the handshake or
handshake error), core rewind the FIFO pointers. Core does not decrement packet
count. It does not toggle PID. DIEPINTx.TimeOUt interrupt will be set which the
application could check.
b) At the end of periodic frame interval (Based on the value programmed in the
DCFG.PerFrint register, core will internally set the even/ odd internal bit to match
the next frame.
6. The packet count for the endpoint is decremented by 1 under the following
conditions:
a) For isochronous endpoints, when a zero- or non-zero-length data packet is
transmitted
b) For interrupt endpoints, when an ACK handshake is transmitted
7. The data PID of the transmitted data packet is based on the value of DIEPTSIZx.MC
programmed by the application. In case the DIEPTSIZx.MC value is set to 3 then, for
a particular frame the core expects to receive 3 Isochronous IN token for the
respective endpoint. The data PIDs transmitted will be D2 followed by D1 and D0
respectively for the tokens.
a) If any of the tokens responded with a zero-length packet due to non-availability of
data in the TxFIFO, the packet is sent in the next frame with the pending data PID.

XMC4500
XMC4000 Family
For example, in a frame, the first received token is responded to with data and data
PID value D2. If the second token is responded to with a zero-length packet, the
host is expected not to send any more tokens for the respective endpoint in the
current frame. When a token arrives in the next frame it will be responded to with
the pending data PID value of D1.
b) Similarly the second token of the current frame gets responded with D0 PID. The
host is expected to send only two tokens for this frame as the first token got
responded with D1 PID.
8. When the transfer size and packet count are both 0, the Transfer Completed interrupt
for the endpoint is generated and the endpoint enable is cleared.
9. The GINTSTS.incompISOIN will be masked by the application hence at the Periodic
Frame interval (controlled by DCFG.PerFrint), even though the core finds non-empty
any of the isochronous IN endpoint FIFOs, GINTSTS.incompISOIN interrupt will not
be generated.

XMC4500
XMC4000 Family
Figure 16-32 Periodic IN Core Internal Flow for Periodic Transfer Interrupt Feature
16.7 Device Scatter-Gather DMA Mode
16.7.1 Scatter/Gather DMA Mode

When the Scatter/Gather DMA mode is enabled data buffers are presented through
descriptor structures
1. The application prepares the descriptors, and sets the bit
DIEPCTLx/DOEPCTLx.EPEna.
2. DMA fetches the corresponding descriptor (initially determined by
DIEPDMAx/DOEPDMAx).

XMC4500
XMC4000 Family
3. DMA internally sets the transfer size from descriptor back to

DIEPTSIZx/DOEPTSIZx.
Note: The registers DIEPTSIZx/DOEPTSIZx must not be written by the application in
Scatter/Gather DMA mode.
From this point, the current OTG flow executes.
Once the transfer size data is moved by DMA, the DMA checks for further links in the
descriptor chain.
If this is the last descriptor, the DMA sets the DIOEPINTn.XferCompl interrupt. If there
are further active links, the DMA continues to process them.
In Scatter/Gather DMA mode, the core implements a true scatter-gather memory
distribution in which data buffers are scattered over the system memory. Each endpoint
memory structure is implemented as a contiguous list of descriptors, in which each
descriptor points to a data buffer of predefined size. In addition to the buffer pointer (1
DWORD), the descriptor also has a status quadlet (1 DWORD). When the list is
implemented as a ring buffer, the list processor switches to the first element of the list
when it encounters last bit. All endpoints (control, bulk, interrupt, and isochronous)
implement these structures in memory.
Note: The descriptors are stored in continuos locations. For example descriptor 1 is
stored in 0000_0000H, descriptor 2 is stored in 0000_0008H, descriptor 3 in
0000_0010H and so on. The descriptors are always DWORD aligned.
16.7.2 SPRAM Requirements

For each endpoint the current descriptor pointer and descriptor status are cached to
avoid additional requests to system memory. These are stored in SPRAM. In addition
DIEPDMAx/DOEPDMAx registers are also implemented in SPRAM.
16.7.3 Descriptor Memory Structures

The descriptor memory structures are displayed in Figure 16-33.

XMC4500
XMC4000 Family
Figure 16-33 Descriptor Memory Structures
16.7.3.1 OUT Data Memory Structure

All endpoints that support OUT direction transactions (endpoints that receive data from
the USB host), must implement a memory structure with the following characteristics:
Each buffer descriptor is two quadlets in length.
When the buffer status of the first descriptor is host Ready, the DMA fetches and
processes its data buffer; otherwise the DMA optionally skips to the next descriptor until
it reaches the end of the descriptor chain. The buffers to which the descriptor points hold
packet data for non-isochronous endpoints and frame (FS)/frame (FS) data for
isochronous endpoints.
Host Ready indicates that the descriptor is available for the DMA to process.
DMA Busy indicates that the DMA is still processing the descriptor.
DMA Doneindicates that the buffer data transfer is complete.
Host Busyindicates that the application is processing the descriptor.
The OUT data memory structure is shown in Figure 16-34, which shows the definition
of status quadlet bits for non-ISO and ISO end points

XMC4500
XMC4000 Family
Figure 16-34 Out Data Memory Structure

The status quadlet interpretation depends on the end point type field
(DOEPCTLx.EPType) for the corresponding end point. For example, if an end point is
OUT and periodic, then the status quadlet is interpreted as Status Quadlet for
Isochronous OUT.

XMC4500
XMC4000 Family
Table 16-8 displays the OUT Data Memory Structure fields.

Note: Note that some fields change depending on the mode.
Table 16-8 OUT Data Memory Structure Values

BS [31:30] Buffer This 2-bit value describes data buffer status. Possible options
Status are:
00B Host Ready
01B DMA Busy
10B DMA Done
11BHost Busy
Application sets to Host Ready if the descriptor is ready or to
Host Busy if the descriptor is not ready. Core sets to DMA
busy if the descriptor is being serviced or to DMA Done if the
transfer finished associated with the descriptor.
The application needs to make these bits as 00B (Host
Ready) as a last step after preparing the entire descriptor
ready.Once the software makes these bits as Host Ready
then it must not alter the descriptor until DMA completes
Rx Sts Receive This 2-bit value describes the status of the received data.
[29:28] Statu Core updates this when the descriptor is closed. This reflects
whether OUT data has been received correctly or with errors.
BUFERR is set by the core when AHB error is encountered
during buffer access. BUFERR is set by the core after
asserting AHBErr for the corresponding end point.The
possible combinations are:
01B Reserved
10B Reserved
11B BUFERR
L [27] Last Set by the application, this bit indicates that this descriptor is
the last one in the chain. Note - L Bit is interpreted by the core
even when BS value is other than Host ready. For example,
BNA is set, the core keeps traversing all the descriptors until
it encounters a descriptor whose L bit is set after which the
core disables the corresponding endpoint.
SP[26] Short Set by the Core, this bit indicates that this descriptor closed
Packet after short packet. When reset it indicates that the descriptor
is closed after requested amount of data is received.

XMC4500
XMC4000 Family

IOC[25] Interrupt On Set by the application, this bit indicates that the core must
complete generate a transfer complete interrupt(XferCompl) after this
descriptor is finished.
[24]1) Varies Non Isochronous Out Isochronous Out
Bit: SR[24] Bit: Reserved [24:23]
Bit ID: Setup Packet Received Bit ID: This field is
Set by the Core, this bit indicates reserved and the core
that this buffer holds 8 bytes of writes 00B.
setup data. There is only one
setup packet per descriptor. On
reception of a setup packet, the
descriptor is closed and the
corresponding endpoint is
disabled after
SETUP_COMPLETE status is
seen in the Rx fifo. The core puts
a SETUP_COMPLETE status
into the Rx FIFO when it sees
the first IN/OUT token after the
SETUP packet for that particular
endpoint.
However, if the L bit of the
descriptor is set, the endpoint is
disabled and the descriptor is
closed irrespective of the
SETUP_COMPLETE status.
The application has to re-enable
for receiving any OUT data for
the control transfer. (It also need
to reprogram the descriptor start
address)
Note - Because of the above
behavior, the core can receive
any number of back to back
setup packets and one
descriptor for every setup packet
is used.

XMC4500
XMC4000 Family

[23]1) Varies Non Isochronous Out See description for bit [24]
Bit: MTRF[23]
Bit ID: Multiple Transfer
Set by the application, this bit
indicates the Core can continue
processing the list after it
encountered last descriptor.This
is to support multiple transfers
without application intervention.
Reserved for ISO OUT and
Control OUT endpoints.
[22:16]1) Varies Non Isochronous Out Isochronous Out
Bit: [22:12] Bit: Frame Number
Bit ID: R [22:12]
Reserved Bit ID: Frame number
The 11-bit frame number
corresponds to full speed
frame number.

XMC4500
XMC4000 Family

[15:12]1) Varies Non Isochronous Out See description for bits
Bit: Rx Bytes [15:0] [22:16]
[11]1) Varies Bit ID: Received number of Isochronous Out
bytes remaining Bit: 11
This 16-bit value can take values Bit ID: Reserved
from 0 to (64K-1) bytes,
[10:0]1) Varies depending on the transfer size of Isochronous Out
data received from the USB Bit: Rx Bytes [10:0]
host. The application programs Bit ID: Received number
the expected transfer size. of bytes
When the descriptor is done this This 11 -bit value can take
indicates remainder of the values from 0 to
transfer size. Here, Rx Bytes (2K-1) bytes, depending
must be in terms of multiple of on the packet size
MPS for the corresponding end of data received from the
point. USB
The MPS for the various packet host.Application programs
types are as follows: the expected
Control transfer size. When the
LS - 8 bytes descriptor is done
FS - 8,16,32,64 bytes this indicates remainder of
Bulk the transfer size.
FS - 8,16,32,64 bytes The maximum payload
Interrupt size of each ISO
LS - up to 8 bytes packet as per USB
FS - up to 64 bytes specification 2.0 is as
Note: In case of Interrupt follows.
packets, the MPS may not be a FS - up to 1023 bytes
multiple of 4. If the MPS in an Note: A Value of 0
interrupt packet is not a multiple indicates zero bytes of
of 4, then a single interrupt data, 1 indicates 1 byte of
packet corresponds to a single data and so on.
descriptor. If MPS is a multiple of
4 for an interrupt packet, then a
single descriptor can have
multiple MPS packets.
Table 16-9 displays the matrix of L bit and MTRF bit options.

XMC4500
XMC4000 Family
Table 16-9 OUT - L Bit and MTRF Bit

L Bit MTRF Functionality
bit
1 1 Continue to process the list after the last descriptor encountered.
Use DOEPDMAx as next descriptor. The Endpoint is not disabled.
1 0 For non-Isochronous endpoints, Stop processing list after last
descriptor encountered. The application intervenes and programs
the list pointer into DOEPDMAx register when a list is created in a
new location otherwise enables the endpoint. Start processing when
the endpoint is enabled again with DOEPDMAx register pointing to
start of list.
For Isochronous endpoints, the DMA engine always goes back to
the base descriptor address after the last descriptor.
0 1 If a short packet is received or expected transfer is done, close the
current descriptor, continue with the next descriptor. If a short
packet or Zero length packet is received, the corresponding
endpoint is not disabled.
0 0 After processing the current descriptor go to next descriptor. If a
short packet OR zero length packet is received disable the endpoint
and a transfer complete interrupt is generated irrespective of IOC bit
setting for that descriptor.

Note: For Bulk and Interrupt End Points, if MTRF bit is set for the last descriptor in a list,
then all the descriptors in that list need to have their MTRF bit set.
Table 16-10 OUT Buffer Pointer

Buf Addr[31:0] Buffer The Buffer pointer field in the descriptor is 32 bits wide
Address and contains the address where the received data is to
be stored in the system memory. The starting buffer
address must be DWORD aligned. The buffer size
must be also DWORD aligned.

XMC4500
XMC4000 Family
16.7.3.2 Isochronous OUT
The application must create one descriptor per packet.

End point is not disabled by the core based on L bit. The DMA always goes back to
the base descriptor address after the last descriptor.
The bit MTRF is not applicable.
16.7.3.3 Non-Isochronous OUT
The core uses one descriptor per setup packet.

The core closes the descriptor after receiving a short packet.
Bit combinations for L and MTRF appear in Table 16-9.
Multiple Interrupt packets in the same buffer is allowed only if the MPS is multiple of 4.
16.7.3.4 IN Data Memory Structure

All endpoints that support IN direction transactions (transmitting data to the USB host)
must implement the following memory structure. Each buffer must have a descriptor
associated with it. The application fills the data buffer, updates its status in the descriptor,
and enables the endpoint. The DMA fetches this descriptor and processes it, moving on
in this fashion until it reaches the end of the descriptor chain. The buffer to which the
descriptor points to hold packet data for non-isochronous endpoints and frame data for
isochronous endpoints.
The definition of status quadlet bits for non-periodic and periodic end points are as
shown in the figure. The status quadlet interpretation depends on the end point type field
(DIEPCTLx.EPType) for the corresponding end point. For example, if an end point is IN
and periodic, then the status quadlet is interpreted as "Status Quadlet for Isochronous
IN".

XMC4500
XMC4000 Family
The IN data memory structure is shown in Figure 16-35.
Figure 16-35 IN Data Memory Structure

XMC4500
XMC4000 Family
Table 16-11 displays the IN Data Memory Structure fields.

Note: Some fields change depending on the mode
Table 16-11 IN Data Memory Structure Values

BS Buffer This 2-bit value describes the status of the data buffer. The
[31:30] Status possible options are:
00B Host ready
01B DMA busy
10B DMA done
11B Host busy
The application needs to make these bits as 00B (Host Ready)
as a last step after preparing the entire descriptor ready.Once
the software makes these bits as HostReady then it must not
alter the descriptor until DMA done
Tx Sts Transmit The status of the transmitted data. This reflects if the IN data
[29:28] Status has been transmitted correctly or with errors. BUFERR is set by
core when there is a AHB error during buffer access.
When iIgnrFrmNum is not set, BUFFLUSH is set by the core
when
the core is fetching data pertaining to the current frame (N)
and finds that the frame has incremented (N+1) during the
data fetch
or
when it fetches a descriptor for which the frame number has
already elapsed. The possible combinations are:
01B BUFFLUSH
10B Reserved
11B BUFERR
L [27] Last When set by the application, this bit indicates that this
descriptor is the last one in the chain.
SP[26] Short When set, this bit indicates that this descriptor points to a short
Packet packet or a zero length packet. If there is more than one packet
in the descriptor, it indicates that the last packet is a short
packet or a zero length packet.
IOC[25] Interrupt When set by the application, this bit indicates that the core must
On generate a transfer complete interrupt after this descriptor is
complete finished.

XMC4500
XMC4000 Family

[24:23]1) Varies Non Isochronous In Isochronous In
Bit: Reserved[24:16] Bit: Reserved[24:23]
Bit ID: Reserved Bit ID: Reserved
[22:12]1) Varies Isochronous In
[15:12] 1)
Varies Non Isochronous In Bit: Frame Number [22:12]
Bit: Tx bytes [15:0] Bit ID: This field must
Bit ID: Number of bytes to be correspond to the 11-bit full
transmitted This 16-bit value can speed frame number.
[11:0]1) Varies take values from 0 to (64K-1) Isochronous In
bytes, indicating the number of Bit: Tx bytes [11:0]
bytes of data to be transmitted to Bit ID: Number of bytes to
the USB host. transmit
Note: A Value of 0 indicates zero Tx bytes [11:0]
bytes of data, 1 indicates 1 byte Number of bytes to be
of data and so on. transmitted
This 12-bit value can take
values from 0 to (4K-1)
bytes, indicating the number
of bytes of data to be
transmitted to the USB host.
Note: A Value of 0 indicates
zero bytes of data, 1
indicates 1 byte of data and
so on.

XMC4500
XMC4000 Family
Table 16-12 displays the matrix of IN - L Bit, SP Bit and Tx bytes options.
Table 16-12 IN - L Bit, SP Bit and Tx bytes

L Bit SP Tx Bytes Functionality
bit
0 1 Multiple of endpoint Transmit a zero length packet after the last packet
maximum packet
size
0 1 Not multiple of Send short packet at the end after normal packets
maximum packet are sent out. Then move onto next descriptor
size
0 1 0 Transmit zero length packet. Then move on to next
descriptor.
0 0 Multiple of endpoint Send normal packets and then move to next
maximum packet descriptor.
size
0 0 Not a multiple of Transmit the normal packets and concatenate the
maximum packet remaining bytes with next buffer from the next
size descriptor. This combination is valid only for bulk
end points.
0 0 0 Invalid. The behavior of the core is undefined.
1 1 Multiple of endpoint Transmit a zero length packet after the last packet
maximum packet If this IN descriptor is for a ISO endpoint, then
size move onto the first descriptor in the list. If this IN
descriptor is for a non-ISO endpoint, then stop
processing this list and disable the corresponding
end point.
1 1 Not multiple of Send short packet after sending the normal
maximum packet packets
size If this IN descriptor is for a ISO endpoint, move
onto the first
descriptor in the list.
If this IN descriptor is for a non-ISO endpoint, then
stop processing this list and disable the
corresponding end point.

XMC4500
XMC4000 Family
Table 16-12 IN - L Bit, SP Bit and Tx bytes (contd)

L Bit SP Tx Bytes Functionality
bit
1 1 0 Transmit zero length packet
If this IN descriptor is for a ISO endpoint, move
onto the first descriptor in the list.
If this IN descriptor is for a non-ISO endpoint, then
stop processing this list and disable the
corresponding end point.
1 0 Multiple of endpoint Send normal packets
maximum packet If this IN descriptor is for a ISO endpoint, Move
size onto the first descriptor in the list after current
transfer done. If this IN descriptor is for a non-ISO
endpoint, then stop processing the list and disable
the corresponding end point.
1 0 Not multiple of Invalid. The behavior of the core is undefined for
maximum packet these values.
size.
1 0 0 invalid. The behavior of the core is undefined for
these values.
The descriptions provided for the different combinations in Table 16-12 depend on the
previous descriptor L, SP, and Tx Bytes values. Consider Table 16-13. The MPS for this
example is 512.
Table 16-13 IN - Buffer Pointer

DESC L SP Txbytes Description
NO bit bit
1 0 0 520 Send a normal packet of size 512, and concatenate the
remaining 8 bytes with the next descriptor's buffer data
2 0 1 512 For this combination of L,SP and TxBytes, as per the
above table, we need to send a zero length packet
instead of a short packet.
However, a normal packet followed by a short packet of
length 8-bytes is sent. This is to illustrate the context
dependency based on previous descriptor L,SP and
TxByte combinations.

XMC4500
XMC4000 Family
Table 16-14 displays the IN buffer pointer field description.

Buf Addr[31:0] Buffer The Buffer pointer field in the descriptor is 32 bits wide
Address and contains the address where the transmit data is
stored in the system memory. The address can be
non- DWORD aligned.
16.7.3.5 Descriptor Update Interrupt Enable Modes

If IOC bit is set for a descriptor and if the corresponding Transfer Completed Interrupt
Mask (XferComplMask) is unmasked, this interrupt (DIOEPINTn.XferCompl) is asserted
while closing that descriptor.
16.7.3.6 DMA Arbitration in Scatter/Gather DMA Mode

The arbiter grants receive higher priority than transmit. Within transmit, the priority is as
follows.
The highest priority is given to periodic endpoints. The periodic endpoints are
serviced in a round robin fashion.
The non periodic endpoints are serviced after the periodic scheduling interval has
elapsed. The duration of the periodic scheduling interval is programmable, as
specified by register bits DCFG[25:24]. When the periodic interval is active, the
periodic endpoints are given priority.
Amongst the periodic endpoints, the priority is round robin.
Amongst the non periodic endpoints, the Global Multi Count field in the Device
Control Register (DCTL) specifies the number of packets that need to be serviced for
that end point before moving to the next endpoint.
The arbiter disables an endpoint and moves on to the next endpoint in the following
scenarios as well, for all the endpoint types:
Descriptor Fetch and AHB Error occurs.
Buffer Not Available (BNA), such as when buffer status is Host busy.
AHB Error during Descriptor update stage and Data transfer stage.
16.7.3.7 Buffer Data Access on AHB in Scatter/Gather DMA Mode

The buffer address whose data needs to be accessed in the system memory can be non
DWORD aligned for transmit.
For buffer data read, the core arranges the buffer data to form a quadlet internally before
populating the TXFIFO within the core as per the following scenarios

XMC4500
XMC4000 Family
The packet starts in a non DWORD aligned address, the core does two reads on AHB
before appending the relevant bytes to form a quadlet internally. Hence the core
stores the bytes before pushing to the TXFIFO.
The packet ends in a non DWORD aligned address and it is not the end of the buffer
or expected transfer, the core may switch to service another end point and come
back to service the initial end point. In this case, the core reads the same DWORD
location again and then samples only the relevant bytes. This eliminates the storage
of the bytes for the initial end point.
For buffer data write, the core always performs DWORD accesses.
16.7.4 Control Transfer Handling

Control transfers (3-Stage Control R/WR or 2-Stage), can be handled effectively in the
Descriptor-Based Scatter/Gather DMA mode by following the procedure explained in
this section. By following this procedure the application is able to handle all normal
control transfer flow and any of the following abnormal cases.
More than one SETUP packet (back to back) Host could send any number of
SETUP packets back to back, before sending any IN/OUT token. In this case, the
application is suppose to take the last SETUP packet, and ignore the others.
More OUT/IN tokens during data phase than what is specified in the wlength field
If the host sends more OUT/IN data tokens than what is specified in the wlength field
of the SETUP data, then the device must STALL.
Premature SETUP packet during data/status phase Device application must be
able to handle this SETUP packet and ignore the previous control transfer.
Lost ACK for the last data packet of a Three-Stage Control Read Status Stage.
16.7.5 Interrupt Usage for Control Transfers

The application checks the following OUT interrupts status bits for the proper decoding
of control transfers.
DIEPINTx.XferCompl (Transfer complete, based on IOC bit in the descriptor)
DIEPINTx.InTknTxfEmp (In token received when Tx FIFO is empty)
DOEPINTx.XferCompl (Transfer complete, based on IOC bit in the descriptor)
DOEPINTx.SetUp (Setup Complete interrupt, generated when the core receives
IN/OUT token after a SETUP packet.
DOEPINTx.StsPhseRcvd (Status phase received interrupt (Also called SI),
generated when host has switched to status phase of a Control Write transfer).
The core performs some optimization of these interrupt settings, when it sees multiple
interrupt bits need to be set for OUT endpoints. This reduces the number of valid
combinations of interrupts and simplifies the application.

XMC4500
XMC4000 Family
The core gives priority for DOEPINTx.XferCompl over DOEPINTx.SetUp and

DOEPINTx.StsPhseRcvd (SI) interrupts. When setting the XferCompl interrupts, it clears
the SetUP and SI interrupt bits.
The core gives priority to DOEPINTx.SI interrupt over DOEPINTx.SetUp. When
setting DOEPINTx.StsPhseRcvd (SI), the core clears DOEPINTx.SetUp interrupt bit.
Based on this, the application needs only to decode the combinations of interrupts for
OUT endpoints shown in Table 16-15.
Table 16-15 Combinations of OUT Endpoint Interrupts for Control Transfer

StsPhse SetUp XferCo Description Template
Rcvd (SI) (SPD) mpl Used
(IOC)
0 0 1 Core has updated the OUT descriptor. Case A
Check the "SR" (Setup Received) bit in the
descriptor to see if the data is for a SETUP
or OUT transaction.
0 1 0 Setup Phase Done Interrupt for the Case B
previously decoded SETUP packet.
0 1 1 The core has updated the OUT descriptor Case C
for a SETUP packet, and the core is
indicating a SETUP complete status also.
1 0 0 Host has switched to Status phase of a Case D
Control OUT transfer
1 0 1 Core has updated the OUT descriptor. Case E
Check the SR" (Setup Received) bit in the
descriptor to see if the data is for a SETUP
or OUT transaction. Also, the host has
already switched to Control Write Status
phase.
16.7.6 Application Programming Sequence

This section describes the application programming sequence to take care of normal and
abnormal Control transfer scenarios.
All the control transfer cases can be handled by five separate descriptor lists. The
descriptor lists are shown in Figure 16-36.
Three lists are for SETUP. The SETUP descriptors also take data for the Status stage
of Control Read.
The first two (index 0 and 1) act in a ping-pong fashion.

XMC4500
XMC4000 Family
The third list is an empty list, linked to one of the OUT descriptors when premature
SETUP comes during the data/ status phase.
Two lists are for IN and OUT data respectively.
Figure 16-36 displays setup_index 0, 1, and 2 as elements of array of pointers called
setup_index. The first two elements of this array point to SETUP descriptors. The
third element of this array is initially a NULL pointer, but is eventually linked to a
SETUP descriptor. These array elements could also point to a descriptor for Control
Read Status phase.

XMC4500
XMC4000 Family
Figure 16-36 Descriptor Lists for Handling Control Transfers

The following are the steps that need to be followed by the application driver.
1. Set up Desc for SETUP/Ctrl-Rd-Sts Setup 2 descriptor lists in memory for taking
in SETUP packets. Each of this list must have only one descriptor, with the descriptor
fields set to the following
a) Rx_bytes Set it to Max packet size of the control endpoint.
b) IOC =1.
c) MTRF=0.

XMC4500
XMC4000 Family
d) L=1.
2. Enable DMAIf current setup_index =0, then setup_index=1. The application ping-
pongs between these two descriptors. Program the address of the current setup
descriptor (specified by setup_index) to DOEPDMAx. Write to DOEPCTLx with the
following fields.
a) DOEPCTL.MPS Max Packet size of the endpoint
b) DOEPCTL.EPEna Set to 1 to enable the DMA for the endpoint.
3. Wait for InterruptWait for OUT endpoint interrupt (GINTSTS.OEPInt). Then read
the corresponding DOEPINT.
4. If Control Read Data Stage in progress
a) Case ACheck SR bit (In this case SR bit is set, because the host cannot send
OUT at this point. If it sends OUT it is NAKed. GOTO Step 24.
b) Case B GOTO Step 26.
c) Case C:-Check SR bit (In this case SR bit is set because host cannot send OUT
packets without SETUP at this stage). GOTO Step 24.
d) Case D Cannot happen at this stage because SI cannot come alone without a
SETUP, at this stage.
e) Case E Indicates that host has switched to another SETUP (Three-Stage
control write) and then has switched to status phase without and data phase (core
clears SUP with SI in this case). Decode SETUP packet and if ok, GOTO Step 11.
else If Ctrl Write Status Stage in progress OR Two-Stage Status Stage in progress
f) Case ACheck SR bit (In this case SR bit is set, because the host cannot send
OUT at this point. If it sends OUT it is NAKed.) GOTO Step 24.
g) Case B (Could happen for Two-Stage Ctrl Transfer.) GOTO Step 26.
h) Case CGOTO Step 24.
i) Case D Clear SI interrupt and wait Step 3.
j) Case E Cannot happen at this stage.
else
k) Case AGOTO Check Desc.

l) Case B Normally, this does not occur at this stage. Either IOC comes first or
IOC comes with SUP (Case C).
m)Case C GOTO Check Desc.
n) Case D Cannot happen at this point.
o) Case E If SR==1, Indicates Three stage control Transfer SETUP and that the
host has switched to status phase. Decode the SETUP packet and Goto Step 11.
p) Check Desc
Read the Descriptor status quadlet corresponding to the setup_index and check
the SR field. (Application might also want to check the BS and RxSts fields and

XMC4500
XMC4000 Family
take necessary actions if there is any abnormalities). If SR field is 1 GOTO Step 5

(If Step Step 20 is active, terminate it). If SR field is 0 GOTO Step 22 (Control Rd
Status phase) (This must also terminate Step 20).
5. Decode SETUPDecode the SETUP packet. If it is a Three-Stage Control Write,
GOTO Step 20. If it is a Three-Stage Control Read, GOTO Step 15. If it is a Two-
Stage Control transfer, GOTO Step 11 (Same as Status stage for 3-Stage Control
Write).
6. Desc list for Ctrl Wr data Setup descriptor list for Control write data phase. This
must be based on the Wlength field in the SETUP data. The descriptors in the list
must be setup such that there must be one descriptor per packet. Each of these
descriptors must have the control fields set as follows.
a) Rx_Bytes Set to the Max Packet Size of the control Endpoint.
b) IOC = 1
c) MTRF = 0.
d) L=1.
e) At this point we are not enabling and clearing the NAK for the IN endpoint for status
phase.This is because, the status phase for Control Write can be ACKed only after
decoding the complete data for the data phase.
GOTO Step 7.
7. Enable DMA for Ctrl Wr DataWrite the start address of this list to DOEPDMAx.
Program the DOEPCTLx with the following bits set
a) DOEPCTL.MPS Max Packet size of the endpoint
b) DOEPCTL.EPEna Set to 1 to enable the DMA for the endpoint. GOTO Step 8.
8. Wait for Ctrl Wr Data InterruptWait for OUT endpoint interrupt (GINTSTS.OEPInt).
Then read the corresponding DOEPINTx.
a) Case Acheck the SR field. Also clear DOEPINTx.XferCompl by writing to
DOEPINTx.(Application might also want to check the BS and RxSts fields and take
necessary actions if there is any abnormalities). If SR field is 0 GOTO Step 9.If SR
field is 1, GOTO Step 23. (This indicates that the host has switched to a new
control transfer).
b) Case B GOTO Step 25.
c) Case CGOTO Step 23. (This indicates that the host has switched to a new
control transfer).
d) Case D Host has switched to status phase. Decode the data received so far.
GOTO Step 10.
e) Case E Check SR bit. If SR==0, decode the data received so far. GOTO Step
10. If SR==1, decode the SETUP packet and Goto Step10.
9. Check Desc If it's not the last packet of data phase, Re-enable the endpoint and
clear the Nak. This is because the core sets NAK after receiving each OUT packet
for control write data phase. This is to allow application to STALL in case the host
sends more data than what is specified in the Wlength field. GOTO Step 8. Re-
enabling and clearing the NK involves the following steps.
a) Write to DOEPDMA with the new descriptor address.

XMC4500
XMC4000 Family
b) Write to DOEPCTLx with the following fields.

- DOEPCTL.MPS Max Packet size of the endpoint
- DOEPCTL.CNAKSet to 1 to clear the NAK.
- DOEPCTL.EPEna Set to 1 to enable the DMA for the endpoint.
If it is the last packet of the data phase, GOTO Step 10.
10. STALL Extra Bytes Write to DOEPCTLx with Stall set so that the core could
STALL any further OUT tokens from host.If the received Bytes so far is greater than
what is specified in Wlength field OR is there were any unsupported commands in
the data phase, then write to DIEPCTLx with the Stall bit set so that the Status phase
could be Stalled.(The STALL bit is automatically cleared by the core with the next
SETUP). GOTO Step 11.
11. Disc list for Ctrl Wr Sts The following two process must run in parallel. This is
because, we are preparing for the status phase (IN) of Control write but at the same
time the host could send another SETUP. So IN and OUT descriptor list must be
ready.
a) Do Step 2 Step 5 (This is for handling SETUP or Ctrl Wr Status). If the OUT DMA
is already enabled (OUT DMA was enabled for data phase of Three-Stage Control
Write, but there was a premature status phase), GOTO Step 3.
b) Setup descriptor list for Status phase IN, depending on the data in the status
phase. Normally it is always a zero length packet.
c) Tx_Bytes Size of status phase,
d) BS Host Ready,
e) L=1.
f) IOC=1.
g) SP=1 (Depending on the Tx_Bytes).
h) Write to DIEPDMAx with the start address of the descriptor.Write to DIEPCTLx
clear the NAK and enable the endpoint. Flush the corresponding TX FIFO.
i) If SI has not been received in the data stage prior to the status stage, then wait for
SI before clearing the NAK(DIEPCTLx.CNAK=1)
j) DIEPCTLx.EpEna=1.
k) GOTO Step 12.
12. Wait for InterruptWait for IN endpoint interrupt (GINTSTS.IEPInt).
13. If IN endpoint INterrupt, and DIEPINTx.XferCompl, then GOTO Step 14.
14. Check Desc Read the Status field of the descriptor. Check Tx_bytes in the
descriptor.(Application might also want to check the BS and RxSts fields and take
necessary actions if there is any abnormalities). This is end of Three-Stage Control
Write OR Two-Stage Control transfer. We are now ready for the next control transfer
(Already taken care by process "a" is Step 11.
15. Desc for Ctrl Rd DataThe following two steps must be run in parallel. This is
because, we are preparing for Data phase of Control read, but at the same time, the
host could abnormally abort this control transfer and send a SETUP, or switch to
status phase.

XMC4500
XMC4000 Family
16. Do Step 2 Step 5 (This is for handling SETUP and also Control Read Status
phase.).
17. Setup descriptor list for Data phase IN, depending on the WLength field in the SETUP
data. The setup can be for a single descriptor OR multiple descriptors. If it is multiple
descriptors, ensure that IOC for the last descriptor is set.
a) Tx_Bytes Size of data phase (Wlength field).
b) BS Host Ready
c) L=1.
d) IOC=1. It is mandatory to set the IOC when it is the last descriptor.
e) SP=1 (Depending on the Tx_Bytes).
f) Write to DIEPDMAx with the start address of the descriptor list.
g) Write to DIEPCTLx clear the NAK and enable the endpoint.
h) Flush the corresponding TX FIFO.
i) DIEPCTLx.MPS = Max_packet size of the endpoint,
j) DIEPCTLx.CNAK=1 only if SPD already set (Case C in Step 3).
k) Also set the DOEPCTLx.CNAK for the corresponding OUT endpoint after SPD
because a premature status stage (OUT) can come which must be acked.
l) DIEPCTLx.EpEna=1.
m)GOTO Step 18.
18. Wait for InterruptWait for IN endpoint interrupt (GINTSTS.IEPInt)
19. If IN endpoint interrupt, read the corresponding DIEPINTx and if XferCompl is set
GOTO Step 20.
20. Check_DescWait for the DIEPINTx.IOC interrupt. Go to Step 21.
21. Set_StallWrite to DIEPCTLx with STALL bit set. (The STALL bit is automatically
cleared by the core with the next SETUP). The function of this process initiated in
step Step 15 is over, and must be terminated. The next control transfer is already
taken care by the process that is running from Step 2.
22. Ctrl Rd Sts Desc Check Read the descriptor to check the Rxbytes and also check
the SP field. The Three-Stage control Read is complete here. GOTO Step 2, in
preparation for the next SETUP.
23. The unexpected SETUP packet now received during the control write data phase, is
sitting in the descriptor allocated for Data. Link this to the setup descriptor pointer.
setup_desc_index = 2. Point setup_desc_index to the current OUT descriptor (which
has the SETUP). GOTO Step 5.
24. Disable IN Endpoint DMA. Core flushes the corresponding Tx FIFO in order to flush
the data that was meant for Control Write Status phase OR Control Read data phase.
If Step 12 or Step 18 is active, terminate it. GOTO Step .
25. Read Modify write DOEPCTLx to clear the NAK. Then GOTO Step 8 again.
a) DOEPCTLx.CNAKSet to 1 to clear the NAK.
26. Read Modify write DIEPCTLx to clear the NAK. Then GOTO Step 3 again.
a) DIEPCTLx.CNAKSet to 1 to clear the NAK.
27. Read Modify write DIEPCTLx to clear the NAK. Then Step 12 again
a) DIEPCTLx.CNAKSet to 1 to clear the NAK.

XMC4500
XMC4000 Family
b) DOEPCTLx.CNAK:Set to 1 to clear the NAK for the out endpoint. This clears the
NAK to accept status stage data in case of control read.
16.7.7 Internal Data Flow

This section explains the cores internal data flow for control transfers.
16.7.7.1 Three-Stage Control Write

Figure 16-37 displays the core behavior for Three-Stage control write transfers.
1. On receiving SETUP, the data is pushed into the Rx FIFO and the core sets NAK on
both IN and OUT endpoint of that control endpoint. Additionally, the clearing of the
NAK bit is blocked by the core until the following SPD or SI is read by the application
and cleared.
2. The DMA detects the RxFIFO as non-empty and does the following:
a) Fetch the descriptor pointed by DOEPMA.
b) Transfer the SETUP packet from the RxFIFO to the buffer pointed by the
descriptor.
c) Close the descriptor with DMA_DONE status.
3. On receiving the first data phase OUT token after the SETUP, the core push a
SETUP_COMPLETE status into the RxFIFO.Core NAKs the data phase OUT tokens
because of the NAK set on receiving the SETUP packet.
4. The core generates DOEPINT.XferCompl interrupt after having transferred the
SETUP packet into memory (Step 2).
5. The core generates DOEPINT.SetUp interrupt after the DMA has popped the
SETUP_COMPLETE status out of the RxFIFO.
6. Application clears NAK for the data phase, after receiving DOEPINTx.SetUp
interrupt.
7. The core ACKs and the next OUT token because the NAK has been cleared
(provided there is enough space in the RxFIFO.
8. DMA detects the OUT packet in RxFIFO and starts transferring the OUT packet to
the system memory.
b) Transfer the OUT packet from the RxFIFO to the buffer pointed by the descriptor.
c) Close descriptor with DMA_DONE status.
9. The core NAKs the next OUT token because the core internally sets the NAK after
every control write data phase packets. This is to allow application to Stall any extra
tokens.
10. The core generates DOEPINT.XferCompl after closing the OUT descriptor (Step 8).
11. Application clear NAK on receiving DOEPINTx.XferCompl interrupt.
12. Host starts the Status phase by sending the IN token which is NAKed by the core.
The core push DATA_PHASE_DONE status into the RxFIFO.

XMC4500
XMC4000 Family
13. The core generates DOEPINTx.XferCompl for the last OUT packet transfer to system
memory.
14. The core generates DOEPINT.StsPhsRcvd interrupt after the DMA has popped the
DATA_PHASE_DONE status from the RxFIFO.
15. Application clears the NAK and enables the IN endpoint for status phase.
16. The core starts fetching the data for the Status phase
a) Fetch the descriptor pointed by DIEPDMA.
b) Fetch the packet (if size >0) to Tx fifo.
c) Close the descriptor with DMA_DONE status
d) The core generates DIEPINTx.XferCompl interrupt after closing the descriptor.
17. The core sends out data in response to the Status Phase IN token.

XMC4500
XMC4000 Family
Figure 16-37 Three-Stage Control Write

XMC4500
XMC4000 Family
16.7.7.2 Three-Stage Control Read

Figure 16-38 displays the core flow for three-stage control read transfers
Figure 16-38 Three-Stage Control Read

In this example, it is assumed that the data phase consists of 2 packets, and the
application allocates these two packets in a single buffer.
both IN and OUT endpoint of that control endpoint.

XMC4500
XMC4000 Family
2. The DMA detects the RxFIFO as non-empty and does the following.
descriptor.
6. Data phase IN tokens are NAKed until this point because the NAK has not yet been
cleared by the application.
7. The core starts fetching the IN data after the application enables IN DMA (In this
example it is assumed that multiple packets are in the same buffer. But it could also
be in different buffers). This involves the following steps
b) Fetch the data into the corresponding Tx FIFO.
c) Close the descriptor with DMA_DONE status...
8. The application clears the NAK after receiving the setup complete (DOEPINT.SetUp)
interrupt. The application also clears NAK of the OUT End point to accept the status
phase.
9. After all the data has been fetched for the descriptor (Step 7), core generates
DIEPINT.XferCompl interrupt.
10. The core sends data in response to the IN token for the data phase.
11. The core sends out the last packet of the IN data phase.
12. The core ACKs the status phase.
13. The core generates DOEPINTx.XferCompl interrupt after transferring the data
received for the status phase to system memory.

XMC4500
XMC4000 Family
16.7.7.3 Two-Stage Control Transfer

Figure 16-39 displays the core behavior for Two Stage control read transfers.
Figure 16-39 Two-Stage Control Transfer

This example shows the core behavior for a Two-Stage Control transfer.
descriptor.
d) The core receives the status phase IN token, which it NAKs. Core also pushes
SETUP_COMPLETE status into the Rx FIFO.

XMC4500
XMC4000 Family
e) The core generates DOEPINT.XferCompl interrupt after having transferred the

SETUP packet into memory (Step 2)
f) The core generates DOEPINT.SetUp interrupt after the DMA has popped the
3. Application enables the IN endpoint for status phase.
4. The core starts fetching the descriptor for IN endpoint.
5. Application clears the NAK for IN endpoint after getting the DOEPINTx.SetUP
interrupt (Step 4).
6. The core generates DIEPINTx.XferCompl after updating the descriptor after IN data
fetch.
7. The core sends out data for the status phase IN token from host.
16.7.7.4 Back to Back SETUP During Control Write

This example shows the core receiving 2 Back to Back SETUP tokens fo3 Three-Stage
Control write.
descriptor.
d) The core receives another SETUP, and pushes the data into the Rx FIFO, also
sets the NAK.
4. The DMA detects the RxFIFO as non-empty (because of the 2nd SETUP packet) and
does the following.
descriptor.
d) The core generates DOEPINT.XferCompl interrupt after having transferred the
second SETUP packet into memory (Step 6)
e) The core generates DOEPINT.SetUp interrupt after the DMA has popped the
interrupt.

XMC4500
XMC4000 Family
6. The core ACKs the next OUT/Ping token after the NAK has been cleared by the
application.
7. The DMA detects the RxFIFO as non-empty (because of the OUT packet) and does
the following.
descriptor.
d) The core generates DOEPINT.XferCompl interrupt after having transferred the
OUT packet into memory (Step 11) and closing the descriptor.
The remaining steps are similar to Steps 11-18 of Application Programming
Sequence on Page 16-143.
This example shows the core behavior for a Two-Stage Control transfer.

XMC4500
XMC4000 Family
Figure 16-40 Back-to-Back SETUP Packet Handling During Control Write

XMC4500
XMC4000 Family
16.7.7.5 Back-to-Back SETUPs During Control Read
descriptor.
d) The core receives another SETUP, and pushes the data into the Rx FIFO, also
sets the NAK.
4. Host sends IN token for the data phase which is NAKed by the core, because NAK
is set in Setp3. The core pushes SETUP_COMPLETE status into RxFIFO.
5. After the application has re-enabled the OUT DMA (Application flow Step 2) core
detects RxFIFO as non-empty because of the second SETUP packet and does the
following.
descriptor.
d) The core generates DOEPINTx.XferCompl interrupt after having transferred the
SETUP packet into memory (Step6).
e) The core starts fetching data for IN endpoint because the IN endpoint was enabled
by application in Step-14.
6. On seeing DOEPINTx.XferCompl (Step 7) and finding that it is a SETUP packet,
application disables the endpoint in Step 20.
7. The core generates DOEPINTx.SetUP (Setup complete) interrupt after popping the
SETUP_COMPLETE status from the RxFIFO.
8. The core generates endpoint disabled interrupt (as a result of application setting
disable bit in step 9)
9. The core generates DIEPINTx.XferCompl after completing the IN data fetch and
updating the descriptor.
10. application clears NAK after seeing setup_complete interrupt (generated in Step 10.
The flow after this is same as steps 9 - 13 of Internal Data Flow on Page 16-150

XMC4500
XMC4000 Family
Figure 16-41 Back-to-Back SETUP During Control Read

XMC4500
XMC4000 Family
16.7.7.6 Extra Tokens During Control Write Data Phase

This example assumes a three-stage control write transfer with only Wlength field in the
SETUP indicating only 1 packet in the data phase. But the host sends an additional OUT
packets which the core STALLs.
descriptor.
interrupt.
8. DMA starts transferring the OUT packet to the system memory.
OUT packet to the system memory. Since there were only one packet in the data
phase, the data phase is complete here.
e) The core initially NAK's the extra tokens send by the host, because the core
internally sets NAK after each OUT packet for the data phase of control write.
9. Application sets STALL to stall any extra tokens.
10. The core stalls the next OUT/PING token.
11. Host switches to next control transfer, core ACKs the SETUP. This SETUP packet is
transferred to the system memory buffer originally allocated for Status phase.
12. The core generates DOEPINTx.XferCompl interrupt after transferring the SETUP
packet to the system memory.

XMC4500
XMC4000 Family
Figure 16-42 Extra Tokens During Control Write Data Phase

XMC4500
XMC4000 Family
16.7.7.7 Extra Tokens During Control Read Data Phase

application allocates these two packets in a single buffer. After the data phase is
complete and the two packets have been transferred, the core sends an extra IN token
and then the application sets Stall.
descriptor.
8. The application clear the NAK after receiving the setup complete (DOEPINT.SetUp)
interrupt. Set the Stall bit after all the Data has been pushed in the FIFO
11. The core sends out the last packet of the IN data phase.
12. Host sends an extra token.
13. The core Stalls the IN token and also automatically Stalls the Status phase if the Host
switches to the Status phase.

XMC4500
XMC4000 Family
Figure 16-43 Extra IN Tokens During Control Read Data Phase

XMC4500
XMC4000 Family
16.7.7.8 Premature SETUP During Control Write Data Phase

This example shows a Three-Stage Control Write transfer with host sending a premature
Control Write SETUP packet during the data phase.
descriptor.
6. The core receives a SETUP packet during the data phase. This is an unexpected
SETUP packet.On receiving this SETUP, the SETUP data is pushed into the RxFIFO
and the core again sets NAK on both IN and OUT endpoints of the control endpoint
(NAK was already set because of the first SETUP packet received).
7. Application decodes the previous DOEPINT.SetUp interrupt and clears the NAK,
unaware of the fact that there is another SETUP packet sitting in the RxFIFO for the
same control endpoint. On seeing this condition, core does not allow clearing of the
NAK bit, and masks the clearing of NAK. The core takes this decision based on the
fact that a SETUP_COMPLETE status is pending in the RXFIFO.
8. The DMA detects the RxFIFO as non-empty (because of the unexpected SETUP)
and does following
descriptor.
d) The core NAKs the data phase OUT token because NAK bit clearing by the
application did not take effect (as explained in Step 7).
f) The core generates DOEPINT.SetUp interrupt after the DMA has popped the
SETUP_COMPLETE status (for the unexpected SETUP packet received) out of
the RxFIFO.
9. Application clears the NAK after decoding the latest SETUP packet. This time, the
core does not mask the clearing of the NAK because there are no more
SETUP_COMPLETE status sitting in the RxFIFO.

XMC4500
XMC4000 Family
10. The core ACKs the next OUT/PING token of the data phase.
11. DMA starts transferring the OUT packet to the system memory.
OUT packet to the system memory.
e) The remaining steps are similar to Steps 11-18 of Application Programming
Sequence on Page 16-143

XMC4500
XMC4000 Family
Figure 16-44 Premature SETUP During Control Write Data Phase

XMC4500
XMC4000 Family
16.7.7.9 Premature SETUP During Control Read Data Phase

application allocates these two packets in a single buffer. The host switches to a new
control read command after having send two IN tokens during the data phase.
descriptor.
3. On receiving the first data phase IN token after the SETUP, the core push a
SETUP_COMPLETE status into the RxFIFO.Core NAKs the data phase IN tokens
6. Host switches to a new Control transfer by sending a SETUP token. This is the
premature SETUP packet. Core sets NAK on both IN and OUT control endpoints.
7. The core fetch the data for IN control endpoint after application enables the IN
endpoint.
8. The core push SETUP_COMPLETE status into Rx FIFO on seeing the IN token for
data phase.
9. Application clears NAK as a result of DOEPINT.SetUP (Setup complete) interrupt
generated in Step 5. But core masks this clearing of setup_complete interrupt,
because there is already one SETUP packet sitting in the Rx FIFO.
10. The core generates DIEPINTx.XFERCompl after closing the IN endpoint descriptor
(for Step 7)
11. The core generates DOEPINTx.XferCompl after transferring the premature SETUP
packet to system memory and closing the descriptor.
12. The core generates SETUP complete interrupt.
13. Application enables IN endpoint DMA for data phase.
14. The core fetches descriptor and data for IN endpoint.
15. Application clears IN endpoint NAK after receiving DOEPINTx.SetUP (Setup
complete) interrupt. This time, the core does not mask the clearing of the Nak
because NO SETUP packet is remaining in the Rx FIFO.
16. The core generates DIEPINTx.XferCompl interrupt after fetching the data and closing
the descriptor. The remaining steps are same as steps 11 to 13 of Internal Data
Flow on Page 16-150.

XMC4500
XMC4000 Family
Figure 16-45 Premature SETUP During Control Read Data Phase

XMC4500
XMC4000 Family
16.7.7.10 Premature Status During Control Write

This example assumes a Three-Stage control write transfer with only Wlength field in the
SETUP indicating two packets in the data phase. But the host switch to data phase after
the first packet of the data phase is complete.
descriptor.
6. Application clears NAK for the data phase, after receiving DOEPINTx.SetUp interrupt
(Step 5).
8. DMA sees TxFIFO non empty and starts transferring the OUT packet to the system
memory.
9. Host switch to status phase (IN token) without completing the data phase.
10. The core generates DOEPINTx.XferComp after closing the descriptor after the data
fetch.
11. Application sets up descriptor, enables IN endpoint and clear NAK.
12. The core starts to fetch the descriptor and data for the status phase once application
has enabled the IN endpoint.
13. The core generates DIEPINTx.XferCompl after doing the data fetch and the
descriptor update (step 12)
14. The core sends data out in response to status phase IN token.

XMC4500
XMC4000 Family
Figure 16-46 Premature Status Phase During Control Write

XMC4500
XMC4000 Family
16.7.7.11 Premature Status During Control Read

In this example, it is assumed that the data phase consists of two packets, and the
application allocates these two packets in a single buffer. After one packet in the data
phase, host switches to status phase.
descriptor.
3. On receiving the first data phase IN token after the SETUP, the core push a
SETUP_COMPLETE status into the RxFIFO.Core NAKs the data phase IN tokens
8. Application clear the NAK after receiving the setup complete (DOEPINT.SetUp)
interrupt.
11. Host switches to status phase and sends the status phase OUT token. Core ACks
the OUT packet because the NAK has already been cleared.
12. The DMA detects the RxFIFO as non-empty (because of the status phase data) and
does following.
descriptor.
d) The core generates DOEPINTx.XferCompl after transferring the status phase data
to system memory and closing the descriptor.

XMC4500
XMC4000 Family
Figure 16-47 Premature Status Phase During Control Read

XMC4500
XMC4000 Family
16.7.7.12 Lost ACK During Last Packet of Control Read

This is similar to the previous section. Figure 16-48 shows this.
Figure 16-48 Lost ACK During Last Packet of Control Read
16.7.8 Bulk IN Transfer Data Transaction in Scatter-Gather DMA Mode

XMC4500
XMC4000 Family
16.7.8.1 Interrupt usage

The following interrupts are of relevance.
1. DIEPINTx.XferCompl (Transfer complete, based on IOC bit in the descriptor)
2. DIEPINTx.BNA (Buffer Not Available)
16.7.8.2 Application Programming Sequence

This section describes the application programming sequence for Bulk IN transfer
scenarios.

XMC4500
XMC4000 Family
Figure 16-49 IN Descriptor List

XMC4500
XMC4000 Family
1. Prepare Descriptor(s):
2. The application creates descriptor list(s) in the system memory pertaining to an
Endpoint.
3. Each descriptor list may have up to n descriptors and there may be up to m descriptor
lists.
4. Application may choose to set the IOC bit of the corresponding descriptor. If the IOC
is set for the last descriptor of the list, the core generates DIEPINTx.XferCompl
interrupt after the entire list is processed.
5. Program DIEPDMAx:
a) Application programs the base address of the descriptor in the corresponding IN
Endpoint DIEPDMAx register.
6. Enable DMA:
a) Application programs the corresponding endpoint DIEPCTLx register with the
following
- DIEPCTLx.MPS Max Packet size of the endpoint
- DIEPCTLx.CNAKSet to 1 to clear the NAK
- DIEPCTLx.EPEna Set to 1 to enable the DMA for the endpoint.
7. Wait for Interrupt:
a) On reception of DIEPINTx.XferCompl, application must check the Buffer status
and Tx Status field of the descriptor to ascertain that the descriptor closed
normally.
DIEPINTx.BNA interrupt gets generated by the core when it encounters a descriptor in
the list whose Buffer Status field is not Host Ready. In this case, the application is
suppose to read the DIEPDMAx register to ascertain the address for which the BNA
interrupt is asserted to take corrective action.
16.7.8.3 Internal Flow
Bulk IN Transfers
The core handles Bulk IN transfers internally as functionally depicted in Figure 16-50
(Non ISO IN Descriptor/Data Processing). Figure 16-51 depicts this flow.

XMC4500
XMC4000 Family
Figure 16-50 Non ISO IN Descriptor/Data Processing

XMC4500
XMC4000 Family
Figure 16-51 Bulk IN Transfers

1. When a BULK IN token is received on an end point before the corresponding DMA is
enabled, (DIEPCTLx.EPEna = 0B), it is NAKed on USB.
2. As a result of application enabling the DMA for the corresponding end point
(DIEPCTLx.EPEna=1), the core fetches the descriptor and processes it.
3. The DMA fetches the data from the system memory and populates its internal FIFO
with this data.
4. After fetching all the data from a descriptor, the core closes the descriptor with a
DMA_DONE status.
5. On reception of BULK IN tokens on USB, data is sent to the USB Host.
6. After the last descriptor in the chain is processed, the core generates
DIEPINTx.XferCompl interrupt provided the IOC bit for the last descriptor is set.

XMC4500
XMC4000 Family
16.7.9 Bulk OUT Data Transaction in Scatter-Gather Mode
16.7.9.1 Interrupt Usage

The following interrupts are of relevance.
1. DOEPINTx.XferCompl (Transfer complete, based on IOC bit in the descriptor)
2. DOEPINTx.BNA (Buffer Not Available)

XMC4500
XMC4000 Family
16.7.9.2 Application Programming Sequence

This section describes the application programming sequence to take care of Bulk OUT
transfer scenarios.
Figure 16-52 OUT Descriptor List

XMC4500
XMC4000 Family
1. Prepare Descriptor(s):
2. The application creates descriptor list(s) in the system memory pertaining to an
Endpoint.
3. Each descriptor list may have up to n descriptors and there may be up to m descriptor
lists.
4. Application may choose to set the IOC bit of the corresponding descriptor. If the IOC
is set for the last descriptor of the list, the core generates DOEPINTx.XferCompl
interrupt after the entire list is processed.
a) a. Based on L bit and MTRF bit combinations, the core may disable the end point.
Refer to Table 16-8 OUT Data Memory Structure Values on Page 16-130 for
bit field descriptions.
5. Program DOEPDMAx:
a) Application programs the base address of the descriptor in the corresponding OUT
Endpoint DOEPDMAx register.
6. Enable DMA:
a) Application programs the corresponding endpoint DOEPCTLx register with the
following
- DOEPCTL.MPS Max Packet size of the endpoint
- DOEPCTL.CNAKSet to 1 to clear the NAK
- DOEPCTL.EPEna Set to 1 to enable the DMA for the endpoint.
a) On reception of DOEPINTx.XferCompl, application must check the Buffer status
and Rx Status field of the descriptor to ascertain that the descriptor closed
normally.
DOEPINTx.BNA interrupt gets generated by the core when it encounters a descriptor in
suppose to read the DOEPDMAx register to ascertain the address for which the BNA

The core handles Bulk OUT transfers internally as depicted in Figure 16-53.
Figure 16-54 also diagrams this flow.

XMC4500
XMC4000 Family
Figure 16-53 Non ISO OUT Descriptor/Data Buffer Processing

XMC4500
XMC4000 Family
Figure 16-54 Bulk OUT Transfers

1. When a BULK OUT token is received on an end point, the core stores the received
data internally in a FIFO.
(DOEPCTLx.EPEna=1), the core fetches the descriptor and processes it.
3. The DMA transfers the data from the internal FIFO to system memory.
4. After transferring all the data from the FIFO, the core closes the descriptor with a
DMA_DONE status.
DOEPINTx.XferCompl interrupt provided the IOC bit for the last descriptor is set.
16.7.10 Interrupt IN Data Transaction in Scatter/Gather DMA Mode

Application programming for Interrupt IN transfers is as with the Bulk IN transfer
sequence. The core handles Interrupt IN transfers internally in the same way it handles
Bulk IN transfers
16.7.11 Interrupt OUT Transfer

Application programming for Interrupt OUT transfers is as with the Bulk OUT transfer
sequence. The core handles Interrupt OUT transfers internally in the same way it
handles Bulk OUT Transfers

XMC4500
XMC4000 Family
16.7.12 Isochronous IN Transfer

The application programming for Isochronous IN transfers is in the same manner as Bulk
IN transfer sequence.
The following behavior is of importance while working with Isochronous IN end points
DCTL.IgnrFrmNum = 1B
The way the core handles Isochronous IN transfers internally in the same way as it
handles Bulk IN Transfers.
DCTL.IgnrFrmNum = 0B
The core closes the descriptor and clears the corresponding fetched data in the FIFO if
the USB frame number to which the descriptor belongs is elapsed.
16.7.12.1 Isochronous Transfers in Scatter/Gather (Descriptor DMA)

Mode
This topic includes descriptions of both isochronous IN and OUT transfers
Isochronous IN
In the case of ISO IN After descriptor is fetched, the frame number field M is compared
with current USB frame number N.
If the frame number in the fetched descriptor is already elapsed (M<N) then the
descriptor is closed with status changed to DMA Done.
If the frame number in the fetched descriptor is for future (N>M+1) then the descriptor is
left untouched. The Core suspends and re-look at this descriptor contents in the next
frame.
If the frame number in the fetched descriptor is for current or next frame (N=M or
M+1) then the descriptor is further processed as per the flow chart. At the end of data
transfer from memory to TxFIFO the above check must be performed. And if the data
fetch finished in the subsequent frame, data must be flushed and descriptor must be
closed (DMA Done) with BUFFLUSH status.
For ISO IN, the application creates a series of descriptors (D,D+1,D+2) for a given
periodic end point corresponding to successive frames (N,N+1,N+2).
Note: The series of descriptors does not correspond to the series of frames in the same
order.
For example, D and D + 1 may correspond to N, D + 2 may correspond to N + 1 and so
on except in the case where the application can create more than one descriptor for the
same frame. The core fetches the descriptor and compares the frame/ ^frame number
field with the current frame/ ^frame number.
If the fetched descriptor corresponds to a frame which has already elapsed, the core
updates the descriptor with DMA Done Buffer status and proceeds to the next descriptor.

XMC4500
XMC4000 Family
If the next descriptor fetched indicates that it corresponds to frame number N or N + 1,

it services it. In the process of fetching the descriptors, if the core determines that the
descriptor corresponds to a future frame/ ^.frame (> N + 1), it does not service the
descriptor in that frame/^frame. Instead, it moves on to the next periodic endpoint or non-
periodic endpoint without disabling the current periodic endpoint. It revisits this endpoint
in the next frame/ ^.frame and repeats the process.
Figure 16-55 ISO IN Data Flow

This section describes the application programming sequence for Isochronous IN
transfer scenarios.
Prepare Descriptor(s)
The application creates descriptor list(s) in the system memory pertaining to an
Endpoint.
Each descriptor list may have up to n descriptors and there may be up to m descriptor
lists.
Application may choose to set the IOC bit of the corresponding descriptor. If the IOC is
set for the last descriptor of the list, the core generates DIEPINTx.XferCompl interrupt
after the entire list is processed.
1. Program DIEPDMAx:
a) Application programs the base address of the descriptor in the corresponding IN
Endpoint DIEPDMAx register.
2. Enable DMA:
a) Application programs the corresponding endpoint DIEPCTLx register with the
following
- DIEPCTLx.MPS Max Packet size of the endpoint
- DIEPCTLx.CNAKSet to 1 to clear the NAK
- DIEPCTLx.EPEna Set to 1 to enable the DMA for the endpoint.

XMC4500
XMC4000 Family

a) On reception of DIEPINTx.XferCompl, application must check the Buffer status
and Tx Status field of the descriptor to ascertain that the descriptor closed
normally.
DIEPINTx.BNA interrupt gets generated by the core when it encounters a descriptor in
suppose to read the DIEPDMAx register to ascertain the address for which the BNA

The core handles isochronous IN transfers internally as functionally depicted in
Figure 16-56. Figure 16-57 also diagrams this flow.

XMC4500
XMC4000 Family
Figure 16-56 ISO IN Descriptor/Data Processing

XMC4500
XMC4000 Family
Figure 16-57 Isochronous IN Transfers

1. When an Isochronous IN token is received on an end point before the corresponding
DMA is enabled, (DIEPCTLx.EPEna = 0B), zero length packet is sent on USB.
(DIEPCTLx.EPEna=1), the core fetches the descriptor. If the descriptor belongs to
the current or the next USB frame number, the core processes it.
3. The DMA fetches the data pointed by the above descriptor from the system memory
and populates its internal FIFO with this data.
4. After fetching all the data, the core closes the descriptor with a DMA_DONE status.
5. On reception of Isochronous IN tokens on USB, data is sent to the USB Host.
DIEPINTx.XferCompl interrupt provided the IOC bit for the last descriptor is set.
7. When the DMA fetches a descriptor whose USB frame number has been already
elapsed, it closes that descriptor with a DMA_DONE status without fetching the data
for that descriptor.
8. When the DMA fetches a descriptor which has a future USB frame number, it does
not service it in the current context. It services it in the future.

XMC4500
XMC4000 Family
16.7.13 Isochronous OUT Transfer

The application programming for isochronous out transfers is in the same manner as
Bulk OUT transfer sequence, except that the application creates only 1 packet per
descriptor for an isochronous OUT endpoint. The core handles isochronous OUT
transfers internally in the same way it handles Bulk OUT transfers, and as depicted in
Figure 16-58.

XMC4500
XMC4000 Family
Figure 16-58 Isochronous OUT Descriptor/Data Buffer Processing

XMC4500
XMC4000 Family
Isochronous OUT
For ISO OUT transactions, the core transfers the packets from the Rx FIFO to the system
memory and updates the frame number field of the descriptor with the frame number in
which the packet was received.The frame number for which data is received is extracted
from the Receive Status queue and written back to the descriptor.
Figure 16-59 ISO Out Data Flow

Note: Incomplete Isochronous Interrupt (GINTSTS.incomplete) is not generated in
Scatter/Gather DMA mode. Received isochronous packets are sent unmodified to
the application memory, with the corresponding frame number updated in the
descriptor status.
16.8 OTG Revision 1.3 Programming Model

This section describes the OTG programming model when the OTG core is configured
to support OTG Revision 1.3 of the specification.
The USB core is an OTG device supporting HNP and SRP. When the core is connected
to an "A" plug, it is referred to as an A-device. When the core is connected to a "B" plug
it is referred to as a B-device. In Host mode, the USB core turns off VBUS to conserve
power. SRP is a method by which the B-device signals the A-device to turn on VBUS
power. A device must perform both data-line pulsing and VBUS pulsing, but a host can
detect either data-line pulsing or VBUS pulsing for SRP. HNP is a method by which the
B-device negotiates and switches to host role. In Negotiated mode after HNP, the B-
device suspends the bus and reverts to the device role.
16.8.1 A-Device Session Request Protocol

The application must set the SRP-Capable bit in the Core USB Configuration register.
This enables the USB core to detect SRP as an A-device.

XMC4500
XMC4000 Family
Figure 16-60 A-Device SRP

1. To save power, the application suspends and turns off port power when the bus is
idle by writing the port Suspend and Port Power bits in the Host Port Control and
Status register.
2. PHY indicates port power off by deasserting the utmi_vbusvalid signal.
3. The device must detect SE0 for at least 2 ms to start SRP when Vbus power is off.
4. To initiate SRP, the device turns on its data line pull-up resistor for 5 to 10 ms. The
USB core detects data-line pulsing.
5. The device drives VBUS above the A-device session valid (2.0 V minimum) for VBUS
pulsing.
The USB core interrupts the application on detecting SRP. The Session Request
Detected bit is set in Global Interrupt Status register (GINTSTS.SessReqInt).
6. The application must service the Session Request Detected interrupt and turn on the
Port Power bit by writing the Port Power bit in the Host Port Control and Status
register. The PHY indicates port power-on by asserting utmi_vbusvalid signal.
7. When the USB is powered, the device connects, completing the SRP process.
16.8.2 B-Device Session Request Protocol

The application must set the SRP-Capable bit in the Core USB Configuration register.
This enables the USB core to initiate SRP as a B-device. SRP is a means by which the
USB core can request a new session from the host.

XMC4500
XMC4000 Family
Figure 16-61 B-Device SRP

1. To save power, the host suspends and turns off port power when the bus is idle. PHY
indicates port power off by deasserting the utmi_vbusvalid signal.The USB core sets
the Early Suspend bit in the Core Interrupt register after 3 ms of bus idleness.
Following this, the USB core sets the USB Suspend bit in the Core Interrupt
register.The PHY indicates the end of the B-device session by deasserting the
utmi_bvalid signal.
2. The USB core asserts the utmi_dischrgvbus signal to indicate to the PHY to speed
up VBUS discharge.
3. The PHY indicates the sessions end by asserting the utmi_sessend signal. This is
the initial condition for SRP. The USB core requires 2 ms of SE0 before initiating
SRP.
For a USB 1.1 full-speed serial transceiver, the application must wait until VBUS
discharges to 0.2 V after GOTGCTL.BSesVld is deasserted.
4. The application initiates SRP by writing the Session Request bit in the OTG Control
and Status register. The USB core perform data-line pulsing followed by VBUS
pulsing.
5. The host detects SRP from either the data-line or VBUS pulsing, and turns on VBUS.
The PHY indicates VBUS power-on by asserting utmi_vbusvalid.
6. The USB core performs VBUS pulsing by asserting utmi_chrgvbus.
The host starts a new session by turning on VBUS, indicating SRP success. The USB
core interrupts the application by setting the Session Request Success Status
Change bit in the OTG Interrupt Status register. The application reads the Session
Request Success bit in the OTG Control and Status register.
7. When the USB is powered, the USB core connects, completing the SRP process.

XMC4500
XMC4000 Family
16.8.3 A-Device Host Negotiation Protocol

HNP switches the USB host role from the A-device to the B-device. The application must
set the HNP- Capable bit in the Core USB Configuration register to enable the USB core
to perform HNP as an A-device.
Figure 16-62 A-Device HNP

1. The USB core sends the B-device a SetFeature b_hnp_enable descriptor to enable
HNP support. The B-devices ACK response indicates that the B-device supports
HNP. The application must set Host Set HNP Enable bit in the OTG Control and
Status register to indicate to the USB core that the B-device supports HNP.
2. When it has finished using the bus, the application suspends by writing the Port
Suspend bit in the Host Port Control and Status register.
3. When the B-device observes a USB suspend, it disconnects, indicating the initial
condition for HNP. The B-device initiates HNP only when it must switch to the host
role; otherwise, the bus continues to be suspended.
The USB core sets the Host Negotiation Detected interrupt in the OTG Interrupt
Status register, indicating the start of HNP.
The USB core deasserts the utmiotg_dppulldown and utmiotg_dmpulldown signals
to indicate a device role. The PHY enable the D+ pull-up resistor indicates a connect
for B-device.
The application must read the Current Mode bit in the OTG Control and Status
register to determine Device mode operation.
4. The B-device detects the connection, issues a USB reset, and enumerates the USB
core for data traffic.
5. The B-device continues the host role, initiating traffic, and suspends the bus when
done.
The USB core sets the Early Suspend bit in the Core Interrupt register after 3 ms of
bus idleness. Following this, the USB core sets the USB Suspend bit in the Core
Interrupt register.

XMC4500
XMC4000 Family
6. In Negotiated mode, the USB core detects the suspend, disconnects, and switches
back to the host role. The USB core asserts the utmiotg_dppulldown and
utmiotg_dmpulldown signals to indicate its assumption of the host role.
7. The USB core sets the Connector ID Status Change interrupt in the OTG Interrupt
Status register. The application must read the connector ID status in the OTG Control
and Status register to determine the USB core's operation as an A-device. This
indicates the completion of HNP to the application. The application must read the
Current Mode bit in the OTG Control and Status register to determine Host mode
operation.
8. The B-device connects, completing the HNP process.
16.8.4 B-Device Host Negotiation Protocol

HNP switches the USB host role from B-device to A-device. The application must set the
HNP-Capable bit in the Core USB Configuration register to enable the USB core to
perform HNP as a B-device.
Figure 16-63 B-Device HNP

1. The A-device sends the SetFeature b_hnp_enable descriptor to enable HNP
support. The USB cores ACK response indicates that it supports HNP. The
application must set the Device HNP Enable bit in the OTG Control and Status
register to indicate HNP support.
The application sets the HNP Request bit in the OTG Control and Status register to
indicate to the USB core to initiate HNP.
2. When it has finished using the bus, the A-device suspends by writing the Port
Suspend bit in the Host Port Control and Status register.
The USB core sets the Early Suspend bit in the Core Interrupt register after 3 ms of
bus idleness. Following this, the USB core sets the USB Suspend bit in the Core
Interrupt register.

XMC4500
XMC4000 Family
The USB core disconnects and the A-device detects SE0 on the bus, indicating HNP.
The USB core asserts the utmiotg_dppulldown and utmiotg_dmpulldown signals to
indicate its assumption of the host role.
The A-device responds by activating its D+ pull-up resistor within 3 ms of detecting
SE0. The USB core detects this as a connect.
The USB core sets the Host Negotiation Success Status Change interrupt in the OTG
Interrupt Status register, indicating the HNP status. The application must read the
Host Negotiation Success bit in the OTG Control and Status register to determine
host negotiation success. The application must read the Current Mode bit in the Core
Interrupt register (GINTSTS) to determine Host mode operation.
3. The application sets the reset bit (HPRT.PrtRst) and the USB core issues a USB
reset and enumerates the A-device for data traffic
4. The USB core continues the host role of initiating traffic, and when done, suspends
the bus by writing the Port Suspend bit in the Host Port Control and Status register.
5. In Negotiated mode, when the A-device detects a suspend, it disconnects and
switches back to the host role. The USB core deasserts the utmiotg_dppulldown and
utmiotg_dmpulldown signals to indicate the assumption of the device role.
6. The application must read the Current Mode bit in the Core Interrupt (GINTSTS)
register to determine the Host mode operation.
7. The USB core connects, completing the HNP process.
16.9 Clock Gating Programming Model

When the USB is suspended or the session is not valid, the PHY is driven into Suspend
mode, and the PHY clock is stopped to reduce power consumption in the PHY and the
USB core. The PHY clock is turned off for as long as the core asserts the suspend signal.
To further reduce power consumption, the USB core also supports AHB clock gating.
The AHB clock to some of the USB internal modules can be gated by writing to the Gate
Hclk bit in the Power and Clock Gating Control register.
The following sections show the procedures to use the clock gating feature.
16.9.1 Host Mode Suspend and Resume With Clock Gating

Sequence of operations:
1. The application sets the Port Suspend bit in the Host Port Control and Signal register,
and the core drives a USB suspend.
2. The application sets the Stop PHY Clock bit in the Power and Clock Gating Control
register, the core asserts the suspend signal to the PHY, and the PHY clock stops.
The application sets the Gate hclk bit in the Power and Clock Gating Control register,
the core gates the hclk (hclk_gated) to AHB- domain modules other than the BIU.
3. The core remains in Suspend mode.
4. The application clears the Gate hclk and Stop PHY Clock bits, and the PHY clock is
generated.

XMC4500
XMC4000 Family
5. The application sets the Port Resume bit, and the core starts driving Resume
signaling.
6. The application clears the Port Resume bit after at least 20 ms.
7. The core is in normal operating mode.
Figure 16-64 Host Mode Suspend and Resume With Clock Gating
16.9.2 Host Mode Suspend and Remote Wakeup With Clock Gating
1. The application sets the Port Suspend bit in the Host Port CSR, and the core drives
a USB suspend.
register, the core asserts the suspend_n signal to the PHY, and the PHY clock stops.
and the core gates the hclk (hclk_ctl) to AHB- domain modules other than the BIU.
4. The Remote Wakeup signaling from the device is detected. The core deasserts the
suspend_n signal to the PHY to generate the PHY clock. The core generates a
Remote Wakeup Detected interrupt.
5. The application clears the Gate hclk and Stop PHY Clock bits. The core sets the Port
Resume bit.
6. The application clears the Port Resume bit after at least 20 ms.

XMC4500
XMC4000 Family
Figure 16-65 Host Mode Suspend and Remote Wakeup With Clock Gating
16.9.3 Host Mode Session End and Start With Clock Gating
a USB suspend.
2. The application clears the Port Power bit. The core turns off VBUS.
4. The core remains in Low-Power mode.
5. The application clears the Gate hclk bit and the application clears the Stop PHY
Clock bit to start the PHY clock.
6. The application sets the Port Power bit to turn on VBUS.
7. The core detects device connection and drives a USB reset.
16.9.4 Host Mode Session End and SRP With Clock Gating
a USB suspend.
2. The application clears the Port Power bit. The core turns off VBUS.

XMC4500
XMC4000 Family
5. SRP (data line pulsing) from the device is detected. The core deasserts the
suspend_n signal to the PHY to generate the PHY clock. An SRP Request Detected
interrupt is generated.
6. The application clears the Gate hclk bit and the Stop PHY Clock bit.
7. The core sets the Port Power bit to turn on VBUS.
8. The core detects device connection and drives a USB reset.
16.9.5 Device Mode Suspend and Resume With Clock Gating

1. The core detects a USB suspend and generates a Suspend Detected interrupt.
4. The Resume signaling from the host is detected. The core deasserts the suspend_n
signal to the PHY to generate the PHY clock. A Resume Detected interrupt is
generated.
6. The host finishes Resume signaling.
16.9.6 Device Mode Suspend and Remote Wakeup With Clock Gating
1. The core detects a USB suspend and generates a Suspend Detected interrupt.
the core gates the hclk (hclk_ctl) to AHB-domain modules other than the BIU.
5. The application sets the Remote Wakeup bit in the Device Control register, the core
starts driving Remote Wakeup signaling.
6. The host drives Resume signaling.

XMC4500
XMC4000 Family
16.9.7 Device Mode Session End and Start With Clock Gating
1. The core detects a USB suspend, and generates a Suspend Detected interrupt. The
host turns off VBUS.
4. The new session is detected (bsessvld is high). The core deasserts the suspend_n
signal to the PHY to generate the PHY clock. A New Session Detected interrupt is
generated.
5. The application clears the Gate hclk and Stop PHY Clock bits.
6. The core detects USB reset.
7. The core is in normal operating mode
16.9.8 Device Mode Session End and SRP With Clock Gating
1. The core detects a USB suspend, and generates a Suspend Detected interrupt. The
host turns off VBUS.
4. The application clears the Gate hclk and Stop PHY Clock bits.
5. The application sets the SRP Request bit, and the core drives data line and VBUS
pulsing.
6. The host turns on Vbus, detects device connection, and drives a USB reset.
16.10 FIFO RAM Allocation
16.10.1 Data FIFO RAM Allocation

The RAM must be allocated among different FIFOs in the core before any transactions
can start. The application must follow this procedure every time it changes core FIFO
RAM allocation.
The application must allocate data RAM per FIFO based on the AHB's operating
frequency, the PHY Clock frequency, the available AHB bandwidth, and the performance

XMC4500
XMC4000 Family
required on the USB. Based on the above mentioned criteria, the application must
provide a table as described below with RAM sizes for each FIFO in each mode.
USB core shares a single SPRAM between transmit FIFO(s) and receive FIFO.
In DMA mode The SPRAM is also used for storing some register information.
In non Scatter Gather mode The Device mode Endpoint DMA address registers
(DI/OEPDMAn) and Host mode Channel DMA registers (HCDMA) are stored in the
SPRAM.
In Scatter Gather DMA modeThe Base descriptor address, the Current descriptor
address, the current buffer address and the descriptor status quadlet information for
each endpoint/channel are stored in the SPRAM.
These register information are stored at the end of the SPRAM after the space
allocated for receive and Transmit FIFO. These register space must also be taken
into account when calculating the total FIFO depth of the core as explained in the
following sections.
In addition, the registers DIEPDMAx/DOEPDMAx are maintained in RAM regardless of
the enabled/disabled setting for Dynamic FIFO Sizing.
The following rules apply while calculating how much RAM space must be allocated to
store these registers.
Host Mode
Slave mode only: No space needed.
Buffer DMA mode: One location per channel.
Scatter/Gather DMA mode: Four locations per channel as listed below.
Location for storing current descriptor address.
Location for storing current buffer address.
Location for storing the status quadlet that is used by the List processor
Location for storing the transfer size used by the token request block
For example in Scatter/Gather DMA mode, if there are ten channels, then the last forty
SPRAM locations are reserved for storing these values.

XMC4500
XMC4000 Family
Device Mode
Slave mode only: No space needed.
Buffer DMA mode: One location per end point direction.
Scatter/Gather DMA mode: Four locations per endpoint direction:
Location for storing base descriptor address.
Location for storing current descriptor address.
Location for storing the current buffer address.
Location to store the descriptor status quadlet
For example in Scatter/Gather DMA mode, if there are five bidirectional endpoints, then
the last forty SPRAM locations are reserved for storing these values.
16.10.1.1 Device Mode RAM Allocation

When allocating data RAM for FIFOs in Device mode when dedicated TX FIFO is used,
keep in mind these factors:
1. Receive FIFO RAM Allocation:
a) RAM for SETUP Packets: 4 * n + 6 locations must be Reserved in the receive FIFO
to receive up to n SETUP packets on control endpoints, where n is the number of
control endpoints the device core supports. The core does not use these locations,
which are Reserved for SETUP packets, to write any other data.
b) One location for Global OUT NAK
c) Status information is written to the FIFO along with each received packet.
Therefore, a minimum space of (Largest Packet Size / 4) + 1 must be allotted to
receive packets. If a high-bandwidth endpoint is enabled, or multiple isochronous
endpoints are enabled, then at least two (Largest Packet Size / 4) + 1 spaces must
be allotted to receive back-to-back packets. Typically, two (Largest Packet Size /
4) + 1 spaces are recommended so that when the previous packet is being
transferred to AHB, the USB can receive the subsequent packet. If AHB latency is
high, enough space must be allocated to receive multiple packets. This is critical
to prevent dropping any isochronous packets.
d) Along with each endpoint's last packet, transfer complete status information is also
pushed to the FIFO. Typically, one location for each OUT endpoint is
recommended.
2. Transmit FIFO RAM Allocation:
a) The minimum RAM space required for each IN Endpoint Transmit FIFO is the
maximum packet size for that particular IN endpoint.
b) More space allocated in the transmit IN Endpoint FIFO results in a better
performance on the USB and can hide latencies on the AHB.

XMC4500
XMC4000 Family
Table 16-16 FIFO Name - Data RAM Size 2

FIFO Name Data RAM Size
Receive data FIFO rx_fifo_size. This must include RAM for setup packets, OUT
endpoint control information and data OUT packets, as
mentioned earlier.
Transmit FIFO 0 tx_fifo_size[0]
... ...
Transmit FIFO i tx_fifo_size[i]
With this information, the following registers must be programmed as follows:

1. Receive FIFO Size Register (GRXFSIZ)
GRXFSIZ.Receive FIFO Depth = rx_fifo_size;
2. Device IN Endpoint Transmit FIFO0 Size Register (GNPTXFSIZ)
GNPTXFSIZ.non-periodic Transmit FIFO Depth = tx_fifo_size[0];
GNPTXFSIZ.non-periodic Transmit RAM Start Address = rx_fifo_size;
3. Device IN Endpoint Transmit FIFO#1 Size Register (DIEPTXF1)
DIEPTXF1. Transmit RAM Start Address = GNPTXFSIZ.FIFO0 Transmit RAM Start
Address + tx_fifo_size[0];
4. Device IN Endpoint Transmit FIFO#2 Size Register (DIEPTXF2)
DIEPTXF2.Transmit RAM Start Address = DIEPTXF1.Transmit RAM Start Address
+ tx_fifo_size[1];
5. Device IN Endpoint Transmit FIFO#i Size Register (DIEPTXFi)
DIEPTXFm.Transmit RAM Start Address = DIEPTXFi-1.Transmit RAM Start
Address + tx_fifo_size[i-1];
6. The transmit FIFOs and receive FIFO must be flushed after the RAM allocation is
done, for the proper functioning of the FIFOs.
a) GRSTCTL.TxFNum = 10H
b) GRSTCTL.TxFFlush = 1B
c) GRSTCTL.RxFFlush = 1B
d) The application must wait until the TxFFlush bit and the RxFFlush bits are cleared
before performing any operation on the core.

XMC4500
XMC4000 Family
16.10.1.2 Host Mode RAM Allocation

Considerations for allocating data RAM for Host Mode FIFOs are listed here:
Receive FIFO RAM allocation:

Status information is written to the FIFO along with each received packet. Therefore, a
minimum space of (Largest Packet Size / 4) + 2 must be allotted to receive packets. If a
high-bandwidth channel is enabled, or multiple isochronous channels are enabled, then
at least two (Largest Packet Size / 4) + 2 spaces must be allotted to receive back-to-back
packets. Typically, two (Largest Packet Size / 4) + 2 spaces are recommended so that
when the previous packet is being transferred to AHB, the USB can receive the
subsequent packet. If AHB latency is high, enough space must be allocated to receive
multiple packets.
Along with each host channel's last packet, information on transfer complete status and
channel halted is also pushed to the FIFO. So two locations must be allocated for this.
For handling NAK/NYET in Buffer DMA mode, the application must determine the
number of Control/Bulk OUT endpoint data that must fit into the TX_FIFO at the same
instant. Based on this, one location each is required for Control/Bulk OUT endpoints.
For example, when the host addresses one Control OUT endpoint and three Bulk OUT
endpoints, and all these must fit into the non-periodic TX_FIFO at the same time, then
four extra locations are required in the RX FIFO to store the rewind status information for
each of these endpoints.
Transmit FIFO RAM allocation

The minimum amount of RAM required for the Host Non-periodic Transmit FIFO is the
largest maximum packet size among all supported non-periodic OUT channels.
More space allocated in the Transmit Non-periodic FIFO results in better performance
on the USB and can hide AHB latencies. Typically, two Largest Packet Sizes' worth of
space is recommended, so that when the current packet is under transfer to the USB,
the AHB can get the next packet. If the AHB latency is large, then enough space must
be allocated to buffer multiple packets.
The minimum amount of RAM required for Host periodic Transmit FIFO is the largest
maximum packet size among all supported periodic OUT channels. If there is at lease
one High Bandwidth Isochronous OUT endpoint, then the space must be at least two
times the maximum packet size of that channel.
Internal Register Storage Space Allocation

When operating in Buffer DMA mode, the DMA address register for each host channel
(HCDMAx) is stored in the SPRAM. One location for each channel must be reserved for
this.

XMC4500
XMC4000 Family
When operating in Scatter/Gather DMA mode, four locations per channel must be
reserved.
Table 16-17 FIFO Name - Data RAM Size 3

FIFO Name Data RAM Size
Receive Data FIFO rx_fifo_size
Non-periodic Transmit FIFO tx_fifo_size[0]
IN Endpoint Transmit FIFO tx_fifo_size[1]
With this information, the following registers must be programmed:

1. Receive FIFO Size Register (GRXFSIZ)
a) GRXFSIZ.RxFDep= rx_fifo_size;
2. Non-periodic Transmit FIFO Size Register (GNPTXFSIZ)
a) GNPTXFSIZ.NPTxFDe=tx_fifo_size[0];
b) GNPTXFSIZ.NPTxFStAddr = rx_fifo_size;
3. Host Periodic Transmit FIFO Size Register (HPTXFSIZ)
a) HPTXFSIZ.PTxFSize = tx_fifo_size[1];
b) HPTXFSIZ.PTxFStAddr= GNPTXFSIZ.NPTxFStAddr +
tx_fifo_size[0];
4. The transmit FIFOs and receive FIFO must be flushed after RAM allocation for proper
FIFO function.
a) GRSTCTL.TxFNum = 10H
b) GRSTCTL.TxFFlush = 1B
c) GRSTCTL.RxFFlush = 1B
d) The application must wait until the TxFFlush bit and the RxFFlush bits are cleared
before performing any operation on the core.
16.10.2 Dynamic FIFO Allocation

The application can change the RAM allocation for each FIFO during the operation of the
core.
16.10.2.1 Host Mode

In Host mode, before changing FIFO data RAM allocation, the application must
determine the following. All channels are disabled
All FIFOs are empty
Once these conditions are met, the application can reallocate FIFO data RAM as
explained in Data FIFO RAM Allocation on Page 16-201.

XMC4500
XMC4000 Family
After reallocating the FIFO data RAM, the application must flush all FIFOs in the core
using the GRSTCTL.TxFIFO Flush and GRSTCTL.RxFIFO Flush fields. Flushing is
required to reset the pointers in the FIFOs for proper FIFO operation after reallocation.
16.10.2.2 Device Mode

In Device mode, before changing FIFO data RAM allocation, the application must
determine the following.
All IN and OUT endpoints are disabled
NAK mode is enabled in the core on all IN endpoints
Global OUT NAK mode is enabled in the core
All FIFOs are empty
Once these conditions are met, the application can reallocate FIFO data RAM as
explained in Data FIFO RAM Allocation on Page 16-201. When NAK mode is
enabled in the core, the core responds with a NAK handshake on all tokens received on
the USB, except for SETUP packets.
After the reallocating the FIFO data RAM, the application must flush all FIFOs in the core
using the GRSTCTL.TxFIFO Flush and GRSTCTL.RxFIFO Flush fields. Flushing is
required to reset the pointers in the FIFOs for proper FIFO operation after reallocation.

XMC4500
XMC4000 Family
The Core Interrupt Handler
Figure 16-66 Core Interrupt Handler

XMC4500
XMC4000 Family

The USB module provides a single service request output connected to an interrupt node
in the Nested Vectored Interrupt Controller (NVIC)
Figure 16-67 displays the USB core interrupt hierarchy.
Session Request/ New Session Detect ed
AHB Configuration
Incomplet e Isochronous OUT Transfer
Register
Incomplet e Isochronous IN Transfer
Resume/Remote Wakeup Detected
DEVI CE OUT Endpoint s Int errupt
Global Interrupt
DEVI CE IN Endpoints Interrupt
Mask (Bit 0) AND

Connect or ID S tatus Change
Host Periodic TxFI FO Empt y
Core
Mode Mismatch Interrupt

DEVI CE Mode Interrupts
Host Channels Interrupt
Interrupt
Disconnected Detected
Data Fet ch S uspended
OR
Host Port I nterrupt
Reset Detected
OTG Interrupt
Current Mode
AND
Reserved
Reserved
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17:10 9:8 7:3 2 1 0
Core Interrupt
Register Core Interrupt
OTG Mask Register
Interrupt
Register
Device All Endpoints
Interrupt Register
22:16 6:0 Device All Endpoints
OUT Endpoints IN Endpoints Interrupt Mask Register
Device IN /OUT Endpoint Device IN /OUT

Interrupt Registers 0 to 6 Endpoints Common
Interrupt Mask Register
Interrupt
Sources
Host Port Control and

Status Register
Host All Channels Host All Channels

Interrupt Register Interrupt Mask Register
Host Channels Interrupt Host Channels Interrupt

Registers 0 to 13 Mask Registers 0 to 13
Figure 16-67 Interrupt Hierarchy

XMC4500
XMC4000 Family
16.12 Debug Behaviour

The USB module is not affected when the CPU enters HALT mode.

When the USB module is programmed as a host, an external charge pump is required
to drive the VBUS.
The module, including all registers, can be reset to its default state by a system reset or
a software reset triggered through the setting of corresponding bits in PRSETx registers.
The module has the following input clocks:
clk_ahbm: the module clock, which is also referred to as hclk in this chapter
clk_usb: the 48 MHz PHY clock., which is also referred to as phy_clk in this chapter
In addition, the module internally generates:
hclk_gated: hclk gated for power optimization

The USB core is held in reset after a start-up from a system or software reset. The USB
PHY is also by default in the power-down state. Therefore, the application has to apply
the following initialization sequence before programming the USB core:
Release reset of USB core by writing a 1 to the USBRS bit in SCU_PRCLR2 register
Enable the 48 MHz PHY clock by configuring the USB PLL in SCU, see clock control
section in SCU chapter
Remove the USB PHY from power-down by writing 1s to the USBOTGEN and
USBPHYPDQ bits in SCU_PWSET register

XMC4500
XMC4000 Family
16.15 Registers
Register Overview
The application controls the USB core by reading from and writing to the Control and
Status Registers (CSRs) through the AHB Slave interface. These registers are 32 bits
wide and the addresses are 32-bit block aligned.
Only the Core Global, Power and Clock Gating, Data FIFO Access, and Host Port
registers can be accessed in both Host and Device modes. When the USB core is
operating in one mode, either Device or Host, the application must not access registers
from the other mode. If an illegal access occurs, a Mode Mismatch interrupt is generated
and reflected in the Core Interrupt register (GINTSTS.ModeMis).
When the core switches from one mode to another, the registers in the new mode must
be reprogrammed as they would be after a power-on reset.

USB0 5004 0000H 5007 FFFFH
Figure 16-68 shows the CSR address map. Host and Device mode registers occupy
different addresses.

XMC4500
XMC4000 Family
0000 H
Core Global CSRs (1 KB)
0400 H
Host Mode CSRs (1 KB)
0800H
Device Mode CSRs (1.5 KB)
0E00 H
Power and Clock Gating CSRs (0.5 KB)
1000H
Device EP 0/Host Channel 0 FIFO (4 KB)
2000H
Device EP 1/Host Channel 1 FIFO (4 KB)
3000 H
7000H
Device EP 6/Host Channel 6 FIFO (4 KB) DFIFO push/pop
8000H to this region only
for slave mode
Host Channel 7 FIFO (4 KB)
9000 H
D000 H
E000 H
F000 H
Reserved
20000H
Direct Access to Data FIFO RAM DFIFO debug
For Debugging (128 KB) read/write to this
3FFFFH
Figure 16-68 CSR Memory Map

The first letter of the register name is a prefix for the register type:
G: Core Global
H: Host mode
D: Device mode
Note: FIFO size and FIFO depth are used interchangeably.

XMC4500
XMC4000 Family

USB Global Registers
GOTGCTL Control and Status Register 000H U, PV U, PV Page 16-218
GOTGINT OTG Interrupt Register 004H U, PV U, PV Page 16-224
GAHBCFG AHB Configuration Register 008H U, PV U, PV Page 16-226
GUSBCFG USB Configuration Register 00CH U, PV U, PV Page 16-228
GRSTCTL Reset Register 010H U, PV U, PV Page 16-231
GINTSTS Interrupt Register 014H U, PV U, PV Page 16-235
GINTMSK Interrupt Mask Register 018H U, PV U, PV Page 16-243
GRXSTSR Receive Status Debug Read 01CH U, PV U, PV Page 16-246
Register
GRXSTSP Status Read and Pop 020H U, PV U, PV Page 16-246
Register
GRXFSIZ Receive FIFO Size Register 024H U, PV U, PV Page 16-250
GNPTXFSIZ Non-Periodic Transmit FIFO 028H U, PV U, PV Page 16-251
Size Register
GNPTXSTS Non-Periodic Transmit 02CH U, PV U, PV Page 16-253
FIFO/Queue Status Register
Reserved Reserved 030H- nBE nBE
038H
GUID User ID Register 03CH U, PV U, PV Page 16-255
058H
GDFIFOCFG DFIFO Software Config 05CH U, PV U, PV Page 16-256
Register
0FCH
HPTXFSIZ Host Periodic Transmit FIFO 100H U, PV U, PV Page 16-257
Size Register
DIEPTXFn Device IN Endpoint Transmit 104H- U, PV U, PV Page 16-258
FIFO Size Register 124H

XMC4500
XMC4000 Family

3FFH
USB Host Mode Registers
HCFG Host Configuration Register 400H U, PV U, PV Page 16-258
HFIR Host Frame Interval Register 404H U, PV U, PV Page 16-262
HFNUM Host Frame Number/Frame 408H U, PV U, PV Page 16-263
Time Remaining Register
HPTXSTS Host Periodic Transmit 410H U, PV U, PV Page 16-264
FIFO/Queue Status Register
HAINT Host All Channels Interrupt 414H U, PV U, PV Page 16-266
Register
HAINTMSK Host All Channels Interrupt 418H U, PV U, PV Page 16-267
Mask Register
HFLBADDR Host Frame List Base 41CH U, PV U, PV Page 16-268
Address Register
43CH
HPRT Host Port Control and Status 440H U, PV U, PV Page 16-269
Register
4FCH
HCCHARx Host Channel-n 500H + U, PV U, PV Page 16-273
Characteristics Register n*20
Reserved Reserved 504H + nBE nBE
n*20
HCINTx Host Channel-n Interrupt 508H + U, PV U, PV Page 16-276
Register n*20
HCINTMSKx Host Channel-n Interrupt 50CH + U, PV U, PV Page 16-279
Mask Register n*20
HCTSIZx Host Channel-n Transfer Size 510H + U, PV U, PV Page 16-281
Register n*20

XMC4500
XMC4000 Family

HCDMAx Host Channel-n DMA 514H + U, PV U, PV Page 16-284
Address Register n*20
n*20
HCDMABx Host Channel-n DMA Buffer 51CH + U, PV U, PV Page 16-288
Address Register n*20
7FFH
USB Device Mode Registers
DCFG Device Configuration 800H U, PV U, PV Page 16-289
Register
DCTL Device Control Register 804H U, PV U, PV Page 16-293
DSTS Device Status Register 808H U, PV U, PV Page 16-297
DIEPMSK Device IN Endpoint Common 810H U, PV U, PV Page 16-299
Interrupt Mask Register
DOEPMSK Device OUT Endpoint 814H U, PV U, PV Page 16-301
Common Interrupt Mask
Register
DAINT Device All Endpoints Interrupt 818H U, PV U, PV Page 16-303
Register
DAINTMSK Device All Endpoints Interrupt 81CH U, PV U, PV Page 16-304
Mask Register
824H
DVBUSDIS Device VBUS Discharge 828H U, PV U, PV Page 16-305
Time Register
DVBUSPULS Device VBUS Pulsing Time 82CH U, PV U, PV Page 16-306
E Register
DIEPEMPMS Device IN Endpoint FIFO 834H U, PV U, PV Page 16-307
K Empty Interrupt Mask
Register

XMC4500
XMC4000 Family

8FCH
DIEPCTL0 Device Control IN Endpoint 0 900H U, PV U, PV Page 16-308
Control Register
DIEPCTLx Device Endpoint n Control 900H + U, PV U, PV Page 16-314
Register n*20H
n*20H
DIEPINTx Device Endpoint-n Interrupt 908H + U, PV U, PV Page 16-324
Register n*20H
Reserved Reserved 90CH + nBE nBE
n*20H
DIEPTSIZ0 Device Endpoint 0 Transfer 910H U, PV U, PV Page 16-330
Size Register
DIEPTSIZx Device Endpoint-n Transfer 910H + U, PV U, PV Page 16-332
Size Register n*20H
DIEPDMAx Device Endpoint-n DMA 914H + U, PV U, PV Page 16-336
Address Register n*20H
DTXFSTSx Device IN Endpoint Transmit 918H + U, PV U, PV Page 16-338
FIFO Status Register n*20H
DIEPDMABx Device Endpoint-n DMA 91CH + U, PV U, PV Page 16-337
Buffer Address Register n*20H
Reserved Reserved 9E0H- nBE nBE
AFCH
DOEPCTL0 Device Control OUT Endpoint B00H U, PV U, PV Page 16-311
0 Control Register
DOEPCTLx Device Endpoint-n Control B00H + U, PV U, PV Page 16-314
Register n*20H
Reserved Reserved B04H + nBE nBE
n*20H
DOEPINTx Device Endpoint-n Interrupt B08H + U, PV U, PV Page 16-324
Register n*20H

XMC4500
XMC4000 Family

Reserved Reserved B0CH + nBE nBE
n*20H
DOEPTSIZ0 Device Endpoint 0 Transfer B10H U, PV U, PV Page 16-330
Size Register
DOEPTSIZx Device Endpoint-n Transfer B10H + U, PV U, PV Page 16-332
Size Register n*20H
DOEPDMAx Device Endpoint-n DMA B14H + U, PV U, PV Page 16-336
Address Register n*20H
Reserved Reserved B18H + nBE nBE
n*20H
DOEPDMAB Device Endpoint-n DMA B1CH + U, PV U, PV Page 16-337
x Buffer Address Register n*20H
Reserved Reserved BE0H- nBE nBE
DFCH
USB Power and Gating Register
PCGCR Power and Clock Gating E00H U, PV U, PV Page 16-338
Control Register
Reserved Reserved E04H- nBE nBE
FFCH
Data FIFO (DFIFO) Access Register Map

These registers, available in both Host and Device modes, are used to read or write the
FIFO space for a specific endpoint or a channel, in a given direction. If a host channel is
of type IN, the FIFO can only be read on the channel. Similarly, if a host channel is of
type OUT, the FIFO can only be written on the channel.
Table 16-20 Data FIFO (DFIFO) Access Register Map

FIFO Access Register Section Address Access
Range
Device IN Endpoint 0/Host OUT Channel 0: DFIFO Write Access 1000H- WO/RO
Device OUT Endpoint 0/Host IN Channel 0: DFIFO Read Access 1FFCH
... ... ...

XMC4500
XMC4000 Family
Table 16-20 Data FIFO (DFIFO) Access Register Map (contd)

FIFO Access Register Section Address Access
Range
Host OUT Channel 7: DFIFO Write Access 8000H- WO/RO
Host IN Channel 7: DFIFO Read Access 8FFCH
... ... ...
Host OUT Channel 13: DFIFO Write Access E000H- WO/RO
Host IN Channel 13: DFIFO Read Access EFFCH
Access Restriction
Note: The USB registers are accessible only through word accesses. Half-word and byte
accesses on USB registers will not generate a bus error. Write to unused address
space will not cause an error but be ignored.
16.15.1 Register Description

This section describes Core Global, Device Mode, Host Mode, and Power and Clock
Gating CSRs.
Note: Always program Reserved fields with 0s. Treat read values from Reserved fields
as unknowns (Xs).
Global Registers
These registers are available in both Host and Device modes, and do not need to be
reprogrammed when switching between these modes.
Control and Status Register (GOTGCTL)

The OTG Control and Status register controls the behavior and reflects the status of the
OTG function of the core.

XMC4500
XMC4000 Family
GOTGCTL
Control and Status Register (000H) Reset Value: 0001 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Dbn
OTG BSe ASe Conl
0 cTim
Ver sVld sVId DSts
e
r rw rh rh rh rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Dev HstS HstN Bvali Bvali Avali Avali Vbva Vbva Ses
HNP Ses
0 HNP etHN egSc dOv dOv dOv dOv lidO lidO Req
Req Req
En PEn s Val En Val En vVal vEn Scs
r rw rw rw rh rw rw rw rw rw rw rw rh

SesReqS 0 rh Session Request Success
cs The core sets this bit when a session request initiation is
successful.
0B Session request failure
1B Session request success
This bit is used in Device only.
SesReq 1 rw Session Request
The application sets this bit to initiate a session request on
the USB. The application can clear this bit by writing a 0
when the Host Negotiation Success Status Change bit in
the OTG Interrupt register
(GOTGINT.HstNegSucStsChng) is set. The core clears
this bit when the HstNegSucStsChng bit is cleared.
Since the USB 1.1 Full-Speed Serial Transceiver interface
is used to initiate the session request, the application must
wait until the Vbus discharges to 0.2 V, after the B-Session
Valid bit in this register (GOTGCTL.BSesVld) is cleared.
0B No session request
1B Session request

XMC4500
XMC4000 Family

VbvalidO 2 rw VBUS Valid Override Enable
vEn This bit is used to enable/disable the software to override
the vbus valid signal using the GOTGCTL.VbvalidOvVal.
0B Override is disabled and vbus valid signal from the
PHY is used internally by the core.
1B Internally vbus valid received from the PHY is
overridden with GOTGCTL.VbvalidOvVal.
This bit is used in Host only.
VbvalidO 3 rw VBUS Valid Override Value
vVal This bit is used to set the override value for vbus valid
signal when GOTGCTL.VbvalidOvEn is set.
0B vbusvalid value is 0B when
GOTGCTL.VbvalidOvEn = 1
1B vbusvalid value is 1B when
GOTGCTL.VbvalidOvEn = 1
AvalidOv 4 rw A-Peripheral Session Valid Override Enable
En This bit is used to enable/disable the software to override
the Avalid signal using the GOTGCTL.AvalidOvVal.
0B Override is disabled and Avalid signal from the PHY
is used internally by the core.
1B Internally Avalid received from the PHY is overridden
with GOTGCTL.AvalidOvVal.
AvalidOv 5 rw A-Peripheral Session Valid Override Value
Val This bit is used to set the override value for Avalid signal
when GOTGCTL.AvalidOvEn is set.
0B Avalid value is 0B when GOTGCTL.AvalidOvEn = 1
1B Avalid value is 1B when GOTGCTL.AvalidOvEn = 1
BvalidOv 6 rw B-Peripheral Session Valid Override Enable
En This bit is used to enable/disable the software to override
the Bvalid signal using the GOTGCTL.BvalidOvVal.
0B Override is disabled and Bvalid signal from the PHY
is used internally by the core.
1B Internally Bvalid received from the PHY is overridden
with GOTGCTL.BvalidOvVal.

XMC4500
XMC4000 Family

BvalidOv 7 rw B-Peripheral Session Valid Override Value
Val This bit is used to set the override value for Bvalid signal
when GOTGCTL.BvalidOvEn is set.
0B Bvalid value is 0B when GOTGCTL.BvalidOvEn = 1
1B Bvalid value is 1B when GOTGCTL.BvalidOvEn = 1
HstNegSc 8 rh Host Negotiation Success
s The core sets this bit when host negotiation is successful.
The core clears this bit when the HNP Request (HNPReq)
bit in this register is set.
0B Host negotiation failure
1B Host negotiation success
HNPReq 9 rw HNP Request
The application sets this bit to initiate an HNP request to the
connected USB host. The application can clear this bit by
writing a 0 when the Host Negotiation Success Status
Change bit in the OTG Interrupt register
(GOTGINT.HstNegSucStsChng) is set. The core clears
this bit when the HstNegSucStsChng bit is cleared.
0B No HNP request
1B HNP request
HstSetHN 10 rw Host Set HNP Enable
PEn The application sets this bit when it has successfully
enabled HNP (using the SetFeature.SetHNPEnable
command) on the connected device.
0B Host Set HNP is not enabled
1B Host Set HNP is enabled
DevHNPE 11 rw Device HNP Enabled
n The application sets this bit when it successfully receives a
SetFeature.SetHNPEnable command from the connected
USB host.
0B HNP is not enabled in the application
1B HNP is enabled in the application

XMC4500
XMC4000 Family

ConlDSts 16 rh Connector ID Status
Indicates the connector ID status on a connect event.
0B The USB core is in A-Device mode
1B The USB core is in B-Device mode
DbncTime 17 rh Long/Short Debounce Time
Indicates the debounce time of a detected connection.
0B Long debounce time, used for physical connections
(100 ms + 2.5 s)
1B Short debounce time, used for soft connections (2.5
s)
ASesVId 18 rh A-Session Valid
Indicates the Host mode transceiver status.
0B A-session is not valid
1B A-session is valid
Note: If the OTG features (such as SRP and HNP) are not
enabled, the read reset value will be 1.
BSesVld 19 rh B-Session Valid
Indicates the Device mode transceiver status.
0B B-session is not valid.
1B B-session is valid.
In OTG mode, this bit can be used to determine if the
device is connected or disconnected.
Note: If the OTG features (such as SRP and HNP) are not
enabled, the read reset value will be 1.

XMC4500
XMC4000 Family

OTGVer 20 rw OTG Version
Indicates the OTG revision.
0B OTG Version 1.3. In this version the core supports
Data line pulsing and VBus pulsing for SRP.
1B OTG Version 2.0. In this version the core supports
only Data line pulsing for SRP.
Note: XMC4500 supports only OTG Version 1.3.
Therefore, the OTGVer bit should always be written
with 0.
0 [15:1 r Reserved
2], Read as 0; should be written with 0.
[31:2
1]

XMC4500
XMC4000 Family
Interrupt Register (GOTGINT)

The application reads this register whenever there is an OTG interrupt and clears the bits
in this register to clear the OTG interrupt.
Note: All bits in this register are set only by hardware and cleared only by a software
write of 1 to the bit.
GOTGINT
OTG Interrupt Register (004H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ADe
Dbn HstN
vTO
0 ceDo egDe 0
UTC
ne t
hg
r rwh rwh rwh r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
HstN Ses
egSu Req SesE
0 cSts Suc 0 ndD 0
Chn StsC et
g hng
r rwh rwh r rwh r

SesEndD 2 rwh Session End Detected
et The core sets this bit when the bvalid signal is deasserted.
SesReqS 8 rwh Session Request Success Status Change
ucStsChn The core sets this bit on the success or failure of a session
g request. The application must read the Session Request
Success bit in the OTG Control and Status register
(GOTGCTL.SesReqScs) to check for success or failure.
HstNegSu 9 rwh Host Negotiation Success Status Change
cStsChng The core sets this bit on the success or failure of a USB
host negotiation request. The application must read the
Host Negotiation Success bit of the OTG Control and
Status register (GOTGCTL.HstNegScs) to check for
success or failure.

XMC4500
XMC4000 Family

HstNegDe 17 rwh Host Negotiation Detected
t The core sets this bit when it detects a host negotiation
request on the USB.
ADevTOU 18 rwh A-Device Timeout Change
TChg The core sets this bit to indicate that the A-device has timed
out while waiting for the B-device to connect.
DbnceDo 19 rwh Debounce Done
ne The core sets this bit when the debounce is completed after
the device connect. The application can start driving USB
reset after seeing this interrupt. This bit is only valid when
the HNP Capable or SRP Capable bit is set in the Core
USB Configuration register (GUSBCFG.HNPCap or
GUSBCFG.SRPCap, respectively).
0 [31:2 r Reserved
[16:1
0],
[7:3],
[1:0]

XMC4500
XMC4000 Family
AHB Configuration Register (GAHBCFG)

This register can be used to configure the core after power-on or a change in mode. This
register mainly contains AHB system-related configuration parameters. Do not change
this register after the initial programming. The application must program this register
before starting any transactions on either the AHB or the USB.
GAHBCFG
AHB Configuration Register (008H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
NPT
PTxF GlblI
xFE DMA
0 Emp 0 HBstLen ntrM
mpL En
Lvl sk
vl
r rw rw r rw rw rw

GlblIntrM 0 rw Global Interrupt Mask
sk The application uses this bit to mask or unmask the
interrupt line assertion to itself. Irrespective of this bit's
setting, the interrupt status registers are updated by the
core.
0B Mask the interrupt assertion to the application.
1B Unmask the interrupt assertion to the application.
HBstLen [4:1] rw Burst Length/Type
This field is used in DMA mode to indicate the AHB Master
burst type.
0000B Single
0001B INCR
0011B INCR4
0101B INCR8
0111B INCR16
Others: Reserved
DMAEn 5 rw DMA Enable
0B Core operates in Slave mode
1B Core operates in a DMA mode

XMC4500
XMC4000 Family

NPTxFEm 7 rw Non-Periodic TxFIFO Empty Level
pLvl This bit indicates when IN endpoint Transmit FIFO empty
interrupt (DIEPINTx.TxFEmp) is triggered.
0B DIEPINTx.TxFEmp interrupt indicates that the IN
Endpoint TxFIFO is half empty
1B DIEPINTx.TxFEmp interrupt indicates that the IN
Endpoint TxFIFO is completely empty
This bit is used only in Device Slave mode.
PTxFEmp 8 rw Periodic TxFIFO Empty Level
Lvl Indicates when the Periodic TxFIFO Empty Interrupt bit in
the Core Interrupt register (GINTSTS.PTxFEmp) is
triggered.
0B GINTSTS.PTxFEmp interrupt indicates that the
Periodic TxFIFO is half empty
1B GINTSTS.PTxFEmp interrupt indicates that the
Periodic TxFIFO is completely empty
This bit is used only in Host Slave mode.
0 [31:9] r Reserved
,6 Read as 0; should be written with 0.

XMC4500
XMC4000 Family
USB Configuration Register (GUSBCFG)

This register can be used to configure the core after power-on or a changing to Host
mode or Device mode. It contains USB and USB-PHY related configuration parameters.
The application must program this register before starting any transactions on either the
AHB or the USB. Do not make changes to this register after the initial programming.
GUSBCFG
USB Configuration Register (00CH) Reset Value: 0000 1440H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Forc Forc
TxEn OtgI
eDev eHst
CTP dDel 0 2CS
Mod Mod
ay el
e e
rw rw rw rw r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
HNP SRP PHY
0 USBTrdTim 0 0 TOutCal
Cap Cap Sel
r rw rw rw r r r rw

TOutCal [2:0] rw FS Timeout Calibration
The number of PHY clocks that the application programs in
this field is added to the full-speed interpacket timeout
duration in the core to account for any additional delays
introduced by the PHY. This can be required, because the
delay introduced by the PHY in generating the line state
condition can vary from one PHY to another.
The USB standard timeout value for full-speed operation is
16 to 18 (inclusive) bit times. The application must program
this field based on the speed of enumeration. The number
of bit times added per PHY clock is 0.25 bit times
PHYSel 6 r USB 1.1 Full-Speed Serial Transceiver Select
This bit is always read as 1 to indicate a full-speed
transceiver is selected.
0B Reserved
1B USB 1.1 full-speed serial transceiver

XMC4500
XMC4000 Family

SRPCap 8 rw SRP-Capable
The application uses this bit to control the USB core SRP
capabilities. If the core operates as a non-SRP-capable B-
device, it cannot request the connected A-device (host) to
activate VBUS and start a session.
0B SRP capability is not enabled.
1B SRP capability is enabled.
HNPCap 9 rw HNP-Capable
The application uses this bit to control the USB core's HNP
capabilities.
0B HNP capability is not enabled.
1B HNP capability is enabled.
USBTrdTi [13:1 rw USB Turnaround Time
m 0] Sets the turnaround time in PHY clocks.
Specifies the response time for a MAC request to the
Packet FIFO Controller (PFC) to fetch data from the DFIFO
(SPRAM).
Note: USB turnaround time is critical for certification where
long cables and 5-Hubs are used. See "Choosing the
Value of GUSBCFG.USBTrdTim" on page 446.
This bit is used in Device Only.
OtgI2CSel 16 rw UTMIFS Interface Select
The application uses this bit to select the USB 1.1 Full-
Speed interface.
0B UTMI USB 1.1 Full-Speed interface for OTG signals
1B Reserved
This bit should always be written with 0.
TxEndDel 28 rw Tx End Delay
ay Writing a 1 to this bit enables the TxEndDelay timers in the
core as per the section 4.1.5 on Opmode of the USB 2.0
Transceiver Macrocell Interface (UTMI) version 1.05.
0B Normal mode
1B Introduce Tx end delay timers
This bit is used in Device Only.

XMC4500
XMC4000 Family

ForceHst 29 rw Force Host Mode
Mode Writing a 1 to this bit forces the core to host mode
irrespective of connected plug.
0B Normal Mode
1B Force Host Mode
After setting the force bit, the application must wait at least
25 ms before the change to take effect.
ForceDev 30 rw Force Device Mode
Mode Writing a 1 to this bit forces the core to device mode
irrespective of connected plug.
0B Normal Mode
1B Force Device Mode
After setting the force bit, the application must wait at least
25 ms before the change to take effect.
CTP 31 rw Corrupt Tx packet
This bit is for debug purposes only. Never set this bit to 1.
0 [27:1 r Reserved
[15:1
4], 7,
[5:3]

XMC4500
XMC4000 Family
Reset Register (GRSTCTL)

The application uses this register to reset various hardware features inside the core.
GRSTCTL
Reset Register (010H) Reset Value: 1000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
AHBI DMA
0
dle Req
r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Frm
TxFF RxF CSft
0 TxFNum 0 Cntr 0
lsh Flsh Rst
Rst
r rw rwh rwh r rwh r rwh

XMC4500
XMC4000 Family

CSftRst 0 rwh Core Soft Reset
Resets the hclk and phy_clock domains as follows:
Clears the interrupts and all the CSR registers except
the following register bits:
PCGCCTL.GateHclk
GUSBCFG.PHYSel
HCFG.FSLSPclkSel
DCFG.DevSpd
GGPIO
All module state machines (except the AHB Slave Unit)
are reset to the IDLE state, and all the transmit FIFOs
and the receive FIFO are flushed.
Any transactions on the AHB Master are terminated as
soon as possible, after gracefully completing the last
data phase of an AHB transfer. Any transactions on the
USB are terminated immediately.
The application can write to this bit any time it wants to
reset the core. This is a self-clearing bit and the core clears
this bit after all the necessary logic is reset in the core,
which can take several clocks, depending on the current
state of the core. Once this bit is cleared software must wait
at least 3 PHY clocks before doing any access to the PHY
domain (synchronization delay). Software must also must
check that bit 31 of this register is 1 (AHB Master is IDLE)
before starting any operation.
Typically software reset is used during software
development.
FrmCntrR 2 rwh Host Frame Counter Reset
st The application writes this bit to reset the frame number
counter inside the core. When the frame counter is reset,
the subsequent SOF sent out by the core has a frame
number of 0.
This bit is set only by software and cleared only by
hardware.

XMC4500
XMC4000 Family

RxFFlsh 4 rwh RxFIFO Flush
The application can flush the entire RxFIFO using this bit,
but must first ensure that the core is not in the middle of a
transaction.
The application must only write to this bit after checking that
the core is neither reading from the RxFIFO nor writing to
the RxFIFO.
The application must wait until the bit is cleared before
performing any other operations. This bit requires 8 clocks
(slowest of PHY or AHB clock) to clear.
hardware.
TxFFlsh 5 rwh TxFIFO Flush
This bit selectively flushes a single or all transmit FIFOs,
but cannot do so if the core is in the midst of a transaction.
The application must write this bit only after checking that
the core is neither writing to the TxFIFO nor reading from
the TxFIFO. Verify using these registers:
ReadNAK Effective Interrupt ensures the core is not
reading from the FIFO
WriteGRSTCTL.AHBIdle ensures the core is not
writing anything to the FIFO.
Flushing is normally recommended when FIFOs are re-
configured. FIFO flushing is also recommended during
device endpoint disable.
The application must wait until the core clears this bit before
performing any operations. This bit requires 8 clocks
(slowest of PHY or AHB clock) to clear.
hardware.

XMC4500
XMC4000 Family

TxFNum [10:6] rw TxFIFO Number
This is the FIFO number that must be flushed using the
TxFIFO Flush bit. This field must not be changed until the
core clears the TxFIFO Flush bit.
00H Non-periodic TxFIFO flush in Host mode or Tx FIFO
0 flush in device mode
01H Periodic TxFIFO flush in Host mode or Tx FIFO 1
flush in device mode
02H Tx FIFO 2 flush in device mode
...H ...
0FH Tx FIFO 15 flush in device mode
10H Flush all the transmit FIFOs in device or host mode.
DMAReq 30 r DMA Request Signal
Indicates that the DMA request is in progress. Used for
debug.
AHBIdle 31 r AHB Master Idle
Indicates that the AHB Master State Machine is in the IDLE
condition.
0 [29:1 r Reserved
1], 3, Read as 0; should be written with 0.
1

XMC4500
XMC4000 Family
Interrupt Register (GINTSTS)

This register interrupts the application for system-level events in the current mode
(Device mode or Host mode). It is shown in Figure 16-67.
Some of the bits in this register are valid only in Host mode, while others are valid in
Device mode only. This register also indicates the current mode.
Note: In the GINTSTS register, interrupt status bits with access type rwh are set by
hardware. To clear these bits, the application must write 1 into these bits.
The FIFO status interrupts are read only; once software reads from or writes to the FIFO
while servicing these interrupts, FIFO interrupt conditions are cleared automatically.
The application must clear the GINTSTS register at initialization before unmasking the
interrupt bit to avoid any interrupts generated prior to initialization.
GINTSTS
Interrupt Register [HOSTMODE] (014H) Reset Value: 1400 0020H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ConI
Sess Disc
WkU DSts PTxF HChI PrtIn inco
ReqI onnI 0 0 0
pInt Chn Emp nt t mplP
nt nt
g
rwh rwh rwh rwh r rh rh rh r rwh r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RxF OTGI Mod Cur
0 1 Sof
Lvl nt eMis Mod
r r rh rwh rh rwh rh

XMC4500
XMC4000 Family

CurMod 0 rh Current Mode of Operation
Indicates the current mode.
0B Device mode
1B Host mode
ModeMis 1 rwh Mode Mismatch Interrupt
The core sets this bit when the application is trying to
access:
A Host mode register, when the core is operating in
Device mode
A Device mode register, when the core is operating in
Host mode
The register access is completed on the AHB with an OKAY
response, but is ignored by the core internally and does not
affect the operation of the core.
OTGInt 2 rh OTG Interrupt
The core sets this bit to indicate an OTG protocol event.
The application must read the OTG Interrupt Status
(GOTGINT) register to determine the exact event that
caused this interrupt. The application must clear the
appropriate status bit in the GOTGINT register to clear this
bit.
Sof 3 rwh Start of Frame
In Host mode, the core sets this bit to indicate that an SOF
is transmitted on the USB.
RxFLvl 4 rh RxFIFO Non-Empty
Indicates that there is at least one packet pending to be
read from the RxFIFO.
incomplP 21 rwh Incomplete Periodic Transfer
In Host mode, the core sets this interrupt bit when there
are incomplete periodic transactions still pending which are
scheduled for the current frame.
PrtInt 24 rh Host Port Interrupt
The core sets this bit to indicate a change in port status of
one of the USB core ports in Host mode. The application
must read the Host Port Control and Status (HPRT) register
to determine the exact event that caused this interrupt. The
application must clear the appropriate status bit in the Host
Port Control and Status register to clear this bit.

XMC4500
XMC4000 Family

HChInt 25 rh Host Channels Interrupt
The core sets this bit to indicate that an interrupt is pending
on one of the channels of the core (in Host mode). The
application must read the Host All Channels Interrupt
(HAINT) register to determine the exact number of the
channel on which the interrupt occurred, and then read the
corresponding Host Channel-n Interrupt (HCINTx) register
to determine the exact cause of the interrupt. The
application must clear the appropriate status bit in the
HCINTx register to clear this bit.
PTxFEmp 26 rh Periodic TxFIFO Empty
This interrupt is asserted when the Periodic Transmit FIFO
is either half or completely empty and there is space for at
least one entry to be written in the Periodic Request Queue.
The half or completely empty status is determined by the
Periodic TxFIFO Empty Level bit in the Core AHB
Configuration register (GAHBCFG.PTxFEmpLvl).
ConIDSts 28 rwh Connector ID Status Change
Chng This interrupt is asserted when there is a change in
connector ID status.
DisconnIn 29 rwh Disconnect Detected Interrupt
t This interrupt is asserted when a device disconnect is
detected.
SessReqI 30 rwh Session Request/New Session Detected Interrupt
nt In Host mode, this interrupt is asserted when a session
request is detected from the device.
In Device mode, this interrupt is asserrted when the Bvalid
signal goes high.
WkUpInt 31 rwh Resume/Remote Wakeup Detected Interrupt
Wakeup Interrupt during Suspend state.
Device Mode - This interrupt is asserted only when Host
Initiated Resume is detected on USB.
Host Mode - This interrupt is asserted only when Device
Initiated Remote Wakeup is detected on USB.

XMC4500
XMC4000 Family

1 5 r Reserved
0 27, r Reserved
[23:2 Read as 0; should be written with 0.
2],
[20:6]
GINTSTS
Interrupt Register [DEVICEMODE] (014H) Reset Value: 1400 0020H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ConI inco
Sess inco
WkU DSts mplS OEPI IEPI
ReqI 0 0 1 0 mpIS 0
pInt Chn OOU nt nt
nt OIN
g T
rwh rwh r rwh r r r rwh rwh r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ISO Enu GOU GIN
EOP USB USB Erly RxF OTGI Mod Cur
OutD mDo 0 TNak Nak 1 Sof
F Rst Susp Susp Lvl nt eMis Mod
rop ne Eff Eff
rwh rwh rwh rwh rwh rwh r rh rh r rh rwh rh rwh rh

CurMod 0 rh Current Mode of Operation
Indicates the current mode.
0B Device mode
1B Host mode
ModeMis 1 rwh Mode Mismatch Interrupt
The core sets this bit when the application is trying to
access:
A Host mode register, when the core is operating in
Device mode
A Device mode register, when the core is operating in
Host mode
The register access is completed on the AHB with an OKAY
response, but is ignored by the core internally and does not
affect the operation of the core.

XMC4500
XMC4000 Family

OTGInt 2 rh OTG Interrupt
The core sets this bit to indicate an OTG protocol event.
The application must read the OTG Interrupt Status
(GOTGINT) register to determine the exact event that
caused this interrupt. The application must clear the
appropriate status bit in the GOTGINT register to clear this
bit.
Sof 3 rwh Start of Frame
In Device mode, the core sets this bit to indicate that an
SOF token has been received on the USB. The application
can read the Device Status register to get the current frame
number.
RxFLvl 4 rh RxFIFO Non-Empty
Indicates that there is at least one packet pending to be
read from the RxFIFO.
GINNakEf 6 rh Global IN Non-Periodic NAK Effective
f Indicates that the Set Global Non-periodic IN NAK bit in the
Device Control register (DCTL.SGNPInNak), set by the
application, has taken effect in the core. That is, the core
has sampled the Global IN NAK bit set by the application.
This bit can be cleared by clearing the Clear Global Non-
periodic IN NAK bit in the Device Control register
(DCTL.CGNPInNak).
This interrupt does not necessarily mean that a NAK
handshake is sent out on the USB. The STALL bit takes
precedence over the NAK bit.
GOUTNak 7 rh Global OUT NAK Effective
Eff Indicates that the Set Global OUT NAK bit in the Device
Control register (DCTL.SGOUTNak), set by the application,
has taken effect in the core. This bit can be cleared by
writing the Clear Global OUT NAK bit in the Device Control
register (DCTL.CGOUTNak).
ErlySusp 10 rwh Early Suspend
The core sets this bit to indicate that an Idle state has been
detected on the USB for 3 ms.

XMC4500
XMC4000 Family

USBSusp 11 rwh USB Suspend
The core sets this bit to indicate that a suspend was
detected on the USB. The core enters the Suspended state
when there is no activity on the two USB data signals for an
extended period of time.
USBRst 12 rwh USB Reset
The core sets this bit to indicate that a reset is detected on
the USB.
EnumDon 13 rwh Enumeration Done
e The core sets this bit to indicate that speed enumeration is
complete. The application must read the Device Status
(DSTS) register to obtain the enumerated speed.
ISOOutDr 14 rwh Isochronous OUT Packet Dropped Interrupt
op The core sets this bit when it fails to write an isochronous
OUT packet into the RxFIFO because the RxFIFO does not
have enough space to accommodate a maximum packet
size packet for the isochronous OUT endpoint.
EOPF 15 rwh End of Periodic Frame Interrupt
Indicates that the period specified in the Periodic Frame
Interval field of the Device Configuration register
(DCFG.PerFrInt) has been reached in the current frame.
IEPInt 18 r IN Endpoints Interrupt
on one of the IN endpoints of the core (in Device mode).
The application must read the Device All Endpoints
Interrupt (DAINT) register to determine the exact number of
the IN endpoint on which the interrupt occurred, and then
read the corresponding Device IN Endpoint-n Interrupt
(DIEPINTx) register to determine the exact cause of the
interrupt. The application must clear the appropriate status
bit in the corresponding DIEPINTx register to clear this bit.

XMC4500
XMC4000 Family

OEPInt 19 r OUT Endpoints Interrupt
on one of the OUT endpoints of the core (in Device mode).
The application must read the Device All Endpoints
Interrupt (DAINT) register to determine the exact number of
the OUT endpoint on which the interrupt occurred, and then
read the corresponding Device OUT Endpoint-n Interrupt
(DOEPINTx) register to determine the exact cause of the
interrupt. The application must clear the appropriate status
bit in the corresponding DOEPINTx register to clear this bit.
incompIS 20 rwh Incomplete Isochronous IN Transfer
OIN The core sets this interrupt to indicate that there is at least
one isochronous IN endpoint on which the transfer is not
completed in the current frame. This interrupt is asserted
along with the End of Periodic Frame Interrupt (EOPF) bit
in this register.
Note: This interrupt is not asserted in Scatter/Gather DMA
mode.
incomplS 21 rwh Incomplete Isochronous OUT Transfer
OOUT In the Device mode, the core sets this interrupt to indicate
that there is at least one isochronous OUT endpoint on
which the transfer is not completed in the current frame.
This interrupt is asserted along with the End of Periodic
Frame Interrupt (EOPF) bit in this register.
ConIDSts 28 rwh Connector ID Status Change
Chng This interrupt is asserted when there is a change in
connector ID status.
SessReqI 30 rwh Session Request/New Session Detected Interrupt
nt In Host mode, this interrupt is asserted when a session
request is detected from the device.
In Device mode, this interrupt is asserrted when the Bvalid
signal goes high.
WkUpInt 31 rwh Resume/Remote Wakeup Detected Interrupt
Wakeup Interrupt during Suspend state.
Device Mode - This interrupt is asserted only when Host
Initiated Resume is detected on USB.
Host Mode - This interrupt is asserted only when Device
Initiated Remote Wakeup is detected on USB.

XMC4500
XMC4000 Family

1 26, 5 r Reserved
0 29, r Reserved
[25:2
2],
[17:1
6],
[9:8]

XMC4500
XMC4000 Family
Interrupt Mask Register (GINTMSK)

This register works with the Interrupt Register (Interrupt Register (GINTSTS) on
Page 16-235) to interrupt the application. When an interrupt bit is masked, the interrupt
associated with that bit is not generated. However, the GINTSTS register bit
corresponding to that interrupt is still set.
Mask interrupt: 0B
Unmask interrupt: 1B
GINTMSK
Interrupt Mask Register [HOSTMODE](018H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ConI
Sess Disc
WkU DSts PTxF HChI inco
ReqI onnI PrtIn
pInt Chn 0 Emp ntMs 0 mplP 0
ntMs ntMs tMsk
Msk gMs Msk k Msk
k k
k
rw rw rw rw r rw rw rw r rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RxF OTGI Mod
SofM
0 LvlM ntMs eMis 0
sk
sk k Msk
r rw rw rw rw r

ModeMisMs 1 rw Mode Mismatch Interrupt Mask
k
OTGIntMsk 2 rw OTG Interrupt Mask
SofMsk 3 rw Start of Frame Mask
RxFLvlMsk 4 rw Receive FIFO Non-Empty Mask
incomplPM 21 rw Incomplete Periodic Transfer Mask
sk
PrtIntMsk 24 rw Host Port Interrupt Mask
HChIntMsk 25 rw Host Channels Interrupt Mask
PTxFEmpM 26 rw Periodic TxFIFO Empty Mask
sk
ConIDStsC 28 rw Connector ID Status Change Mask
hngMsk

XMC4500
XMC4000 Family

DisconnInt 29 rw Disconnect Detected Interrupt Mask
Msk
SessReqInt 30 rw Session Request/New Session Detected Interrupt
Msk Mask
WkUpIntMs 31 rw Resume/Remote Wakeup Detected Interrupt Mask
k
0 27, r Reserved
[23: Read as 0; should be written with 0.
22],
[20:
5], 0
GINTMSK
Interrupt Mask Register [DEVICEMODE] (018H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ConI inco
Sess Disc inco
WkU DSts mplS OEPI IEPI
ReqI onnI mpIS
pInt Chn 0 OOU ntMs ntMs 0
ntMs ntMs OIN
Msk gMs TMs k k
k k Msk
k k
rw rw rw rw r rw rw rw rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ISO Enu GOU GIN
EOP USB USB Erly RxF OTGI Mod
OutD mDo TNak Nak SofM
FMs RstM Susp Susp 0 0 LvlM ntMs eMis 0
ropM neM EffM EffM sk
k sk Msk Msk sk k Msk
sk sk sk sk
rw rw rw rw rw rw r rw rw r rw rw rw rw r

ModeMisMs 1 rw Mode Mismatch Interrupt Mask
k
OTGIntMsk 2 rw OTG Interrupt Mask
SofMsk 3 rw Start of Frame Mask
RxFLvlMsk 4 rw Receive FIFO Non-Empty Mask
GINNakEffM 6 rw Global Non-periodic IN NAK Effective Mask
sk

XMC4500
XMC4000 Family

GOUTNakEf 7 rw Global OUT NAK Effective Mask
fMsk
ErlySuspMs 10 rw Early Suspend Mask
k
USBSuspM 11 rw USB Suspend Mask
sk
USBRstMsk 12 rw USB Reset Mask
EnumDone 13 rw Enumeration Done Mask
Msk
ISOOutDrop 14 rw Isochronous OUT Packet Dropped Interrupt Mask
Msk
EOPFMsk 15 rw End of Periodic Frame Interrupt Mask
Mode: Device only
Reset: 0B
IEPIntMsk 18 rw IN Endpoints Interrupt Mask
OEPIntMsk 19 rw OUT Endpoints Interrupt Mask
incompISOI 20 rw Incomplete Isochronous IN Transfer Mask
NMsk
incomplSO 21 rw Incomplete Isochronous OUT Transfer Mask
OUTMsk
ConIDStsC 28 rw Connector ID Status Change Mask
hngMsk
DisconnInt 29 rw Disconnect Detected Interrupt Mask
Msk
SessReqInt 30 rw Session Request/New Session Detected Interrupt
Msk Mask
WkUpIntMs 31 rw Resume/Remote Wakeup Detected Interrupt Mask
k
0 [27: r Reserved
[17:
16],
[9:8]
, 5, 0

XMC4500
XMC4000 Family
Receive Status Debug Read/Status Read and Pop Registers

(GRXSTSR/GRXSTSP)
A read to the Receive Status Debug Read register returns the contents of the top of the
Receive FIFO. A read to the Receive Status Read and Pop register additionally pops the
top data entry out of the RxFIFO.
The receive status contents must be interpreted differently in Host and Device modes.
The core ignores the receive status pop/read when the receive FIFO is empty and
returns a value of 00000000H. The application must only pop the Receive Status FIFO
when the Receive FIFO Non-Empty bit of the Core Interrupt register (GINTSTS.RxFLvl)
is asserted.
Notes
1. Use of these fields vary based on whether the OTG core is functioning as a host or
a device.
2. Do not read this register's reset value before configuring the core because the read
value is "X".

XMC4500
XMC4000 Family
Receive Status Debug Read/Status Read and Pop Registers in Host Mode
GRXSTSR
Receive Status Debug Read Register [HOSTMODE]
GRXSTSP
Receive Status Read and Pop Register [HOSTMODE]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 PktSts DPID
r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DPID BCnt ChNum
r r r

ChNum [3:0] r Channel Number
Indicates the channel number to which the current
received packet belongs.
BCnt [14:4] r Byte Count
Indicates the byte count of the received IN data packet.
DPID [16:15] r Data PID
Indicates the Data PID of the received packet
00B DATA0
10B DATA1
01B DATA2
11B MDATA
PktSts [20:17] r Packet Status
Indicates the status of the received packet
0010B IN data packet received
0011B IN transfer completed (triggers an interrupt)
0101B Data toggle error (triggers an interrupt)
0111B Channel halted (triggers an interrupt)
Others: Reserved

XMC4500
XMC4000 Family
Receive Status Debug Read/Status Read and Pop Registers in Device Mode
(GRXSTSR/GRXSTSP)
GRXSTSR
Receive Status Debug Read Register [DEVICEMODE]
GRXSTSP
Receive Status Read and Pop Register [DEVICEMODE]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 FN PktSts DPID
r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DPID BCnt EPNum
r r r

EPNum [3:0] r Endpoint Number
Indicates the endpoint number to which the current
received packet belongs.
BCnt [14:4] r Byte Count
Indicates the byte count of the received data packet.
DPID [16:15] r Data PID
Indicates the Data PID of the received OUT data packet
00B DATA0
10B DATA1
01B DATA2
11B MDATA
PktSts [20:17] r Packet Status
Indicates the status of the received packet
0001B Global OUT NAK (triggers an interrupt)
0010B OUT data packet received
0011B OUT transfer completed (triggers an interrupt)
0100B SETUP transaction completed (triggers an
interrupt)
0110B SETUP data packet received
Others: Reserved

XMC4500
XMC4000 Family

FN [24:21] r Frame Number
This is the least significant 4 bits of the frame number in
which the packet is received on the USB. This field is
supported only when isochronous OUT endpoints are
supported.

XMC4500
XMC4000 Family
Receive FIFO Size Register (GRXFSIZ)

The application can program the RAM size that must be allocated to the RxFIFO.
GRXFSIZ
Receive FIFO Size Register (024H) Reset Value: 0000 011AH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 RxFDep
r rw

RxFDep [15:0] rw RxFIFO Depth
This value is in terms of 32-bit words.
Minimum value is 16
Maximum value is 282
Programmed values must not exceed the maximum value.
0 [31:1 r Reserved
6] Read as 0; should be written with 0.

XMC4500
XMC4000 Family
Non-Periodic Transmit FIFO Size Register (GNPTXFSIZ)

The application can program the RAM size and the memory start address for the Non-
periodic TxFIFO.
Note: The fields of this register change, depending on host or device mode.
GNPTXFSIZ
Non-Periodic Transmit FIFO Size Register [HOSTMODE]
(028H) Reset Value: 0010 011AH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
NPTxFDep NPTxFStAddr
rw rw

NPTxF [15:0] rw Non-periodic Transmit RAM Start Address
StAddr This field contains the memory start address for Non-periodic
Transmit FIFO RAM.
Programmed values must not exceed the power-on value.
NPTxF [31:1 rw Non-periodic TxFIFO Depth
Dep 6] This value is in terms of 32-bit words.
Minimum value is 16
Maximum value is 16
GNPTXFSIZ
Non-Periodic Transmit FIFO Size Register [DEVICEMODE]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
INEPTxF0Dep 0
rw r

XMC4500
XMC4000 Family

INEPTxF0 [31:1 rw IN Endpoint TxFIFO 0 Depth
Minimum value is 16
Maximum value is 16
0 [15:0] r Reserved

XMC4500
XMC4000 Family
Non-Periodic Transmit FIFO/Queue Status Register (GNPTXSTS)

This register is valid only in Host.
This read-only register contains the free space information for the Non-periodic TxFIFO
and the Non- periodic Transmit Request Queue.
GNPTXSTS
Non-Periodic Transmit FIFO/Queue Status Register(02CH) Reset Value:
0008 0010H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 NPTxQTop NPTxQSpcAvail NPTxFSpcAvail
r rh rh rh

NPTxFSp [15:0] rh Non-periodic TxFIFO Space Avail
cAvail Indicates the amount of free space available in the Non-
periodic TxFIFO.
Values are in terms of 32-bit words.
0H Non-periodic TxFIFO is full
1H 1 word available
2H 2 words available
Others: Up to n words can be selected (0 < n < 16);
selections greater than n are reserved
NPTxQSp [23:1 rh Non-periodic Transmit Request Queue Space Available
cAvail 6] Indicates the amount of free space available in the Non-
periodic Transmit RequestQueue. This queue holds both
IN and OUT requests in Host mode.
0H Non-periodic Transmit Request Queue is full
1H 1 location available
2H 2 locations available
Others: Up to n locations can be selected (0 < n < 8);

XMC4500
XMC4000 Family

NPTxQTo [30:2 rh Top of the Non-periodic Transmit Request Queue
p 4] Entry in the Non-periodic Tx Request Queue that is
currently being processed by the
MAC.
Bits [30:27]: Channel/endpoint number
Bits [26:25]:
00B IN/OUT token
01B Zero-length transmit packet (device IN/host OUT)
10B Reserved
11B Channel halt command
Bit [24]: Terminate (last entry for selected
channel/endpoint)
0 31 r Reserved

XMC4500
XMC4000 Family
USB Module Identification Register (GUID)

This register contains the USB module version and revision and should not be
overwritten by application.
GUID
USB Module Identification Register (03CH) Reset Value: 00AE C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
rw rw rw

MOD_REV [7:0] rw Module Revision
MOD_TYPE [15:8] rw Module Type
MOD_NUMBER [31:1 rw Module Number
6] Indicates the module identification number.

XMC4500
XMC4000 Family
Global DFIFO Software Config Register (GDFIFOCFG)
GDFIFOCFG
Global DFIFO Software Config Register(05CH) Reset Value: 027A 02B2H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EPInfoBaseAddr GDFIFOCfg
rw rw

GDFIFOCf [15:0] rw GDFIFOCfg
g This field is for dynamic programming of the DFIFO Size.
This value takes effect only when the application programs
a non zero value to this register. The value programmed
must conform to the guidelines described in Data FIFO
RAM Allocation on Page 16-201. The USB core does
not have any corrective logic if the FIFO sizes are
programmed incorrectly.
EPInfoBas [31:1 rw EPInfoBaseAddr
eAddr 6] This field provides the start address of the RAM space
allocated to store register information in DMA mode. See
Data FIFO RAM Allocation on Page 16-201.

XMC4500
XMC4000 Family
Host Periodic Transmit FIFO Size Register (HPTXFSIZ)

This register holds the size and the memory start address of the Periodic TxFIFO.
HPTXFSIZ
Host Periodic Transmit FIFO Size Register(100H) Reset Value: 0100 012AH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PTxFSize PTxFStAddr
rw rw

PTxFStAd [15:0] rw Host Periodic TxFIFO Start Address
dr The power-on reset value of this register is the sum of the
Largest Rx Data FIFO Depth and Largest Non-periodic Tx
Data FIFO Depth.
Programmed values must not exceed the power-on value .
PTxFSize [31:1 rw Host Periodic TxFIFO Depth
6] This value is in terms of 32-bit words.
Minimum value is 16

XMC4500
XMC4000 Family
Device IN Endpoint Transmit FIFO Size Register (DIEPTXFn)

This register holds the size and memory start address of IN endpoint TxFIFOs
implemented in Device mode. Each FIFO holds the data for one IN endpoint. This
register is repeated for instantiated IN endpoint FIFOs 1 to 6. For IN endpoint FIFO 0 use
GNPTXFSIZ register for programming the size and memory start address.
DIEPTXFx (x=1-6)
Device IN Endpoint Transmit FIFO Size Register(100H + x*04H) Reset Value:
0100 011AH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
INEPnTxFDep INEPnTxFStAddr
rw rw

INEPnTxF [15:0] rw IN Endpoint FIFOn Transmit RAM Start Address
StAddr This field contains the memory start address for IN endpoint
Transmit FIFOn (1 < n 6).
Programmed values must not exceed the reset value.
INEPnTxF [31:1 rw IN Endpoint TxFIFO Depth
Minimum value is 16
Host Mode Registers

These registers affect the operation of the core in the Host mode. Host mode registers
must not be accessed in Device mode, as the results are undefined. Host Mode registers
can be categorized as follows:
Host Configuration Register (HCFG)

This register configures the core after power-on. Do not make changes to this register
after initializing the host.

XMC4500
XMC4000 Family
HCFG
Host Configuration Register (400H) Reset Value: 0000 0200H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PerS
Desc
0 ched FrListEn 0
DMA
Ena
r rw rw rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FSL
FSLSPclk
0 1 0 SSu
Sel
pp
r r r rw rw

FSLSPclk [1:0] rw FS PHY Clock Select
Sel 01B PHY clock is running at 48 MHz
Others: Reserved
FSLSSup 2 rw FS-Only Support
p The application uses this bit to control the core's
enumeration speed. Using this bit, the application can
make the core enumerate as a FS host, even if the
connected device supports HS traffic. Do not make
changes to this field after initial programming.
0B FS-only, connected device can supports also only
FS.
1B FS-only, even if the connected device can support
HS

XMC4500
XMC4000 Family

DescDMA 23 rw Enable Scatter/gather DMA in Host mode
The application can set this bit during initialization to enable
the Scatter/Gather DMA operation.
Note: This bit must be modified only once after a reset. The
following combinations are available for
programming:
GAHBCFG.DMAEn=0, HCFG.DescDMA=0 => Slave
mode
GAHBCFG.DMAEn=0, HCFG.DescDMA=1 => Invalid
GAHBCFG.DMAEn=1, HCFG.DescDMA=0 =>
Buffered DMA mode
GAHBCFG.DMAEn=1, HCFG.DescDMA=1 =>
Scatter/Gather DMA mode
In non Scatter/Gather DMA mode, this bit is reserved.
FrListEn [25:2 rw Frame List Entries
4] This field is valid only in Scatter/Gather DMA mode. The
value in the register specifies the number of entries in the
Frame list.
00B 8 Entries
01B 16 Entries
10B 32 Entries
11B 64 Entries
In modes other than Scatter/Gather DMA mode, these bits
are reserved.
PerSched 26 rw Enable Periodic Scheduling
Ena Applicable in Scatter/Gather DMA mode only. Enables
periodic scheduling within the core. Initially, the bit is reset.
The core will not process any periodic channels. As soon as
this bit is set, the core will get ready to start scheduling
periodic channels and sets HCFG.PerSchedStat. The
setting of HCFG.PerSchedStat indicates the core has
enabled periodic scheduling. Once HCFG.PerSchedEna is
set, the application is not supposed to again reset the bit
unless HCFG.PerSchedStat is set. As soon as this bit is
reset, the core will get ready to stop scheduling periodic
channels and resets HCFG.PerSchedStat.

XMC4500
XMC4000 Family

1 9 r Reserved
0 [31:2 r Reserved
[22:1
0],
[8:3]

XMC4500
XMC4000 Family
Host Frame Interval Register (HFIR)

This register stores the frame interval information for the current speed to which the USB
core has enumerated.
HFIR
Host Frame Interval Register (404H) Reset Value: 0000 EA60H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 FrInt
r rw

FrInt [15:0] rw Frame Interval
The value that the application programs to this field
specifies the interval between two consecutive SOFs. This
field contains the number of PHY clocks that constitute the
required frame interval. The default value set in this field for
a FS operation when the PHY clock frequency is 60 MHz.
The application can write a value to this register only after
the Port Enable bit of the Host Port Control and Status
register (HPRT.PrtEnaPort) has been set. If no value is
programmed, the core calculates the value based on the
PHY clock specified in the FS PHY Clock Select field of the
Host Configuration register (HCFG.FSLSPclkSel).
Do not change the value of this field after the initial
configuration.
1 ms * (PHY clock frequency for FS)
0 [31:1 r Reserved

XMC4500
XMC4000 Family
Host Frame Number/Frame Time Remaining Register (HFNUM)

This register indicates the current frame number. It also indicates the time remaining (in
terms of the number of PHY clocks) in the current frame.
HFNUM
Host Frame Number/Frame
Time Remaining Register (408H) Reset Value: 0000 3FFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FrRem FrNum
r rw

FrNum [15:0] rw Frame Number
This field increments when a new SOF is transmitted on the
USB, and is reset to 0H when it reaches 3FFFH.
FrRem [31:1 r Frame Time Remaining
6] Indicates the amount of time remaining in the current frame,
in terms of PHY clocks. This field decrements on each PHY
clock. When it reaches zero, this field is reloaded with the
value in the Frame Interval register and a new SOF is
transmitted on the USB.

XMC4500
XMC4000 Family
Host Periodic Transmit FIFO/Queue Status Register (HPTXSTS)

This read-only register contains the free space information for the Periodic TxFIFO and
the Periodic Transmit Request Queue.
HPTXSTS
Host Periodic Transmit FIFO/
Queue Status Register (410H) Reset Value: 0008 0100H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PTxQTop PTxQSpcAvail PTxFSpcAvail
r r rw

PTxFSpc [15:0] rw Periodic Transmit Data FIFO Space Available
Avail Indicates the number of free locations available to be
written to in the Periodic TxFIFO.
Values are in terms of 32-bit words
0B Periodic TxFIFO is full
1H 1 word available

XMC4500
XMC4000 Family

PTxQSpc [23:1 r Periodic Transmit Request Queue Space Available
Avail 6] Indicates the number of free locations available to be
written in the Periodic Transmit
Request Queue. This queue holds both IN and OUT
requests.
0H Periodic Transmit Request Queue is full
1H 1 location available
2H 2 locations available
Others: Up to n locations can be selected (0 < n < 8);
PTxQTop [31:2 r Top of the Periodic Transmit Request Queue
4] This indicates the entry in the Periodic Tx Request Queue
that is currently being processes by the MAC.
This register is used for debugging.
Bit [31]: Odd/Even frame
0B send in even frame
1B send in odd frame
Bits [30:27]: Channel/endpoint number
Bits [26:25]: Type
00B IN/OUT
01B Zero-length packet
10B Reserved
11B Disable channel command
Bit [24]: Terminate (last entry for the selected
channel/endpoint)

XMC4500
XMC4000 Family
Host All Channels Interrupt Register (HAINT)

When a significant event occurs on a channel, the Host All Channels Interrupt register
interrupts the application using the Host Channels Interrupt bit of the Core Interrupt
register (GINTSTS.HChInt). This is shown in Figure 16-67 Interrupt Hierarchy on
Page 16-209. There is one interrupt bit per channel, up to a maximum of 14 bits. Bits in
this register are set and cleared when the application sets and clears bits in the
corresponding Host Channel- n Interrupt register.
HAINT
Host All Channels Interrupt Register (414H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 HAINT
r rh

HAINT [13:0] rh Channel Interrupts
One bit per channel: Bit 0 for Channel 0, bit 13 for Channel
13
0 [31:1 r Reserved

XMC4500
XMC4000 Family
Host All Channels Interrupt Mask Register (HAINTMSK)

The Host All Channel Interrupt Mask register works with the Host All Channel Interrupt
register to interrupt the application when an event occurs on a channel. There is one
interrupt mask bit per channel, up to a maximum of 14 bits.
Mask interrupt: 0B
HAINTMSK
Host All Channels Interrupt Mask Register(418H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 HAINTMsk
r rw

HAINTMs [13:0] rw Channel Interrupt Mask
k One bit per channel: Bit 0 for channel 0, bit 13 for channel
13
0 [31:1 r Reserved

XMC4500
XMC4000 Family
Host Frame List Base Address Register (HFLBADDR)

This register holds the starting address of the Frame list information. It is present only in
case of Scatter/Gather DMA and used only for Isochronous and Interrupt Channels. The
register is implemented in RAM.
HFLBADDR
Host Frame List Base Address Register(41CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Starting_Address
rw

Starting_ [31:0] rw Starting Address
Address The starting address of the Frame list.

XMC4500
XMC4000 Family
Host Port Control and Status Register (HPRT)

This register is available only in Host mode. Currently, the OTG Host supports only one
port.
A single register holds USB port-related information such as USB reset, enable,
suspend, resume, connect status, and test mode for each port. It is shown in
Figure 16-67 Interrupt Hierarchy on Page 16-209. The bits PrtOvrCurrChng,
PrtEnChng and PrtConnDet in this register can trigger an interrupt to the application
through the Host Port Interrupt bit of the Core Interrupt register (GINTSTS.PrtInt). On a
Port Interrupt, the application must read this register and clear the bit that caused the
interrupt. For these bits, the application must write a 1 to the bit to clear the interrupt.
HPRT
Host Port Control and Status Register(440H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 PrtSpd 0
r rh r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PrtO
PrtO PrtE PrtC PrtC
PrtP PrtR PrtS PrtR vrCu PrtE
0 PrtLnSts 0 vrCu nCh onn onn
wr st usp es rrCh na
rrAct ng Det Sts
ng
r rwh rh r rw rwh rwh rwh r rwh rwh rwh rh

PrtConnS 0 rh Port Connect Status
ts 0B No device is attached to the port.
1B A device is attached to the port.
PrtConnD 1 rwh Port Connect Detected
et The core sets this bit when a device connection is detected
to trigger an interrupt to the application using the Host Port
Interrupt bit of the Core Interrupt register (GINTSTS.PrtInt).
This bit is set only by hardware and cleared only by a
software write of 1 to the bit.

XMC4500
XMC4000 Family

PrtEna 2 rwh Port Enable
A port is enabled only by the core after a reset sequence,
and is disabled by an overcurrent condition, a disconnect
condition, or by the application clearing this bit. The
application cannot set this bit by a register write. It can only
clear it to disable the port. This bit does not trigger any
interrupt to the application.
0B Port disabled
1B Port enabled
PrtEnChn 3 rwh Port Enable/Disable Change
g The core sets this bit when the status of the Port Enable bit
[2] of this register changes.
PrtOvrCur 4 r Port Overcurrent Active
rAct Indicates the overcurrent condition of the port.
0B No overcurrent condition
1B Overcurrent condition
PrtOvrCur 5 rwh Port Overcurrent Change
rChng The core sets this bit when the status of the Port
Overcurrent Active bit (bit 4) in this register changes.
PrtRes 6 rwh Port Resume
The application sets this bit to drive resume signaling on the
port. The core continues to drive the resume signal until the
application clears this bit.
If the core detects a USB remote wakeup sequence, as
indicated by the Port Resume/Remote Wakeup Detected
Interrupt bit of the Core Interrupt register
(GINTSTS.WkUpInt), the core starts driving resume
signaling without application intervention and clears this bit
when it detects a disconnect condition. The read value of
this bit indicates whether the core is currently driving
resume signaling.
0B No resume driven
1B Resume driven
This bit can be set and cleared by both hardware and
software.

XMC4500
XMC4000 Family

PrtSusp 7 rwh Port Suspend
The application sets this bit to put this port in Suspend
mode. The core only stops sending SOFs when this is set.
To stop the PHY clock, the application must set the Port
Clock Stop bit, which asserts the suspend input pin of the
PHY. The read value of this bit reflects the current suspend
status of the port. This bit is cleared by the core after a
remote wakeup signal is detected or the application sets
the Port Reset bit or Port Resume bit in this register or the
Resume/Remote WakeupDetected Interrupt bit or
Disconnect Detected Interrupt bit in the Core Interrupt
register (GINTSTS.WkUpInt or GINTSTS.DisconnInt,
respectively).
0B Port not in Suspend mode
1B Port in Suspend mode
hardware.
PrtRst 8 rw Port Reset
When the application sets this bit, a reset sequence is
started on this port. The application must time the reset
period and clear this bit after the reset sequence is
complete.
0B Port not in reset
1B Port in reset
To start a reset on the port, the application must leave this
bit set for at least the minimum duration mentioned below,
as specified in the USB 2.0 specification, Section 7.1.7.5.
The application can leave it set for another 10 ms in
addition to the required minimum duration, before clearing
the bit, even though there is no maximum limit set by the
USB standard.
Full speed: 10 ms
PrtLnSts [11:1 rh Port Line Status
0] Indicates the current logic level USB data lines
Bit [10]: Logic level of D+
Bit [11]: Logic level of D-

XMC4500
XMC4000 Family

PrtPwr 12 rwh Port Power
The application uses this field to control power to this port,
and the core can clear this bit on an over current condition.
0B Power off
1B Power on
This bit is set only by software and can be cleared by
hardware or a software write of 0 to the bit.
PrtSpd [18:1 rh Port Speed
7] Indicates the speed of the device attached to this port.
01B Full speed
Other values are reserved.
0 [31:1 r Reserved
[16:1
3], 9

XMC4500
XMC4000 Family
Host Channel-n Characteristics Register (HCCHARx)
HCCHARx (x=0-13)
Host Channel-x Characteristics Register(500H + x*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
ChE ChDi Odd
DevAddr MC_EC EPType 0
na s Frm
rwh rwh rw rw rw rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EPDi
EPNum MPS
r
rw rw rw

MPS [10:0] rw Maximum Packet Size
Indicates the maximum packet size of the associated
endpoint.
EPNum [14:1 rw Endpoint Number
1] Indicates the endpoint number on the device serving as the
data source or sink.
EPDir 15 rw Endpoint Direction
Indicates whether the transaction is IN or OUT.
0B OUT
1B IN
EPType [19:1 rw Endpoint Type
8] Indicates the transfer type selected.
00B Control
01B Isochronous
10B Bulk
11B Interrupt

XMC4500
XMC4000 Family

MC_EC [21:2 rw Multi Count / Error Count
0] This field indicates to the host the number of transactions
that must be executed per frame for this periodic endpoint.
For non periodic transfers, this field is used only in DMA
mode, and specifies the number packets to be fetched for
this channel before the internal DMA engine changes
arbitration.
00B Reserved. This field yields undefined results.
01B 1 transaction
10B 2 transactions to be issued for this endpoint per
frame
11B 3 transactions to be issued for this endpoint per
frame
DevAddr [28:2 rw Device Address
2] This field selects the specific device serving as the data
source or sink.
OddFrm 29 rw Odd Frame
This field is set (reset) by the application to indicate that the
OTG host must perform a transfer in an odd frame. This
field is applicable for only periodic (isochronous and
interrupt) transactions.
0B Even frame
1B Odd frame
This field is not applicable for Scatter/Gather DMA mode
and need not be programmed by the application and is
ignored by the core.
ChDis 30 rwh Channel Disable
The application sets this bit to stop transmitting/receiving
data on a channel, even before the transfer for that channel
is complete. The application must wait for the Channel
Disabled interrupt before treating the channel as disabled.
This bit can be set by software and can be cleared by both
hardware and software.

XMC4500
XMC4000 Family

ChEna 31 rwh Channel Enable
When Scatter/Gather mode is enabled
0B Indicates that the descriptor structure is not yet
ready.
1B Indicates that the descriptor structure and data buffer
with data is setup and this channel can access the
descriptor.
When Scatter/Gather mode is disabled
This field is set by the application and cleared by the OTG
host.
0B Channel disabled
1B Channel enabled
hardware.
0 [17:1 r Reserved

XMC4500
XMC4000 Family
Host Channel-n Interrupt Register (HCINTx)

This register indicates the status of a channel with respect to USB- and AHB-related
events. It is shown in Figure 16-67 Interrupt Hierarchy on Page 16-209. The
application must read this register when the Host Channels Interrupt bit of the Core
Interrupt register (GINTSTS.HChInt) is set. Before the application can read this register,
it must first read the Host All Channels Interrupt (HAINT) register to get the exact channel
number for the Host Channel-n Interrupt register. The application must clear the
appropriate bit in this register to clear the corresponding bits in the HAINT and GINTSTS
registers.
Note: All bits of the access type rwh in this register are set only by hardware and
cleared only by a software write of 1 to the bits.
HCINTx (x=0-13)
Host Channel-x Interrupt Register(508H + x*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DES
XCS
C_L Data Frm Xfer
_XA BNAI BblE Xact NYE STA AHB ChHl
0 ST_ TglE Ovru ACK NAK Com
CT_ ntr rr Err T LL Err td
ROL rr n pl
ERR
LIntr
r rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh

XMC4500
XMC4000 Family

XferComp 0 rwh Transfer Completed
l For Scatter/Gather DMA mode, it indicates that current
descriptor processing got completed with IOC bit set in its
descriptor.
In non Scatter/Gather DMA mode, it indicates that Transfer
completed normally without any errors.
ChHltd 1 rwh Channel Halted
In non Scatter/Gather DMA mode, it indicates the transfer
completed abnormally either because of any USB
transaction error or in response to disable request by the
application or because of a completed transfer.
In Scatter/Gather DMA mode, this indicates that transfer
completed due to any of the following
EOL being set in descriptor
AHB error
Excessive transaction errors
In response to disable request by the application
Babble
Stall
Buffer Not Available (BNA)
AHBErr 2 rwh AHB Error
This is generated only in DMA mode when there is an AHB
error during AHB read/write.
The application can read the corresponding channel's DMA
address register to get the error address.
STALL 3 rwh STALL Response Received Interrupt
In Scatter/Gather DMA mode, the interrupt due to this bit is
masked in the core.
NAK 4 rwh NAK Response Received Interrupt
masked in the core.
ACK 5 rwh ACK Response Received/Transmitted Interrupt
masked in the core.
NYET 6 rwh NYET Response Received Interrupt
masked in the core.

XMC4500
XMC4000 Family

XactErr 7 rwh Transaction Error
Indicates one of the following errors occurred on the USB.
CRC check failure
Timeout
Bit stuff error
False EOP
masked in the core.
BblErr 8 rwh Babble Error
masked in the core.
FrmOvrun 9 rwh Frame Overrun
masked in the core
DataTglEr 10 rwh Data Toggle Error
r In Scatter/Gather DMA mode, the interrupt due to this bit is
masked in the core.
BNAIntr 11 rwh BNA (Buffer Not Available) Interrupt
This bit is valid only when Scatter/Gather DMA mode is
enabled. The core generates this interrupt when the
descriptor accessed is not ready for the Core to process.
BNA will not be generated for Isochronous channels.
For non Scatter/Gather DMA mode, this bit is reserved.
XCS_XAC 12 rwh Excessive Transaction Error
T_ERR This bit is valid only when Scatter/Gather DMA mode is
enabled. The core sets this bit when 3 consecutive
transaction errors occurred on the USB bus.
XCS_XACT_ERR will not be generated for Isochronous
channels.
DESC_LS 13 rwh Descriptor rollover interrupt
T_ROLLIn This bit is valid only when Scatter/Gather DMA mode is
tr enabled. The core sets this bit when the corresponding
channel's descriptor list rolls over.
0 [31:1 r Reserved

XMC4500
XMC4000 Family
Host Channel-n Interrupt Mask Register (HCINTMSKx)

This register reflects the mask for each channel status described in register HCINTx.
Mask interrupt: 0B
HCINTMSKx (x=0-13)
Host Channel-x Interrupt Mask Register(50CH + x*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DES
Data Frm Xfer
C_L BNAI BblE Xact AHB ChHl
ST_ TglE Ovru Nyet Ack Nak Stall Com
0 0 ntrM rrMs ErrM ErrM tdMs
rrMs nMs Msk Msk Msk Msk plMs
ROL sk k sk sk k
k k k
LIntr
r rw r rw rw rw rw rw rw rw rw rw rw rw rw

XferComp 0 rw Transfer Completed Mask
lMsk
ChHltdMs 1 rw Channel Halted Mask
k
AHBErrM 2 rw AHB Error Mask
sk
StallMsk 3 rw STALL Response Received Interrupt Mask
This bit is not applicable in Scatter/Gather DMA mode.
NakMsk 4 rw NAK Response Received Interrupt Mask
AckMsk 5 rw ACK Response Received/Transmitted Interrupt Mask
NyetMsk 6 rw NYET Response Received Interrupt Mask
XactErrM 7 rw Transaction Error Mask
sk This bit is not applicable in Scatter/Gather DMA mode

XMC4500
XMC4000 Family

BblErrMs 8 rw Babble Error Mask
k This bit is not applicable in Scatter/Gather DMA mode.
FrmOvrun 9 rw Frame Overrun Mask
Msk This bit is not applicable in Scatter/Gather DMA mode.
DataTglEr 10 rw Data Toggle Error Mask
rMsk This bit is not applicable in Scatter/Gather DMA mode.
BNAIntrM 11 rw BNA (Buffer Not Available) Interrupt mask register
sk This bit is valid only when Scatter/Gather DMA mode is
enabled.
In non Scatter/Gather DMA mode, this bit is reserved
DESC_LS 13 rw Descriptor rollover interrupt Mask register
T_ROLLIn This bit is valid only when Scatter/Gather DMA mode is
trMsk enabled.
0 [31:1 r Reserved
4], 12 Read as 0; should be written with 0.

XMC4500
XMC4000 Family
Host Channel-n Transfer Size Register (HCTSIZx)

The HCTSIZx register description depends on the selected DMA mode.
In Scatter/Gather mode, HCTSIZx is defined as follows:
HCTSIZx (x=0-13)
Host Channel-x Transfer Size Register [SCATGATHER]
(510H + x*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 Pid 0 NTD SCHED_INFO
r rw r rw rw

SCHED_I [7:0] rw Schedule information
NFO This field should be written with 11111111B for a FS Host.
NTD [15:8] rw Number of Transfer Descriptors
(Non Isochronous)
This value is in terms of number of descriptors. Maximum
number of descriptor that can be present in the list is 64.
The values can be from 0 to 63.
0D 1 descriptor
...D ...
63D 64 descriptors
This field indicates the total number of descriptors present
in that list. The core will wrap around after servicing NTD
number of descriptors for that list.
(Isochronous)
This field indicates the number of descriptors present in that
list frame
The possible values are
1D 2 descriptors
3D 4 descriptors
7D 8 descriptors
15D 16 descriptors
31D 32 descriptors
63D 64 descriptors

XMC4500
XMC4000 Family

Pid [30:2 rw PID
9] The application programs this field with the type of PID to
use for the initial transaction.The host maintains this field
for the rest of the transfer.
00B DATA0
01B DATA2
10B DATA1
11B MDATA (non-control)
0 31, r Reserved
6]
Host Channel-n Transfer Size Register (HCTSIZx)

In Buffer DMA Mode, HCTSIZx is defined as follows:
HCTSIZx (x=0-13)
Host Channel-x Transfer Size Register [BUFFERMODE]
(510H + x*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 Pid PktCnt XferSize
r rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
XferSize
rw

XMC4500
XMC4000 Family

XferSize [18:0] rw Transfer Size
For an OUT, this field is the number of data bytes the host
sends during the transfer.
For an IN, this field is the buffer size that the application has
reserved for the transfer.
The application is expected to program this field as an
integer multiple of the maximum packet size for IN
transactions (periodic and non-periodic).
PktCnt [28:1 rw Packet Count
9] This field is programmed by the application with the
expected number of packets to be transmitted (OUT) or
received (IN).
The host decrements this count on every successful
transmission or reception of an OUT/IN packet. Once this
count reaches zero, the application is interrupted to
indicate normal completion.
Pid [30:2 rw PID
9] The application programs this field with the type of PID to
use for the initial transaction.The host maintains this field
for the rest of the transfer.
00B DATA0
01B DATA2
10B DATA1
11B MDATA (non-control)/SETUP (control)
0 31 r Reserved

XMC4500
XMC4000 Family
Host Channel-n DMA Address Register (HCDMAx)

This register is used by the OTG host in DMA mode to maintain the current buffer pointer
for IN/OUT transactions. The starting DMA address must be DWORD-aligned. The
HCDMAx register description depends on the selected DMA mode.
In Buffer DMA Mode, HCDMAx is defined as follows:
HCDMAx (x=0-13)
Host Channel-x DMA Address Register [BUFFERMODE]
(514H + x*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DMAAddr
rw

DMAAddr [31:0] rw DMA Address
This field holds the start address in the external
memory from which the data for the endpoint must be
fetched or to which it must be stored. This register is
incremented on every AHB transaction.

XMC4500
XMC4000 Family
In Scatter/Gather DMA Mode, HCDMAx is defined as follows:
HCDMAx (x=0-13)
Host Channel-x DMA Address Register [SCATGATHER]
(514H + x*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DMAAddr CTD 0
rw rw r

XMC4500
XMC4000 Family

CTD [8:3] rw Current Transfer Desc:
Non Isochronous:
This value is in terms of number of descriptors. The
values can be from 0 to 63.
0D 1 descriptor
...D ...
63D 64 descriptors
This field indicates the current descriptor processed in
the list. This field is updated both by application and
the core. For example, if the application enables the
channel after programming CTD=5, then the core will
start processing the 6th descriptor. The address is
obtained by adding a value of (8 bytes*5=) 40 to
DMAAddr.
Isochronous:
For isochronous transfers, the bits are [N-1:3]. CTD for
isochronous is based on the current frame value. Need
to be set to zero by application.

XMC4500
XMC4000 Family

Non-Isochronous:
This field holds the start address of the 512 bytes
page. The first descriptor in the list should be located
in this address. The first descriptor may be or may not
be ready. The core starts processing the list from the
CTD value.
Isochronous:
For isochronous transfers, the bits are [31:N]. This field
holds the address of the 2*(nTD+1) bytes of locations
in which the isochronous descriptors are present
where N is based on nTD as listed below:
nTD=1 => N=4
nTD=3 => N=5
nTD=7 => N=6
nTD=15 => N=7
nTD=31 => N=8
nTD=63 => N=9
Note: For Scatter/Gather DMA mode, this address is
the start of the page address where the
descriptor list is located.
0 [2:0] r Reserved

XMC4500
XMC4000 Family
Host Channel-n DMA Buffer Address Register (HCDMABx)

This register is present only in case of Scatter/Gather DMA. It is implemented in RAM.
This register holds the current buffer address.
HCDMABx (x=0-13)
Host Channel-x DMA Buffer Address Register(51CH + x*20H) Reset Value:
0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Buffer_Address

Buffer_Ad [31:0] r Buffer Address
dress Holds the current buffer address. This register is updated
as and when the data transfer for the corresponding end
point is in progress.
Reset: "X" if not programmed as the register is in SPRAM
Device Mode Registers

These registers are visible only in Device mode and must not be accessed in Host mode,
as the results are unknown. Some of them affect all the endpoints uniformly, while others
affect only a specific endpoint. Device Mode registers fall into two categories:
Device Logical IN Endpoint-Specific Registers

One set of endpoint registers is instantiated per logical endpoint. A logical endpoint is
unidirectional: it can be either IN or OUT. To represent a bidirectional endpoint, two
logical endpoints are required, one for the IN direction and the other for the OUT
direction. This is also true for control endpoints.
The registers and register fields described in this section can pertain to IN or OUT
endpoints, or both, or specific endpoint types as noted.

XMC4500
XMC4000 Family
Device Configuration Register (DCFG)

This register configures the core in Device mode after power-on or after certain control
commands or enumeration. Do not make changes to this register after initial
programming.
DCFG
Device Configuration Register (800H) Reset Value: 0820 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PerSchInt Desc
0 1 0 0 1 0 0
vl DMA
r r r rw rw r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
NZSt
sOU
0 PerFrInt DevAddr 0 DevSpd
THS
hk
r rw rw r rw rw

XMC4500
XMC4000 Family

DevSpd [1:0] rw Device Speed
Indicates the speed at which the application requires the
core to enumerate, or the maximum speed the application
can support. However, the actual bus speed is determined
only after the chirp sequence is completed, and is based on
the speed of the USB host to which the core is connected.
See Device Initialization on Page 16-69 for details.
00B Reserved
01B Reserved
10B Reserved
11B Full speed (USB 1.1 transceiver clock is 48 MHz)
NZStsOU 2 rw Non-Zero-Length Status OUT Handshake
THShk The application can use this field to select the handshake
the core sends on receiving a nonzero-length data packet
during the OUT transaction of a control transfer's Status
stage.
1B Send a STALL handshake on a nonzero-length
status OUT transaction and do not send the received
OUT packet to the application.
0B Send the received OUT packet to the application
(zero-length or nonzero-length) and send a
handshake based on the NAK and STALL bits for the
endpoint in the Device Endpoint Control register.
DevAddr [10:4] rw Device Address
The application must program this field after every
SetAddress control command.
PerFrInt [12:1 rw Periodic Frame Interval
1] Indicates the time within a frame at which the application
must be notified using the End Of Periodic Frame Interrupt.
This can be used to determine if all the isochronous traffic
for that frame is complete.
00B 80% of the frame interval
01B 85%
10B 90%
11B 95%

XMC4500
XMC4000 Family

DescDMA 23 rw Enable Scatter/Gather DMA in Device mode.
The application can set this bit during initialization to enable
the Scatter/Gather DMA operation.
Note: This bit must be modified only once after a reset.
The following combinations are available for programming:
GAHBCFG.DMAEn=0,DCFG.DescDMA=0 => Slave
mode
GAHBCFG.DMAEn=0,DCFG.DescDMA=1 => Invalid
GAHBCFG.DMAEn=1 ,DCFG.DescDMA=0 =>
Buffered DMA mode
GAHBCFG.DMAEn=1 ,DCFG.DescDMA=1 =>
Scatter/Gather DMA mode
PerSchInt [25:2 rw Periodic Scheduling Interval
vl 4] PerSchIntvl must be programmed only for Scatter/Gather
DMA mode.
Description: This field specifies the amount of time the
Internal DMA engine must allocate for fetching periodic IN
endpoint data. Based on the number of periodic endpoints,
this value must be specified as 25, 50 or 75% of frame.
When any periodic endpoints are active, the internal
DMA engine allocates the specified amount of time in
fetching periodic IN endpoint data.
When no periodic endpoints are active, then the internal
DMA engine services non-periodic endpoints, ignoring
this field.
After the specified time within a frame, the DMA
switches to fetching for non-periodic endpoints.
00B 25% of frame.
01B 50% of frame.
10B 75% of frame.
11B Reserved.

XMC4500
XMC4000 Family

1 27, r Reserved
0 [31:2 r Reserved
26,
22,
[20:1
8],
[17:1
3], 3

XMC4500
XMC4000 Family
Device Control Register (DCTL)
DCTL
Device Control Register (804H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Nak
0 OnB
ble
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Ignr CGO SGO CGN SGN GOU GNPI Rmt
SftDi
Frm GMC 0 UTN UTN PInN PInN 0 TNak NNa WkU
scon
Num ak ak ak ak Sts kSts pSig
rw rw r w w w w r rh rh rw rw

RmtWkUp 0 rw Remote Wakeup Signaling
Sig When the application sets this bit, the core initiates remote
signaling to wake the USB host. The application must set
this bit to instruct the core to exit the Suspend state. As
specified in the USB 2.0 specification, the application must
clear this bit 1 to15 ms after setting it.
SftDiscon 1 rw Soft Disconnect
The application uses this bit to signal the USB core to do a
soft disconnect. As long as this bit is set, the host does not
see that the device is connected, and the device does not
receive signals on the USB. The core stays in the
disconnected state until the application clears this bit.
The minimum duration for which the core must keep this bit
set is specified in Table 16-21.
0B Normal operation. When this bit is cleared after a soft
disconnect, the core drives a device connect event to
the USB host. When the device is reconnected, the
USB host restarts device enumeration.
1B The core drives a device disconnect event to the
USB host.

XMC4500
XMC4000 Family

GNPINNa 2 rh Global Non-periodic IN NAK Status
kSts 0B A handshake is sent out based on the data
availability in the transmit FIFO.
1B A NAK handshake is sent out on all non-periodic IN
endpoints, irrespective of the data availability in the
transmit FIFO.
GOUTNak 3 rh Global OUT NAK Status
Sts 0B A handshake is sent based on the FIFO Status and
the NAK and STALL bit settings.
1B No data is written to the RxFIFO, irrespective of
space availability. Sends a NAK handshake on all
packets, except on SETUP transactions. All
isochronous OUT packets are dropped.
SGNPInN 7 w Set Global Non-periodic IN NAK
ak A write to this field sets the Global Non-periodic IN
NAK.The application uses this bit to send a NAK
handshake on all non-periodic IN endpoints. The core can
also set this bit when a timeout condition is detected on a
non-periodic endpoint in shared FIFO operation.
The application must set this bit only after making sure that
the Global IN NAK Effective bit in the Core Interrupt
Register (GINTSTS.GINNakEff) is cleared.
CGNPInN 8 w Clear Global Non-periodic IN NAK
ak A write to this field clears the Global Non-periodic IN NAK.
SGOUTNa 9 w Set Global OUT NAK
k A write to this field sets the Global OUT NAK.
The application uses this bit to send a NAK handshake on
all OUT endpoints.
The application must set the this bit only after making sure
that the Global OUT NAK Effective bit in the Core Interrupt
Register (GINTSTS.GOUTNakEff) is cleared.
CGOUTN 10 w Clear Global OUT NAK
ak A write to this field clears the Global OUT NAK.

XMC4500
XMC4000 Family

GMC [14:1 rw Global Multi Count
3] GMC must be programmed only once after initialization.
Applicable only for Scatter/Gather DMA mode. This
indicates the number of packets to be serviced for that end
point before moving to the next end point. It is only for non-
periodic end points.
00B Invalid.
01B 1 packet.
10B 2 packets.
11B 3 packets.
When Scatter/Gather DMA mode is disabled, this field is
reserved. and reads 00B.
IgnrFrmN 15 rw Ignore frame number for isochronous endpoints in
um case of Scatter/Gather DMA
Note: When this bit is enabled, there must be only one
packet per descriptor.
0B The core transmits the packets only in the frame
number in which they are intended to be transmitted.
1B The core ignores the frame number, sending packets
immediately as the packets are ready.
Scatter/Gather:
In Scatter/Gather DMA mode, when this bit is enabled, the
packets are not flushed when an ISOC IN token is received
for an elapsed frame.
When Scatter/Gather DMA mode is disabled, this field is
used by the application to enable periodic transfer interrupt.
The application can program periodic endpoint transfers for
multiple frames.
0B Periodic transfer interrupt feature is disabled; the
application must program transfers for periodic
endpoints every frame
1B Periodic transfer interrupt feature is enabled; the
application can program transfers for multiple frames
for periodic endpoints.
In non-Scatter/Gather DMA mode, the application receives
transfer complete interrupt after transfers for multiple
frames are completed.

XMC4500
XMC4000 Family

NakOnBbl 16 rw Set NAK automatically on babble
e The core sets NAK automatically for the endpoint on which
babble is received.
0 [31:1 r Reserved
[12:1
1],
[6:4]
Table 16-21 lists the minimum duration under various conditions for which the Soft
Disconnect (SftDiscon) bit must be set for the USB host to detect a device disconnect.
To accommodate clock jitter, it is recommended that the application add some extra
delay to the specified minimum duration.
Table 16-21 Minimum Duration for Soft Disconnect

Operating Speed Device State Minimum Duration
Full speed Suspended 1 ms + 2.5 s
Full speed Idle 2.5 s
Full speed Not Idle or Suspended 2.5 s
(Performing transactions)

XMC4500
XMC4000 Family
Device Status Register (DSTS)

This register indicates the status of the core with respect to USB-related events. It must
be read on interrupts from Device All Interrupts (DAINT) register.
DSTS
Device Status Register (808H) Reset Value: 0000 0002H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 SOFFN
r rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Errti Susp
SOFFN 0 EnumSpd
cErr Sts
rh r rh rh rh

SuspSts 0 rh Suspend Status
In Device mode, this bit is set as long as a Suspend
condition is detected on the USB. The core enters the
Suspended state when there is no activity on the two USB
data signals for an extended period of time. The core
comes out of the suspend:
When there is any activity on the two USB data signals
When the application writes to the Remote Wakeup
Signaling bit in the Device Control register
(DCTL.RmtWkUpSig)
EnumSpd [2:1] rh Enumerated Speed
Indicates the speed at which the USB core has come up
after speed detection through a chirp sequence.
00B Reserved
01B Reserved
10B Reserved
11B Full speed (PHY clock is running at 48 MHz)

XMC4500
XMC4000 Family

ErrticErr 3 rh Erratic Error
The core sets this bit to report any erratic errors.
Due to erratic errors, the USB core goes into Suspended
state and an interrupt is generated to the application with
Early Suspend bit of the Core Interrupt register
(GINTSTS.ErlySusp). If the early suspend is asserted due
to an erratic error, the application can only perform a soft
disconnect recover.
SOFFN [21:8] rh Frame Number of the Received SOF
When the core is operating at full speed, this field contains
a frame number.
0 [31:2 r Reserved
[7:4]

XMC4500
XMC4000 Family
Device IN Endpoint Common Interrupt Mask Register (DIEPMSK)

This register works with each of the Device IN Endpoint Interrupt (DIEPINTx) registers
for all endpoints to generate an interrupt per IN endpoint. The IN endpoint interrupt for a
specific status in the DIEPINTx register can be masked by writing to the corresponding
bit in this register. Status bits are masked by default.
Mask interrupt: 0B
DIEPMSK
Device IN Endpoint Common
Interrupt Mask Register (810H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
INTk
Txfif INEP Xfer
BNAI nTX Time AHB EPDi
NAK oUn Nak Com
0 0 nIntr 0 0 FEm OUT ErrM sbld
Msk drnM EffM plMs
Msk pMs Msk sk Msk
sk sk k
k
r rw r rw rw r rw r rw rw rw rw rw

XferComplMsk 0 rw Transfer Completed Interrupt Mask
EPDisbldMsk 1 rw Endpoint Disabled Interrupt Mask
AHBErrMsk 2 rw AHB Error Mask
TimeOUTMsk 3 rw Timeout Condition Mask
(Non-isochronous endpoints)
INTknTXFEmpMsk 4 rw IN Token Received When TxFIFO Empty Mask
INEPNakEffMsk 6 rw IN Endpoint NAK Effective Mask
TxfifoUndrnMsk 8 rw Fifo Underrun Mask
BNAInIntrMsk 9 rw BNA Interrupt Mask

XMC4500
XMC4000 Family

NAKMsk 13 rw NAK interrupt Mask
0 [31:1 r Reserved
[12:1
0], 7,
5

XMC4500
XMC4000 Family
Device OUT Endpoint Common Interrupt Mask Register (DOEPMSK)

This register works with each of the Device OUT Endpoint Interrupt (DOEPINTx)
registers for all endpoints to generate an interrupt per OUT endpoint. The OUT endpoint
interrupt for a specific status in the DOEPINTx register can be masked by writing into the
corresponding bit in this register. Status bits are masked by default.
Mask interrupt: 0B
DOEPMSK
Device OUT Endpoint Common
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Bna Back OUT Xfer
NYE Bble OutP SetU AHB EPDi
NAK OutI 2Bac TknE Com
0 TMs ErrM 0 ktErr 0 0 PMs ErrM sbld
Msk ntrM kSE Pdis plMs
k sk Msk k sk Msk
sk Tup Msk k
r rw rw rw r rw rw r rw r rw rw rw rw rw

XferComplMsk 0 rw Transfer Completed Interrupt Mask
EPDisbldMsk 1 rw Endpoint Disabled Interrupt Mask
AHBErrMsk 2 rw AHB Error
SetUPMsk 3 rw SETUP Phase Done Mask
Applies to control endpoints only.
OUTTknEPdisMsk 4 rw OUT Token Received when Endpoint Disabled
Mask
Applies to control OUT endpoints only.
Back2BackSETup 6 rw Back-to-Back SETUP Packets Received Mask
OutPktErrMsk 8 rw OUT Packet Error Mask
BnaOutIntrMsk 9 rw BNA interrupt Mask
BbleErrMsk 12 rw Babble Interrupt Mask
NAKMsk 13 rw NAK Interrupt Mask

XMC4500
XMC4000 Family

NYETMsk 14 rw NYET Interrupt Mask
0 [31:1 r Reserved
[11:1
0], 7,
5

XMC4500
XMC4000 Family
Device All Endpoints Interrupt Register (DAINT)

When a significant event occurs on an endpoint, a Device All Endpoints Interrupt register
interrupts the application using the Device OUT Endpoints Interrupt bit or Device IN
Endpoints Interrupt bit of the Core Interrupt register (GINTSTS.OEPInt or
GINTSTS.IEPInt, respectively). This is shown in Figure 16-67 Interrupt Hierarchy
on Page 16-209. There is one interrupt bit per endpoint, up to a maximum of 7 bits for
OUT endpoints and 7 bits for IN endpoints. For a bidirectional endpoint, the
corresponding IN and OUT interrupt bits are used. Bits in this register are set and cleared
when the application sets and clears bits in the corresponding Device Endpoint-n
Interrupt register (DIEPINTx/DOEPINTx).
DAINT
Device All Endpoints Interrupt Register(818H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
OutEPInt InEpInt
rh rh

InEpInt [15:0] rh IN Endpoint Interrupt Bits
One bit per IN Endpoint:
Bit 0 for IN endpoint 0, bit 6 for endpoint 6. Bits [15:7] are
not used.
OutEPInt [31:1 rh OUT Endpoint Interrupt Bits
6] One bit per OUT endpoint:
Bit 16 for OUT endpoint 0, bit 22 for OUT endpoint 6. Bits
[31:23] are not used.

XMC4500
XMC4000 Family
Device All Endpoints Interrupt Mask Register (DAINTMSK)

The Device Endpoint Interrupt Mask register works with the Device Endpoint Interrupt
register to interrupt the application when an event occurs on a device endpoint.
However, the Device All Endpoints Interrupt (DAINT) register bit corresponding to that
interrupt is still set.
Mask Interrupt: 0B
Unmask Interrupt: 1B
DAINTMSK
Device All Endpoints Interrupt Mask Register(81CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
OutEpMsk InEpMsk
rw rw

InEpMsk [15:0] rw IN EP Interrupt Mask Bits
One bit per IN Endpoint:
Bit 0 for IN EP 0, bit 6 for IN EP 6. Bits [15:7] are not
used.
OutEpMsk [31:16] rw OUT EP Interrupt Mask Bits
One per OUT Endpoint:
Bit 16 for OUT EP 0, bit 22 for OUT EP 6. Bits
[31:23] are not used.

XMC4500
XMC4000 Family
Device VBUS Discharge Time Register (DVBUSDIS)

This register specifies the VBUS discharge time after VBUS pulsing during SRP.
DVBUSDIS
Device VBUS Discharge Time Register(828H) Reset Value: 0000 17D7H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 DVBUSDis
r rw

DVBUSDi [15:0] rw Device Vbus Discharge Time
s Specifies the Vbus discharge time after Vbus pulsing
during SRP. This value equals:
Vbus discharge time in PHY clocks / 1,024
The reset value is based on PHY operating at 60 MHz.
Depending on the Vbus load, this value might need
adjustment.
0 [31:1 r Reserved

XMC4500
XMC4000 Family
Device VBUS Pulsing Time Register (DVBUSPULSE)

This register specifies the VBUS pulsing time during SRP.
DVBUSPULSE
Device VBUS Pulsing Time Register (82CH) Reset Value: 0000 05B8H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 DVBUSPulse
r rw

DVBUSPu [11:0] rw Device Vbus Pulsing Time
lse Specifies the Vbus pulsing time during SRP. This value
equals:
Vbus pulsing time in PHY clocks / 1,024
The reset value is based on PHY operating at 60 MHz.
0 [31:1 r Reserved

XMC4500
XMC4000 Family
Device IN Endpoint FIFO Empty Interrupt Mask Register (DIEPEMPMSK)

This register is used to control the IN endpoint FIFO empty interrupt generation
(DIEPINTx.TxfEmp).
Mask interrupt: 0B
DIEPEMPMSK
Device IN Endpoint FIFO Empty
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 InEpTxfEmpMsk
r rw

InEpTxfE [15:0] rw IN EP Tx FIFO Empty Interrupt Mask Bits
mpMsk These bits acts as mask bits for DIEPINTx.
TxFEmp interrupt One bit per IN Endpoint:
Bit 0 for IN endpoint 0
...
Bit 6 for endpoint 6
Bits [15:7] are not used.
0 [31:1 r Reserved

XMC4500
XMC4000 Family
Device Control IN Endpoint 0 Control Register (DIEPCTL0)

This section describes the Control IN Endpoint 0 Control register. Non-zero control
endpoints use registers for endpoints 1-6.
DIEPCTL0
Device Control IN Endpoint 0 Control Register(900H) Reset Value: 0000 8000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
EPE EPDi SNA CNA NAK
0 TxFNum Stall 0 EPType 0
na s K K Sts
rwh rwh r w w rw rwh r r rh r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
USB
ActE 0 MPS
P
r r rw

Applies to IN and OUT endpoints.
The application must program this field with the maximum
packet size for the current logical endpoint.
00B 64 bytes
01B 32 bytes
10B 16 bytes
11B 8 bytes
USBActE 15 r USB Active Endpoint
P This bit is always set to 1, indicating that control endpoint 0
is always active in all configurations and interfaces.
NAKSts 17 rh NAK Status
Indicates the following:
0B The core is transmitting non-NAK handshakes based
on the FIFO status
1B The core is transmitting NAK handshakes on this
endpoint.
When this bit is set, either by the application or core, the
core stops transmitting data, even if there is data available
in the TxFIFO. Irrespective of this bit's setting, the core
always responds to SETUP data packets with an ACK
handshake.

XMC4500
XMC4000 Family

EPType [19:1 r Endpoint Type
8] Hardcoded to 00B for control.
Stall 21 rwh STALL Handshake
The application can only set this bit, and the core clears it,
when a SETUP token is received for this endpoint. If a NAK
bit, Global Non-periodic IN NAK, or Global OUT NAK is set
along with this bit, the STALL bit takes priority.
hardware.
TxFNum [25:2 rw TxFIFO Number
2] This value is set to the FIFO number that is assigned to
IN Endpoint 0.
CNAK 26 w Clear NAK
A write to this bit clears the NAK bit for the endpoint.
SNAK 27 w Set NAK
A write to this bit sets the NAK bit for the endpoint.
Using this bit, the application can control the transmission
of NAK handshakes on an endpoint. The core can also set
this bit for an endpoint after a SETUP packet is received on
that endpoint.
EPDis 30 rwh Endpoint Disable
The application sets this bit to stop transmitting data on an
endpoint, even before the transfer for that endpoint is
complete. The application must wait for the Endpoint
Disabled interrupt before treating the endpoint as disabled.
The core clears this bit before setting the Endpoint Disabled
Interrupt. The application must set this bit only if Endpoint
Enable is already set for this endpoint.
hardware.

XMC4500
XMC4000 Family

EPEna 31 rwh Endpoint Enable
When Scatter/Gather DMA mode is enabled, for IN
endpoints this bit indicates that the descriptor structure
and data buffer with data ready to transmit is setup.
When Scatter/Gather DMA mode is disabledsuch as
in buffer-pointer based DMA modethis bit indicates
that data is ready to be transmitted on the endpoint.
The core clears this bit before setting the following
interrupts on this endpoint:
Endpoint Disabled
Transfer Completed
hardware.
0 [29:2 r Reserved
20,
16,
[14:2]

XMC4500
XMC4000 Family
Device Control OUT Endpoint 0 Control Register (DOEPCTL0)

This section describes the Control OUT Endpoint 0 Control register. Non-zero control
endpoints use registers for endpoints 1-6.
DOEPCTL0
Device Control OUT Endpoint 0 Control Register(B00H) Reset Value: 0000 8000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
EPE EPDi SNA CNA NAK
0 0 Stall Snp EPType 0
na s K K Sts
rwh r r w w r rwh rw r rh r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
USB
ActE 0 MPS
P
r r r

MPS [1:0] r Maximum Packet Size
The maximum packet size for control OUT endpoint 0 is the
same as what is programmed in control IN Endpoint 0.
00B 64 bytes
01B 32 bytes
10B 16 bytes
11B 8 bytes
USBActE 15 r USB Active Endpoint
P This bit is always set to 1, indicating that a control endpoint
0 is always active in all configurations and interfaces.
0B The core is transmitting non-NAK handshakes based
on the FIFO status.
endpoint.
When either the application or the core sets this bit, the
core stops receiving data, even if there is space in the
RxFIFO to accommodate the incoming packet.
Irrespective of this bit's setting, the core always responds to
SETUP data packets with an ACK handshake.

XMC4500
XMC4000 Family

EPType [19:1 r Endpoint Type
8] Hardcoded to 00 for control.
Snp 20 rw Snoop Mode
This bit configures the endpoint to Snoop mode. In Snoop
mode, the core does not check the correctness of OUT
packets before transferring them to application memory.
The application can only set this bit, and the core clears it,
when a SETUP token is received for this endpoint. If a NAK
bit or Global OUT NAK is set along with this bit, the STALL
bit takes priority. Irrespective of this bit's setting, the core
always responds to SETUP data packets with an ACK
handshake.
hardware.
CNAK 26 w Clear NAK
SNAK 27 w Set NAK
A write to this bit sets the NAK bit for the endpoint.
Using this bit, the application can control the transmission
of NAK handshakes on an endpoint. The core can also set
bit on a Transfer Completed interrupt, or after a SETUP is
received on the endpoint.
EPDis 30 r Endpoint Disable
The application cannot disable control OUT endpoint 0.

XMC4500
XMC4000 Family

When Scatter/Gather DMA mode is enabled, for OUT
endpoints this bit indicates that the descriptor structure and
data buffer to receive data is setup.
When Scatter/Gather DMA mode is disabled(such as
for buffer-pointer based DMA mode)this bit indicates
that the application has allocated the memory to start
receiving data from the USB.
The core clears this bit before setting any of the following
interrupts on this endpoint:
SETUP Phase Done
Endpoint Disabled
Transfer Completed
Note: In DMA mode, this bit must be set for the core to
transfer SETUP data packets into memory.
hardware.
0 [29:2 r Reserved
[25:2
2],
16,
[14:2]

XMC4500
XMC4000 Family
Device Endpoint-n Control Register (DIEPCTLx/DOEPCTLx)

The application uses this register to control the behavior of each logical endpoint other
than endpoint 0.
Note: The fields of the DIEPCTLx/DOEPCTLx register change, depending on
interrupt/bulk or isochronous/control endpoint.
DIEPCTLx (x=1-6)
Device Endpoint-x Control Register [INTBULK]
(900H + x*20H) Reset Value: 0000 0000H
DOEPCTLx (x=1-6)
Device Endpoint-x Control Register [INTBULK]
(B00H + x*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
EPE EPDi SetD SetD SNA CNA NAK
TxFNum Stall Snp EPType DPID
na s 1PID 0PID K K Sts
rwh rwh w w w w rw rw rw rw rh rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
USB
ActE 0 MPS
P
rwh r rw

The application must program this field with the
maximum packet size for the current logical endpoint.
This value is in bytes.
USBActEP 15 rwh USB Active Endpoint
Indicates whether this endpoint is active in the current
configuration and interface. The core clears this bit for all
endpoints (other than EP 0) after detecting a USB reset.
After receiving the SetConfiguration and SetInterface
commands, the application must program endpoint
registers accordingly and set this bit.

XMC4500
XMC4000 Family

DPID 16 rh Endpoint Data PID
Applies to interrupt/bulk IN and OUT endpoints only.
Contains the PID of the packet to be received or
transmitted on this endpoint. The application must
program the PID of the first packet to be received or
transmitted on this endpoint, after the endpoint is
activated. The applications use the SetD1PID and
SetD0PID fields of this register to program either DATA0
or DATA1 PID.
0B DATA0
1B DATA1
This field is applicable both for Scatter/Gather DMA
mode and non-Scatter/Gather DMA mode.
0B The core is transmitting non-NAK handshakes
based on the FIFO status.
endpoint.
When either the application or the core sets this bit:
The core stops receiving any data on an OUT endpoint,
even if there is space in the RxFIFO to accommodate the
incoming packet.
For non-isochronous IN endpoints: The core stops
transmitting any data on an IN endpoint, even if there
data is available in the TxFIFO.
For isochronous IN endpoints: The core sends out a
zero-length data packet, even if there data is available in
the TxFIFO.
Irrespective of this bit's setting, the core always responds
to SETUP data packets with an ACK handshake.
8] Applies to IN and OUT endpoints.
This is the transfer type supported by this logical
endpoint.
00B Control
01B Isochronous
10B Bulk
11B Interrupt

XMC4500
XMC4000 Family

Applies to OUT endpoints only.
This bit configures the endpoint to Snoop mode. In
Snoop mode, the core does not check the correctness of
OUT packets before transferring them to application
memory.
Stall 21 rw STALL Handshake
Applies to non-control, non-isochronous IN and OUT
endpoints only.
The application sets this bit to stall all tokens from the
USB host to this endpoint. If a NAK bit, Global Non-
periodic IN NAK, or Global OUT NAK is set along with
this bit, the STALL bit takes priority. Only the application
can clear this bit, never the core.
2] These bits specify the FIFO number associated with this
endpoint. Each active IN endpoint must be programmed
to a separate FIFO number.
This field is valid only for IN endpoints.
CNAK 26 w Clear NAK
SNAK 27 w Set NAK
Applies to IN and OUT endpoints.A write to this bit sets
the NAK bit for the endpoint.
Using this bit, the application can control the
transmission of NAK handshakes on an endpoint. The
core can also set this bit for OUT endpoints on a Transfer
Completed interrupt, or after a SETUP is received on the
endpoint.
SetD0PID 28 w Set DATA0 PID
Writing to this field sets the Endpoint Data PID (DPID)
field in this register to DATA0.

XMC4500
XMC4000 Family

SetD1PID 29 w 29 Set DATA1 PID
Writing to this field sets the Endpoint Data PID (DPID)
field in this register to DATA1.
data on an endpoint, even before the transfer for that
endpoint is complete. The application must wait for the
Endpoint Disabled interrupt before treating the endpoint
as disabled. The core clears this bit before setting the
Endpoint Disabled interrupt. The application must set
this bit only if Endpoint Enable is already set for this
endpoint.
hardware.

XMC4500
XMC4000 Family

When Scatter/Gather DMA mode is enabled,
For IN endpoints this bit indicates that the descriptor
structure and data buffer with data ready to transmit
is setup.
For OUT endpoint it indicates that the descriptor
structure and data buffer to receive data is setup.
When Scatter/Gather DMA mode is enabledsuch
as for buffer-pointer based DMA mode:
For IN endpoints, this bit indicates that data is
ready to be transmitted on the endpoint.
For OUT endpoints, this bit indicates that the
application has allocated the memory to start
The core clears this bit before setting any of the
following interrupts on this endpoint:
SETUP Phase Done
Endpoint Disabled
Transfer Completed
Note: For control endpoints in DMA mode, this bit must
be set to be able to transfer SETUP data packets
in memory.
hardware.
0 [14:1 r Reserved

XMC4500
XMC4000 Family
DIEPCTLx (x=1-6)
Device Endpoint-x Control Register [ISOCONT]
(900H + x*20H) Reset Value: 0000 0000H
DOEPCTLx (x=1-6)
Device Endpoint-x Control Register [ISOCONT]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SetE EO_
EPE EPDi SetO SNA CNA NAK
venF TxFNum Stall Snp EPType FrNu
na s ddFr K K Sts
r m
rwh rwh w w w w rw rwh rw rw rh rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
USB
ActE 0 MPS
P
rwh r rw

The application must program this field with the
maximum packet size for the current logical endpoint.
This value is in bytes.
USBActEP 15 rwh USB Active Endpoint
Indicates whether this endpoint is active in the current
configuration and interface. The core clears this bit for all
endpoints (other than EP 0) after detecting a USB reset.
After receiving the SetConfiguration and SetInterface
commands, the application must program endpoint
registers accordingly and set this bit.

XMC4500
XMC4000 Family

EO_FrNum 16 rh Even/Odd Frame
Applies to isochronous IN and OUT endpoints only.
In non-Scatter/Gather DMA mode, the bit Indicates the
frame number in which the core transmits/receives
isochronous data for this endpoint. The application must
program the even/odd frame number in which it intends
to transmit/receive isochronous data for this endpoint
using the SetEvnFr and SetOddFr fields in this register.
0B Even frame
1B Odd rame
When Scatter/Gather DMA mode is enabled, this field is
reserved. The frame number in which to send data is
provided in the transmit descriptor structure. The frame
in which data is received is updated in receive descriptor
structure.
0B The core is transmitting non-NAK handshakes
based on the FIFO status.
endpoint.
When either the application or the core sets this bit:
The core stops receiving any data on an OUT endpoint,
even if there is space in the RxFIFO to accommodate the
incoming packet.
For non-isochronous IN endpoints: The core stops
transmitting any data on an IN endpoint, even if there
data is available in the TxFIFO.
For isochronous IN endpoints: The core sends out a
zero-length data packet, even if there data is available in
the TxFIFO.

XMC4500
XMC4000 Family

8] Applies to IN and OUT endpoints.
This is the transfer type supported by this logical
endpoint.
00B Control
01B Isochronous
10B Bulk
11B Interrupt
Applies to OUT endpoints only.
This bit configures the endpoint to Snoop mode. In
Snoop mode, the core does not check the correctness of
OUT packets before transferring them to application
memory.
Applies to control endpoints only.
The application can only set this bit, and the core clears
it, when a SETUP token is received for this endpoint. If a
NAK bit, Global Non-periodic IN NAK, or Global OUT
NAK is set along with this bit, the STALL bit takes priority.
hardware.
2] These bits specify the FIFO number associated with this
endpoint. Each active IN endpoint must be programmed
to a separate FIFO number.
This field is valid only for IN endpoints.
CNAK 26 w Clear NAK

XMC4500
XMC4000 Family

SNAK 27 w Set NAK
Applies to IN and OUT endpoints.A write to this bit sets
the NAK bit for the endpoint.
Using this bit, the application can control the
transmission of NAK handshakes on an endpoint. The
core can also set this bit for OUT endpoints on a Transfer
Completed interrupt, or after a SETUP is received on the
endpoint.
SetEvenFr 28 w In non-Scatter/Gather DMA mode: Set Even frame
Writing to this field sets the Even/Odd frame
(EO_FrNum) field to even frame.
When Scatter/Gather DMA mode is enabled, this field is
reserved. The frame number in which to send data is in
the transmit descriptor structure. The frame in which to
receive data is updated in receive descriptor structure.
SetOddFr 29 w Set Odd frame
Writing to this field sets the Even/Odd frame
(EO_FrNum) field to odd frame.
This field is not applicable for Scatter/Gather DMA mode.
data on an endpoint, even before the transfer for that
endpoint is complete. The application must wait for the
Endpoint Disabled interrupt before treating the endpoint
as disabled. The core clears this bit before setting the
Endpoint Disabled interrupt. The application must set
this bit only if Endpoint Enable is already set for this
endpoint.
hardware.

XMC4500
XMC4000 Family

When Scatter/Gather DMA mode is enabled,
For IN endpoints this bit indicates that the descriptor
structure and data buffer with data ready to transmit
is setup.
For OUT endpoint it indicates that the descriptor
structure and data buffer to receive data is setup.
When Scatter/Gather DMA mode is enabledsuch
as for buffer-pointer based DMA mode:
For IN endpoints, this bit indicates that data is
ready to be transmitted on the endpoint.
For OUT endpoints, this bit indicates that the
application has allocated the memory to start
The core clears this bit before setting any of the
following interrupts on this endpoint:
SETUP Phase Done
Endpoint Disabled
Transfer Completed
Note: For control endpoints in DMA mode, this bit must
be set to be able to transfer SETUP data packets
in memory.
hardware.
0 [14:1 r Reserved

XMC4500
XMC4000 Family
Device Endpoint-n Interrupt Register (DIEPINTx/DOEPINTx)

This register indicates the status of an endpoint with respect to USB- and AHB-related
events. It is shown in Figure 16-67 Interrupt Hierarchy on Page 16-209. The
application must read this register when the OUT Endpoints Interrupt bit or IN Endpoints
Interrupt bit of the Core Interrupt register (GINTSTS.OEPInt or GINTSTS.IEPInt,
respectively) is set. Before the application can read this register, it must first read the
Device All Endpoints Interrupt (DAINT) register to get the exact endpoint number for the
Device Endpoint-n Interrupt register. The application must clear the appropriate bit in this
register to clear the corresponding bits in the DAINT and GINTSTS registers.
Note: In the DIEPINTx/DOEPINTx registers, status bits with access type rwh are set by
hardware. To clear these bits, the application must write 1 into these bits.
DIEPINTx (x=0-6)
Device Endpoint-x Interrupt Register (908H + x*20H) Reset Value: 0000 0080H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
INTk
INEP Xfer
BNAI TxFE nTX Time AHB EPDi
0 0 Nak 0 Com
ntr mp FEm OUT Err sbld
Eff pl
p
r rwh r r rwh r rwh rwh rwh rwh rwh

XMC4500
XMC4000 Family

XferComp 0 rwh Transfer Completed Interrupt
l Applies to IN and OUT endpoints.
When Scatter/Gather DMA mode is enabled
For IN endpoint this field indicates that the requested
data from the descriptor is moved from external system
memory to internal FIFO.
For OUT endpoint this field indicates that the requested
data from the internal FIFO is moved to external system
memory. This interrupt is generated only when the
corresponding endpoint descriptor is closed, and the
IOC bit for the corresponding descriptor is set.
When Scatter/Gather DMA mode is disabled, this field
indicates that the programmed transfer is complete on
the AHB as well as on the USB, for this endpoint.
EPDisbld 1 rwh Endpoint Disabled Interrupt
This bit indicates that the endpoint is disabled per the
application's request.
error during an AHB read/write. The application can read
the corresponding endpoint DMA address register to get
the error address.
TimeOUT 3 rwh Timeout Condition
Applies only to Control IN endpoints.
In Scatter/Gather DMA mode, the TimeOUT interrupt is
not asserted.
Indicates that the core has detected a timeout condition on
the USB for the last IN token on this endpoint.
INTknTXF 4 rwh IN Token Received When TxFIFO is Empty
Emp Indicates that an IN token was received when the
associated TxFIFO (periodic/non-periodic) was empty. This
interrupt is asserted on the endpoint for which the IN token
was received.

XMC4500
XMC4000 Family

INEPNakE 6 rwh IN Endpoint NAK Effective
ff Applies to periodic IN endpoints only.
This bit can be cleared when the application clears the IN
endpoint NAK by writing to DIEPCTLx.CNAK.
This interrupt indicates that the core has sampled the NAK
bit set (either by the application or by the core). The
interrupt indicates that the IN endpoint NAK bit set by the
application has taken effect in the core.
This interrupt does not guarantee that a NAK handshake is
sent on the USB. A STALL bit takes priority over a NAK bit.
This bit is applicable only when the endpoint is enabled.
TxFEmp 7 r Transmit FIFO Empty
This bit is valid only for IN Endpoints
This interrupt is asserted when the TxFIFO for this endpoint
is either half or completely empty. The half or completely
empty status is determined by the TxFIFO Empty Level bit
in the Core AHB Configuration register
(GAHBCFG.NPTxFEmpLvl)).
The core generates this interrupt when the descriptor
accessed is not ready for the Core to process, such as Host
busy or DMA done
enabled.
0 [31:1 r Reserved
0], 8, Read as 0; should be written with 0.
5

XMC4500
XMC4000 Family
DOEPINTx (x=0-6)
Device Endpoint-x Interrupt Register (B08H + x*20H) Reset Value: 0000 0080H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Back
NYE Bble PktD StsP OUT Xfer
NAKI BNAI 2Bac SetU AHB EPDi
0 TIntr ErrIn rpSt 0 0 hseR TknE Com
ntrpt ntr kSE p Err sbld
pt trpt s cvd Pdis pl
Tup
r rwh rwh rwh rwh r rwh r rw rwh rwh rwh rwh rwh rwh

XferComp 0 rwh Transfer Completed Interrupt
l Applies to IN and OUT endpoints.
When Scatter/Gather DMA mode is enabled
For IN endpoint this field indicates that the requested
data from the descriptor is moved from external system
memory to internal FIFO.
For OUT endpoint this field indicates that the requested
data from the internal FIFO is moved to external system
memory. This interrupt is generated only when the
corresponding endpoint descriptor is closed, and the
IOC bit for the corresponding descriptor is set.
When Scatter/Gather DMA mode is disabled, this field
indicates that the programmed transfer is complete on
the AHB as well as on the USB, for this endpoint.
EPDisbld 1 rwh Endpoint Disabled Interrupt
This bit indicates that the endpoint is disabled per the
application's request.
error during an AHB read/write. The application can read
the corresponding endpoint DMA address register to get
the error address.

XMC4500
XMC4000 Family

SetUp 3 rwh SETUP Phase Done
Indicates that the SETUP phase for the control endpoint is
complete and no more back-to-back SETUP packets were
received for the current control transfer. On this interrupt,
the application can decode the received SETUP data
packet.
OUTTknE 4 rwh OUT Token Received When Endpoint Disabled
Pdis Indicates that an OUT token was received when the
endpoint was not yet enabled.
This interrupt is asserted on the endpoint for which the OUT
token was received.
StsPhseR 5 rwh Status Phase Received For Control Write
cvd This interrupt is valid only for Control OUT endpoints and
only in Scatter Gather DMA mode.
This interrupt is generated only after the core has
transferred all the data that the host has sent during the
data phase of a control write transfer, to the system
memory buffer.
The interrupt indicates to the application that the host has
switched from data phase to the status phase of a Control
Write transfer. The application can use this interrupt to ACK
or STALL the Status phase, after it has decoded the data
phase. This is applicable only in case of Scatter Gather
DMA mode.
Back2Bac 6 rw Back-to-Back SETUP Packets Received
kSETup Applies to Control OUT endpoints only.
This bit indicates that the core has received more than
three back-to-back SETUP packets for this particular
endpoint. For information about handling this interrupt, see
Handling More Than Three Back-to-Back SETUP
Packets on Page 16-79.
The core generates this interrupt when the descriptor
accessed is not ready for the Core to process, such as Host
busy or DMA done
enabled.

XMC4500
XMC4000 Family

PktDrpSts 11 rwh Packet Dropped Status
This bit indicates to the application that an ISOC OUT
packet has been dropped. This bit does not have an
associated mask bit and does not generate an interrupt.
This bit is valid in non Scatter/Gather DMA mode when
periodic transfer interrupt feature is selected.
BbleErrInt 12 rwh BbleErr (Babble Error) interrupt
rpt The core generates this interrupt when babble is received
for the endpoint.
NAKIntrpt 13 rwh NAK interrupt
The core generates this interrupt when a NAK is
transmitted or received by the device.In case of
isochronous IN endpoints the interrupt gets generated
when a zero length packet is transmitted due to un-
availability of data in the TXFIFO.
NYETIntr 14 rwh NYET interrupt
pt The core generates this interrupt when a NYET response is
transmitted for a non isochronous OUT endpoint.
0 [31:1 r Reserved
10,
[8:7]

XMC4500
XMC4000 Family
Device Endpoint 0 Transfer Size Register (DIEPTSIZ0/DOEPTSIZ0)

The application must modify this register before enabling endpoint 0. Once endpoint 0 is
enabled using Endpoint Enable bit of the Device Control Endpoint 0 Control registers
(DIEPCTL0.EPEna/DOEPCTL0.EPEna), the core modifies this register. The application
can only read this register once the core has cleared the Endpoint Enable bit.
Non-zero endpoints use the registers for endpoints 1-6.
When Scatter/Gather DMA mode is enabled, this register must not be programmed by
the application. If the application reads this register when Scatter/Gather DMA mode is
enabled, the core returns all zeros.
DIEPTSIZ0
Device IN Endpoint 0 Transfer Size Register(910H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 PktCnt 0
r rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 XferSize
r rw

Indicates the transfer size in bytes for endpoint 0. The core
interrupts the application only after it has exhausted the
transfer size amount of data. The transfer size can be set
to the maximum packet size of the endpoint, to be
interrupted at the end of each packet.
The core decrements this field every time a packet from the
external memory is written to the TxFIFO.
9] Indicates the total number of USB packets that constitute
the Transfer Size amount of data for endpoint 0.
This field is decremented every time a packet (maximum
size or short packet) is read from the TxFIFO.
0 [31:2 r Reserved
[18:7]

XMC4500
XMC4000 Family
DOEPTSIZ0
Device OUT Endpoint 0 Transfer Size Register(B10H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 SUPCnt 0 PktCnt 0
r rw r rw r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 XferSize
r rw

Indicates the transfer size in bytes for endpoint 0. The core
interrupts the application only after it has exhausted the
transfer size amount of data. The transfer size can be set
to the maximum packet size of the endpoint, to be
interrupted at the end of each packet.
The core decrements this field every time a packet is read
from the RxFIFO and written to the external memory.
9] This field is decremented to zero after a packet is written
into the RxFIFO.
SUPCnt [30:2 rw SETUP Packet Count
9] This field specifies the number of back-to-back SETUP
data packets the endpoint can receive.
01B 1 packet
10B 2 packets
11B 3 packets
0 31, r Reserved
1],
[18:7]

XMC4500
XMC4000 Family
Device Endpoint-n Transfer Size Register (DIEPTSIZx/DOEPTSIZx)

The application must modify this register before enabling the endpoint. Once the
endpoint is enabled using Endpoint Enable bit of the Device Endpoint-n Control registers
(DIEPCTLx.EPEna/DOEPCTLx.EPEna), the core modifies this register. The application
can only read this register once the core has cleared the Endpoint Enable bit.
This register is used only for endpoints other than Endpoint 0.
Note: When Scatter/Gather DMA mode is enabled, this register must not be
programmed by the application. If the application reads this register when
Scatter/Gather DMA mode is enabled, the core returns all zeros
DIEPTSIZx (x=1-6)
Device Endpoint-x Transfer Size Register(910H + x*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 PktCnt XferSize
r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
XferSize
rw

This field contains the transfer size in bytes for the current
endpoint.
The core only interrupts the application after it has
exhausted the transfer size amount of data. The transfer
size can be set to the maximum packet size of the endpoint,
to be interrupted at the end of each packet.
IN Endpoints: The core decrements this field every time
a packet from the external memory is written to the
TxFIFO.

XMC4500
XMC4000 Family

the Transfer Size amount of data for this endpoint.
IN Endpoints: This field is decremented every time a
packet (maximum size or short packet) is read from the
TxFIFO..
0 [31:2 r Reserved
Note: The fields of the DOEPTSIZx register change, depending on isochronous or

control OUT endpoint.
DOEPTSIZx (x=1-6)
Device Endpoint-x Transfer Size Register [ISO]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 RxDPID PktCnt XferSize
r r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
XferSize
rw

XMC4500
XMC4000 Family

endpoint.
OUT Endpoints: The core decrements this field every
time a packet is read from the RxFIFO and written to the
external memory.
OUT Endpoints: This field is decremented every time a
packet (maximum size or short packet) is written to the
RxFIFO.
RxDPID [30:2 r Received Data PID
9] Applies to isochronous OUT endpoints only.
This is the data PID received in the last packet for this
endpoint.
00B DATA0
01B DATA2
10B DATA1
11B MDATA
0 31 r Reserved

XMC4500
XMC4000 Family
DOEPTSIZx (x=1-6)
Device Endpoint-x Transfer Size Register [CONT]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 SUPCnt PktCnt XferSize
r rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
XferSize
rw

endpoint.
OUT Endpoints: The core decrements this field every
time a packet is read from the RxFIFO and written to the
external memory.
OUT Endpoints: This field is decremented every time a
packet (maximum size or short packet) is written to the
RxFIFO.
SUPCnt [30:2 rw SETUP Packet Count
9] Applies to control OUT Endpoints only.
This field specifies the number of back-to-back SETUP
data packets the endpoint can receive.
00B 1 packet
00B 2 packets
00B 3 packets
0 31 r Reserved

XMC4500
XMC4000 Family
Device Endpoint-n DMA Address Register (DIEPDMAx/DOEPDMAx)

These registers are implemented in RAM.
DIEPDMAx (x=0-6)
Device Endpoint-x DMA Address Register(914H + x*20H) Reset Value:
XXXX XXXXH
DOEPDMAx (x=0-6)
Device Endpoint-x DMA Address Register(B14H + x*20H) Reset Value:
XXXX XXXXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DMAAddr
rw

Holds the start address of the external memory for storing
or fetching endpoint data.
Note: For control endpoints, this field stores control OUT
data packets as well as SETUP transaction data
packets. When more than three SETUP packets are
received back-to-back, the SETUP data packet in the
memory is overwritten.
This register is incremented on every AHB transaction. The
application can give only a DWORD-aligned address.
When Scatter/Gather DMA mode is not enabled, the
application programs the start address value in this
field.
When Scatter/Gather DMA mode is enabled, this field
indicates the base pointer for the descriptor list.

XMC4500
XMC4000 Family
Device Endpoint-n DMA Buffer Address Register (DIEPDMABx/DOEPDMABx)

These fields are present only in case of Scatter/Gather DMA. These registers are
implemented in RAM.
DIEPDMABx (x=0-6)
Device Endpoint-x DMA Buffer Address Register(91CH + x*20H) Reset Value:
XXXX XXXXH
DOEPDMABx (x=0-6)
Device Endpoint-x DMA Buffer Address Register(B1CH + x*20H) Reset Value:
XXXX XXXXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DMABufferAddr

DMABuffe [31:0] r DMA Buffer Address
rAddr Holds the current buffer address.This register is updated as
and when the data transfer for the corresponding end point
is in progress.
This register is present only in Scatter/Gather DMA mode.
Otherwise this field is reserved.

XMC4500
XMC4000 Family
Device IN Endpoint Transmit FIFO Status Register (DTXFSTSx)

This read-only register contains the free space information for the Device IN endpoint
TxFIFO.
DTXFSTSx (x=0-6)
Device IN Endpoint Transmit FIFO Status Register(918H + x*20H) Reset Value:
0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 INEPTxFSpcAvail
r rh

INEPTxFS [15:0] rh IN Endpoint TxFIFO Space Avail
pcAvail Indicates the amount of free space available in the
Endpoint TxFIFO.
Values are in terms of 32-bit words.
0H Endpoint TxFIFO is full
1H 1 word available
0 [31:1 r Reserved
Power and Clock Gating Registers

There is a single register for power and clock gating. It is available in both Host and
Device modes.
Power and Clock Gating Control Register (PCGCCTL)

This register is available in Host and Device modes. The application can use this register
to control the core's clock gating features.

XMC4500
XMC4000 Family
PCGCCTL
Power and Clock Gating Control Register(E00H) Reset Value: 0000 0100H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Gate Stop
0 1 0
Hclk Pclk
r r r rw rw

StopPclk 0 rw Stop Pclk
The application sets this bit to stop the PHY clock (phy_clk)
when the USB is suspended, the session is not valid, or the
device is disconnected. The application clears this bit when
the USB is resumed or a new session starts.
GateHclk 1 rw Gate Hclk
The application sets this bit to gate hclk to modules other
than the AHB Slave and Master and wakeup logic when the
USB is suspended or the session is not valid.
The application clears this bit when the USB is resumed or
a new session starts.
1 8 r Reserved
0 [31:9] r Reserved
, [7:2] Read as 0; should be written with 0.

XMC4500
XMC4000 Family
16.16 Interconnects
The interconnects section describes the connectivity of the module.

USB0.ID I P0.9 ID pad signal
USB0.D+ I/O USB_DP Data + signal
USB0.D- I/O USB_DM Data - signal
USB0.VBUS I/O VBUS VBUS signal
USB0.DRIVEVBUS O P0.1 Drive VBUS signal
P3.2

XMC4500
XMC4000 Family
17 Universal Serial Interface Channel (USIC)

The Universal Serial Interface Channel module (USIC) is a flexible interface module
covering several serial communication protocols. A USIC module contains two
independent communication channels named USICx_CH0 and USICx_CH1, with x
being the number of the USIC module (e.g. channel 0 of USIC module 0 is referenced
as USIC0_CH0). The user can program during run-time which protocol will be handled
by each communication channel and which pins are used.
References
The following documents are referenced for further information
[17] IIC Bus Specification (Philips Semiconductors v2.1)
[18] IIS Bus Specification (Philips Semiconductors June 5 1996 revision)
17.1 Overview
This section gives an overview about the feature set of the USIC.
17.1.1 Features
Each USIC channel can be individually configured to match the application needs, e.g.
the protocol can be selected or changed during run time without the need for a reset. The
following protocols are supported:
UART (ASC, asynchronous serial channel)
Module capability: receiver/transmitter with max. baud rate fPB / 4
Wide baud rate range down to single-digit baud rates
Number of data bits per data frame: 1 to 63
MSB or LSB first
LIN Support by hardware (Local Interconnect Network)
Data transfers based on ASC protocol
Baud rate detection possible by built-in capture event of baud rate generator
Checksum generation under software control for higher flexibility
SSC/SPI (synchronous serial channel with or without slave select lines)
Standard, Dual and Quad SPI format supported
Module capability: maximum baud rate fPB / 2, limited by loop delay
Number of data bits per data frame 1 to 63, more with explicit stop condition
Parity bit generation supported
MSB or LSB first
IIC (Inter-IC Bus)
Application baud rate 100 kbit/s to 400 kbit/s
7-bit and 10-bit addressing supported
Full master and slave device capability

USIC, V2.4 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
IIS (infotainment audio bus)

Module capability: maximum baud rate fPB / 2
Note: The real baud rates that can be achieved in a real application depend on the
operating frequency of the device, timing parameters as described in the Data
Sheet, signal delays on the PCB and timings of the peer device.
In addition to the flexible choice of the communication protocol, the USIC structure has
been designed to reduce the system load (CPU load) allowing efficient data handling.
The following aspects have been considered:
Data buffer capability
The standard buffer capability includes a double word buffer for receive data and a
single word buffer for transmit data. This allows longer CPU reaction times (e.g.
interrupt latency).
Additional FIFO buffer capability
In addition to the standard buffer capability, the received data and the data to be
transmitted can be buffered in a FIFO buffer structure. The size of the receive and
the transmit FIFO buffer can be programmed independently. Depending on the
application needs, a total buffer capability of 64 data words can be assigned to the
receive and transmit FIFO buffers of a USIC module (the two channels of the USIC
module share the 64 data word buffer).
In addition to the FIFO buffer, a bypass mechanism allows the introduction of high-
priority data without flushing the FIFO buffer.
Transmit control information
For each data word to be transmitted, a 5-bit transmit control information has been
added to automatically control some transmission parameters, such as word length,
frame length, or the slave select control for the SPI protocol. The transmit control
information is generated automatically by analyzing the address where the user
software has written the data word to be transmitted (32 input locations = 25 = 5 bit
transmit control information).
This feature allows individual handling of each data word, e.g. the transmit control
information associated to the data words stored in a transmit FIFO can automatically
modify the slave select outputs to select different communication targets (slave
devices) without CPU load. Alternatively, it can be used to control the frame length.
Flexible frame length control
The number of bits to be transferred within a data frame is independent of the data
word length and can be handled in two different ways. The first option allows
automatic generation of frames up to 63 bits with a known length. The second option
supports longer frames (even unlimited length) or frames with a dynamically
controlled length.
Interrupt capability
The events of each USIC channel can be individually routed to one of 6 service
request outputs SR[5:0] available for each USIC module, depending on the

XMC4500
XMC4000 Family
application needs. Furthermore, specific start and end of frame indications are
supported in addition to protocol-specific events.
Flexible interface routing
Each USIC channel offers the choice between several possible input and output pins
connections for the communications signals. This allows a flexible assignment of
USIC signals to pins that can be changed without resetting the device.
Input conditioning
Each input signal is handled by a programmable input conditioning stage with
programmable filtering and synchronization capability.
Baud rate generation
Each USIC channel contains its own baud rate generator. The baud rate generation
can be based either on the internal module clock or on an external frequency input.
This structure allows data transfers with a frequency that can not be generated
internally, e.g. to synchronize several communication partners.
Transfer trigger capability
In master mode, data transfers can be triggered by events generated outside the
USIC module, e.g. by an input pin or a timer unit (transmit data validation). This
feature allows time base related data transmission.
Debugger support
The USIC offers specific addresses to read out received data without interaction with
the FIFO buffer mechanism. This feature allows debugger accesses without the risk
of a corrupted receive data sequence.
To reach a desired baud rate, two criteria have to be respected, the module capability
and the application environment. The module capability is defined with respect to the
modules input clock frequency, being the base for the module operation. Although the
modules capability being much higher (depending on the module clock and the number
of module clock cycles needed to represent a data bit), the reachable baud rate is
generally limited by the application environment. In most cases, the application
environment limits the maximum reachable baud rate due to driver delays, signal
propagation times, or due to EMI reasons.
Note: Depending on the selected additional functions (such as digital filters, input
synchronization stages, sample point adjustment, data structure, etc.), the
maximum reachable baud rate can be limited. Please also take care about
additional delays, such as (internal or external) propagation delays and driver
delays (e.g. for collision detection in ASC mode, for IIC, etc.).

XMC4500
XMC4000 Family
A block diagram of the USIC module/channel structure is shown in Figure 17-1.
SRx To Interrupt
Interrupt Generation Registers
Pins
USICx
Baud Rate Generator fPB _C0
Input
Data PPP Stages
Data
Buffer Shift ( ASC,
Signal Distribution
Unit SSC. ..)
User Interface
Channel 0
USICx
Baud Rate Generator fPB _C1
Input
Data PPP Stages
Data Shift
Buffer Unit
( ASC,
SSC. ..)
Channel 1
Optional : FIFO Data Buffer shared USIC

between U SICx_C0 and USICx_C1 Module x
Figure 17-1 USIC Module/Channel Structure

XMC4500
XMC4000 Family
17.2 Operating the USIC

This section describes how to operate the USIC communication channel.
17.2.1 USIC Structure Overview

This section introduces the USIC structure.
17.2.1.1 Channel Structure

The USIC module contains two independent communication channels, with a structure
as shown in Figure 17-1.
The data shift unit and the data buffering of each channel support full-duplex data
transfers. The protocol-specific actions are handled by the protocol pre-processors
(PPP). In order to simplify data handling, an additional FIFO data buffer is optionally
available for each USIC module to store transmit and receive data for each channel.
Due to the independent channel control and baud rate generation, the communication
protocol, baud rate and the data format can be independently programmed for each
communication channel.
17.2.1.2 Input Stages

For each protocol, the number of input signals used depends on the selected protocol.
Each input signal is handled by an input stage (called DXn, where n=0-5) for signal
conditioning, such as input selection, polarity control, or a digital input filter. They can be
classified according to their meaning for the protocols, see Table 17-1.
The inputs marked as optional are not needed for the standard function of a protocol
and may be used for enhancements. The descriptions of protocol-specific items are
given in the related protocol chapters. For the external frequency input, please refer to
the baud rate generator section, and for the transmit data validation, to the data handling
section.

XMC4500
XMC4000 Family
Table 17-1 Input Signals for Different Protocols

Selected Shift Data Input(s) Shift Clock Input Shift Control Input
Protocol (handled by DX0, (handled by DX1) (handled by DX2)
DX3, DX4 and DX5)1)
ASC, LIN RXD optional: optional:
external frequency transmit data validation
input or TXD collision
detection
Standard DIN0 optional: optional:
SSC, SPI (MRST, MISO) external frequency transmit data validation
(Master) input or delay or delay compensation
compensation
Standard DIN0 SCLKIN SELIN
SSC, SPI (MTSR, MOSI)
(Slave)
Dual- DIN[1:0] optional: optional:
SSC, SPI (MRST[1:0], external frequency transmit data validation
(Master) MISO[1:0]) input or delay or delay compensation
compensation
Dual- DIN[1:0] SCLKIN SELIN
SSC, SPI (MTSR[1:0],
(Slave) MOSI[1:0])
Quad- DIN[3:0] optional: optional:
SSC, SPI (MRST[3:0], external frequency transmit data validation
(Master) MISO[3:0]) input or delay or delay compensation
compensation
Quad- DIN[3:0] SCLKIN SELIN
SSC, SPI (MTSR[3:0],
(Slave) MOSI[3:0])
IIC SDA SCL optional:
transmit data validation
IIS DIN0 optional: optional:
(Master) external frequency transmit data validation
input or delay or delay compensation
compensation
IIS DIN0 SCLKIN WAIN
(Slave)
1) ASC, IIC, IIS and standard SSC protocols use only DX0 as the shift data input.

XMC4500
XMC4000 Family
Note: To allow a certain flexibility in assigning required USIC input functions to port pins
of the device, each input stage can select the desired input location among several
possibilities.
The available USIC signals and their port locations are listed in the interconnects
section, see Page 17-225.
17.2.1.3 Output Signals

For each protocol, up to 14 protocol-related output signals are available. The number of
actually used outputs depends on the selected protocol. They can be classified
according to their meaning for the protocols, see Table 17-2.
The outputs marked as optional are not needed for the standard function of a protocol
and may be used for enhancements. The descriptions of protocol-specific items are
given in the related protocol chapters. The MCLKOUT output signal has a stable
frequency relation to the shift clock output (the frequency of MCLKOUT can be higher
than for SCLKOUT) for synchronization purposes of a slave device to a master device.
If the baud rate generator is not needed for a specific protocol (e.g. in SSC slave mode),
the SCLKOUT and MCLKOUT signals can be used as clock outputs with 50% duty cycle
with a frequency that can be independent from the communication baud rate.
Table 17-2 Output Signals for Different Protocols

Selected Shift Data Shift Clock Shift Control Master Clock
Protocol Output(s) Output Outputs Output
DOUT[3:0] SCLKOUT SELO[7:0] MCLKOUT
ASC, LIN TXD not used not used optional:
master time base
Standard DOUT0 master shift clock slave select, optional:
SSC, SPI (MTSR, MOSI) chip select master time base
(Master)
Standard DOUT0 optional: not used optional:
SSC, SPI (MRST, MISO) independent independent
(Slave) clock output clock output
Dual- DOUT[1:0] master shift clock slave select, optional:
SSC, SPI (MTSR[1:0], chip select master time base
(Master) MOSI[1:0])
Dual- DOUT[1:0] optional: not used optional:
SSC, SPI (MRST[1:0], independent independent
(Slave) MISO[1:0]) clock output clock output

XMC4500
XMC4000 Family
Table 17-2 Output Signals for Different Protocols (contd)

Selected Shift Data Shift Clock Shift Control Master Clock
Protocol Output(s) Output Outputs Output
DOUT[3:0] SCLKOUT SELO[7:0] MCLKOUT
Quad- DOUT[3:0] master shift clock slave select, optional:
SSC, SPI (MTSR[3:0], chip select master time base
(Master) MOSI[3:0])
Quad- DOUT[3:0] optional: not used optional:
SSC, SPI (MRST[3:0], independent independent
(Slave) MISO[3:0]) clock output clock output
IIC SDA SCL not used optional:
master time base
IIS DOUT0 master shift clock WA optional:
(master) master time base
IIS DOUT0 optional: not used optional:
(slave) independent independent
clock output clock output
Note: To allow a certain flexibility in assigning required USIC output functions to port
pins of the device, most output signals are made available on several port pins.
The port control itself defines pin-by-pin which signal is used as output signal for
a port pin (see port chapter).
The available USIC signals and their port locations are listed in the interconnects
section, see Page 17-225.
17.2.1.4 Baud Rate Generator

Each USIC Channel contains a baud rate generator structured as shown in Figure 17-2.
It is based on coupled divider stages, providing the frequencies needed for the different
protocols. It contains:
A fractional divider to generate the input frequency fPIN = fFD for baud rate generation
based on the internal system frequency fPB.
The DX1 input to generate the input frequency fPIN = fDX1 for baud rate generation
based on an external signal.
Two protocol-related counters: the divider mode counter to provide the master clock
signal MCLK, the shift clock signal SCLK, and other protocol-related signals; and the
capture mode timer for time interval measurement, e.g. baud rate detection.
A time quanta counter associated to the protocol pre-processor defining protocol-
specific timings, such shift control signals or bit timings, based on the input frequency
fCTQIN.

XMC4500
XMC4000 Family
The output signals MCLKOUT and SCLKOUT of the protocol-related divider that can
be made available on pins. In order to adapt to different applications, some output
characteristics of these signals can be configured.
For device-specific details about availability of USIC signals on pins please refer to
the interconnects section.
BRG
DX1 CLKSEL fCTQIN Protocol
Input Pre-Processor
2
Enable
fD X1
fPIN Protocol
SCLK Output
Related SCLKOUT
fFD Configration
Counter s
Enable
fPB Fractional Output
MCLK
Divider Configration MCLKOUT
Figure 17-2 Baud Rate Generator
17.2.1.5 Channel Events and Interrupts

The notification of the user about events occurring during data traffic and data handling
is based on:
Data transfer events related to the transmission or reception of a data word,
independent of the selected protocol.
Protocol-specific events depending on the selected protocol.
Data buffer events related to data handling by the optional FIFO data buffers.
17.2.1.6 Data Shifting and Handling

The data handling of the USIC module is based on an independent data shift unit (DSU)
and a buffer structure that is similar for the supported protocols. The data shift and buffer
registers are 16-bit wide (maximum data word length), but several data words can be
concatenated to achieve longer data frames. The DSU inputs are the shift data (handled
by input stage DX0, DX3, DX4 and DX5), the shift clock (handled by the input stage
DX1), and the shift control (handled by the input stage DX2). The signal DOUT[3:0]
represents the shift data outputs.

XMC4500
XMC4000 Family
Optional Transmit Basic Data Buffer Shift Data Input(s)

Data Buffer DX0,
BYP DX[5:3]
Bypass 4 Inputs
Bypass Data
INx TBUF TSR s Shift Data Output(s)
Out
FIFO
In
Buffered
User Interface
Transmit Data DOUT[3:0]

Data 4
TBUFx
Shift
Transmit Data Unit Shift Clock Input
Optional Receive (DSU)

DX1
Data Buffer Input
OUTR RBUF0 RSR0[3:0]
Shift Control Input
Out
FIFO
In
Buffered
Receive Data RBUF1 RSR1[3:0] DX2
RBUF Input
Receive Data
Figure 17-3 Principle of Data Buffering

The principle of data handling comprises:
A transmitter with transmit shift registers (TSR and TSR[3:0]) in the DSU and a
transmit data buffer (TBUF). A data validation scheme allows triggering and gating of
data transfers by external events under certain conditions.
A receiver with two alternating sets of receive shift registers (RSR0[3:0] and
RSR1[3:0]) in the DSU and a double receive buffer structure (RBUF0, RBUF1). The
alternating receive shift registers support the reception of data streams and data
frames longer than one data word.
Optional transmit and receive data buffers according to the first-in-first-out principle
(FIFO), that are not necessarily available in all devices. For device-specific details
about availability of the FIFO buffer please refer to the USIC implementation chapter.
A user interface to handle data, interrupts, and status and control information.
Basic Data Buffer Structure

The read access to received data and the write access of data to be transmitted can be
handled by a basic data buffer structure.
The received data stored in the receiver buffers RBUF0/RBUF1 can be read directly from
these registers. In this case, the user has to take care about the reception sequence to
read these registers in the correct order. To simplify the use of the receive buffer
structure, register RBUF has been introduced. A read action from this register delivers
the data word received first (oldest data) to respect the reception sequence. With a read
access from at least the low byte of RBUF, the data is automatically declared to be no

XMC4500
XMC4000 Family
longer new and the next received data word becomes visible in RBUF and can be read
out next.
Control Info TCI RBUF01SR RBUF01SR

TBUF RBUF0 RBUF1
5 16
Location Data
TBUF31 DS
.
.
.
.
TBUF01 RBUFSR
TBUF00 RBUF RBUF
Mirror
Data Write Access Data Read Access Debug Read Access
Figure 17-4 Data Access Structure without additional Data Buffer

It is recommended to read the received data words by accesses to RBUF and to avoid
handling of RBUF0 and RBUF1. The USIC module also supports the use of debug
accesses to receive data words. Debugger read accesses should not disturb the receive
data sequence and, as a consequence, should not target RBUF. Therefore, register
RBUFD has been introduced. It contains the same value as RBUF, but a read access
from RBUFD does not change the status of the data (same data can be read several
times). In addition to the received data, some additional status information about each
received data word is available in the receiver buffer status register RBUF01SR (related
to data in RBUF0 and RBUF1) and RBUFSR (related to data in RBUF).
Transmit data can be loaded to TBUF by software by writing to the transmit buffer input
locations TBUFx (x = 00-31), consisting of 32 consecutive addresses. The data written
to one of these input locations is stored in the transmit buffer TBUF. Additionally, the
address of the written location is evaluated and can be used for additional control
purposes. This 5-bit wide information (named Transmit Control Information TCI) can be
used for different purposes in different protocols.
FIFO Buffer Structure

To allow easier data setup and handling, an additional data buffering mechanism can be
optionally supported. The data buffer is based on the first-in-first-out principle (FIFO) that
ensures that the sequence of transferred data words is respected.

XMC4500
XMC4000 Family
If a FIFO buffer structure is used, the data handling scheme (data with associated control
information) is similar to the one without FIFO. The additional FIFO buffer can be
independently enabled/disabled for transmission and reception (e.g. if data FIFO buffers
are available for a specific USIC channel, it is possible to configure the transmit data path
without and the receive data path with FIFO buffering).
The transmit FIFO buffer is addressed by using 32 consecutive address locations for INx
instead of TBUFx (x=00-31) regardless of the FIFO depth. The 32 addresses are used
to store the 5-bit TCI (together with the written data) associated with each FIFO entry.
The receive FIFO can be read out at two independent addresses, OUTR and OUTDR
instead of RBUF and RBUFD. A read from the OUTR location triggers the next data
packet to be available for the next read (general FIFO mechanism). In order to allow non-
intrusive debugging (without risk of data loss), a second address location (OUTDR) has
been introduced. A read at this location delivers the same value as OUTR, but without
modifying the FIFO contents.
The transmit FIFO also has the capability to bypass the data stream and to load bypass
data to TBUF. This can be used to generate high-priority messages or to send an
emergency message if the transmit FIFO runs empty. The transmission control of the
FIFO buffer can also use the transfer trigger and transfer gating scheme of the
transmission logic for data validation (e.g. to trigger data transfers by events).
Note: The available size of a FIFO data buffer for a USIC channel depends on the
specific device. Please refer to the implementation chapter for details about
available FIFO buffer capability.

XMC4500
XMC4000 Family
Control Info TCI RBUF01SR RBUF01SR

TBUF RBUF0 RBUF1
Transmit FIFO Receive FIFO
5-bit 16-bit
TCI=
IN31 11111 TX Data
.
.
.
.
TCI=
IN01 00001 TX Data OUTR OUTDR
Mirror
TCI=
IN00 00000 TX Data OUTR OUTDR
Data Write Access Data Read Access Debug Read Access
Figure 17-5 Data Access Structure with FIFO
17.2.2 Operating the USIC Communication Channel

This section describes how to operate a USIC communication channel, including
protocol control and status, mode control and interrupt handling. The following aspects
have to be taken into account:
Enable the USIC module for operation and configure the behavior for the different
device operation modes (see Page 17-15).
Configure the pinning (refer to description in the corresponding protocol section).
Configure the data structure (shift direction, word length, frame length, polarity, etc.).
Configure the data buffer structure of the optional FIFO buffer area. A FIFO buffer
can only be enabled if the related bit in register CCFG is set.
Select a protocol by CCR.MODE. A protocol can only be selected if the related bit in
register CCFG is set.

XMC4500
XMC4000 Family
17.2.2.1 Protocol Control and Status

The protocol-related control and status information are located in the protocol control
register PCR and in the protocol status register PSR. These registers are shared
between the available protocols. As a consequence, the meaning of the bit positions in
these registers is different within the protocols.
Use of PCR Bits

The signification of the bits in register PCR is indicated by the protocol-related alias
names for the different protocols.
PCR for the ASC protocol (see Page 17-64)
PCR for the SSC protocol (see Page 17-96)
PCR for the IIC protocol (see Page 17-127)
PCR for the IIS protocol (see Page 17-145)
Use of PSR Flags

The signification of the flags in register PSR is indicated by the protocol-related alias
names for the different protocols.
PSR flags for the ASC protocol (see Page 17-68)
PSR flags for the SSC protocol (see Page 17-100)
PSR flags for the IIC protocol (see Page 17-130)
PSR flags for the IIS protocol (see Page 17-147)

XMC4500
XMC4000 Family
17.2.2.2 Mode Control

The mode control concept for system control tasks, such as suspend request for
debugging, allows to program the module behavior under different device operating
conditions. The behavior of a communication channel can be programmed for each of
the device operating modes (normal operation, suspend mode). Therefore, each
communication channel has an associated kernel state configuration register KSCFG
defining its behavior in the following operating modes:
Normal operation:
This operating mode is the default operating mode when no suspend request is
pending. The module clock is not switched off and the USIC registers can be read or
written. The channel behavior is defined by KSCFG.NOMCFG.
Suspend mode:
This operating mode is requested when a suspend request is pending in the device.
The module clock is not switched off and the USIC registers can be read or written.
The channel behavior is defined by KSCFG.SUMCFG.
The four kernel modes defined by the register KSCFG are shown in Table 17-3.
Table 17-3 USIC Communication Channel Behavior

Kernel Mode Channel Behavior KSCFG.
NOMCFG
Run mode 0 Channel operation as specified, no impact on data transfer 00B
Run mode 1 01B
Stop mode 0 Explicit stop condition as described in the protocol chapters 10B
Stop mode 1 11B
Generally, bit field KSCFG.NOMCFG should be configured for run mode 0 as default
setting for standard operation. If a communication channel should not react to a suspend
request (and to continue its operation as in normal mode), bit field KSCFG.SUMCFG has
to be configured with the same value as KSCFG.NOMCFG. If the communication
channel should show a different behavior and stop operation when a specific stop
condition is reached, the code for stop mode 0 or stop mode 1 have to be written to
KSCFG.SUMCFG.
The stop conditions are defined for the selected protocol (see mode control description
in the protocol section).
Note: The stop mode selection strongly depends on the application needs and it is very
unlikely that different stop modes are required in parallel in the same application.
As a result, only one stop mode type (either 0 or 1) should be used in the bit fields
in register KSCFG. Do not mix stop mode 0 and stop mode 1 and avoid transitions

XMC4500
XMC4000 Family
from stop mode 0 to stop mode 1 (or vice versa) for the same communication
channel.
17.2.2.3 General Channel Events and Interrupts

The general event and interrupt structure is shown in Figure 17-6. If a defined condition
is met, an event is detected and an event indication flag becomes automatically set. The
flag stays set until it is cleared by software. If enabled, an interrupt can be generated if
an event is detected. The actual status of the event indication flag has no influence on
the interrupt generation. As a consequence, the event indication flag does not need to
be cleared to generate further interrupts.
Additionally, the service request output SRx of the USIC channel that becomes activated
in case of an event condition can be selected by an interrupt node pointer. This structure
allows to assign events to interrupts, e.g. depending on the application, several events
can share the same interrupt routine (several events activate the same SRx output) or
can be handled individually (only one event activates one SRx output).
The SRx outputs are connected to interrupt control registers to handle the CPU reaction
to the service requests. This assignment is described in the implementation section on
Page 17-151.
Clear Event Clear Event

Indication Indication Interrupt Interrupt
Enable Node Pointer
Flag Flag
Set 2
To SR0
Event Condition .
.
..
. .
is met
To SR5
Figure 17-6 General Event and Interrupt Structure

XMC4500
XMC4000 Family
17.2.2.4 Data Transfer Events and Interrupts

The data transfer events are based on the transmission or reception of a data word. The
related indication flags are located in register PSR. All events can be individually enabled
for interrupt generation.
Receive event to indicate that a data word has been received:
If a new received word becomes available in the receive buffer RBUF, either a
receive event or an alternative receive event occurs.
The receive event occurs if bit RBUFSR.PERR = 0. It is indicated by flag PSR.RIF
and, if enabled, leads to receive interrupt.
Receiver start event to indicate that a data word reception has started:
When the receive clock edge that shifts in the first bit of a new data word is detected
and reception is enabled, a receiver start event occurs. It is indicated by flag
PSR.RSIF and, if enabled, leads to transmit buffer interrupt.
In full duplex mode, this event follows half a shift clock cycle after the transmit buffer
event and indicates when the shift control settings are internally frozen for the
current data word reception and a new setting can be programmed.
In SSC and IIS mode, the transmit data valid flag TCSR.TDV is cleared in single shot
mode with the receiver start event.
Alternative receive event to indicate that a specific data word has been received:
If a new received word becomes available in the receive buffer RBUF, either a
receive event or an alternative receive event occurs.
The alternative receive event occurs if bit RBUFSR.PERR = 1. It is indicated by flag
PSR.AIF and, if enabled, leads to alternative receive interrupt.
Depending on the selected protocol, bit RBUFSR.PERR is set to indicate a parity
error in ASC mode, the reception of the first byte of a new frame in IIC mode, and the
WA information about right/left channel in IIS mode. In SSC mode, it is used as
indication if the received word is the first data word, and is set if first and reset if not.
Transmit shift event to indicate that a data word has been transmitted:
A transmit shift event occurs with the last shift clock edge of a data word. It is
indicated by flag PSR.TSIF and, if enabled, leads to transmit shift interrupt.
Transmit buffer event to indicate that a data word transmission has been started:
When a data word from the transmit buffer TBUF has been loaded to the shift register
and a new data word can be written to TBUF, a transmit buffer event occurs. This
happens with the transmit clock edge that shifts out the first bit of a new data word
and transmission is enabled. It is indicated by flag PSR.TBIF and, if enabled, leads
to transmit buffer interrupt.
This event also indicates when the shift control settings (word length, shift direction,
etc.) are internally frozen for the current data word transmission.
In ASC and IIC mode, the transmit data valid flag TCSR.TDV is cleared in single shot
mode with the transmit buffer event.
Data lost event to indicate a loss of the oldest received data word:
If the data word available in register RBUF (oldest data word from RBUF0 or RBUF1)

XMC4500
XMC4000 Family
has not been read out before it becomes overwritten with new incoming data, this
event occurs. It is indicated by flag PSR.DLIF and, if enabled, leads to a protocol
interrupt.
Table 17-4 shows the registers, bits and bit fields indicating the data transfer events and
controlling the interrupts of a USIC channel.
Table 17-4 Data Transfer Events and Interrupt Handling

Event Indication Indication Interrupt SRx Output
Flag cleared by enabled by selected by
Standard receive event PSR.RIF PSCR.CRIF CCR.RIEN INPR.RINP
Receive start event PSR.RSIF PSCR.CRSIF CCR.RSIEN INPR.TBINP
Alternative receive event PSR.AIF PSCR.CAIF CCR.AIEN INPR.AINP
Transmit shift event PSR.TSIF PSCR.CTSIF CCR.TSIEN INPR.TSINP
Transmit buffer event PSR.TBIF PSCR.CTBIF CCR.TBIEN INPR.TBINP
Data lost event PSR.DLIF PSCR.CDLIF CCR.DLIEN INPR.PINP
Figure 17-7 shows the two transmit events and interrupts.
PSCR PSR CCR INPR

Clear
CTSIF TSIF TSIEN TSINP
Set 2
Transmit Shift
Interrupt ..
SR0
.
Transmit Shift .
.
.
Event SR5
(End of last transmit
shift clock period of
data word)
PSCR PSR CCR INPR
Clear
CTBIF TBIF TBIEN TBINP
Set 2
Transmit Buffer
Interrupt .
SR0
.
Transmit Buffer .
.
.
.
Event SR5
(First transmit shift
clock of data word)
Figure 17-7 Transmit Events and Interrupts

XMC4500
XMC4000 Family
Figure 17-8 shows the receive events and interrupts.
RBUFSR PSCR PSR CCR INPR

Clear
PERR CRIF RIF RIEN RINP
Set 2
Standard Standard
SR0
Receive Event Receive Interrupt .. ..
. .
SR5
New Data in 0
RBUF Event 1
Alternate Alternate SR0
Receive Event Receive Interrupt .
.
.
.
. .
SR5
Set
2
Clear
CAIF AIF AIEN AINP
PSCR PSR CCR INPR
PSCR PSR CCR INPR

Clear
CRSIF RSIF RSIEN TBINP
Set 2
Receive Start SR0
Receive Start Interrupt .
.
.
.
. .
Event SR5
(First receive shift
clock of data world)
PSCR PSR CCR INPR

Clear
CDLIF DLIF DLIEN PINP
Set 2
Data Lost
Interrupt .
SR0
.
. .
Data Lost Event . .
(RBUF becomes SR5
overwritten without
having been read out)
Figure 17-8 Receive Events and Interrupts
17.2.2.5 Baud Rate Generator Event and Interrupt

The baud rate generator event is based on the capture mode timer reaching its
maximum value. It is indicated by flag PSR.BRGIF and, if enabled, leads to a protocol
interrupt.

XMC4500
XMC4000 Family
Table 17-5 shows the registers, bits and bit fields indicating the baud rate generator
event and controlling the interrupt of a USIC channel.
Table 17-5 Baud Rate Generator Event and Interrupt Handling

Baud rate generator event PSR. PSCR. CCR. INPR.PINP
BRGIF CBRGIF BRGIEN
Figure 17-9 shows the baud rate generator event and interrupt.
PSCR PSR CCR INPR

Clear
CBRGIF BRGIF BRGIEN PINP
Baud Rate 2
Set
Generator SR0
Baud Rate Interrupt .. .
.
. .
Generator Event SR5
(Capture mode timer
reaches its maximum value)
Figure 17-9 Baud Rate Generator Event and Interrupt

XMC4500
XMC4000 Family
17.2.2.6 Protocol-specific Events and Interrupts

These events are related to protocol-specific actions that are described in the
corresponding protocol chapters. The related indication flags are located in register
PSR. All events can be individually enabled for the generation of the common protocol
interrupt.
Protocol-specific events in ASC mode:
Synchronization break, data collision on the transmit line, receiver noise, format error
in stop bits, receiver frame finished, transmitter frame finished
Protocol-specific events in SSC mode:
MSLS event (start-end of frame in master mode), DX2T event (start/end of frame in
slave mode), both based on slave select signals, parity error
Protocol-specific events in IIC mode:
Wrong transmit code (error in frame sequence), start condition received, repeated
start condition received, stop condition received, non-acknowledge received,
arbitration lost, slave read request, other general errors
Protocol-specific events in IIS mode:
DX2T event (change on WA line), WA falling edge or rising edge detected, WA
generation finished
Table 17-6 Protocol-specific Events and Interrupt Handling

Event Indication Indication Interrupt enabled SRx Output
Flag cleared by by selected by
Protocol-specific PSR.ST[8:2] PSCR.CST[8:2] PCR.CTR[7:3]] INPR.PINP
events in
ASC mode
Protocol-specific PSR.ST[3:2] PSCR.CST[3:2] PCR.CTR[15:14] INPR.PINP
events in
SSC mode
Protocol-specific PSR.ST[8:1] PSCR.CST[8:1] PCR.CTR[24:18] INPR.PINP
events in
IIC mode
Protocol-specific PSR.ST[6:3] PSCR.CST[6:3] PCR.CTR[6:4], INPR.PINP
events in PCR.CTR[15]
IIS mode
17.2.3 Operating the Input Stages

All input stages offer the same feature set. They are used for all protocols, because the
signal conditioning can be adapted in a very flexible way and the digital filters can be
switched on and off separately.

XMC4500
XMC4000 Family
17.2.3.1 General Input Structure

There are generally two types of input stages, one for the data input stages DX0, DX[5:3]
and the other for non-data input stages DX[2:1], as shown in Figure 17-10 and
Figure 17-11. The difference is that for the data input stages, the input signal can be
additionally selected from the port signal HWINn if hardware port control is enabled
through CCR.HPCEN bit. All other enable/disable functions and selections are
controlled independently for each input stage by bits in the registers DXnCR.
The desired input signal can be selected among the input lines DXnA to DXnG and a
permanent 1-level by programming bit field DSEL (for the data input stages, hardware
port control must be disabled for DSEL to take effect). Please refer to the interconnects
section (Section 17.12) for the device-specific input signal assignment. Bit DPOL allows
a polarity inversion of the selected input signal to adapt the input signal polarity to the
internal polarity of the data shift unit and the protocol state machine. For some protocols,
the input signals can be directly forwarded to the data shift unit for the data transfers
(DSEN = 0, INSW = 1) without any further signal conditioning. In this case, the data path
does not contain any delay due to synchronization or filtering.
In the case of noise on the input signals, there is the possibility to synchronize the input
signal (signal DXnS is synchronized to fPB) and additionally to enable a digital noise filter
in the signal path. The synchronized input signal (and optionally filtered if DFEN = 1) is
taken into account by DSEN = 1. Please note that the synchronization leads to a delay
in the signal path of 2-3 times the period of fPB.
DXnCR
CCR DXnCR DXnCR DXnCR
DSEL
HPCEN DPOL DSEN INSW
DXnA 000
DXnB 001
0
...
...
0 0
1 1
DXnG 110 1 1 Data Shift Unit
1 111 0
HWINn DXnS
Protocol
Pre-Processor
Digital Edge
Filter Detection
DXnINS
DXnT
DFEN CM
DXnCR DXnCR
Figure 17-10 Input Conditioning for DX0 and DX[5:3]

XMC4500
XMC4000 Family
DXnCR DXnCR DXnCR DXnCR

DSEL DPOL DSEN INSW
DXnA 000
DXnB 001 0
0
...
...
1 1
1 Data Shift Unit
DXnG 110 0
1 111
DXnS Protocol
DXnINS Pre-Processor
Digital Edge
Filter Detection
DXnT
DFEN CM
DXnCR DXnCR
Figure 17-11 Input Conditioning for DX[2:1]

If the input signals are handled by a protocol pre-processor, the data shift unit is directly
connected to the protocol pre-processor by INSW = 0. The protocol pre-processor is
connected to the synchronized input signal DXnS and, depending on the selected
protocol, also evaluates the edges.
To support delay compensation in SSC and IIS protocols, the DX1 input stage
additionally allows the receive shift clock to be controlled independently from the transmit
shift clock through the bit DCEN. When DCEN = 0, the shift clock source is selected by
INSW and is the same for both receive and transmit. When DCEN = 1, the receive shift
clock is derived from the selected input line as shown in Figure 17-12.

XMC4500
XMC4000 Family
DX1CR DX1CR DX1CR

DSEN INSW DCEN
0 1 Receive shift
Similar to 1 clock (DSU)
0
structure of 1
0
DX2
1 Transmit shift
0 clock (DSU)
Signal from
Protocol
Pre-processor
Figure 17-12 Delay Compensation Enable in DX1
17.2.3.2 Digital Filter

The digital filter can be enabled to reduce noise on the input signals. Before being
filtered, the input signal becomes synchronized to fPB. If the filter is disabled, signal DXnS
corresponds to the synchronized input signal. If the filter is enabled, pulses shorter than
one filter sampling period are suppressed in signal DXnS. After an edge of the
synchronized input signal, signal DXnS changes to the new value if two consecutive
samples of the new value have been detected.
In order to adapt the filter sampling period to different applications, it can be
programmed. The first possibility is the system frequency fPB. Longer pulses can be
suppressed if the fractional divider output frequency fFD is selected. This frequency is
programmable in a wide range and can also be used to determine the baud rate of the
data transfers.
In addition to the synchronization delay of 2-3 periods of fPB, an enabled filter adds a
delay of up to two filter sampling periods between the selected input and signal DXnS.
17.2.3.3 Edge Detection

The synchronized (and optionally filtered) signal DXnS can be used as input to the data
shift unit and is also an input to the selected protocol pre-processor. If the protocol pre-
processor does not use the DXnS signal for protocol-specific handling, DXnS can be

XMC4500
XMC4000 Family
used for other tasks, e.g. to control data transmissions in master mode (a data word can
be tagged valid for transmission, see chapter about data buffering).
A programmable edge detection indicates that the desired event has occurred by
activating the trigger signal DXnT (introducing a delay of one period of fPB before a
reaction to this event can take place).
17.2.3.4 Selected Input Monitoring

The selected input signal of each input stage has been made available with the signals
DXnINS. These signals can be used in the system to trigger other actions, e.g. to
generate interrupts.
17.2.3.5 Loop Back Mode

The USIC transmitter output signals can be connected to the corresponding receiver
inputs of the same communication channel in loop back mode. Therefore, the input G
of the input stages that are needed for the selected protocol have to be selected. In this
case, drivers for ASC, SSC, and IIS can be evaluated on-chip without the connections
to port pins. Data transferred by the transmitter can be received by the receiver as if it
would have been sent by another communication partner.
17.2.4 Operating the Baud Rate Generator

The following blocks can be configured to operate the baud rate generator, see also
Figure 17-2.
17.2.4.1 Fractional Divider

The fractional divider generates its output frequency fFD by either dividing the input
frequency fPB by an integer factor n or by multiplication of n/1024. It has two operating
modes:
Normal divider mode (FDR.DM = 01B):
In this mode, the output frequency fFD is derived from the input clock fPB by an integer
division by a value between 1 and 1024. The division is based on a counter
FDR.RESULT that is incremented by 1 with fPB. After reaching the value 3FFH, the
counter is loaded with FDR.STEP and then continues counting. In order to achieve
fFD = fPB, the value of STEP has to be programmed with 3FFH.
The output frequency in normal divider mode is defined by the equation:
fFD = fPB 1 with n = 1024 - STEP (17.1)

n
Fractional divider mode (FDR.DM = 10B):

In this mode, the output frequency fFD is derived from the input clock fPB by a

XMC4500
XMC4000 Family
fractional multiplication of n/1024 for a value of n between 0 and 1023. In general, the
fractional divider mode allows to program the average output clock frequency with a
finer granularity than in normal divider mode. Please note that in fractional divider
mode fFD can have a maximum period jitter of one fPB period. This jitter is not
accumulated over several cycles.
The frequency fFD is generated by an addition of FDR.STEP to FDR.RESULT with
fPB. The frequency fFD is based on the overflow of the addition result over 3FFH.
The output frequency in fractional divider mode is defined by the equation:
n
fFD = fPB with n = STEP (17.2)
1024
The output frequency fFD of the fractional divider is selected for baud rate generation by
BRG.CLKSEL = 00B.
17.2.4.2 External Frequency Input

The baud rate can be generated referring to an external frequency input (instead of to
fPB) if in the selected protocol the input stage DX1 is not needed (DX1CTR.INSW = 0).
In this case, an external frequency input signal at the DX1 input stage can be
synchronized and sampled with the system frequency fPB. It can be optionally filtered by
the digital filter in the input stage. This feature allows data transfers with frequencies that
can not be generated by the device itself, e.g. for specific audio frequencies.
If BRG.CLKSEL = 10B, the trigger signal DX1T determines fDX1. In this mode, either the
rising edge, the falling edge, or both edges of the input signal can be used for baud rate
generation, depending on the configuration of the DX1T trigger event by bit field
DX1CTR.CM. The signal MCLK toggles with each trigger event of DX1T.
If BRG.CLKSEL = 11B, the rising edges of the input signal can be used for baud rate
generation. The signal MCLK represents the synchronized input signal DX1S.
Both, the high time and the low time of external input signal must each have a length of
minimum 2 periods of fPB to be used for baud rate generation.
17.2.4.3 Divider Mode Counter

The divider mode counter is used for an integer division delivering the output frequency
fPDIV. Additionally, two divider stages with a fixed division by 2 provide the output signals
MCLK and SCLK with 50% duty cycle. If the fractional divider mode is used, the
maximum fractional jitter of 1 period of fPB can also appear in these signals. The output
frequencies of this divider is controlled by register BRG.

XMC4500
XMC4000 Family
In order to define a frequency ratio between the master clock MCLK and the shift clock
SCLK, the divider stage for MCLK is located in front of the divider by PDIV+1, whereas
the divider stage for SCLK is located at the output of this divider.
fPIN
fMCLK = (17.3)
2
fPDIV
fSCLK = (17.4)
2
In the case that the master clock is used as reference for external devices (e.g. for IIS
components) and a fixed phase relation to SCLK and other timing signals is required, it
is recommended to use the MCLK signal as input for the PDIV divider. If the MCLK signal
is not used or a fixed phase relation is not necessary, the faster frequency fPIN can be
selected as input frequency.
1
fPDIV = fPIN if PPPEN = 0
PDIV + 1
(17.5)
1
fPDIV = fMCLK if PPPEN = 1
PDIV + 1
11
10
fCTQIN
01
00
Divide 0 Divide by Divide SCLK

fPIN by 2 1 fPPP PDIV + 1 fPDIV by 2 fSC LK
fMCLK
MCLK
PPPEN CTQSEL
BRG BRG
Figure 17-13 Divider Mode Counter
17.2.4.4 Capture Mode Timer

The capture mode timer is used for time interval measurement and is enabled by
BRG.TMEN = 1. The timer works independently from the divider mode counter.
Therefore, any serial data reception or transmission can continue while the timer is
performing timing measurements. The timer counts fPPP periods and stops counting

XMC4500
XMC4000 Family
when it reaches its maximum value. Additionally, a baud rate generator interrupt event
is generated (bit PSR.BRGIF becomes set).
If an event is indicated by DX0T or DX1T, the actual timer value is captured into bit field
CMTR.CTV and the timer restarts from 0. Additionally, a transmit shift interrupt event is
generated (bit PSR.TSIF becomes set).
DX0T 1
DX1T
Clear Capture
Divide 0
Up-Counter Capture in
fPIN by 2 1 fPPP CTV
fMC L K
MCLK
PPPEN TMEN = 1
BRG BRG
Figure 17-14 Protocol-Related Counter (Capture Mode)

The capture mode timer can be used to measure the baud rate in slave mode before
starting or during data transfers, e.g. to measure the time between two edges of a data
signal (by DX0T) or of a shift clock signal (by DX1T). The conditions to activate the DXnT
trigger signals can be configured in each input stage.
17.2.4.5 Time Quanta Counter

The time quanta counter CTQ associated to the protocol pre-processor allows to
generate time intervals for protocol-specific purposes. The length of a time quantum tq is
given by the selected input frequency fCTQIN and the programmed pre-divider value.
The meaning of the time quanta depend on the selected protocol, please refer to the
corresponding chapters for more protocol-specific information.
tq Time Quanta Protocol

fC TQIN Pre-Divider
Counter CTQ Pre-Processor
PCTQ DCTQ
BRG BRG
Figure 17-15 Time Quanta Counter

XMC4500
XMC4000 Family
17.2.4.6 Master and Shift Clock Output Configuration

The master clock output signal MCLKOUT available at the corresponding output pin can
be configured in polarity. The MCLK signal can be generated for each protocol in order
to provide a kind of higher frequency time base compared to the shift clock.
The configuration mechanism of the master clock output signal MCLKOUT ensures that
no shortened pulses can occur. Each MCLK period consists of two phases, an active
phase, followed by a passive phase. The polarity of the MCLKOUT signal during the
active phase is defined by the inverted level of bit BRG.MCLKCFG, evaluated at the start
of the active phase. The polarity of the MCLKOUT signal during the passive phase is
defined by bit BRG.MCLKCFG, evaluated at the start of the passive phase. If bit
BRG.MCLKOUT is programmed with another value, the change is taken into account
with the next change between the phases. This mechanism ensures that no shorter
pulses than the length of a phase occur at the MCLKOUT output. In the example shown
in Figure 17-16, the value of BRG.MCLKCFG is changed from 0 to 1 during the passive
phase of MCLK period 2.
The generation of the MCLKOUT signal is enabled/disabled by the protocol pre-
processor, based on bit PCR.MCLK. After this bit has become set, signal MCLKOUT is
generated with the next active phase of the MCLK period. If PCR.MCLK = 0 (MCLKOUT
generation disabled), the level for the passive phase is also applied for active phase.
MCLK Period 1 MCLK Period 2 MCLK Period 3 MCLK Period 4
MCLKOUT
Active Passive Active Passive Active Passive Active Passive

Phase Phase Phase Phase Phase Phase Phase Phase
Bit BRG. 0 1
MCLKCFG
Figure 17-16 Master Clock Output Configuration

The shift clock output signal SCLKOUT available at the corresponding output pin can be
configured in polarity and additionally, a delay of one period of fPDIV (= half SCLK period)
can be introduced. The delay allows to adapt the order of the shift clock edges to the
application requirements. If the delay is used, it has to be taken into account for the
calculation of the signal propagation times and loop delays.
The mechanism for the polarity control of the SCLKOUT signal is similar to the one for
MCLKOUT, but based on bit field BRG.SCLKCFG. The generation of the SCLKOUT

XMC4500
XMC4000 Family
signal is enabled/disabled by the protocol pre-processor. Depending on the selected

protocol, the protocol pre-processor can control the generation of the SCLKOUT signal
independently of the divider chain, e.g. for protocols without the need of a shift clock
available at a pin, the SCLKOUT generation is disabled.
17.2.5 Operating the Transmit Data Path

The transmit data path is based on 16-bit wide transmit shift registers (TSR and
TSR[3:0]) and a transmit buffer TBUF. The data transfer parameters like data word
length, data frame length, or the shift direction are controlled commonly for transmission
and reception by the shift control register SCTR. The transmit control and status register
TCSR controls the transmit data handling and monitors the transmit status.
A change of the value of the data shift output signal DOUTx only happens at the
corresponding edge of the shift clock input signal. The level of the last data bit of a data
word/frame is held constant at DOUTx until the next data word begins with the next
corresponding edge of the shift clock.
17.2.5.1 Transmit Buffering

The transmit shift registers can not be directly accessed by software, because they are
automatically updated with the value stored in the transmit buffer TBUF if a currently
transmitted data word is finished and new data is valid for transmission. Data words can
be loaded directly into TBUF by writing to one of the transmit buffer input locations
TBUFx (see Page 17-32) or, optionally, by a FIFO buffer stage (see Page 17-38).

XMC4500
XMC4000 Family
Shift Clock Domain

Shift Data Output 3 TSR3
TSR0
Shift Data Output 0
8 8 4 4
Shift Clock Domain TSR
Control 16 16
Shift Clock Input Shift and Status
Control & of TSR
Shift Control Input Status 16
Data
TCSR SCTR TBUF
Transmit
Control
Optional TBUFx
FIFO
System Clock Domain
Figure 17-17 Transmit Data Path
17.2.5.2 Transmit Data Shift Mode

The transmit shift data can be selected to be shifted out one, two or four bits at a time
through the corresponding number of output lines. This option allows the USIC to
support protocols such as the Dual- and Quad-SSC. The selection is done through the
bit field DSM in the shift control register SCTR.
Note: The bit field SCTR.DSM controls the data shift mode for both the transmit and
receive paths to allow the transmission and reception of data through one to four
data lines.
For the shift mode with two or four parallel data outputs, the data word and frame length
must be in multiples of two or four respectively. The number of data shifts required to
output a specific data word or data frame length is thus reduced by the factor of the
number of parallel data output lines. For example, to transmit a 16-bit data word through
four output lines, only four shifts are required.

XMC4500
XMC4000 Family
Depending on the shift mode, different transmit shift registers with different bit
composition are used as shown in Table 17-7. Note that the n in the table denotes the
shift number less one, i.e. for the first data shift n = 0, the second data shift n = 1 and
continues until the total number of shifts less one is reached.
For all transmit shift registers, whether the first bit shifted out is the MSB or LSB depends
on the setting of SCTR.SDIR.
Table 17-7 Transmit Shift Register Composition

Transmit Shift Single Data Output Two Data Outputs Four Data Outputs
Registers (SCTR.DSM = 00B) (SCTR.DSM = 10B) (SCTR.DSM = 11B)
TSR All data bits Not used Not used
TSR0 Not used Bit n*2 Bit n*4
TSR1 Not used Bit n*2 + 1 Bit n*4 + 1
TSR2 Not used Not used Bit n*4 + 2
TSR3 Not used Not used Bit n*4 + 3
17.2.5.3 Transmit Control Information

The transmit control information TCI is a 5-bit value derived from the address x of the
written TBUFx or INx input location. For example, writing to TBUF31 generates a TCI of
11111B.
The TCI can be used as an additional control parameter for data transfers to dynamically
change the data word length, the data frame length, or other protocol-specific functions
(for more details about this topic, please refer to the corresponding protocol chapters).
The way how the TCI is used in different applications can be programmed by the bits
WLEMD, FLEMD, SELMD, WAMD and HPCMD in register TCSR. Please note that not
all possible settings lead to useful system behavior.
Word length control:
If TCSR.WLEMD = 1, bit field SCTR.WLE is updated with TCI[3:0] if a transmit buffer
input location TBUFx is written. This function can be used in all protocols to
dynamically change the data word length between 1 and 16 data bits per data word.
Additionally, bit TCSR.EOF is updated with TCI[4]. This function can be used in SSC
master mode to control the slave select generation to finish data frames. It is
recommended to program TCSR.FLEMD = TCSR.SELMD = TCSR.WAMD =
TCSR.HPCMD = 0.
Frame length control:
If TCSR.FLEMD = 1, bit field SCTR.FLE[4:0] is updated with TCI[4:0] and
SCTR.FLE[5] becomes 0 if a transmit buffer input location TBUFx is written. This
function can be used in all protocols to dynamically change the data frame length

XMC4500
XMC4000 Family
between 1 and 32 data bits per data frame. It is recommended to program

TCSR.SELMD = TCSR.WLEMD = TCSR.WAMD = TCSR.HPCMD = 0.
Select output control:
If TCSR.SELMD = 1, bit field PCR.CTR[20:16] is updated with TCI[4:0] and
PCR.CTR[23:21] becomes 0 if a transmit buffer input location TBUFx is written. This
function can be used in SSC master mode to define the targeted slave device(s). It
is recommended to program TCSR.WLEMD = TCSR.FLEMD = TCSR.WAMD =
TCSR.HPCMD = 0.
Word address control:
If TCSR.WAMD = 1, bit TCSR.WA is updated with TCI[4] if a transmit buffer input
location TBUFx is written. This function can be used in IIS mode to define if the data
word is transmitted on the right or the left channel. It is recommended to program
TCSR.WLEMD = TCSR.FLEMD = TCSR.SELMD = TCSR.HPCMD = 0.
Hardware Port control:
If TCSR.HPCMD = 1, bit field SCTR.DSM is updated with TCI[1:0] if a transmit buffer
input location TBUFx is written. This function can be used in SSC protocols to
dynamically change the number of data input and output lines to set up for standard,
dual and quad SSC formats.
Additionally, bit TCSR.HPCDIR is updated with TCI[2]. This function can be used in
SSC protocols to control the pin(s) direction when the hardware port control function
is enabled through CCR.HPCEN = 1. It is recommended to program TCSR.FLEMD
= TCSR.WLEMD = TCSR.SELMD = TCSR.WAMD = 0.
17.2.5.4 Transmit Data Validation

The data word in the transmit buffer TBUF can be tagged valid or invalid for transmission
by bit TCSR.TDV (transmit data valid). A combination of data flow related and event
related criteria define whether the data word is considered valid for transmission. A data
validation logic checks the start conditions for each data word. Depending on the result
of the check, the transmit shift register is loaded with different values, according to the
following rules:
If a USIC channel is the communication master (it defines the start of each data word
transfer), a data word transfer can only be started with valid data in the transmit buffer
TBUF. In this case, the transmit shift register is loaded with the content of TBUF, that
is not changed due to this action.
If a USIC channel is a communication slave (it can not define the start itself, but has
to react), a data word transfer requested by the communication master has to be
started independently of the status of the data word in TBUF. If a data word transfer
is requested and started by the master, the transmit shift register is loaded at the first
corresponding shift clock edge either with the data word in TBUF (if it is valid for
transmission) or with the level defined by bit SCTR.PDL (if the content of TBUF has
not been valid at the transmission start). In both cases, the content of TBUF is not
changed.

XMC4500
XMC4000 Family
The control and status bits for the data validation are located in register TCSR. The data
validation is based on the logic blocks shown in Figure 17-18.
TCSR Data Shift Unit

DSU
TDVTR
TCSR
DX2T Transfer TE
Trigger TDV
Shift Control TBUF
Input DX2 Data
Transfer Validation
DX2S Gating
TDEN TDSSM
TCSR TCSR
Figure 17-18 Transmit Data Validation

A transfer gating logic enables or disables the data word transfer from TBUF under
software or under hardware control. If the input stage DX2 is not needed for data
shifting, signal DX2S can be used for gating purposes. The transfer gating logic is
controlled by bit field TCSR.TDEN.
A transfer trigger logic supports data word transfers related to events, e.g. timer
based or related to an input pin. If the input stage DX2 is not needed for data shifting,
signal DX2T can be used for trigger purposes. The transfer trigger logic is controlled
by bit TCSR.TDVTR and the occurrence of a trigger event is indicated by bit
TCSR.TE. For example, this can be used for triggering the data transfer upon
receiving the Clear to Send (CTS) signal at DX2 in the RS-232 protocol.
A data validation logic combining the inputs from the gating logic, the triggering logic
and DSU signals. A transmission of the data word located in TBUF can only be
started if the gating enables the start, bit TCSR.TDV = 1, and bit TCSR.TE = 1.
The content of the transmit buffer TBUF should not be overwritten with new data
while it is valid for transmission and a new transmission can start. If the content of
TBUF has to be changed, it is recommended to clear bit TCSR.TDV by writing
FMR.MTDV = 10B before updating the data. Bit TCSR.TDV becomes automatically
set when TBUF is updated with new data. Another possibility are the interrupts TBI
(for ASC and IIC) or RSI (for SSC and IIS) indicating that a transmission has started.
While a transmission is in progress, TBUF can be loaded with new data. In this case
the user has to take care that an update of the TBUF content takes place before a
new transmission starts.
With this structure, the following data transfer functionality can be achieved:

XMC4500
XMC4000 Family
If bit TCSR.TDSSM = 0, the content of the transmit buffer TBUF is always considered
as valid for transmission. The transfer trigger mechanism can be used to start the
transfer of the same data word based on the selected event (e.g. on a timer base or
an edge at a pin) to realize a kind of life-sign mechanism. Furthermore, in slave
mode, it is ensured that always a correct data word is transmitted instead of the
passive data level.
Bit TCSR.TDSSM = 1 has to be programmed to allow word-by-word data
transmission with a kind of single-shot mechanism. After each transmission start, a
new data word has to be loaded into the transmit buffer TBUF, either by software
write actions to one of the transmit buffer input locations TBUFx or by an optional
data buffer (e.g. FIFO buffer). To avoid that data words are sent out several times or
to allow data handling with an additional data buffer (e.g. FIFO), bit TCSR.TDSSM
has to be 1.
Bit TCSR.TDV becoming automatically set when a new data word is loaded into the
transmit buffer TBUF, a transmission start can be requested by a write action of the
data to be transmitted to at least the low byte of one of the transmit buffer input
locations TBUFx. The additional information TCI can be used to control the data word
length or other parameters independently for each data word by a single write
access.
Bit field FMR.MTDV allows software driven modification (set or clear) of bit
TCSR.TDV. Together with the gating control bit field TCSR.TDEN, the user can set
up the transmit data word without starting the transmission. A possible program
sequence could be: clear TCSR.TDEN = 00B, write data to TBUFx, clear TCSR.TDV
by writing FMR.MTDV = 10B, re-enable the gating with TCSR.TDEN = 01B and then
set TCSR.TDV under software control by writing FMR.MTDV = 01B.
17.2.6 Operating the Receive Data Path

The receive data path is based on two sets of 16-bit wide receive shift registers
RSR0[3:0] and RSR1[3:0] and a receive buffer for each of the set (RBUF0 and RBUF1).
The data transfer parameters like data word length, data frame length, or the shift
direction are controlled commonly for transmission and reception by the shift control
registers.
Register RBUF01SR monitors the status of RBUF0 and RBUF1.
17.2.6.1 Receive Buffering

The receive shift registers cannot be directly accessed by software, but their contents
are automatically loaded into the receive buffer registers RBUF0 (or RBUF1
respectively) if a complete data word has been received or the frame is finished. The
received data words in RBUF0 or RBUF1 can be read out in the correct order directly
from register RBUF or, optionally, from a FIFO buffer stage (see Page 17-38).

XMC4500
XMC4000 Family
Shift Clock Domain
RSR13
Shift Data Input 3
RSR03
RSR12
Shift Data Input 2
RSR02
RSR11
Shift Data Input 1
RSR01 8 4 4
8 4 4
RSR10
Shift Data Input 0
4
RSR00
Shift 4
4
Shift Clock Input Control 8
& 4
Shift Control Input Status 8
Status of Status of 16 16 16 16 16 16
RSR0 RSR1 Data Data
RBUF01 RBUF01
SR (Lower SR (Upper RBUF0 RBUF1 SCTR
16-bit) 16-bit)
Receive
Control
RBUFSR RBUF
System Clock Domain
Figure 17-19 Receive Data Path
17.2.6.2 Receive Data Shift Mode

Receive data can be selected to be shifted in one, two or four bits at a time through the
corresponding number of input stages and data input lines. This option allows the USIC
to support protocols such as the Dual- and Quad-SSC. The selection is done through the
bit field DSM in the shift control register SCTR.
Note: The bit field SCTR.DSM controls the data shift mode for both the transmit and
receive paths to allow the transmission and reception of data through one to four
data lines.
For the shift mode with two or four parallel data inputs, the data word and frame length
must be in multiples of two or four respectively. The number of data shifts required to
input a specific data word or data frame length is thus reduced by the factor of the

XMC4500
XMC4000 Family
number of parallel data input lines. For example, to receive a 16-bit data word through
four input lines, only four shifts are required.
Depending on the shift mode, different receive shift registers with different bit
composition are used as shown in Table 17-7. Note that the n in the table denotes the
shift number less one, i.e. for the first data shift n = 0, the second data shift n = 1 and
continues until the total number of shifts less one is reached.
For all receive shift registers, whether the first bit shifted in is the MSB or LSB depends
on the setting of SCTR.SDIR.
Table 17-8 Receive Shift Register Composition

Receive Input stage Single Data Input Two Data Inputs Four Data Inputs
Shift used (SCTR.DSM = (SCTR.DSM = (SCTR.DSM =
Registers 00B) 10B) 11B)
RSRx0 DX0 All data bits Bit n*2 Bit n*4
RSRx1 DX3 Not used Bit n*2 + 1 Bit n*4 + 1
RSRx2 DX4 Not used Not used Bit n*4 + 2
RSRx3 DX5 Not used Not used Bit n*4 + 3
17.2.6.3 Baud Rate Constraints

The following baud rate constraints have to be respected to ensure correct data
reception and buffering. The user has to take care about these restrictions when
selecting the baud rate and the data word length with respect to the module clock
frequency fPB.
A received data word in a receiver shift registers RSRx[3:0] must be held constant for
at least 4 periods of fPB in order to ensure correct loading of the related receiver buffer
register RBUFx.
The shift control signal has to be constant inactive for at least 5 periods of fPB
between two consecutive frames in order to correctly detect the end of a frame.
The shift control signal has to be constant active for at least 1 period of fPB in order
to correctly detect a frame (shortest frame).
A minimum setup and hold time of the shift control signal with respect to the shift
clock signal has to be ensured.
17.2.7 Hardware Port Control

Hardware port control is intended for SSC protocols with half-duplex configurations,
where a single port pin is used for both input and output data functions, to control the pin
direction through a dedicated hardware interface. All settings in Pn_IOCRy.PCx, except
for the input pull device selection and output driver type (open drain or push-pull), are
overruled by the hardware port control.

XMC4500
XMC4000 Family
Input pull device selection is done through the Pn_IOCRy.PCx as before, while the
output driver is fixed to push-pull-only in this mode.
One, two or four port pins can be selected with the hardware port control to support SSC
protocols with multiple bi-directional data lines, such as dual- and quad-SSC. This
selection and the enable/disable of the hardware port control is done through
CCR.HPCEN. The direction of all selected pins is controlled through a single bit
SCTR.HPCDIR.
SCTR.HPCDIR is automatically shadowed with the start of each data word to prevent
changing of the pin direction in the middle of a data word transfer.
17.2.8 Operating the FIFO Data Buffer

The FIFO data buffers of a USIC module are built in a similar way, with transmit buffer
and receive buffer capability for each channel. Depending on the device, the amount of
available FIFO buffer area can vary. In the XMC4500, totally 64 buffer entries can be
distributed among the transmit or receive FIFO buffers of both channels of the USIC
module.
Buffered
Receive Data Receive Data
Receive Shift Data
OUTR RBUF
FIFO Data Input (s)
Shift
Buffered Unit
Transmit Data Transmit Transmit Data (DSU) Shift Data
INx FIFO TBUF
Output (s)
Bypass
USICx_C0
User
Inter-
face
Buffered
Receive Data Receive Data
Receive Shift Data
OUTR RBUF
FIFO Data Input (s)
Shift
Buffered Unit
Transmit Data Transmit Transmit Data (DSU) Shift Data
INx FIFO TBUF
Output (s)
Bypass
USICx_C1
Figure 17-20 FIFO Buffer Overview

In order to operate the FIFO data buffers, the following issues have to be considered:

XMC4500
XMC4000 Family
FIFO buffer available and selected:

The transmit FIFO buffer and the bypass structure are only available if CCFG.TB = 1,
whereas the receive FIFO buffer is only available if CCFG.RB = 1.
It is recommended to configure all buffer parameters while there is no data traffic for
this USIC channel and the FIFO mechanism is disabled by TBCTR.SIZE = 0 (for
transmit buffer) or RBCTR.SIZE = 0 (for receive buffer). The allocation of a buffer
area by writing TBCTR or RBCTR has to be done while the corresponding FIFO
buffer is disabled. The FIFO buffer interrupt control bits can be modified
independently of data traffic.
FIFO buffer setup:
The total amount of available FIFO buffer entries limits the length of the transmit and
receive buffers for each USIC channel.
Bypass setup:
In addition to the transmit FIFO buffer, a bypass can be configured as described on
Page 17-49.
17.2.8.1 FIFO Buffer Partitioning

If available, the FIFO buffer area consists of a defined number of FIFO buffer entries,
each containing a data part and the associated control information (RCI for receive data,
TCI for transmit data). One FIFO buffer entry represents the finest granularity that can
be allocated to a receive FIFO buffer or a transmit FIFO buffer. All available FIFO buffer
entries of a USIC module are located one after the other in the FIFO buffer area. The
overall counting starts with FIFO entry 0, followed by 1, 2, etc.
For each USIC module, a certain number of FIFO entries is available, that can be
allocated to the channels of the same USIC module. It is not possible to assign FIFO
buffer area to USIC channels that are not located within the same USIC module.
For each USIC channel, the size of the transmit and the receive FIFO buffer can be
chosen independently. For example, it is possible to allocate the full amount of available
FIFO entries as transmit buffer for one USIC channel. Some possible scenarios of FIFO
buffer partitioning are shown in Figure 17-21.
Each FIFO buffer consists of a set of consecutive FIFO entries. The size of a FIFO data
buffer can only be programmed as a power of 2, starting with 2 entries, then 4 entries,
then 8 entries, etc. A FIFO data buffer can only start at a FIFO entry aligned to its size.
For example, a FIFO buffer containing n entries can only start with FIFO entry 0, n, 2*n,
3*n, etc. and consists of the FIFO entries [x*n, (x+1)*n-1], with x being an integer number
(incl. 0). It is not possible to have holes with unused FIFO entries within a FIFO buffer,
whereas there can be unused FIFO entries between two FIFO buffers.

XMC4500
XMC4000 Family
Available Buffer Available Buffer Available Buffer Available Buffer

Area Area Area Area
Transmit Data Transmit Data
Area for CH1 Area for CH1 Transmit Data Transmit Data
Receive Data Area for CH0 Area for CH1
Unused Entries
Area for CH1
Transmit Data
Area for CH0 Receive Data Receive Data Transmit Data
Receive Data Area for CH0 Area for CH0 Area for CH0
Area for CH0
Scenario 1 Scenario 2 Scenario 3 Scenario 4
Figure 17-21 FIFO Buffer Partitioning

The data storage inside the FIFO buffers is based on pointers, that are internally updated
whenever the data contents of the FIFO buffers have been modified. This happens
automatically when new data is put into a FIFO buffer or the oldest data is taken from a
FIFO buffer. As a consequence, the user program does not need to modify the pointers
for data handling. Only during the initialization phase, the start entry of a FIFO buffer has
to be defined by writing the number of the first FIFO buffer entry in the FIFO buffer to the
corresponding bit field DPTR in register RBCTR (for a receive FIFO buffer) or TBCTR
(for a transmit FIFO buffer) while the related bit field RBCTR.SIZE=0 (or
TBCTR.SIZE = 0, respectively). The assignment of buffer entries to a FIFO buffer
(regarding to size and pointers) must not be changed by software while the related USIC
channel is taking part in data traffic.
17.2.8.2 Transmit Buffer Events and Interrupts

The transmit FIFO buffer mechanism detects the following events, that can lead to
interrupts (if enabled):
Standard transmit buffer event
Transmit buffer error event
Standard Transmit Buffer Event

The standard transmit buffer event is triggered by the filling level of the transmit buffer
(given by TRBSR.TBFLVL) exceeding (TBCTR.LOF = 1) or falling below
(TBCTR.LOF = 0)1) a programmed limit (TBCTR.LIMIT).
1) If the standard transmit buffer event is used to indicate that new data has to be written to one of the INx
locations, TBCTR.LOF = 0 should be programmed.

XMC4500
XMC4000 Family
If the event trigger with TRBSR.STBT feature is disabled (TBCTR.STBTEN = 0), the
trigger of the standard transmit buffer event is based on the transition of the fill level from
equal to below or above the limit, not the fact of being below or above.
If TBCTR.STBTEN = 1, the transition of the fill level below or above the programmed
limit additionally sets TRBSR.STBT. This bit triggers also the standard transmit buffer
event whenever there is a transfer data to TBUF event or write data to INx event.
The way TRBSR.STBT is cleared depends on the trigger mode (selected by
TBCTR.STBTM). If TBCTR.STBTM = 0, TRBSR.STBT is cleared by hardware when the
buffer fill level equals the programmed limit again (TRBSR.TBFLVL = TBCTR.LIMIT). If
TBCTR.STBTM = 1, TRBSR.STBT is cleared by hardware when the buffer fill level
equals the buffer size (TRBSR.TBFLVL = TBCTR.SIZE).
Note: The flag TRBSR.STBI is set only when the transmit buffer fill level exceeds or falls
below the programmed limit (depending on TBCTR.LOF setting). Standard
transmit buffer events triggered by TRBSR.STBT does not set the flag.
Figure 17-22 shows examples of the standard transmit buffer event with the different
TBCTR.STBTEN and TBCTR.STBTM settings. These examples are meant to illustrate
the hardware behaviour and might not always represent real application use cases.

XMC4500
XMC4000 Family
The interrupt is serviced

and it is used to fill up the
FIFO.
...
Example 1:
TBCTR settings:
SIZE = 8
LIMIT = 3
LOF = 0 D1
STBTEN = 0
STBTM = 0 D0 D0 TBUF D1 D2
D1 D1 D2 D3 ...
D2 D2 INx D3 INx D4
TBFLVL = 3 TBFLVL = 2 TBFLVL = 3 TBFLVL = 4

STBI = 0 STBI = 1 STBI = 0 STBI = 0
STBT = 0 STBT = 0 STBT = 0 STBT = 0
The interrupt is serviced The interrupt is serviced

Data continues to be
and it is used to fill up the again and this time the
transferred to TBUF while
FIFO. LIMIT value is reached.
the interrupt is pending.
...
Example 2:
TBCTR settings:
SIZE = 8
LIMIT = 3
LOF = 0
STBTEN = 1
STBTM = 0 D0 D0 TBUF D2
D1 D1 D1 TBUF D2 D3 ...
D2 D2 D2 INx D3 INx D4
TBFLVL = 3 TBFLVL = 2 TBFLVL = 1 TBFLVL = 2 TBFLVL = 3

STBI = 0 STBI = 1 STBI = 1 STBI = 0 STBI = 0
STBT = 0 STBT = 1 STBT = 1 STBT = 1 STBT = 0
The interrupt is serviced Interrupt continues to be

and it is used to fill up the requested until TBFLVL = SIZE.
FIFO.
D1
... D1 D2 ...
Example 3: D2 D3
TBCTR settings:
SIZE = 8 D3 D4
LIMIT = 3
LOF = 0 D4 D5
STBTEN = 1
STBTM = 1 D0 D0 TBUF D1 D5 D6
D1 D1 D2 ... D6 D7 ...
D2 D2 INx D3 INx D7 INx D8
TBFLVL = 3 TBFLVL = 2 TBFLVL = 3 TBFLVL = 7 TBFLVL = SIZE

STBI = 0 STBI = 1 STBI = 0 STBI = 0 STBI = 0
STBT = 0 STBT = 1 STBT = 1 STBT = 1 STBT = 0
Figure 17-22 Standard Transmit Buffer Event Examples
Transmit Buffer Error Event

The transmit buffer error event is triggered when software has written to a full buffer. The
written value is ignored.

XMC4500
XMC4000 Family
Transmit Buffer Events and Interrupt Handling

Figure 17-23 shows the transmit buffer events and interrupts.
TBCTR TRBSCR TRBSR

Clear TBCTR TBCTR
LOF CSTBI STBI
STBIEN STBINP
Set 2
SR0
1 .
.
.
.
Transfer Data to . .
& SR5
TBUF Event 0 TBCTR
Write Data to & Standard
1 STBTEN Transmit Standard
INx Event Transmit
Buffer
LIMIT equal to TRBSR Event Buffer Interrupt
TBFLVL Set
STBT
Clear
0
TBFLVL equal to
1
SIZE
TBCTR
STBTM
TRBSCR TRBSR TBCTR TBCTR

Clear
CTBERI TBERI TBERIEN ATBINP
Set 2
Transmit Buffer
Transmit Buffer SR0
Error Interrupt . .
Error Event .
.
.
.
(Write to full transmit
buffer) SR5
Figure 17-23 Transmit Buffer Events

Table 17-9 shows the registers, bits and bit fields to indicate the transmit buffer events
and to control the interrupts related to the transmit FIFO buffers of a USIC channel.
Table 17-9 Transmit Buffer Events and Interrupt Handling

Standard transmit buffer event TRBSR. TRBSCR. TBCTR. TBCTR.
STBI CSTBI STBIEN STBINP
TRBSR. Cleared by
STBT hardware
Transmit buffer error event TRBSR. TRBSCR. TBCTR. TBCTR.
TBERI CTBERI TBERIEN ATBINP

XMC4500
XMC4000 Family
17.2.8.3 Receive Buffer Events and Interrupts

The receive FIFO buffer mechanism detects the following events, that can lead to an
interrupt (if enabled):
Standard receive buffer event
Alternative receive buffer event
Receive buffer error event
The standard receive buffer event and the alternative receive buffer event can be
programmed to two different modes, one referring to the filling level of the receive buffer,
the other one related to a bit position in the receive control information RCI of the data
word that becomes available in OUTR.
If the interrupt generation refers to the filling level of the receive FIFO buffer, only the
standard receive buffer event is used, whereas the alternative receive buffer event is not
used. This mode can be selected to indicate that a certain amount of data has been
received, without regarding the content of the associated RCI.
If the interrupt generation refers to RCI, the filling level is not taken into account. Each
time a new data word becomes available in OUTR, an event is detected. If bit RCI[4] = 0,
a standard receive buffer event is signaled, otherwise an alternative receive buffer
device (RCI[4] = 1). Depending on the selected protocol and the setting of
RBCTR.RCIM, the value of RCI[4] can hold different information that can be used for
protocol-specific interrupt handling (see protocol sections for more details).
Standard Receive Buffer Event in Filling Level Mode

In filling level mode (RBCTR.RNM = 0), the standard receive buffer event is triggered by
the filling level of the receive buffer (given by TRBSR.RBFLVL) exceeding
(RBCTR.LOF = 1) or falling below (RBCTR.LOF = 0) a programmed limit
(RBCTR.LIMIT).1)
If the event trigger with bit TRBSR.SRBT feature is disabled (RBCTR.SRBTEN = 0), the
trigger of the standard receive buffer event is based on the transition of the fill level from
equal to below or above the limit, not the fact of being below or above.
If RBCTR.SRBTEN = 1, the transition of the fill level below or above the programmed
limit additionally sets the bit TRBSR.SRBT. This bit also triggers the standard receive
buffer event each time there is a data read out event or new data received event.
The way TRBSR.SRBT is cleared depends on the trigger mode (selected by
RBCTR.SRBTM). If RBCTR.SRBTM = 0, TRBSR.SRBT is cleared by hardware when
the buffer fill level equals the programmed limit again (TRBSR.RBFLVL =
RBCTR.LIMIT). If RBCTR.SRBTM = 1, TRBSR.SRBT is cleared by hardware when the
buffer fill level equals 0 (TRBSR.RBFLVL = 0).
1) If the standard receive buffer event is used to indicate that new data has to be read from OUTR,
RBCTR.LOF = 1 should be programmed.

XMC4500
XMC4000 Family
Note: The flag TRBSR.SRBI is set only when the receive buffer fill level exceeds or falls
below the programmed limit (depending on RBCTR.LOF setting). Standard
receive buffer events triggered by TRBSR.SRBT does not set the flag.

XMC4500
XMC4000 Family
Figure 17-24 shows examples of the standard receive buffer event with the different
RBCTR.SRBTEN and RBCTR.SRBTM settings. These examples are meant to illustrate
the hardware behaviour and might not always represent real application use cases.
Interrupt is serviced and four data read outs from

OUTR takes place.
...
Example 1:
RBCTR settings:
SIZE = 8
LIMIT = 3
LOF = 1 D0
D3 RBUF
SRBTEN = 0
SRBTM = 0 D2 D1
D2 D2
D1
D3
D1 D2
D1 D3
D2 ...
D0 D3
D0 D0 D4
D3
D1 D3
RBFLVL = 3 RBFLVL = 4 RBFLVL = 3 RBFLVL = 0

SRBI = 0 SRBI = 1 SRBI = 0 SRBI = 0
SRBT = 0 SRBT = 0 SRBT = 0 SRBT = 0
FIFO continues to receive data while the interrupt is Interrupt is serviced and the first
pending.
of four data reads from OUTR
takes place.
D7
D0 RBUF
... D1
D6 D7
D0 ...
Example 2: D2
D5 D1
D6
RBCTR settings:
SIZE = 8 D4 RBUF D3
D4 D2
D5
LIMIT = 3
LOF = 1 D3
D0 RBUF D3
D0 D3
D0 D3
D4
SRBTEN = 1
SRBTM = 0 D1
D2 D1
D2 D1
D2 D1
D2 D3
D0
D2
D1 D2
D1 D2
D1 ... D2
D1 D1
D2 ...
D3
D0 D3
D0 D3
D0 D3
D0 D0 D2
D1
RBFLVL = 3 RBFLVL = 4 RBFLVL = 5 RBFLVL = 8 RBFLVL = 7

SRBI = 0 SRBI = 1 SRBI = 1 SRBI = 1 SRBI = 0
SRBT = 0 SRBT = 1 SRBT = 1 SRBT = 1 SRBT = 1
The interrupt routine

completes the data read; The interrupt routine is
interrupt is still requested entered a second time.
due to SRBT = 1.
D7
D0
D1
D6 D7
D0
D2
D5 D1
D6 D7
D3 D3
D4 D4 D2
D5 D5 D6 D6 D7 D7
RBFLVL = 4 RBFLVL = 3 RBFLVL = 2 RBFLVL = 1 RBFLVL = 0

SRBI = 0 SRBI = 0 SRBI = 0 SRBI = 0 SRBI = 0
SRBT = 1 SRBT = 0 SRBT = 0 SRBT = 0 SRBT = 0
For the case SRBTM = 1, SRBT remains set during these 3 instances
and interrupt is requested.
Figure 17-24 Standard Receive Buffer Event Examples

XMC4500
XMC4000 Family
Standard and Alternate Receive Buffer Events in RCI Mode

In RCI mode (RBCTR.RNM = 1), the standard receive buffer event is triggered when the
OUTR stage is updated with a new data value with RCI[4] = 0.
If the OUTR stage is updated with a new data value with RCI[4] = 1, an alternate receive
buffer event is triggered instead.
Receive Buffer Error Event

The receive buffer error event is triggered if the software reads from an empty buffer,
regardless of RBCTR.RNM value. The read data is invalid.
Receive Buffer Events and Interrupt Handling

Figure 17-25 shows the receiver buffer events and interrupts in filling level mode.
RBCTR TRBSCR TRBSR RBCTR RBCTR

Clear
LOF CSRBI SRBI STBIEN SRBINP
2
Set
1 ..
SR0
.
.
. .
Data Read Out & SR5
Event RBCTR
0 Standard Standard
New Data & SRBTEN Receive
1 Receive
Received Event Buffer Buffer Interrupt
TRBSR Event
LIMIT equal to Set
RBFLVL SRBT
Clear
0
RBFLVL equal 1
to 0 RBCTR
SRBTM
TRBSCR TRBSR RBCTR RBCTR

Clear
CRBERI RBERI RBERIEN ARBINP
Set 2
Receive Buffer
Receive Buffer SR0
Error Interrupt . .
Error Event .
.
.
.
(Read from empty
receive buffer) SR5
Figure 17-25 Receiver Buffer Events in Filling Level Mode

XMC4500
XMC4000 Family
Figure 17-26 shows the receiver buffer events and interrupts in RCI mode.
OUTR TRBSCR TRBSR RBCTR RBCTR

Clear
RCI[4] CSRBI SRBI SRBIEN SRBINP
2
Set
SR0
.. ..
. .
Standard Receive Standard Receive SR5
Buffer Event Buffer Interrupt
New Data in 0
OUTR Event 1
Alternate Receive Alternate Receive
SR0
Buffer Event Buffer Interrupt .
.
.
.
. .
SR5
Set
2
Clear
CARBI ARBI ARBIEN ARBINP
TRBSCR TRBSR RBCTR RBCTR
TRBSCR TRBSR RBCTR

Clear
CRBERI RBERI RBERIEN
Set 2
Receive Buffer
Receive Buffer SR0
Error Interrupt . .
Error Event .
.
.
.
(Read from empty
receive buffer) SR5
Figure 17-26 Receiver Buffer Events in RCI Mode

Table 17-10 shows the registers, bits and bit fields to indicate the receive buffer events
and to control the interrupts related to the receive FIFO buffers of a USIC channel.
Table 17-10 Receive Buffer Events and Interrupt Handling

Standard receive buffer event TRBSR. TRBSCR. RBCTR. RBCTR.
SRBI CSRBI SRBIEN SRBINP
TRBSR. Cleared by
SRBT hardware

XMC4500
XMC4000 Family
Table 17-10 Receive Buffer Events and Interrupt Handling (contd)

Alternative receive buffer event TRBSR. TRBSCR. RBCTR. RBCTR.
ARBI CARBI ARBIEN ARBINP
Receive buffer error event TRBSR. TRBSCR. RBCTR. RBCTR.
RBERI CRBERI RBERIEN ARBINTXDP
17.2.8.4 FIFO Buffer Bypass

The data bypass mechanism is part of the transmit FIFO control block. It allows to
introduce a data word in the data stream without modifying the transmit FIFO buffer
contents, e.g. to send a high-priority message. The bypass structure consists of a
bypass data word of maximum 16 bits in register BYP and some associated control
information in register BYPCR. For example, these bits define the word length of the
bypass data word and configure a transfer trigger and gating mechanism similar to the
one for the transmit buffer TBUF.
The bypass data word can be tagged valid or invalid for transmission by bit BYRCR.BDV
(bypass data valid). A combination of data flow related and event related criteria define
whether the bypass data word is considered valid for transmission. A data validation
logic checks the start conditions for this data word. Depending on the result of the check,
the transmit buffer register TBUF is loaded with different values, according to the
following rules:
Data from the transmit FIFO buffer or the bypass data can only be transferred to
TBUF if TCSR.TDV = 0 (TBUF is empty).
Bypass data can only be transferred to TBUF if the bypass is enabled by
BYPCR.BDEN or the selecting gating condition is met.
If the bypass data is valid for transmission and has either a higher transmit priority
than the FIFO data or if the transmit FIFO is empty, the bypass data is transferred to
TBUF.
If the bypass data is valid for transmission and has a lower transmit priority than the
FIFO buffer that contains valid data, the oldest transmit FIFO data is transferred to
TBUF.
If the bypass data is not valid for transmission and the FIFO buffer contains valid
data, the oldest FIFO data is transferred to TBUF.
If neither the bypass data is valid for transmission nor the transmit FIFO buffer
contains valid data, TBUF is unchanged.
The bypass data validation is based on the logic blocks shown in Figure 17-27.
A transfer gating logic enables or disables the bypass data word transfer to TBUF
under software or under hardware control. If the input stage DX2 is not needed for

XMC4500
XMC4000 Family
data shifting, signal DX2S can be used for gating purposes. The transfer gating logic
is controlled by bit field BYPCR.BDEN.
A transfer trigger logic supports data word transfers related to events, e.g. timer
based or related to an input pin. If the input stage DX2 is not needed for data shifting,
signal DX2T can be used for trigger purposes. The transfer trigger logic is controlled
by bit BYPCR.BDVTR.
A bypass data validation logic combining the inputs from the gating logic, the
triggering logic and TCSR.TDV.
BYPCR TBUF
TDV
BDVTR
BYPCR
DX2T Transfer
BDV
Trigger
Shift Control Bypass
Input DX2 Data
Transfer Validation
DX2S Gating
BDEN BDSSM
BYPCR BYPCR
Figure 17-27 Bypass Data Validation

With this structure, the following bypass data transfer functionality can be achieved:
Bit BYPCR.BDSSM = 1 has to be programmed for a single-shot mechanism. After
each transfer of the bypass data word to TBUF, the bypass data word has to be
tagged valid again. This can be achieved either by writing a new bypass data word
to BYP or by DX2T if BDVTR = 1 (e.g. trigger on a timer base or an edge at a pin).
Bit BYPCR.BDSSM = 0 has to be programmed if the bypass data is permanently
valid for transmission (e.g. as alternative data if the data FIFO runs empty).
17.2.8.5 FIFO Access Constraints

The data in the shared FIFO buffer area is accessed by the hardware mechanisms for
data transfer of each communication channel (for transmission and reception) and by
software to read out received data or to write data to be transmitted. As a consequence,
the data delivery rate can be limited by the FIFO mechanism. Each access by hardware
to the FIFO buffer area has priority over a software access, that is delayed in case of an
access collision.
In order to avoid data loss and stalling of the CPU due to delayed software accesses, the

XMC4500
XMC4000 Family
baud rate, the word length and the software access mechanism have to be taken into
account. Each access to the FIFO data buffer area by software or by hardware takes one
period of fPB. Especially a continuous flow of very short, consecutive data words can lead
to an access limitation.
17.2.8.6 Handling of FIFO Transmit Control Information

In addition to the transmit data, the transmit control information TCI can be transferred
from the transmit FIFO or bypass structure to the USIC channel. Depending on the
selected protocol and the enabled update mechanism, some settings of the USIC
channel parameters can be modified. The modifications are based on the TCI of the
FIFO data word loaded to TBUF or by the bypass control information if the bypass data
is loaded into TBUF.
TCSR.SELMD = 1: update of PCR.CTR[20:16] by FIFO TCI or BYPCR.BSELO with
additional clear of PCR.CTR[23:21]
TCSR.WLEMD = 1: update of SCTR.WLE and TCSR.EOF by FIFO TCI or
BYPCR.BWLE (if the WLE information is overwritten by TCI or BWLE, the user has
to take care that FLE is set accordingly)
TCSR.FLEMD = 1: update of SCTR.FLE[4:0] by FIFO TCI or BYPCR.BWLE with
additional clear of SCTR.FLE[5]
TCSR.HPCMD = 1: update of SCTR.DSM and SCTR.HPCDIR by FIFO TCI or
BYPCR.BHPC
TCSR.WAMD = 1: update of TCSR.WA by FIFO TCI[4]
See Section 17.2.5.3 for more details on TCI.

XMC4500
XMC4000 Family
FIFO / Bypass USIC Channel

16
BDATA
16
TBUF
Transmit
FIFO SELMD
5 TCI
CTR[20:16]
5
BSEL0 0 CTR[23:21]
Bypass
Control WLEMD
4+ 1
WLE , EOF
BWLE
FLEMD
FLE[4:0]
0 FLE[5]
HPCMD
TCI[2:0]
3
DSM
BHPC
HPCDIR
WAMD
TCI[4]
WA
Figure 17-28 TCI Handling with FIFO / Bypass

XMC4500
XMC4000 Family
17.3 Asynchronous Serial Channel (ASC = UART)

The asynchronous serial channel ASC covers the reception and the transmission of
asynchronous data frames and provides a hardware LIN support. The receiver and
transmitter being independent, frames can start at different points in time for
transmission and reception. The ASC mode is selected by CCR.MODE = 0010B with
CCFG.ASC = 1 (ASC mode available).
17.3.1 Signal Description

An ASC connection is characterized by the use of a single connection line between a
transmitter and a receiver. The receiver input RXD signal is handled by the input stage
DX0.
ASC Module A ASC Module B

DIN0 DIN0
RXD RXD
RBUF DX0 DX0 RBUF
DOUT0 DOUT0
TBUF TXD TXD TBUF
Transfer Transfer
Control Control
fPB Baud Rate Baud Rate fPB

(ASC A) Generator Generator (ASC B)
Figure 17-29 ASC Signal Connections for Full-Duplex Communication

For full-duplex communication, an independent communication line is needed for each
transfer direction. Figure 17-29 shows an example with a point-to-point full-duplex
connection between two communication partners ASC A and ASC B.
For half-duplex or multi-transmitter communication, a single communication line is
shared between the communication partners. Figure 17-30 shows an example with a
point-to-point half-duplex connection between ASC A and ASC B. In this case, the user
has to take care that only one transmitter is active at a time. In order to support
transmitter collision detection, the input stage DX1 can be used to monitor the level of
the transmit line and to check if the line is in the idle state or if a collision occurred.
There are two possibilities to connect the receiver input DIN0 to the transmitter output

XMC4500
XMC4000 Family
DOUT0. Communication partner ASC A uses an internal connection with only the
transmit pin TXD, that is delivering its input value as RXD to the DX0 input stage for
reception and to DX1 to check for transmitter collisions. Communication partner ASC B
uses an external connection between the two pins TXD and RXD.
ASC Module A ASC Module B

DIN0 DIN0
RXD
RBUF DX0 DX0 RBUF
DOUT0
DOUT0
TBUF TBUF
TXD TXD
DX1 DX1
Transfer Transfer
Control Control
fPB Baud Rate Baud Rate fPB

(ASC A) Generator Generator
(ASC B)
Figure 17-30 ASC Signal Connections for Half-Duplex Communication
17.3.2 Frame Format

A standard ASC frame is shown in Figure 17-31. It consists of:
An idle time with the signal level 1.
One start of frame bit (SOF) with the signal level 0.
A data field containing a programmable number of data bits (1-63).
A parity bit (P), programmable for either even or odd parity. It is optionally possible to
handle frames without parity bit.
One or two stop bits with the signal level 1.

XMC4500
XMC4000 Family
1
IDLE SOF DATA P STOP IDLE
0
1 Bit 1-63 Bit 0-1 Bit 1-2 Bits
Figure 17-31 Standard ASC Frame Format

The protocol specific bits (SOF, P, STOP) are automatically handled by the ASC protocol
state machine and do not appear in the data flow via the receive and transmit buffers.
17.3.2.1 Idle Time

The receiver and the transmitter independently check the respective data input lines
(DX0, DX1) for being idle. The idle detection ensures that an SOF bit of a recently
enabled ASC module does not collide with an already running frame of another ASC
module.
In order to start the idle detection, the user software has to clear bits PSR.RXIDLE and/or
PSR.TXIDLE, e.g. before selecting the ASC mode or during operation. If a bit is cleared
by software while a data transfer is in progress, the currently running frame transfer is
finished normally before starting the idle detection again. Frame reception is only
possible if PSR.RXIDLE = 1 and frame transmission is only possible if PSR.TXIDLE = 1.
The duration of the idle detection depends on the setting of bit PCR.IDM. In the case that
a collision is not possible, the duration can be shortened and the bus can be declared as
being idle by setting PCR.IDM = 0.
In the case that the complete idle detection is enabled by PCR.IDM = 1, the data input
of DX0 is considered as idle (PSR.RXIDLE becomes set) if a certain number of
consecutive passive bit times has been detected. The same scheme applies for the
transmitters data input of DX1. Here, bit PSR.TXIDLE becomes set if the idle condition
of this input signal has been detected.
The duration of the complete idle detection is given by the number of programmed data
bits per frame plus 2 (in the case without parity) or plus 3 (in the case with parity). The
counting of consecutive bit times with 1 level restarts from the beginning each time an
edge is found, after leaving a stop mode or if ASC mode becomes enabled.
If the idle detection bits PSR.RXIDLE and/or TXIDLE are cleared by software, the
counting scheme is not stopped (no re-start from the beginning). As a result, the cleared
bit(s) can become set immediately again if the respective input line still meets the idle
criterion.
Please note that the idle time check is based on bit times, so the maximum time can be
up to 1 bit time more than programmed value (but not less).

XMC4500
XMC4000 Family
17.3.2.2 Start Bit Detection

The receiver input signal DIN0 (selected signal of input stage DX0) is checked for a
falling edge. An SOF bit is detected when a falling edge occurs while the receiver is idle
or after the sampling point of the last stop bit. To increase noise immunity, the SOF bit
timing starts with the first falling edge that is detected. If the sampled bit value of the SOF
is 1, the previous falling edge is considered to be due to noise and the receiver is
considered to be idle again.
17.3.2.3 Data Field

The length of the data field (number of data bits) can be programmed by bit field
SCTR.FLE. It can vary between 1 and 63 data bits, corresponding to values of
SCTR.FLE = 0 to 62 (the value of 63 is reserved and must not be programmed in ASC
mode).
The data field can consist of several data words, e.g. a transfer of 12 data bits can be
composed of two 8-bit words, with the 12 bits being split into 8-bits of the first word and
4 bits of the second word. The user software has to take care that the transmit data is
available in-time, once a frame has been started. If the transmit buffer runs empty during
a running data frame, the passive data level (SCTR.PDL) is sent out.
The shift direction can be programmed by SCTR.SDIR. The standard setting for ASC
frames with LSB first is achieved with the default setting SDIR = 0.
17.3.2.4 Parity Bit

The ASC allows parity generation for transmission and parity check for reception on
frame base. The type of parity can be selected by bit field CCR.PM, common for
transmission and reception (no parity, even or odd parity). If the parity handling is
disabled, the ASC frame does not contain any parity bit. For consistency reasons, all
communication partners have to be programmed to the same parity mode.
After the last data bit of the data field, the transmitter automatically sends out its
calculated parity bit if parity generation has been enabled. The receiver interprets this bit
as received parity and compares it to its internally calculated one. The received parity bit
value and the result of the parity check are monitored in the receiver buffer status
registers, RBUFSR and RBUF01SR, as receiver buffer status information. These
registers contain bits to monitor a protocol-related argument (PAR) and protocol-related
error indication (PERR).
17.3.2.5 Stop Bit(s)

Each ASC frame is completed by 1 or 2 of stop bits with the signal level 1 (same level as
the idle level). The number of stop bits is programmable by bit PSR.STPB. A new start
bit can be transferred directly after the last stop bit.

XMC4500
XMC4000 Family
17.3.3 Operating the ASC

In order to operate the ASC protocol, the following issues have to be considered:
Select ASC mode:
It is recommended to configure all parameters of the ASC that do not change during
run time while CCR.MODE = 0000B. Bit field SCTR.TRM = 01B has to be
programmed. The configuration of the input stages has to be done while
CCR.MODE = 0000B to avoid unintended edges of the input signals and the ASC
mode can be enabled by CCR.MODE = 0010B afterwards.
Pin connections:
Establish a connection of input stage DX0 with the selected receive data input pin
(signal DIN0) with DX0CR.INSW = 0 and configure a transmit data output pin (signal
DOUT0). For collision or idle detection of the transmitter, the input stage DX1 has to
be connected to the selected transmit output pin, also with DX1CR.INSW = 0.
Additionally, program DX2CR.INSW = 0.
Due to the handling of the input data stream by the synchronous protocol handler, the
propagation delay of the synchronization in the input stage has to be considered.
Bit timing configuration:
The desired baud rate setting has to be selected, comprising the fractional divider,
the baud rate generator and the bit timing. Please note that not all feature
combinations can be supported by the application at the same time, e.g. due to
propagation delays. For example, the length of a frame is limited by the frequency
difference of the transmitter and the receiver device. Furthermore, in order to use the
average of samples (SMD = 1), the sampling point has to be chosen to respect the
signal settling and data propagation times.
Data format configuration:
The word length, the frame length, and the shift direction have to be set up according
to the application requirements by programming the register SCTR. If required by the
application, the data input and output signals can be inverted.
Additionally, the parity mode has to be configured (CCR.PM).
17.3.3.1 Bit Timing

In ASC mode, each bit (incl. protocol bits) is divided into time quanta in order to provide
granularity in the sub-bit range to adjust the sample point to the application
requirements. The number of time quanta per bit is defined by bit fields BRG.DCTQ and
the length of a time quantum is given by BRG.PCTQ.
In the example given in Figure 17-32, one bit time is composed of 16 time quanta
(BRG.DCTQ = 15). It is not recommended to program less than 4 time quanta per bit
time.
Bit field PCR.SP determines the position of the sampling point for the bit value. The value
of PCR.SP must not be set to a value greater than BRG.DCTQ. It is possible to sample
the bit value only once per bit time or to take the average of samples. Depending on bit

XMC4500
XMC4000 Family
PCR.SMD, either the current input value is directly sampled as bit value, or a majority
decision over the input values sampled at the latest three time quanta is taken into
account. The standard ASC bit timing consists of 16 time quanta with sampling after 8
or 9 time quanta with majority decision.
The bit timing setup (number of time quanta and the sampling point definition) is common
for the transmitter and the receiver. Due to independent bit timing blocks, the receiver
and the transmitter can be in different time quanta or bit positions inside their frames.
The transmission of a frame is aligned to the time quanta generation.
1 Bit Time
PCR.SP = 15
PCR.SP = 8
Time Quanta 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
= sample taken if SMD= 0 = sample taken if SMD= 1
Figure 17-32 ASC Bit Timing

The sample point setting has to be adjusted carefully if collision or idle detection is
enabled (via DX1 input signal), because the driver delay and some external delays have
to be taken into account. The sample point for the transmit line has to be set to a value
where the bit level is stable enough to be evaluated.
If the sample point is located late in the bit time, the signal itself has more time to become
stable, but the robustness against differences in the clock frequency of transmitter and
receiver decreases.
17.3.3.2 Baud Rate Generation

The baud rate fASC in ASC mode depends on the number of time quanta per bit time and
their timing. The baud rate setting should only be changed while the transmitter and the
receiver are idle. The bits in register BRG define the baud rate setting:
BRG.CTQSEL
to define the input frequency fCTQIN for the time quanta generation
BRG.PCTQ
to define the length of a time quantum (division of fCTQIN by 1, 2, 3, or 4)
BRG.DCTQ
to define the number of time quanta per bit time

XMC4500
XMC4000 Family
The standard setting is given by CTQSEL = 00B (fCTQIN = fPDIV) and PPPEN = 0
(fPPP = fPIN). Under these conditions, the baud rate is given by:
1 1 1
fASC = fPIN (17.6)
PDIV + 1 PCTQ + 1 DCTQ + 1
In order to generate slower frequencies, two additional divide-by-2 stages can be

selected by CTQSEL = 10B (fCTQIN = fSCLK) and PPPEN = 1 (fPPP = fMCLK), leading to:
fPIN 1 1 1
fASC = (17.7)
22 PDIV + 1 PCTQ + 1 DCTQ + 1
17.3.3.3 Noise Detection

The ASC receiver permanently checks the data input line of the DX0 stage for noise (the
check is independent from the setting of bit PCR.SMD). Bit PSR.RNS (receiver noise)
becomes set if the three input samples of the majority decision are not identical at the
sample point for the bit value. The information about receiver noise gets accumulated
over several bits in bit PSR.RNS (it has to be cleared by software) and can trigger a
protocol interrupt each time noise is detected if enabled by PCR.RNIEN.
17.3.3.4 Collision Detection

In some applications, such as data transfer over a single data line shared by several
sending devices (see Figure 17-30), several transmitters have the possibility to send on
the same data output line TXD. In order to avoid collisions of transmitters being active at
the same time or to allow a kind of arbitration, a collision detection has been
implemented.
The data value read at the TXD input at the DX1 stage and the transmitted data bit value
are compared after the sampling of each bit value. If enabled by PCR.CDEN = 1 and a
bit sent is not equal to the bit read back, a collision is detected and bit PSR.COL is set.
If enabled, bit PSR.COL = 1 disables the transmitter (the data output lines become 1)
and generates a protocol interrupt. The content of the transmit shift register is considered
as invalid, so the transmit buffer has to be programmed again.
17.3.3.5 Pulse Shaping

For some applications, the 0 level of transmitted bits with the bit value 0 is not applied at
the transmit output during the complete bit time. Instead of driving the original 0 level,
only a 0 pulse is generated and the remaining time quanta of the bit time are driven with
1 level. The length of a bit time is not changed by the pulse shaping, only the signalling
is changed.

XMC4500
XMC4000 Family
In the standard ASC signalling scheme, the 0 level is signalled during the complete bit
time with bit value 0 (ensured by programming PCR.PL = 000B). In the case
PCR.PL > 000B, the transmit output signal becomes 0 for the number of time quanta
defined by PCR.PL. In order to support correct reception with pulse shaping by the
transmitter, the sample point has to be adjusted in the receiver according to the applied
pulse length.
0-Pulse for
PL = 001 B
0-Pulse for
PL = 010 B
0-Pulse for
PL = 111 B
0-Pulse for
PL = 000 B
Time Quanta 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0
Figure 17-33 Transmitter Pulse Length Control

Figure 17-34 shows an example for the transmission of an 8-bit data word with LSB first
and one stop bit (e.g. like for IrDA). The polarity of the transmit output signal has been
inverted by SCTR.DOCFG = 01B.
ASC Frame
STOP
SOF
D0
D1
D2
D3
D4
D5
D6
D7
Idle Idle
Bit Value
DOUT Pulse
Figure 17-34 Pulse Output Example

XMC4500
XMC4000 Family
17.3.3.6 Automatic Shadow Mechanism

The contents of the protocol control register PCR, as well as bit field SCTR.FLE are
internally kept constant while a data frame is transferred by an automatic shadow
mechanism (shadowing takes place with each frame start). The registers can be
programmed all the time with new settings that are taken into account for the next data
frame. During a data frame, the applied (shadowed) setting is not changed, although
new values have been written after the start of the data frame.
Bit fields SCTR.WLE and SCTR.SDIR are shadowed automatically with the start of each
data word. As a result, a data frame can consist of data words with a different length. It
is recommended to change SCTR.SDIR only when no data frame is running to avoid
interference between hardware and software.
Please note that the starting point of a data word can be different for a transmitter and a
receiver. In order to ensure correct handling, it is recommended to modify SCTR.WLE
only while transmitter and receiver are both idle. If the transmitter and the receiver are
referring to the same data signal (e.g. in a LIN bus system), SCTR.WLE can be modified
while a data transfer is in progress after the RSI event has been detected.
17.3.3.7 End of Frame Control

The number of bits per ASC frame is defined by bit field SCTR.FLE. In order to support
different frame length settings for consecutively transmitted frames, this bit field can be
modified by hardware. The automatic update mechanism is enabled by
TCSR.FLEMD = 1 (in this case, bits TCSR.WLEMD, SELMD, WAMD and HPCMD have
to be written with 0).
If enabled, the transmit control information TCI automatically overwrites the bit field
TCSR.FLEMD when the ASC frame is started (leading to frames with 1 to 32 data bits).
The TCI value represents the written address location of TBUFxx (without additional data
buffer) or INxx (with additional data buffer). With this mechanism, an ASC with 8 data
bits is generated by writing a data word to TBUF07 (IN07, respectively).
17.3.3.8 Mode Control Behavior

In ASC mode, the following kernel modes are supported:
Run Mode 0/1:
Behavior as programmed, no impact on data transfers.
Stop Mode 0:
Bit PSR.TXIDLE is cleared. A new transmission is not started. A current transmission
is finished normally. Bit PSR.RXIDLE is not modified. Reception is still possible.
When leaving stop mode 0, bit TXIDLE is set according to PCR.IDM.
Stop Mode 1:
Bit PSR.TXIDLE is cleared. A new transmission is not started. A current transmission
is finished normally. Bit PSR.RXIDLE is cleared. A new reception is not possible. A

XMC4500
XMC4000 Family
current reception is finished normally.

When leaving stop mode 1, bits TXIDLE and RXIDLE are set according to PCR.IDM.
17.3.3.9 Disabling ASC Mode

In order to switch off ASC mode without any data corruption, the receiver and the
transmitter have to be both idle. This is ensured by requesting Stop Mode 1 in register
KSCFG. After waiting for the end of the frame, the ASC mode can be disabled.
17.3.3.10 Protocol Interrupt Events

The following protocol-related events are generated in ASC mode and can lead to a
protocol interrupt. The collision detection and the transmitter frame finished events are
related to the transmitter, whereas the receiver events are given by the synchronization
break detection, the receiver noise detection, the format error checks and the end of the
received frame.
Please note that the bits in register PSR are not automatically cleared by hardware and
have to be cleared by software in order to monitor new incoming events.
Collision detection:
This interrupt indicates that the transmitted value (DOUT0) does not match with the
input value of the DX1 input stage at the sample point of a bit. For more details refer
to Page 17-59.
Transmitter frame finished:
This interrupt indicates that the transmitter has completely finished a frame. Bit
PSR.TFF becomes set at the end of the last stop bit. The DOUT0 signal assignment
to port pins can be changed while no transmission is in progress.
Receiver frame finished:
This interrupt indicates that the receiver has completely finished a frame. Bit
PSR.RFF becomes set at the end of the last stop bit. The DIN0 signal assignment to
port pins can be changed while no reception is in progress.
Synchronization break detection:
This interrupt can be used in LIN networks to indicate the reception of the
synchronization break symbol (at the beginning of a LIN frame).
Receiver noise detection:
This interrupt indicates that the input value at the sample point of a bit and at the two
time quanta before are not identical.
Format error:
The bit value of the stop bit(s) is defined as 1 level for the ASC protocol. A format
error is signalled if the sampled bit value of a stop bit is 0.
17.3.3.11 Data Transfer Interrupt Handling

The data transfer interrupts indicate events related to ASC frame handling.

XMC4500
XMC4000 Family
Transmit buffer interrupt TBI:

Bit PSR.TBIF is set after the start of first data bit of a data word. This is the earliest
point in time when a new data word can be written to TBUF.
With this event, bit TCSR.TDV is cleared and new data can be loaded to the transmit
buffer.
Transmit shift interrupt TSI:
Bit PSR.TSIF is set after the start of the last data bit of a data word.
Receiver start interrupt RSI:
Bit PSR.RSIF is set after the sample point of the first data bit of a data word.
Receiver interrupt RI and alternative interrupt AI:
Bit PSR.RIF is set after the sampling point of the last data bit of a data word if this
data word is not directly followed by a parity bit (parity generation disabled or not the
last word of a data frame).
If the data word is directly followed by a parity bit (last data word of a data frame and
parity generation enabled), bit PSR.RIF is set after the sampling point of the parity bit
if no parity error has been detected. If a parity error has been detected, bit PSR.AIF
is set instead of bit PSR.RIF.
The first data word of a data frame is indicated by RBUFSR.SOF = 1 for the received
word.
Bit PSR.RIF is set for a receiver interrupt RI with WA = 0. Bit PSR.AIF is set for a
alternative interrupt AI with WA = 1.
17.3.3.12 Baud Rate Generator Interrupt Handling

The baud rate generator interrupt indicate that the capture mode timer has reached its
maximum value. With this event, the bit PSR.BRGIF is set.
17.3.3.13 Protocol-Related Argument and Error

The protocol-related argument (RBUFSR.PAR) and the protocol-related error
(RBUFSR.PERR) are two flags that are assigned to each received data word in the
corresponding receiver buffer status registers.
In ASC mode, the received parity bit is monitored by the protocol-related argument and
the result of the parity check by the protocol-related error indication (0 = received parity
bit equal to calculated parity value). This information being elaborated only for the last
received data word of each data frame, both bit positions are 0 for data words that are
not the last data word of a data frame or if the parity generation is disabled.
17.3.3.14 Receive Buffer Handling

If a receive FIFO buffer is available (CCFG.RB = 1) and enabled for data handling
(RBCTR.SIZE > 0), it is recommended to set RBCTR.RCIM = 11B in ASC mode. This
leads to an indication that the data word has been the first data word of a new data frame

XMC4500
XMC4000 Family
if bit OUTR.RCI[0] = 1, a parity error is indicated by OUTR.RCI[4] = 1, and the received

parity bit value is given by OUTR.RCI[3].
The standard receive buffer event and the alternative receive buffer event can be used
for the following operations in RCI mode (RBCTR.RNM = 1):
A standard receive buffer event indicates that a data word can be read from OUTR
that has been received without parity error.
An alternative receive buffer event indicates that a data word can be read from OUTR
that has been received with parity error.
17.3.3.15 Sync-Break Detection

The receiver permanently checks the DIN0 signal for a certain number of consecutive bit
times with 0 level. The number is given by the number of programmed bits per frame
(SCTR.FLE) plus 2 (in the case without parity) or plus 3 (in the case with parity). If a 0
level is detected at a sample point of a bit after this event has been found, bit PSR.SBD
is set and additionally, a protocol interrupt can be generated (if enabled by
PCR.SBD = 1). The counting restarts from 0 each time a falling edge is found at input
DIN0. This feature can be used for the detection of a synchronization break for slave
devices in a LIN bus system (the master does not check for sync break).
For example, in a configuration for 8 data bits without parity generation, bit PCR.SBD is
set after at the next sample point at 0 level after 10 complete bit times have elapsed
(representing the sample point of the 11th bit time since the first falling edge).
17.3.3.16 Transfer Status Indication

The receiver status can be monitored by flag PSR[9] = BUSY if bit PCR.CTR[16]
(receiver status enable RSTEN) is set. In this case, bit BUSY is set during a complete
frame reception from the beginning of the start of frame bit to the end of the last stop bit.
The transmitter status can be monitored by flag PSR[9] = BUSY if bit PCR.CTR[17]
(transmitter status enable TSTEN) is set. In this case, bit BUSY is set during a complete
frame reception from the beginning of the start of frame bit to the end of the last stop bit.
If both bits RSTEN and TSTEN are set, flag BUSY indicates the logical OR-combination
of the receiver and the transmitter status. If both bits are cleared, flag BUSY is not
modified depending on the transfer status (status changes are ignored).
17.3.4 ASC Protocol Registers

In ASC mode, the registers PCR and PSR handle ASC related information.
17.3.4.1 ASC Protocol Control Register

In ASC mode, the PCR register bits or bit fields are defined as described in this section.

XMC4500
XMC4000 Family
PCR
Protocol Control Register [ASC Mode]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MCL TST RST
0
K EN EN
rw r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FFIE FEIE RNIE CDE SBIE STP
PL SP IDM SMD
N N N N N B
rw rw rw rw rw rw rw rw rw rw

SMD 0 rw Sample Mode
This bit field defines the sample mode of the ASC receiver.
The selected data input signal can be sampled only once
per bit time or three times (in consecutive time quanta).
When sampling three times, the bit value shifted in the
receiver shift register is given by a majority decision
among the three sampled values.
0B Only one sample is taken per bit time. The current
input value is sampled.
1B Three samples are taken per bit time and a majority
decision is made.
STPB 1 rw Stop Bits
This bit defines the number of stop bits in an ASC frame.
0B The number of stop bits is 1.
1B The number of stop bits is 2.

XMC4500
XMC4000 Family

IDM 2 rw Idle Detection Mode
This bit defines if the idle detection is switched off or based
on the frame length.
0B The bus idle detection is switched off and bits
PSR.TXIDLE and PSR.RXIDLE are set
automatically to enable data transfers without
checking the inputs before.
1B The bus is considered as idle after a number of
consecutive passive bit times defined by SCTR.FLE
plus 2 (in the case without parity bit) or plus 3 (in the
case with parity bit).
SBIEN 3 rw Synchronization Break Interrupt Enable
This bit enables the generation of a protocol interrupt if a
synchronization break is detected. The automatic
detection is always active, so bit SBD can be set
independently of SBIEN.
0B The interrupt generation is disabled.
1B The interrupt generation is enabled.
CDEN 4 rw Collision Detection Enable
This bit enables the reaction of a transmitter to the
collision detection.
0B The collision detection is disabled.
1B If a collision is detected, the transmitter stops its
data transmission, outputs a 1, sets bit PSR.COL
and generates a protocol interrupt.
In order to allow data transmission again, PSR.COL
has to be cleared by software.
RNIEN 5 rw Receiver Noise Detection Interrupt Enable
This bit enables the generation of a protocol interrupt if
receiver noise is detected. The automatic detection is
always active, so bit PSR.RNS can be set independently
of PCR.RNIEN.

XMC4500
XMC4000 Family

FEIEN 6 rw Format Error Interrupt Enable
format error is detected. The automatic detection is
always active, so bits PSR.FER0/FER1 can be set
independently of PCR.FEIEN.
FFIEN 7 rw Frame Finished Interrupt Enable
This bit enables the generation of a protocol interrupt if the
receiver or the transmitter reach the end of a frame. The
automatic detection is always active, so bits PSR.RFF or
PSR.TFF can be set independently of PCR.FFIEN.
SP [12:8] rw Sample Point
This bit field defines the sample point of the bit value. The
sample point must not be located outside the programmed
bit timing (PCR.SP BRG.DCTQ).
PL [15:13] rw Pulse Length
This bit field defines the length of a 0 data bit, counted in
time quanta, starting with the time quantum 0 of each bit
time. Each bit value that is a 0 can lead to a 0 pulse that is
shorter than a bit time, e.g. for IrDA applications. The
length of a bit time is not changed by PL, only the length
of the 0 at the output signal.
The pulse length must not be longer than the programmed
bit timing (PCR.PL BRG.DCTQ).
This bit field is only taken into account by the transmitter
and is ignored by the receiver.
000B The pulse length is equal to the bit length (no
shortened 0).
001B The pulse length of a 0 bit is 2 time quanta.
...

XMC4500
XMC4000 Family

RSTEN 16 rw Receiver Status Enable
This bit enables the modification of flag PSR[9] = BUSY
according to the receiver status.
0B Flag PSR[9] is not modified depending on the
receiver status.
1B Flag PSR[9] is set during the complete reception of
a frame.
TSTEN 17 rw Transmitter Status Enable
This bit enables the modification of flag PSR[9] = BUSY
according to the transmitter status.
0B Flag PSR[9] is not modified depending on the
transmitter status.
1B Flag PSR[9] is set during the complete transmission
of a frame.
MCLK 31 rw Master Clock Enable
This bit enables the generation of the master clock MCLK.
0B The MCLK generation is disabled and the MCLK
signal is 0.
1B The MCLK generation is enabled.
Returns 0 if read; should be written with 0.
17.3.4.2 ASC Protocol Status Register

In ASC mode, the PSR register bits or bit fields are defined as described in this section.
The bits and bit fields in register PSR are not cleared by hardware.
The flags in the PSR register can be cleared by writing a 1 to the corresponding bit
position in register PSCR. Writing a 1 to a bit position in PSR sets the corresponding flag,
but does not lead to further actions (no interrupt generation). Writing a 0 has no effect.
The PSR flags should be cleared by software before enabling a new protocol.

XMC4500
XMC4000 Family
PSR
Protocol Status Register [ASC Mode] (48H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
BRG
0
IF
r rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BUS FER FER RXID TXID
AIF RIF TBIF TSIF DLIF RSIF TFF RFF RNS COL SBD
Y 1 0 LE LE
rwh rwh rwh rwh rwh rwh r rwh rwh rwh rwh rwh rwh rwh rwh rwh

TXIDLE 0 rwh Transmission Idle
This bit shows if the transmit line (DX1) has been idle. A
frame transmission can only be started if TXIDLE is set.
0B The transmitter line has not yet been idle.
1B The transmitter line has been idle and frame
transmission is possible.
RXIDLE 1 rwh Reception Idle
This bit shows if the receive line (DX0) has been idle. A
frame reception can only be started if RXIDLE is set.
0B The receiver line has not yet been idle.
1B The receiver line has been idle and frame reception
is possible.
SBD 2 rwh Synchronization Break Detected1)
This bit is set if a programmed number of consecutive bit
values with level 0 has been detected (called
synchronization break, e.g. in a LIN bus system).
0B A synchronization break has not yet been detected.
1B A synchronization break has been detected.
COL 3 rwh Collision Detected1)
This bit is set if a collision has been detected (with
PCR.CDEN = 1).
0B A collision has not yet been detected and frame
transmission is possible.
1B A collision has been detected and frame
transmission is not possible.

XMC4500
XMC4000 Family

RNS 4 rwh Receiver Noise Detected1)
This bit is set if receiver noise has been detected.
0B Receiver noise has not been detected.
1B Receiver noise has been detected.
FER0 5 rwh Format Error in Stop Bit 01)
This bit is set if a 0 has been sampled in the stop bit 0
(called format error 0).
0B A format error 0 has not been detected.
1B A format error 0 has been detected.
FER1 6 rwh Format Error in Stop Bit 11)
This bit is set if a 0 has been sampled in the stop bit 1
(called format error 1).
0B A format error 1 has not been detected.
1B A format error 1 has been detected.
RFF 7 rwh Receive Frame Finished1)
This bit is set if the receiver has finished the last stop bit.
0B The received frame is not yet finished.
1B The received frame is finished.
TFF 8 rwh Transmitter Frame Finished1)
This bit is set if the transmitter has finished the last stop bit.
0B The transmitter frame is not yet finished.
1B The transmitter frame is finished.
BUSY 9 r Transfer Status BUSY
This bit indicates the receiver status (if PCR.RSTEN = 1)
or the transmitter status (if PCR.TSTEN = 1) or the logical
OR combination of both
(if PCR.RSTEN = PCR.TSTEN = 1).
0B A data transfer does not take place.
1B A data transfer currently takes place.
RSIF 10 rwh Receiver Start Indication Flag
0B A receiver start event has not occurred.
1B A receiver start event has occurred.
DLIF 11 rwh Data Lost Indication Flag
0B A data lost event has not occurred.
1B A data lost event has occurred.
TSIF 12 rwh Transmit Shift Indication Flag
0B A transmit shift event has not occurred.
1B A transmit shift event has occurred.

XMC4500
XMC4000 Family

TBIF 13 rwh Transmit Buffer Indication Flag
0B A transmit buffer event has not occurred.
1B A transmit buffer event has occurred.
RIF 14 rwh Receive Indication Flag
0B A receive event has not occurred.
1B A receive event has occurred.
AIF 15 rwh Alternative Receive Indication Flag
0B An alternative receive event has not occurred.
1B An alternative receive event has occurred.
BRGIF 16 rwh Baud Rate Generator Indication Flag
0B A baud rate generator event has not occurred.
1B A baud rate generator event has occurred.
0 [31:17 r Reserved
] Returns 0 if read; should be written with 0.
1) This status bit can generate a protocol interrupt (see Page 17-21). The general interrupt status flags are
described in the general interrupt chapter.
17.3.5 Hardware LIN Support

In order to support the LIN protocol, bit TCSR.FLEMD = 1 should be set for the master.
For slave devices, it can be cleared and the fixed number of 8 data bits has to be set
(SCTR.FLE = 7H). For both, master and slave devices, the parity generation has to be
switched off (CCR.PM = 00B) and transfers take place with LSB first (SCTR.SDIR = 0)
and 1 stop bit (PCR.STPB = 0).
The Local Interconnect Network (LIN) data exchange protocol contains several symbols
that can all be handled in ASC mode. Each single LIN symbol represents a complete
ASC frame. The LIN bus is a master-slave bus system with a single master and multiple
slaves (for the exact definition please refer to the official LIN specification).
A complete LIN frame contains the following symbols:
Synchronization break:
The master sends a synchronization break to signal the beginning of a new frame. It
contains at least 13 consecutive bit times at 0 level, followed by at least one bit time
at 1 level (corresponding to 1 stop bit). Therefore, TBUF11 if the transmit buffer is
used, (or IN11 if the FIFO buffer is used) has to be written with 0 (leading to a frame
with SOF followed by 12 data bits at 0 level).
A slave device shall detect 11 consecutive bit times at 0 level, which done by the
synchronization break detection. Bit PSR.SBD is set if such an event is detected and
a protocol interrupt can be generated. Additionally, the received data value of 0
appears in the receive buffer and a format error is signaled.

XMC4500
XMC4000 Family
If the baud rate of the slave has to be adapted to the master, the baud rate
measurement has to be enabled for falling edges by setting BRG.TMEN = 1,
DX0CR.CM = 10H and DX1CR.CM = 00H before the next symbol starts.
Synchronization byte:
The master sends this symbol after writing the data value 55H to TBUF07 (or IN07).
A slave device can either receive this symbol without any further action (and can
discard it) or it can use the falling edges for baud rate measurement. Bit
PSR.TSIF = 1 (with optionally the corresponding interrupt) indicates the detection of
a falling edge and the capturing of the elapsed time since the last falling edge in
BRG.PDIV. Valid captured values can be read out after the second, third, fourth and
fifth activation of TSIF. After the fifth activation of TSIF within this symbol, the baud
rate detection can be disabled (BRG.TMEN = 0) and BRG.PDIV can be programmed
with the formerly captured value divided by twice the number of time quanta per bit
(assuming BRG.PCTQ = 00B).
Other symbols:
The other symbols of a LIN frame can be handled with ASC data frames without
specific actions.
If LIN frames should be sent out on a frame base by the LIN master, the input DX2 can
be connected to external timers to trigger the transmit actions (e.g. the synchronization
break symbol has been prepared but is started if a trigger occurs). Please note that
during the baud rate measurement of the ASC receiver, the ASC transmitter of the same
USIC channel can still perform a transmission.

XMC4500
XMC4000 Family
17.4 Synchronous Serial Channel (SSC)

The synchronous serial channel SSC covers the data transfer function of an SPI-like
module. It can handle reception and transmission of synchronous data frames between
a device operating in master mode and at least one device in slave mode. Besides the
standard SSC protocol consisting of one input and one output data line, SSC protocols
with two (Dual-SSC) or four (Quad-SSC) input/output data lines are also supported. The
SSC mode is selected by CCR.MODE = 0001B with CCFG.SSC = 1 (SSC mode is
available).
17.4.1 Signal Description

A synchronous SSC data transfer is characterized by a simultaneous transfer of a shift
clock signal together with the transmit and/or receive data signal(s) to determine when
the data is valid (definition of transmit and sample point).
SSC Communication Master SSC Communication Slave

DOUT0 Master Transmit / DIN0
Slave Receive
TBUF DX0 RBUF
DIN0 Master Receive / DOUT0

Slave Transmit
RBUF DX0 TBUF
SCLKOUT SCLKIN
Baud Rate Slave Clock
DX1
Generator
SELOx SELIN
Slave Select Slave Select
Generator DX2
fPB fPB
(Master) (Slave)
Figure 17-35 SSC Signals for Standard Full-Duplex Communication

In order to explicitly indicate the start and the end of a data transfer and to address more
than one slave devices individually, the SSC module supports the handling of slave
select signals. They are optional and are not necessarily needed for SSC data transfers.
The SSC module supports up to 8 different slave select output signals for master mode
operation (named SELOx, with x = 0-7) and 1 slave select input SELIN for slave mode.
In most applications, the slave select signals are active low.

XMC4500
XMC4000 Family
A device operating in master mode controls the start and end of a data frame, as well as
the generation of the shift clock and slave select signals. This comprises the baud rate
setting for the shift clock and the delays between the shift clock and the slave select
output signals. If several SSC modules are connected together, there can be only one
SSC master at a time, but several slaves. Slave devices receive the shift clock and
optionally a slave select signal(s). For the programming of the input stages DXn please
refer to Page 17-21.
Table 17-11 SSC Communication Signals

SSC Mode Receive Data Transmit Data Shift Clock Slave Select(s)
Standard SSC MRST1), MTSR2), Output Output(s)
Master input DIN0, Output DOUT0 SCLKOUT SELOx
handled by DX0
Standard SSC MTSR, MRST, Input SCLKIN, input SELIN,
Slave input DIN0, Output DOUT0 handled by DX1 handled by DX2
handled by DX0
Dual-SSC MRST[1:0], MTSR[1:0], Output Output(s)
Master input DIN[1:0], Output SCLKOUT SELOx
handled by DX0 DOUT[1:0]
and DX3
Dual-SSC Slave MTSR[1:0], MRST[1:0], Input SCLKIN, input SELIN,
input DIN[1:0], Output handled by DX1 handled by DX2
handled by DX0 DOUT[1:0]
and DX3
Quad-SSC MRST[3:0], MTSR[3:0], Output Output(s)
Master input DIN[3:0], Output SCLKOUT SELOx
handled by DOUT[3:0]
DX0, DX3, DX4
and DX5
Quad-SSC MTSR[3:0], MRST[3:0], Input SCLKIN, input SELIN,
Slave input DIN[3:0], Output handled by DX1 handled by DX2
handled by DOUT[3:0]
DX0, DX3, DX4
and DX5
1) MRST = master receive slave transmit, also known as MISO = master in slave out
2) MTSR = master transmit slave receive, also known as MOSI = master out slave in

XMC4500
XMC4000 Family
Shift
Clock
Transmit
D0 D1 Dn D0 D1 Dn
Data
Receive
D0 D1 Dn D0 D1 Dn
Data
Data Word 0 Data Word x
Slave Data Frame

Select
Figure 17-36 4-Wire SSC Standard Communication Signals
17.4.1.1 Transmit and Receive Data Signals

In standard SSC half-duplex mode, a single data line is used, either for data transfer from
the master to a slave or from a slave to the master. In this case, MRST and MTSR are
connected together, one signal as input, the other one as output, depending on the data
direction. The user software has to take care about the data direction to avoid data
collision (e.g. by preparing dummy data of all 1s for transmission in case of a wired AND
connection with open-drain drivers, by enabling/disabling push/pull output drivers or by
switching pin direction with hardware port control enabled). In full-duplex mode, data
transfers take place in parallel between the master device and a slave device via two
independent data signals MTSR and MRST, as shown in Figure 17-35.
The receive data input signal DIN0 is handled by the input stage DX0. In master mode
(referring to MRST) as well as in slave mode (referring to MTSR), the data input signal
DIN0 is taken from an input pin. The signal polarity of DOUT0 (data output) with respect
to the data bit value can be configured in block DOCFG (data output configuration) by bit
field SCTR.DOCFG.
MRST SCTR MTSR

Master Mode DIN0 Input Stage Data Shift DOUT0 Master Mode
DX0 Unit DOCFG
MTSR MRST
Slave Mode Slave Mode
Figure 17-37 SSC Data Signals

XMC4500
XMC4000 Family
For dual- and quad-SSC modes that require multiple input and output data lines to be
used, additional input stages, DINx and DOUTx signals need to be set up.
17.4.1.2 Shift Clock Signals

The shift clock signal is handled by the input stage DX1. In slave mode, the signal
SCLKIN is received from an external master, so the DX1 stage has to be connected to
an input pin. The input stage can invert the received input signal to adapt to the polarity
of SCLKIN to the function of the data shift unit (data transmission on rising edges, data
reception on falling edges).
In master mode, the shift clock is generated by the internal baud rate generator. The
output signal SCLK of the baud rate generator is taken as shift clock input for the data
shift unit. The internal signal SCLK is made available for external slave devices by signal
SCLKOUT. For complete closed loop delay compensation in a slave mode, SCLKOUT
can also take the transmit shift clock from the input stage DX1. The selection is done
through the bit BRG.SCLKOSEL. See Section 17.4.6.3.
SSC in Slave Mode SSC in Master Mode

SCLKIN SCLKOUT
Delay of
SCLKCFG
Bit Time
Input Stage
DX1
SCLK
Transfer Baud Rate
Data Shift Unit
Control Logic Generator
Figure 17-38 SSC Shift Clock Signals

Due to the multitude of different SSC applications, in master mode, there are different
ways to configure the shift clock output signal SCLKOUT with respect to SCLK. This is
done in the block SCLKCFG (shift clock configuration) by bit field BRG.SCLKCFG,
allowing 4 possible settings, as shown in Figure 17-39.
No delay, no polarity inversion (SCLKCFG = 00B, SCLKOUT equals SCLK):
The inactive level of SCLKOUT is 0, while no data frame is transferred. The first data
bit of a new data frame is transmitted with the first rising edge of SCLKOUT and the
first data bit is received in with the first falling edge of SCLKOUT. The last data bit of
a data frame is transmitted with the last rising clock edge of SCLKOUT and the last

XMC4500
XMC4000 Family
data bit is received in with the last falling edge of SCLKOUT. This setting can be used
in master and in slave mode. It corresponds to the behavior of the internal data shift
unit.
No delay, polarity inversion (SCLKCFG = 01B):
The inactive level of SCLKOUT is 1, while no data frame is transferred. The first data
bit of a new data frame is transmitted with the first falling clock edge of SCLKOUT
and the first data bit is received with the first rising edge of SCLKOUT. The last data
bit of a data frame is transmitted with the last falling edge of SCLKOUT and the last
data bit is received with the last rising edge of SCLKOUT. This setting can be used
in master and in slave mode.
SCLKOUT is delayed by 1/2 shift clock period, no polarity inversion
(SCLKCFG = 10B):
The inactive level of SCLKOUT is 0, while no data frame is transferred.
The first data bit of a new data frame is transmitted 1/2 shift clock period before the
first rising clock edge of SCLKOUT. Due to the delay, the next data bits seem to be
transmitted with the falling edges of SCLKOUT. The last data bit of a data frame is
transmitted 1/2 period of SCLKOUT before the last rising clock edge of SCLKOUT.
The first data bit is received 1/2 shift clock period before the first falling edge of
SCLKOUT. Due to the delay, the next data bits seem to be received with the rising
edges of SCLKOUT. The last data bit is received 1/2 period of SCLKOUT before the
last falling clock edge of SCLKOUT.
This setting can be used only in master mode and not in slave mode (the connected
slave has to provide the first data bit before the first SCLKOUT edge, e.g. as soon as
it is addressed by its slave select).
SCLKOUT is delayed by 1/2 shift clock period, polarity inversion (SCLKCFG = 11B):
The inactive level of SCLKOUT is 1, while no data frame is transferred.
The first data bit of a new data frame is transmitted 1/2 shift clock period before the
first falling clock edge of SCLKOUT. Due to the delay, the next data bits seem to be
transmitted with the rising edges of SCLKOUT. The last data bit of a data frame is
transmitted 1/2 period of SCLKOUT before the last falling clock edge of SCLKOUT.
The first data bit is received 1/2 shift clock period before the first rising edge of
SCLKOUT. Due to the delay, the next data bits seem to be received with the falling
edges of SCLKOUT. The last data bit is received 1/2 period of SCLKOUT before the
last rising clock edge of SCLKOUT.
This setting can be used only in master mode and not in slave mode (the connected
slave has to provide the first data bit before the first SCLKOUT edge, e.g. as soon as
it is addressed by its slave select).

XMC4500
XMC4000 Family
Data Bit x transmitted

1 2 n
(x = 1-n)
Bit 1 Bit n
SCK
SCLKOUT
(SCLKCFG = 00B)
SCLKOUT
(SCLKCFG = 01B)
SCLKOUT
(SCLKCFG = 10B)
SCLKOUT
(SCLKCFG = 11B)
Data Bit x received

1 2 n
(x = 1-n)
Figure 17-39 SCLKOUT Configuration in SSC Master Mode

Note: If a configuration with delay is selected and a slave select line is used, the slave
select delays have to be set up accordingly.
17.4.1.3 Slave Select Signals

The slave select signal is handled by the input stage DX2. In slave mode, the input signal
SELIN is received from an external master via an input pin. The input stage can invert
the received input signal to adapt the polarity of signal SELIN to the function of the data
shift unit (the module internal signals are considered as high active, so a data transfer is
only possible while the slave select input of the data shift unit is at 1-level, otherwise, shift
clock pulses are ignored and do not lead to data transfers). If an input signal SELIN is
low active, it should be inverted in the DX2 input stage.
In master mode, a master slave select signal MSLS is generated by the internal slave
select generator. In order to address different external slave devices independently, the
internal MSLS signal is made available externally via up to 8 SELOx output signals that
can be configured by the block SELCFG (select configuration).

XMC4500
XMC4000 Family
SSC in Slave Mode SSC in Master Mode
SELIN .. ... . SELOx

x = 0-7
SELCFG
Input Stage
DX2
MSLS
Transfer Slave Select
Data Shift Unit Control Logic Generator
Figure 17-40 SSC Slave Select Signals

The control of the SELCFG block is based on protocol specific bits and bit fields in the
protocol control register PCR. For the generation of the MSLS signal please refer to
Section 17.4.3.2.
PCR.SELCTR to chose between direct and coded select mode
PCR.SELINV to invert the SELOx outputs
PCR.SELO[7:0] as individual value for each SELOx line
The SELCFG block supports the following configurations of the SELOx output signals:
Direct Select Mode (SELCTR = 1):
Each SELOx line (with x = 0-7) can be directly connected to an external slave device.
If bit x in bit field SELO is 0, the SELOx output is permanently inactive. A SELOx
output becomes active while the internal signal MSLS is active (see
Section 17.4.3.2) and bit x in bit field SELO is 1. Several external slave devices can
be addressed in parallel if more than one bit in bit field SELO are set during a data
frame. The number of external slave devices that can be addressed individually is
limited to the number of available SELOx outputs.
Coded Select Mode (SELCTR = 0):
The SELOx lines (with x = 1-7) can be used as addresses for an external address
decoder to increase the number of external slave devices. These lines only change
with the start of a new data frame and have no other relation to MSLS. Signal SELO0
can be used as enable signal for the external address decoder. It is active while
MSLS is active (during a data frame) and bit 0 in bit field SELO is 1. Furthermore, in
coded select mode, this output line is delayed by one cycle of fPB compared to MSLS
to allow the other SELOx lines to stabilize before enabling the address decoder.

XMC4500
XMC4000 Family
17.4.2 Operating the SSC

This chapter contains SSC issues, that are of general interest and not directly linked to
either master mode or slave mode.

The contents of the baud rate control register BRG, bit fields SCTR.FLE as well as the
protocol control register PCR are internally kept constant while a data frame is
transferred (= while MSLS is active) by an automatic shadow mechanism. The registers
can be programmed all the time with new settings that are taken into account for the next
data frame. During a data frame, the applied (shadowed) setting is not changed,
although new values have been written after the start of the data frame.
Bit fields SCTR.WLE, SCTR.DSM, SCTR.HPCDIR and SCTR.SDIR are shadowed
automatically with the start of each data word. As a result, a data frame can consist of
data words with a different length, or data words that are transmitted or received through
different number of data lines. It is recommended to change SCTR.SDIR only when no
data frame is running to avoid interference between hardware and software.
Please note that the starting point of a data word are different for a transmitter (first bit
transmitted) and a receiver (first bit received). In order to ensure correct handling, it is
recommended to refer to the receive start interrupt RSI before modifying SCTR.WLE. If
TCSR.WLEMD = 1, it is recommended to update TCSR and TBUFxx after the receiver
start interrupt has been generated.

In SSC mode, the following kernel modes are supported:
Run Mode 0/1:
Stop Mode 0/1:
The content of the transmit buffer is considered as not valid for transmission.
Although being considered as 0, bit TCSR.TDV it is not modified by the stop mode
condition.
In master mode, a currently running word transfer is finished normally, but no new
data word is started (the stop condition is not considered as end-of-frame condition).
In slave mode, a currently running word transfer is finished normally. Passive data
will be sent out instead of a valid data word if a data word transfer is started by the
external master while the slave device is in stop mode. In order to avoid passive slave
transmit data, it is recommended not to program stop mode for an SSC slave device
if the master device does not respect the slave devices stop mode.

XMC4500
XMC4000 Family
17.4.2.3 Disabling SSC Mode

In order to disable SSC mode without any data corruption, the receiver and the
transmitter have to be both idle. This is ensured by requesting Stop Mode 1 in register
KSCFG. After Stop Mode 1 has been acknowledged by KSCFG.2 = 1, the SSC mode
can be disabled.
17.4.2.4 Data Frame Control

An SSC data frame can consist of several consecutive data words that may be
separated by an inter-word delay. Without inter-word delay, the data words seem to form
a longer data word, being equivalent to a data frame. The length of the data words are
most commonly identical within a data frame, but may also differ from one word to
another. The data word length information (defined by SCTR.WLE) is evaluated for each
new data word, whereas the frame length information (defined by SCTR.FLE) is
evaluated at the beginning at each start of a new frame.
The length of an SSC data frame can be defined in two different ways:
By the number of bits per frame:
If the number of bits per data frame is defined (frame length FLE), a slave select
signal is not necessarily required to indicate the start and the end of a data frame.
If the programmed number of bits per frame is reached within a data word, the frame
is considered as finished and remaining data bits in the last data word are ignored
and are not transferred.
This method can be applied for data frames with up to 63 data bits.
By the slave select signal:
If the number of bits per data frame is not known, the start/end information of a data
frame is given by a slave select signal. If a deactivation of the slave select signal is
detected within a data word, the frame is considered as finished and remaining data
bits in the last data word are ignored and are not transferred.
This method has to be applied for frames with more than 63 data bits (programming
limit of FLE). The advantage of slave select signals is the clearly defined start and
end condition of data frames in a data stream. Furthermore, slave select signals allow
to address slave devices individually.
17.4.2.5 Parity Mode

The SSC allows parity generation for transmission and parity check for reception on
frame base. The type of parity can be selected by bit field CCR.PM, common for
transmission and reception (no parity, even or odd parity). If the parity handling is
disabled, the SSC frame does not contain any parity bit. For consistency reasons, all
communication partners have to be programmed to the same parity mode.

XMC4500
XMC4000 Family
If parity generation has been enabled, the transmitter automatically extends the clock by
one cycle after the last data word of the data frame, and sends out its calculated parity
bit in this cycle.
Figure 17-41 shows how a parity bit is added to the transmitted data bits of a frame. The
number of the transmitted bits of a complete frame with parity is always one more than
that without parity. The parity bit is transmitted as the last bit of a frame, following the
data bits, independent of the shift direction (SCTR.SDIR).
Note: For dual and quad SSC protocols, the parity bit will be transmitted and received
only on DOUT0 and DX0 respectively in the extended clock cycle.
Data Frame with LSB First (SCTR.SDIR = 0)
Bit Bit Bit Bit Bit Bit Parity Mode

0 1 2 3 FLE-1 FLE Disabled
(FLE+ 1) Bits
Bit Bit Bit Bit Bit Bit Parity Parity Mode

0 1 2 3 FLE-1 FLE Bit Enabled
(FLE+ 1) + Parity
Time
Data Frame with MSB First (SCTR.SDIR = 1)
Bit Bit Bit Bit Bit Bit Parity Mode

FLE FLE-1 3 2 1 0 Disabled
(FLE+ 1) Bits
Bit Bit Bit Bit Bit Bit Parity Parity Mode

FLE FLE-1 3 2 1 0 Bit Enabled
(FLE+1) + Parity
Time
Figure 17-41 Data Frames without/with Parity

XMC4500
XMC4000 Family
Similarly, after the receiver receives the last word of a data frame as defined by FLE, it
expects an additional one clock cycle, which will contain the parity bit. The receiver
interprets this bit as received parity and separates it from the received data. The received
parity bit value is instead monitored in the protocol-related argument (PAR) of the
receiver buffer status registers as receiver buffer status information. The receiver
compares the bit to its internally calculated parity and the result of the parity check is
indicated by the flag PSR.PARERR. The parity error event generates a protocol interrupt
if PCR.PARIEN = 1.
Parity bit generation and detection is not supported for the following cases:
When frame length is 64 data bits or greater, i.e. FLE = 63H;
When in slave mode, the end of frame occurs before the number of data bits defined
by FLE is reached.
17.4.2.6 Transfer Mode

In SSC mode, bit field SCTR.TRM = 01B has to be programmed to allow data transfers.
Setting SCTR.TRM = 00B disables and stops the data transfer immediately.

The data transfer interrupts indicate events related to SSC frame handling.
Bit PSR.TBIF is set after the start of first data bit of a data word.
Bit PSR.RSIF is set after the reception of the first data bit of a data word.
buffer.
Receiver interrupt RI:
The reception of the second, third, and all subsequent words in a multi-word frame is
always indicated by RBUFSR.SOF = 0. Bit PSR.RIF is set after the reception of the
last data bit of a data word if RBUFSR.SOF = 0.
Bit RBUFSR.SOF indicates whether the received data word has been the first data
word of a multi-word frame or some subsequent word. In SSC mode, it decides if
alternative interrupt or receive interrupt is generated.
Alternative interrupt AI:
The reception of the first word in a frame is always indicated by RBUFSR.SOF = 1.
This is true both in case of reception of multi-word frames and single-word frames. In
SSC mode, this results in setting PSR.AIF.

XMC4500
XMC4000 Family


The protocol-related argument (RBUFSR.PAR) and the protocol-related error
(RBUFSR.PERR) are two flags that are assigned to each received data word in the
corresponding receiver buffer status registers.
In SSC mode, the received parity bit is monitored by the protocol-related argument. The
received start of frame indication is monitored by the protocol-related error indication
(0 = received word is not the first word of a frame, 1 = received word is the first word of
a new frame).
Note: For SSC, the parity error event indication bit is located in the PSR register.

(RBCTR.SIZE > 0), it is recommended to set RBCTR.RCIM = 01B in SSC mode. This
if bit OUTR.RCI[4] = 1, and the word length of the received data is given by
OUTR.RCI[3:0].
for the following operation in RCI mode (RBCTR.RNM = 1):
that has not been the first word of a data frame.
An alternative receive buffer event indicates that the first data word of a new data
frame can be read from OUTR.
17.4.2.11 Multi-IO SSC Protocols

The SSC implements the following three features to support multiple data input/output
SSC protocols, such as the dual- and quad-SSC:
1. Data Shift Mode (Section 17.2.5.2)
Configures the data for transmission and reception using one, two or four data lines
in parallel, through the bit field SCTR.DSM.
2. Hardware Port Control (Section 17.2.7)
Sets up a dedicated hardware interface to control the direction of the pins overlaid
with both DINx and DOUTx functions, through the bit SCTR.HPCDIR.
3. Transmit Control Information (Section 17.2.5.3)
Allows the dynamic control of both the shift mode and pin direction during data
transfers by writing to SCTR.DSM and SCTR.HPCDIR with TCI.

XMC4500
XMC4000 Family
Figure 17-42 shows an example of a Quad-SSC protocol, which requires the master
SSC to first transmit a command byte (to request a quad output read from the slave) and
a dummy byte through a single data line. At the end of the dummy byte, both master and
slave SSC switches to quad data lines, and with the roles of transmitter and receiver
reversed. The master SSC then receives the data four bits per shift clock from the slave
through the MRST[3:0] lines.
Slave
Select
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
SCLKOUT
MTSR/
Command Byte Dummy Byte 4 0 4 0
MRST0
MRST1 5 1 5 1
MRST2 6 2 6 2
MRST3 7 3 7 3
Data Data
Byte 0 Byte 1
Shadowed
00B 11B
SCTR.DSM
Shadowed
SCTR.HPCDIR
(Master)
Figure 17-42 Quad-SSC Example

To work with the quad-SSC protocol in the given example, the following issues have to
be additionally considered on top of those defined in Section 17.4.3 and Section 17.4.4:
During the initialization phase:
Set CCR.HPCEN to 11B to enable the dedicated hardware interface to the
DX0/DOUT0, DX3/DOUT1, DX4/DOUT2 and DX5/DOUT3 pins.
Set TCSR.[4:0] to 10H to enable hardware port control in TCI
To start the data transfer:
For the master SSC, write the command and dummy bytes into TBUF04 to select
a single data line in output mode and initiate the data transfer.
For the slave SSC, dummy data can be preloaded into TBUF00 to select a single
data line in input mode.
To switch to quad data lines and pin direction:

XMC4500
XMC4000 Family
For the master SSC, write subsequent dummy data to TBUF03 to select dual data
lines in input mode to read in valid slave data.
For the slave SSC, write valid data to TBUF07 for transmission through dual data
lines in output mode.
Figure 17-43 shows the connections for the Quad-SSC example.
USIC Master USIC Slave
DX5 DX5
MTSR3/MRST3
DOUT3 DOUT3
DX4 DX4
MTSR2/MRST2
DOUT2 DOUT2
DX3 DX3
MTSR1/MRST1
DOUT1 DOUT1
DX0 DX0
MTSR0/MRST0
DOUT0 DOUT0
clock
SCLKOUT DX1 SCLK
Slave_select
SELO DX2 SELO
Figure 17-43 Connections for Quad-SSC Example
17.4.3 Operating the SSC in Master Mode

In order to operate the SSC in master mode, the following issues have to be considered:
Select SSC mode:
It is recommended to configure all parameters of the SSC that do not change during
CCR.MODE = 0000B to avoid unintended edges of the input signals and the SSC
Pin connections:
Establish a connection of the input stage (DX0, DX3, DX4, DX5) with the selected

XMC4500
XMC4000 Family
receive data input pin (DIN[3:0]) with DXnCR.INSW = 1 and configure the transmit
data output pin (DOUT[3:0]). One, two or four such connections may be needed
depending on the protocol. For half-duplex configurations, hardware port control can
be also used to establish the required connections.
Baud rate generation:
The desired baud rate setting has to be selected, comprising the fractional divider
and the baud rate generator. Bit DX1CR.INSW = 0 has to be programmed to use the
baud rate generator output SCLK directly as input for the data shift unit. Configure a
shift clock output pin (signal SCLKOUT).
Slave select generation:
The slave select delay generation has to be enabled by setting PCR.MSLSEN = 1
and the programming of the time quanta counter setting. Bit DX2CR.INSW = 0 has
to be programmed to use the slave select generator output MSLS as input for the
data shift unit. Configure slave select output pins (signals SELOx) if needed.
The word length, the frame length, the shift direction and shift mode have to be set
up according to the application requirements by programming the register SCTR.
Note: The USIC can only receive in master mode if it is transmitting, because the master
frame handling refers to bit TDV of the transmitter part.

The baud rate (determining the length of one data bit) of the SSC is defined by the
frequency of the SCLK signal (one period of fSCLK represents one data bit). The SSC
baud rate generation does not imply any time quanta counter.
In a standard SSC application, the phase relation between the optional MCLK output
signal and SCLK is not relevant and can be disabled (BRG.PPPEN = 0). In this case, the
SCLK signal directly derives from the protocol input frequency fPIN. In the exceptional
case that a fixed phase relation between the MCLK signal and SCLK is required (e.g.
when using MCLK as clock reference for external devices), the additional divider by 2
stage has to be taken into account (BRG.PPPEN = 1).
The adjustable divider factor is defined by bit field BRG.PDIV.
fPIN 1
fSCLK = if PPPEN = 0
2 PDIV + 1
(17.8)
fPIN 1
22 PDIV + 1
17.4.3.2 MSLS Generation

The slave select signals indicate the start and the end of a data frame and are also used
by the communication master to individually select the desired slave device. A slave

XMC4500
XMC4000 Family
select output of the communication master becomes active a programmable time before
a data part of the frame is started (leading delay Tld), necessary to prepare the slave
device for the following communication. After the transfer of a data part of the frame, it
becomes inactive again a programmable time after the end of the last bit (trailing delay
Ttd) to respect the slave hold time requirements. If data frames are transferred back-to-
back one after the other, the minimum time between the deactivation of the slave select
and the next activation of a slave select is programmable (next-frame delay Tnf). If a data
frame consists of more than one data word, an optional delay between the data words
can also be programmed (inter-word delay Tiw).
Data Frame
Data Word 0 Data Word 1
Shift
Clock
Transmit
Data D0 D1 Dn D0 D1 Dn
Receive
Data D0 D1 Dn D0 D1 Dn
Tld Tiw Ttd Tn f

Active
MSLS Inactive
SELOx
(SELINV = 1)
Figure 17-44 MSLS Generation in SSC Master Mode

In SSC master mode, the slave select delays are defined as follows:
Leading delay Tld:
The leading delay starts if valid data is available for transmission. The internal signal
MSLS becomes active with the start of the leading delay. The first shift clock edge
(rising edge) of SCLK is generated by the baud rate generator after the leading delay
has elapsed.
Trailing delay Ttd
The trailing delay starts at the end of the last SCLK cycle of a data frame. The internal
signal MSLS becomes inactive with the end of the trailing delay.
Inter-word delay Tiw:
This delay is optional and can be enabled/disabled by PCR.TIWEN. If the inter-word
delay is disabled (TIWEN = 0), the last data bit of a data word is directly followed by

XMC4500
XMC4000 Family
the first data bit of the next data word of the same data frame. If enabled
(TIWEN = 1), the inter-word delay starts at the end of the last SCLK cycle of a data
word. The first SCLK cycle of the following data word of the same data frame is
started when the inter-word delay has elapsed. During this time, no shift clock pulses
are generated and signal MSLS stays active. The communication partner has time to
digest the previous data word or to prepare for the next one.
Next-frame delay Tnf:
The next-frame delay starts at the end of the trailing delay. During this time, no shift
clock pulses are generated and signal MSLS stays inactive. A frame is considered as
finished after the next-frame delay has elapsed.
17.4.3.3 Automatic Slave Select Update

If the number of bits per SSC frame and the word length are defined by bit fields
SCTR.FLE and SCTR.WLE, the transmit control information TCI can be used to update
the slave select setting PCR.CTR[23:16] to control the SELOx select outputs. The
automatic update mechanism is enabled by TCSR.SELMD = 1 (bits TCSR.WLEMD,
FLEMD, and WAMD have to be cleared). In this case, the TCI of the first data word of a
frame defines the slave select setting of the complete frame due to the automatic
shadow mechanism (see Page 17-61).

XMC4500
XMC4000 Family
17.4.3.4 Slave Select Delay Generation

The slave select delay generation is based on time quanta. The length of a time quantum
(defined by the period of the fCTQIN) and the number of time quanta per delay can be
programmed.
In standard SSC applications, the leading delay Tld and the trailing delay Ttd are mainly
used to ensure stability on the input and output lines as well as to respect setup and hold
times of the input stages. These two delays have the same length (in most cases shorter
than a bit time) and can be programmed with the same set of bit fields.
BRG.CTQSEL
to define the input frequency fCTQIN for the time quanta generation for Tld and Ttd
BRG.PCTQ
to define the length of a time quantum (division of fCTQIN by 1, 2, 3, or 4) for Tld and Ttd
BRG.DCTQ
to define the number of time quanta for the delay generation for Tld and Ttd
The inter-word delay Tiw and the next-frame delay Tnf are used to handle received data
or to prepare data for the next word or frame. These two delays have the same length
(in most cases in the bit time range) and can be programmed with a second, independent
set of bit fields.
PCR.CTQSEL1
to define the input frequency fCTQIN for the time quanta generation for Tnf and Tiw
PCR.PCTQ1
to define the length of a time quantum (division of fCTQIN by 1, 2, 3, or 4) for Tnf and Tiw
PCR.DCTQ1
to define the number of time quanta for the delay generation for Tnf and Tiw
PCR.TIWEN
to enable/disable the inter-word delay Tiw
Each delay depends on the length of a time quantum and the programmed number of
time quanta given by the bit fields CTQSEL/CTQSEL1, PCTQ/DCTQ and
PCTQ1/DCTQ1 (the coding of CTQSEL1 is similar to CTQSEL, etc.). To provide a high
flexibility in programming the delay length, the input frequencies can be selected
between several possibilities (e.g. based on bit times or on the faster inputs of the
protocol-related divider). The delay times are defined as follows:
(PCTQ + 1) (DCTQ + 1)
Tld = Ttd =
fCTQIN
(17.9)
(PCTQ1 + 1) (DCTQ1 + 1)
Tiw = Tnf =
fCTQIN

XMC4500
XMC4000 Family

The following protocol-related events generated in SSC mode and can lead to a protocol
interrupt. They are related to the start and the end of a data frame. After the start of a
data frame a new setting could be programmed for the next data frame and after the end
of a data frame the SSC connections to pins can be changed.
Please note that the bits in register PSR are not all automatically cleared by hardware
and have to be cleared by software in order to monitor new incoming events.
MSLS Interrupt:
This interrupt indicates in master mode (MSLS generation enabled) that a data frame
has started (activation of MSLS) and has been finished (deactivation of MSLS). Any
change of the internal MSLS signal sets bit PSR.MSLSEV and additionally, a protocol
interrupt can be generated if PCR.MSLSIEN = 1. The actual state of the internal
MSLS signal can be read out at PSR.MSLS to take appropriate actions when this
interrupt has been detected.
DX2T Interrupt:
This interrupt monitors edges of the input signal of the DX2 stage (although this
signal is not used as slave select input for data transfers).
A programmable edge detection for the DX2 input signal sets bit PSR.DX2TEV and
additionally, a protocol interrupt can be generated if PCR.DX2TIEN = 1. The actual
state of the selected input signal can be read out at PSR.DX2S to take appropriate
actions when this interrupt has been detected.
Parity Error Interrupt:
This interrupt indicates that there is a mismatch in the received parity bit (in
RBUFSR.PAR) with the calculated parity bit of the last received word of a data frame.

XMC4500
XMC4000 Family
17.4.3.6 End-of-Frame Control

The information about the frame length is required for the MSLS generator of the master
device. In addition to the mechanism based on the number of bits per frame (selected
with SCTR.FLE < 63), the following alternative mechanisms for end of frame handling
are supported. It is recommended to set SCTRFLE = 63 (if several end of frame
mechanisms are activated in parallel, the first end condition being found finishes the
frame).
Software-based start of frame indication TCSR.SOF:
This mechanism can be used if software handles the TBUF data without data FIFO.
If bit SOF is set, a valid content of TBUF is considered as first word of a new frame.
Bit SOF has to be set before the content of TBUF is transferred to the transmit shift
register, so it is recommended to write it before writing data to TBUF. A current data
word transfer is finished completely and the slave select delays Ttd and Tnf are
applied before starting a new data frame with Tld and the content of TBUF.
For software-handling of bit SOF, bit TCSR.WLEMD = 0 has to be programmed. In
this case, all TBUF[31:0] address locations show an identical behavior (TCI not taken
into account for data handling).
Software-based end of frame indication TCSR.EOF:
If bit EOF is set, a valid content of TBUF is considered as last word of a new frame.
Bit EOF has to be set before the content of TBUF is transferred to the transmit shift
register, so it is recommended to write it before writing data to TBUF. The data word
in TBUF is sent out completely and the slave select delays Ttd and Tnf are applied. A
new data frame can start with Tld with the next valid TBUF value.
For software-handling of bit EOF, bit TCSR.WLEMD = 0 has to be programmed. In
this case, all TBUF[31:0] address locations show an identical behavior (TCI not taken
into account for data handling).
Software-based address related end of frame handling:
If bit TCSR.WLEMD = 1, the address of the written TBUF[31:0] is used as transmit
control information TCI[4:0] to update SCTR.WLE (= TCI[3:0]) and TCSR.EOF
(= TCI[4]) for each data word. The written TBUF[31:0] address location defines the
word length and the end of a frame (locations TBUF[31:16] lead to a frame end).
For example, writing transmit data to TBUF[07] results in a data word of 8-bit length
without finishing the frame, whereas writing transmit data to TBUF[31] leads to a data
word length of 16 bits, followed by Ttd, the deactivation of MSLS and Tnf.
If TCSR.WLEMD = 1, bits TCSR.EOF and SOF, as well as SCTR.WLE must not be
written by software after writing data to a TBUF location. Furthermore, it is
recommended to clear bits TCSR.SELMD, FLEMD and WAMD.
FIFO-based address related end of frame handling:
This mechanism can be used if a data FIFO is used to store the transmit data. The
general behavior is similar to the software-based address related end of frame

XMC4500
XMC4000 Family
handling, except that transmit data is not written to the locations TBUF[31:0], but to
the FIFO input locations IN[31:0] instead. In this case, software must not write to any
of the TBUF locations.
TBUF related end of frame handling:
If bit PCR.FEM = 0, an end of frame is assumed if the transmit buffer TBUF does not
contain valid transmit data at the end of a data word transmission (TCSR.TDV = 0 or
in Stop Mode). In this case, the software has to take care that TBUF does not run
empty during a data frame in Run Mode. If bit PCR.FEM = 1, signal MSLS stays
active while the transmit buffer is waiting for new data (TCSR.TDV = 1 again) or until
Stop Mode is left.
Explicit end of frame by software:
The software can explicitly stop a frame by clearing bit PSR.MSLS by writing a 1 to
the related bit position in register PSCR. This write action immediately clears bit
PSR.MSLS, whereas the internal MSLS signal becomes inactive after finishing a
currently running word transfer and respecting the slave select delays Ttd and Tnf.

XMC4500
XMC4000 Family
17.4.4 Operating the SSC in Slave Mode

In order to operate the SSC in slave mode, the following issues have to be considered:
Select SSC mode:
It is recommended to configure all parameters of the SSC that do not change during
CCR.MODE = 0000B to avoid unintended edges of the input signals and the SSC
mode can be enabled afterwards by CCR.MODE = 0001B.
Pin connections:
Establish the connection of the input stage (DX0, DX3, DX4, DX5) with the selected
receive data input pin (DIN[3:0]) with DXnCR.INSW = 1 and configure the transmit
data output pin (DOUT[3:0]). One, two or four such connections may be needed
depending on the protocol. For half-duplex configurations, hardware port control can
be also used to establish the required connections.
Establish a connection of input stage DX1 with the selected shift clock input pin
(signal SCLKIN) with DX1CR.INSW = 1.
Establish a connection of input stage DX2 with the selected slave select input pin
(signal SELIN) with DX2CR.INSW = 1. If no slave select input signal is used, the DX2
stage has to deliver a 1-level to the data shift unit to allow data reception and
transmission. If a slave device is not selected (DX2 stage delivers a 0 to the data shift
unit) and a shift clock pulse are received, the incoming data is not received and the
DOUTx signal outputs the passive data level defined by SCTR.PDL.
The baud rate generator is not needed and can be switched off by the fractional
divider.
If required, the shift mode can be set up for reception and/or transmission of two or
four data bits at one time by programming the register SCTR.
Slave select generation:
The slave select delay generation is not needed and can be switched off. The bits
and bit fields MSLSEN, SELCTR, SELINV, CTQSEL1, PCTQ1, DCTQ1, MSLSIEN,
SELO[7:0], and TIWEN in register PCR are not necessary and can be programmed
to 0.
17.4.4.1 Protocol Interrupts

The following protocol-related events generated in SSC mode and can lead to a protocol
interrupt. They are related to the start and the end of a data frame. After the start of a
data frame a new setting could be programmed for the next data frame and after the end
of a data frame the SSC connections to pins can be changed.

XMC4500
XMC4000 Family
MSLS event:
The MSLS generation being switched off, this event is not available.
DX2T event:
The slave select input signal SELIN is handled by the DX2 stage and the edges of
the selected signal can generate a protocol interrupt. This interrupt allows to indicate
that a data frame has started and/or that a data frame has been completely finished.
A programmable edge detection for the DX2 input signal activates DX2T, sets bit
PSR.DX2TEV and additionally, a protocol interrupt can be generated if
PCR.DX2TIEN = 1. The actual state of the selected input signal can be read out at
PSR.DX2S to take appropriate actions when this interrupt has been detected.
Parity Error Interrupt:
This interrupt indicates that there is a mismatch in the received parity bit (in
RBUFSR.PAR) with the calculated parity bit of the last received word of a data frame.
17.4.4.2 End-of-Frame Control

In slave mode, the following possibilities exist to determine the frame length. The slave
device either has to refer to an external slave select signal, or to the number of received
data bits.
Frame length known in advance by the slave device, no slave select:
In this case bit field SCTR.FLE can be programmed to the known value (if it does not
exceed 63 bits). A currently running data word transfer is considered as finished if the
programmed frame length is reached.
Frame length not known by the slave, no slave select:
In this case, the slave devices software has to decide on data word base if a frame
is finished. Bit field SCTR.FLE can be either programmed to the word length
SCTR.WLE, or to its maximum value to disable the slave internal frame length
evaluation by counting received bits.
Slave device addressed via slave select signal SELIN:
If the slave device is addressed by a slave select signal delivered by the
communication master, the frame start and end information are given by this signal.
In this case, bit field SCTR.FLE should be programmed to its maximum value to
disable the slave internal frame length evaluation.

XMC4500
XMC4000 Family
17.4.5 SSC Protocol Registers

In SSC mode, the registers PCR and PSR handle SSC related information.
17.4.5.1 SSC Protocol Control Registers

In SSC mode, the PCR register bits or bit fields are defined as described in this section.
PCR
Protocol Control Register [SSC Mode]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MCL TIW
0 SELO
K EN
rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DX2 MSL PARI SELI SEL MSL
DCTQ1 PCTQ1 CTQSEL1 FEM
TIEN SIEN EN NV CTR SEN
rw rw rw rw rw rw rw rw rw rw

MSLSEN 0 rw MSLS Enable
This bit enables/disables the generation of the master
slave select signal MSLS. If the SSC is a transfer slave,
the SLS information is read from a pin and the internal
generation is not needed. If the SSC is a transfer master,
it has to provide the MSLS signal.
0B The MSLS generation is disabled (MSLS = 0).
This is the setting for SSC slave mode.
1B The MSLS generation is enabled.
This is the setting for SSC master mode.
SELCTR 1 rw Select Control
This bit selects the operating mode for the SELO[7:0]
outputs.
0B The coded select mode is enabled.
1B The direct select mode is enabled.

XMC4500
XMC4000 Family

SELINV 2 rw Select Inversion
This bit defines if the polarity of the SELO[7:0] outputs in
relation to the master slave select signal MSLS.
0B The SELO outputs have the same polarity as the
MSLS signal (active high).
1B The SELO outputs have the inverted polarity to the
MSLS signal (active low).
FEM 3 rw Frame End Mode
This bit defines if a transmit buffer content that is not valid
for transmission is considered as an end of frame
condition for the slave select generation.
0B The current data frame is considered as finished
when the last bit of a data word has been sent out
and the transmit buffer TBUF does not contain new
data (TDV = 0).
1B The MSLS signal is kept active also while no new
data is available and no other end of frame condition
is reached. In this case, the software can accept
delays in delivering the data without automatic
deactivation of MSLS in multi-word data frames.
CTQSEL1 [5:4] rw Input Frequency Selection
This bit field defines the input frequency fCTQIN for the
generation of the slave select delays Tiw and Tnf.
00B fCTQIN = fPDIV
01B fCTQIN = fPPP
10B fCTQIN = fSCLK
11B fCTQIN = fMCLK
PCTQ1 [7:6] rw Divider Factor PCTQ1 for Tiw and Tnf
This bit field represents the divider factor PCTQ1
(range = 0 - 3) for the generation of the inter-word delay
and the next-frame delay.
Tiw = Tnf = 1/fCTQIN x (PCTQ1 + 1) x (DCTQ1 + 1)
DCTQ1 [12:8] rw Divider Factor DCTQ1 for Tiw and Tnf
This bit field represents the divider factor DCTQ1
(range = 0 - 31) for the generation of the inter-word delay
and the next-frame delay.
Tiw = Tnf = 1/fCTQIN x (PCTQ1 + 1) x (DCTQ1 + 1)

XMC4500
XMC4000 Family

PARIEN 13 rw Parity Error Interrupt Enable
This bit enables/disables the generation of a protocol
interrupt with the detection of a parity error.
0B A protocol interrupt is not generated with the
detection of a parity error.
1B A protocol interrupt is generated with the detection
of a parity error.
MSLSIEN 14 rw MSLS Interrupt Enable
interrupt if the state of the MSLS signal changes (indicated
by PSR.MSLSEV = 1).
0B A protocol interrupt is not generated if a change of
signal MSLS is detected.
1B A protocol interrupt is generated if a change of
signal MSLS is detected.
DX2TIEN 15 rw DX2T Interrupt Enable
interrupt if the DX2T signal becomes activated (indicated
by PSR.DX2TEV = 1).
0B A protocol interrupt is not generated if DX2T is
activated.
1B A protocol interrupt is generated if DX2T is
activated.
SELO [23:16] rw Select Output
This bit field defines the setting of the SELO[7:0] output
lines.
0B The corresponding SELOx line cannot be activated.
1B The corresponding SELOx line can be activated
(according to the mode selected by SELCTR).
TIWEN 24 rw Enable Inter-Word Delay Tiw
This bit enables/disables the inter-word delay Tiw after the
transmission of a data word.
0B No delay between data words of the same frame.
1B The inter-word delay Tiw is enabled and introduced
between data words of the same frame.

XMC4500
XMC4000 Family

This bit enables/disables the generation of the master
clock output signal MCLK, independent from master or
slave mode.
0B The MCLK generation is disabled and output
MCLK = 0.
Returns 0 if read; should be written with 0.

XMC4500
XMC4000 Family
17.4.5.2 SSC Protocol Status Register

In SSC mode, the PSR register bits or bit fields are defined as described in this section.
The bits and bit fields in register PSR are not cleared by hardware.
The PSR flags should be cleared by software before enabling a new protocol.
PSR
Protocol Status Register [SSC Mode] (48H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
BRG
0
IF
r rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PAR DX2 MSL DX2 MSL
AIF RIF TBIF TSIF DLIF RSIF 0
ERR TEV SEV S S
rwh rwh rwh rwh rwh rwh r rwh rwh rwh rwh rwh

MSLS 0 rwh MSLS Status
This bit indicates the current status of the MSLS
signal. It must be cleared by software to stop a
running frame.
0B The internal signal MSLS is inactive (0).
1B The internal signal MSLS is active (1).
DX2S 1 rwh DX2S Status
This bit indicates the current status of the DX2S
signal that can be used as slave select input SELIN.
0B DX2S is 0.
1B DX2S is 1.
MSLSEV 2 rwh MSLS Event Detected1)
This bit indicates that the MSLS signal has changed
its state since MSLSEV has been cleared. Together
with the MSLS status bit, the activation/deactivation
of the MSLS signal can be monitored.
0B The MSLS signal has not changed its state.
1B The MSLS signal has changed its state.

XMC4500
XMC4000 Family

DX2TEV 3 rwh DX2T Event Detected1)
This bit indicates that the DX2T trigger signal has
been activated since DX2TEV has been cleared.
0B The DX2T signal has not been activated.
1B The DX2T signal has been activated.
PARERR 4 rwh Parity Error Event Detected1)
This bit indicates that there is a mismatch in the
received parity bit (in RBUFSR.PAR) with the
calculated parity bit of the last received word of the
data frame.
0B A parity error event has not been activated.
1B A parity error event has been activated.
0 [9:5], r Reserved
[31:17] Returns 0 if read; not modified in SSC mode.
1) This status bit can generate a protocol interrupt in SSC mode (see Page 17-21). The general interrupt status
flags are described in the general interrupt chapter.

XMC4500
XMC4000 Family
17.4.6 SSC Timing Considerations

The input and output signals have to respect certain timings in order to ensure correct
data reception and transmission. In addition to module internal timings (due to input
filters, reaction times on events, etc.), also the timings from the input pin via the input
stage (Tin) to the module and from the module via the output driver stage to the pin (Tout),
as well as the signal propagation on the wires (Tprop) have to be taken into account.
Please note that there might be additional delays in the DXn input stages, because the
digital filter and the synchronization stages lead to systematic delays, that have to be
considered if these functions are used.
17.4.6.1 Closed-loop Delay

A system-inherent limiting factor for the baud rate of an SSC connection is the closed-
loop delay. In a typical application setup, a communication master device is connected
to a slave device in full-duplex mode with independent lines for transmit and receive
data. In a general case, all transmitters refer to one shift clock edge for transmission and
all receivers refer to the other shift clock edge for reception. The master devices SSC
module sends out the transmit data, the shift clock and optionally the slave select signal.
Therefore, the baud rate generation (BRG) and slave select generation (SSG) are part
of the master device. The frame control is similar for SSC modules in master and slave
mode, the main difference is the fact which module generates the shift clock and
optionally, the slave select signals.
SSC Master Device SSC Slave Device
SSC Master SSC Slave

Module To u t Tin Module
MTSR Tp ro p
TBUF RBUF
Tin To u t
MRST Tp ro p
RBUF TBUF
Frame Frame
Control Control
To u t Tin
Shift Clock Tp ro p
BRG
To u t Tin
Slave Select Tp ro p
SSG
Figure 17-45 SSC Closed-loop Delay

XMC4500
XMC4000 Family
The signal path between the SSC modules of the master and the slave device includes
the masters output driver, the wiring to the slave device and the slave devices input
stage. With the received shift clock edges, the slave device receives the masters
transmit data and transmits its own data back to the master device, passing by a similar
signal path in the other direction. The master module receives the slaves transmit data
related to its internal shift clock edges. In order to ensure correct data reception in the
master device, the slaves transmit data has to be stable (respecting setup and hold
times) as master receive data with the next shift clock edge of the master (generally 1/2
shift clock period). To avoid data corruption, the accumulated delays of the input and
output stages, the signal propagation on the wiring and the reaction times of the
transmitter/receiver have to be carefully considered, especially at high baud rates.
In the given example, the time between the generation of the shift clock signal and the
evaluation of the receive data by the master SSC module is given by the sum of Tout_master
+ 2 x Tprop + Tin_slave + Tout_slave + Tin_master + module reaction times + input setup times.
The input path is characterized by an input delay depending mainly on the input stage
characteristics of the pads. The output path delay is determined by the output driver
delay and its slew rate, the external load and current capability of the driver. The device
specific values for the input/output driver are given in the Data Sheet.

XMC4500
XMC4000 Family
Figure 17-46 describes graphically the closed-loop delay and the effect of two delay
compensation options discussed in Section 17.4.6.2 and Section 17.4.6.3.
1) Without any delay compensation
SCLK at master
(Output driver stage )
MTSR at master
Master Data
Tout_master + Tprop + Tin_slave
SCLK at slave
(input driver stage )
MRST at slave
Slave Data
Delay may lead to a wrong

slave data being latched in
MRST at master
Slave Data
(Input driver stage )
Tout_slave+ Tprop + Tin_master
2) With master mode delay compensation
SCLK at master
(Receive data path )
For both cases with delay

compensation , slave data is
3) With complete closed loop delay latched in correctly
compensation
SCLK at master
(Receive data path)
Figure 17-46 SSC Closed-loop Delay Timing Waveform

XMC4500
XMC4000 Family
17.4.6.2 Delay Compensation in Master Mode

A higher baud rate can be reached by delay compensation in master mode. This
compensation is possible if (at least) the shift clock pin is bidirectional.

Module To u t Tin Module
MTSR Tp ro p
TBUF RBUF
Tin To u t
MRST Tp ro p
RBUF TBUF
Frame Frame
Control Control
Tin
Shift Clock Tp ro p
BRG
Tin
Slave Select Tp ro p
SSG
Figure 17-47 SSC Master Mode with Delay Compensation

If the receive shift clock signal in master mode is directly taken from the input function in
parallel to the output signal, the output delay of the master devices shift clock output is
compensated and only the difference between the input delays of the master and the
slave devices have to be taken into account instead of the complete masters output
delay and the slaves input delay of the shift clock path. The delay compensation is
enabled with DX1CR.DCEN = 1 while DX1CR.INSW = 0 (transmit shift clock is taken
from the baud-rate generator).
In the given example, the time between the evaluation of the shift clock signal and the
receive data by the master SSC module is reduced by Tin_master + Tout_master.
Although being a master mode, the shift clock input and optionally the slave select signal
are not directly connected internally to the data shift unit, but are taken as external
signals from input pins. The delay compensation does not lead to additional pins for the
SSC communication if the shift clock output pin (slave select output pin, respectively)
is/are bidirectional. In this case, the input signal is decoupled from other internal signals,
because it is related to the signal level at the pin itself.

XMC4500
XMC4000 Family
17.4.6.3 Complete Closed-loop Delay Compensation

Alternatively, the complete closed-loop delay can be compensated by using one
additional pin on both the SSC master and slave devices for the SSC communication.

Module To ut Tin Module
MTSR Tp ro p
TBUF RBUF
Tin Tou t
MRST Tprop
RBUF TBUF
Tin Tou t
Shift Clock Tp ro p
Frame (for Master Frame
Control Receive ) Control
Tin
Shift Clock Tprop
BRG
Tin
Slave Select Tprop
SSG
Figure 17-48 SSC Complete Closed-loop Delay Compensation

The principle behind this delay compensation method is to have the slave feedback the
shift clock back to the master, which uses it as the receive shift clock. By going through
a complete closed-loop signal path, the receive shift clock is thus fully compensated.
The slave has to setup the SCLKOUT pin function to output the shift clock by setting the
bit BRG.SCLKOSEL to 1, while the master has to setup the DX1 pin function to receive
the shift clock from the slave and enable the delay compensation with DX1CR.DCEN = 1
and DX1CR.INSW = 0.

XMC4500
XMC4000 Family
17.5 Inter-IC Bus Protocol (IIC)

The IIC protocol of the USIC refers to the IIC bus specification [17]. Contrary to that
specification, the USIC device assumes rise/fall times of the bus signals of max. 300 ns
in all modes. Please refer to the pad characteristics in the AC/DC chapter for the driver
capability. CBUS mode and HS mode are not supported.
The IIC mode is selected by CCR.MODE = 0100B with CCFG.IIC = 1 (IIC mode
available).
17.5.1 Introduction
USIC IIC Features:
Two-wire interface, with one line for shift clock transfer and synchronization (shift
clock SCL), the other one for the data transfer (shift data SDA)
Communication in standard mode (100 kBit/s) or in fast mode (up to 400 kBit/s)
Support of 7-bit addressing, as well as 10-bit addressing
Master mode operation,
where the IIC controls the bus transactions and provides the clock signal.
Slave mode operation,
where an external master controls the bus transactions and provides the clock signal.
Multi-master mode operation,
where several masters can be connected to the bus and bus arbitration can take
place, i.e. the IIC module can be master or slave. The master/slave operation of an
IIC bus participant can change from frame to frame.
Efficient frame handling (low software effort), also allowing DMA transfers
Powerful interrupt handling due to multitude of indication flags
Compensation support for input delays
17.5.1.1 Signal Description

An IIC connection is characterized by two wires (SDA and SCL). The output drivers for
these signals must have open-drain characteristics to allow the wired-AND connection
of all SDA lines together and all SCL lines together to form the IIC bus system. Due to
this structure, a high level driven by an output stage does not necessarily lead
immediately to a high level at the corresponding input. Therefore, each SDA or SCL
connection has to be input and output at the same time, because the input function
always monitors the level of the signal, also while sending.
Shift data SDA: input handled by DX0 stage, output signal DOUT0
Shift clock SCL: input handled by DX1 stage, output signal SCLKOUT
Figure 17-29 shows a connection of two IIC bus participants (modules IIC A and IIC B)
using the USIC. In this example, the pin assignment of module IIC A shows separate pins
for the input and output signals for SDA and SCL. This assignment can be used if the
application does not provide pins having DOUT0 and a DX0 stage input for the same pin

XMC4500
XMC4000 Family
(similar for SCLKOUT and DX1). The pin assignment of module IIC B shows the
connection of DOUT0 and a DX0 input at the same pin, also for SCLKOUT and a DX1
input.
IIC Module A IIC Module B
TBUF TBUF
RBUF SCLKOUT + 3.3 V RBUF
SCLKOUT
SCLKIN SCLKIN
DX1 DX1
Transfer SCL Transfer
Protocol Protocol
DOUT0 + 3.3 V
PPP PPP
IIC DOUT0 IIC
DIN0 DIN0
DX0 DX0
SDA
Baud Rate fPB ffSYS Baud Rate

PB
Generator Generator
(IIC A) (IIC
(IIC A)B)
Figure 17-49 IIC Signal Connections
17.5.1.2 Symbols
A symbol is a sequence of edges on the lines SDA and SCL. Symbols contain 10 or 25
time quanta tq, depending on the selected baud rate. The baud rate generator
determines the length of the time quanta tq, the sequence of edges in a symbol is
handled by the IIC protocol pre-processor, and the sequence of symbols can be
programmed by the user according to the application needs.
The following symbols are defined:
Bus idle:
SDA and SCL are high. No data transfer takes place currently.
Data bit symbol:
SDA stable during the high phase of SCL. SDA then represents the transferred bit
value. There is one clock pulse on SCL for each transferred bit of data. During data
transfers SDA may only change while SCL is low.

XMC4500
XMC4000 Family
Start symbol:
Signal SDA being high followed by a falling edge of SDA while SCL is high indicates
a start condition. This start condition initiates a data transfer over the IIC bus after the
bus has been idle.
Repeated start symbol:
This start condition initiates a data transfer over the bus after a data symbol when the
bus has not been idle. Therefore, SDA is set high and SCL low, followed by a start
symbol.
Stop symbol:
A rising edge on SDA while SCL is high indicates a stop condition. This stop condition
terminates a data transfer to release the bus to idle state. Between a start condition
and a stop condition an arbitrary number of bytes may be transferred.
17.5.1.3 Frame Format

Data is transferred by the 2-line IIC bus (SDA, SCL) using a protocol that ensures reliable
and efficient transfers. The sender of a (data) byte receives and checks the value of the
following acknowledge field. The IIC being a wired-AND bus system, a 0 of at least one
device leads to a 0 on the bus, which is received by all devices.
A data word consists of 8 data bit symbols for the data value, followed by another data
bit symbol for the acknowledge bit. The data word can be interpreted as address
information (after a start symbol) or as transferred data (after the address).
In order to be able to receive an acknowledge signal, the sender of the data bits has to
release the SDA line by sending a 1 as acknowledge value. Depending on the internal
state of the receiver, the acknowledge bit is either sent active or passive.
1
SDA D7 D6 Dx D0 P
Master 0
SCL 1
Master 1 2 8 9
0
1
SDA
Slave
0
SCL 1
Slave
0
Start Data Word Ack Stop
Figure 17-50 IIC Frame Example (simplified)

XMC4500
XMC4000 Family
17.5.2 Operating the IIC

In order to operate the IIC protocol, the following issues have to be considered:
Select IIC mode:
It is recommended to configure all parameters of the IIC that do not change during
run time while CCR.MODE = 0000B. Bit field SCTR.TRM = 11B should be
CCR.MODE = 0000B to avoid unintended edges of the input signals and the IIC
Pin connections:
Establish a connection of input stage DX0 (with DX0CR.DPOL = 0) to the selected
shift data pin SDA (signal DIN0) with DX0CR.INSW = 0 and configure the transmit
data output signal DOUT0 (with SCTR.DOCFG = 00B) to the same pin. If available,
this can be the same pin for input and output, or connect the selected input pin and
the output pin to form the SDA line.
The same mechanism applies for the shift clock line SCL. Here, signal SCLKOUT
(with BRG.SCLKCFG = 00B) and an input of the DX1 stage have to be connected
(with DX1CR.DPOL = 0).
The input stage DX2 is not used for the IIC protocol.
If the digital input filters are enabled in the DX0/1 stages, their delays have to be
taken into account for correct calculation of the signal timings.
The pins used for SDA and SCL have to be set to open-drain mode to support the
wired-AND structure of the IIC bus lines.
Note that the basic I/O port configuration for the IIC I/O pins must also setup correctly
before the IIC mode becomes enabled by CCR.MODE = 0100B.
Bit timing configuration:
In standard mode (100 kBit/s) a minimum module frequency of 2 MHz is necessary,
whereas in fast mode (400 kBit/s) a minimum of 10 MHz is required. Additionally, if
the digital filter stage should be used to eliminate spikes up to 50 ns, a filter frequency
of 20 MHz is necessary.
There could be an uncertainty in the SCL high phase timing of maximum 1/fPPP if
another IIC participant lengthens the SCL low phase on the bus.
More details are given in Section 17.5.3.
The data format has to be configured for 8 data bits (SCTR.WLE = 7), unlimited data
flow (SCTR.FLE = 3FFH), and MSB shifted first (SCTR.SDIR = 1). The parity
generation has to be disabled (CCR.PM = 00B).
General hints:
The IIC slave module becomes active (for reception or transmission) if it is selected
by the address sent by the master. In the case that the slave sends data to the
master, it uses the transmit path. So a master must not request to read data from the
slave address defined for its own channel in order to avoid collisions.
The built-in error detection mechanisms are only activated while the IIC module is

XMC4500
XMC4000 Family
taking part in IIC bus traffic.

If the slave can not deal with too high frequencies, it can lengthen the low phase of
the SCL signal.
For data transfers according to the IIC specification, the shift data line SDA shall only
change while SCL = 0 (defined by IIC bus specification).
17.5.2.1 Transmission Chain

The IIC bus protocol requiring a kind of in-bit-response during the arbitration phase and
while a slave is transmitting, the resulting loop delay of the transmission chain can limit
the reachable maximal baud rate, strongly depending on the bus characteristics (bus
load, module frequency, etc.).
Figure 17-49 shows the general signal path and the delays in the case of a slave
transmission. The shift clock SCL is generated by the master device, output on the wire,
then it passes through the input stage and the input filter. Now, the edges can be
detected and the SDA data signal can be generated accordingly. The SDA signal passes
through the output stage and the wire to the master receiver part. There, it passes
through the input stage and the input filter before it is sampled.
This complete loop has to be finished (including all settling times to obtain stable signal
levels) before the SCL signal changes again. The delays in this path have to be taken
into account for the calculation of the baud rate as a function of fPB and fPPP.
17.5.2.2 Byte Stretching

If a device is selected as transceiver and should transmit a data byte but the transmit
buffer TBUF does not contain valid data to be transmitted, the device ties down SCL = 0
at the end of the previous acknowledge bit. The waiting period is finished if new valid
data has been detected in TBUF.
17.5.2.3 Master Arbitration

During the address and data transmission, the master transmitter checks at the rising
edge of SCL for each data bit if the value it is sending is equal to the value read on the
SDA line. If yes, the next data bit values can be 0. If this is not the case (transmitted
value = 1, value read = 0), the master has lost the transmit arbitration. This is indicated
by status flag PSR.ARL and can generate a protocol interrupt if enabled by
PCR.ARLIEN.
When the transmit arbitration has been lost, the software has to initialize the complete
frame again, starting with the first address byte together with the start condition for a new
master transmit attempt. Arbitration also takes place for the ACK bit.

XMC4500
XMC4000 Family
17.5.2.4 Release of TBUF

In case of a non-acknowledge or an error, the content of TBUF becomes invalid. In both
cases, the software has to flush the transmit buffer and to set it up again with appropriate
values to react on the previous event.

In multi-master mode, only run mode 0 and stop mode 0 are supported, the other modes
must not be programmed.
Run Mode 0:
Behavior as programmed. If TCSR.TDV = 0 (no new valid TBUF entry found) when
a new TBUF entry needs to be processed, the IIC module waits for TDV becoming
set to continue operation.
Run Mode 1:
Behavior as programmed. If in master mode, TCSR.TDV = 0 (no new valid TBUF
entry found) when a new TBUF entry needs to be processed, the IIC module sends
a stop condition to finish the frame. In slave mode, no difference to run mode 0.
Stop Mode 0:
Bit TCSR.TDV is internally considered as 0 (the bit itself is not modified by the stop
mode). A currently running word is finished normally, but no new word is started in
case of master mode (wait for TDV active).
Bit TDV being considered as 0 for master and slave, the slave will force a wait state
on the bus if read by an external master, too.
Additionally, it is not possible to force the generation of a STOP condition out of the
wait state. The reason is, that a master read transfer must be finished with a not-
acknowledged followed by a STOP condition to allow the slave to release his SDA
line. Otherwise the slave may force the SDA line to 0 (first data bit of next byte)
making it impossible to generate the STOP condition (rising edge on SDA).
To continue operation, the mode must be switched to run mode 0
Stop Mode 1:
Same as stop mode 0, but additionally, a master sends a STOP condition to finish
the frame.
If stop mode 1 is requested for a master device after the first byte of a 10 bit address,
a stop condition will be sent out. In this case, a slave device will issue an error
interrupt.

The data transfer interrupts indicate events related to IIC frame handling. As the data
input and output pins are the same in IIC protocol, a IIC transmitter also receives the
output data at its input pin. However, no receive related interrupts will be generated in
this case.

XMC4500
XMC4000 Family
Transmit buffer event:

The transmit buffer event indication flag PSR.TBIF is set when the content of the
transmit buffer TBUF has been loaded to the transmit shift register, indicating that the
action requested by the TBUF entry has started.
With this event, bit TCSR.TDV is cleared. This interrupt can be used to write the next
TBUF entry while the last one is in progress (handled by the transmitter part).
Receive event:
This receive event indication flag PSR.RIF indicates that a new data byte has been
written to the receive buffer RBUF0/1 (except for the first data byte of a new frame,
that is indicated by an alternative receive interrupt). The flag becomes set when the
data byte is received (after the falling edge of SCL). This interrupt can be used to read
out the received data while a new data byte can be in progress (handled by the
receiver part).
Alternate receive event:
The alternative receive event indication flag AIF is based on bit RBUFSR[9] (same
as RBUF[9]), indicating that the received data word has been the first data word of a
new data frame.
Transmit shift event:
The transmit shift event indication flag TSIF is set after the start of the last data bit of
a data byte.
Receive start event:
The receive start event indication flag RSIF is set after the sample point of the first
data bit of a data byte.
Note: The transmit shift and receive start events can be ignored if the application does
not require them during the IIC data transfer.
17.5.2.7 IIC Protocol Interrupt Events

The following protocol-related events are generated in IIC mode and can lead to a
protocol interrupt.
start condition received at a correct position in a frame (PSR.SCR)
repeated start condition received at a correct position in a frame (PSR.RSCR)
stop condition transferred at a correct position in a frame (PSR.PCR)
master arbitration lost (PSR.ARL)
slave read requested (PSR.SRR)
acknowledge received (PSR.ACK)
non-acknowledge received (PSR.NACK)
start condition not at the expected position in a frame (PSR.ERR)
stop condition not at the expected position in a frame (PSR.ERR)

XMC4500
XMC4000 Family
as slave, 10-bit address interrupted by a stop condition after the first address byte
(PSR.ERR)
TDF slave code in master mode (PSR.WTDF)
TDF master code in slave mode (PSR.WTDF)
Reserved TDF code found (PSR.WDTF)
Start condition code during a running frame in master mode (PSR.WTDF)
Data byte transmission code after transfer direction has been changed to reception
(master read) in master mode (PSR.WTDF)
If a wrong TDF code is found in TBUF, the error event is active until the TDF value is
either corrected or invalidated. If the related interrupt is enabled, the interrupt handler
should check PSR.WDTF first and correct or invalidate TBUF, before dealing with the
other possible interrupt events.

17.5.2.9 Receiver Address Acknowledge

After a (repeated) start condition, the master sends a slave address to identify the target
device of the communication. The start address can comprise one or two address bytes
(for 7 bit or for 10 bit addressing schemes). After an address byte, a slave sensitive to
the transmitted address has to acknowledge the reception.
Therefore, the slaves address can be programmed in the device, where it is compared
to the received address. In case of a match, the slave answers with an acknowledge
(SDA = 0). Slaves that are not targeted answer with an non-acknowledge (SDA = 1).
In addition to the match of the programmed address, another address byte value has to
be answered with an acknowledge if the slave is capable to handle the corresponding
requests. The address byte 00H indicates a general call address, that can be
acknowledged. The value 01H stands for a start byte generation, that is not
acknowledged
In order to allow selective acknowledges for the different values of the address byte(s),
the following control mechanism is implemented:
The address byte 00H is acknowledged if bit PCR.ACK00 is set.
The address byte 01H is not acknowledged.
The first 7 bits of a received first address byte are compared to the programmed slave
address (PCR.SLAD[15:9]). If these bits match, the slave sends an acknowledge. In
addition to this, if the slave address is programmed to 1111 0XXB, the slave device
waits for a second address byte and compares it also to PCR.SLAD[7:0] and sends
an acknowledge accordingly to cover the 10 bit addressing mode. The user has to

XMC4500
XMC4000 Family
take care about reserved addresses (refer to IIC specification for more detailed
description). Only the address 1111 0XXB is supported.
Under each of these conditions, bit PSR.SLSEL will be set when the addressing
delivered a match. This bit is cleared automatically by a (repeated) start condition.
17.5.2.10 Receiver Handling

A selected slave receiver always acknowledges a received data byte. If the receive
buffers RBUF0/1 are already full and can not accept more data, the respective register
is overwritten (PSR.DLI becomes set in this case and a protocol interrupt can be
generated).
An address reception also uses the registers RBUF0/1 to store the address before
checking if the device is selected. The received addresses do not set RDV0/1, so the
addresses are not handled like received data.
17.5.2.11 Receiver Status Information

In addition to the received data byte, some IIC protocol related information is stored in
the 16-bit data word of the receive buffer. The received data byte is available at the bit
positions RBUF[7:0], whereas the additional information is monitored at the bit positions
RBUF[12:8]. This structure allows to identify the meaning of each received data byte
without reading additional registers, also when using a FIFO data buffer.
RBUF[8]:
Value of the received acknowledge bit. This information is also available in
RBUFSR[8] as protocol argument.
RBUF[9]:
A 1 at this bit position indicates that after a (repeated) start condition followed by the
address reception the first data byte of a new frame has been received. A 0 at this bit
position indicates further data bytes. This information is also available in RBUFSR[9],
allowing different interrupt routines for the address and data handling.
RBUF[10]:
A 1 at this bit position indicates that the data byte has been received when the device
has been in slave mode, whereas a 0 indicates a reception in master mode.
RBUF[11]:
A 1 at this bit position indicates an incomplete/erroneous data byte in the receive
buffer caused by a wrong position of a START or STOP condition in the frame. The
bit is not identical to the frame error status bit in PSR, because the bit in the PSR has
to be cleared by software (sticky bit), whereas RBUF[11] is evaluated data byte by
data byte. If RBUF[11] = 0, the received data byte has been correct, independent of
former errors.
RBUF[12]:
A 0 at this bit position indicates that the programmed address has been received. A
1 indicates a general call address.

XMC4500
XMC4000 Family
17.5.3 Symbol Timing

The symbol timing of the IIC is determined by the master stimulating the shift clock line
SCL. It is different for standard and fast IIC mode.
100 kBaud standard mode (PCR.STIM = 0):
The symbol timing is based on 10 time quanta tq per symbol. A minimum module
clock frequency fPB = 2 MHz is required.
400 kBaud standard mode (PCR.STIM = 1):
The symbol timing is based on 25 time quanta tq per symbol. A minimum module
clock frequency fPB = 10 MHz is required.
The baud rate setting should only be changed while the transmitter and the receiver are
idle or CCR.MODE = 0. The bits in register BRG define the length of a time quantum tq
that is given by one period of fPCTQ.
BRG.CTQSEL
to define the input frequency fCTQIN for the time quanta generation
BRG.PCTQ
to define the length of a time quantum (division of fCTQIN by 1, 2, 3, or 4)
BRG.DCTQ
to define the number of time quanta per symbol (number of tq = DCTQ + 1)
The standard setting is given by CTQSEL = 00B (fCTQIN = fPDIV) and PPPEN = 0
(fPPP = fIN). Under these conditions, the frequency fPCTQ is given by:
1 1
fPCTQ = fPIN (17.10)
PDIV + 1 PCTQ + 1
To respect the specified SDA hold time of 300 ns after a falling edge of signal SCL, a
hold delay tHDEL has been introduced. It also prevents an erroneous detection of a start
or a stop condition. The length of this delay can be programmed by bit field PCR.HDEL.
Taking into account the input sampling and output update, bit field HDEL can be
programmed according to:
fPPP
HDEL 300 ns fPPP - 3 +1 with digital filter and HDELmin = 2
fPB
(17.11)
f
HDEL 300 ns fPPP - 3 PPP + 2 without digital filter and HDELmin = 1
fPB
If the digital input filter is used, HDEL compensates the filter delay of 2 filter periods (fPPP
should be used) in case of a spike on the input signal. This ensures that a data bit on the
SDA line changing just before the rising edge or behind the falling edge of SCL will not
be treated as a start or stop condition.

XMC4500
XMC4000 Family
17.5.3.1 Start Symbol

Figure 17-51 shows the general start symbol timing.
Start Symbol
Bus Idle
SDA
SCL
Standard .... ....

Mode X 0 4 5 9 X
tq
Fast .... ....
Mode X 0 15 16 24 X
Figure 17-51 Start Symbol Timing
17.5.3.2 Repeated Start Symbol

During the first part of a repeated start symbol, an SCL low value is driven for the
specified number of time quanta. Then a high value is output. After the detection of a
rising edge at the SCL input, a normal start symbol is generated, as shown in
Figure 17-52.
Repeated Start Symbol
Start Symbol
SDA
tH D EL
SCL
Standard .... .... ....

X 0 4 0 4 5 9 X
Mode
tq
Fast .... ....
Mode X 0 15 0 15 16 24 X
Figure 17-52 Repeated Start Symbol Timing

XMC4500
XMC4000 Family
17.5.3.3 Stop Symbol

Figure 17-53 shows the stop symbol timing.
Stop Symbol
Bus Idle
SDA
tH D EL
SCL
Standard .... ....

Mode X 0 4 5 9 X
tq
Fast .... ....
Mode X 0 15 16 24 X
Figure 17-53 Stop Symbol Timing
17.5.3.4 Data Bit Symbol

Figure 17-54 shows the general data bit symbol timing.
Data Bit Symbol
SDA
tH D EL
SCL
Standard .... ....

X 0 4 5 9 X
Mode
tq
Fast .... ....
X 0 15 16 24 X
Mode
Figure 17-54 Data Bit Symbol

Output SDA changes after the time tHDEL defined by PCR.HDEL has elapsed if a falling
edge is detected at the SCL input to respect the SDA hold time. The value of PCR.HDEL
allows compensation of the delay of the SCL input path (sampling, filtering).

XMC4500
XMC4000 Family
In the case of an acknowledge transmission, the USIC IIC waits for the receiver
indicating that a complete byte has been received. This adds an additional delay of 3
periods of fPB to the path. The minimum module input frequency has to be selected
properly to ensure the SDA setup time to SCL rising edge.
17.5.4 Data Flow Handling

The handling of the data flow and the sequence of the symbols in an IIC frame is
controlled by the IIC transmitter part of the USIC communication channel. The IIC bus
protocol is byte-oriented, whereas a USIC data buffer word can contain up to 16 data
bits. In addition to the data byte to be transmitted (located at TBUF[7:0]), bit field TDF
(transmit data format) to control the IIC sequence is located at the bit positions
TBUF[10:8]. The TDF code defines for each data byte how it should be transmitted (IIC
master or IIC slave), and controls the transmission of (repeated) start and stop symbols.
This structure allows the definition of a complete IIC frame for an IIC master device only
by writing to TBUFx or by using a FIFO data buffer mechanism, because no other control
registers have to be accessed. Alternatively, polling of the ACK and NACK bits in PSR
register can be performed, and the next data byte is transmitted only after an ACK is
received.
If a wrong or unexpected TDF code is encountered (e.g. due to a software error during
setup of the transmit buffer), a stop condition will be sent out by the master. This leads
to an abort of the currently running frame. A slave module waits for a valid TDF code and
sets SCL = 0. The software then has to invalidate the unexpected TDF code and write a
valid one.
Please note that during an arbitration phase in multi-master bus systems an
unpredictable bus behavior may occur due to an unexpected stop condition.
17.5.4.1 Transmit Data Formats

The following transmit data formats are available in master mode:
Table 17-12 Master Transmit Data Formats

TDF Code Description
000B Send data byte as master
This format is used to transmit a data byte from the master to a slave.
The transmitter sends its data byte (TBUF[7:0]), receives and checks
the acknowledge bit sent by the slave.
010B Receive data byte and send acknowledge
This format is used by the master to read a data byte from a slave. The
master acknowledges the transfer with a 0-level to continue the
transfer. The content of TBUF[7:0] is ignored.

XMC4500
XMC4000 Family
Table 17-12 Master Transmit Data Formats (contd)

011B Receive data byte and send not-acknowledge
This format is used by the master to read a data byte from a slave. The
master does not acknowledge the transfer with a 1-level to finish the
transfer. The content of TBUF[7:0] is ignored.
100B Send start condition
If TBUF contains this entry while the bus is idle, a start condition will be
generated. The content of TBUF[7:0] is taken as first address byte for
the transmission (bits TBUF[7:1] are the address, the LSB is the
read/write control).
101B Send repeated start condition
If TBUF contains this entry and SCL = 0 and a byte transfer is not in
progress, a repeated start condition will be sent out if the device is the
current master. The current master is defined as the device that has set
the start condition (and also won the master arbitration) for the current
message. The content of TBUF[7:0] is taken as first address byte for
the transmission (bits TBUF[7:1] are the address, the LSB is the
read/write control).
110B Send stop condition
If the current master has finished its last byte transfer (including
acknowledge), it sends a stop condition if this format is in TBUF. The
content of TBUF[7:0] is ignored.
111B Reserved
This code must not be programmed. No additional action except
releasing the TBUF entry and setting the error bit in PSR (that can lead
to a protocol interrupt).
The following transmit data format is available in slave mode (the symbols in a frame are
controlled by the master and the slave only has to send data if it has been asked by the
master):
Table 17-13 Slave Transmit Data Format

001B Send data byte as slave
This format is used to transmit a data byte from a slave to the master.
The transmitter sends its data byte (TBUF[7:0]) plus the acknowledge
bit as a 1.

XMC4500
XMC4000 Family
17.5.4.2 Valid Master Transmit Data Formats

Due to the IIC frame format definitions, only some specific sequences of TDF codes are
possible and valid. If the USIC IIC module detects a wrong TDF code in a running frame,
the transfer is aborted and flag PCR.WTDF is set. Additionally, an interrupt can be
generated if enabled by the user. In case of a wrong TDF code, the frame will be aborted
immediately with a STOP condition if the USIC IIC master still owns the SDA line. But if
the accessed slave owns the SDA line (read transfer), the master must perform a dummy
read with a non-acknowledge so that the slave releases the SDA line before a STOP
condition can be sent. The received data byte of the dummy read will be stored in
RBUF0/1, but RDV0/1 will not be set. Therefore the dummy read will not generate a
receive interrupt and the data byte will not be stored into the receive FIFO.
If the transfer direction has changed in the current frame (master read access), the
transmit data request (TDF = 000B) is not possible and won't be accepted (leading to a
wrong TDF Code indication).
Table 17-14 Valid TDF Codes Overview

Frame Position Valid TDF Codes
First TDF code (master idle) Start (100B)
Read transfer: second TDF code (after Receive with acknowledge (010B) or
start or repeated start) receive with not-acknowledge (011B)
Write transfer: second TDF code (after start Transmit (000B), repeated start (101B), or
or repeated start) stop (110B)
Read transfer: third and subsequent TDF Receive with acknowledge (010B) or
code after acknowledge receive with not-acknowledge (011B)
Read transfer: third and subsequent TDF Repeated start (101B) or stop (110B)
code after not-acknowledge
Write transfer: third and subsequent TDF Transmit (000B), repeated start (101B), or
code stop (110B)
First TDF code:

A master transfer starts with the TDF start code (100B). All other codes are ignored,
but no WTDF error will be indicated.
TDF code after a start (100B) or repeated start code (101B) in case of a read access:
If a master-read transfer is started (determined by the LSB of the address byte = 1),
the transfer direction of SDA changes and the slave will actively drive the data line.
In this case, only the codes 010B and 011B are valid. To abort the transfer in case of
a wrong code, a dummy read must be performed by the master before the STOP
condition can be generated.

XMC4500
XMC4000 Family
TDF code after a start (100B) or repeated start code (101B) in case of a write access:
If a master-write transfer is started (determined by the LSB of the address byte = 0),
the master still owns the SDA line. In this case, the transmit (000B), repeated start
(101B) and stop (110B) codes are valid. The other codes are considered as wrong.
To abort the transfer in case of a wrong code, the STOP condition is generated
immediately.
TDF code of the third and subsequent command in case of a read access with
acknowledged previous data byte:
If a master-read transfer is started (determined by the LSB of the address byte), the
transfer direction of SDA changes and the slave will actively drive the data line. To
force the slave to release the SDA line, the master has to not-acknowledge a byte
transfer. In this case, only the receive codes 010B and 011B are valid. To abort the
transfer in case of a wrong code, a dummy read must be performed by the master
before the STOP condition can be generated.
TDF code of the third and subsequent command in case of a read access with a not-
acknowledged previous data byte:
If a master-read transfer is started (determined by the LSB of the address byte), the
transfer direction of SDA changes and the slave will actively drive the data line. To
force the slave to release the SDA line, the master has to not-acknowledge a byte
transfer. In this case, only the restart (101B) and stop code (110B) are valid. To abort
the transfer in case of a wrong code, the STOP condition is generated immediately.
TDF code of the third and subsequent command in case of a write access:
If a master-write transfer is started (determined by the LSB of the address byte), the
master still owns the SDA line. In this case, the transmit (000B), repeated start (101B)
and stop (110B) codes are valid. The other codes are considered as wrong. To abort
the transfer in case of a wrong code, the STOP condition is generated immediately.
After a master device has received a non-acknowledge from a slave device, a stop
condition will be sent out automatically, except if the following TDF code requests a
repeated start condition. In this case, the TDF code is taken into account, whereas
all other TDF codes are ignored.

XMC4500
XMC4000 Family
no
Bus idle?
yes
TDF no
= 100 B ?
yes Indicate arbitration
Send start loss and release
condition bus
Send repeated Send TBUF[7:0]

start condition with ACK = 1
yes
Arbitration
lost ? Send all 1s
with ACK = 1
no
Get new valid Send all 1s
TBUF value with ACK = 0
Transmit Receive
or receive ?
Transmit
yes TDF no
TDF yes
= 000 B ?
= 010 B?
no
Send stop yes no yes
condition TDF TDF
= 101 B? = 011 B?
no
yes
Indicate error TDF
= 110 B?
Ignore TBUF
no
Figure 17-55 IIC Master Transmission

XMC4500
XMC4000 Family
17.5.4.3 Master Transmit/Receive Modes

In master transmit mode, the IIC sends a number of data bytes to a slave receiver. The
TDF code sequence for the master transmit mode is shown in Table 17-15.
Table 17-15 TDF Code Sequence for Master Transmit

TDF Code TBUF[10:8] TBUF[7:0] IIC Response Interrupt Events
Sequence (TDF Code)
1st code 100B Slave Send START SCR: Indicates a
address + condition, slave START condition is
write bit address and write bit detected
TBIF: Next word can be
written to TBUF
2nd code 000B Data or 2nd Send data or 2nd TBIF: Next word can be
slave slave address byte written to TBUF
address
byte
Subsequent 000B Data Send data TBIF: Next word can be
codes for written to TBUF
data
transmit
Last code 110B Dont care Send STOP PCR: Indicates a STOP
condition condition is detected
In master receive mode, the IIC receives a number of data bytes from a slave transmitter.
The TDF code sequence for the master receive 7-bit and 10-bit addressing modes are
shown in Table 17-16 and Table 17-17.
Table 17-16 TDF Code Sequence for Master Receive (7-bit Addressing Mode)
Sequence (TDF Code)
address + condition, slave START condition is
read bit address and read bit detected
TBIF: Next word can be
written to TBUF
2nd code 010B Dont care Receive data and TBIF: Next word can be
send ACK bit written to TBUF
AIF: First data received
can be read

XMC4500
XMC4000 Family
Sequence (TDF Code)
Subsequent 010B Dont care Receive data and TBIF: Next word can be
codes for send ACK bit written to TBUF
data receive RIF: Subsequent data
received can be read
Code for 011B Dont care Receive data and TBIF: Next word can be
last data to send NACK bit written to TBUF
be received RIF: Last data received
can be read
Sequence (TDF Code)
address condition, slave START condition is
(1st byte) + address (1st byte) detected
write bit and write bit TBIF: Next word can be
written to TBUF
2nd code 000B Slave Send address (2nd TBIF: Next word can be
address byte) written to TBUF
(2nd byte)
3rd code 101B 1st slave Send repeated RSCR: Indicates a
address + START condition, repeated START
read bit slave address (1st condition is detected
byte) and read bit TBIF: Next word can be
written to TBUF
4th code 010B Dont care Receive data and TBIF: Next word can be
send ACK bit written to TBUF
AIF: First data received
can be read
Subsequent 010B Dont care Receive data and TBIF: Next word can be
codes for send ACK bit written to TBUF
data receive RIF: Subsequent data
received can be read

XMC4500
XMC4000 Family
Sequence (TDF Code)
Code for 011B Dont care Receive data and TBIF: Next word can be
last data to send NACK bit written to TBUF
be received RIF: Last data received
from slave can be read
Figure 17-56 shows the interrupt events during the master transmit-slave receive and
master receive/slave transmit sequences.
Master Transmit Slave Receive

TBIF SCR TBIF TBIF PCR
Master
Transmit
S Slave Address W A Data A Data A P
Slave
Receive
SCR AIF RIF PCR
Master Receive Slave Transmit

TBIF SCR TBIF AIF TBIF RIF PCR
Master
Receive
S Slave Address R A Data A Data NA P
Slave
Transmit
SCR SRR TBIF TBIF PCR
Interrupt events on Interrupt events on

From master to slave From slave to master
the master the slave
Figure 17-56 Interrupt Events on Data Transfers
17.5.4.4 Slave Transmit/Receive Modes

In slave receive mode, no TDF code needs to be written and data reception is indicated
by the alternate receive (AIF) or receive (RIF) events.
In slave transmit mode, upon receiving its own slave address or general call address if
this option is enabled, a slave read request event (SRR) will be triggered. The slave IIC
then writes the TDF code 001B and the requested data to TBUF to transmit the data to

XMC4500
XMC4000 Family
the master. The slave does not check if the master reply with an ACK or NACK to the
transmitted data.
In both cases, the data transfer is terminated by the master sending a STOP condition,
which is indicated by a PCR event. See also Figure 17-56.
17.5.5 IIC Protocol Registers

In IIC mode, the registers PCR and PSR handle IIC related information.
17.5.5.1 IIC Protocol Control Registers

In IIC mode, the PCR register bits or bit fields are defined as described in this section.
PCR
Protocol Control Register [IIC Mode]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MCL ACKI SAC ERRI SRRI ARLI NAC PCRI RSC SCRI ACK
HDEL STIM
K EN KDIS EN EN EN KIEN EN RIEN EN 00
rw rw rw rw rw rw rw rw rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SLAD
rw

SLAD [15:0] rw Slave Address
This bit field contains the programmed slave address. The
corresponding bits in the first received address byte are
compared to the bits SLAD[15:9] to check for address
match. If SLAD[15:11] = 11110B, then the second address
byte is also compared to SLAD[7:0].
ACK00 16 rw Acknowledge 00H
This bit defines if a slave device should be sensitive to the
slave address 00H.
0B The slave device is not sensitive to this address.
1B The slave device is sensitive to this address.

XMC4500
XMC4000 Family

STIM 17 rw Symbol Timing
This bit defines how many time quanta are used in a
symbol.
0B A symbol contains 10 time quanta. The timing is
adapted for standard mode (100 kBaud).
1B A symbol contains 25 time quanta. The timing is
adapted for fast mode (400 kBaud).
SCRIEN 18 rw Start Condition Received Interrupt Enable
start condition is detected.
0B The start condition interrupt is disabled.
1B The start condition interrupt is enabled.
RSCRIEN 19 rw Repeated Start Condition Received Interrupt Enable
repeated start condition is detected.
0B The repeated start condition interrupt is disabled.
1B The repeated start condition interrupt is enabled.
PCRIEN 20 rw Stop Condition Received Interrupt Enable
stop condition is detected.
0B The stop condition interrupt is disabled.
1B The stop condition interrupt is enabled.
NACKIEN 21 rw Non-Acknowledge Interrupt Enable
non-acknowledge is detected by a master.
0B The non-acknowledge interrupt is disabled.
1B The non-acknowledge interrupt is enabled.
ARLIEN 22 rw Arbitration Lost Interrupt Enable
This bit enables the generation of a protocol interrupt if an
arbitration lost event is detected.
0B The arbitration lost interrupt is disabled.
1B The arbitration lost interrupt is enabled.
SRRIEN 23 rw Slave Read Request Interrupt Enable
slave read request is detected.
0B The slave read request interrupt is disabled.
1B The slave read request interrupt is enabled.

XMC4500
XMC4000 Family

ERRIEN 24 rw Error Interrupt Enable
IIC error condition is detected (indicated by PSR.ERR or
PSR.WTDF).
0B The error interrupt is disabled.
1B The error interrupt is enabled.
SACKDIS 25 rw Slave Acknowledge Disable
This bit disables the generation of an active acknowledge
signal for a slave device (active acknowledge = 0 level).
Once set by software, it is automatically cleared with each
(repeated) start condition. If this bit is set after a byte has
been received (indicated by an interrupt) but before the
next acknowledge bit has started, the next acknowledge
bit will be sent with passive level. This would indicate that
the receiver does not accept more bytes. As a result, a
minimum of 2 bytes will be received if the first receive
interrupt is used to set this bit.
0B The generation of an active slave acknowledge is
enabled (slave acknowledge with 0 level = more
bytes can be received).
1B The generation of an active slave acknowledge is
disabled (slave acknowledge with 1 level =
reception stopped).
HDEL [29:26] rw Hardware Delay
This bit field defines the delay used to compensate the
internal treatment of the SCL signal (see Page 17-116) in
order to respect the SDA hold time specified for the IIC
protocol.
ACKIEN 30 rw Acknowledge Interrupt Enable
acknowledge is detected by a master.
0B The acknowledge interrupt is disabled.
1B The acknowledge interrupt is enabled.
This bit enables generation of the master clock MCLK (not
directly used for IIC protocol, can be used as general
frequency output).
0B The MCLK generation is disabled and MCLK is 0.

XMC4500
XMC4000 Family
17.5.5.2 IIC Protocol Status Register

The following PSR status bits or bit fields are available in IIC mode. Please note that the
bits in register PSR are not cleared by hardware.
These flags should be cleared by software before enabling a new protocol.
PSR
Protocol Status Register [IIC Mode] (48H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
BRG
0
IF
r rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
NAC RSC WTD SLS
AIF RIF TBIF TSIF DLIF RSIF ACK ERR SRR ARL PCR SCR
K R F EL
rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh rwh

SLSEL 0 rwh Slave Select
This bit indicates that this device has been selected as
slave.
0B The device is not selected as slave.
1B The device is selected as slave.
WTDF 1 rwh Wrong TDF Code Found1)
This bit indicates that an unexpected/wrong TDF code
has been found. A protocol interrupt can be generated if
PCR.ERRIEN = 1.
0B A wrong TDF code has not been found.
1B A wrong TDF code has been found.
SCR 2 rwh Start Condition Received1)
This bit indicates that a start condition has been detected
on the IIC bus lines.A protocol interrupt can be generated
if PCR.SCRIEN = 1.
0B A start condition has not yet been detected.
1B A start condition has been detected.

XMC4500
XMC4000 Family

RSCR 3 rwh Repeated Start Condition Received1)
This bit indicates that a repeated start condition has been
detected on the IIC bus lines. A protocol interrupt can be
generated if PCR.RSCRIEN = 1.
0B A repeated start condition has not yet been
detected.
1B A repeated start condition has been detected.
PCR 4 rwh Stop Condition Received1)
This bit indicates that a stop condition has been detected
on the IIC bus lines. A protocol interrupt can be generated
if PCR.PCRIEN = 1.
0B A stop condition has not yet been detected.
1B A stop condition has been detected.
NACK 5 rwh Non-Acknowledge Received1)
This bit indicates that a non-acknowledge has been
received in master mode. This bit is not set in slave mode.
A protocol interrupt can be generated if
PCR.NACKIEN = 1.
0B A non-acknowledge has not been received.
1B A non-acknowledge has been received.
ARL 6 rwh Arbitration Lost1)
This bit indicates that an arbitration has been lost. A
protocol interrupt can be generated if PCR.ARLIEN = 1.
0B An arbitration has not been lost.
1B An arbitration has been lost.
SRR 7 rwh Slave Read Request1)
This bit indicates that a slave read request has been
detected. It becomes active to request the first data byte
to be made available in the transmit buffer. For further
consecutive data bytes, the transmit buffer issues more
interrupts. For the end of the transfer, the master
transmitter sends a stop condition. A protocol interrupt
can be generated if PCR.SRRIEN = 1.
0B A slave read request has not been detected.
1B A slave read request has been detected.

XMC4500
XMC4000 Family

ERR 8 rwh Error1)
This bit indicates that an IIC error (frame format or TDF
code) has been detected. A protocol interrupt can be
generated if PCR.ERRIEN = 1.
0B An IIC error has not been detected.
1B An IIC error has been detected.
ACK 9 rwh Acknowledge Received1)
This bit indicates that an acknowledge has been received
in master mode. This bit is not set in slave mode. A
protocol interrupt can be generated if PCR.ACKIEN = 1.
0B An acknowledge has not been received.
1B An acknowledge has been received.
Returns 0 if read; not modified in IIC mode.

XMC4500
XMC4000 Family
17.6 Inter-IC Sound Bus Protocol (IIS)

This chapter describes how the USIC module handles the IIS protocol. This serial
protocol can handle reception and transmission of synchronous data frames between a
device operating in master mode and a device in slave mode. An IIS connection based
on a USIC communication channel supports half-duplex and full-duplex data transfers.
The IIS mode is selected by CCR.MODE = 0011B with CCFG.IIS = 1 (IIS mode is
available).
17.6.1 Introduction
The IIS protocol is a synchronous serial communication protocol mainly for audio and
infotainment applications [18].
17.6.1.1 Signal Description

A connection between an IIS master and an IIS slave is based on the following signals:
A shift clock signal SCK, generated by the transfer master. It is permanently
generated while an IIS connection is established, also while no valid data bits are
transferred.
A word address signal WA (also named WS), generated by the transfer master. It
indicates the beginning of a new data word and the targeted audio channel (e.g.
left/right). The word address output signal WA is available on all SELOx outputs if the
WA generation is enabled (by PCR.WAGEN = 1 for the transfer master). The WA
signal changes synchronously to the falling edges of the shift clock.
If the transmitter is the IIS master device, it generates a master transmit slave receive
data signal. The data changes synchronously to the falling edges of the shift clock.
If the transmitter is the IIS slave device, it generates a master receive slave transmit
data signal. The data changes synchronously to the falling edges of the shift clock.
The transmitter part and the receiver part of the USIC communication channel can be
used together to establish a full-duplex data connection between an IIS master and a
slave device.
Table 17-18 IIS IO Signals

IIS Mode Receive Data Transmit Data Shift Clock Word Address
Master Input DIN0, Output DOUT0 Output Output(s)
handled by DX0 SCLKOUT SELOx
Slave Input DIN0, Output DOUT0 Input SCLKIN, Input SELIN,
handled by DX0 handled by DX1 handled by DX2

XMC4500
XMC4000 Family
IIS Communication Master IIS Communication Slave

Master Transmit /
DOUT0 DIN0
Slave Receive
TBUF DX0 RBUF
Master Receive /
DIN0 DOUT0
Slave Transmit
RBUF DX0 TBUF
Word Address
SELOx SELIN
WA (Word Select )
DX2
Generator
SCLKOUT SCLKIN
Shift Clock
Baud Rate DX1
Generator
MCLKOUT
Master Clock
Output fPB
(Slave)
SCLKIN
Synchronization
DX1
Clock Input
fPB
(Master)
Figure 17-57 IIS Signals

Two additional signals are available for the USIC IIS communication master:
A master clock output signal MCLKOUT with a fixed phase relation to the shift clock
to support oversampling for audio components. It can also be used as master clock
output of a communication network with synchronized IIS connections.
A synchronization clock input SCLKIN for synchronization of the shift clock
generation to an external frequency to support audio frequencies that can not be
directly derived from the system clock fPB of the communication master. It can be
used as master clock input of a communication network with synchronized IIS
connections.
17.6.1.2 Protocol Overview

An IIS connection supports transfers for two different data frames via the same data line,
e.g. a data frames for the left audio channel and a data frame for the right audio channel.
The word address signal WA is used to distinguish between the different data frames.
Each data frame can consist of several data words.

XMC4500
XMC4000 Family
In a USIC communication channel, data words are tagged for being transmitted for the
left or for the right channel. Also the received data words contain a tag identifying the WA
state when the data has been received.
WA (WS) Right Channel Left Channel
SCK
MSB LSB MSB LSB
DOUT0 0 Right Data Frame 0 Left Data Frame 0
MSB LSB MSB LSB
DIN0 X Right Data Frame X Left Data Frame X
Figure 17-58 Protocol Overview
17.6.1.3 Transfer Delay

The transfer delay feature allows the transfer of data (transmission and reception) with
a programmable delay (counted in shift clock periods).
SCK SCK
WA WA
DATA DATA
Without Delay With Delay 1
Figure 17-59 Transfer Delay for IIS
17.6.1.4 Connection of External Audio Components

The IIS signals can be used to communicate with external audio devices (such as
Codecs) or other audio data sources/destinations.

XMC4500
XMC4000 Family
USIC IIS Audio-ADC
MCLKOUT MCLK_IN
R
SCLKOUT SCK_IN Analog
L Inputs
WA WA_IN
DIN0 SD_OUT
DOUT0
Audio-DAC
MCLK_IN
R
SCK_IN Analog
L Outputs
WA_IN
SD_IN
Figure 17-60 Connection of External Audio Devices

In some applications, especially for Audio-ADCs or Audio-DACs, a master clock signal
is required with a fixed phase relation to the shift clock signal. The frequency of
MCLKOUT is a multiple of the shift frequency SCLKOUT. This factor defines the
oversampling factor of the external device (commonly used values: 256 or 384).
17.6.2 Operating the IIS

This chapter contains IIS issues, that are of general interest and not directly linked to
master mode or slave mode.
17.6.2.1 Frame Length and Word Length Configuration

After each change of the WA signal, a complete data frame is intended to be transferred
(frame length system word length). The number of data bits transferred after a change
of signal WA is defined by SCTR.FLE. A data frame can consist of several data words
with a data word length defined by SCTR.WLE. The changes of signal WA define the
system word length as the number of SCLK cycles between two changes of WA (number
of bits available for the right channel and same number available for the left channel).
If the system word length is longer than the frame length defined by SCTR.FLE, the
additional bits are transmitted with passive data level (SCTR.PDL). If the system word

XMC4500
XMC4000 Family
length is smaller than the device frame length, not all LSBs of the transmit data can be
transferred.
It is recommended to program bits WLEMD, FLEMD and SELMD in register TCSR to 0.

The baud rate and shift control setting are internally kept constant while a data frame is
transferred by an automatic shadow mechanism. The registers can be programmed all
the time with new settings that are taken into account for the next data frame. During a
data frame, the applied (shadowed) setting is not changed, although new values have
been written after the start of the data frame. The setting is internally frozen with the
start of each data frame.
Although this shadow mechanism being implemented, it is recommended to change the
baud rate and shift control setting only while the IIS protocol is switched off.

In IIS mode, the following kernel modes are supported:
Run Mode 0/1:
Stop Mode 0/1:
Bit PCR.WAGEN is internally considered as 0 (the bit itself is not changed). If
WAGEN = 1, then the current system word cycle is finished and then the WA
generation is stopped, but PSR.END is not set. The complete data frame is finished
before entering stop mode, including a possible delay due to PCR.TDEL.
When leaving a stop mode with WAGEN = 1, the WA generation starts from the
beginning.
17.6.2.4 Transfer Delay

The transfer delay can be used to synchronize a data transfer to an event (e.g. a change
of the WA signal). This event has to be synchronously generated to the falling edge of
the shift clock SCK (like the change of the transmit data), because the input signal for
the event is directly sampled in the receiver (as a result, the transmitter can use the
detection information with its next edge).
Event signals that are asynchronous to the shift clock while the shift clock is running must
not be used. In the example in Figure 17-59, the event (change of signal WA) is
generated by the transfer master and as a result, is synchronous to the shift clock SCK.
With the rising edge of SCK, signal WA is sampled and checked for a change. If a
change is detected, a transfer delay counter TDC is automatically loaded with its
programmable reload value (PCR.TDEL), otherwise it is decremented with each rising
edge of SCK until it reaches 0, where it stops. The transfer itself is started if the value of
TDC has become 0. This can happen under two conditions:

XMC4500
XMC4000 Family
TDC is reloaded with a PCR.TDEL = 0 when the event is detected

TDC has reached 0 while counting down
The transfer delay counter is internal to the IIS protocol pre-processor and can not be
observed by software. The transfer delay in SCK cycles is given by PCR.TDEL+1.
In the example in Figure 17-61, the reload value PCR.TDEL for TDC is 0. When the
samples taken on receiver side show the change of the WA signal, the counter TDC is
reloaded. If the reload value is 0, the data transfer starts with 1 shift clock cycle delay
compared to the change of WA.
SCK
s s s s s s s
WA
TDC 0 0 0
DOUT0 X D0 D1 X D0
DIN0
sampled D0 D1 D0
s = sampling of WA
Figure 17-61 Transfer Delay with Delay 1

The ideal case without any transfer delay is shown in Figure 17-62. The WA signal
changes and the data output value become valid at the same time. This implies that the
transmitter knows in advance that the event signal will change with the next rising edge
of TCLK. This is achieved by delaying the data transmission after the previously detected
WA change the system word length minus 1.

XMC4500
XMC4000 Family
SCK
s s s s s s s
WA
TDC 1 0 n n-1 n-2 1 0 n
DOUT0 X D0 D1 D2 X D0 D1
DIN0
sampled D0 D1 D0 D1
s = sampling of WA
Figure 17-62 No Transfer Delay

If the end of the transfer delay is detected simultaneously to change of WA, the transfer
is started and the delay counter is reloaded with PCR.TDEL. This allows to run the USIC
as IIS device without any delay. In this case, internally the delay from the previous event
elapses just at the moment when a new event occurs. If PCR.TDEL is set to a value
bigger than the system word length, no transfer takes place.
17.6.2.5 Parity Mode

Parity generation is not supported in IIS mode and bit field CCR.PM = 00B has to be
programmed.
17.6.2.6 Transfer Mode

In IIS mode, bit field SCTR.TRM = 11B has to be programmed to allow data transfers.
Setting SCTR.TRM = 00B disables and stops the data transfer immediately.

The data transfer interrupts indicate events related to IIS frame handling.
Bit PSR.TBIF is set after the start of first data bit of a data word.

XMC4500
XMC4000 Family

Bit PSR.RSIF is set after the reception of the first data bit of a data word.
buffer.
Receiver interrupt RI and alternative interrupt AI:
Bit PSR.RIF is set at after the reception of the last data bit of a data word with WA = 0.
word of a new data frame.
Bit PSR.AIF is set at after the reception of the last data bit of a data word with WA = 1.
word of a new data frame.


In order to distinguish between data words received for the left or the right channel, the
IIS protocol pre-processor samples the level of the WA input (just after the WA transition)
and propagates it as protocol-related error (although it is not an error, but an indication)
to the receive buffer status register at the bit position RBUFSR[9]. This bit position
defines if either a standard receive interrupt (if RBUFSR[9] = 0) or an alternative receive
interrupt (if RBUFSR[9] = 1) becomes activated when a new data word has been
received. Incoming data can be handled by different interrupts or DMA mechanisms for
the left and the right channel if the corresponding events are directed to different interrupt
nodes. Flag PAR is always 0.
17.6.2.10 Transmit Data Handling

The IIS protocol pre-processor allows to distinguish between the left and the right
channel for data transmission. Therefore, bit TCSR.WA indicates on which channel the
data in the buffer will be transmitted. If TCSR.WA = 0, the data will be transmitted after
a falling edge of WA. If TCSR.WA = 1, the data will be transmitted after a rising edge of
WA. The WA value sampled after the WA transition is considered to distinguish between
both channels (referring to PSR.WA).
Bit TCSR.WA can be automatically updated by the transmit control information TCI[4] for
each data word if TCSR.WAMD = 1. In this case, data written to TBUF[15:0] (or IN[15:0]
if a FIFO data buffer is used) is considered as left channel data, whereas data written to
TBUF[31:16] (or IN[31:16] if a FIFO data buffer is used) is considered as right channel
data.

XMC4500
XMC4000 Family

(RBCTR.SIZE > 0), it is recommended to set RBCTR.RCIM = 11B in IIS mode. This
if bit OUTR.RCI[0] = 1, and the channel indication by the sampled WA value is given by
OUTR.RCI[4].
for the following operation in RCI mode (RBCTR.RNM = 1):
that belongs to a data frame started when WA = 0.
An alternative receive buffer event indicates that a data word can be read from OUTR
that belongs to a data frame started when WA = 1.
17.6.2.12 Loop-Delay Compensation

The synchronous signaling mechanism of the IIS protocol being similar to the one of the
SSC protocol, the closed-loop delay has to be taken into account for the application
setup. In IIS mode, loop-delay compensation in master mode is also possible to achieve
higher baud rates.
Please refer to the more detailed description in the SSC chapter.
17.6.3 Operating the IIS in Master Mode

In order to operate the IIS in master mode, the following issues have to be considered:
Select IIS mode:
It is recommended to configure all parameters of the IIS that do not change during
CCR.MODE = 0000B to avoid unintended edges of the input signals and the IIS mode
can be enabled by CCR.MODE = 0011B afterwards.
Pin connection for data transfer:
(DIN0) with DX0CR.INSW = 1. Configure a transmit data output pin (DOUT0) for a
transmitter.
The data shift unit allowing full-duplex data transfers based on the same WA signal,
the values delivered by the DX0 stage are considered as data bits (receive function
can not be disabled independently from the transmitter). To receive IIS data, the
transmitter does not necessarily need to be configured (no assignment of DOUT0
signal to a pin).
The desired baud rate setting has to be selected, comprising the fractional divider
and the baud rate generator. Bit DX1CR.INSW = 0 has to be programmed to use the

XMC4500
XMC4000 Family
baud rate generator output SCLK directly as input for the data shift unit. Configure a
shift clock output pin with the inverted signal SCLKOUT without additional delay
(BRG.SCLKCFG = 01B).
Word address WA generation:
The WA generation has to be enabled by setting PCR.WAGEN = 1 and the
programming of the number of shift clock cycles between the changes of WA. Bit
DX2CR.INSW = 0 has to be programmed to use the WA generator as input for the
data shift unit. Configure WA output pin for signal SELOx if needed.
The word length, the frame length, and the shift direction have to be set up according
to the application requirements by programming the register SCTR. Generally, the
MSB is shifted first (SCTR.SDIR = 1).
Bit TCSR.WAMD can be set to use the transmit control information TCI[4] to
distinguish the data words for transmission while WA = 0 or while WA = 1.

The baud rate is defined by the frequency of the SCLK signal (one period of fSCLK
represents one data bit).
If the fractional divider mode is used to generate fPIN, there can be an uncertainty of one
period of fPB for fPIN. This uncertainty does not accumulate over several SCLK cycles. As
a consequence, the average frequency is reached, whereas the duty cycle of 50% of the
SCLK and MCLK signals can vary by one period of fPB.
In IIS applications, where the phase relation between the optional MCLK output signal
and SCLK is not relevant, SCLK can be based on the frequency fPIN (BRG.PPPEN = 0).
In the case that a fixed phase relation between the MCLK signal and SCLK is required
(e.g. when using MCLK as clock reference for external devices), the additional divider by
2 stage has to be taken into account (BRG.PPPEN = 1). This division is due to the fact
that signal MCLK toggles with each cycle of fPIN. Signal SCLK is then based on signal
MCLK, see Figure 17-63.
The adjustable integer divider factor is defined by bit field BRG.PDIV.
fPIN 1
2 PDIV + 1
(17.12)
fPIN 1
22 PDIV + 1
Note: In the IIS protocol, the master (unit generating the shift clock and the WA signal)
changes the status of its data and WA output line with the falling edge of SCK. The
slave transmitter also has to transmit on falling edges. The sampling of the
received data is done with the rising edges of SCLK. The input stage DX1 and the

XMC4500
XMC4000 Family
SCLKOUT have to be programmed to invert the shift clock signal to fit to the
internal signals.
17.6.3.2 WA Generation
The word address (or word select) line WA regularly toggles after N cycles of signal
SCLK. The time between the changes of WA is called system word length and can be
programmed by using the following bit fields.
In IIS master mode, the system word length is defined by:
BRG.CTQSEL = 10B
to base the WA toggling on SCLK
BRG.PCTQ
to define the number N of SCLK cycles per system word length
BRG.DCTQ
to define the number N of SCLK cycles per system word length
N = (PCTQ + 1) (DCTQ + 1) (17.13)
17.6.3.3 Master Clock Output

The master clock signal MCLK can be generated by the master of the IIS transfer
(BRG.PPPEN = 1). It is used especially to connect external Codec devices. It can be
configured by bit BRG.MCLKCFG in its polarity to become the output signal MCLKOUT.
x SCLK = x SCLK =
fPIN
(PDIV+1) x MCLK (PDIV+1) x MCLK
MCLK MCLK
SCLK SCLK
zoom in
Transmitter
DOUT0 D(n) D(n+1)
Receiver
sampled D(n) D(n+1)
DIN0
1 Period of SCLK = 1 Data Bit Length
Figure 17-63 MCLK and SCLK for IIS

XMC4500
XMC4000 Family

The following protocol-related events are generated in IIS mode and can lead to a
protocol interrupt.
WA rising/falling edge events:
The WA generation block indicates two events that are monitored in register PSR.
Flag PSR.WAFE is set with the falling edge, flag PSR.WARE with the rising edge of
the WA signal. A protocol interrupt can be generated if PCR.WAFEIEN = 1 for the
falling edge, similar for PCR.WAREIEN = 1 for a rising edge.
WA end event:
The WA generation block also indicates when it has stopped the WA generation after
it has been disabled by writing PCR.WAGEN = 0. A protocol interrupt can be
generated if PCR.ENDIEN = 1.
DX2T event:
An activation of the trigger signal DX2T is indicated by PSR.DX2TEV = 1 and can
generate a protocol interrupt if PCR.DX2TIEN = 1. This event can be evaluated
instead of the WA rising/falling events if a delay compensation like in SSC mode (for
details, refer to corresponding SSC section) is used.
17.6.4 Operating the IIS in Slave Mode

In order to operate the IIS in slave mode, the following issues have to be considered:
Select IIS mode:
It is recommended to configure all parameters of the IIS that do not change during
CCR.MODE = 0000B to avoid unintended edges of the input signals and the IIS mode
can be enabled by CCR.MODE = 0011B afterwards.
Pin connection for data transfer:
(DIN0) with DX0CR.INSW = 1. Configure a transmit data output pin (DOUT0) for a
transmitter.
The data shift unit allowing full-duplex data transfers based on the same WA signal,
the values delivered by the DX0 stage are considered as data bits (receive function
can not be disabled independently from the transmitter). To receive IIS data, the
transmitter does not necessarily need to be configured (no assignment of DOUT0
signal to a pin).
Pin connection for shift clock:
Establish a connection of input stage DX1 with the selected shift clock input pin
(SCLKIN) with DX1CR.INSW = 1 and with inverted polarity (DX1CR.DPOL = 1).

XMC4500
XMC4000 Family
Pin connection for WA input:

Establish a connection of input stage DX2 with the WA input pin (SELIN) with
DX2CR.INSW = 1.
The baud rate generator is not needed and can be switched off by the fractional
divider.
WA generation:
The WA generation is not needed and can be switched off (PCR.WAGEN = 0).
17.6.4.1 Protocol Events and Interrupts

The following protocol-related event is generated in IIS mode and can lead to a protocol
interrupt.
WA rising/falling/end events:
The WA generation being switched off, these events are not available.
DX2T event:
An activation of the trigger signal DX2T is indicated by PSR.DX2TEV = 1 and can
generate a protocol interrupt if PCR.DX2TIEN = 1.
17.6.5 IIS Protocol Registers

In IIS mode, the registers PCR and PSR handle IIS related information.
17.6.5.1 IIS Protocol Control Registers

In IIS mode, the PCR register bits or bit fields are defined as described in this section.
PCR
Protocol Control Register [IIS Mode]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MCL
0 TDEL
K
rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DX2 ENDI WAR WAF SELI DTE WAG
0 0
TIEN EN EIEN EIEN NV N EN
rw rw rw rw rw rw rw rw rw

XMC4500
XMC4000 Family

WAGEN 0 rw WA Generation Enable
This bit enables/disables the generation of word address
control output signal WA.
0B The IIS can be used as slave. The generation of the
word address signal is disabled. The output signal
WA is 0. The MCLKO signal generation depends on
PCR.MCLK.
1B The IIS can be used as master. The generation of
the word address signal is enabled. The signal
starts with a 0 after being enabled. The generation
of MCLK is enabled, independent of PCR.MCLK.
After clearing WAGEN, the USIC module stops the
generation of the WA signal within the next 4 WA
periods.
DTEN 1 rw Data Transfers Enable
This bit enables/disables the transfer of IIS frames as a
reaction to changes of the input word address control line
WA.
0B The changes of the WA input signal are ignored and
no transfers take place.
1B Transfers are enabled.
SELINV 2 rw Select Inversion
This bit defines if the polarity of the SELOx outputs in
relation to the internally generated word address signal
WA.
0B The SELOx outputs have the same polarity as the
WA signal.
1B The SELOx outputs have the inverted polarity to the
WA signal.
WAFEIEN 4 rw WA Falling Edge Interrupt Enable
This bit enables/disables the activation of a protocol
interrupt when a falling edge of WA has been generated.
0B A protocol interrupt is not activated if a falling edge
of WA is generated.
1B A protocol interrupt is activated if a falling edge of
WA is generated.

XMC4500
XMC4000 Family

WAREIEN 5 rw WA Rising Edge Interrupt Enable
interrupt when a rising edge of WA has been generated.
0B A protocol interrupt is not activated if a rising edge
of WA is generated.
1B A protocol interrupt is activated if a rising edge of
WA is generated.
ENDIEN 6 rw END Interrupt Enable
interrupt when the WA generation stops after clearing
PCR.WAGEN (complete system word length is processed
before stopping).
0B A protocol interrupt is not activated.
1B A protocol interrupt is activated.
DX2TIEN 15 rw DX2T Interrupt Enable
interrupt if the DX2T signal becomes activated (indicated
by PSR.DX2TEV = 1).
0B A protocol interrupt is not generated if DX2T is
active.
1B A protocol interrupt is generated if DX2T is active.
TDEL [21:16] rw Transfer Delay
This bit field defines the transfer delay when an event is
detected. If bit field TDEL = 0, the additional delay
functionality is switched off and a delay of one shift clock
cycle is introduced.
This bit enables generation of the master clock MCLK (not
directly used for IIC protocol, can be used as general
frequency output).
0B The MCLK generation is disabled and MCLK is 0.
0 3, rw Reserved
[14:7], Returns 0 if read; should be written with 0;
[30:22]
17.6.5.2 IIS Protocol Status Register

The following PSR status bits or bit fields are available in IIS mode. Please note that the
bits in register PSR are not cleared by hardware.

XMC4500
XMC4000 Family
These flags should be cleared by software before enabling a new protocol.
PSR
Protocol Status Register [IIS Mode] (48H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
BRG
0
IF
r rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
WAR WAF DX2 DX2
AIF RIF TBIF TSIF DLIF RSIF 0 END 0 WA
E E TEV S
rwh rwh rwh rwh rwh rwh r rwh rwh rwh rwh r rwh rwh

WA 0 rwh Word Address
This bit indicates the status of the WA input signal,
sampled after a transition of WA has been detected.
This information is forwarded to the corresponding bit
position RBUFSR[9] to distinguish between data received
for the right and the left channel.
0B WA has been sampled 0.
1B WA has been sampled 1.
DX2S 1 rwh DX2S Status
This bit indicates the current status of the DX2S signal,
which is used as word address signal WA.
0B DX2S is 0.
1B DX2S is 1.
DX2TEV 3 rwh DX2T Event Detected1)
This bit indicates that the DX2T signal has been activated.
In IIS slave mode, an activation of DX2T generates a
protocol interrupt if PCR.DX2TIEN = 1.
0B The DX2T signal has not been activated.
1B The DX2T signal has been activated.

XMC4500
XMC4000 Family

WAFE 4 rwh WA Falling Edge Event1)
This bit indicates that a falling edge of the WA output
signal has been generated. This event generates a
protocol interrupt if PCR.WAFEIEN = 1.
0B A WA falling edge has not been generated.
1B A WA falling edge has been generated.
WARE 5 rwh WA Rising Edge Event1)
This bit indicates that a rising edge of the WA output
signal has been generated. This event generates a
protocol interrupt if PCR.WAREIEN = 1.
0B A WA rising edge has not been generated.
1B A WA rising edge has been generated.
END 6 rwh WA Generation End1)
This bit indicates that the WA generation has ended after
clearing PCR.WAGEN. This bit should be cleared by
software before clearing WAGEN.
0B The WA generation has not yet ended (if it is
running and WAGEN has been cleared).
1B The WA generation has ended (if it has been
running).

XMC4500
XMC4000 Family

0 2, [9:7], r Reserved
[31:17] Returns 0 if read; not modified in IIS mode.

XMC4500
XMC4000 Family

The USIC module provides 6 service request outputs SR[5:0] to be shared between two
channels. The service request outputs SR[5:0] are connected to interrupt nodes in the
Nested Vectored Interrupt Controller (NVIC). Additionally, the first 4 outputs, SR[3:0], are
also connected to the DMA Line Router (DLR). For details of the interrupt node and DMA
line assignments, refer to the respective chapter in the specification.
Each USIC communication channel can be connected to up to 6 service request
handlers (connected to USICx_CHy.SR[5:0], though 3 or 4 are normally used, e.g. one
for transmission, one for reception, one or two for protocol or error handling, or for the
alternative receive events).
17.8 Debug Behaviour

Each USIC communication channel can be pre-configured to enter one of four kernel
modes, when the program execution of the CPU is halted by the debugger.
Refer to Section 17.2.2.2 for details.

The USIC module is located in the core power domain. The module, including all
registers other than the bit field KSCFG.SUMCFG, can be reset to its default state by a
system reset or a software reset triggered through the setting of corresponding bits in
PRSETx registers. The bit field KSCFG.SUMCFG is reset to its default value only by a
debug reset.
The USIC module is clocked by the Peripheral Bus clock (fPB). If the module clock is
disabled by KSCFG.MODEN = 0, the module cannot be accessed by read or write
operations (except register KSCFG that can always be accessed).

The USIC module is held in reset after a start-up from a system or software reset.
Therefore, the application has to apply the following initialization sequence before
operating the USIC module:
Release reset of USIC module by writing a 1 to the USICxRS bit in SCU_PRCLR0 or
SCU_PRCLR1 registers
Enable the module by writing 1s to the MODEN and BPMODEN bits in KSCFG
register.
17.11 Registers
Table 17-19 shows all registers which are required for programming a USIC channel, as
well as the FIFO buffer. It summarizes the USIC communication channel registers and
defines the relative addresses and the reset values.

XMC4500
XMC4000 Family
Please note that all registers can be accessed with any access width (8-bit, 16-bit, 32-
bit), independent of the described width.
All USIC registers (except bit field KSCFG.SUMCFG) are always reset by a system
reset. Bit field KSCFG.SUMCFG is reset by a debug reset.
Note: The register bits marked w always deliver 0 when read. They are used to modify
flip-flops in other registers or to trigger internal actions.
Figure 17-64 shows the register types of the USIC module registers and channel
registers. In a specific microcontroller, module registers of USIC module x are marked
by the module prefix USICx_. Channel registers of USIC module x are marked by the
channel prefix USICx_CH0_ and USICx_CH1_.
USICx Module
Channel 0 Channel 1
Registers Registers
FIFO FIFO
Buffer Buffer
Registers Registers
Channel Channel
Registers Registers
Module Registers
Figure 17-64 USIC Module and Channel Registers
Table 17-19 USIC Kernel-Related and Kernel Registers

Short Name Addr. Read Write see
Module Registers1)
ID Module Identification Register 008H U, PV U, PV Page 17-157
Channel Registers
reserved 000H nBE nBE
CCFG Channel Configuration Register 004H U, PV U, PV Page 17-162

XMC4500
XMC4000 Family
Table 17-19 USIC Kernel-Related and Kernel Registers (contd)

KSCFG Kernel State Configuration 00CH U, PV U, PV Page 17-163
Register
FDR Fractional Divider Register 010H U, PV PV Page 17-176
BRG Baud Rate Generator Register 014H U, PV PV Page 17-177
INPR Interrupt Node Pointer Register 018H U, PV U, PV Page 17-166
DX0CR Input Control Register 0 01CH U, PV U, PV Page 17-171
DX1CR Input Control Register 1 020H U, PV U, PV Page 17-173
DX2CR Input Control Register 2 024H U, PV U, PV Page 17-171
DX3CR Input Control Register 3 028H U, PV U, PV
DX4CR Input Control Register 4 02CH U, PV U, PV
DX5CR Input Control Register 5 030H U, PV U, PV
SCTR Shift Control Register 034H U, PV U, PV Page 17-181
TCSR Transmit Control/Status 038H U, PV U, PV Page 17-184
Register
PCR Protocol Control Register 03CH U, PV U, PV Page 17-168
2)
U, PV U, PV Page 17-653)
U, PV U, PV Page 17-127
5)
6)
CCR Channel Control Register 040H U, PV PV Page 17-158

CMTR Capture Mode Timer Register 044H U, PV U, PV Page 17-180

XMC4500
XMC4000 Family

PSR Protocol Status Register 048H U, PV U, PV Page 17-168
2)
4)
5)
6)
PSCR Protocol Status Clear Register 04CH U, PV U, PV Page 17-170

RBUFSR Receiver Buffer Status Register 050H U, PV U, PV Page 17-202
RBUF Receiver Buffer Register 054H U, PV U, PV Page 17-199
RBUFD Receiver Buffer Register for 058H U, PV U, PV Page 17-201
Debugger
RBUF0 Receiver Buffer Register 0 05CH U, PV U, PV Page 17-193
RBUF1 Receiver Buffer Register 1 060H U, PV U, PV Page 17-194
RBUF01SR Receiver Buffer 01 Status 064H U, PV U, PV Page 17-195
Register
FMR Flag Modification Register 068H U, PV U, PV Page 17-191
reserved; do not access this 06CH U, PV nBE
location
reserved 070H - nBE nBE
07CH
TBUFx Transmit Buffer Input Location x 080H + U, PV U, PV Page 17-193
(x = 00-31) x*4
FIFO Buffer Registers
BYP Bypass Data Register 100H U, PV U, PV Page 17-203
BYPCR Bypass Control Register 104H U, PV U, PV Page 17-204
TBCTR Transmit Buffer Control Register 108H U, PV U, PV Page 17-212
RBCTR Receive Buffer Control Register 10CH U, PV U, PV Page 17-216
TRBPTR Transmit/Receive Buffer Pointer 110H U, PV U, PV Page 17-224
Register

XMC4500
XMC4000 Family

TRBSR Transmit/Receive Buffer Status 114H U, PV U, PV Page 17-207
Register
TRBSCR Transmit/Receive Buffer Status 118H U, PV U, PV Page 17-211
Clear Register
OUTR Receive Buffer Output Register 11CH U, PV U, PV Page 17-222
OUTDR Receive Buffer Output Register 120H U, PV U, PV Page 17-223
for Debugger
reserved 124H - nBE nBE
17CH
INx Transmit FIFO Buffer Input 180H + U, PV U, PV Page 17-221
Location x (x = 00-31) x*4
1) Details of the module identification registers are described in the implementation section (see Page 17-157).
2) This page shows the general register layout.
3) This page shows the register layout in ASC mode.
4) This page shows the register layout in SSC mode.
5) This page shows the register layout in IIC mode.
6) This page shows the register layout in IIS mode.
17.11.1 Address Map

The registers of the USIC communication channel are available at the following base
addresses. The exact register address is given by the relative address of the register
(given in Table 17-19) plus the channel base address (given in Table 17-20).

USIC0_CH0 40030000H 400301FFH
USIC0_CH1 40030200H 400303FFH
USIC1_CH0 48020000H 480201FFH
USIC1_CH1 48020200H 480203FFH
USIC2_CH0 48024000H 480241FFH
USIC2_CH1 48024200H 480243FFH

XMC4500
XMC4000 Family
Table 17-21 FIFO and Reserved Address Space

USIC0 40030400H 400307FFH USIC0 RAM area,
shared between
USIC0_CH0 and
USIC0_CH1
reserved 40030800H 40033FFFH This address range is
reserved
shared between
USIC1_CH0 and
USIC1_CH1
reserved
shared between
USIC2_CH0 and
USIC2_CH1
reserved
17.11.2 Module Identification Registers

The module identification registers indicate the function and the design step of the USIC
modules.

XMC4500
XMC4000 Family
USIC0_ID
(4003 0008H) Reset Value: 00AA C0XXH
USIC1_ID
USIC2_ID
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MOD_NUMBER
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MOD_TYPE MOD_REV
r r

module.
MOD_NUMBE [31:16] r Module Number Value
R This bit field defines the USIC module identification
number (00AAH = USIC).
17.11.3 Channel Control and Configuration Registers
17.11.3.1 Channel Control Register

The channel control register contains the enable/disable bits for hardware port control
and interrupt generation on channel events, the control of the parity generation and the
protocol selection of a USIC channel.
FDR can be written only with a privilege mode access.

XMC4500
XMC4000 Family
CCR
Channel Control Register (40H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
BRG
0
IEN
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TBIE TSIE DLIE RSIE
AIEN RIEN PM HPCEN 0 MODE
N N N N
rw rw rw rw rw rw rw rw r rw

MODE [3:0] rw Operating Mode
This bit field selects the protocol for this USIC
channel. Selecting a protocol that is not available (see
register CCFG) or a reserved combination disables
the USIC channel. When switching between two
protocols, the USIC channel has to be disabled
before selecting a new protocol. In this case, registers
PCR and PSR have to be cleared or updated by
software.
0H The USIC channel is disabled. All protocol-
related state machines are set to an idle state.
1H The SSC (SPI) protocol is selected.
2H The ASC (SCI, UART) protocol is selected.
3H The IIS protocol is selected.
4H The IIC protocol is selected.
Other bit combinations are reserved.

XMC4500
XMC4000 Family

HPCEN [7:6] rw Hardware Port Control Enable
This bit enables the hardware port control for the
specified set of DX[3:0] and DOUT[3:0] pins.
00B The hardware port control is disabled.
01B The hardware port control is enabled for DX0
and DOUT0.
10B The hardware port control is enabled for DX3,
DX0 and DOUT[1:0].
11B The hardware port control is enabled for DX0,
DX[5:3] and DOUT[3:0].
Note: The hardware port control feature is useful only
for SSC protocols in half-duplex configurations,
such as dual- and quad-SSC. For all other
protocols HPCEN must always be written with
00B.
PM [9:8] rw Parity Mode
This bit field defines the parity generation of the
sampled input values.
00B The parity generation is disabled.
01B Reserved
10B Even parity is selected (parity bit = 1 on odd
number of 1s in data, parity bit = 0 on even
number of 1s in data).
11B Odd parity is selected (parity bit = 0 on odd
number of 1s in data, parity bit = 1 on even
number of 1s in data).
RSIEN 10 rw Receiver Start Interrupt Enable
This bit enables the interrupt generation in case of a
receiver start event.
0B The receiver start interrupt is disabled.
1B The receiver start interrupt is enabled.
In case of a receiver start event, the service
request output SRx indicated by INPR.TBINP is
activated.

XMC4500
XMC4000 Family

DLIEN 11 rw Data Lost Interrupt Enable
data lost event (data received in RBUFx while
RDVx = 1).
0B The data lost interrupt is disabled.
1B The data lost interrupt is enabled. In case of a
data lost event, the service request output SRx
indicated by INPR.PINP is activated.
TSIEN 12 rw Transmit Shift Interrupt Enable
transmit shift event.
0B The transmit shift interrupt is disabled.
1B The transmit shift interrupt is enabled. In case
of a transmit shift interrupt event, the service
request output SRx indicated by INPR.TSINP is
activated.
TBIEN 13 rw Transmit Buffer Interrupt Enable
transmit buffer event.
0B The transmit buffer interrupt is disabled.
1B The transmit buffer interrupt is enabled. In case
of a transmit buffer event, the service request
output SRx indicated by INPR.TBINP is
activated.
RIEN 14 rw Receive Interrupt Enable
receive event.
0B The receive interrupt is disabled.
1B The receive interrupt is enabled. In case of a
receive event, the service request output SRx
indicated by INPR.RINP is activated.
AIEN 15 rw Alternative Receive Interrupt Enable
alternative receive event.
0B The alternative receive interrupt is disabled.
1B The alternative receive interrupt is enabled. In
case of an alternative receive event, the service
request output SRx indicated by INPR.AINP is
activated.

XMC4500
XMC4000 Family

BRGIEN 16 rw Baud Rate Generator Interrupt Enable
baud rate generator event.
0B The baud rate generator interrupt is disabled.
1B The baud rate generator interrupt is enabled. In
case of a baud rate generator event, the service
request output SRx indicated by INPR.PINP is
activated.
0 [5:4], r Reserved

XMC4500
XMC4000 Family
17.11.3.2 Channel Configuration Register

The channel configuration register contains indicates the functionality that is available in
the USIC channel.
CCFG
Channel Configuration Register (04H) Reset Value: 0000 00CFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 TB RB 0 IIS IIC ASC SSC
r r r r r r r r

SSC 0 r SSC Protocol Available
This bit indicates if the SSC protocol is available.
0B The SSC protocol is not available.
1B The SSC protocol is available.
ASC 1 r ASC Protocol Available
This bit indicates if the ASC protocol is available.
0B The ASC protocol is not available.
1B The ASC protocol is available.
IIC 2 r IIC Protocol Available
This bit indicates if the IIC functionality is available.
0B The IIC protocol is not available.
1B The IIC protocol is available.
IIS 3 r IIS Protocol Available
This bit indicates if the IIS protocol is available.
0B The IIS protocol is not available.
1B The IIS protocol is available.
RB 6 r Receive FIFO Buffer Available
This bit indicates if an additional receive FIFO buffer
is available.
0B A receive FIFO buffer is not available.
1B A receive FIFO buffer is available.

XMC4500
XMC4000 Family

TB 7 r Transmit FIFO Buffer Available
This bit indicates if an additional transmit FIFO buffer
is available.
0B A transmit FIFO buffer is not available.
1B A transmit FIFO buffer is available.
0 [5:4], r Reserved
[31:16]
17.11.3.3 Kernel State Configuration Register

The kernel state configuration register KSCFG allows the selection of the desired kernel
modes for the different device operating modes.
KSCFG
Kernel State Configuration Register (0CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BPM
BPS BPN MOD
0 0 SUMCFG 0 NOMCFG 0 ODE
UM OM EN
N
r w r rw w r rw r w rw

XMC4500
XMC4000 Family

MODEN 0 rw Module Enable
This bit enables the module kernel clock and the
module functionality.
0B The module is switched off immediately
(without respecting a stop condition).
It does not react on mode control actions and
the module clock is switched off. The module
does not react on read accesses and ignores
write accesses (except to KSCFG).
1B The module is switched on and can operate.
After writing 1 to MODEN, it is recommended
to read register KSCFG to avoid pipeline
effects in the control block before accessing
other USIC registers.
BPMODEN 1 w Bit Protection for MODEN
This bit enables the write access to the bit MODEN.
It always reads 0.
0B MODEN is not changed.
1B MODEN is updated with the written value.
NOMCFG [5:4] rw Normal Operation Mode Configuration
This bit field defines the kernel mode applied in
normal operation mode.
00B Run mode 0 is selected.
01B Run mode 1 is selected.
10B Stop mode 0 is selected.
11B Stop mode 1 is selected.
BPNOM 7 w Bit Protection for NOMCFG
This bit enables the write access to the bit field
NOMCFG. It always reads 0.
0B NOMCFG is not changed.
1B NOMCFG is updated with the written value.
SUMCFG [9:8] rw Suspend Mode Configuration
This bit field defines the kernel mode applied in
suspend mode. Coding like NOMCFG.

XMC4500
XMC4000 Family

BPSUM 11 w Bit Protection for SUMCFG
This bit enables the write access to the bit field
SUMCFG. It always reads 0.
0B SUMCFG is not changed.
1B SUMCFG is updated with the written value.
0 [3:2], 6, r Reserved
10, Read as 0; should be written with 0. Bit 2 can read as
[31:12] 1 after BootROM exit (but can be ignored).

XMC4500
XMC4000 Family
17.11.3.4 Interrupt Node Pointer Register

The interrupt node pointer register defines the service request output SRx that is
activated if the corresponding event occurs and interrupt generation is enabled.
INPR
Interrupt Node Pointer Register (18H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 PINP
r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 AINP 0 RINP 0 TBINP 0 TSINP
r rw r rw r rw r rw

TSINP [2:0] rw Transmit Shift Interrupt Node Pointer
This bit field defines which service request output
SRx becomes activated in case of a transmit shift
interrupt.
000B Output SR0 becomes activated.
Note: All other settings of the bit field are reserved.
TBINP [6:4] rw Transmit Buffer Interrupt Node Pointer
SRx will be activated in case of a transmit buffer
interrupt or a receive start interrupt.
Coding like TSINP.
RINP [10:8] rw Receive Interrupt Node Pointer
SRx will be activated in case of a receive interrupt.
Coding like TSINP.

XMC4500
XMC4000 Family

AINP [14:12] rw Alternative Receive Interrupt Node Pointer
SRx will be activated in case of a alternative receive
interrupt.
Coding like TSINP.
PINP [18:16] rw Transmit Shift Interrupt Node Pointer
SRx becomes activated in case of a protocol
interrupt.
0 3, 7, 11, r Reserved
[31:19]
17.11.4 Protocol Related Registers
17.11.4.1 Protocol Control Registers

The bits in the protocol control register define protocol-specific functions. They have to
be configured by software before enabling a new protocol. Only the bits used for the
selected protocol are taken into account, whereas the other bit positions always read as
0. The protocol-specific meaning is described in the related protocol section.

XMC4500
XMC4000 Family
PCR
Protocol Control Register (3CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR CTR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

CTRx x rw Protocol Control Bit x
(x = 0-31) This bit is a protocol control bit.
17.11.4.2 Protocol Status Register

The flags in the protocol status register can be cleared by writing a 1 to the
corresponding bit position in register PSCR. Writing a 1 to a bit position in PSR sets the
corresponding flag, but does not lead to further actions (no interrupt generation). Writing
a 0 has no effect. These flags should be cleared by software before enabling a new
protocol. The protocol-specific meaning is described in the related protocol section.
PSR
Protocol Status Register (48H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
BRG
0
IF
r rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
AIF RIF TBIF TSIF DLIF RSIF ST9 ST8 ST7 ST6 ST5 ST4 ST3 ST2 ST1 ST0

XMC4500
XMC4000 Family

STx x rwh Protocol Status Flag x
(x = 0-9) See protocol specific description.
0 [31:17] r Reserved;
read as 0; should be written with 0;
17.11.4.3 Protocol Status Clear Register

Read accesses to this register always deliver 0 at all bit positions.

XMC4500
XMC4000 Family
PSCR
Protocol Status Clear Register (4CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CBR
0
GIF
r w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CTBI CTSI CDLI CRSI CST CST CST CST CST CST CST CST CST CST
CAIF CRIF
F F F F 9 8 7 6 5 4 3 2 1 0
w w w w w w w w w w w w w w w w

CSTx x w Clear Status Flag x in PSR
(x = 0-9) 0B No action
1B Flag PSR.STx is cleared.
CRSIF 10 w Clear Receiver Start Indication Flag
0B No action
1B Flag PSR.RSIF is cleared.
CDLIF 11 w Clear Data Lost Indication Flag
0B No action
1B Flag PSR.DLIF is cleared.
CTSIF 12 w Clear Transmit Shift Indication Flag
0B No action
1B Flag PSR.TSIF is cleared.
CTBIF 13 w Clear Transmit Buffer Indication Flag
0B No action
1B Flag PSR.TBIF is cleared.
CRIF 14 w Clear Receive Indication Flag
0B No action
1B Flag PSR.RIF is cleared.
CAIF 15 w Clear Alternative Receive Indication Flag
0B No action
1B Flag PSR.AIF is cleared.
CBRGIF 16 w Clear Baud Rate Generator Indication Flag
0B No action
1B Flag PSR.BRGIF is cleared.

XMC4500
XMC4000 Family

0 [31:17] r Reserved;
read as 0; should be written with 0;
17.11.5 Input Stage Register
17.11.5.1 Input Control Registers

The input control registers contain the bits to define the characteristics of the input
stages (input stage DX0 is controlled by register DX0CR, etc.).
DX0CR
Input Control Register 0 (1CH) Reset Value: 0000 0000H
DX2CR
Input Control Register 2 (24H) Reset Value: 0000 0000H
DX3CR
DX4CR
Input Control Register 4 (2CH) Reset Value: 0000 0000H
DX5CR
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SFS DPO DSE DFE INS
DXS 0 CM 0 0 DSEL
EL L N N W
rh r rw rw rw r rw rw rw r rw

XMC4500
XMC4000 Family

DSEL [2:0] rw Data Selection for Input Signal
This bit field defines the input data signal for the
corresponding input line for protocol pre-processor.
The selection can be made from the input vector
DXn[G:A].
000B The data input DXnA is selected.
001B The data input DXnB is selected.
010B The data input DXnC is selected.
011B The data input DXnD is selected.
100B The data input DXnE is selected.
101B The data input DXnF is selected.
110B The data input DXnG is selected.
111B The data input is always 1.
INSW 4 rw Input Switch
This bit defines if the data shift unit input is derived
from the input data path DXn or from the selected
protocol pre-processors.
0B The input of the data shift unit is controlled by the
protocol pre-processor.
1B The input of the data shift unit is connected to
the selected data input line. This setting is used
if the signals are directly derived from an input
pin without treatment by the protocol pre-
processor.
DFEN 5 rw Digital Filter Enable
This bit enables/disables the digital filter for signal
DXnS.
0B The input signal is not digitally filtered.
1B The input signal is digitally filtered.
DSEN 6 rw Data Synchronization Enable
This bit selects if the asynchronous input signal or the
synchronized (and optionally filtered) signal DXnS can
be used as input for the data shift unit.
0B The un-synchronized signal can be taken as
input for the data shift unit.
1B The synchronized signal can be taken as input
for the data shift unit.

XMC4500
XMC4000 Family

DPOL 8 rw Data Polarity for DXn
This bit defines the signal polarity of the input signal.
0B The input signal is not inverted.
1B The input signal is inverted.
SFSEL 9 rw Sampling Frequency Selection
This bit defines the sampling frequency of the digital
filter for the synchronized signal DXnS.
0B The sampling frequency is fPB.
1B The sampling frequency is fFD.
CM [11:10] rw Combination Mode
This bit field selects which edge of the synchronized
(and optionally filtered) signal DXnS actives the trigger
output DXnT of the input stage.
00B The trigger activation is disabled.
01B A rising edge activates DXnT.
10B A falling edge activates DXnT.
11B Both edges activate DXnT.
DXS 15 rh Synchronized Data Value
This bit indicates the value of the synchronized (and
optionally filtered) input signal.
0B The current value of DXnS is 0.
1B The current value of DXnS is 1.
0 3, 7, r Reserved
,
[31:16]
DX1CR
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SFS DPO DSE DFE INS DCE
DXS 0 CM 0 DSEL
EL L N N W N
rh r rw rw rw r rw rw rw rw rw

XMC4500
XMC4000 Family

DSEL [2:0] rw Data Selection for Input Signal
This bit field defines the input data signal for the
corresponding input line for protocol pre-processor.
The selection can be made from the input vector
DX1[G:A].
000B The data input DX1A is selected.
001B The data input DX1B is selected.
010B The data input DX1C is selected.
011B The data input DX1D is selected.
100B The data input DX1E is selected.
101B The data input DX1F is selected.
110B The data input DX1G is selected.
111B The data input is always 1.
DCEN 3 rw Delay Compensation Enable
This bit selects if the receive shift clock is controlled by
INSW or derived from the input data path DX1.
0B The receive shift clock is dependent on INSW
selection.
1B The receive shift clock is connected to the
selected data input line. This setting is used if
delay compensation is required in SSC and IIS
protocols, else DCEN should always be 0.
INSW 4 rw Input Switch
This bit defines if the data shift unit input is derived
from the input data path DX1 or from the selected
protocol pre-processors.
0B The input of the data shift unit is controlled by the
1B The input of the data shift unit is connected to
the selected data input line. This setting is used
if the signals are directly derived from an input
pin without treatment by the protocol pre-
processor.
DFEN 5 rw Digital Filter Enable
This bit enables/disables the digital filter for signal
DX1S.
0B The input signal is not digitally filtered.
1B The input signal is digitally filtered.

XMC4500
XMC4000 Family

DSEN 6 rw Data Synchronization Enable
This bit selects if the asynchronous input signal or the
synchronized (and optionally filtered) signal DX1S can
be used as input for the data shift unit.
0B The un-synchronized signal can be taken as
input for the data shift unit.
1B The synchronized signal can be taken as input
for the data shift unit.
DPOL 8 rw Data Polarity for DXn
This bit defines the signal polarity of the input signal.
0B The input signal is not inverted.
1B The input signal is inverted.
SFSEL 9 rw Sampling Frequency Selection
This bit defines the sampling frequency of the digital
filter for the synchronized signal DX1S.
0B The sampling frequency is fPB.
1B The sampling frequency is fFD.
CM [11:10] rw Combination Mode
This bit field selects which edge of the synchronized
(and optionally filtered) signal DX1S actives the trigger
output DX1T of the input stage.
00B The trigger activation is disabled.
01B A rising edge activates DX1T.
10B A falling edge activates DX1T.
11B Both edges activate DX1T.
DXS 15 rh Synchronized Data Value
This bit indicates the value of the synchronized (and
optionally filtered) input signal.
0B The current value of DX1S is 0.
1B The current value of DX1S is 1.
0 7, r Reserved
,
[31:16]

XMC4500
XMC4000 Family
17.11.6 Baud Rate Generator Registers
17.11.6.1 Fractional Divider Register

The fractional divider register FDR allows the generation of the internal frequency fFD,
that is derived from the system clock fPB.
FDR
Fractional Divider Register (10H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 RESULT
rw r rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DM 0 STEP
rw r rw

STEP [9:0] rw Step Value
In normal divider mode STEP contains the reload
value for RESULT after RESULT has reached 3FFH.
In fractional divider mode STEP defines the value
added to RESULT with each input clock cycle.
DM [15:14] rw Divider Mode
This bit fields defines the functionality of the
fractional divider block.
00B The divider is switched off, fFD = 0.
01B Normal divider mode selected.
10B Fractional divider mode selected.
11B The divider is switched off, fFD = 0.

XMC4500
XMC4000 Family

RESULT [25:16] rh Result Value
In normal divider mode this bit field is updated with
fPB according to: RESULT = RESULT + 1
In fractional divider mode this bit field is updated with
fPB according to: RESULT = RESULT + STEP
If bit field DM is written with 01B or 10B, RESULT is
loaded with a start value of 3FFH.
0 [31:30] rw Reserved for Future Use
Must be written with 0 to allow correct fractional
divider operation.
17.11.6.2 Baud Rate Generator Register

The protocol-related counters for baud rate generation and timing measurement are
controlled by the register BRG.
BRG
Baud Rate Generator Register (14H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MCL SCL
SCLKCFG KCF KOS 0 PDIV
G EL
rw rw rw r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PPP TME
0 DCTQ PCTQ CTQSEL 0 0 CLKSEL
EN N
r rw rw rw r rw rw r rw

XMC4500
XMC4000 Family

CLKSEL [1:0] rw Clock Selection
This bit field defines the input frequency fPIN
00B The fractional divider frequency fFD is selected.
01B Reserved, no action
10B The trigger signal DX1T defines fPIN. Signal
MCLK toggles with fPIN.
11B Signal MCLK corresponds to the DX1S signal
and the frequency fPIN is derived from the rising
edges of DX1S.
TMEN 3 rw Timing Measurement Enable
This bit enables the timing measurement of the
capture mode timer.
0B Timing measurement is disabled:
The trigger signals DX0T and DX1T are
ignored.
1B Timing measurement is enabled:
The 10-bit counter is incremented by 1 with fPPP
and stops counting when reaching its maximum
value. If one of the trigger signals DX0T or
DX1T become active, the counter value is
captured into bit field CTV, the counter is
cleared and a transmit shift event is generated.
PPPEN 4 rw Enable 2:1 Divider for fPPP
This bit defines the input frequency fPPP.
0B The 2:1 divider for fPPP is disabled.
fPPP = fPIN
1B The 2:1 divider for fPPP is enabled.
fPPP = fMCLK = fPIN / 2.
CTQSEL [7:6] rw Input Selection for CTQ
This bit defines the length of a time quantum for the
00B fCTQIN = fPDIV
01B fCTQIN = fPPP
10B fCTQIN = fSCLK
11B fCTQIN = fMCLK

XMC4500
XMC4000 Family

PCTQ [9:8] rw Pre-Divider for Time Quanta Counter
This bit field defines length of a time quantum tq for
the time quanta counter in the protocol pre-processor.
tQ = (PCTQ + 1) / fCTQIN
DCTQ [14:10] rw Denominator for Time Quanta Counter
This bit field defines the number of time quanta tq
taken into account by the time quanta counter in the
PDIV [25:16] rw Divider Mode: Divider Factor to Generate fPDIV
This bit field defines the ratio between the input
frequency fPPP and the divider frequency fPDIV.
SCLKOSEL 28 rw Shift Clock Output Select
This bit field selects the input source for the
SCLKOUT signal.
0B SCLK from the baud rate generator is selected
as the SCLKOUT input source.
1B The transmit shift clock from DX1 input stage is
selected as the SCLKOUT input source.
Note: The setting SCLKOSEL = 1 is used only when
complete closed loop delay compensation is
required for a slave SSC/IIS. The default
setting of SCLKOSEL = 0 should be always
used for all other cases.
MCLKCFG 29 rw Master Clock Configuration
This bit field defines the level of the passive phase of
the MCLKOUT signal.
0B The passive level is 0.
1B The passive level is 1.
SCLKCFG [31:30] rw Shift Clock Output Configuration
This bit field defines the level of the passive phase of
the SCLKOUT signal and enables/disables a delay of
half of a SCLK period.
00B The passive level is 0 and the delay is disabled.
01B The passive level is 1 and the delay is disabled.
10B The passive level is 0 and the delay is enabled.
11B The passive level is 1 and the delay is enabled.
0 2, 5, 15, r Reserved

XMC4500
XMC4000 Family
17.11.6.3 Capture Mode Timer Register

The captured timer value is provided by the register CMTR.
CMTR
Capture Mode Timer Register (44H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 CTV
r rwh

CTV [9:0] rwh Captured Timer Value
The value of the counter is captured into this bit field
if one of the trigger signals DX0T or DX1T are
activated by the corresponding input stage.
17.11.7 Transfer Control and Status Registers
17.11.7.1 Shift Control Register

The data shift unit is controlled by the register SCTR. The values in this register are
applied for data transmission and reception.
Please note that the shift control settings SDIR, WLE, FLE, DSM and HPCDIR are
shared between transmitter and receiver. They are internally frozen for a each data
word transfer in the transmitter with the first transmit shift clock edge and with the first
receive shift clock edge in the receiver. The software has to take care that updates of
these bit fields by software are done coherently (e.g. refer to the receiver start event
indication PSR.RSIF).

XMC4500
XMC4000 Family
SCTR
Shift Control Register (34H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 WLE 0 FLE
r rwh r rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
HPC
0 TRM DOCFG 0 DSM PDL SDIR
DIR

SDIR 0 rw Shift Direction
This bit defines the shift direction of the data words for
transmission and reception.
0B Shift LSB first. The first data bit of a data word
is located at bit position 0.
1B Shift MSB first. The first data bit of a data word
is located at the bit position given by bit field
SCTR.WLE.
PDL 1 rw Passive Data Level
This bit defines the output level at the shift data output
signal when no data is available for transmission. The
PDL level is output with the first relevant transmit shift
clock edge of a data word.
0B The passive data level is 0.
1B The passive data level is 1.

XMC4500
XMC4000 Family

DSM [3:2] rw Data Shift Mode
This bit field describes how the receive and transmit
data is shifted in and out.
00B Receive and transmit data is shifted in and out
one bit at a time through DX0 and DOUT0.
01B Reserved.
two bits at a time through two input stages (DX0
and DX3) and DOUT[1:0] respectively.
four bits at a time through four input stages
(DX0, DX[5:3]) and DOUT[3:0] respectively.
Note: Dual- and Quad-output modes are used only by
the SSC protocol. For all other protocols DSM
must always be written with 00B.
HPCDIR 4 rw Port Control Direction
This bit defines the direction of the port pin(s) which
allows hardware pin control (CCR.PCEN = 1).
0B The pin(s) with hardware pin control enabled
are selected to be in input mode.
1B The pin(s) with hardware pin control enabled
are selected to be in output mode.
DOCFG [7:6] rw Data Output Configuration
This bit defines the relation between the internal shift
data value and the data output signal DOUTx.
X0B DOUTx = shift data value
X1B DOUTx = inverted shift data value

XMC4500
XMC4000 Family

TRM [9:8] rw Transmission Mode
This bit field describes how the shift control signal is
interpreted by the DSU. Data transfers are only
possible while the shift control signal is active.
00B The shift control signal is considered as inactive
and data frame transfers are not possible.
01B The shift control signal is considered active if it
is at 1-level. This is the setting to be
programmed to allow data transfers.
10B The shift control signal is considered active if it
is at 0-level. It is recommended to avoid this
setting and to use the inversion in the DX2
stage in case of a low-active signal.
11B The shift control signal is considered active
without referring to the actual signal level. Data
frame transfer is possible after each edge of the
signal.
FLE [21:16] rwh Frame Length
This bit field defines how many bits are transferred
within a data frame. A data frame can consist of
several concatenated data words.
If TCSR.FLEMD = 1, the value can be updated
automatically by the data handler.
WLE [27:24] rwh Word Length
This bit field defines the data word length (amount of
bits that are transferred in each data word) for
reception and transmission. The data word is always
right-aligned in the data buffer at the bit positions
[WLE down to 0].
If TCSR.WLEMD = 1, the value can be updated
automatically by the data handler.
0H The data word contains 1 data bit located at bit
position 0.
1H The data word contains 2 data bits located at bit
positions [1:0].
...
EH The data word contains 15 data bits located at
bit positions [14:0].
FH The data word contains 16 data bits located at
bit positions [15:0].

XMC4500
XMC4000 Family

0 5, r Reserved
[23:22],
[31:28]
17.11.7.2 Transmission Control and Status Register

The data transmission is controlled and monitored by register TCSR.
TCSR
Transmit Control/Status Register (38H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TSO
0 TE TVC TV 0 0
F
r rh rh rh r rh r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TDV TDS HPC WA FLE SEL WLE
0 WA TDEN 0 TDV EOF SOF
TR SM MD MD MD MD MD
r rwh rw rw r rw rh rwh rw rw rw rw rw rw

WLEMD 0 rw WLE Mode
This bit enables the data handler to automatically
update the bit field SCTR.WLE by the transmit control
information TCI[3:0] and bit TCSR.EOF by TCI[4]
(see Page 17-32). If enabled, an automatic update
takes place when new data is loaded to register
TBUF, either by writing to one of the transmit buffer
input locations TBUFx or by an optional data buffer.
0B The automatic update of SCTR.WLE and
TCSR.EOF is disabled.
1B The automatic update of SCTR.WLE and
TCSR.EOF is enabled.

XMC4500
XMC4000 Family

SELMD 1 rw Select Mode
This bit can be used mainly for the SSC protocol. It
enables the data handler to automatically update bit
field PCR.CTR[20:16] by the transmit control
information TCI[4:0] and clear bit field
PCR.CTR[23:21] (see Page 17-32). If enabled, an
automatic update takes place when new data is
loaded to register TBUF, either by writing to one of the
transmit buffer input locations TBUFx or by an
optional data buffer.
0B The automatic update of PCR.CTR[23:16] is
disabled.
1B The automatic update of PCR.CTR[23:16] is
disabled.
FLEMD 2 rw FLE Mode
This bit enables the data handler to automatically
update bits SCTR.FLE[4:0] by the transmit control
information TCI[4:0] and to clear bit SCTR.FLE[5]
0B The automatic update of FLE is disabled.
1B The automatic update of FLE is enabled.
WAMD 3 rw WA Mode
This bit can be used mainly for the IIS protocol. It
enables the data handler to automatically update bit
TCSR.WA by the transmit control information TCI[4]
0B The automatic update of bit WA is disabled.
1B The automatic update of bit WA is enabled.

XMC4500
XMC4000 Family

HPCMD 4 rw Hardware Port Control Mode
This bit can be used mainly for the dual and quad
SSC protocol. It enables the data handler to
automatically update bit SCTR.DSM by the transmit
control information TCI[1:0] and bit SCTR.HPCDIR by
TCI[2] (see Page 17-32). If enabled, an automatic
update takes place when new data is loaded to
register TBUF, either by writing to one of the transmit
buffer input locations TBUFx or by an optional data
buffer.
0B The automatic update of bits SCTR.DSM and
SCTR.HPCDIR is disabled.
1B The automatic update of bits SCTR.DSM and
SCTR.HPCDIR is enabled.
SOF 5 rw Start Of Frame
This bit is only taken into account for the SSC
protocol, otherwise it is ignored.
It indicates that the data word in TBUF is considered
as the first word of a new SSC frame if it is valid for
transmission (TCSR.TDV = 1). This bit becomes
cleared when the TBUF data word is transferred to
the transmit shift register.
0B The data word in TBUF is not considered as
first word of a frame.
1B The data word in TBUF is considered as first
word of a frame. A currently running frame is
finished and MSLS becomes deactivated
(respecting the programmed delays).

XMC4500
XMC4000 Family

EOF 6 rwh End Of Frame
This bit is only taken into account for the SSC
protocol, otherwise it is ignored. It can be modified
automatically by the data handler if bit WLEMD = 1.
It indicates that the data word in TBUF is considered
as the last word of an SSC frame. If it is the last word,
the MSLS signal becomes inactive after the transfer,
respecting the programmed delays. This bit becomes
cleared when the TBUF data word is transferred to
the transmit shift register.
last word of an SSC frame.
1B The data word in TBUF is considered as last
word of an SSC frame.
TDV 7 rh Transmit Data Valid
This bit indicates that the data word in the transmit
buffer TBUF can be considered as valid for
transmission. The TBUF data word can only be sent
out if TDV = 1. It is automatically set when data is
moved to TBUF (by writing to one of the transmit
buffer input locations TBUFx, or optionally, by the
bypass or FIFO mechanism).
0B The data word in TBUF is not valid for
transmission.
1B The data word in TBUF is valid for transmission
and a transmission start is possible. New data
should not be written to a TBUFx input location
while TDV = 1.

XMC4500
XMC4000 Family

TDSSM 8 rw TBUF Data Single Shot Mode
This bit defines if the data word TBUF data is
considered as permanently valid or if the data should
only be transferred once.
invalid after it has been loaded into the transmit
shift register. The loading of the TBUF data into
the shift register does not clear TDV.
1B The data word in TBUF is considered as invalid
after it has been loaded into the shift register. In
ASC and IIC mode, TDV is cleared with the TBI
event, whereas in SSC and IIS mode, it is
cleared with the RSI event.
TDSSM = 1 has to be programmed if an
optional data buffer is used.
TDEN [11:10] rw TBUF Data Enable
This bit field controls the gating of the transmission
start of the data word in the transmit buffer TBUF.
00B A transmission start of the data word in TBUF is
disabled. If a transmission is started, the
passive data level is sent out.
01B A transmission of the data word in TBUF can be
started if TDV = 1.
started if TDV = 1 while DX2S = 0.
started if TDV = 1 while DX2S = 1.
TDVTR 12 rw TBUF Data Valid Trigger
This bit enables the transfer trigger unit to set bit
TCSR.TE if the trigger signal DX2T becomes active
for event driven transfer starts, e.g. timer-based or
depending on an event at an input pin. Bit TDVTR has
to be 0 for protocols where the input stage DX2 is
used for data shifting.
0B Bit TCSR.TE is permanently set.
1B Bit TCSR.TE is set if DX2T becomes active
while TDV = 1.

XMC4500
XMC4000 Family

WA 13 rwh Word Address
This bit is only taken into account for the IIS protocol,
otherwise it is ignored. It can be modified
automatically by the data handler if bit WAMD = 1.
Bit WA defines for which channel the data stored in
TBUF will be transmitted.
0B The data word in TBUF will be transmitted after
a falling edge of WA has been detected
(referring to PSR.WA).
1B The data word in TBUF will be transmitted after
a rising edge of WA has been detected
(referring to PSR.WA).
TSOF 24 rh Transmitted Start Of Frame
This bit indicates if the latest start of a data word
transmission has taken place for the first data word of
a new data frame. This bit is updated with the
transmission start of each data word.
0B The latest data word transmission has not been
started for the first word of a data frame.
1B The latest data word transmission has been
started for the first word of a data frame.
TV 26 rh Transmission Valid
This bit represents the transmit buffer underflow and
indicates if the latest start of a data word transmission
has taken place with a valid data word from the
transmit buffer TBUF. This bit is updated with the
transmission start of each data word.
0B The latest start of a data word transmission has
taken place while no valid data was available.
As a result, the transmission of a data words
with passive level (SCTR.PDL) has been
started.
1B The latest start of a data word transmission has
taken place with valid data from TBUF.

XMC4500
XMC4000 Family

TVC 27 rh Transmission Valid Cumulated
This bit cumulates the transmit buffer underflow
indication TV. It is cleared automatically together with
bit TV and has to be set by writing FMR.ATVC = 1.
0B Since TVC has been set, at least one data
buffer underflow condition has occurred.
1B Since TVC has been set, no data buffer
underflow condition has occurred.
TE 28 rh Trigger Event
If the transfer trigger mechanism is enabled, this bit
indicates that a trigger event has been detected
(DX2T = 1) while TCSR.TDV = 1. If the event trigger
mechanism is disabled, the bit TE is permanently set.
It is cleared by writing FMR.MTDV = 10B or when the
data word located in TBUF is loaded into the shift
register.
0B The trigger event has not yet been detected. A
transmission of the data word in TBUF can not
be started.
1B The trigger event has been detected (or the
trigger mechanism is switched off) and a
transmission of the data word in TBUF can not
be started.
0 9, r Reserved
25,
[31:29]
17.11.7.3 Flag Modification Registers

The flag modification register FMR allows the modification of control and status flags
related to data handling by using only write accesses. Read accesses to FMR always
deliver 0 at all bit positions.
Additionally, the service request outputs of this USIC channel can be activated by
software (the activation is triggered by the write access and is deactivated
automatically).

XMC4500
XMC4000 Family
FMR
Flag Modification Register (68H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 SIO5 SIO4 SIO3 SIO2 SIO1 SIO0
r w w w w w w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CRD CRD ATV
0 0 MTDV
V1 V0 C
w w r w r w

MTDV [1:0] w Modify Transmit Data Valid
Writing to this bit field can modify bits TCSR.TDV and
TCSR.TE to control the start of a data word
transmission by software.
00B No action.
01B Bit TDV is set, TE is unchanged.
10B Bits TDV and TE are cleared.
11B Reserved
ATVC 4 w Activate Bit TVC
Writing to this bit can set bit TCSR.TVC to start a new
cumulation of the transmit buffer underflow condition.
0B No action.
1B Bit TCSR.TVC is set.
CRDV0 14 w Clear Bits RDV for RBUF0
Writing 1 to this bit clears bits RBUF01SR.RDV00
and RBUF01SR.RDV10 to declare the received data
in RBUF0 as no longer valid (to emulate a read
action).
0B No action.
1B Bits RBUF01SR.RDV00 and
RBUF01SR.RDV10 are cleared.

XMC4500
XMC4000 Family

CRDV1 15 w Clear Bit RDV for RBUF1
Writing 1 to this bit clears bits RBUF01SR.RDV01
and RBUF01SR.RDV11 to declare the received data
in RBUF1 as no longer valid (to emulate a read
action).
0B No action.
1B Bits RBUF01SR.RDV01 and
RBUF01SR.RDV11 are cleared.
SIO0, 16, w Set Interrupt Output SRx
SIO1, 17, Writing a 1 to this bit field activates the service
SIO2, 18, request output SRx of this USIC channel. It has no
SIO3, 19, impact on service request outputs of other USIC
SIO4, 20, channels.
SIO5 21 0B No action.
1B The service request output SRx is activated.
0 [3:2], r Reserved
[31:22]
17.11.8 Data Buffer Registers
17.11.8.1 Transmit Buffer Locations

The 32 independent data input locations TBUF00 to TBUF31 are address locations that
can be used as data entry locations for the transmit buffer. Data written to one of these
locations will appear in a common register TBUF. Additionally, the 5 bit coding of the
number [31:0] of the addressed data input location represents the transmit control
information TCI (please refer to the protocol sections for more details).
The internal transmit buffer register TBUF contains the data that will be loaded to the
transmit shift register for the next transmission of a data word. It can be read out at all
TBUF00 to TBUF31 addresses.

XMC4500
XMC4000 Family
TBUFx (x = 00-31)
Transmit Buffer Input Location x (80H + x*4) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TDATA
rwh

TDATA [15:0] rwh Transmit Data
This bit field contains the data to be transmitted (read
view).
A data write action to at least the low byte of TDATA
sets TCSR.TDV.
17.11.8.2 Receive Buffer Registers RBUF0, RBUF1

The receive buffer register RBUF0 contains the data received from RSR0[3:0]. A read
action does not change the status of the receive data from not yet read = valid to
already read = not valid.
RBUF0
Receiver Buffer Register 0 (5CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DSR0
rh

XMC4500
XMC4000 Family

DSR0 [15:0] rh Data of Shift Registers 0[3:0]
The receive buffer register RBUF1 contains the data received from RSR1[3:0]. A read
action does not change the status of the receive data from not yet read = valid to
already read = not valid.
RBUF1
Receiver Buffer Register 1 (60H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DSR1
rh

DSR1 [15:0] rh Data of Shift Registers 1[3:0]
The receive buffer status register RBUF01SR provides the status of the data in receive
buffers RBUF0 and RBUF1.

XMC4500
XMC4000 Family
RBUF01SR
Receiver Buffer 01 Status Register (64H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RDV RDV PER PAR SOF
DS1 0 0 0 WLEN1
11 10 R1 1 1
rh rh rh r rh rh r rh r rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RDV RDV PER PAR SOF
DS0 0 0 0 WLEN0
01 00 R0 0 0

WLEN0 [3:0] rh Received Data Word Length in RBUF0
This bit field indicates how many bits have been
received within the last data word stored in RBUF0.
This number indicates how many data bits have to be
considered as receive data, whereas the other bits in
RBUF0 have been cleared automatically. The
received bits are always right-aligned.
0H One bit has been received.
...
FH Sixteen bits have been received.
SOF0 6 rh Start of Frame in RBUF0
This bit indicates whether the data word in RBUF0
has been the first data word of a data frame.
0B The data in RBUF0 has not been the first data
word of a data frame.
1B The data in RBUF0 has been the first data word
of a data frame.
PAR0 8 rh Protocol-Related Argument in RBUF0
This bit indicates the value of the protocol-related
argument. This value is elaborated depending on the
selected protocol and adds additional information to
the data word in RBUF0.
The meaning of this bit is described in the
corresponding protocol chapter.

XMC4500
XMC4000 Family

PERR0 9 rh Protocol-related Error in RBUF0
This bit indicates if the value of the protocol-related
argument meets an expected value. This value is
elaborated depending on the selected protocol and
adds additional information to the data word in
RBUF0.
0B The received protocol-related argument PAR
matches the expected value. The reception of
the data word sets bit PSR.RIF and can
generate a receive interrupt.
does not match the expected value. The
reception of the data word sets bit PSR.AIF and
can generate an alternative receive interrupt.
RDV00 13 rh Receive Data Valid in RBUF0
This bit indicates the status of the data content of
register RBUF0. This bit is identical to bit
RBUF01SR.RDV10 and allows consisting reading of
information for the receive buffer registers. It is set
when a new data word is stored in RBUF0 and
automatically cleared if it is read out via RBUF.
0B Register RBUF0 does not contain data that has
not yet been read out.
1B Register RBUF0 contains data that has not yet
been read out.
information for the receive buffer registers. It is set
when a new data word is stored in RBUF1 and
automatically cleared if it is read out via RBUF.
been read out.

XMC4500
XMC4000 Family

DS0 15 rh Data Source
This bit indicates which receive buffer register
(RBUF0 or RBUF1) is currently visible in registers
RBUF(D) and in RBUFSR for the associated status
information. It indicates which buffer contains the
oldest data (the data that has been received first).
This bit is identical to bit RBUF01SR.DS1 and allows
consisting reading of information for the receive buffer
registers.
0B The register RBUF contains the data of RBUF0
(same for associated status information).
WLEN1 [19:16] rh Received Data Word Length in RBUF1
This bit field indicates how many bits have been
received within the last data word stored in RBUF1.
This number indicates how many data bits have to be
considered as receive data, whereas the other bits in
RBUF1 have been cleared automatically. The
received bits are always right-aligned.
0H One bit has been received.
...
FH Sixteen bits have been received.
SOF1 22 rh Start of Frame in RBUF1
This bit indicates whether the data word in RBUF1
has been the first data word of a data frame.
0B The data in RBUF1 has not been the first data
word of a data frame.
1B The data in RBUF1 has been the first data word
of a data frame.
PAR1 24 rh Protocol-Related Argument in RBUF1
This bit indicates the value of the protocol-related
argument. This value is elaborated depending on the
selected protocol and adds additional information to
the data word in RBUF1.

XMC4500
XMC4000 Family

PERR1 25 rh Protocol-related Error in RBUF1
This bit indicates if the value of the protocol-related
argument meets an expected value. This value is
elaborated depending on the selected protocol and
adds additional information to the data word in
RBUF1.
matches the expected value. The reception of
the data word sets bit PSR.RIF and can
generate a receive interrupt.
does not match the expected value. The
reception of the data word sets bit PSR.AIF and
can generate an alternative receive interrupt.
information for the receive buffer registers.
been read out.
information for the receive buffer registers.
been read out.

XMC4500
XMC4000 Family

DS1 31 rh Data Source
This bit indicates which receive buffer register
(RBUF0 or RBUF1) is currently visible in registers
RBUF(D) and in RBUFSR for the associated status
information. It indicates which buffer contains the
oldest data (the data that has been received first).
This bit is identical to bit RBUF01SR.DS0 and allows
consisting reading of information for the receive buffer
registers.
[21:20],
23,
[28:26]
17.11.8.3 Receive Buffer Registers RBUF, RBUFD, RBUFSR

The receiver buffer register RBUF shows the content of the either RBUF0 or RBUF1,
depending on the order of reception. Always the oldest data (the data word that has been
received first) from both receive buffers can be read from RBUF. It is recommended to
read out the received data from RBUF instead of RBUF0/1. With a read access of at least
the low byte of RBUF, the status of the receive data is automatically changed from not
yet read = valid to already read = not valid, the content of RBUF becomes updated,
and the next received data word becomes visible in RBUF.
RBUF
Receiver Buffer Register (54H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DSR
rh

XMC4500
XMC4000 Family

DSR [15:0] rh Received Data
This bit field monitors the content of either RBUF0 or
RBUF1, depending on the reception sequence.

XMC4500
XMC4000 Family
If a debugger should be used to monitor the received data, the automatic update
mechanism has to be de-activated to guaranty data consistency. Therefore, the receiver
buffer register for debugging RBUFD is available. It is similar to RBUF, but without the
automatic update mechanism by a read action. So a debugger (or other monitoring
function) can read RBUFD without disturbing the receive sequence.
RBUFD
Receiver Buffer Register for Debugger(58H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DSR
rh

DSR [15:0] rh Data from Shift Register
Same as RBUF.DSR, but without releasing the buffer
after a read action.

XMC4500
XMC4000 Family
The receive buffer status register RBUFSR provides the status of the data in receive
buffers RBUF and RBUFD. If bits RBUF01SR.DS0 (or RBUF01SR.DS1) are 0, the lower
16-bit content of RBUF01SR is monitored in RBUFSR, otherwise the upper 16-bit
content of RBUF01SR is shown.
RBUFSR
Receiver Buffer Status Register (50H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RDV RDV PER
DS 0 PAR 0 SOF 0 WLEN
1 0 R

WLEN [3:0] rh Received Data Word Length in RBUF or RBUFD
Description see RBUF01SR.WLEN0 or
RBUF01SR.WLEN1.
SOF 6 rh Start of Frame in RBUF or RBUFD
Description see RBUF01SR.SOF0 or
RBUF01SR.SOF1.
PAR 8 rh Protocol-Related Argument in RBUF or RBUFD
Description see RBUF01SR.PAR0 or
RBUF01SR.PAR1.
PERR 9 rh Protocol-related Error in RBUF or RBUFD
Description see RBUF01SR.PERR0 or
RBUF01SR.PERR1.
RDV0 13 rh Receive Data Valid in RBUF or RBUFD
Description see RBUF01SR.RDV00 or
RBUF01SR.RDV10.
RDV1 14 rh Receive Data Valid in RBUF or RBUFD
Description see RBUF01SR.RDV01 or
RBUF01SR.RDV11.

XMC4500
XMC4000 Family

DS 15 rh Data Source of RBUF or RBUFD
Description see RBUF01SR.DS0 or
RBUF01SR.DS1.
[31:16]
17.11.9 FIFO Buffer and Bypass Registers
17.11.9.1 Bypass Registers

A write action to at least the low byte of the bypass data register sets BYPCR.BDV = 1
(bypass data tagged valid).
BYP
Bypass Data Register (100H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BDATA
rw
Bit (Field) Width Type Description

BDATA [15:0] rw Bypass Data
This bit field contains the bypass data.

XMC4500
XMC4000 Family
BYPCR
Bypass Control Register (104H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 BHPC BSELO
r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BPRI BDV BDS
BDV 0 BDEN 0 0 BWLE
O TR SM
rh r rw rw rw r rw r rw

BWLE [3:0] rw Bypass Word Length
This bit field defines the word length of the bypass
data. The word length is given by BWLE + 1 with the
data word being right-aligned in the data buffer at the
bit positions [BWLE down to 0].
The bypass data word is always considered as an
own frame with the length of BWLE.
Same coding as SCTR.WLE.
BDSSM 8 rw Bypass Data Single Shot Mode
This bit defines if the bypass data is considered as
permanently valid or if the bypass data is only
transferred once (single shot mode).
0B The bypass data is still considered as valid after
it has been loaded into TBUF. The loading of
the data into TBUF does not clear BDV.
1B The bypass data is considered as invalid after it
has been loaded into TBUF. The loading of the
data into TBUF clears BDV.

XMC4500
XMC4000 Family

BDEN [11:10] rw Bypass Data Enable
This bit field defines if and how the transfer of bypass
data to TBUF is enabled.
00B The transfer of bypass data is disabled.
01B The transfer of bypass data to TBUF is
possible. Bypass data will be transferred to
TBUF according to its priority if BDV = 1.
10B Gated bypass data transfer is enabled. Bypass
data will be transferred to TBUF according to its
priority if BDV = 1 and while DX2S = 0.
11B Gated bypass data transfer is enabled. Bypass
data will be transferred to TBUF according to its
priority if BDV = 1 and while DX2S = 1.
BDVTR 12 rw Bypass Data Valid Trigger
This bit enables the bypass data for being tagged
valid when DX2T is active (for time framing or time-
out purposes).
0B Bit BDV is not influenced by DX2T.
1B Bit BDV is set if DX2T is active.
BPRIO 13 rw Bypass Priority
This bit defines the priority between the bypass data
and the transmit FIFO data.
0B The transmit FIFO data has a higher priority
than the bypass data.
1B The bypass data has a higher priority than the
transmit FIFO data.
BDV 15 rh Bypass Data Valid
This bit defines if the bypass data is valid for a transfer
to TBUF. This bit is set automatically by a write
access to at least the low-byte of register BYP. It can
be cleared by software by writing TRBSCR.CBDV.
0B The bypass data is not valid.
1B The bypass data is valid.
BSELO [20:16] rw Bypass Select Outputs
This bit field contains the value that is written to
PCR.CTR[20:16] if bypass data is transferred to
TBUF while TCSR.SELMD = 1.
In the SSC protocol, this bit field can be used to define
which SELOx output line will be activated when
bypass data is transmitted.

XMC4500
XMC4000 Family

BHPC [23:21] rw Bypass Hardware Port Control
This bit field contains the value that is written to
SCTR[4:2] if bypass data is transferred to TBUF while
TCSR.HPCMD = 1.
In the SSC protocol, this bit field can be used to define
the data shift mode and if hardware port control is
enabled through CCR.HPCEN = 1, the pin direction
when bypass data is transmitted.
[31:24]
17.11.9.2 General FIFO Buffer Control Registers

The transmit and receive FIFO status information of USICx_CHy is given in registers
USICx_CHy.TRBSR.
The bits related to the transmitter buffer in this register can only by written if the transmit
buffer functionality is enabled by CCFG.TB = 1, otherwise write accesses are ignored. A
similar behavior applies for the bits related to the receive buffer referring to
CCFG.RB = 1.
The interrupt flags (event flags) in the transmit and receive FIFO status register TRBSR
can be cleared by writing a 1 to the corresponding bit position in register TRBSCR,
whereas writing a 0 has to effect on these bits. Writing a 1 by software to SRBI, RBERI,
ARBI, STBI, or TBERI sets the corresponding bit to simulate the detection of a
transmit/receive buffer event, but without activating any service request output
(therefore, see FMR.SIOx).
Bits TBUS and RBUS have been implemented for testing purposes. They can be ignored
by data handling software. Please note that a read action can deliver either a 0 or a 1 for
these bits. It is recommended to treat them as dont care.

XMC4500
XMC4000 Family
TRBSR
Transmit/Receive Buffer Status Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 TBFLVL 0 RBFLVL
r rh r rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
STB TBU TFU TEM TBE SRB RBU RFU REM RBE
0 0 STBI 0 ARBI SRBI
T S LL PTY RI T S LL PTY RI
r rh rh rh rh r rwh rwh r rh rh rh rh rwh rwh rwh

SRBI 0 rwh Standard Receive Buffer Event
This bit indicates that a standard receive buffer event
has been detected. It is cleared by writing
TRBSCR.CSRBI = 1.
If enabled by RBCTR.SRBIEN, the service request
output SRx selected by RBCTR.SRBINP becomes
activated if a standard receive buffer event is
detected.
0B A standard receive buffer event has not been
detected.
1B A standard receive buffer event has been
detected.
RBERI 1 rwh Receive Buffer Error Event
This bit indicates that a receive buffer error event has
been detected. It is cleared by writing
TRBSCR.CRBERI = 1.
If enabled by RBCTR.RBERIEN, the service request
output SRx selected by RBCTR.ARBINP becomes
activated if a receive buffer error event is detected.
0B A receive buffer error event has not been
detected.
1B A receive buffer error event has been
detected.

XMC4500
XMC4000 Family

ARBI 2 rwh Alternative Receive Buffer Event
This bit indicates that an alternative receive buffer
event has been detected. It is cleared by writing
TRBSCR.CARBI = 1.
If enabled by RBCTR.ARBIEN, the service request
output SRx selected by RBCTR.ARBINP becomes
activated if an alternative receive buffer event is
detected.
0B An alternative receive buffer event has not
been detected.
1B An alternative receive buffer event has been
detected.
REMPTY 3 rh Receive Buffer Empty
This bit indicates whether the receive buffer is
empty.
0B The receive buffer is not empty.
1B The receive buffer is empty.
RFULL 4 rh Receive Buffer Full
This bit indicates whether the receive buffer is full.
0B The receive buffer is not full.
1B The receive buffer is full.
RBUS 5 rh Receive Buffer Busy
This bit indicates whether the receive buffer is
currently updated by the FIFO handler.
0B The receive buffer information has been
completely updated.
1B The OUTR update from the FIFO memory is
ongoing. A read from OUTR will be delayed.
FIFO pointers from the previous read are not
yet updated.
SRBT 6 rh Standard Receive Buffer Event Trigger
This bit triggers a standard receive buffer event
when set.
If enabled by RBCTR.SRBIEN, the service request
output SRx selected by RBCTR.SRBINP becomes
activated until the bit is cleared.
0B A standard receive buffer event is not triggered
using this bit.
1B A standard receive buffer event is triggered
using this bit.

XMC4500
XMC4000 Family

STBI 8 rwh Standard Transmit Buffer Event
This bit indicates that a standard transmit buffer
event has been detected. It is cleared by writing
TRBSCR.CSTBI = 1.
If enabled by TBCTR.STBIEN, the service request
output SRx selected by TBCTR.STBINP becomes
activated if a standard transmit buffer event is
detected.
0B A standard transmit buffer event has not been
detected.
1B A standard transmit buffer event has been
detected.
TBERI 9 rwh Transmit Buffer Error Event
This bit indicates that a transmit buffer error event
has been detected. It is cleared by writing
TRBSCR.CTBERI = 1.
If enabled by TBCTR.TBERIEN, the service request
output SRx selected by TBCTR.ATBINP becomes
activated if a transmit buffer error event is detected.
0B A transmit buffer error event has not been
detected.
1B A transmit buffer error event has been
detected.
TEMPTY 11 rh Transmit Buffer Empty
This bit indicates whether the transmit buffer is
empty.
0B The transmit buffer is not empty.
1B The transmit buffer is empty.
TFULL 12 rh Transmit Buffer Full
This bit indicates whether the transmit buffer is full.
0B The transmit buffer is not full.
1B The transmit buffer is full.

XMC4500
XMC4000 Family

TBUS 13 rh Transmit Buffer Busy
This bit indicates whether the transmit buffer is
currently updated by the FIFO handler.
0B The transmit buffer information has been
completely updated.
1B The FIFO memory update after write to INx is
ongoing. A write to INx will be delayed. FIFO
pointers from the previous INx write are not yet
updated.
STBT 14 rh Standard Transmit Buffer Event Trigger
This bit triggers a standard transmit buffer event
when set.
If enabled by TBCTR.STBIEN, the service request
output SRx selected by TBCTR.STBINP becomes
activated until the bit is cleared.
0B A standard transmit buffer event is not
triggered using this bit.
1B A standard transmit buffer event is triggered
using this bit.
RBFLVL [22:16] rh Receive Buffer Filling Level
This bit field indicates the filling level of the receive
buffer, starting with 0 for an empty buffer.
TBFLVL [30:24] rh Transmit Buffer Filling Level
This bit field indicates the filling level of the transmit
buffer, starting with 0 for an empty buffer.
0 7, 10, r Reserved
15, 23, Read as 0; should be written with 0.
31

XMC4500
XMC4000 Family
The bits in register TRBSCR are used to clear the notification bits in register TRBSR or
to clear the FIFO mechanism for the transmit or receive buffer. A read action always
delivers 0.
TRBSCR
Transmit/Receive Buffer Status Clear Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FLU FLU
CBD CTB CST CAR CRB CSR
SHT SHR 0 0
V ERI BI BI ERI BI
B B
w w r w w w r w w w

CSRBI 0 w Clear Standard Receive Buffer Event
0B No effect.
1B Clear TRBSR.SRBI.
CRBERI 1 w Clear Receive Buffer Error Event
0B No effect.
1B Clear TRBSR.RBERI.
CARBI 2 w Clear Alternative Receive Buffer Event
0B No effect.
1B Clear TRBSR.ARBI.
CSTBI 8 w Clear Standard Transmit Buffer Event
0B No effect.
1B Clear TRBSR.STBI.
CTBERI 9 w Clear Transmit Buffer Error Event
0B No effect.
1B Clear TRBSR.TBERI.
CBDV 10 w Clear Bypass Data Valid
0B No effect.
1B Clear BYPCR.BDV.

XMC4500
XMC4000 Family

FLUSHRB 14 w Flush Receive Buffer
0B No effect.
1B The receive FIFO buffer is cleared (filling level
is cleared and output pointer is set to input
pointer value). Should only be used while the
FIFO buffer is not taking part in data traffic.
FLUSHTB 15 w Flush Transmit Buffer
0B No effect.
1B The transmit FIFO buffer is cleared (filling level
is cleared and output pointer is set to input
pointer value). Should only be used while the
FIFO buffer is not taking part in data traffic.
0 [7:3], r Reserved
[31:16]
17.11.9.3 Transmit FIFO Buffer Control Registers

The transmit FIFO buffer is controlled by register TBCTR. TBCTR can only by written if
the transmit buffer functionality is enabled by CCFG.TB = 1, otherwise write accesses
are ignored.
TBCTR
Transmitter Buffer Control Register (108H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TBE STBI
0 LOF 0 SIZE 0 ATBINP STBINP
RIEN EN
rw rw r rw r rw r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
STB STB
LIMIT 0 DPTR
TEN TM
rw rw rw r w

XMC4500
XMC4000 Family

DPTR [5:0] w Data Pointer
This bit field defines the start value for the transmit
buffer pointers when assigning the FIFO entries to
the transmit FIFO buffer. A read always delivers 0.
When writing DPTR while SIZE = 0, both transmitter
pointers TDIPTR and RTDOPTR in register
TRBPTR are updated with the written value and the
buffer is considered as empty. A write access to
DPTR while SIZE > 0 is ignored and does not modify
the pointers.
LIMIT [13:8] rw Limit For Interrupt Generation
This bit field defines the target filling level of the
transmit FIFO buffer that is used for the standard
transmit buffer event detection.
STBTM 14 rw Standard Transmit Buffer Trigger Mode
This bit selects the standard transmit buffer event
trigger mode.
0B Trigger mode 0:
If enabled by TBCTR.STBTEN = 1, the
transition of the transmit buffer fill level away
from the programmed limit, sets the bit
TRBSR.STBT.
1B Trigger mode 1:
If enabled by TBCTR.STBTEN = 1, the
condition whereby the transmit buffer fill level
is below the buffer size, sets the bit
TRBSR.STBT.
STBTEN 15 rw Standard Transmit Buffer Trigger Enable
This bit enables/disables triggering of the standard
transmit buffer event through bit TRBSR.STBT.
0B The standard transmit buffer event trigger
through bit TRBSR.STBT is disabled.
1B The standard transmit buffer event trigger
through bit TRBSR.STBT is enabled.

XMC4500
XMC4000 Family

STBINP [18:16] rw Standard Transmit Buffer Interrupt Node Pointer
SRx becomes activated in case of a standard
transmit buffer event.
ATBINP [21:19] rw Alternative Transmit Buffer Interrupt Node
Pointer
This bit field define which service request output SRx
will be activated in case of a transmit buffer error
event.
SIZE [26:24] rw Buffer Size
This bit field defines the number of FIFO entries
assigned to the transmit FIFO buffer.
000B The FIFO mechanism is disabled. The buffer
does not accept any request for data.
001B The FIFO buffer contains 2 entries.
111B Reserved

XMC4500
XMC4000 Family

LOF 28 rw Buffer Event on Limit Overflow
This bit defines which relation between filling level
and programmed limit leads to a standard transmit
buffer event.
0B A standard transmit buffer event occurs when
the filling level equals the limit value and gets
lower due to transmission of a data word.
1B A standard transmit buffer interrupt event
occurs when the filling level equals the limit
value and gets bigger due to a write access to
a data input location INx.
STBIEN 30 rw Standard Transmit Buffer Interrupt Enable
This bit enables/disables the generation of a
standard transmit buffer interrupt in case of a
standard transmit buffer event.
0B The standard transmit buffer interrupt
generation is disabled.
1B The standard transmit buffer interrupt
generation is enabled.
TBERIEN 31 rw Transmit Buffer Error Interrupt Enable
This bit enables/disables the generation of a transmit
buffer error interrupt in case of a transmit buffer error
event (software writes to a full transmit buffer).
0B The transmit buffer error interrupt generation
is disabled.
1B The transmit buffer error interrupt generation
is enabled.
0 [7:6], r Reserved
27, 29

XMC4500
XMC4000 Family
17.11.9.4 Receive FIFO Buffer Control Registers

The receive FIFO buffer is controlled by register RBCTR. This register can only be
written if the receive buffer functionality is enabled by CCFG.RB = 1, otherwise write
accesses are ignored.
RBCTR
Receiver Buffer Control Register (10CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RBE SRBI ARBI
LOF RNM SIZE RCIM ARBINP SRBINP
RIEN EN EN
rw rw rw rw rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SRB SRB
LIMIT 0 DPTR
TEN TM
rw rw rw r w

DPTR [5:0] w Data Pointer
This bit field defines the start value for the receive
buffer pointers when assigning the FIFO entries to
the receive FIFO buffer. A read always delivers 0.
When writing DPTR while SIZE = 0, both receiver
pointers RDIPTR and RDOPTR in register TRBPTR
are updated with the written value and the buffer is
considered as empty. A write access to DPTR while
SIZE > 0 is ignored and does not modify the
pointers.
LIMIT [13:8] rw Limit For Interrupt Generation
This bit field defines the target filling level of the
receive FIFO buffer that is used for the standard
receive buffer event detection.

XMC4500
XMC4000 Family

SRBTM 14 rw Standard Receive Buffer Trigger Mode
This bit selects the standard receive buffer event
trigger mode.
0B Trigger mode 0:
If enabled by RBCTR.SRBTEN = 1, the
transition of the transmit buffer fill level away
from the programmed limit, sets the bit
TRBSR.SRBT.
1B Trigger mode 1:
If enabled by RBCTR.SRBTEN = 1, the
condition whereby the transmit buffer fill level
is above 0, sets the bit TRBSR.SRBT.
SRBTEN 15 rw Standard Receive Buffer Trigger Enable
This bit enables/disables triggering of the standard
receive buffer event through bit TRBSR.SRBT.
0B The standard receive buffer event trigger
through bit TRBSR.SRBT is disabled.
1B The standard receive buffer event trigger
through bit TRBSR.SRBT is enabled.
SRBINP [18:16] rw Standard Receive Buffer Interrupt Node Pointer
SRx becomes activated in case of a standard
receive buffer event.

XMC4500
XMC4000 Family

ARBINP [21:19] rw Alternative Receive Buffer Interrupt Node
Pointer
SRx becomes activated in case of an alternative
receive buffer event or a receive buffer error event.
RCIM [23:22] rw Receiver Control Information Mode
This bit field defines which information from the
receiver status register RBUFSR is propagated as
5 bit receiver control information RCI[4:0] to the
receive FIFO buffer and can be read out in registers
OUT(D)R.
00B RCI[4] = PERR, RCI[3:0] = WLEN
01B RCI[4] = SOF, RCI[3:0] = WLEN
10B RCI[4] = 0, RCI[3:0] = WLEN
11B RCI[4] = PERR, RCI[3] = PAR,
RCI[2:1] = 00B, RCI[0] = SOF
SIZE [26:24] rw Buffer Size
This bit field defines the number of FIFO entries
assigned to the receive FIFO buffer.
000B The FIFO mechanism is disabled. The buffer
does not accept any request for data.
111B Reserved

XMC4500
XMC4000 Family

RNM 27 rw Receiver Notification Mode
This bit defines the receive buffer event mode. The
receive buffer error event is not affected by RNM.
0B Filling level mode:
A standard receive buffer event occurs when
the filling level equals the limit value and
changes, either due to a read access from
OUTR (LOF = 0) or due to a new received
data word (LOF = 1).
1B RCI mode:
A standard receive buffer event occurs when
register OUTR is updated with a new value if
the corresponding value in OUTR.RCI[4] = 0.
If OUTR.RCI[4] = 1, an alternative receive
buffer event occurs instead of the standard
receive buffer event.
LOF 28 rw Buffer Event on Limit Overflow
This bit defines which relation between filling level
and programmed limit leads to a standard receive
buffer event in filling level mode (RNM = 0). In RCI
mode (RNM = 1), bit fields LIMIT and LOF are
ignored.
0B A standard receive buffer event occurs when
lower due to a read access from OUTR.
1B A standard receive buffer event occurs when
bigger due to the reception of a new data word.
ARBIEN 29 rw Alternative Receive Buffer Interrupt Enable
This bit enables/disables the generation of an
alternative receive buffer interrupt in case of an
alternative receive buffer event.
0B The alternative receive buffer interrupt
1B The alternative receive buffer interrupt

XMC4500
XMC4000 Family

SRBIEN 30 rw Standard Receive Buffer Interrupt Enable
This bit enables/disables the generation of a
standard receive buffer interrupt in case of a
standard receive buffer event.
0B The standard receive buffer interrupt
1B The standard receive buffer interrupt
RBERIEN 31 rw Receive Buffer Error Interrupt Enable
This bit enables/disables the generation of a receive
buffer error interrupt in case of a receive buffer error
event (the software reads from an empty receive
buffer).
0B The receive buffer error interrupt generation is
disabled.
1B The receive buffer error interrupt generation is
enabled.
0 [7:6] r Reserved

XMC4500
XMC4000 Family
17.11.9.5 FIFO Buffer Data Registers

The 32 independent data input locations IN00 to IN31 are addresses that can be used
as data entry locations for the transmit FIFO buffer. Data written to one of these locations
will be stored in the transmit buffer FIFO. Additionally, the 5-bit coding of the number
[31:0] of the addressed data input location represents the transmit control information
TCI.
If the FIFO is already full and new data is written to it, the write access is ignored and a
transmit buffer error event is signaled.
INx (x = 00-31)
Transmit FIFO Buffer Input Location x
(180H + x *4) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TDATA

TDATA [15:0] w Transmit Data
This bit field contains the data to be transmitted (write
view), read actions deliver 0.
A write action to at least the low byte of TDATA
triggers the data storage in the FIFO.

XMC4500
XMC4000 Family
The receiver FIFO buffer output register OUTR shows the oldest received data word in
the FIFO buffer and contains the receiver control information RCI containing the
information selected by RBCTR.RCIM. A read action from this address location delivers
the received data. With a read access of at least the low byte, the data is declared to be
read and the next entry becomes visible. Write accesses to OUTR are ignored.
OUTR
Receiver Buffer Output Register (11CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 RCI
r rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DSR
rh

DSR [15:0] rh Received Data
This bit field monitors the content of the oldest data
word in the receive FIFO.
Reading at least the low byte releases the buffer entry
currently shown in DSR.
RCI [20:16] rh Receiver Control Information
This bit field monitors the receiver control information
associated to DSR. The bit structure of RCI depends
on bit field RBCTR.RCIM.

XMC4500
XMC4000 Family
If a debugger should be used to monitor the received data in the FIFO buffer, the FIFO
mechanism must not be activated in order to guaranty data consistency. Therefore, a
second address set is available, named OUTDR (D like debugger), having the same bit
fields like the original buffer output register OUTR, but without the FIFO mechanism. A
debugger can read here (in order to monitor the receive data flow) without the risk of data
corruption. Write accesses to OUTDR are ignored.
OUTDR
Receiver Buffer Output Register L for Debugger
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 RCI
r rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DSR
rh

DSR [15:0] rh Data from Shift Register
Same as OUTR.DSR, but without releasing the buffer
after a read action.
RCI [20:16] rh Receive Control Information from Shift Register
Same as OUTR.RCI.

XMC4500
XMC4000 Family
17.11.9.6 FIFO Buffer Pointer Registers

The pointers for FIFO handling of the transmit and receive FIFO buffers are located in
register TRBPTR. The pointers are automatically handled by the FIFO buffer mechanism
and do not need to be modified by software. As a consequence, these registers can only
be read by software (e.g. for verification purposes), whereas write accesses are ignored.
TRBPTR
Transmit/Receive Buffer Pointer Register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 RDOPTR 0 RDIPTR
r rh r rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 TDOPTR 0 TDIPTR
r rh r rh

TDIPTR [5:0] rh Transmitter Data Input Pointer
This bit field indicates the buffer entry that will be
used for the next transmit data coming from the INx
addresses.
TDOPTR [13:8] rh Transmitter Data Output Pointer
used for the next transmit data to be output to TBUF.
RDIPTR [21:16] rh Receiver Data Input Pointer
used for the next receive data coming from RBUF.
RDOPTR [29:24] rh Receiver Data Output Pointer
used for the next receive data to be output at the
OUT(D)R addresses.
0 [7:6], r Reserved
[23:22],
[31:30]

XMC4500
XMC4000 Family
17.12 Interconnects
The XMC4500 device contains three USIC modules (USIC0, USIC1 and USIC2) with 2
communication channels each.
Port Lines Port Lines Port Lines
USIC0 USIC1 USIC2

Channel 0
Channel 1
Channel 0
Channel 1
Channel 0
Channel 1
Bus Interface Bus Interface Bus Interface
AHB-Lite Bus
Figure 17-65 USIC Module Structure in XMC4500

Figure 17-66 shows the I/O lines of one USIC channel. The tables in this section define
the pin assignments and internal connections of the USIC channels I/O lines in the
XMC4500 device. Naming convention: USICx_CHy refers to USIC module x channel y.

XMC4500
XMC4000 Family
USIC Channel
DX0A
Input HWDIR
: : Hardware HWEN0
: : Stage
Port HWEN1
DX0G
Control HWEN2
HWIN0 DX0 HWEN3
DX0INS
DX1A SR0
: : Input SR1
: : Stage Interrupt SR2
DX1G Control SR3
DX1 SR4
SR5
DX1INS
DX2A SELO0
: : Input SELO1
Slave
: : Stage : :
Select
DX2G : :
Generator SELO6
DX2
SELO7
DX2INS
DX3A
: : Input DOUT0
Output
: : Stage DOUT1
Stage
DX3G DOUT2
HWIN1 DOUT DOUT3
DX3
DX3INS
DX4A
: : Input
Baud SCLKOUT
: : Stage
Rate
DX4G
Generator MCLKOUT
HWIN2 DX4
DX4INS
DX5A
: : Input
: : Stage
DX5G
HWIN3 DX5
DX5INS
Figure 17-66 USIC Channel I/O Lines

The connections of the service request outputs SR[5:0] are described in Section 17.7.
17.12.1 USIC Module 0 Interconnects

The interconnects of USIC module 0 is grouped into the following categories:
USIC Module 0 Channel 0 Interconnects (Table 17-22)

XMC4500
XMC4000 Family
Table 17-22 USIC Module 0 Channel 0 Interconnects

Data Inputs (DX0)
USIC0_CH0.DX0A I P1.5 Shift data input
USIC0_CH0.DX0B I P1.4 Shift data input
USIC0_CH0.DX0C I P4.7 Shift data input
USIC0_CH0.DX0D I P5.0 Shift data input
USIC0_CH0.DX0E I 0 Shift data input
USIC0_CH0.DX0F I XTAL1 Shift data input
USIC0_CH0.DX0G I USIC0_CH0.DOUT0 Loop back shift data input
USIC0_CH0.HWIN0 I P1.5 HW controlled shift data input
Clock Inputs
USIC0_CH0.DX1A I P1.1 Shift clock input
USIC0_CH0.DX1B I P0.8 Shift clock input
USIC0_CH0.DX1C I 0 Shift clock input
USIC0_CH0.DX1D I 0 Shift clock input
USIC0_CH0.DX1E I 0 Shift clock input
USIC0_CH0.DX1F I USIC0_CH0.DX0INS Shift clock input
USIC0_CH0.DX1G I USIC0_CH0.SCLKOU Loop back shift clock input
T
Control Inputs
USIC0_CH0.DX2A I P1.0 Shift control input
USIC0_CH0.DX2B I P0.7 Shift control input
USIC0_CH0.DX2C I 0 Shift control input
USIC0_CH0.DX2D I 0 Shift control input
USIC0_CH0.DX2E I CCU40.SR1 Shift control input
USIC0_CH0.DX2F I CCU80.SR1 Shift control input
USIC0_CH0.DX2G I USIC0_CH0.SELO0 Loop back shift control input
Data Inputs (DX3)
USIC0_CH0.DX3A I 0 Shift data input
USIC0_CH0.DX3B I 0 Shift data input

XMC4500
XMC4000 Family
Table 17-22 USIC Module 0 Channel 0 Interconnects (contd)

USIC0_CH0.DX3C I 0 Shift data input
USIC0_CH0.DX3D I 0 Shift data input
USIC0_CH0.DX3F I 0 Shift data input
Data Inputs (DX4)
Data Inputs (DX5)
Data Outputs
USIC0_CH0.DOUT0 O P1.5 Shift data output
P1.7
P5.1
P1.5.HW0_OUT
USIC0_CH0.DOUT1 O P1.4.HW0_OUT Shift data output

XMC4500
XMC4000 Family

Clock Outputs
USIC0_CH0.MCLKO O P1.3 Master clock output
UT
USIC0_CH0.SCLKOU O P0.8 Shift clock output
T P1.1
P1.6
P1.10
Control Outputs
USIC0_CH0.SELO0 O P0.7 Shift control output
P1.0
P1.11
USIC0_CH0.SELO6 O not connected Shift control output
System Related Outputs
USIC0_CH0.DX0INS O USIC0_CH0.DX1F Selected DX0 input signal
USIC0_CH0.DX1INS O DAC.TRIGGER[6] Selected DX1 input signal
USIC0_CH0.DX2INS O CCU40.IN0L Selected DX2 input signal
CCU42.IN0L
CCU43.IN0L
USIC0_CH0.DX3INS O not connected Selected DX3 input signal

XMC4500
XMC4000 Family

Data Inputs (DX0)
USIC0_CH1.DX0E I P4.0 Shift data input
Clock Inputs
USIC0_CH1.DX1C I P6.2 Shift clock input
T
Control Inputs
USIC0_CH1.DX2C I P6.1 Shift control input
Data Inputs (DX3)

XMC4500
XMC4000 Family

Data Inputs (DX4)
Data Inputs (DX5)
Data Outputs
P3.5
P3.13
P6.4
P3.13.HW0_OUT

XMC4500
XMC4000 Family

Clock Outputs
UT
T P3.0
P3.6
P6.2
Control Outputs
P3.1
P4.1
P6.1
P6.0
P3.11
P3.8
CCU42.IN1L
CCU43.IN1L

XMC4500
XMC4000 Family

The interconnects of USIC module 1 is grouped into the following three categories:

Data Inputs (DX0)
Clock Inputs
T
Control Inputs

XMC4500
XMC4000 Family

Data Inputs (DX3)
Data Inputs (DX4)
Data Inputs (DX5)
Data Outputs
P2.14
P0.5.HW0_OUT

XMC4500
XMC4000 Family

Clock Outputs
UT
T P5.8
Control Outputs
P5.9
P5.11
USIC1_CH0.DX1INS O DAC.TRIGGER[7] Selected DX1 input signal
CCU42.IN2L
CCU43.IN2L

XMC4500
XMC4000 Family

Data Inputs (DX0)
USIC1_CH1.DX0E I CAN1INS Shift data input
Clock Inputs
USIC1_CH1.DX1C I P4.0 Shift clock input
T
Control Inputs
Data Inputs (DX3)

XMC4500
XMC4000 Family

Data Inputs (DX4)
Data Inputs (DX5)
Data Outputs
P3.15
P4.2
P3.15.HW0_OUT

XMC4500
XMC4000 Family

Clock Outputs
UT
T P0.13
Control Outputs
P0.12
P3.3
CCU43.IN3L

The interconnects of USIC module 2 is grouped into the following three categories:

XMC4500
XMC4000 Family

Data Inputs (DX0)
Clock Inputs
USIC2_CH0.DX1B I 0 Shift clock input
T
Control Inputs
USIC2_CH0.DX2B I 0 Shift control input
Data Inputs (DX3)

XMC4500
XMC4000 Family

Data Inputs (DX4)
Data Inputs (DX5)
Data Outputs
P5.0
P5.0.HW0_OUT
Clock Outputs

XMC4500
XMC4000 Family

USIC2_CH0.MCLKO O not connected Master clock output
UT
T P5.2
Control Outputs
P5.3

Data Inputs (DX0)
USIC2_CH1.DX0E I CAN1INS Shift data input

XMC4500
XMC4000 Family

Clock Inputs
T
Control Inputs
Data Inputs (DX3)
Data Inputs (DX4)

XMC4500
XMC4000 Family

Data Inputs (DX5)
Data Outputs
P3.11
P4.7.HW0_OUT
Clock Outputs
UT
T P3.13
P4.2
Control Outputs
P4.1

XMC4500
XMC4000 Family


XMC4500
XMC4000 Family
Controller Area Network Controller (MultiCAN)
18 Controller Area Network Controller (MultiCAN)

This chapter describes the MultiCAN controller of the XMC4500. It contains the following
sections:
CAN basics (see Page 18-5)
Overview of the CAN Module in the XMC4500 (see Page 18-4)
Functional description of the MultiCAN Kernel (see Page 18-14)
MultiCAN Kernel register description (see Page 18-59)
XMC4500 implementation-specific details are listed below,
Service Request Generation (see Page 18-53)
Debug Behavior (see Page 18-55)
Power, Reset and Clock (see Page 18-56)
Interconnects (see Page 18-120)
Note: The MultiCAN register names described in this chapter are referenced in the
XMC4500 Reference Manual by the module name prefix CAN_.

MultiCAN, V2.3 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
18.1 Overview
The MultiCAN module contains independently operating CAN nodes with Full-CAN
functionality that are able to exchange Data and Remote Frames via a gateway function.
Transmission and reception of CAN frames is handled in accordance with CAN
specification V2.0 B (active). Each CAN node can receive and transmit standard frames
with 11-bit identifiers as well as extended frames with 29-bit identifiers.
All CAN nodes share a common set of message objects. Each message object can be
individually allocated to one of the CAN nodes. Besides serving as a storage container
for incoming and outgoing frames, message objects can be combined to build gateways
between the CAN nodes or to setup a FIFO buffer.
The message objects are organized in double-chained linked lists, where each CAN
node has its own list of message objects. A CAN node stores frames only into message
objects that are allocated to the message object list of the CAN node, and it transmits
only messages belonging to this message object list. A powerful, command-driven list
controller performs all message object list operations.
The bit timings for the CAN nodes are derived from the module timer clock (fCAN), and
are programmable up to a data rate of 1 Mbit/s. External bus transceivers are connected
to a CAN node via a pair of receive and transmit pins.
18.1.1 Features
The MultiCAN module provides the following functionality:
3 independent CAN nodes and 64 message objects available.
Compliant with ISO 11898
CAN functionality according to CAN specification V2.0 B active
Dedicated control registers for each CAN node
Data transfer rates up to 1 Mbit/s
Flexible and powerful message transfer control and error handling capabilities
Advanced CAN bus bit timing analysis and baud rate detection for each CAN node
via a frame counter
Full-CAN functionality: A set of 64 message objects can be individually
Allocated (assigned) to any CAN node
Configured as transmit or receive object
Set up to handle frames with 11-bit or 29-bit identifier
Identified by a timestamp via a frame counter
Configured to remote monitoring mode
Advanced acceptance filtering
Each message object provides an individual acceptance mask to filter incoming
frames
A message object can be configured to accept standard or extended frames or to
accept both standard and extended frames

XMC4500
XMC4000 Family
Message objects can be grouped into four priority classes for transmission and
reception
The selection of the message to be transmitted first can be based on frame
identifier, IDE bit and RTR bit according to CAN arbitration rules, or according to
its order in the list
Advanced message object functionality
Message objects can be combined to build FIFO message buffers of arbitrary size,
limited only by the total number of message objects
Message objects can be linked to form a gateway that automatically transfers
frames between two different CAN buses. A single gateway can link any two CAN
nodes. An arbitrary number of gateways can be defined.
Advanced data management
The message objects are organized in double-chained lists
List reorganizations can be performed at any time, even during full operation of the
CAN nodes
A powerful, command-driven list controller manages the organization of the list
structure and ensures consistency of the list
Message FIFOs are based on the list structure and can easily be scaled in size
during CAN operation
Static allocation commands offer compatibility with TwinCAN applications that are
not list-based
Advanced interrupt handling
Up to 8 interrupt output lines are available. Interrupt requests can be routed
individually to one of the 8 interrupt output lines
Message post-processing notifications can be mapped flexibly using dedicated
registers consisting of notification bits

XMC4500
XMC4000 Family

This section describes the serial communication module called MultiCAN
(CAN = Controller Area Network) of the XMC4500. A MultiCAN module can contain
between two and eight independent CAN nodes, depending on the device, each
representing one serial communication interface.
MultiCAN Module Kernel

fCAN TXDC x-1
CAN
Clock Node x-1
Control f CLC RXDCx-1
Message . . .
Object . . .
Buffer Linked . . .
Address List Port
Decoder Control CAN TXDC1 Control
n
Objects Node 1
RXDC1
CAN TXDC0
Node 0
RXDC0
Interrupt
Control CAN Control
MultiCAN_overview_x_n_noTT.vsd
Figure 18-1 Overview of the MultiCAN Module

XMC4500
XMC4000 Family
18.2 CAN Basics

CAN is an asynchronous serial bus system with one logical bus line. It has an open,
linear bus structure with equal bus participants called nodes. A CAN bus consists of two
or more nodes.
The bus logic corresponds to a wired-AND mechanism. Recessive bits (equivalent to
the logic 1 level) are overwritten by dominant bits (logic 0 level). As long as no bus node
is sending a dominant bit, the bus is in the recessive state. In this state, a dominant bit
from any bus node generates a dominant bus state. The maximum CAN bus speed is,
by definition, 1 Mbit/s. This speed limits the CAN bus to a length of up to 40 m. For bus
lengths longer than 40 m, the bus speed must be reduced.
The binary data of a CAN frame is coded in NRZ code (Non-Return-to-Zero). To ensure
re-synchronization of all bus nodes, bit stuffing is used. This means that during the
transmission of a message, a maximum of five consecutive bits can have the same
polarity. Whenever five consecutive bits of the same polarity have been transmitted, the
transmitter will insert one additional bit (stuff bit) of the opposite polarity into the bit
stream before transmitting further bits. The receiver also checks the number of bits with
the same polarity and removes the stuff bits from the bit stream (= destuffing).
18.2.1 Addressing and Bus Arbitration

In the CAN protocol, address information is defined in the identifier field of a message.
The identifier indicates the contents of the message and its priority. The lower the binary
value of the identifier, the higher is the priority of the message.
For bus arbitration, CSMA/CD with NDA (Carrier Sense Multiple Access/Collision
Detection with Non-Destructive Arbitration) is used. If bus node A attempts to transmit a
message across the network, it first checks that the bus is in the idle state (Carrier
Sense) i.e. no node is currently transmitting. If this is the case (and no other node
wishes to start a transmission at the same moment), node A becomes the bus master
and sends its message. All other nodes switch to receive mode during the first
transmitted bit (Start-Of-Frame bit). After correct reception of the message
(acknowledged by each node), each bus node checks the message identifier and stores
the message, if required. Otherwise, the message is discarded.
If two or more bus nodes start their transmission at the same time (Multiple Access),
bus collision of the messages is avoided by bit-wise arbitration (Collision Detection /
Non-Destructive Arbitration together with the Wired-AND mechanism, dominant bits
override recessive bits). Each node that sends also reads back the bus level. When a
recessive bit is sent but a dominant one is read back, bus arbitration is lost and the
transmitting node switches to receive mode. This condition occurs for example when the
message identifier of a competing node has a lower binary value and therefore sends a
message with a higher priority. In this way, the bus node with the highest priority
message wins arbitration without losing time by having to repeat the message. Other
nodes that lost arbitration will automatically try to repeat their transmission once the bus

XMC4500
XMC4000 Family
returns to idle state. Therefore, the same identifier can be sent in a Data Frame only by
one node in the system. There must not be more than one node programmed to send
Data Frames with the same identifier.
Standard message identifier has a length of 11 bits. CAN specification 2.0B extends the
message identifier lengths to 29 bits, i.e. the extended identifier.
18.2.2 CAN Frame Formats

There are three types of CAN frames:
Data Frames
Remote Frames
Error Frames
A Data Frame contains a Data Field of 0 to 8 bytes in length. A Remote Frame contains
no Data Field and is typically generated as a request for data (e.g. from a sensor). Data
and Remote Frames can use an 11-bit Standard identifier or a 29-bit Extended
identifier. An Error Frame can be generated by any node that detects a CAN bus error.
18.2.2.1 Data Frames

There are two types of Data Frames defined (see Figure 18-2):
Standard Data Frame
Extended Data Frame
Standard Data Frame

A Data Frame begins with the Start-Of-Frame bit (SOF = dominant level) for hard
synchronization of all nodes. The SOF is followed by the Arbitration Field consisting of
12 bits, the 11-bit identifier (reflecting the contents and priority of the message), and the
RTR (Remote Transmission Request) bit. With RTR at dominant level, the frame is
marked as Data Frame. With RTR at recessive level, the frame is defined as a Remote
Frame.
The next field is the Control Field consisting of 6 bits. The first bit of this field is the IDE
(Identifier Extension) bit and is at dominant level for the Standard Data Frame. The
following bit is reserved and defined as a dominant bit. The remaining 4 bits of the
Control Field are the Data Length Code (DLC) that specifies the number of bytes in the
Data Field. The Data Field can be 0 to 8 bytes wide. The Cyclic Redundancy (CRC) Field
that follows the data bytes is used to detect possible transmission errors. It consists of a
15-bit CRC sequence, completed by a recessive CRC delimiter bit.
The final field is the Acknowledge Field. During the ACK Slot, the transmitting node
sends out a recessive bit. Any node that has received an error free frame acknowledges
the correct reception of the frame by sending back a dominant bit, regardless of whether
or not the node is configured to accept that specific message. This behavior assigns the

XMC4500
XMC4000 Family
CAN protocol to the in-bit-response group of protocols. The recessive ACK delimiter
bit, which must not be overwritten by a dominant bit, completes the Acknowledge Field.
Seven recessive End-of-Frame (EOF) bits finish the Data Frame. Between any two
consecutive frames, the bus must remain in the recessive state for at least 3 bit times
(called Inter Frame Space). If after the Inter Frame Space, no other nodes attempt to
transmit the bus remains in idle state with a recessive level.
Standard Data Frame
Recessive Level
Bus Idle 1 11 1 1 1 4 0 - 64 15 1 1 1 7 3 Bus Idle
Dominant Level
Inter Frame Space

End of Frame (EOF)
ACK Delimiter Acknowledge

ACK Slot Field
CRC Delimiter
CRC Field
CRC Sequence
Data Field
Data Length Code
Reserved (D) Control Field
IDE Bit (D)
RTR Bit (D) Arbitration
Identifier Field (12 bit)
Start of Frame
2 Reserved (D)
RTR Bit (D)
29-bit Identfier Arbitration
IDE Bit (R) Field (32 bit)
SRR Bit (R)
Recessive Level
Bus Idle 1 11 1 1 18 1 2 4 0 - 64 15 1 1 1 7 3 Bus Idle
Dominant Level
Extended Data Frame
MCT06258
Figure 18-2 CAN Data Frame
Extended Data Frame

In the Extended CAN Data Frame, the message identifier of the standard frame has
been extended to 29-bit. A split of the extended identifier into two parts, an 11-bit least

XMC4500
XMC4000 Family
significant section (as in standard CAN frame) and an 18-bit most significant section,
ensures that the Identifier Extension bit (IDE) can remain at the same bit position in both
standard and extended frames.
In the Extended CAN Data Frame, the SOF bit is followed by the 32-bit Arbitration Field.
The first 11 bits are the least significant bits of the 29-bit Identifier (Base-ID). These
11 bits are followed by the recessive Substitute Remote Request (SRR) bit. The SRR is
further followed by the recessive IDE bit, which indicates the frame to be an Extended
CAN frame. If arbitration remains unresolved after transmission of the first 11 bits of the
identifier, and if one of the nodes involved in arbitration is sending a Standard CAN
frame, then the Standard CAN frame will win arbitration due to the assertion of its
dominant IDE bit. Therefore, the SRR bit in an Extended CAN frame is recessive to allow
the assertion of a dominant RTR bit by a node that is sending a Standard CAN Remote
Frame. The SRR and IDE bits are followed by the remaining 18 bits of the extended
identifier and the RTR bit.
Control field and frame termination is identical to the Standard Data Frame.
18.2.2.2 Remote Frames

Normally, data transmission is performed on an autonomous basis with the data source
node (e.g. a sensor) sending out a Data Frame. It is also possible, however, for a
destination node (or nodes) to request the data from the source. For this purpose, the
destination node sends a Remote Frame with an identifier that matches the identifier of
the required Data Frame. The appropriate data source node will then send a Data Frame
as a response to this remote request.
There are 2 differences between a Remote Frame and a Data Frame.
The RTR bit is in the recessive state in a Remote Frame.
There is no Data Field in a Remote Frame.
If a Data Frame and a Remote Frame with the same identifier are transmitted at the
same time, the Data Frame wins arbitration due to the dominant RTR bit following the
identifier. In this way, the node that transmitted the Remote Frame receives the
requested data immediately. The format of a Standard and Extended Remote Frames is
shown in Figure 18-3.

XMC4500
XMC4000 Family
Standard Remote Frame
Recessive Level
Bus Idle 1 11 1 1 1 4 15 1 1 1 7 3 Bus Idle
Dominant Level
Inter Frame Space

End of Frame (EOF)
ACK Delimiter Acknowledge

ACK Slot Field
CRC Delimiter
CRC Field
CRC Sequence
Data Length Code
Reserved (D) Control Field
IDE Bit (D)
RTR Bit (D) Arbitration
Identifier Field (12 bit)
Start of Frame
2 Reserved (D)
RTR Bit (D)
29-bit Identfier Arbitration
IDE Bit (R) Field (32 bit)
SRR Bit (R)
Recessive Level
Bus Idle 1 11 1 1 18 1 2 4 15 1 1 1 7 3 Bus Idle
Dominant Level
Extended Remote Frame
MCT06259
Figure 18-3 CAN Remote Frame

XMC4500
XMC4000 Family
18.2.2.3 Error Frames

An Error Frame is generated by any node that detects a bus error. An Error Frame
consists of two fields, an Error Flag field followed by an Error Delimiter field. The Error
Delimiter Field consists of 8 recessive bits and allows the bus nodes to restart bus
communications after an error. There are, however, two forms of Error Flag fields. The
form of the Error Flag field depends on the error status of the node that detects the error.
When an error-active node detects a bus error, the node generates an Error Frame with
an active-error flag. The error-active flag is composed of six consecutive dominant bits
that actively violate the bit-stuffing rule. All other stations recognize a bit-stuffing error
and generate Error Frames themselves. The resulting Error Flag field on the CAN bus
therefore consists of six to twelve consecutive dominant bits (generated by one or more
nodes). The Error Delimiter field completes the Error Frame. After completion of the
Error Frame, bus activity returns to normal and the interrupted node attempts to re-send
the aborted message.
If an error-passive node detects a bus error, the node transmits an error-passive flag
followed, again, by the Error Delimiter field. The error-passive flag consists of six
consecutive recessive bits, and therefore the Error Frame (for an error-passive node)
consists of 14 recessive bits (i.e. no dominant bits). Therefore, the transmission of an
Error Frame by an error-passive node will not affect any other node on the network,
unless the bus error is detected by the node that is actually transmitting (i.e. the bus
master). If the bus master node generates an error-passive flag, this may cause other
nodes to generate Error Frames due to the resulting bit-stuffing violation. After
transmission of an Error Frame an error-passive node must wait for 6 consecutive
recessive bits on the bus before attempting to rejoin bus communications.
Error Frame of "Error Active" Node
Recessive Level
Bus Idle 6 8 Bus Idle
Dominant Level
Error Delimiter Field

Error Flag Field
Recessive Level
Bus Idle 6 8 Bus Idle
Dominant Level
Error Frame of "Error Passive" Node
MCT06260
Figure 18-4 CAN Error Frames

XMC4500
XMC4000 Family
18.2.3 The Nominal Bit Time

One bit cell (this means one high or low pulse of the NRZ code) is composed by four
segments. Each segment is an integer multiple of Time Quanta tQ. The Time Quanta is
the smallest discrete timing resolution used by a CAN node. The nominal bit time
definition with its segments is shown in Figure 18-5.
Nominal Bit Time
Synchronisation Propagation Phase Buffer Phase Buffer

Segment Segment Segment 1 Segment 2
(SYNC_SEG) (PROP_SEG) (PHASE_SEG1) (PHASE_SEG2)
Sample
Point
MCA06261
Figure 18-5 Partition of Nominal Bit Time

The Synchronization Segment (SYNC_SEG) is used to synchronize the various bus
nodes. If there is a bit state change between the previous bit and the current bit, then the
bus state change is expected to occur within this segment. The length of this segment is
always 1 tQ.
The Propagation Segment (PROP_SEG) is used to compensate for signal delays across
the network. These delays are caused by signal propagation delay on the bus line and
through the electronic interface circuits of the bus nodes.
The Phase Segments 1 and 2 (PHASE_SEG1, PHASE_SEG2) are used to compensate
for edge phase errors. These segments can be lengthened or shortened by re-
synchronization. PHASE_SEG2 is reserved for calculation of the subsequent bit level,
and is 2 tQ. At the sample point, the bus level is read and interpreted as the value of
the bit cell. It occurs at the end of PHASE_SEG1.
The total number of tQ in a bit time is between 8 and 25.
As a result of re-synchronization, PHASE_SEG1 can be lengthened or PHASE_SEG2
can be shortened. The amount of lengthening or shortening the phase buffer segments
has an upper limit given by the re-synchronization jump width. The re-synchronization
jump width may be between 1 and 4 tQ, but it may not be longer than PHASE_SEG1.

XMC4500
XMC4000 Family
18.2.4 Error Detection and Error Handling

The CAN protocol has sophisticated error detection mechanisms. The following errors
can be detected:
Cyclic Redundancy Check (CRC) Error
With the Cyclic Redundancy Check, the transmitter calculates special check bits for
the bit sequence from the start of a frame until the end of the Data Field. This CRC
sequence is transmitted in the CRC Field. The receiving node also calculates the
CRC sequence using the same formula, and performs a comparison to the received
sequence. If a mismatch is detected, a CRC error has occurred and an Error Frame
is generated. The message is repeated.
Acknowledge Error
In the Acknowledge Field of a message, the transmitter checks whether a dominant
bit is read during the Acknowledge Slot (that is sent out as a recessive bit). If not, no
other node has received the frame correctly, an Acknowledge Error has occurred,
and the message must be repeated. No Error Frame is generated.
Form Error
If a transmitter detects a dominant bit in one of the four segments End of Frame,
Interframe Space, Acknowledge Delimiter, or CRC Delimiter, a Form Error has
occurred, and an Error Frame is generated. The message is repeated.
Bit Error
A Bit Error occurs if a) a transmitter sends a dominant bit and detects a recessive bit
or b) if the transmitter sends a recessive bit and detects a dominant bit when
monitoring the actual bus level and comparing it to the just transmitted bit. In case b),
no error occurs during the Arbitration Field (ID, RTR, IDE) and the Acknowledge Slot.
Stuff Error
If between Start of Frame and CRC Delimiter, six consecutive bits with the same
polarity are detected, the bit-stuffing rule has been violated. A stuff error occurs and
an Error Frame is generated. The message is repeated.
Detected errors are made public to all other nodes via Error Frames (except
Acknowledge Errors). The transmission of the erroneous message is aborted and the
frame is repeated as soon as possible. Furthermore, each CAN node is in one of the
three error states (error-active, error-passive or bus-off) according to the value of the
internal error counters. The error-active state is the usual state where the bus node can
transmit messages and active-error frames (made of dominant bits) without any
restrictions. In the error-passive state, messages and passive-error frames (made of
recessive bits) may be transmitted. The bus-off state makes it temporarily impossible for
the node to participate in the bus communication. During this state, messages can be
neither received nor transmitted.

XMC4500
XMC4000 Family
Basic CAN, Full CAN

There is one more CAN characteristic that is related to the interface of a CAN module
(controller) and the host CPU: Basic-CAN and Full-CAN functionality.
In Basic-CAN devices, only basic functions of the protocol are implemented in hardware,
such as the generation and the check of the bit stream. The decision, whether a received
message has to be stored or not (acceptance filtering), and the complete message
management must be done by software. Normally, the CAN device also provides only
one transmit buffer and one or two receive buffers. Therefore, the host CPU load is quite
high when using Basic-CAN modules. The main advantage of Basic-CAN is a reduced
chip size leading to low costs of these devices.
Full-CAN devices (this is the case for the MultiCAN controller as implemented in
XMC4500) manage the whole bus protocol in hardware, including the acceptance
filtering and message management. Full-CAN devices contain message objects that
handle autonomously the identifier, the data, the direction (receive or transmit) and the
information of Standard CAN/Extended CAN operation. During the initialization of the
device, the host CPU determines which messages are to be sent and which are to be
received. The host CPU is informed by interrupt if the identifier of a received message
matches with one of the programmed (receive-) message objects. The CPU load of Full-
CAN devices is greatly reduced. When using Full-CAN devices, high baud rates and high
bus loads with many messages can be handled.

XMC4500
XMC4000 Family
18.3 MultiCAN Kernel Functional Description

This section describes the functionality of the MultiCAN module.
18.3.1 Module Structure

Figure 18-6 shows the general structure of the MultiCAN module.
CAN Bus 0 CAN Bus 1 ... CAN Bus x-1
Node Bitstream
Control Processor
Unit
CAN CAN CAN Bit Error
...
Node 0 Node 1 Node x-1 Frame Timing Handling
Counter Unit Unit
Interrupt Control Unit
Message Controller
Interrupt List
Message
Control Control
RAM
Logic Logic
Address Decoder
interrupt control bus interface MultiCAN_Blockdiag_x.vsd
Figure 18-6 MultiCAN Block Diagram
CAN Nodes
Each CAN node consists of several sub-units.
Bitstream Processor
The Bitstream Processor performs data, remote, error and overload frame
processing according to the ISO 11898 standard. This includes conversion between
the serial data stream and the input/output registers.
Bit Timing Unit
The Bit Timing Unit determines the length of a bit time and the location of the sample
point according to the user settings, taking into account propagation delays and
phase shift errors. The Bit Timing Unit also performs resynchronization.

XMC4500
XMC4000 Family
Error Handling Unit

The Error Handling Unit manages the receive and transmit error counter. Depending
on the contents of both counters, the CAN node is set into an error-active, error
passive or bus-off state.
Node Control Unit
The Node Control Unit coordinates the operation of the CAN node:
Enable/disable CAN transfer of the node
Enable/disable and generate node-specific events that lead to an interrupt request
(CAN bus errors, successful frame transfers etc.)
Administration of the Frame Counter
Interrupt Control Unit
The Interrupt Control Unit in the CAN node controls the interrupt generation for the
different conditions that can occur in the CAN node.
Message Controller
The Message Controller handles the exchange of CAN frames between the CAN nodes
and the message objects that are stored in the Message RAM. The Message Controller
performs several functions:
Receive acceptance filtering to determine the correct message object for storing of a
received CAN frame
Transmit acceptance filtering to determine the message object to be transmitted first,
individually for each CAN node
Transfer contents between message objects and the CAN nodes, taking into account
the status/control bits of the message objects
Handling of the FIFO buffering and gateway functionality
Aggregation of message-pending notification bits
List Controller
The List Controller performs all operations that lead to a modification of the double-
chained message object lists. Only the list controller is allowed to modify the list
structure. The allocation/deallocation or reallocation of a message object can be
requested via a user command interface (command panel). The list controller state
machine then performs the requested command autonomously.
Interrupt Control
The general interrupt structure is shown in Figure 18-7. The interrupt event can trigger
the interrupt generation. The interrupt pulse is generated independently of the interrupt
flag in the interrupt status register. The interrupt flag can be reset by software by writing
a 0 to it.
If enabled by the related interrupt enable bit in the interrupt enable register, an interrupt
pulse can be generated at one of the 16 interrupt output lines INT_Om of the MultiCAN

XMC4500
XMC4000 Family
module. If more than one interrupt source is connected to the same interrupt node
pointer (in the interrupt node pointer register), the requests are combined to one
common line.
Reset Interrupt
Writing 0 INP
Flag
Set
Interrupt Event &
Interrupt
Enable To INT_O0
1
To INT_O1
Other Interrupt
.....
Sources on the
same INP To INT_On1)
Note:
1) There can be 8 or 16 interrupt outputs, (i.e INT_O7/15) depending on
device configuration.
MCA 06264
Figure 18-7 General Interrupt Structure
18.3.2 Port Input Control

It is possible to select the input lines for the RXDCx inputs for the CAN nodes. The
selected input is connected to the CAN node and is also available to wake-up the
system. More details are defined in Section 18.8.2.1 on Page 18-121.

XMC4500
XMC4000 Family
18.3.3 CAN Node Control

Each CAN node may be configured and run independently of the other CAN node. Each
CAN node is equipped with its own node control logic to configure the global behavior
and to provide status information.
Note: In the following descriptions, index x stands for the node number and index n
represents the message object number.
Configuration Mode is activated when bit NCRx.CCE is set to 1. This mode allows CAN
bit timing parameters and the error counter registers to be modified.
CAN Analyzer Mode is activated when bit NCRx.CALM is set to 1. In this operation
mode, Data And Remote Frames are monitored without active participation in any CAN
transfer (CAN transmit pin is held on recessive level). Incoming Remote Frames are
stored in a corresponding transmit message object, while arriving data frames are saved
in a matching receive message object.
In CAN Analyzer Mode, the entire configuration information of the received frame is
stored in the corresponding message object, and can be evaluated by the CPU to
determine their identifier, XTD bit information and data length code (ID and DLC
optionally if the Remote Monitoring Mode is active, bit MOFCRn.RMM = 1). Incoming
frames are not acknowledged, and no Error Frames are generated. If CAN Analyzer
Mode is enabled, Remote Frames are not responded to by the corresponding Data
Frame, and Data Frames cannot be transmitted by setting the transmit request bit
MOSTATn.TXRQ. Receive interrupts are generated in CAN Analyzer Mode (if enabled)
for all error free received frames.
The node-specific interrupt configuration is also defined by the Node Control Logic via
the NCRx register bits TRIE, ALIE and LECIE:
If control bit TRIE is set to 1, a transfer interrupt is generated when the NSRx register
has been updated (after each successfully completed message transfer).
If control bit ALIE is set to 1, an error interrupt is generated when a bus-off condition
has been recognized or the Error Warning Level has been exceeded or under-run.
Additionally, list or object errors lead to this type of interrupt.
If control bit LECIE is set to 1, a last error code interrupt is generated when an error
code > 0 is written into bit field NSRx.LEC by hardware.
The Node x Status Register NSRx provides an overview about the current state of the
respective CAN node x, comprising information about CAN transfers, CAN node status,
and error conditions.
The CAN frame counter can be used to check the transfer sequence of message objects
or to obtain information about the instant a frame has been transmitted or received from
the associated CAN bus. CAN frame counting is performed by a 16-bit counter,
controlled by register NFCRx. Bit fields NFCRx.CFMOD and NFCRx.CFSEL determine
the operation mode and the trigger event incrementing the frame counter.

XMC4500
XMC4000 Family
18.3.3.1 Bit Timing Unit

According to the ISO 11898 standard, a CAN bit time is subdivided into different
segments (Figure 18-8). Each segment consists of multiples of a time quantum tq. The
magnitude of tq is adjusted by Node x Bit Timing Register bit fields NBTRx.BRP and
NBTRx.DIV8, both controlling the baud rate prescaler (register NBTRx is described on
Page 18-85). The baud rate prescaler is driven by the module timer clock fCAN
(generation and control of fCAN is described on Page 18-58).
1 Bit Time
TSeg1 TSeg2
TSync TProp Tb1 Tb2
Sync.
Seg
1 Time Quantum (tq)
Sample Point Transmit Point
MCT06266
Figure 18-8 CAN Bus Bit Timing Standard

The Synchronization Segment (TSync) allows a phase synchronization between
transmitter and receiver time base. The Synchronization Segment length is always
one tq. The Propagation Time Segment (TProp) takes into account the physical
propagation delay in the transmitter output driver on the CAN bus line and in the
transceiver circuit. For a working collision detection mechanism, TProp must be two times
the sum of all propagation delay quantities rounded up to a multiple of tq. The phase
buffer segments 1 and 2 (Tb1, Tb2) before and after the signal sample point are used to
compensate for a mismatch between transmitter and receiver clock phases detected in
the synchronization segment.
The maximum number of time quanta allowed for re-synchronization is defined by bit
field NBTRx.SJW. The Propagation Time Segment and the Phase Buffer Segment 1 are
combined to parameter TSeg1, which is defined by the value NBTRx.TSEG1. A minimum
of 3 time quanta is demanded by the ISO standard. Parameter TSeg2, which is defined by
the value of NBTRx.TSEG2, covers the Phase Buffer Segment 2. A minimum of 2 time
quanta is demanded by the ISO standard. According to ISO standard, a CAN bit time,
calculated as the sum of TSync, TSeg1 and TSeg2, must not fall below 8 time quanta.

XMC4500
XMC4000 Family
Calculation of the bit time:
tq = (BRP + 1) / fCAN if DIV8 = 0

= 8 (BRP + 1) / fCAN if DIV8 = 1
TSync = 1 tq
TSeg1 = (TSEG1 + 1) tq (min. 3 tq)
TSeg2 = (TSEG2 + 1) tq (min. 2 tq)
bit time = TSync + TSeg1 + TSeg2 (min. 8 tq)
To compensate phase shifts between clocks of different CAN controllers, the CAN
controller must synchronize on any edge from the recessive to the dominant bus level.
If the hard synchronization is enabled (at the start of frame), the bit time is restarted at
the synchronization segment. Otherwise, the re-synchronization jump width TSJW defines
the maximum number of time quanta, a bit time may be shortened or lengthened by one
re-synchronization. The value of SJW is defined by bit field NBTRx.SJW.
TSJW = (SJW + 1) tq
TSeg1 TSJW + Tprop
TSeg2 TSJW
The maximum relative tolerance for fCAN depends on the Phase Buffer Segments and
the re-synchronization jump width.
dfCAN min (Tb1, Tb2) / 2 (13 bit time - Tb2) AND

dfCAN TSJW / 20 bit time
A valid CAN bit timing must be written to the CAN Node Bit Timing Register NBTR before
resetting the INIT bit in the Node Control Register, i.e. before enabling the operation of
the CAN node.
The Node Bit Timing Register may be written only if bit CCE (Configuration Change
Enable) is set in the corresponding Node Control Register.
18.3.3.2 Bitstream Processor

Based on the message objects in the message buffer, the Bitstream Processor
generates the remote and Data Frames to be transmitted via the CAN bus. It controls the
CRC generator and adds the checksum information to the new remote or Data Frame.
After including the SOF bit and the EOF field, the Bitstream Processor starts the CAN

XMC4500
XMC4000 Family
bus arbitration procedure and continues with the frame transmission when the bus was
found in idle state. While the data transmission is running, the Bitstream Processor
continuously monitors the I/O line. If (outside the CAN bus arbitration phase or the
acknowledge slot) a mismatch is detected between the voltage level on the I/O line and
the logic state of the bit currently sent out by the transmit shift register, a CAN error
interrupt request is generated, and the error code is indicated by the Node x Status
Register bit field NSRx.LEC.
The data consistency of an incoming frame is verified by checking the associated CRC
field. When an error has been detected, a CAN error interrupt request is generated and
the associated error code is presented in the Node x Status Register NSRx.
Furthermore, an Error Frame is generated and transmitted on the CAN bus. After
decomposing a faultless frame into identifier and data portion, the received information
is transferred to the message buffer executing remote and Data Frame handling,
interrupt generation and status processing.
18.3.3.3 Error Handling Unit

The Error Handling Unit of a CAN node x is responsible for the fault confinement of the
CAN device. Its two counters, the Receive Error Counter REC and the Transmit Error
Counter TEC (bit fields of the Node x Error Counter Register NECNTx, see Page 18-87)
are incremented and decremented by commands from the Bitstream Processor. If the
Bitstream Processor itself detects an error while a transmit operation is running, the
Transmit Error Counter is incremented by 8. An increment of 1 is used when the error
condition was reported by an external CAN node via an Error Frame generation. For
error analysis, the transfer direction of the disturbed message and the node that
recognizes the transfer error are indicated for the respective CAN node x in register
NECNTx. Depending on the values of the error counters, the CAN node is set into error-
active, error-passive, or bus-off state.
The CAN node is in error-active state if both error counters are below the error-passive
limit of 128. The CAN node is in error-passive state, if at least one of the error counters
is equal to or greater than 128.
The bus-off state is activated if the Transmit Error Counter is equal to or greater than the
bus-off limit of 256. This state is reported for CAN node x by the Node x Status Register
flag NSRx.BOFF. The device remains in this state, until the bus-off recovery sequence
is finished. Additionally, Node x Status Register flag NSRx.EWRN is set when at least
one of the error counters is equal to or greater than the error warning limit defined by the
Node x Error Count Register bit field NECNTx.EWRNLVL. Bit NSRx.EWRN is reset if
both error counters fall below the error warning limit again (see Page 18-78).

XMC4500
XMC4000 Family
18.3.3.4 CAN Frame Counter

Each CAN node is equipped with a frame counter that counts transmitted/received CAN
frames or obtains information about the time when a frame has been started to transmit
or be received by the CAN node. CAN frame counting/bit time counting is performed by
a 16-bit counter that is controlled by Node x Frame Counter Register NFCRx (see
Page 18-89). Bit field NFCRx.CFSEL determines the operation mode of the frame
counter:
Frame Count Mode:
After the successful transmission and/or reception of a CAN frame, the frame counter
is copied into the CFCVAL bit field of the MOIPRn register of the message object
involved in the transfer. Afterwards, the frame counter is incremented.
Time Stamp Mode:
The frame counter is incremented with the beginning of a new bit time. When the
transmission/reception of a frame starts, the value of the frame counter is captured
and stored to the CFC bit field of the NFCRx register. After the successful transfer of
the frame the captured value is copied to the CFCVAL bit field of the MOIPRn register
of the message object involved in the transfer.
Bit Timing Mode:
Used for baud rate detection and analysis of the bit timing (Chapter 18.3.5.3).
18.3.3.5 CAN Node Interrupts

Each CAN node has four hardware triggered interrupt request types that are able to
generate an interrupt request upon:
The successful transmission or reception of a frame
A CAN protocol error with a last error code
An alert condition: Transmit/receive error counters reach the warning limit, bus-off
state changes, a List Length Error occurs, or a List Object Error occurs
An overflow of the frame counter
Besides the hardware generated interrupts, software initiated interrupts can be
generated using the Module Interrupt Trigger Register MITR. Writing a 1 to bit n of bit
field MITR.IT generates an interrupt request signal on the corresponding interrupt output
line INT_On. When writing MITR.IT more than one bit can be set resulting in activation
of multiple INT_On interrupt output lines at the same time. See also Service Request
Generation on Page 18-53 for further processing of the CAN node interrupts.

XMC4500
XMC4000 Family
NSRx NCRx
Correct Message
Object Transfer TXOK TRIE
NIPRx
Transmit 1
TRINP
Receive
RXOK
NSRx
NSRx NCRx
LEC LECIE
3 NIPRx
CAN Error LECINP
NCRx
NSRx
EWRN 1 ALIE
NIPRx
BOFF
ALINP
List Length Error
NSRx
List Object Error
ALERT
LLE LOE
NSRx NSRx
NFCRx NFCRx
CFCOV CFCIE
NIPRx
Frame Counter
Overflow/Event CFCINP
MCA06267
Figure 18-9 CAN Node Interrupts

XMC4500
XMC4000 Family
18.3.4 Message Object List Structure

This section describes the structure of the message object lists in the MultiCAN module.
18.3.4.1 Basics
The message objects of the MultiCAN module are organized in double-chained lists,
where each message object has a pointer to the previous message object in the list as
well as a pointer to the next message object in the list. The MultiCAN module provides
8 lists. Each message object is allocated to one of these lists. In the example in
Figure 18-10, the three message objects (3, 5, and 16) are allocated to the list with
index 2 (List Register LIST2).
PPREV = 5 PPREV = 5 PPREV = 16
PNEXT = 16 PNEXT = 3 PNEXT = 3
LIST = 2 LIST = 2 LIST = 2
Message Message Message

Object 5 Object 16 Object 3
EMPTY = 0 SIZE = 2 BEGIN = 5 END = 3

Register LIST2
MCA06268
Figure 18-10 Example Allocation of Message Objects to a List

Bit field BEGIN in the List Register (for definition, see Page 18-69) points to the first
element in the list (object 5 in the example), and bit field END points to the last element
in the list (object 3 in the example). The number of elements in the list is indicated by bit
field SIZE of the List Register (SIZE = number of list elements - 1, thus SIZE = 2 for the
3 elements in the example). The EMPTY bit of the List Register indicates whether or not
a list is empty (EMPTY = 0 in the example, because list 2 is not empty).
Each message object n has a pointer PNEXT in its Message Object n Control Register
MOCTRn (see Page 18-93) that points to the next message object in the list, and a
pointer PPREV that points to the previous message object in the list. PPREV of the first
message object points to the message object itself because the first message object has
no predecessor (in the example message object 5 is the first message object in the list,

XMC4500
XMC4000 Family
indicated by PPREV = 5). PNEXT of the last message object also points to the message
object itself because the last message object has no successor (in the example, object 3
is the last message object in the list, indicated by PNEXT = 3).
Bit field MOCTRn.LIST indicates the list index number to which the message object is
currently allocated. The message object of the example are allocated to list 2. Therefore,
all LIST bit fields for the message objects assigned to list 2 are set to LIST = 2.
18.3.4.2 List of Unallocated Elements

The list with list index 0 has a special meaning: it is the list of all unallocated elements.
An element is called unallocated if it belongs to list 0 (MOCTRn.LIST = 0). It is called
allocated if it belongs to a list with an index not equal to 0 (MOCTRn.LIST > 0).
After reset, all message objects are unallocated. This means that they are assigned to
the list of unallocated elements with MOCTRn.LIST = 0. After this initial allocation of the
message objects caused by reset, the list of all unallocated message objects is ordered
by message number (predecessor of message object n is object n-1, successor of object
n is object n+1).
18.3.4.3 Connection to the CAN Nodes

Each CAN node is linked to one unique list of message objects. A CAN node performs
message transfer only with the message objects that are allocated to the list of the CAN
node. This is illustrated in Figure 18-11. Frames that are received on a CAN node may
only be stored in one of the message objects that belongs to the CAN node; frames to
be transmitted on a CAN node are selected only from the message objects that are
allocated to that node, as indicated by the vertical arrows.
There are more lists (8) than CAN nodes (3). This means that some lists are not linked
to one of the CAN nodes. A message object that is allocated to one of these unlinked
lists cannot receive messages directly from a CAN node and it may not transmit
messages.
FIFO and gateway mechanisms refer to message numbers and not directly to a specific
list. The user must take care that the message objects targeted by FIFO/gateway belong
to the desired list. The mechanisms make it possible to work with lists that do not belong
to the CAN node.

XMC4500
XMC4000 Family
CAN Bus 0 CAN Bus 1 . . . CAN Bus x-1
List of all CAN CAN CAN

unallocated
Node 0 Node 1 Node x-1
elements
1st Object 1st Object 1st Object 1st Object

in List 0 in List 1 in List 2 in List x
. . .
2nd Object 2nd Object 2nd Object 2nd Object

Last Object Last Object Last Object Last Object

MultiCAN_list_to_can_x.vsd
Figure 18-11 Message Objects Linked to CAN Nodes
18.3.4.4 List Command Panel

The list structure cannot be modified directly by write accesses to the LIST registers and
the PPREV, PNEXT and LIST bit fields in the Message Object Control Registers, as they
are read only. The list structure is managed by and limited to the list controller inside the
MultiCAN module. The list controller is controlled via a command panel allowing the user
to issue list allocation commands to the list controller. The list controller has two main
purposes:
1. Ensure that all operations that modify the list structure result in a consistent list
structure.
2. Present maximum ease of use and flexibility to the user.
The list controller and the associated command panel allows the programmer to
concentrate on the final properties of the list, which are characterized by the allocation
of message objects to a CAN node, and the ordering relation between objects that are
allocated to the same list. The process of list (re-)building is done in the list controller.

XMC4500
XMC4000 Family
Table 18-1 gives an overview on the available panel commands while Table 18-6 on
Page 18-64 describes the panel commands in more detail.
Table 18-1 Panel Commands Overview

Command Name Description
No Operation No new command is started.
Initialize Lists Run the initialization sequence to reset the CTRL and LIST
field of all message objects.
Static Allocate Allocate message object to a list.
Dynamic Allocate Allocate the first message object of the list of unallocated
objects to the selected list.
Static Insert Before Remove a message object (source object) from the list that it
currently belongs to, and insert it before a given destination
object into the list structure of the destination object.
Dynamic Insert Before Insert a new message object before a given destination
object.
Static Insert Behind Remove a message object (source object) from the list that it
currently belongs to, and insert it behind a given destination
object into the list structure of the destination object.
Dynamic Insert Behind Insert a new message object behind a given destination
object.
A panel command is started by writing the respective command code into the Panel
Control Register bit field PANCTR.PANCMD (see Page 18-63). The corresponding
command arguments must be written into bit fields PANCTR.PANAR1 and
PANCTR.PANAR2 before writing the command code, or latest along with the command
code in a single 32-bit write access to the Panel Control Register.
With the write operation of a valid command code, the PANCTR.BUSY flag is set and
further write accesses to the Panel Control Register are ignored. The BUSY flag remains
active and the control panel remains locked until the execution of the requested
command has been completed. After a reset, the list controller builds up list 0. During
this operation, BUSY is set and other accesses to the CAN RAM are forbidden. The CAN
RAM can be accessed again when BUSY becomes inactive.
Note: The CAN RAM is automatically initialized after reset by the list controller in order
to ensure correct list pointers in each message object. The end of this CAN RAM
initialization is indicated by bit PANCTR.BUSY becoming inactive.
In case of a dynamic allocation command that takes an element from the list of
unallocated objects, the PANCTR.RBUSY bit is also set along with the BUSY bit

XMC4500
XMC4000 Family
(RBUSY = BUSY = 1). This indicates that bit fields PANAR1 and PANAR2 are going to
be updated by the list controller in the following way:
1. The message number of the message object taken from the list of unallocated
elements is written to PANAR1.
2. If ERR (bit 7 of PANAR2) is set to 1, the list of unallocated elements was empty and
the command is aborted. If ERR is 0, the list was not empty and the command will be
performed successfully.
The results of a dynamic allocation command are written before the list controller starts
the actual allocation process. As soon as the results are available, RBUSY becomes
inactive (RBUSY = 0) again, while BUSY still remains active until completion of the
command. This allows the user to set up the new message object while it is still in the
process of list allocation. The access to message objects is not limited during ongoing
list operations. However, any access to a register resource located inside the RAM
delays the ongoing allocation process by one access cycle.
As soon as the command is finished, the BUSY flag becomes inactive (BUSY = 0) and
write accesses to the Panel Control Register are enabled again. Also, the No Operation
command code is automatically written to the PANCTR.PANCMD field. A new command
may be started any time when BUSY = 0.
All fields of the Panel Control Register PANCTR except BUSY and RBUSY may be
written by the user. This makes it possible to save and restore the Panel Control Register
if the Command Panel is used within independent (mutually interruptible) interrupt
service routines. If this is the case, any task that uses the Command Panel and that may
interrupt another task that also uses the Command Panel should poll the BUSY flag until
it becomes inactive and save the whole PANCTR register to a memory location before
issuing a command. At the end of the interrupt service routine, the task should restore
PANCTR from the memory location.
Before a message object that is allocated to the list of an active CAN node shall be
moved to another list or to another position within the same list, bit MOCTRn.MSGVAL
(Message Valid) of message object n must be cleared.

XMC4500
XMC4000 Family
18.3.5 CAN Node Analysis Features

The chapter describes the CAN node analysis capabilities of the MultiCAN module.
18.3.5.1 Analyzer Mode

The CAN Analyzer Mode makes it possible to monitor the CAN traffic for each CAN node
individually without affecting the logical state of the CAN bus. The CAN Analyzer Mode
for CAN node x is selected by setting Node x Control Register bit NCRx.CALM.
In CAN Analyzer Mode, the transmit pin of a CAN node is held at a recessive level
permanently. The CAN node may receive frames (Data, Remote, and Error Frames) but
is not allowed to transmit. Received Data/Remote Frames are not acknowledged (i.e.
acknowledge slot is sent recessive) but will be received and stored in matching message
objects as long as there is any other node that acknowledges the frame. The complete
message object functionality is available, but no transmit request will be executed.
18.3.5.2 Loop-Back Mode

The MultiCAN module provides a Loop-Back Mode to enable an in-system test of the
MultiCAN module as well as the development of CAN driver software without access to
an external CAN bus.
The loop-back feature consists of an internal CAN bus (inside the MultiCAN module) and
a bus select switch for each CAN node (see Figure 18-12). With the switch, each CAN
node can be connected either to the internal CAN bus (Loop-Back Mode activated) or
the external CAN bus, respectively to transmit and receive pins (normal operation). The
CAN bus that is not currently selected is driven recessive; this means the transmit pin is
held at 1, and the receive pin is ignored by the CAN nodes that are in Loop-Back Mode.
The Loop-Back Mode is selected for CAN node x by setting the Node x Port Control
Register bit NPCRx.LBM. All CAN nodes that are in Loop-Back Mode may communicate
together via the internal CAN bus without affecting the normal operation of the other CAN
nodes that are not in Loop-Back Mode.

XMC4500
XMC4000 Family
NPCR0.LBM internal CAN bus
0
CAN Bus 0
CAN node 0
1
NPCR1.LBM
0
CAN Bus 1
CAN node 1
1
. .
. .
. .
NPCRx.LBM
0
CAN Bus x-1
CAN node x
1
MultiCAN_loop_back_x.vsd
Figure 18-12 Loop-Back Mode
18.3.5.3 Bit Timing Analysis

Detailed analysis of the bit timing can be performed for each CAN node using the
analysis modes of the CAN frame counter. The bit timing analysis functionality of the
frame counter may be used for automatic detection of the CAN baud rate, as well as to
analyze the timing of the CAN network.
Bit timing analysis for CAN node x is selected when bit field NFCRx.CFMOD = 10B. Bit
timing analysis does not affect the operation of the CAN node.
The bit timing measurement results are written into the NFCRx.CFC bit field. Whenever
NFCRx.CFC is updated in bit timing analysis mode, bit NFCRx.CFCOV is also set to
indicate the CFC update event. If NFCRx.CFCIE is set, an interrupt request can be
generated (see Figure 18-9).

XMC4500
XMC4000 Family
Automatic Baud Rate Detection

For automatic baud rate detection, the time between the observation of subsequent
dominant edges on the CAN bus must be measured. This measurement is automatically
performed if bit field NFCRx.CFSEL = 000B. With each dominant edge monitored on the
CAN receive input line, the time (measured in fCAN clock cycles) between this edge and
the most recent dominant edge is stored in the NFCRx.CFC bit field.

XMC4500
XMC4000 Family
Synchronization Analysis
The bit time synchronization is monitored if NFCRx.CFSEL = 010B. The time between
the first dominant edge and the sample point is measured and stored in the NFCRx.CFC
bit field. The bit timing synchronization offset may be derived from this time as the first
edge after the sample point triggers synchronization and there is only one
synchronization between consecutive sample points.
Synchronization analysis can be used, for example, for fine tuning of the baud rate
during reception of the first CAN frame with the measured baud rate.
Driver Delay Measurement

The delay between a transmitted edge and the corresponding received edge is
measured when NFCRx.CFSEL = 011B (dominant to dominant) and
NFCRx.CFSEL = 100B (recessive to recessive). These delays indicate the time needed
to represent a new bit value on the physical implementation of the CAN bus.

XMC4500
XMC4000 Family
18.3.6 Message Acceptance Filtering

The chapter describes the Message Acceptance Filtering capabilities of the MultiCAN
module.
18.3.6.1 Receive Acceptance Filtering

When a CAN frame is received by a CAN node, a unique message object is determined
in which the received frame is stored after successful frame reception. A message object
is qualified for reception of a frame if the following six conditions are met.
The message object is allocated to the message object list of the CAN node by which
the frame is received.
Bit MOSTATn.MSGVAL in the Message Status Register (see Page 18-96) is set.
Bit MOSTATn.RXEN is set.
Bit MOSTATn.DIR is equal to bit RTR of the received frame.
If bit MOSTATn.DIR = 1 (transmit object), the message object accepts only Remote
Frames. If bit MOSTATn.DIR = 0 (receive object), the message object accepts only
Data Frames.
If bit MOAMRn.MIDE = 1, the IDE bit of the received frame becomes evaluated in the
following way: If MOARn.IDE = 1, the IDE bit of the received frame must be set
(indicates extended identifier). If MOARn.IDE = 0, the IDE bit of the received frame
must be cleared (indicates standard identifier).
If bit MOAMRn.MIDE = 0, the IDE bit of the received frame is dont care. In this
case, message objects with standard and extended frames are accepted.
The identifier of the received frame matches the identifier stored in the Arbitration
Register of the message object as qualified by the acceptance mask in the MOAMRn
register. This means that each bit of the received message object identifier is equal
to the bit field MOARn.ID, except those bits for which the corresponding acceptance
mask bits in bit field MOAMRn.AM are cleared. These identifier bits are dont care
for reception. Figure 18-13 illustrates this receive message identifier check.
Among all messages that fulfill all six qualifying criteria the message object with the
highest receive priority wins receive acceptance filtering and becomes selected to store
the received frame. All other message objects lose receive acceptance filtering.
The following priority scheme is defined for the message objects:
A message object a (MOa) has higher receive priority than a message object b (MOb) if
the following two conditions are fulfilled (see Page 18-110):
1. MOa has a higher priority class than MOb. This means, the 2-bit priority bit field
MOARa.PRI must be equal or less than bit field MOARb.PRI.
2. If both message objects have the same priority class (MOARa.PRI = MOARb.PRI),
MOb is a list successor of MOa. This means that MOb can be reached by means of
successively stepping forward in the list, starting from a.

XMC4500
XMC4000 Family
Identifier of
Received Frame 0 = Bit match
Bitwise 1 = No match
XOR
Identifier of
Message Object
Acceptance Mask of Bitwise IDmatch

Message Object AND
IDmatch = 0: ID of the received frame fits to message object

IDmatch > 0: ID of the received frame does not fit to message object
MCA06271
Figure 18-13 Received Message Identifier Acceptance Check
18.3.6.2 Transmit Acceptance Filtering

A message is requested for transmission by setting a transmit request in the message
object that holds the message. If more than one message object have a valid transmit
request for the same CAN node, one of these message objects is chosen for
transmission, because only a single message object can be transmitted at one time on
a CAN bus.
A message object is qualified for transmission on a CAN node if the following four
conditions are met (see also Figure 18-14).
1. The message object is allocated to the message object list of the CAN node.
2. Bit MOSTATn.MSGVAL is set.
3. Bit MOSTATn.TXRQ is set.
4. Bit MOSTATn.TXEN0 and MOSTATn.TXEN1 are set.
A priority scheme determines which one of all qualifying message objects is transmitted
first. It is assumed that message object a (MOa) and message object b (MOb) are two
message objects qualified for transmission. MOb is a list successor of MOa. For both
message objects, CAN messages CANa and CANb are defined (identifier, IDE, and RTR
are taken from the message-specific bit fields and bits MOARn.ID, MOARn.IDE and
MOCTRn.DIR).
If both message objects belong to the same priority class (identical PRI bit field in register
MOARn), MOa has a higher transmit priority than MOb if one of the following conditions
is fulfilled.
PRI = 10B and CAN message MOa has higher or equal priority than CAN message
MOb with respect to CAN arbitration rules (see Table 18-12 on Page 18-111).
PRI = 01B or PRI = 11B (priority by list order).

XMC4500
XMC4000 Family
The message object that is qualified for transmission and has highest transmit priority
wins the transmit acceptance filtering, and will be transmitted first. All other message
objects lose the current transmit acceptance filtering round. They get a new chance in
subsequent acceptance filtering rounds.
&
MSGVAL
TXRQ
0 = Object will not be transmitted
1 = Object is requested for transmission
TXEN0
TXEN1
MCA06272
Figure 18-14 Effective Transmit Request of Message Object

XMC4500
XMC4000 Family
18.3.7 Message Postprocessing

After a message object has successfully received or transmitted a frame, the CPU can
be notified to perform a postprocessing on the message object. The postprocessing of
the MultiCAN module consists of two elements:
1. Message interrupts to trigger postprocessing.
2. Message pending registers to collect pending message interrupts into a common
structure for postprocessing.
18.3.7.1 Message Object Interrupts

When the storage of a received frame into a message object or the successful
transmission of a frame is completed, a message interrupt can be issued. For each
message object, a transmit and a receive interrupt can be generated and routed to one
of the sixteen CAN interrupt output lines (see Figure 18-15). A receive interrupt occurs
also after a frame storage event that has been induced by a FIFO or a gateway action.
The status bits TXPND and RXPND in the Message Object n Status Register are always
set after a successful transmission/reception, whether or not the respective message
interrupt is enabled.
A third FIFO full interrupt condition of a message object is provided. If bit field
MOFCRn.OVIE (Overflow Interrupt Enable) is set, the FIFO full interrupt will be activated
depending on the actual message object type.
In case of a Receive FIFO Base Object (MOFCRn.MMC = 0001B), the FIFO full interrupt
is routed to the interrupt output line INT_Om as defined by the transmit interrupt node
pointer MOIPRn.TXINP.
In case of a Transmit FIFO Base Object (MOFCRn.MMC = 0010B), the FIFO full interrupt
becomes routed to the interrupt output line INT_Om as defined by the receive interrupt
node pointer MOIPRn.RXINP.
See also Service Request Generation on Page 18-53 for further processing of the
message object interrupts.

XMC4500
XMC4000 Family
MOSTATn MOFCRn
TXPND RXPND OVIE TXIE RXIE MMC
= 0010B
= 0001B MOIPRn
Message n
1
transmitted TXINP
&
Message n
FIFO full &
MOIPRn
1
Message n RXINP
received
MMC = 0001B: Message object n is a Receive FIFO Base Object

MMC = 0010B: Message object n is a Transmit FIFO Base Object
MCA06273
Figure 18-15 Message Interrupt Request Routing

XMC4500
XMC4000 Family
18.3.7.2 Pending Messages

When a message interrupt request is generated, a message pending bit is set in one of
the Message Pending Registers. There are 8 Message Pending Registers, MSPNDk
(k = 0-7) with 32 pending bits available each. The general Figure 18-16 shows the
allocation of the message pending bits in case that the maximum possible number of
eight Message Pending Registers are implemented and available on the chip.
Message Object n Interrupt Pointer Register MOIPRn[15:0]
MPN TXINP RXINP

7 6 5 4 3 2 1 0 3 2 1 0 3 2 1 0
15 0
0 1 0 1 0 1 0 1 0 = Transmit Event
1 = Receive Event
Message Pending Registers

1 7 255 MSPND7 224
223 MSPND6 192
0 7 D
191 MSPND5 160
2 E
6 159 MSPND4 128
1 M 127 96
5 MSPND3
1 0 U 95 64
MSPND2
X 63 MSPND1 32
0
0 31 MSPND0 0
. . . . . . . . . . . . . . .
1
31
1 D
MSB
. . . . . . . .
4 E
0 M
U
4 X
3:0
0
3 2 1 0
31 0
MPSEL
Modul Control Register MCR[31:0] MCA06274
Figure 18-16 Message Pending Bit Allocation

XMC4500
XMC4000 Family
The location of a pending bit is defined by two demultiplexers selecting the number k of
the MSPNDk registers (3-bit demux), and the bit location within the corresponding
MSPNDk register (5-bit demux).
Allocation Case 1
In this allocation case, bit field MCR.MPSEL = 0000B (see Page 18-67). The location
selection consists of 2 parts:
The upper three bits of MOIPRn.MPN (MPN[7:5]) select the number k of a Message
Pending Register MSPNDk in which the pending bit will be set.
The lower five bits of MOIPRn.MPN (MPN[4:0]) select the bit position (0-31) in
MSPNDk for the pending bit to be set.
Allocation Case 2
In this allocation case, bit field MCR.MPSEL is taken into account for pending bit
allocation. Bit field MCR.MPSEL makes it possible to include the interrupt request node
pointer for reception (MOIPRn.RXINP) or transmission (MOIPRn.TXINP) for pending bit
allocation in such a way that different target locations for the pending bits are used in
receive and transmit case. If MPSEL = 1111B, the location selection operates in the
following way:
At a transmit event, the upper 3 bits of TXINP determine the number k of a Message
Pending Register MSPNDk in which the pending bit will be set. At a receive event,
the upper 3 bits of RXINP determine the number k.
The bit position (0-31) in MSPNDk for the pending bit to be set is selected by the
lowest bit of TXINP or RXINP (selects between low and high half-word of MSPNDk)
and the four least significant bits of MPN.
General Hints
The Message Pending Registers MSPNDk can be written by software. Bits that are
written with 1 are left unchanged, and bits which are written with 0 are cleared. This
makes it possible to clear individual MSPNDk bits with a single register write access.
Therefore, access conflicts are avoided when the MultiCAN module (hardware) sets
another pending bit at the same time when software writes to the register.
Each Message Pending Register MSPNDk is associated with a Message Index Register
MSIDk (see Page 18-72) which indicates the lowest bit position of all set (1) bits in
Message Pending Register k. The MSIDk register is a read-only register that is updated
immediately when a value in the corresponding Message Pending Register k is changed
by software or hardware.

XMC4500
XMC4000 Family
18.3.8 Message Object Data Handling

This chapter describes the handling capabilities for the Message Object Data of the
MultiCAN module.
18.3.8.1 Frame Reception

After the reception of a message, it is stored in a message object according to the
scheme shown in Figure 18-17. The MultiCAN module not only copies the received data
into the message object, and it provides advanced features to enable consistent data
exchange between MultiCAN and CPU.
MSGVAL
Bit MSGVAL (Message Valid) in the Message Object n Status Register MOSTATn is the
main switch of the message object. During the frame reception, information is stored in
the message object only when MSGVAL = 1. If bit MSGVAL is reset by the CPU, the
MultiCAN module stops all ongoing write accesses to the message object. Now the
message object can be re-configured by the CPU with subsequent write accesses to it
without being disturbed by the MultiCAN.
RTSEL
When the CPU re-configures a message object during CAN operation (for example,
clears MSGVAL, modifies the message object and sets MSGVAL again), the following
scenario can occur:
1. The message object wins receive acceptance filtering.
2. The CPU clears MSGVAL to re-configure the message object.
3. The CPU sets MSGVAL again after re-configuration.
4. The end of the received frame is reached. As MSGVAL is set, the received data is
stored in the message object, a message interrupt request is generated, gateway and
FIFO actions are processed, etc.
After the re-configuration of the message object (after step 3 above) the storage of
further received data may be undesirable. This can be achieved through bit
MOCTRn.RTSEL (Receive/Transmit Selected) that makes it possible to disconnect a
message object from an ongoing frame reception.
When a message object wins the receive acceptance filtering, its RTSEL bit is set by the
MultiCAN module to indicate an upcoming frame delivery. The MultiCAN module checks
RTSEL whether it is set on successful frame reception to verify that the object is still
ready for receiving the frame. The received frame is then stored in the message object
(along with all subsequent actions such as message interrupts, FIFO & gateway actions,
flag updates) only if RTSEL = 1.
When a message object is invalidated during CAN operation (resetting bit MSGVAL),
RTSEL should be cleared before setting MSGVAL again (latest with the same write

XMC4500
XMC4000 Family
access that sets MSGVAL) to prevent the storage of a frame that belongs to the old
context of the message object. Therefore, a message object re-configuration should
consist of the following steps:
1. Clear MSGVAL bit
2. Re-configure the message object while MSGVAL = 0
3. Clear RTSEL bit and set MSGVAL again
RXEN
Bit MOSTATn.RXEN enables a message object for frame reception. A message object
can receive CAN messages from the CAN bus only if RXEN = 1. The MultiCAN module
evaluates RXEN only during receive acceptance filtering. After receive acceptance
filtering, RXEN is ignored and has no further influence on the actual storage of a received
message in a message object.
Bit RXEN enables the soft phase out of a message object: after clearing RXEN, a
currently received CAN message for which the message object has won acceptance
filtering is still stored in the message object but for subsequent messages the message
object no longer wins receive acceptance filtering.
RXUPD, NEWDAT and MSGLST

An ongoing frame storage process is indicated by the RXUPD (Receive Updating) flag
in the MOSTATn register. RXUPD is set with the start and cleared with the end of a
message object update, which consists of frame storage as well as flag updates.
After storing the received frame (identifier, IDE bit, DLC; including the Data Field for Data
Frames), the NEWDAT (New Data) bit of the message object is set. If NEWDAT was
already set before it becomes set again, bit MSGLST (Message Lost) is set to indicate
a data loss condition.
The RXUPD and NEWDAT flags can help to read consistent frame data from the
message object during an ongoing CAN operation. The following steps are
recommended to be executed:
1. Clear NEWDAT bit.
2. Read message content (identifier, data etc.) from the message object.
3. Check that both, NEWDAT and RXUPD, are cleared. If this is not the case, go back
to step 1.
4. When step 3 was successful, the message object contents are consistent and has
not been updated by the MultiCAN module while reading.
Bits RXUPD, NEWDAT and MSGLST have the same behavior for the reception of Data
as well as Remote Frames.

XMC4500
XMC4000 Family
Start receiving Get data from

CAN frame gateway/FIFO source
no Object wins
acc. Filtering ?
Time
yes Milestones
RTSEL := 1
1
no CAN rec.
successful ?
yes
no MSGVAL & no
MSGVAL = 1?
RTSEL = 1?
yes yes
RXUPD := 1 RXUPD := 1
2
Copy frame to Copy frame to

message object message object
3
yes TXRQ := 1 in this

DIR = 1?
or in foreign objects
no
yes
NEWDAT = 1? MSGLST := 1
no
NEWDAT := 1
RXUPD := 0
RXPND := 1
4
yes
RXIE = 1? Interrupt Generated
no
Done
MCA06275
Figure 18-17 Reception of a Message Object

XMC4500
XMC4000 Family
18.3.8.2 Frame Transmission

The process of a message object transmission is shown in Figure 18-18. Along with the
copy of the message object content to be transmitted (identifier, IDE bit, RTR = DIR bit,
DLC, including the Data Field for Data Frames) into the internal transmit buffer of the
assigned CAN node, several status flags are also served and monitored to control
consistent data handling.
The transmission process of a message object starting after the transmit acceptance
filtering is identical for Remote and Data Frames.
MSGVAL, TXRQ, TXEN0, TXEN1

A message can only be transmitted if all four bits in registers MOSTATn, MSGVAL
(Message Valid), TXRQ (Transmit Request), TXEN0 (Transmit Enable 0), TXEN1
(Transmit Enable 1) are set as shown in Figure 18-14. Although these bits are
equivalent with respect to the transmission process, they have different semantics:
Table 18-2 Message Transmission Bit Definitions

Bit Description
MSGVAL Message Valid
This is the main switch bit of the message object.
TXRQ Transmit Request
This is the standard transmit request bit. This bit must be set whenever a
message object should be transmitted. TXRQ is cleared by hardware at the
end of a successful transmission, except when there is new data (indicated
by NEWDAT = 1) to be transmitted.
When bit MOFCRn.STT (Single Transmit Trial) is set, TXRQ becomes
already cleared when the contents of the message object are copied into
the transmit frame buffer of the CAN node.
A received remote request (after a Remote Frame reception) sets bit TXRQ
to request the transmission of the requested data frame.
TXEN0 Transmit Enable 0
This bit can be temporarily cleared by software to suppress the
transmission of this message object when it writes new content to the Data
Field. This avoids transmission of inconsistent frames that consist of a
mixture of old and new data.
Remote requests are still accepted when TXEN0 = 0, but transmission of
the Data Frame is suspended until transmission is re-enabled by software
(setting TXEN0).

XMC4500
XMC4000 Family
Table 18-2 Message Transmission Bit Definitions (contd)

Bit Description
TXEN1 Transmit Enable 1
This bit is used in transmit FIFOs to select the message object that is
transmit active within the FIFO structure.
For message objects that are not transmit FIFO elements, TXEN1 can
either be set permanently to 1 or can be used as a second independent
transmission enable bit.
RTSEL
When a message object has been identified to be transmitted next after transmission
acceptance filtering, bit MOCTRn.RTSEL (Receive/Transmit Selected) is set.
When the message object is copied into the internal transmit buffer, bit RTSEL is
checked, and the message is transmitted only if RTSEL = 1. After the successful
transmission of the message, bit RTSEL is checked again and the message
postprocessing is only executed if RTSEL = 1.
For a complete re-configuration of a valid message object, the following steps should be
executed:
1. Clear MSGVAL bit
2. Re-configure the message object while MSGVAL = 0
3. Clear RTSEL and set MSGVAL
Clearing of RTSEL ensures that the message object is disconnected from an
ongoing/scheduled transmission and no message object processing (copying message
to transmit buffer including clearing NEWDAT, clearing TXRQ, time stamp update,
message interrupt, etc.) within the old context of the object can occur after the message
object becomes valid again, but within a new context.
NEWDAT
When the contents of a message object have been transferred to the internal transmit
buffer of the CAN node, bit MOSTATn.NEWDAT (New Data) is cleared by hardware to
indicate that the transmit message object data is no longer new.
When the transmission of the frame is successful and NEWDAT is still cleared (if no new
data has been copied into the message object meanwhile), TXRQ (Transmit Request) is
cleared automatically by hardware.
If, however, the NEWDAT bit has been set again by the software (because a new frame
should be transmitted), TXRQ is not cleared to enable the transmission of the new data.

XMC4500
XMC4000 Family
Object wins transmit

acc. filtering Time
Milestones
RTSEL := 1 1
Copy Message to
internal transmit buffer
MSGVAL & TXRQ &

no
TXEN0 & TXEN1 = 1
continuously valid
yes
no
RTSEL = 1?
yes
Request transmission
of internal buffer on
CAN bus
NEWDAT := 0 2
Transmission no
successful ?
yes
MSGVAL & no
RTSEL = 1?
yes
no
NEWDAT = 1? TXRQ := 0
yes
no
TXIE = 1?
yes 3
Issue interrupt
Done
MCA06276
Figure 18-18 Transmission of a Message Object

XMC4500
XMC4000 Family
18.3.9 Message Object Functionality

This chapter describes the functionality of the Message Objects in the MultiCAN module.
18.3.9.1 Standard Message Object

A message object is selected as standard message object when bit field
MOFCRn.MMC = 0000B (see Page 18-103). The standard message object can transmit
and receive CAN frames according to the basic rules described in the previous sections.
Additional services such as Single Data Transfer Mode or Single Transmit Trial (see
following sections) are available and can be individually selected.
18.3.9.2 Single Data Transfer Mode

Single Data Transfer Mode is a useful feature in order to broadcast data over the CAN
bus without unintended duplication of information. Single Data Transfer Mode is selected
via bit MOFCRn.SDT.
Message Reception
When a received message stored in a message object is overwritten by a new received
message, the contents of the first message are lost and replaced with the contents of the
new received message (indicated by MSGLST = 1).
If SDT is set (Single Data Transfer Mode activated), bit MSGVAL of the message object
is automatically cleared by hardware after the storage of a received Data Frame. This
prevents the reception of further messages.
After the reception of a Remote Frame, bit MSGVAL is not automatically cleared.
Message Transmission
When a message object receives a series of multiple remote requests, it transmits
several Data Frames in response to the remote requests. If the data within the message
object has not been updated in the time between the transmissions, the same data can
be sent more than once on the CAN bus.
In Single Data Transfer Mode (SDT = 1), this is avoided because MSGVAL is
automatically cleared after the successful transmission of a Data Frame.
After the transmission of a Remote Frame, bit MSGVAL is not automatically cleared.
18.3.9.3 Single Transmit Trial

If the bit STT in the message object function register is set (STT = 1), the transmission
request is cleared (TXRQ = 0) when the frame contents of the message object have
been copied to the internal transmit buffer of the CAN node. Thus, the transmission of
the message object is not tried again when it fails due to CAN bus errors.

XMC4500
XMC4000 Family
18.3.9.4 Message Object FIFO Structure

In case of high CPU load it may be difficult to process a series of CAN frames in time.
This may happen if multiple messages are received or must be transmitted in short time.
Therefore, a FIFO buffer structure is available to avoid loss of incoming messages and
to minimize the setup time for outgoing messages. The FIFO structure can also be used
to automate the reception or transmission of a series of CAN messages and to generate
a single message interrupt when the whole CAN frame series is done.
There can be several FIFOs in parallel. The number of FIFOs and their size are limited
only by the number of available message objects. A FIFO can be installed, resized and
de-installed at any time, even during CAN operation.
The basic structure of a FIFO is shown in Figure 18-19. A FIFO consists of one base
object and n slave objects. The slave objects are chained together in a list structure
(similar as in message object lists). The base object may be allocated to any list.
Although Figure 18-19 shows the base object as a separate part beside the slave
objects, it is also possible to integrate the base object at any place into the chain of slave
objects. This means that the base object is slave object, too (not possible for gateways).
The absolute object numbers of the message objects have no impact on the operation
of the FIFO.
The base object does not need to be allocated to the same list as the slave objects. Only
the slave object must be allocated to a common list (as they are chained together).
Several pointers (BOT, CUR and TOP) that are located in the Message Object n
FIFO/Gateway Pointer Register MOFGPRn link the base object to the slave objects,
regardless whether the base object is allocated to the same or to another list than the
slave objects.
The smallest FIFO would be a single message object which is both, FIFO base and FIFO
slave (not very useful). The biggest possible FIFO structure would include all message
objects of the MultiCAN module. Any FIFO sizes between these limits are possible.
In the FIFO base object, the FIFO boundaries are defined. Bit field MOFGPRn.BOT of
the base object points to (includes the number of) the bottom slave object in the FIFO
structure. The MOFGPRn.TOP bit field points to (includes the number of) the top slave
object in the FIFO structure. The MOFGPRn.CUR bit field points to (includes the number
of) the slave object that is actually selected by the MultiCAN module for message
transfer. When a message transfer takes place with this object, CUR is set to the next
message object in the list structure of the slave objects (CUR = PNEXT of current
object). If CUR was equal to TOP (top of the FIFO reached), the next update of CUR will
result in CUR = BOT (wrap-around from the top to the bottom of the FIFO). This scheme
represents a circular FIFO structure where the bit fields BOT and TOP establish the link
from the last to the first element.
Bit field MOFGPRn.SEL of the base object can be used for monitoring purposes. It
makes it possible to define a slave object within the list at which a message interrupt is

XMC4500
XMC4000 Family
generated whenever the CUR pointer reaches the value of the SEL pointer. Thus SEL
makes it possible to detect the end of a predefined message transfer series or to issue
a warning interrupt when the FIFO becomes full.
PPREV = f[n-1]
PNEXT
Slave Object fn
..
..
PPREV
PPREV = f[i-1]
PNEXT
PNEXT = f[i+1]
TOP = fn Slave Object fi
CUR = fi
..
BOT = f1 ..
Base Object PPREV = f1
PNEXT = f3
Slave Object f2
PPREV
PNEXT = f2
Slave Object f1
MCA06277
Figure 18-19 FIFO Structure with FIFO Base Object and n FIFO Slave Objects

XMC4500
XMC4000 Family
18.3.9.5 Receive FIFO

The Receive FIFO structure is used to buffer incoming (received) Remote or Data
Frames.
A Receive FIFO is selected by setting MOFCRn.MMC = 0001B in the FIFO base object.
This MMC code automatically designates a message object as FIFO base object. The
message modes of the FIFO slave objects are not relevant for the operation of the
Receive FIFO.
When the FIFO base object receives a frame from the CAN node it belongs to, the frame
is not stored in the base object itself but in the message object that is selected by the
base objects MOFGPRn.CUR pointer. This message object receives the CAN message
as if it is the direct receiver of the message. However, MOFCRn.MMC = 0000B is
implicitly assumed for the FIFO slave object, and a standard message delivery is
performed. The actual message mode (MMC setting) of the FIFO slave object is ignored.
For the slave object, no acceptance filtering takes place that checks the received frame
for a match with the identifier, IDE bit, and DIR bit.
With the reception of a CAN frame, the current pointer CUR of the base object is set to
the number of the next message object in the FIFO structure. This message object will
then be used to store the next incoming message.
If bit field MOFCRn.OVIE (Overflow Interrupt Enable) of the FIFO base object is set and
the current pointer MOFGPRn.CUR becomes equal to MOFGPRn.SEL, a FIFO overflow
interrupt request is generated. This interrupt request is generated on interrupt node
TXINP of the base object immediately after the storage of the received frame in the slave
object. Transmit interrupts are still generated if TXIE is set.
A CAN message is stored in a FIFO slave only if MSGVAL = 1 in both FIFO base and
slave object.
In order to avoid direct reception of a message by a slave message object, as if it was
an independent message object and not a part of a FIFO, the bit RXEN of each slave
object must be cleared. The setting of the bit RXEN is dont care only if the slave object
is located in a list not assigned to a CAN node.

XMC4500
XMC4000 Family
18.3.9.6 Transmit FIFO

The Transmit FIFO structure is used to buffer a series of Data or Remote Frames that
must be transmitted. A transmit FIFO consists of one base message object and one or
more slave message objects.
A Transmit FIFO is selected by setting MOFCRn.MMC = 0010B in the FIFO base object.
Unlike the Receive FIFO, slave objects assigned to the Transmit FIFO must explicitly set
their bit fields MOFCRn.MMC = 0011B. The CUR pointer in all slave objects must point
back to the Transmit FIFO Base Object (to be initialized by software).
The MOSTATn.TXEN1 bits (Transmit Enable 1) of all message objects except the one
which is selected by the CUR pointer of the base object must be cleared by software.
TXEN1 of the message (slave) object selected by CUR must be set. CUR (of the base
object) may be initialized to any FIFO slave object.
When tagging the message objects of the FIFO as valid to start the operation of the
FIFO, then the base object must be tagged valid (MSGVAL = 1) first.
Before a Transmit FIFO becomes de-installed during operation, its slave objects must
be tagged invalid (MSGVAL = 0).
The Transmit FIFO uses the TXEN1 bit in the Message Object Control Register of all
FIFO elements to select the actual message for transmission. Transmit acceptance
filtering evaluates TXEN1 for each message object and a message object can win
transmit acceptance filtering only if its TXEN1 bit is set. When a FIFO object has
transmitted a message, the hardware clears its TXEN1 bit in addition to standard
transmit postprocessing (clear TXRQ, transmit interrupt etc.), and moves the CUR
pointer in the next FIFO base object to be transmitted. TXEN1 is set automatically (by
hardware) in the next message object. Thus, TXEN1 moves along the Transmit FIFO
structure as a token that selects the active element.
If bit field MOFCRn.OVIE (Overflow Interrupt Enable) of the FIFO base object is set and
the current pointer CUR becomes equal to MOFGPRn.SEL, a FIFO overflow interrupt
request is generated. The interrupt request is generated on interrupt node RXINP of the
base object after postprocessing of the received frame. Receive interrupts are still
generated for the Transmit FIFO base object if bit RXIE is set.

XMC4500
XMC4000 Family
18.3.9.7 Gateway Mode

The Gateway Mode makes it possible to establish an automatic information transfer
between two independent CAN buses without CPU interaction.
The Gateway Mode operates on message object level. In Gateway mode, information is
transferred between two message objects, resulting in an information transfer between
the two CAN nodes to which the message objects are allocated. A gateway may be
established with any pair of CAN nodes, and there can be as many gateways as there
are message objects available to build the gateway structure.
Gateway Mode is selected by setting MOFCRs.MMC = 0100B for the gateway source
object s. The gateway destination object d is selected by the MOFGPRd.CUR pointer of
the source object. The gateway destination object only needs to be valid (its
MSGVAL = 1). All other settings are not relevant for the information transfer from the
source object to the destination object.
Gateway source object behaves as a standard message object with the difference that
some additional actions are performed by the MultiCAN module when a CAN frame has
been received and stored in the source object (see Figure 18-20):
1. If bit MOFCRs.DLCC is set, the data length code MOFCRs.DLC is copied from the
gateway source object to the gateway destination object.
2. If bit MOFCRs.IDC is set, the identifier MOARs.ID and the identifier extension
MOARs.IDE are copied from the gateway source object to the gateway destination
object.
3. If bit MOFCRs.DATC is set, the data bytes stored in the two data registers
MODATALs and MODATAHs are copied from the gateway source object to the
gateway destination object. All 8 data bytes are copied, even if MOFCRs.DLC
indicates less than 8 data bytes.
4. If bit MOFCRs.GDFS is set, the transmit request flag MOSTATd.TXRQ is set in the
gateway destination object.
5. The receive pending bit MOSTATd.RXPND and the new data bit
MOSTATd.NEWDAT are set in the gateway destination object.
6. A message interrupt request is generated for the gateway destination object if its
MOSTATd.RXIE is set.
7. The current object pointer MOFGPRs.CUR of the gateway source object is moved to
the next destination object according to the FIFO rules as described on Page 18-46.
A gateway with a single (static) destination object is obtained by setting
MOFGPRs.TOP = MOFGPRs.BOT = MOFGPRs.CUR = destination object.
The link from the gateway source object to the gateway destination object works in the
same way as the link from a FIFO base to a FIFO slave. This means that a gateway with
an integrated destination FIFO may be created; in Figure 18-19, the object on the left is
the gateway source object and the message object on the right side is the gateway
destination objects.

XMC4500
XMC4000 Family
The gateway operates equivalent for the reception of data frames (source object is
receive object, i.e. DIR = 0) as well as for the reception of Remote Frames (source object
is transmit object).
Source CAN Bus Destination CAN Bus
Pointer to Destination
Message Object
CUR
Copy if IDCSource = 1
Identifier + IDE Identifier + IDE
Copy if DLCCSource = 1
DLC DLC
Copy if DATCSource = 1
Data Data
Set if GDFSSource = 1
TXRQ
Set
NEWDAT
Source
Message Object Set
MMC = 0100B TXRQ
Destination
Message Object
MCA06278
Figure 18-20 Gateway Transfer from Source to Destination

XMC4500
XMC4000 Family
18.3.9.8 Foreign Remote Requests

When a Remote Frame has been received on a CAN node and is stored in a message
object, a transmit request is set to trigger the answer (transmission of a Data Frame) to
the request or to automatically issue a secondary request. If the Foreign Remote
Request Enable bit MOFCRn.FRREN is cleared in the message object in which the
remote request is stored, MOSTATn.TXRQ is set in the same message object.
If bit FRREN is set (FRREN = 1: foreign remote request enabled), TXRQ is set in the
message object that is referenced by pointer MOFGPRn.CUR. The value of CUR is,
however, not changed by this feature.
Although the foreign remote request feature works independently of the selected
message mode, it is especially useful for gateways to issue a remote request on the
source bus of a gateway after the reception of a remote request on the gateway
destination bus. According to the setting of FRREN in the gateway destination object,
there are two capabilities to handle remote requests that appear on the destination side
(assuming that the source object is a receive object and the destination is a transmit
object, i.e. DIRsource = 0 and DIRdestination = 1):
FRREN = 0 in the Gateway Destination Object

1. A Remote Frame is received by gateway destination object.
2. TXRQ is set automatically in the gateway destination object.
3. A Data Frame with the current data stored in the destination object is transmitted on
the destination bus.
FRREN = 1 in the Gateway Destination Object

1. A Remote Frame is received by gateway destination object.
2. TXRQ is set automatically in the gateway source object (must be referenced by CUR
pointer of the destination object).
3. A remote request is transmitted by the source object (which is a receive object) on
the source CAN bus.
4. The receiver of the remote request responds with a Data Frame on the source bus.
5. The Data Frame is stored in the source object.
6. The Data Frame is copied to the destination object (gateway action).
7. TXRQ is set in the destination object (assuming GDFSsource = 1).
8. The new data stored in the destination object is transmitted on the destination bus,
in response to the initial remote request on the destination bus.

XMC4500
XMC4000 Family

The interrupt control logic in the MultiCAN module uses an interrupt compressing
scheme that allows high flexibility in interrupt processing. There are 140 hardware
interrupt sources and one software interrupt source available:
CAN node interrupts:
Four different interrupt sources for each of the three CAN nodes = 12 interrupt
sources
Message object interrupts:
Two interrupt source for each message object = 128 interrupt sources
One software initiated interrupt (register MITR)
Each of the 140 hardware initiated interrupt sources is controlled by a 4-bit interrupt
pointer that directs the interrupt source to one of the 8 interrupt outputs INT_Om (m = 0-
7). This makes it possible to connect more than one interrupt source (between one and
all) to one interrupt output line. The interrupt wiring matrix shown in Figure 18-21 is built
up according to the following rules:
Each output of the 4-bit interrupt pointer demultiplexer is connected to exactly one
OR-gate input of the INT_Om line. The number m of the corresponding selected
INT_Om interrupt output line is defined by the interrupt pointer value.
Each INT_Om output line has an input OR gate which is connected to all interrupt
pointer demultiplexer outputs which are selected by an identical 4-bit pointer value.

XMC4500
XMC4000 Family
CAN 4
Node
0
1
SR0
CAN
4 1
Node SR1
1
..
..
..
..
..
CAN 4 ..
Interrupt ..
Node
2 Wiring ..
Matrix ..
..
..
..
..
Message ..
2 ..
Object
0 1
.. SR6
..
..
Message 1
2
Object SR7
63
Register 16
MITR
Mca 06284_3n_nott_64_v2.vsd
Figure 18-21 Interrupt Compressor

XMC4500
XMC4000 Family
18.5 Debug behavior

The Suspend Mode can be triggered by the OCDS in order to freeze the state of the
module and to permit access to the registers (at least for read actions). The MultiCAN
module provides the following Suspend Modes:
The current action is finished (Soft Suspend Mode):
The module clock fCLC keeps running. Module functions are stopped automatically
after internal actions have been finished (for example, after a CAN frame has been
sent out). The end of the internal actions is indicated to the fractional divider by a
suspend mode acknowledged signal. Due to this behavior, the communication
network is not blocked. Furthermore, all registers are accessible for read and write
actions. As a result, the debugger can stop the module actions and modify registers.
These modifications are taken into account after the Suspend Mode is left.
The Soft Suspend Mode can be individually enabled for each CAN node.
A CAN node that is not active can always be suspended. Refer to CAN_CLC and
CAN_FDR registers for the corresponding OCDS control.

XMC4500
XMC4000 Family

The MultiCAN module is located in the core power domain. The module and all registers
are reset to their default state by a system reset as shown on Table 18-4 and
Table 18-13.
18.6.1 Clock Control

The CAN module timer clock fCAN of the functional blocks of the MultiCAN module is
derived from the module control clock fCLC. The Fractional Divider is used to generate
fCAN used for bit timing calculation, The frequency of fCAN is identical for all CAN nodes.
The register file operate with the module control clock fCLC. See also Module Clock
Generation on Page 18-58.
The output clock fCAN of the Fractional Divider is based on the system clock fCLC, but only
every n-th clock pulse is taken. The suspend signal (coming as acknowledge from the
MultiCAN module in response to a OCDS suspend request) freezes or resets the
Fractional Divider.
Module Kernel
fPB f CLC fCAN

Clock Control Fractional Baud Rate
Register Divider Prescalers
Register
File
mca 06265_c
Figure 18-22 MultiCAN Clock Generation

Table 18-3 indicates the minimum operating frequencies in MHz for fCLC that are
required for a baud rate of 1 Mbit/s for the active CAN nodes. If a lower baud rate is
desired, the values can be scaled linearly (e.g. for a maximum of 500 kbit/s, 50% of the
indicated value are required).
The values imply that the CPU (or DMA) executes maximum accesses to the MultiCAN
module. The values may contain rounding effects.

XMC4500
XMC4000 Family
Table 18-3 Minimum Operating Frequencies [MHz]

Number of allocated message objects MO1) 1 CAN 2 CAN 3 CAN
node nodes nodes
active active active
16 MO 12 19 26
32 MO 15 23 30
64 MO 21 28 37
1) Only those message objects have to be taken into account that are allocated to a CAN node. The unallocated
message objects have no influence on the minimum operating frequency.
The baud rate generation of the MultiCAN being based on fPB, this frequency has to be
chosen carefully to allow correct CAN bit timing. The required value of fPB is given by an
integer multiple (n) of the CAN baud rate multiplied by the number of time quanta per
CAN bit time. For example, to reach 1 Mbit/s with 20 tq per bit time, possible values of
fPB are given by formula [n 20] MHz, with n being an integer value, starting at 1.
In order to minimize jitter, it is not recommended to use the fractional divider mode for
high baud rates.

XMC4500
XMC4000 Family
18.6.2 Module Clock Generation

As shown in Figure 18-23, the clock signals for the MultiCAN module are generated and
controlled by a clock control unit. This clock generation unit is responsible for the
enable/disable control, the clock frequency adjustment, and the debug clock control.
This unit includes two registers:
CAN_CLC: generation of the module control clock fCLC
CAN_FDR: frequency control of the module timer clock fCAN
MultiCAN Clock Control
fPB Clock Control Fractional Divider fCAN

Register Register
CAN_CLC CAN_FDR
fCLC
mca 06283_b
Figure 18-23 MultiCAN Module Clock Generation

The module control clock fCLC is used inside the MultiCAN module for control purposes
such as clocking of control logic and register operations. The frequency of fCLC is
identical to the system clock frequency fPB. The clock control register CAN_CLC makes
it possible to enable/disable fCLC under certain conditions.
The module timer clock fCAN is used inside the MultiCAN module as input clock for all
timing relevant operations (e.g. bit timing). The settings in the CAN_FDR register
determine the frequency of the module timer clock fCAN according the following two
formulas:
1
f CAN = f PB --- with n = 1024 - CAN_FDR.STEP (18.1)
n
n
f CAN = f PB ------------- with n = 0-1023 (18.2)
1024
Equation (18.1) applies to normal divider mode (CAN_FDR.DM = 01B) of the fractional
divider. Equation (18.2) applies to fractional divider mode (CAN_FDR.DM = 10B).
Note: The CAN module is disabled after reset. In general, after reset, the module control
clock fCLC must be switched on (writing to register CAN_CLC) before the
frequency of the module timer clock fCAN is defined (writing to register CAN_FDR).

XMC4500
XMC4000 Family
18.7 Register Description

This section describes the kernel registers of the MultiCAN module. All MultiCAN kernel
register names described in this section are also referenced in other parts of the
XMC4500 Reference Manual by the module name prefix CAN_.
MultiCAN Kernel Register Overview

The MultiCAN Kernel include three blocks of registers:
Global Module Registers
Node Registers, for each CAN node x
Message Object Registers, for each message object n
Global Module CAN Node Message Object

Registers Registers Registers
LISTi NCRx MOFCRn

MSPNDk NSRx MOFGPRn
MSIDk NIPRx MOIPRn
MSIMASK NPCRx MOAMRn
PANCTR NBTRx MOARn
MCR NECNTx MODATALn
MITR NFCRx MODATAHn
MOCTRn
i = 0 to (Lists -1) x = 0 to (CAN Nodes 1)
k = 0 (Message MOSTATn
Pending Registers -1)
n = 0 to (Message Objects 1)
MCA 06279_x.vsd
Figure 18-24 MultiCAN Kernel Registers

The registers of the MultiCAN module kernel are listed below.
Table 18-4 Registers Address Space - MultiCAN Kernel Registers

CAN 4801 4000H 4801 7FFFH -

XMC4500
XMC4000 Family
Table 18-5 Registers Overview - MultiCAN Kernel Registers

Register Register Long Name Offset Access Mode2) Description
Short Name Address see
1)
Read Write
Global Module Registers

LISTi List Register i 0100H + U, PV U, PV Page 18-69
i 4H
MSPNDk Message Pending Register k 0140H + U, PV U, PV Page 18-71
k 4H
MSIDk Message Index Register k 0180H + U, PV U, PV Page 18-72
k 4H
MSIMASK Message Index Mask 01C0H U, PV U, PV Page 18-73
Register
PANCTR Panel Control Register 01C4H U, PV U, PV Page 18-63
MCR Module Control Register 01C8H U, PV U, PV Page 18-67
MITR Module Interrupt Trigger 01CCH U, PV U, PV Page 18-68
Reg.
CAN Node Registers
NCRx Node x Control Register 0200H + U, PV U, PV Page 18-74
x 100H
NSRx Node x Status Register 0204H + U, PV U, PV Page 18-78
x 100H
NIPRx Node x Interrupt Pointer Reg. 0208H + U, PV U, PV Page 18-82
x 100H
NPCRx Node x Port Control Register 020CH + U, PV U, PV Page 18-84
x 100H
NBTRx Node x Bit Timing Register 0210H + U, PV U, PV Page 18-85
x 100H
NECNTx Node x Error Counter 0214H + U, PV U, PV Page 18-87
Register x 100H
NFCRx Node x Frame Counter 0218H + U, PV U, PV Page 18-89
Register x 100H
Message Object Registers
MOFCRn Message Object n 1000H + U, PV U, PV Page 18-10
Function Control Register n 20H 3

XMC4500
XMC4000 Family
Table 18-5 Registers Overview - MultiCAN Kernel Registers (contd)

Register Register Long Name Offset Access Mode2) Description
Short Name Address see
1)
Read Write
MOFGPRn Message Object n 1004H + U, PV U, PV Page 18-10

FIFO/Gateway Pointer n 20H 7
Register
MOIPRn Message Object n 1008H + U, PV U, PV Page 18-10
Interrupt Pointer Register n 20H 1
MOAMRn Message Object n 100CH + U, PV U, PV Page 18-10
Acceptance Mask Register n 20H 8
MODATALn Message Object n 1010H + U, PV U, PV Page 18-11
Data Register Low n 20H 2
MODATAHn Message Object n 1014H + U, PV U, PV Page 18-11
Data Register High n 20H 3
MOARn Message Object n 1018H + U, PV U, PV Page 18-10
Arbitration Register n 20H 9
MOCTRn Message Object n Control 101CH + U, PV U, PV Page 18-93
MOSTATn Reg. n 20H Page 18-96
Message Object n Status
Reg.
Further, the following ranges for parameters i, k, x, and n are valid: i = 0-7, k = 0-7, x = 0-2, n = 0-63.
2) Accesses to empty addresses: nBE
18.7.1 Global Module Registers

All list operations such as allocation, de-allocation and relocation of message objects
within the list structure are performed via the Command Panel. It is not possible to modify
the list structure directly by software by writing to the message objects and the LIST
registers.
ID
The ID (Module Identification Register) defines the MultiCAN module identification
number, module type and module revision number.

XMC4500
XMC4000 Family
ID
Module Identification Register (008H) Reset Value: 002B C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MOD_NUMBER
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MOD_TYPE MODE_REV
r rwh

C0H Define the module as a 32-bit module.
This bit field defines the MultiCAN module
identification number (=002BH)

XMC4500
XMC4000 Family
PANCTR
The Panel Control Register PANCTR is used to start a new command by writing the
command arguments and the command code into its bit fields.
PANCTR
Panel Control Register (1C4H) Reset Value: 0000 0301H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PANAR2 PANAR1
rwh rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RBU BUS
0 PANCMD
SY Y
r rh rh rwh

PANCMD [7:0] rwh Panel Command
This bit field is used to start a new command by
writing a panel command code into it. At the end of a
panel command, the NOP (no operation) command
code is automatically written into PANCMD. The
coding of PANCMD is defined in Table 18-6.
BUSY 8 rh Panel Busy Flag
0B Panel has finished command and is ready to
accept a new command.
1B Panel operation is in progress.
RBUSY 9 rh Result Busy Flag
0B No update of PANAR1 and PANAR2 is
scheduled by the list controller.
1B A list command is running (BUSY = 1) that will
write results to PANAR1 and PANAR2, but the
results are not yet available.
PANAR1 [23:16] rwh Panel Argument 1
See Table 18-6.
PANAR2 [31:24] rwh Panel Argument 2
See Table 18-6.

XMC4500
XMC4000 Family

Panel Commands
A panel operation consists of a command code (PANCMD) and up to two panel
arguments (PANAR1, PANAR2). Commands that have a return value deliver it to the
PANAR1 bit field. Commands that return an error flag deliver it to bit 31 of the Panel
Control Register, this means bit 7 of PANAR2.
Table 18-6 Panel Commands

PANCMD PANAR2 PANAR1 Command Description
00H No Operation
Writing 00H to PANCMD has no effect.
No new command is started.
01H Result: Initialize Lists
Bit 7: ERR Run the initialization sequence to reset
Bit 6-0: undefined the CTRL and LIST fields of all message
objects. List registers LIST[7:0] are set to
their reset values. This results in the de-
allocation of all message objects.
The initialization command requires that
bits NCRx.INIT and NCRx.CCE are set
for all CAN nodes.
Bit 7 of PANAR2 (ERR) reports the
success of the operation:
0B Initialization was successful
1B Not all NCRx.INIT and NCRx.CCE
bits are set. Therefore, no
initialization is performed.
The initialize lists command is
automatically performed with each reset
of the MultiCAN module, but with the
exception that all message object
registers are reset, too.

XMC4500
XMC4000 Family
Table 18-6 Panel Commands (contd)

02H Argument: Argument: Static Allocate
List Index Message Allocate message object to a list. The
Object message object is removed from the list
Number that it currently belongs to, and
appended to the end of the list, given by
PANAR2.
This command is also used to deallocate
a message object. In this case, the target
list is the list of unallocated elements
(PANAR2 = 0).
03H Argument: Result: Dynamic Allocate
List Index Message Allocate the first message object of the
Result: Object list of unallocated objects to the selected
Bit 7: ERR Number list. The message object is appended to
Bit 6-0: undefined the end of the list. The message number
of the message object is returned in
PANAR1.
An ERR bit (bit 7 of PANAR2) reports the
0B Success.
1B The operation has not been
performed because the list of
unallocated elements was empty.
04H Argument: Argument: Static Insert Before
Destination Object Source Remove a message object (source
Number Object object) from the list that it currently
Number belongs to, and insert it before a given
destination object into the list structure of
the destination object.
The source object thus becomes the
predecessor of the destination object.

XMC4500
XMC4000 Family
Table 18-6 Panel Commands (contd)

05H Argument: Result: Dynamic Insert Before
Destination Object Object Insert a new message object before a
Number Number of given destination object. The new object
Result: inserted is taken from the list of unallocated
Bit 7: ERR object elements (the first element is chosen).
Bit 6-0: undefined The number of the new object is
delivered as a result to PANAR1.
0B Success.
06H Argument: Argument: Static Insert Behind
Destination Object Source Remove a message object (source
Number Object object) from the list that it currently
Number belongs to, and insert it behind a given
destination object into the list structure of
the destination object.
The source object thus becomes the
successor of the destination object.
07H Argument: Result: Dynamic Insert Behind
Destination Object Object Insert a new message object behind a
Number Number of given destination object. The new object
Result: inserted is taken from the list of unallocated
Bit 7: ERR object elements (the first element is chosen).
Bit 6-0: undefined The number of the new object is
delivered as result to PANAR1.
0B Success.
08H - FFH Reserved

XMC4500
XMC4000 Family
MCR
The Module Control Register MCR contains basic settings that determine the operation
of the MultiCAN module.
MCR
Module Control Register (1C8H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MPSEL 0
rw r

MPSEL [15:12] rw Message Pending Selector
Bit field MPSEL makes it possible to select the bit
position of the message pending bit after a message
reception/transmission by a mixture of the MOIPRn
register bit fields RXINP, TXINP, and MPN. Selection
details are given in Figure 18-16 on Page 18-37.

XMC4500
XMC4000 Family
MITR
The Interrupt Trigger Register ITR is used to trigger interrupt requests on each interrupt
output line by software.
MITR
Module Interrupt Trigger Register (1CCH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
IT

IT [7:0] w Interrupt Trigger
Writing a 1 to IT[n] (n = 0-7) generates an interrupt
request on interrupt output line INT_O[n]. Writing a 0 to
IT[n] has no effect. Bit field IT is always read as 0.
Multiple interrupt requests can be generated with a
single write operation to MITR by writing a 1 to several
bit positions of IT.
0 [31:8] r Reserved

XMC4500
XMC4000 Family
LIST
Each CAN node has a list that determines the allocated message objects. Additionally,
a list of all unallocated objects is available. Furthermore, general purpose lists are
available which are not associated to a CAN node. The List Registers are assigned in
the following way:
LIST0 provides the list of all unallocated objects
LIST1 provides the list for CAN node 0
LIST[7:4] are not associated to a CAN node (free lists)
LIST0
List Register 0 (100H) Reset Value: 003F 3F00H
LISTx (x = 1-7)
List Register x (100H+x*4H) Reset Value: 0100 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
EMP
0 SIZE
TY
r rh rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
END BEGIN
rh rh

BEGIN [7:0] rh List Begin
BEGIN indicates the number of the first message object
in list i.
END [15:8] rh List End
END indicates the number of the last message object in
list i.
SIZE [23:16] rh List Size
SIZE indicates the number of elements in the list i.
SIZE = number of list elements - 1
SIZE = 0 indicates that list x is empty.

XMC4500
XMC4000 Family

EMPTY 24 rh List Empty Indication
0B At least one message object is allocated to list i.
1B No message object is allocated to the list x. List x
is empty.
Read as 0.

XMC4500
XMC4000 Family
MSPNDk
When a message object n generates an interrupt request upon the transmission or
reception of a message, then the request is routed to the interrupt output line selected
by the bit field MOIPRn.TXINP or MOIPRn.RXINP of the message object n. As there are
more message objects than interrupt output lines, an interrupt routine typically processes
requests from more than one message object. Therefore, a priority selection mechanism
is implemented in the MultiCAN module to select the highest priority object within a
collection of message objects.
The Message Pending Register MSPNDk contains the pending interrupt notification of
list i.
MSPNDk (k = 0-7)
Message Pending Register k (140H+k*4H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PND
rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PND
rwh

PND [31:0] rwh Message Pending
When a message interrupt occurs, the message
object sets a bit in one of the MSPND register, where
the bit position is given by the MPN[4:0] field of the
IPR register of the message object. The register
selection n is given by the higher bits of MPN.
The register bits can be cleared by software (write 0).
Writing a 1 has no effect.

XMC4500
XMC4000 Family
MSIDk
Each Message Pending Register has a Message Index Register MSIDk associated with
it. The Message Index Register shows the active (set) pending bit with lowest bit position
within groups of pending bits.
MSIDk (k = 0-7)
Message Index Register k (180H+k*4H) Reset Value: 0000 0020H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 INDEX
r rh

INDEX [5:0] rh Message Pending Index
The value of INDEX is given by the bit position i of the
pending bit of MSPNDk with the following properties:
1. MSPNDk[i] & IM[i] = 1
2. i = 0 or MSPNDk[i-1:0] & IM[i-1:0] = 0
If no bit of MSPNDk satisfies these conditions then
INDEX reads 100000B.
Thus INDEX shows the position of the first pending bit
of MSPNDk, in which only those bits of MSPNDk that
are selected in the Message Index Mask Register are
taken into account.
0 [31:6] r Reserved

XMC4500
XMC4000 Family
MSIMASK
The Message Index Mask Register MSIMASK selects individual bits for the calculation
of the Message Pending Index. The Message Index Mask Register is used commonly
for all Message Pending registers and their associated Message Index registers.
MSIMASK
Message Index Mask Register (1C0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
IM
rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
IM
rw

IM [31:0] rw Message Index Mask
Only those bits in MSPNDk for which the
corresponding Index Mask bits are set contribute to
the calculation of the Message Index.

XMC4500
XMC4000 Family
18.7.2 CAN Node Registers

The CAN node registers are built in for each CAN node of the MultiCAN module. They
contain information that is directly related to the operation of the CAN nodes and are
shared among the nodes.
NCR
The Node Control Register contains basic settings that determine the operation of the
CAN node.
NCRx (x = 0-2)
Node x Control Register (200H+x*100H) Reset Value: 0000 0001H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SUS CAL CAN LECI
0 CCE 0 ALIE TRIE INIT
EN M DIS E
r rw rw rw r rw rw rw rw rwh

XMC4500
XMC4000 Family

INIT 0 rwh Node Initialization
0B Resetting bit INIT enables the participation of the
node in the CAN traffic.
If the CAN node is in the bus-off state, the ongoing
bus-off recovery (which does not depend on the
INIT bit) is continued. With the end of the bus-off
recovery sequence the CAN node is allowed to
take part in the CAN traffic.
If the CAN node is not in the bus-off state, a
sequence of 11 consecutive recessive bits must be
detected before the node is allowed to take part in
the CAN traffic.
1B Setting this bit terminates the participation of this
node in the CAN traffic. Any ongoing frame transfer
is cancelled and the transmit line goes recessive.
If the CAN node is in the bus-off state, then the
running bus-off recovery sequence is continued. If
the INIT bit is still set after the successful
completion of the bus-off recovery sequence, i.e.
after detecting 128 sequences of 11 consecutive
recessive bits (11 1), then the CAN node leaves
the bus-off state but remains inactive as long as
INIT remains set.
Bit INIT is automatically set when the CAN node enters
the bus-off state (see Page 18-20).
TRIE 1 rw Transfer Interrupt Enable
TRIE enables the transfer interrupt of CAN node x. This
interrupt is generated after the successful reception or
transmission of a CAN frame in node x.
0B Transfer interrupt is disabled.
1B Transfer interrupt is enabled.
Bit field NIPRx.TRINP selects the interrupt output line
which becomes activated at this type of interrupt.

XMC4500
XMC4000 Family

LECIE 2 rw LEC Indicated Error Interrupt Enable
LECIE enables the last error code interrupt of CAN
node x. This interrupt is generated with each update of bit
field NSRx.LEC with LEC > 0 (CAN protocol error).
0B Last error code interrupt is disabled.
1B Last error code interrupt is enabled.
Bit field NIPRx.LECINP selects the interrupt output line
ALIE 3 rw Alert Interrupt Enable
ALIE enables the alert interrupt of CAN node x. This
interrupt is generated by any one of the following events:
A change of bit NSRx.BOFF
A change of bit NSRx.EWRN
A List Length Error, which also sets bit NSRx.LLE
A List Object Error, which also sets bit NSRx.LOE
A Bit INIT is set by hardware
0B Alert interrupt is disabled.
1B Alert interrupt is enabled.
Bit field NIPRx.ALINP selects the interrupt output line
CANDIS 4 rw CAN Disable
Setting this bit disables the CAN node. The CAN node
first waits until it is bus-idle or bus-off. Then bit INIT is
automatically set, and an alert interrupt is generated if bit
ALIE is set.
CCE 6 rw Configuration Change Enable
0B The Bit Timing Register, the Port Control Register,
and the Error Counter Register may only be read.
All attempts to modify them are ignored.
1B The Bit Timing Register, the Port Control Register,
and the Error Counter Register may be read and
written.
CALM 7 rw CAN Analyzer Mode
If this bit is set, then the CAN node operates in Analyzer
Mode. This means that messages may be received, but
not transmitted. No acknowledge is sent on the CAN bus
upon frame reception. Active-error flags are sent
recessive instead of dominant. The transmit line is
continuously held at recessive (1) level.
Bit CALM can be written only while bit INIT is set.

XMC4500
XMC4000 Family

SUSEN 8 rw Suspend Enable
This bit makes it possible to set the CAN node into
Suspend Mode via OCDS (on chip debug support):
0B An OCDS suspend trigger is ignored by the CAN
node.
1B An OCDS suspend trigger disables the CAN node:
As soon as the CAN node becomes bus-idle or
bus-off, bit INIT is internally forced to 1 to disable
the CAN node. The actual value of bit INIT remains
unchanged.
Bit SUSEN is reset via OCDS Reset.

XMC4500
XMC4000 Family
NSR
The Node Status Register NSRx reports errors as well as successfully transferred CAN
frames.
NSRx (x = 0-2)
Node x Status Register (204H+x*100H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SUS BOF EWR ALE RXO TXO
0 LOE LLE LEC
ACK F N RT K K
r rh rwh rwh rh rh rwh rwh rwh rwh

LEC [2:0] rwh Last Error Code
This bit field indicates the type of the last (most
recent) CAN error. The encoding of this bit field is
described in Table 18-7.
TXOK 3 rwh Message Transmitted Successfully
0B No successful transmission since last (most
recent) flag reset.
1B A message has been transmitted successfully
(error-free and acknowledged by at least
another node).
TXOK must be reset by software (write 0). Writing 1
has no effect.
RXOK 4 rwh Message Received Successfully
0B No successful reception since last (most
recent) flag reset.
1B A message has been received successfully.
RXOK must be reset by software (write 0). Writing 1
has no effect.

XMC4500
XMC4000 Family

ALERT 5 rwh Alert Warning
The ALERT bit is set upon the occurrence of one of
the following events (the same events which also
trigger an alert interrupt if ALIE is set):
A change of bit NSRx.BOFF
A change of bit NSRx.EWRN
A List Length Error, which also sets bit NSRx.LLE
A List Object Error, which also sets bit NSRx.LOE
Bit INIT has been set by hardware
ALERT must be reset by software (write 0). Writing 1
has no effect.
EWRN 6 rh Error Warning Status
0B No warning limit exceeded.
1B One of the error counters REC or TEC reached
the warning limit EWRNLVL.
BOFF 7 rh Bus-off Status
0B CAN controller is not in the bus-off state.
1B CAN controller is in the bus-off state.
LLE 8 rwh List Length Error
0B No List Length Error since last (most recent)
flag reset.
1B A List Length Error has been detected during
message acceptance filtering. The number of
elements in the list that belongs to this CAN
node differs from the list SIZE given in the list
termination pointer.
LLE must be reset by software (write 0). Writing 1 has
no effect.
LOE 9 rwh List Object Error
0B No List Object Error since last (most recent) flag
reset.
1B A List Object Error has been detected during
message acceptance filtering. A message
object with wrong LIST index entry in the
Message Object Control Register has been
detected.
LOE must be reset by software (write 0). Writing 1 has
no effect.

XMC4500
XMC4000 Family

SUSACK 10 rh Suspend Acknowledge
0B The CAN node is not in Suspend Mode or a
suspend request is pending, but the CAN node
has not yet reached bus-idle or bus-off.
1B The CAN node is in Suspend Mode: The CAN
node is inactive (bit NCR.INIT internally forced
to 1) due to an OCDS suspend request.
Encoding of the LEC Bit Field
Table 18-7 Encoding of the LEC Bit Field

LEC Value Signification
000B No Error:
No error was detected for the last (most recent) message on the CAN
bus.
001B Stuff Error:
More than 5 equal bits in a sequence have occurred in a part of a
received message where this is not allowed.
010B Form Error:
A fixed format part of a received frame has the wrong format.
011B Ack Error:
The transmitted message was not acknowledged by another node.
100B Bit1 Error:
During a message transmission, the CAN node tried to send a
recessive level (1) outside the arbitration field and the acknowledge
slot, but the monitored bus value was dominant.
101B Bit0 Error:
Two different conditions are signaled by this code:
1. During transmission of a message (or acknowledge bit, active-error
flag, overload flag), the CAN node tried to send a dominant level (0),
but the monitored bus value was recessive.
2. During bus-off recovery, this code is set each time a sequence of
11 recessive bits has been monitored. The CPU may use this code
as indication that the bus is not continuously disturbed.

XMC4500
XMC4000 Family
Table 18-7 Encoding of the LEC Bit Field (contd)

LEC Value Signification
110B CRC Error:
The CRC checksum of the received message was incorrect.
111B CPU write to LEC:
Whenever the the CPU writes the value 111 to LEC, it takes the value
111. Whenever the CPU writes another value to LEC, the written LEC
value is ignored.

XMC4500
XMC4000 Family
NIPR
The four interrupt pointers in the Node Interrupt Pointer Register NIPRx select one out
of the sixteen interrupt outputs individually for each type of CAN node interrupt. See also
Page 18-21 for more CAN node interrupt details.
NIPRx (x = 0-2)
Node x Interrupt Pointer Register
(208H+x*100H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 CFCINP 0 TRINP 0 LECINP 0 ALINP
r rw r rw r rw r rw

ALINP [2:0] rw Alert Interrupt Node Pointer
ALINP selects the interrupt output line INT_Om
(m = 0-7) for an alert interrupt of CAN Node x.
000B Interrupt output line INT_O0 is selected.
B
LECINP [6:4] rw Last Error Code Interrupt Node Pointer
LECINP selects the interrupt output line INT_Om
(m = 0-7) for an LEC interrupt of CAN Node x.
B

XMC4500
XMC4000 Family

TRINP [10:8] rw Transfer OK Interrupt Node Pointer
TRINP selects the interrupt output line INT_Om
(m = 0-7) for a transfer OK interrupt of CAN Node x.
B
CFCINP [14:12] rw Frame Counter Interrupt Node Pointer
CFCINP selects the interrupt output line INT_Om
(m = 0-7) for a transfer OK interrupt of CAN Node x.
B
, 11, 7, Read as 0; should be written with 0.
3

XMC4500
XMC4000 Family
NPCR
The Node Port Control Register NPCRx configures the CAN bus transmit/receive ports.
NPCRx can be written only if bit NCRx.CCE is set.
NPCRx (x = 0-2)
Node x Port Control Register (20CH+x*100H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 LBM 0 RXSEL
r rw r rw

RXSEL [2:0] rw Receive Select
RXSEL selects one out of 8 possible receive inputs.
The CAN receive signal is performed only through the
selected input.
Note: In XMC4500, only specific combinations of
RXSEL are available (see also MultiCAN I/O
Control Selection and Setup on
Page 18-122).
LBM 8 rw Loop-Back Mode
0B Loop-Back Mode is disabled.
1B Loop-Back Mode is enabled. This node is
connected to an internal (virtual) loop-back
CAN bus. All CAN nodes which are in Loop-
Back Mode are connected to this virtual CAN
bus so that they can communicate with each
other internally. The external transmit line is
forced recessive in Loop-Back Mode.
0 [7:3], r Reserved

XMC4500
XMC4000 Family
NBTR
The Node Bit Timing Register NBTRx contains all parameters to set up the bit timing for
the CAN transfer. NBTRx can be written only if bit NCRx.CCE is set.
NBTRx (x = 0-2)
Node x Bit Timing Register (210H+x*100H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DIV8 TSEG2 TSEG1 SJW BRP
rw rw rw rw rw

BRP [5:0] rw Baud Rate Prescaler
The duration of one time quantum is given by
(BRP + 1) clock cycles if DIV8 = 0.
The duration of one time quantum is given by
8 (BRP + 1) clock cycles if DIV8 = 1.
SJW [7:6] rw (Re) Synchronization Jump Width
(SJW + 1) time quanta are allowed for re-
synchronization.
TSEG1 [11:8] rw Time Segment Before Sample Point
(TSEG1 + 1) time quanta is the user-defined nominal
time between the end of the synchronization segment
and the sample point. It includes the propagation
segment, which takes into account signal propagation
delays. The time segment may be lengthened due to
re-synchronization.
Valid values for TSEG1 are 2 to 15.
TSEG2 [14:12] rw Time Segment After Sample Point
(TSEG2 + 1) time quanta is the user-defined nominal
time between the sample point and the start of the
next synchronization segment. It may be shortened
due to re-synchronization.
Valid values for TSEG2 are 1 to 7.

XMC4500
XMC4000 Family

DIV8 15 rw Divide Prescaler Clock by 8
0B A time quantum lasts (BRP+1) clock cycles.
1B A time quantum lasts 8 (BRP+1) clock cycles.

XMC4500
XMC4000 Family
NECNT
The Node Error Counter Register NECNTx contains the CAN receive and transmit error
counter as well as some additional bits to ease error analysis. NECNTx can be written
only if bit NCRx.CCE is set.
NECNTx (x = 0-2)
Node x Error Counter Register (214H+x*100H) Reset Value: 0060 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
LEIN LET
0 EWRNLVL
C D
r rh rh rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TEC REC
rwh rwh

REC [7:0] rwh Receive Error Counter
Bit field REC contains the value of the receive error
counter of CAN node x.
TEC [15:8] rwh Transmit Error Counter
Bit field TEC contains the value of the transmit error
counter of CAN node x.
EWRNLVL [23:16] rw Error Warning Level
Bit field EWRNLVL determines the threshold value
(warning level, default 96) to be reached in order to
set the corresponding error warning bit EWRN.
LETD 24 rh Last Error Transfer Direction
0B The last error occurred while the CAN node x
was receiver (REC has been incremented).
1B The last error occurred while the CAN node x
was transmitter (TEC has been incremented).
LEINC 25 rh Last Error Increment
0B The last error led to an error counter increment
of 1.
1B The last error led to an error counter increment
of 8.

XMC4500
XMC4000 Family


XMC4500
XMC4000 Family
NFCR
The Node Frame Counter Register NFCRx contains the actual value of the frame
counter as well as control and status bits of the frame counter.
NFCRx (x = 0-2)
Node x Frame Counter Register (218H+x*100H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CFC CFCI
0 0 CFMOD CFSEL
OV E
r rwh rw r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CFC
rwh

CFC [15:0] rwh CAN Frame Counter
In Frame Count Mode (CFMOD = 00B), this bit field contains
the frame count value.
In Time Stamp Mode (CFMOD = 01B), this bit field contains
the captured bit time count value, captured with the start of a
new frame.
In all Bit Timing Analysis Modes (CFMOD = 10B), CFC
always displays the number of fCLC clock cycles
(measurement result) minus 1. Example: a CFC value of 34
in measurement mode CFSEL = 000B means that 35 fCLC
clock cycles have been elapsed between the most recent two
dominant edges on the receive input.

XMC4500
XMC4000 Family

CFSEL [18:16] rw CAN Frame Count Selection
This bit field selects the function of the frame counter for the
chosen frame count mode.
Frame Count Mode
Bit 0
If Bit 0 of CFSEL is set, then CFC is incremented each time
a foreign frame (i.e. a frame not matching to a message
object) has been received on the CAN bus.
Bit 1
a frame matching to a message object has been received on
the CAN bus.
Bit 2
a frame has been transmitted successfully by the node.
Time Stamp Mode
000B The frame counter is incremented (internally) at the
beginning of a new bit time. The value is sampled
during the SOF bit of a new frame. The sampled value
is visible in the CFC field.
Bit Timing Mode
The available bit timing measurement modes are shown in
Table 18-8. If CFCIE is set, then an interrupt on request
node x (where x is the CAN node number) is generated with
a CFC update.
CFMOD [20:19] rw CAN Frame Counter Mode
This bit field determines the operation mode of the frame
counter.
00B Frame Count Mode: The frame counter is incremented
upon the reception and transmission of frames.
01B Time Stamp Mode: The frame counter is used to count
bit times.
10B Bit Timing Mode: The frame counter is used for
analysis of the bit timing.

XMC4500
XMC4000 Family

CFCIE 22 rw CAN Frame Count Interrupt Enable
CFCIE enables the CAN frame counter overflow interrupt of
CAN node x.
0B CAN frame counter overflow interrupt is disabled.
1B CAN frame counter overflow interrupt is enabled.
Bit field NIPRx.CFCINP selects the interrupt output line that
is activated at this type of interrupt.
CFCOV 23 rwh CAN Frame Counter Overflow Flag
Flag CFCOV is set upon a frame counter overflow (transition
from FFFFH to 0000H). In bit timing analysis mode, CFCOV
is set upon an update of CFC. An interrupt request is
generated if CFCIE = 1.
0B No overflow has occurred since last flag reset.
1B An overflow has occurred since last flag reset.
CFCOV must be reset by software.
0 21, r Reserved
Bit Timing Analysis Modes
Table 18-8 Bit Timing Analysis Modes (CFMOD = 10)

CFSEL Measurement
000B Whenever a dominant edge (transition from 1 to 0) is monitored on the
receive input, the time (measured in clock cycles) between this edge and the
most recent dominant edge is stored in CFC.
001B Whenever a recessive edge (transition from 0 to 1) is monitored on the
receive input the time (measured in clock cycles) between this edge and the
most recent dominant edge is stored in CFC.
010B Whenever a dominant edge is received as a result of a transmitted dominant
edge, the time (clock cycles) between both edges is stored in CFC.
011B Whenever a recessive edge is received as a result of a transmitted recessive
edge, the time (clock cycles) between both edges is stored in CFC.
100B Whenever a dominant edge that qualifies for synchronization is monitored on
the receive input, the time (measured in clock cycles) between this edge and
the most recent sample point is stored in CFC.

XMC4500
XMC4000 Family
Table 18-8 Bit Timing Analysis Modes (CFMOD = 10) (contd)

CFSEL Measurement
101B With each sample point, the time (measured in clock cycles) between the
start of the new bit time and the start of the previous bit time is stored in
CFC[11:0].
Additional information is written to CFC[15:12] at each sample point:
CFC[15]: Transmit value of actual bit time
CFC[14]: Receive sample value of actual bit time
CFC[13:12]: CAN bus information (see Table 18-9)
110B Reserved, do not use this combination.
111B Reserved, do not use this combination.
Table 18-9 CAN Bus State Information

CFC[13:12] CAN Bus State
00B NoBit
The CAN bus is idle, performs bit (de-) stuffing or is in one of the following
frame segments:
SOF, SRR, CRC, delimiters, first 6 EOF bits, IFS.
01B NewBit
This code represents the first bit of a new frame segment.
The current bit is the first bit in one of the following frame segments:
Bit 10 (MSB) of standard ID (transmit only), RTR, reserved bits, IDE,
DLC(MSB), bit 7 (MSB) in each data byte and the first bit of the ID
extension.
10B Bit
This code represents a bit inside a frame segment with a length of more
than one bit (not the first bit of those frame segments that is indicated by
NewBit).
The current bit is processed within one of the following frame segments:
ID bits (except first bit of standard ID for transmission and first bit of ID
extension), DLC (3 LSB) and bits 6-0 in each data byte.
11B Done
The current bit is in one of the following frame segments:
Acknowledge slot, last bit of EOF, active/passive-error frame, overload
frame.
Two or more directly consecutive Done codes signal an Error Frame.

XMC4500
XMC4000 Family
18.7.3 Message Object Registers
MOCTR
The Message Object Control Register MOCTRn and the Message Object Status
Register MOSTATn are located at the same address offset within a message object
address block (offset address 1CH). The MOCTRn is a write-only register that makes it
possible to set/reset CAN transfer related control bits through software.
MOCTR0
Message Object 0 Control Register (101CH) Reset Value: 0100 0000H
MOCTRn (n = 1-62)
Message Object n Control Register
(101CH+n*20H)
Reset Value: ((n+1)*01000000H)+((n-1)*00010000H)
MOCTR63
Message Object 63 Control Register (17FCH) Reset Value: 3F3E 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SET SET SET SET SET SET SET SET SET SET SET
SET
0 TXE TXE TXR RXE RTS MSG MSG NEW RXU TXP RXP
DIR
N1 N0 Q N EL VAL LST DAT PD ND ND
w w w w w w w w w w w w w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RES RES RES RES RES RES RES RES RES RES RES
RES
0 TXE TXE TXR RXE RTS MSG MSG NEW RXU TXP RXP
DIR
N1 N0 Q N EL VAL LST DAT PD ND ND
w w w w w w w w w w w w w

RESRXPND, 0, w Reset/Set Receive Pending
SETRXPND 16 These bits control the set/reset condition for RXPND
(see Table 18-10).
RESTXPND, 1, w Reset/Set Transmit Pending
SETTXPND 17 These bits control the set/reset condition for TXPND
(see Table 18-10).
RESRXUPD, 2, w Reset/Set Receive Updating
SETRXUPD 18 These bits control the set/reset condition for RXUPD
(see Table 18-10).

XMC4500
XMC4000 Family

RESNEWDAT, 3, w Reset/Set New Data
SETNEWDAT 19 These bits control the set/reset condition for
NEWDAT (see Table 18-10).
RESMSGLST, 4, w Reset/Set Message Lost
SETMSGLST 20 These bits control the set/reset condition for
MSGLST (see Table 18-10).
RESMSGVAL, 5, w Reset/Set Message Valid
SETMSGVAL 21 These bits control the set/reset condition for
MSGVAL (see Table 18-10).
RESRTSEL, 6, w Reset/Set Receive/Transmit Selected
SETRTSEL 22 These bits control the set/reset condition for RTSEL
(see Table 18-10).
RESRXEN, 7, w Reset/Set Receive Enable
SETRXEN 23 These bits control the set/reset condition for RXEN
(see Table 18-10).
RESTXRQ, 8, w Reset/Set Transmit Request
SETTXRQ 24 These bits control the set/reset condition for TXRQ
(see Table 18-10).
RESTXEN0, 9, w Reset/Set Transmit Enable 0
SETTXEN0 25 These bits control the set/reset condition for TXEN0
(see Table 18-10).
RESTXEN1, 10, w Reset/Set Transmit Enable 1
SETTXEN1 26 These bits control the set/reset condition for TXEN1
(see Table 18-10).
RESDIR, 11, w Reset/Set Message Direction
SETDIR 27 These bits control the set/reset condition for DIR
(see Table 18-10).
0 [15:12], w Reserved
[31:28] Should be written with 0.

XMC4500
XMC4000 Family
Table 18-10 Reset/Set Conditions for Bits in Register MOCTRn

RESy Bit1) SETy Bit Action on Write
Write 0 Write 0 Leave element unchanged
No write
No write Write 0
Write 1 Write 1
Write 1 Write 0 Reset element
No write
Write 0 Write 1 Set element
No write
1) The parameter y stands for the second part of the bit name (RXPND, TXPND, up to DIR).

XMC4500
XMC4000 Family
MOSTAT
The MOSTATn is a read-only register that indicates message object list status
information such as the number of the current message object predecessor and
successor message object, as well as the list number to which the message object is
assigned.
MOSTAT0
Message Object 0 Status Register (101CH) Reset Value: 0100 0000H
MOSTATn (n = 1-62)
Message Object n Status Register
(101CH+n*20H)
Rest Value: ((n+1)*01000000H)+((n-1)*00010000H)
MOSTAT63
Message Object 63 Status Register (17FCH) Reset Value: 3F3E 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PNEXT PPREV
rh rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TX TX TX RX RTS MSG MSG NEW RX TX RX
LIST DIR
EN1 EN0 RQ EN EL VAL LST DAT UPD PND PND
rh rh rh rh rh rh rh rh rh rh rh rh rh

RXPND 0 rh Receive Pending
0B No CAN message has been received.
1B A CAN message has been received by the
message object n, either directly or via gateway
copy action.
RXPND is set by hardware and must be reset by
software.
TXPND 1 rh Transmit Pending
0B No CAN message has been transmitted.
1B A CAN message from message object n has
been transmitted successfully over the CAN
bus.
TXPND is set by hardware and must be reset by
software.

XMC4500
XMC4000 Family

RXUPD 2 rh Receive Updating
0B No receive update ongoing.
1B Message identifier, DLC, and data of the
message object are currently updated.
NEWDAT 3 rh New Data
0B No update of the message object n since last
flag reset.
1B Message object n has been updated.
NEWDAT is set by hardware after a received CAN
frame has been stored in message object n.
NEWDAT is cleared by hardware when a CAN
transmission of message object n has been started.
NEWDAT should be set by software after the new
transmit data has been stored in message object n to
prevent the automatic reset of TXRQ at the end of an
ongoing transmission.
MSGLST 4 rh Message Lost
0B No CAN message is lost.
1B A CAN message is lost because NEWDAT has
become set again when it has already been set.
MSGVAL 5 rh Message Valid
0B Message object n is not valid.
1B Message object n is valid.
Only a valid message object takes part in CAN
transfers.

XMC4500
XMC4000 Family

RTSEL 6 rh Receive/Transmit Selected
0B Message object n is not selected for receive or
transmit operation.
1B Message object n is selected for receive or
transmit operation.
Frame Reception:
RTSEL is set by hardware when message object n
has been identified for storage of a CAN frame that is
currently received. Before a received frame becomes
finally stored in message object n, a check is
performed to determine if RTSEL is set. Thus the
CPU can suppress a scheduled frame delivery to this
message object n by clearing RTSEL by software.
Frame Transmission:
RTSEL is set by hardware when message object n
has been identified to be transmitted next. A check is
performed to determine if RTSEL is still set before
message object n is actually set up for transmission
and bit NEWDAT is cleared. It is also checked that
RTSEL is still set before its message object n is
verified due to the successful transmission of a frame.
RTSEL needs to be checked only when the context of
message object n changes, and a conflict with an
ongoing frame transfer shall be avoided. In all other
cases, RTSEL can be ignored. RTSEL has no impact
on message acceptance filtering. RTSEL is not
cleared by hardware.
RXEN 7 rh Receive Enable
0B Message object n is not enabled for frame
reception.
1B Message object n is enabled for frame
reception.
RXEN is evaluated for receive acceptance filtering
only.

XMC4500
XMC4000 Family

TXRQ 8 rh Transmit Request
0B No transmission of message object n is
requested.
1B Transmission of message object n on the CAN
bus is requested.
The transmit request becomes valid only if TXRQ,
TXEN0, TXEN1 and MSGVAL are set. TXRQ is set
by hardware if a matching Remote Frame has been
received correctly. TXRQ is reset by hardware if
message object n has been transmitted successfully
and NEWDAT is not set again by software.
TXEN0 9 rh Transmit Enable 0
transmission.
transmission.
Message object n can be transmitted only if both bits,
TXEN0 and TXEN1, are set.
The user may clear TXEN0 in order to inhibit the
transmission of a message that is currently updated,
or to disable automatic response of Remote Frames.
TXEN1 10 rh Transmit Enable 1
transmission.
transmission.
Message object n can be transmitted only if both bits,
TXEN0 and TXEN1, are set.
TXEN1 is used by the MultiCAN module for selecting
the active message object in the Transmit FIFOs.

XMC4500
XMC4000 Family

DIR 11 rh Message Direction
0B Receive Object selected:
With TXRQ = 1, a Remote Frame with the
identifier of message object n is scheduled for
transmission. On reception of a Data Frame
with matching identifier, the message is stored
in message object n.
1B Transmit Object selected:
If TXRQ = 1, message object n is scheduled for
transmission of a Data Frame. On reception of
a Remote Frame with matching identifier, bit
TXRQ is set.
LIST [15:12] rh List Allocation
LIST indicates the number of the message list to
which message object n is allocated. LIST is updated
by hardware when the list allocation of the object is
modified by a panel command.
PPREV [23:16] rh Pointer to Previous Message Object
PPREV holds the message object number of the
previous message object in a message list structure.
PNEXT [31:24] rh Pointer to Next Message Object
PNEXT holds the message object number of the next
message object in a message list structure.
Table 18-11 MOSTATn Reset Values

Message Object PNEXT PPREV Reset Value
0 1 0 0100 0000H
1 2 0 0200 0000H
2 3 1 0301 0000H
3 4 2 0402 0000H

60 61 59 3D3B 0000H
61 62 60 3E3C 0000H
62 63 61 3F3D 0000H
63 63 62 3F3E 0000H

XMC4500
XMC4000 Family
MOIPR
The Message Object Interrupt Pointer Register MOIPRn holds the message interrupt
pointers, the message pending number, and the frame counter value of message
object n.
MOIPRn (n = 0-63)
Message Object n Interrupt Pointer Register
(1008H+n*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CFCVAL
rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
MPN 0 TXINP 0 RXINP
rw r rw r rw

RXINP [2:0] rw Receive Interrupt Node Pointer
RXINP selects the interrupt output line INT_Om
(m = 0-7) for a receive interrupt event of message
object n. RXINP can also be taken for message
pending bit selection (see Page 18-37).
B
TXINP [6:4] rw Transmit Interrupt Node Pointer
TXINP selects the interrupt output line INT_Om
(m = 0-7) for a transmit interrupt event of message
object n. TXINP can also be taken for message
pending bit selection (see Page 18-37).
B

XMC4500
XMC4000 Family

MPN [15:8] rw Message Pending Number
This bit field selects the bit position of the bit in the
Message Pending Register that is set upon a
message object n receive/transmit interrupt.
CFCVAL [31:16] rwh CAN Frame Counter Value
When a message is stored in message object n or
message object n has been successfully transmitted,
the CAN frame counter value NFCRx.CFC is then
copied to CFCVAL.
0 7, 3 r Reserved

XMC4500
XMC4000 Family
MOFCR
The Message Object Function Control Register MOFCRn contains bits that select and
configure the function of the message object. It also holds the CAN data length code.
MOFCRn (n = 0-63)
Message Object n Function Control Register
(1000H+n*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
FRR
0 DLC STT SDT RMM 0 OVIE TXIE RXIE
EN
rw rwh rw rw rw rw rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DAT DLC GDF
0 IDC 0 MMC
C C S

MMC [3:0] rw Message Mode Control
MMC controls the message mode of message
object n.
0000B Standard Message Object
0001B Receive FIFO Base Object
0010B Transmit FIFO Base Object
0011B Transmit FIFO Slave Object
0100B Gateway Source Object
...B Reserved
GDFS 8 rw Gateway Data Frame Send
0B TXRQ is unchanged in the destination object.
1B TXRQ is set in the gateway destination object
after the internal transfer from the gateway
source to the gateway destination object.
Applicable only to a gateway source object; ignored
in other nodes.

XMC4500
XMC4000 Family

IDC 9 rw Identifier Copy
0B The identifier of the gateway source object is
not copied.
1B The identifier of the gateway source object
(after storing the received frame in the source)
is copied to the gateway destination object.
in other nodes.
DLCC 10 rw Data Length Code Copy
0B Data length code is not copied.
1B Data length code of the gateway source object
is copied to the gateway destination object.
in other nodes.
DATC 11 rw Data Copy
0B Data fields are not copied.
1B Data fields in registers MODATALn and
MODATAHn of the gateway source object
are copied to the gateway destination.
in other nodes.
RXIE 16 rw Receive Interrupt Enable
RXIE enables the message receive interrupt of
message object n. This interrupt is generated after
reception of a CAN message (independent of
whether the CAN message is received directly or
indirectly via a gateway action).
0B Message receive interrupt is disabled.
1B Message receive interrupt is enabled.
Bit field MOIPRn.RXINP selects the interrupt output
line which becomes activated at this type of interrupt.

XMC4500
XMC4000 Family

TXIE 17 rw Transmit Interrupt Enable
TXIE enables the message transmit interrupt of
message object n. This interrupt is generated after
the transmission of a CAN message.
0B Message transmit interrupt is disabled.
1B Message transmit interrupt is enabled.
Bit field MOIPRn.TXINP selects the interrupt output
OVIE 18 rw Overflow Interrupt Enable
OVIE enables the FIFO full interrupt of message
object n. This interrupt is generated when the pointer
to the current message object (CUR) reaches the
value of SEL in the FIFO/Gateway Pointer Register.
0B FIFO full interrupt is disabled.
1B FIFO full interrupt is enabled.
If message object n is a Receive FIFO base object,
bit field MOIPRn.TXINP selects the interrupt output
If message object n is a Transmit FIFO base object,
bit field MOIPRn.RXINP selects the interrupt output
For all other message object modes, bit OVIE has no
effect.
FRREN 20 rw Foreign Remote Request Enable
Specifies whether the TXRQ bit is set in message
object n or in a foreign message object referenced by
the pointer CUR.
0B TXRQ of message object n is set on reception
of a matching Remote Frame.
1B TXRQ of the message object referenced by
the pointer CUR is set on reception of a
matching Remote Frame.

XMC4500
XMC4000 Family

RMM 21 rw Transmit Object Remote Monitoring
0B Remote monitoring is disabled:
Identifier, IDE bit, and DLC of message object
n remain unchanged upon the reception of a
matching Remote Frame.
1B Remote monitoring is enabled:
Identifier, IDE bit, and DLC of a matching
Remote Frame are copied to transmit object n
in order to monitor incoming Remote Frames.
Bit RMM applies only to transmit objects and has no
effect on receive objects.
SDT 22 rw Single Data Transfer
If SDT = 1 and message object n is not a FIFO base
object, then MSGVAL is reset when this object has
taken part in a successful data transfer (receive or
transmit).
If SDT = 1 and message object n is a FIFO base
object, then MSGVAL is reset when the pointer to the
current object CUR reaches the value of SEL in the
FIFO/Gateway Pointer Register.
With SDT = 0, bit MSGVAL is not affected.
STT 23 rw Single Transmit Trial
If this bit is set, then TXRQ is cleared on
transmission start of message object n. Thus, no
transmission retry is performed in case of
transmission failure.
DLC [27:24] rwh Data Length Code
Bit field determines the number of data bytes for
message object n. Valid values for DLC are 0 to 8.
A value of DLC > 8 results in a data length of 8 data
bytes.
If a frame with DLC > 8 is received, the received
value is stored in the message object.
0 [7:4], rw Reserved
[15:12], Read as 0 after reset; value last written is read back;
19 should be written with 0.

XMC4500
XMC4000 Family
MOFGPR
The Message Object FIFO/Gateway Pointer register MOFGPRn contains a set of
message object link pointers that are used for FIFO and gateway operations.
MOFGPRn (n = 0-63)
Message Object n FIFO/Gateway Pointer Register
(1004H+n*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SEL CUR
rw rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TOP BOT
rw rw

BOT [7:0] rw Bottom Pointer
Bit field BOT points to the first element in a FIFO
structure.
TOP [15:8] rw Top Pointer
Bit field TOP points to the last element in a FIFO
structure.
CUR [23:16] rwh Current Object Pointer
Bit field CUR points to the actual target object within
a FIFO/Gateway structure.
After a FIFO/gateway operation CUR is updated with
the message number of the next message object in
the list structure (given by PNEXT of the message
control register) until it reaches the FIFO top element
(given by TOP) when it is reset to the bottom element
(given by BOT).
SEL [31:24] rw Object Select Pointer
Bit field SEL is the second (software) pointer to
complement the hardware pointer CUR in the FIFO
structure. SEL is used for monitoring purposes (FIFO
interrupt generation).

XMC4500
XMC4000 Family
MOAMR
Message Object n Acceptance Mask Register MOAMRn contains the mask bits for the
acceptance filtering of the message object n.
MOAMRn (n = 0-63)
Message Object n Acceptance Mask Register
(100CH+n*20H) Reset Value: 3FFF FFFFH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MID
0 AM
E
rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
AM
rw

AM [28:0] rw Acceptance Mask for Message Identifier
Bit field AM is the 29-bit mask for filtering incoming
messages with standard identifiers (AM[28:18]) or
extended identifiers (AM[28:0]). For standard
identifiers, bits AM[17:0] are dont care.
MIDE 29 rw Acceptance Mask Bit for Message IDE Bit
0B Message object n accepts the reception of
both, standard and extended frames.
1B Message object n receives frames only with
matching IDE bit.
Read as 0 after reset; value last written is read back;
should be written with 0.

XMC4500
XMC4000 Family
MOAR
Message Object n Arbitration Register MOARn contains the CAN identifier of the
message object.
MOARn (n = 0-63)
Message Object n Arbitration Register
(1018H+n*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
PRI IDE ID
rw rwh rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ID
rwh

ID [28:0] rwh CAN Identifier of Message Object n
Identifier of a standard message (ID[28:18]) or an
extended message (ID[28:0]). For standard
identifiers, bits ID[17:0] are dont care.
IDE 29 rwh Identifier Extension Bit of Message Object n
0B Message object n handles standard frames
with 11-bit identifier.
1B Message object n handles extended frames
with 29-bit identifier.

XMC4500
XMC4000 Family

PRI [31:30] rw Priority Class
PRI assigns one of the four priority classes 0, 1, 2, 3
to message object n. A lower PRI number defines a
higher priority. Message objects with lower PRI value
always win acceptance filtering for frame reception
and transmission over message objects with higher
PRI value. Acceptance filtering based on
identifier/mask and list position is performed only
between message objects of the same priority class.
PRI also determines the acceptance filtering method
for transmission:
00B Applicable only if TTCAN is available.
01B Transmit acceptance filtering is based on the
list order. This means that message object n is
considered for transmission only if there is no
other message object with valid transmit
request (MSGVAL & TXEN0 & TXEN1 = 1)
somewhere before this object in the list.
CAN identifier. This means, message object n
is considered for transmission only if there is no
other message object with higher priority
identifier + IDE + DIR (with respect to CAN
arbitration rules) somewhere in the list (see
Table 18-12).
list order (as PRI = 01B).

XMC4500
XMC4000 Family
Transmit Priority of Msg. Objects based on CAN Arbitration Rules
Table 18-12 Transmit Priority of Msg. Objects Based on CAN Arbitration Rules
Settings of Arbitrarily Chosen Message Comment
Objects A and B,
(A has higher transmit priority than B)
A.MOAR[28:18] < B.MOAR[28:18] Messages with lower standard identifier
(11-bit standard identifier of A less than have higher priority than messages with
11-bit standard identifier of B) higher standard identifier. MOAR[28] is the
most significant bit (MSB) of the standard
identifier. MOAR[18] is the least significant
bit of the standard identifier.
A.MOAR[28:18] = B.MOAR[28:18] Standard Frames have higher transmit
A.MOAR.IDE = 0 (send Standard Frame) priority than Extended Frames with equal
B.MOAR.IDE = 1 (send Extended Frame) standard identifier.
A.MOAR[28:18] = B.MOAR[28:18] Standard Data Frames have higher
A.MOAR.IDE = B.MOAR.IDE = 0 transmit priority than standard Remote
A.MOCTR.DIR = 1 (send Data Frame) Frames with equal identifier.
B.MOCTR.DIR = 0 (send Remote Fame)
A.MOAR[28:0] = B.MOAR[28:0] Extended Data Frames have higher
A.MOAR.IDE = B.MOAR.IDE = 1 transmit priority than Extended Remote
A.MOCTR.DIR = 1 (send Data Frame) Frames with equal identifier.
B.MOCTR.DIR = 0 (send Remote Frame)
A.MOAR[28:0] < B.MOAR[28:0] Extended Frames with lower identifier have
A.MOAR.IDE = B.MOAR.IDE = 1 higher transmit priority than Extended
(29-bit identifier) Frames with higher identifier. MOAR[28] is
the most significant bit (MSB) of the overall
identifier (standard identifier MOAR[28:18]
and identifier extension MOAR[17:0]).
MOAR[0] is the least significant bit (LSB) of
the overall identifier.

XMC4500
XMC4000 Family
MODATAL
Message Object n Data Register Low MODATALn contains the lowest four data bytes of
message object n. Unused data bytes are set to zero upon reception and ignored for
transmission.
MODATALn (n = 0-63)
Message Object n Data Register Low
(1010H+n*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DB3 DB2
rwh rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DB1 DB0
rwh rwh

DB0 [7:0] rwh Data Byte 0 of Message Object n

XMC4500
XMC4000 Family
MODATAH
Message Object n Data Register High MODATAH contains the highest four data bytes
of message object n. Unused data bytes are set to zero upon reception and ignored for
transmission.
MODATAHn (n = 0-63)
Message Object n Data Register High
(1014H+n*20H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DB7 DB6
rwh rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DB5 DB4
rwh rwh


XMC4500
XMC4000 Family
18.7.4 MultiCAN Module External Registers

The registers listed in Figure 18-25 must be programmed for proper operation of the
MultiCAN module.
Clock Control Port Registers

Registers
CAN_ CLC P 0_ IO CR0 P0_P DR0

CAN_ FDR P 1_ IO CR4 P1_P DR0 / 1
P 1_ IO CR8 P2_P DR0
P 2_ IO CR4 P3_P DR0 / 1
P 3_ IO CR0
P 3_ IO CR8
P 14 _IOCR12
MCA 05865_X E 3K
Figure 18-25 CAN Implementation-specific Special Function Registers
Table 18-13 MultiCAN Module External Registers

Short Description Offset Access Description
Name Addr Mode1) see
Read Write
Module Identification Registers
ID Module Identification Register 008H U, PV U, PV Page 18-62
Clock Control Registers
CLC Clock Control Register 000H U, PV PV, E Page 18-11
5
FDR Fractional Divider Register 00CH U, PV PV, E Page 18-11
6
1) Accesses to empty addresses: nBE

XMC4500
XMC4000 Family
CAN_CLC
The clock control registers makes it possible to control (enable/disable) the module
control clock fCLC.
CAN_CLC
CAN Clock Control Register (000H) Reset Value: 0000 0003H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SB E DIS DIS
0 0 0
WE DIS S R
r r w rw r r rw

DISS 1 r Module Disable Status Bit
Bit indicates the current status of the module.
EDIS 3 rw Sleep Mode Enable Control
Used to control modules sleep mode.
SBWE 4 w Module Suspend Bit Write Enable for OCDS
Determines whether SPEN and FSOE are write-
protected.
0 2, 5, r Reserved
Note: In disabled state, no registers of CAN module can be read or written except the
CAN_CLC register.

XMC4500
XMC4000 Family
CAN_FDR
The fractional divider register allows the programmer to control the clock rate of the
module timer clock fCAN.
CAN_FDR
CAN Fractional Divider Register (00CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DIS EN SUS SUS
0 RESULT
CLK HW REQ ACK
rwh rw rh rh r rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DM SC SM 0 STEP
rw rw rw r rw

STEP [9:0] rw Step Value
Reload or addition value for RESULT.
SM 11 rw Suspend Mode
SM selects between granted or immediate Suspend
Mode.
SC [13:12] rw Suspend Control
This bit field determines the behavior of the fractional
divider in Suspend Mode.
DM [15:14] rw Divider Mode
This bit field selects normal divider mode, fractional
divider mode, and off-state.
RESULT [25:16] rh Result Value
Bit field for the addition result.
SUSACK 28 rh Suspend Mode Acknowledge
Indicates state of SPNDACK signal.
SUSREQ 29 rh Suspend Mode Request
Indicates state of SPND signal.
ENHW 30 rw Enable Hardware Clock Control
Controls operation of ECEN input and DISCLK bit.

XMC4500
XMC4000 Family

DISCLK 31 rwh Disable Clock
Hardware controlled disable for fOUT signal.
0 10, r Reserved

XMC4500
XMC4000 Family
MultiCAN Module Register Address Map

The complete MultiCAN module register address map of Figure 18-26 shows the
general implementation-specific registers for clock control, module identification, and
interrupt service request control and adds the absolute address information.

XMC4500
XMC4000 Family
MO = Message Object;
n = 0 to (Number of Message Objects -1)
3FFFH
MOBASE = 1000H + n * 20H
MO n Control Register MO BASE + 1CH
MO BASE + 20H MO n Arbitration Reg. MO BASE + 18H
MO BASE Message Object n-1 MO n Data Register High MO BASE + 14H
MO n Data Register Low MO BASE + 10H
. .
. . MO n Accept. Mask Reg. MO BASE + 0CH
. .
. Message Object . MO n Interrupt Ptr . Reg. MO BASE + 08H
. Registers .
. . MO n FIFO/Gtw. Ptr. Reg. MO BASE + 04H
1040H . .
. . MO n Function Control Reg. MO BASE + 00H
1020H Message Object 1
1000H Message Object 0 NO = CAN Node,
x = 0 to (Number of CAN Nodes -1)
NOBASE = 200 H + x * 100H
Node x Frame Counter Reg. NO BASE + 18H

Node x Error Counter Reg . NO BASE + 14H
Node x Registers Node x Bit Timing Reg. NO BASE + 10H
NOBASE
Node x Port Control Reg . NO BASE + 0CH
Node x Interrupt Ptr . Reg. NO BASE + 08H
Node x Status Registers NO BASE + 04H
300H Node 1 Registers
Node x Control Registers NO BASE + 00H
i = 0-7, k = 0-7
Node 0 Registers Module Interrupt Trg. Reg. + CCH

200H
Module Control Register + C8H
Panel Control Register + C4H
Msg. Index Mask Register + C0H
Msg. Index Registers k + 80H
Global Msg. Pending Registers k + 40H
Module
Control List Registers i + 00H
100H
General
Module Fractional Divider Register + 0CH
Control Module Identification Reg. + 08H
000H Clock Control Register + 00H
mca 06285_n_ver2
Figure 18-26 MultiCAN Module Register Map

XMC4500
XMC4000 Family
18.8 Interconnects
This section describes CAN module interfaces with the clock control, port connections,
and address decoding.
18.8.1 Interfaces of the MultiCAN Module

Figure 18-27 shows the XMC4500 specific implementation details and interconnections
of the MultiCAN module. The six I/O lines of the MultiCAN module (two I/O lines of each
CAN node) are connected to I/O lines of Port 0,1,2,3,4 and 14. The MultiCAN module is
also supplied by clock control, interrupt control, and address decoding logic. MultiCAN
interrupts can be directed to the GPDMA controller and the CCU4 modules. CAN
interrupts are able to trigger DMA transfers and CCU4 operations.
MultiCAN Module Kernel

A2 P1.9 / TXDC2
fCAN
Clock TXDC2 Port 1, A1+ P3.7, P4.7 / TXDC2
fCLC CAN
Control 3, 4
Node 2 P3.8, P4.6 /
RXDC2 Control A1+
RXDC2B, 2C
Address A2 P1.8 / RXDC2A
Decoder
Message P1.5, P2.7, P3.9 /

A1+
Object TXDC1
Linked
Buffer TXDC1 A2 P1.12 / TXDC1
List CAN Port 1,
Control Node 1 2, 3
DLR INT_O 64
(DMA Line
RXDC1 Control A2 P1.13 / RXDC1C
[3:0] Objects
Router)
A1+
P2.6, P3.11, P1.4 /
RXDC1A, 1B, 1D
INT_O P0.0, P3.10, P1.4 /
CCU4 A1+
[7] TXDC0
A2 P3.2 / TXDC0
TXDC0 Port 0,
CAN
Interrupt INT_O 1, 3, 14 A2 P3.12 / RXDC0C
Node 0
Control [7:0] RXDC0 Control
1
AN P14.3 / RXDC0B
CAN Control A1+ P1.5 / RXDC0A
Note:
1) AN refers to AN/DIG_IN pad type.
mca 06281_3n_noTTCAN_64_MO _x.vsd
Figure 18-27 CAN module Implementation and Interconnections

XMC4500
XMC4000 Family
18.8.2 Port and I/O Line Control

The interconnections between the MultiCAN module and the port I/O lines are controlled
in the port logic. Additionally to the port input selection, the following port control
operations must be executed:
Input/output function selection (IOCR registers)
Pad driver characteristics selection for the outputs (PDR registers)
18.8.2.1 Input/Output Function Selection in Ports

The port input/output control registers contain the bit fields that select the digital output
and input driver characteristics such as pull-up/down devices, port direction
(input/output), open-drain, and alternate output selections. The I/O lines for the MultiCAN
module are controlled by the port input/output control registers Pn_IOCRy PCx defined
in the GPIO chapter.
Additionally to the I/O control selection, as defined in Table 18-14, the selection of a
CAN nodes receive input line requires that bit field RXSEL in its node port control
register NPCRx must be set.
The selected input signal (selected by bit field NPCRx.RXSEL) for each CAN node is
made available by internal signal CANxINS (CAN node x input signal, with x = 0 - 2) as
shown in Figure 18-28. The default setting after reset of a nodes NPCRx.RXSEL bit
field connect node x with RXDCx I/O line (x = 0-2).
RXDCxA
RXDCxB
CAN .
Node x .
.
RXDCxH
CANxINS
NPCRx.RXSEL
rx_selection.vsd
Figure 18-28 CAN Module Receive Input Selection

XMC4500
XMC4000 Family
Table 18-14 shows how bits and bit fields must be programmed for the required I/O
functionality of the CAN I/O lines.
Table 18-14 MultiCAN I/O Control Selection and Setup

Receive Inputs (Node 0)
CAN.CAN0_RXDC0A I P1.5 CAN Receive Input
CAN.CAN0_RXDC0B I P14.3 CAN Receive Input
CAN.CAN0_RXDC0C I P3.12 CAN Receive Input
CAN.CAN1_RXDC1D I P1.4 CAN Receive Input
CAN.CAN1_RXDC1F I CAN0INS CAN Receive Input
CAN.CAN2_RXDC2F I CAN1INS CAN Receive Input
Transmit Outputs (Node 0)
CAN.CAN0_TXDC0 O P0.0 CAN Transmit Output
O P1.4 CAN Transmit Output

XMC4500
XMC4000 Family
Table 18-14 MultiCAN I/O Control Selection and Setup (contd)

18.8.2.2 MultiCAN Interrupt Output Connections

The interrupt outputs of the MultiCAN module are connected as shown in Table 18-15.
Table 18-15 CAN Interrupt Output Connections

SR0 O NVIC Interrrupt Request
O DLR DMA Request
SR1 O CPU CAN Interrrupt Output
O DLR DMA Request
O DLR DMA Request
O DLR DMA Request
O CCU4 CCU4 Trigger
18.8.2.3 Connections to USIC Inputs

The internal signal CAN1INS is connected to the USIC module, see Table 18-16.
Table 18-16 CAN-to-USIC Connections

CAN.CAN1INS O U1C1_DX0E CAN Receive Multiplexer Output
O U2C2_DX0E CAN Receive Multiplexer Output

XMC4500
XMC4000 Family

XMC4500
XMC4000 Family
Versatile Analog-to-Digital Converter (VADC)
19 Versatile Analog-to-Digital Converter (VADC)

The XMC4500 provides a series of analog input channels connected to a cluster of
Analog/Digital Converters using the Successive Approximation Register (SAR) principle
to convert analog input values (voltages) to discrete digital values.
The number of analog input channels and ADCs depends on the chosen product type
(please refer to Product-Specific Configuration on Page 19-127).
Table 19-1 Abbreviations used in ADC chapter

ADC Analog to Digital Converter
DMA Direct Memory Access (controller)
DNL Differential Non-Linearity (error)
INL Integral Non-Linearity (error)
LSBn Least Significant Bit: finest granularity of the analog value in digital
format, represented by one least significant bit of the conversion result
with n bits resolution (measurement range divided in 2n equally
distributed steps)
SCU System Control Unit of the device
TUE Total Unadjusted Error
19.1 Overview
Each converter of the ADC cluster can operate independent of the others, controlled by
a dedicated set of registers and triggered by a dedicated group request source. The
results of each channel can be stored in a dedicated channel-specific result register or
in a group-specific result register.
A background request source can access all analog input channels that are not assigned
to any group request source. These conversions are executed with low priority. The
background request source can, therefore, be regarded as an additional background
converter.
The Versatile Analog to Digital Converter module (VADC) of the XMC4500 comprises a
set of converter blocks that can be operated either independently or via a common
request source that emulates a background converter. Each converter block is equipped
with a dedicated input multiplexer and dedicated request sources, which together build
separate groups.
This basic structure supports application-oriented programming and operating while still
providing general access to all resources. The almost identical converter groups allow a
flexible assignment of functions to channels.

VADC, V1.4M Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
The basic module clock fADC is connected to the system clock signal fPB.
Feature List
The following features describe the functionality of the ADC cluster:
Nominal analog supply voltage 3.3 V
Input voltage range from 0 V up to analog supply voltage
Standard (VAREF) and alternate (CH0) reference voltage source selectable for each
channel to support ratiometric measurements and different signal scales
Up to 4 independent converters with up to 8 analog input channels
External analog multiplexer control, including adjusted sample time and scan support
Conversion speed and sample time adjustable to adapt to sensors and reference
Conversion time below 1 s (depending on result width and sample time)
Flexible source selection and arbitration
Programmable arbitrary conversion sequence (single or repeated)
Configurable auto scan conversion (single or repeated) on each converter
Configurable auto scan conversion (single or repeated) in the background (all
converters)
Conversions triggered by software, timer events, or external events
Cancel-inject-restart mode for reduced conversion delay on priority channels
Powerful result handling
Selectable result width of 8/10/12 bits
Fast Compare Mode
Independent result registers
Configurable limit checking against programmable border values
Data rate reduction through adding a selectable number of conversion results
FIR/IIR filter with selectable coefficients
Flexible service request generation based on selectable events
Built-in safety features
Broken wire detection with programmable default levels
Multiplexer test mode to verify signal path integrity
Support of suspend and power saving modes
Note: Additional functions are available from the out of range comparator (see
description in the SCU).

XMC4500
XMC4000 Family
Table 19-2 VADC Applications

Use Case VADC Application
Automatic scheduling of complex conversion sequences, Motor control,
including priorization of time-critical conversions Power
conversion
Effective result handling for bursts of high-speed conversions Highly dynamic
input signals
Synchronous sampling of up to 4 input signals Multi-phase
current
measurement
Conv.Group/Kernel Conv.Group/Kernel
Result Result Result

Registers Registers Register
Result Result
Validation Validation
Group Group Background

Source Source Source
Converter Converter
... Clock Control
Service Req.
Generation
... ...
Figure 19-1 ADC Structure Overview

XMC4500
XMC4000 Family
19.2 Introduction and Basic Structure

The Versatile Analog to Digital Converter module (VADC) of the XMC4500 comprises a
set of converter blocks that can be operated either independently or via a common
request source that emulates a background converter. Each converter block is equipped
with a dedicated input multiplexer and dedicated request sources, which together build
separate groups.
This basic structure supports application-oriented programming and operating while still
providing general access to all resources. The almost identical converter groups allow a
flexible assignment of functions to channels.
A set of functional units can be configured according to the requirements of a given
application. These units build a path from the input signals to the digital results.
Analog reference ADC Kernel

voltage VAREF
Analog reference Interrupt
ground VAGND generation
Analog input Result

...
...
AD converter
channels CHx handling
Conversion Request
Ext. multiplexer
control control
control MUX[2:0]
MC_ ADC_KERNEL
Figure 19-2 ADC Kernel Block Diagram

XMC4500
XMC4000 Family
Conversion Modes and Request Sources

Analog/Digital conversions can be requested by several request sources (2 group
request sources and the background request source) and can be executed in several
conversion modes. The request sources can be enabled concurrently with configurable
priorities.
Fixed Channel Conversion (single or continuous)
A specific channel source requests conversions of one selectable channel (once or
repeatedly)
Auto Scan Conversion (single or continuous)
A channel scan source (request source 1 or 2) requests auto scan conversions of a
configurable linear sequence of all available channels (once or repeatedly)
Channel Sequence Conversion (single or continuous)
A queued source (request source 0) requests a sequence of conversions of up to 8
arbitrarily selectable channels (once or repeatedly)
The conversion modes can be used concurrently by the available request sources, i.e.
conversions in different modes can be enabled at the same time. Each source can be
enabled separately and can be triggered by external events, such as edges of PWM or
timer signals, or pin transitions.
Request Source Control

Because all request sources can be enabled at the same time, an arbiter resolves
concurrent conversion requests from different sources. Each source can be triggered by
external signals, by on-chip signals, or by software.
Requests with higher priority can either cancel a running lower-priority conversion
(cancel-inject-repeat mode) or be converted immediately after the currently running
conversion (wait-for-start mode). If the target result register has not been read, a
conversion can be deferred (wait-for-read mode).
Certain channels can also be synchronized with other ADC kernels, so several signals
can be converted in parallel.

XMC4500
XMC4000 Family
Background
Source (2)
(channel scan )
ADC Kernel
Request Control
Timer
Unit(s)
Request Request
Analog
Source 1 Source
Converter
(channel scan ) Arbiter
External
Request(s)
Request
Source 0
(8-stage queue )
MC_VADC_CONV_REQUEST_UNIT
Figure 19-3 Conversion Request Unit
Input Channel Selection

The analog input multiplexer selects one of the available analog inputs (CH0 - CHx1)) to
be converted. Three sources can select a linear sequence, an arbitrary sequence, or a
specific channel. The priorities of these sources can be configured.
Additional external analog multiplexers can be controlled automatically, if more separate
input channels are required than are built in.
Note: Not all analog input channels are necessarily available in all packages, due to pin
limitations. Please refer to the implementation description in Section 19.14.
Conversion Control
Conversion parameters, such as sample phase duration, reference voltage, or result
resolution can be configured for 4 input classes (2 group-specific classes, 2 global
classes). Each channel can be individually assigned to one of these input classes.
The input channels can, thus, be adjusted to the type of sensor (or other analog sources)
connected to the ADC.
1) The availablity of input channels depends on the package of the used product type. A summary can be found
in Section 19.14.2.

XMC4500
XMC4000 Family
This unit also controls the built-in multiplexer and external analog multiplexers, if
selected.
Analog/Digital Converter
The selected input channel is converted to a digital value by first sampling the voltage
on the selected input and then generating the selected number of result bits.
For 12-bit conversions, post-calibration is executed after converting the channel.
For broken wire detection (see Section 19.10.1), the converter network can be
preloaded before sampling the selected input channel.
Result Handling
The conversion results of each analog input channel can be directed to one of 16 group-
specific result registers and one global result register to be stored there. A result register
can be used by a group of channels or by a single channel.
The wait-for-read mode avoids data loss due to result overwrite by blocking a conversion
until the previous result has been read.
Data reduction (e.g. for digital anti-aliasing filtering) can automatically add up to 4
conversion results before issuing a service request.
Alternatively, an FIR or IIR filter can be enabled that preprocesses the conversion results
before sending them to the result register.
Also, result registers can be concatenated to build FIFO structures that store a number
of conversion results without overwriting previous data. This increases the allowed CPU
latency for retrieving conversion data from the ADC.
Service Request Generation

Several ADC events can issue service requests to CPU or DMA:
Source events indicate the completion of a conversion sequence in the
corresponding request source. This event can be used to trigger the setup of a new
sequence.
Channel events indicate the completion of a conversion for a certain channel. This
can be combined with limit checking, so interrupt are generated only if the result is
within a defined range of values.
Result events indicate the availability of new result data in the corresponding result
register. If data reduction mode is active, events are generated only after a complete
accumulation sequence.
Each event can be assigned to one of eight service request nodes. This allows grouping
the requests according to the requirements of the application.

XMC4500
XMC4000 Family
Safety Features
Safety-aware applications are supported with mechanisms that help to ensure the
integrity of a signal path.
Broken-wire-detection (BWD) preloads the converter network with a selectable level
before sampling the input channel. The result will then reflect the preload value if the
input signal is no more connected. If buffer capacitors are used, a certain number of
conversions may be required to reach the failure indication level.
Pull Down Diagnostics (PDD) connects an additional strong pull-down device to an
input channel. A subsequent conversion can then confirm the expected modified signal
level. This allows to check the proper connection of a signal source (sensor) to the
multiplexer.
Multiplexer Diagnostics (MD) connects a weak pull-up or pull-down device to an input
channel. A subsequent conversion can then confirm the expected modified signal level.
This allows to check the proper operation of the multiplexer.
Converter Diagnostics (CD) connects an alternate signal to the converter. A
subsequent conversion can then confirm the proper operation of the converter.

XMC4500
XMC4000 Family
19.3 Configuration of General Functions

While many parameters can be selected individually for each channel, source, or group,
some adjustments are valid for the whole ADC cluster:
Clock control
Kernel synchronization
External multiplexer control
Test functions
19.3.1 General Clocking Scheme and Control

The A/D Converters of the XMC4500 are supplied with a global clock signal from the
system fADC. Two clock signals are derived from this input and are distributed to all
converters. The global configuration register defines common clock bases for all
converters of the cluster. This ensures deterministic behavior of converters that shall
operate in parallel.
The analog converter clock fADCI determines the performance of the converters and must
be selected to comply with the specification given in the Data Sheet.
Clock Generation
Unit
ADC Kernel Module Clock f ADC
DIVD DIVA
Digital Analog
Clock Clock
fADCD fADCI
State Mach.,
Service Arbiter Converter
Requests
MC_ VADC_CLOCKS
Figure 19-4 Clock Signal Summary

XMC4500
XMC4000 Family
19.3.2 Priority Channel Assignment

Each channel of a group can be assigned to this groups request sources and is then
regarded as a priority channel. An assigned priority channel can only be converted by its
own groups request sources. A not assigned channel can also be converted by the
background request source.
19.4 Module Activation and Power Saving

The analog converter of the ADC draws a permanent current during its operation. It can
be deactivated between conversions to reduce the consumed overall energy.
The operating mode is determined by bitfield GxARBCFG (x = 0 - 3).ANONS:
ANONS = 11B: Normal Operation
The converter is active, conversions are started immediately.
Requires no wakeup time.
ANONS = 10B or 01B: Reserved
ANONS = 00B: Converter switched Off (default after reset)
The converter is switched off. Furthermore, digital logic blocks are set to their initial
state. If the arbiter is currently running, it completes the actual arbitration round and
then stops.
Before starting a conversion, select the active mode for ANONS.
Requires the wakeup time (see below).
Wakeup Time from Analog Powerdown

When the converter is activated, it needs a certain wakeup time to settle before a
conversion can be properly executed. This wakeup time can be established by waiting
the required period before starting a conversion, or by adding it to the intended sample
time.
The wakeup time is approximately 15 s.
Exact numbers can be found in the respective Data Sheets.
Note: The wakeup time is also required after initially enabling the converter.
Calibration
Calibration automatically compensates deviations caused by process, temperature, and
voltage variations. This ensures precise results throughout the operation time.
An initial start-up calibration is required once after a reset for all calibrated converters
and is triggered globally. All calibrated converters must be enabled (ANONS = 11B)
before initiating the start-up calibration. Conversions may be started after the initial
calibration sequence. This is indicated by bit CAL = 0B.
After that, postcalibration cycles will compensate the effects of drifting parameters.

XMC4500
XMC4000 Family
19.5 Conversion Request Generation

The conversion request unit of a group autonomously handles the generation of
conversion requests. Three request sources (2 group-specific sources and the
background source) can generate requests for the conversion of an analog channel. The
arbiter resolves concurrent requests and selects the channel to be converted next.
Upon a trigger event, the request source requests the conversion of a certain analog
input channel or a sequence of channels.
Software triggers
directly activate the respective request source.
External triggers
synchronize the request source activation with external events, such as a trigger
pulse from a timer generating a PWM signal or from a port pin.
Application software selects the trigger, the channel(s) to be converted, and the request
source priority. A request source can also be activated directly by software without
requiring an external trigger.
The arbiter regularly scans the request sources for pending conversion requests and
selects the conversion request with the highest priority. This conversion request is then
forwarded to the converter to start the conversion of the requested channel.
Each request source can operate in single-shot or in continuous mode:
In single-shot mode,
the programmed conversion (sequence) is requested once after being triggered. A
subsequent conversion (sequence) must be triggered again.
In continuous mode,
the programmed conversion (sequence) is automatically requested repeatedly after
being triggered once.
For each request source, external triggers are generated from one of 16 selectable
trigger inputs (REQTRx[P:A]) and from one of 16 selectable gating inputs
(REQGTx[P:A]). The available trigger signals for the XMC4500 are listed in
Section 19.14.3.
Note: Figure 19-3 Conversion Request Unit on Page 19-6 summarizes the request
sources.

XMC4500
XMC4000 Family
Two types of requests sources are available:

A queued source can issue conversion requests for an arbitrary sequence of input
channels. The channel numbers for this sequence can be freely programmed1). This
supports application-specific conversion sequences that cannot be covered by a
channel scan source. Also, multiple conversions of the same channel within a
sequence are supported.
A queued source converts a series of input channels permanently or on a regular
time base. For example, if programmed with medium priority, some input channels
can be converted upon a specified event (e.g. synchronized to a PWM). Conversions
of lower priority sources are suspended in the meantime.
Request source 0 is a group-specific 8-stage queued source.
A channel scan source can issue conversion requests for a coherent sequence of
input channels. This sequence begins with the highest enabled channel number and
continues towards lower channel numbers. All available channels1) can be enabled
for the scan sequence. Each channel is converted once per sequence.
A scan source converts a series of input channels permanently or on a regular time
base. For example, if programmed with low priority, some input channels can be
scanned in a background task to update information that is not time-critical.
Request source 1 is a group-specific channel scan source.
Request source 2 is a global channel scan source (background source).
The background source can request all channels of all groups.
1) The availablity of input channels depends on the package of the used product type. A summary can be found
in Section 19.14.2.
The background source can only request non-priority channels, i.e. channels that are not selected in registers
GxCHASS. Priority channels are reserved for the group-specific request sources 0 and 1.

XMC4500
XMC4000 Family
19.5.1 Queued Request Source Handling

A queued request source supports short conversion sequences (up to 8) of arbitrary
channels (contrary to a scan request source with a fixed conversion order for the enabled
channels). The programmed sequence is stored in a queue buffer (based on a FIFO
mechanism). The requested channel numbers are entered via the queue input, while
queue stage 0 defines the channel to be converted next.
A conversion request is only issued to the request source arbiter if a valid entry is stored
in queue stage 0.
If the arbiter aborts a conversion triggered by a queued request source due to higher
priority requests, the corresponding conversion parameters are automatically saved in
the backup stage. This ensures that an aborted conversion is not lost but takes part in
the next arbitration round (before stage 0).
The trigger and gating unit generates trigger events from the selected external (outside
the ADC) trigger and gating signals. For example, a timer unit can issue a request signal
to synchronize conversions to PWM events.
Trigger events start a queued sequence and can be generated either via software or via
the selected hardware triggers. The occurrence of a trigger event is indicated by bit
QSRx.EV. This flag is cleared when the corresponding conversion is started or by writing
to bit QMRx.CEV.
refill
trigger inputs queue input
REQTRx
REQTRx[H:A]
trigger & intermediate

gating unit queue stages
E queue stage 0
gating inputs V
REQGTx[H:A] REQGTx
wait for
trigger request request
request source
request handling status source
event
arbiter
abort restart
backup stage
sequential
request source x ADC_seq_reqsrc
Figure 19-5 Queued Request Source

XMC4500
XMC4000 Family
A sequence is defined by entering conversion requests into the queue input register
(GxQINR0 (x = 0 - 3)). Each entry selects the channel to be converted and can enable
an external trigger, generation of an interrupt, and an automatic refill (i.e. copy this entry
to the top of the queue after conversion). The entries are stored in the queue buffer
stages.
The content of stage 0 (GxQ0R0 (x = 0 - 3)) selects the channel to be converted next.
When the requested conversion is started, the contents of this queue stage is invalidated
and copied to the backup stage. Then the next queue entry can be handled (if available).
Note: The contents of the queue stages cannot be modified directly, but only by writing
to the queue input or by flushing the queue.
The current status of the queue is shown in register GxQSR0 (x = 0 - 3).
If all queue entries have automatic refill selected, the defined conversion
sequence can be repeated without re-programming.
Properties of the Queued Request Source

Queued request source 0 provides 8 buffer stages and can handle sequences of up to
8 input channel entries. It supports short application-specific conversion sequences,
especially for timing-critical sequences containing also multiple conversions of the same
channel.
Queued Source Operation

Configure the queued request source by executing the following actions:
Define the sequence by writing the entries to the queue input GxQINR0 (x = 0 - 3).
Initialize the complete sequence before enabling the request source, because with
enabled refill feature, software writes to QINRx are not allowed.
If hardware trigger or gating is desired, select the appropriate trigger and gating
inputs and the proper transitions by programming GxQCTRL0 (x = 0 - 3).
Enable the trigger and select the gating mode by programming bitfield ENGT in
register GxQMR0 (x = 0 - 3).1)
Enable the corresponding arbitration slot (0) to accept conversion requests from the
queued source (see register GxARBPR (x = 0 - 3)).
Start a queued sequence by generating a trigger event:
If a hardware trigger is selected and enabled, generate the configured transition at
the selected input signal, e.g. from a timer or an input pin.
Generate a software trigger event by setting GxQMR0.TREV = 1.
1) If PDOUT signals from the ERU are used, initialize the ERU accordingly before enabling the gate inputs to
avoid un expected signal transitions.

XMC4500
XMC4000 Family
Write a new entry to the queue input of an empty queue. This leads to a (new) valid
queue entry that is forwarded to queue stage 0 and starts a conversion request (if
enabled by GxQMR0.ENGT and without waiting for an external trigger).
Note: If the refill mechanism is activated, a processed entry is automatically reloaded
into the queue. This permanently repeats the respective sequence (autoscan).
In this case, do not write to the queue input while the queued source is running.
Write operations to a completely filled queue are ignored.
Stop or abort an ongoing queued sequence by executing the following actions:
If external gating is enabled, switch the gating signal to the defined inactive level. This
does not modify the queue entries, but only prevents issuing conversion requests to
the arbiter.
Disable the corresponding arbitration slot (0) in the arbiter. This does not modify the
queue entries, but only prevents the arbiter from accepting requests from the request
handling block.
Disable the queued source by clearing bitfield ENGT = 00B.
Invalidate the next pending queue entry by setting bit GxQMR0.CLRV = 1.
If the backup stage contains a valid entry, this one is invalidated, otherwise stage 0
is invalidated.
Remove all entries from the queue by setting bit GxQMR0.FLUSH = 1.
Queue Request Source Events and Service Requests

A request source event of a queued source occurs when a conversion is finished. A
source event service request can be generated based on a request source event
according to the structure shown in Figure 19-6. If a request source event is detected, it
sets the corresponding indication flag in register GxSEFLAG (x = 0 - 3). These flags can
also be set by writing a 1 to the corresponding bit position, whereas writing 0 has no
effect. The indication flags can be cleared by SW by writing a 1 to the corresponding bit
position in register GxSEFCLR (x = 0 - 3).
The interrupt enable bit is taken from stage 0 for a normal sequential conversion, or from
the backup stage for a repeated conversion after an abort.
The service request output line SRx that is selected by the request source event interrupt
node pointer bitfields in register GxSEVNP (x = 0 - 3) becomes activated each time the
related request source event is detected (and enabled by GxQ0R0.ENSI, or
GxQBUR0.ENSI respectively) or the related bit position in register GxSEFLAG (x = 0 -
3) is written with a 1 (this write action simulates a request source event).

XMC4500
XMC4000 Family
request source request source request source

event event event
indication flag interrupt enable node pointer
GxSEFLAG. GxQ0R0. GxSEVNP.
SEV0 ENSI SEV0NP
set
conversion
finished request source
GxSR0
event
triggered by 0 :
request GxSR3
source CySR0
1 :
CySR3
GxQBUR0. GxQBUR0.
ENSI V
MC_VADC_REQSRCQ_INT
Figure 19-6 Interrupt Generation of a Queued Request Source
19.5.2 Channel Scan Request Source Handling

The VADC provides two types of channel scan sources:
Source 1: Group scan source
This scan source can request all channels of the corresponding group.
Source 2: Background scan source
This scan source can request all channels of all groups.
Priority channels selected in registers GxCHASS (x = 0 - 3) cannot take part in
background conversion sequences.
Both sources operate in the same way and provide the same register interface. The
background source provides more request/pending bits because it can request all
channels of all groups.
Each analog input channel can be included in or excluded from the scan sequence by
setting or clearing the corresponding channel select bit in register GxASSEL (x = 0 - 3)
or BRSSELx (x = 0 - 3). The programmed register value remains unchanged by an
ongoing scan sequence. The scan sequence starts with the highest enabled channel
number and continues towards lower channel numbers.
Upon a load event, the request pattern is transferred to the pending bits in register
GxASPND (x = 0 - 3) or BRSPNDx (x = 0 - 3). The pending conversion requests indicate

XMC4500
XMC4000 Family
which input channels are to be converted in an ongoing scan sequence. Each

conversion start that was triggered by the scan request source, automatically clears the
corresponding pending bit. If the last conversion triggered by the scan source is finished
and all pending bits are cleared, the current scan sequence is considered finished and
a request source event is generated.
A conversion request is only issued to the request source arbiter if at least one pending
bit is set.
If the arbiter aborts a conversion triggered by the scan request source due to higher
priority requests, the corresponding pending bit is automatically set. This ensures that
an aborted conversion is not lost but takes part in the next arbitration round.
The trigger and gating unit generates load events from the selected external (outside the
ADC) trigger and gating signals. For example, a timer unit can issue a request signal to
synchronize conversions to PWM events.
Load events start a scan sequence and can be generated either via software or via the
selected hardware triggers. The request source event can also generate an automatic
load event, so the programmed sequence is automatically repeated.
Conversion
Ext. Trigger
Internal MUX
Request
Signals
Trigger Sequence
Gener- Control
ation Service
Request
Sequence
Internal MUX
Ext. Gate
Pending
Signals
Sequence
Select
MC_VADC_REQSRCS
Figure 19-7 Scan Request Source

XMC4500
XMC4000 Family
Scan Source Operation

Configure the scan request source by executing the following actions:
Select the input channels for the sequence by programming GxASSEL (x = 0 - 3) or
BRSSELx (x = 0 - 3)
If hardware trigger or gating is desired, select the appropriate trigger and gating
inputs and the proper signal transitions by programming GxASCTRL (x = 0 - 3) or
BRSCTRL. Enable the trigger and select the gating mode by programming GxASMR
(x = 0 - 3) or BRSMR.1)
Define the load event operation (handling of pending bits, autoscan mode) by
programming GxASMR (x = 0 - 3) or BRSMR.
A load event with bit LDM = 0 copies the content of GxASSEL (x = 0 - 3) or
BRSSELx (x = 0 - 3) to GxASPND (x = 0 - 3) or BRSPNDx (x = 0 - 3) (overwrite
mode). This starts a new scan sequence and aborts any pending conversions from
a previous scan sequence.
A load event with bit LDM = 1 OR-combines the content of GxASSEL (x = 0 - 3) or
BRSSELx (x = 0 - 3) to GxASPND (x = 0 - 3) or BRSPNDx (x = 0 - 3) (combine
mode). This starts a scan sequence that includes pending conversions from a prvious
scan sequence.
Enable the corresponding arbitration slot (1) to accept conversion requests from the
channel scan source (see register GxARBPR (x = 0 - 3)).
Start a channel scan sequence by generating a load event:
If a hardware trigger is selected and enabled, generate the configured transition at
the selected input signal, e.g. from a timer or an input pin.
Generate a software load event by setting LDEV = 1 (GxASMR (x = 0 - 3) or
BRSMR).
Generate a load event by writing the scan pattern directly to the pending bits in
GxASPND (x = 0 - 3) or BRSPNDx (x = 0 - 3). The pattern is copied to GxASSEL (x
= 0 - 3) or BRSSELx (x = 0 - 3) and a load event is generated automatically.
In this case, a scan sequence can be defined and started with a single data write
action, e.g. under PEC control (provided that the pattern fits into one register).
Note: If autoscan is enabled, a load event is generated automatically each time a
request source event occurs when the scan sequence has finished. This
permanently repeats the defined scan sequence (autoscan).
Stop or abort an ongoing scan sequence by executing the following actions:
If external gating is enabled, switch the gating signal to the defined inactive level. This
does not modify the conversion pending bits, but only prevents issuing conversion
requests to the arbiter.
1) If PDOUT signals from the ERU are used, initialize the ERU accordingly before enabling the gate inputs to
avoid un expected signal transitions.

XMC4500
XMC4000 Family
Disable the corresponding arbitration slot (1 or 2) in the arbiter. This does not modify
the contents of the conversion pending bits, but only prevents the arbiter from
accepting requests from the request handling block.
Disable the channel scan source by clearing bitfield ENGT = 00B. Clear the pending
request bits by setting bit CLRPND = 1 (GxASMR (x = 0 - 3) or BRSMR).
Scan Request Source Events and Service Requests

A request source event of a scan source occurs if the last conversion of a scan sequence
is finished (all pending bits = 0). A request source event interrupt can be generated
based on a request source event. If a request source event is detected, it sets the
corresponding indication flag in register GxSEFLAG (x = 0 - 3). These flags can also be
set by writing a 1 to the corresponding bit position, whereas writing 0 has no effect.
The service request output SRx that is selected by the request source event interrupt
node pointer bitfields in register GxSEVNP (x = 0 - 3) becomes activated each time the
related request source event is detected (and enabled by ENSI) or the related bit position
in register GxSEFLAG (x = 0 - 3) is written with a 1 (this write action simulates a request
source event).
The indication flags can be cleared by SW by writing a 1 to the corresponding bit position
in register GxSEFCLR (x = 0 - 3).1)
1) Please refer to Service Request Generation on Page 19-55.

XMC4500
XMC4000 Family
19.6 Request Source Arbitration

The request source arbiter regularly polls the request sources, one after the other, for
pending conversion requests. Each request source is assigned to a certain time slot
within an arbitration round, called arbitration slot. The duration of an arbitration slot is
user-configurable via register GLOBCFG.
The priority of each request source is user-configurable via register GxARBPR (x = 0 -
3), so the arbiter can select the next channel to be converted, in the case of concurrent
requests from multiple sources, according to the application requirements.
An unused arbitration slot is considered empty and does not take part in the arbitration.
After reset, all slots are disabled and must be enabled (register GxARBPR (x = 0 - 3))
to take part in the arbitration process.
Figure 19-8 summarizes the arbitration sequence. An arbitration round consists of one
arbitration slot for each available request source. The synchronization source is always
evaluated in the last slot and has a higher priority than all other sources. At the end of
each arbitration round, the arbiter has determined the highest priority conversion
request.
If a conversion is started in an arbitration round, this arbitration round does not deliver
an arbitration winner. In the XMC4500, the following request sources are available:
Arbitration slot 0: Group Queued source, 8-stage sequences in arbitrary order
Arbitration slot 1: Group Scan source, sequences in defined order within group
Arbitration slot 2: Background Scan source, sequences in defined order, all groups
Last arbitration slot: Synchronization source, synchronized conversion requests
from another ADC kernel (always handled with the highest priority in a
synchronization slave kernel).
arbitration round
arbitration
winner
arbitration arbitration arbitration arbitration found
slot 0 slot 1 slot 2 slot 3
polling of polling of polling of check for conversion

request request request synchronized can be
source 0 source 1 source 2 start request started
ADC_arbiter_round
Figure 19-8 Arbitration Round with 4 Arbitration Slots

XMC4500
XMC4000 Family
19.6.1 Arbiter Operation and Configuration

The timing of the arbiter (i.e. of an arbitration round) is determined by the number of
arbitration slots within an arbitration round and by the duration of an arbitration slot.
An arbitration round consist of 420 arbitration slots (defined by bitfield GxARBCFG (x
= 0 - 3).ARBRND). 4 slots are sufficient for the XMC4500, more can be programmed to
obtain the same arbiter timing for different products.
The duration of an arbitration slot is configurable tSlot = (DIVD+1) / fADC.
The duration of an arbitration round, therefore, is tARB = 4 tSlot.
The period of the arbitration round introduces a timing granularity to detect an incoming
conversion request signal and the earliest point to start the related conversion. This
granularity can introduce a jitter of maximum one arbitration round. The jitter can be
reduced by minimizing the period of an arbitration round.
To achieve a reproducible reaction time (constant delay without jitter) between the
trigger event of a conversion request (e.g. by a timer unit or due to an external event)
and the start of the related conversion, mainly the following two options exist. For both
options, the converter has to be idle and other conversion requests must not be pending
for at least one arbiter round before the trigger event occurs:
If bit GxARBCFG (x = 0 - 3).ARBM = 0, the arbiter runs permanently. In this mode,
synchronized conversions of more than one ADC kernel are possible.1)
The trigger for a conversion request has to be generated synchronously to the arbiter
timing. Incoming triggers should have exactly n-times the granularity of the arbiter
(n = 1, 2, 3,...). In order to allow some flexibility, the duration of an arbitration slot can
be programmed in cycles of fADC.
If bit GxARBCFG (x = 0 - 3).ARBM = 1, the arbiter stops after an arbitration round
when no conversion request have been found pending any more. The arbiter is
started again if at least one enabled request source indicates a pending conversion
request. The trigger for a conversion request does not need to be synchronous to the
arbiter timing.
In this mode, parallel conversions are not possible for synchronization slave kernels.
Each request source has a configurable priority, so the arbiter can resolve concurrent
conversion requests from different sources. The request with the highest priority is
selected for conversion. These priorities can be adapted to the requirements of a given
application (see register GxARBPR (x = 0 - 3)).
The Conversion Start Mode determines the handling of the conversion request that has
won the arbitration.
1) For more information, please refer to Synchronization of Conversions on Page 19-46.

XMC4500
XMC4000 Family
19.6.2 Conversion Start Mode

When the arbiter has selected the request to be converted next, the handling of this
channel depends on the current activity of the converter:
Converter is currently idle: the conversion of the arbitration winner is started
immediately.
Current conversion has same or higher priority: the current conversion is completed,
the conversion of the arbitration winner is started after that.
Current conversion has lower priority: the action is user-configurable:
Wait-for-start mode: the current conversion is completed, the conversion of the
arbitration winner is started after that. This mode provides maximum throughput,
but can produce a jitter for the higher priority conversion.
Example in Figure 19-9:
Conversion A is requested (t1) and started (t2). Conversion B is then requested
(t3), but started only after completion of conversion A (t4).
Cancel-inject-repeat mode: the current conversion is aborted, the conversion of
the arbitration winner is started after the abortion (3 fADC cycles).
The aborted conversion request is restored in the corresponding request source
and takes part again in the next arbitration round. This mode provides minimum
jitter for the higher priority conversions, but reduces the overall throughput.
Example in Figure 19-9:
Conversion A is requested (t6) and started (t7). Conversion B is then requested
(t8) and started (t9), while conversion A is aborted but requested again. When
conversion B is complete (t10), conversion A is restarted.
Exception: If both requests target the same result register with wait-for-read mode
active (see Section 19.8.3), the current conversion cannot be aborted.
Note: A cancelled conversion can be repeated automatically in each case, or it can be
discarded if it was cancelled. This is selected for each source by bit RPTDIS in the
corresponding sources mode register.

XMC4500
XMC4000 Family
t1 t3 t6 t8
request
channel B
request
channel A
conversions A B A B A
t2 t4 t5 t7 t9 t10 t11
wait-for-start mode cancel-inject-repeat mode

ADC_conv_starts
Figure 19-9 Conversion Start Modes

The conversion start mode can be individually programmed for each request source by
bits in register GxARBPR (x = 0 - 3) and is applied to all channels requested by the
source. In this example, channel A is issued by a request source with a lower priority than
the request source requesting the conversion of channel B.

XMC4500
XMC4000 Family
19.7 Analog Input Channel Configuration

For each analog input channel a number of parameters can be configured that control
the conversion of this channel. The channel control registers define the following
parameters:
Channel Parameters: The sample time for this channel and the data width of the
result are defined via input classes. Each channel can select one of two classes of
its own group or one of two global classes.
Reference selection: an alternate reference voltage can be selected for most
channels (exceptions are marked in Section 19.14.2)
Result target: The conversion result values are stored either in a group-specific
result register or in the global result register. The group-specific result registers are
selected channel-specific, selected by bitfield RESREG in register G0CHCTRy (y =
0 - 7) etc.
Result position: The result values can be stored left-aligned or right-aligned. The
exact position depends also on the configured result width and on the data
accumulation mode.
See also Figure 19-15 Result Storage Options on Page 19-35.
Compare with Standard Conversions (Limit Checking): Channel events can be
generated whenever a new result value becomes available. Channel event
generation can be restricted to values that lie inside or outside a user-configurable
band.
In Fast Compare Mode, channel events can be generated depending on the
transitions of the (1-bit) result.
Broken Wire Detection: This safety feature can detect a missing connection to an
analog signal source (sensor).
Synchronization of Conversions: Synchronized conversions are executed at the
same time on several converters.
The Alias Feature redirects conversion requests for channels CH0 and/or CH1 to other
channels.
19.7.1 Channel Parameters

Each analog input channel is configured by its associated channel control register.
Note: For the safety feature Broken Wire Detection, refer to Section 19.10.1.
The following features can be defined for each channel:
The conversion class defines the result width and the sample time
Generation of channel events and the result value band, if used
Target of the result defining the target register and the position within the register
The group-specific input class registers define the sample time and data conversion
mode for each channel of the respective group that selects them via bitfield ICLSEL in
its channel control register GxCHCTRx.

XMC4500
XMC4000 Family
The global input class registers define the sample time and data conversion mode for
each channel of any group that selects them via bitfield ICLSEL in its channel control
register GxCHCTRx.

XMC4500
XMC4000 Family
19.7.2 Conversion Timing

The total time required for a conversion depends on several user-definable factors:
The ADC conversion clock frequency, where fADCI = fADC / (DIVA+1)1)
The selected sample time, where tS = (2 + STC) tADCI
(STC = additional sample time, see also Table 19-9)
The selected operating mode (normal conversion / fast compare mode)
The result width N (8/10/12 bits) for normal conversions
The post-calibration time PC, if selected (PC = 2, otherwise 0)
The selected duration of the MSB conversion (DM = 0 or 1)
Synchronization steps done at module clock speed
The conversion time is the sum of sample time, conversion steps, and synchronization.
It can be computed with the following formulas:
Standard conversions: tCN = (2 + STC + N + DM + PC) tADCI + 2 tADC
Fast compare mode: tCN = (2 + STC + 2) tADCI + 2 tADC
The frequency at which conversions are triggered also depends on several configurable
factors:
The selected conversion time, according to the input class definitions. For
conversions using an external multiplexer, also the extended sample times count.
Delays induced by cancelled conversions that must be repeated.
Delays due to equidistant sampling of other channels.
The configured arbitration cycle time.
The frequency of external trigger signals, if enabled.
Timing Examples
System assumptions:
fADC = 120 MHz i.e. tADC = 8.3 ns, DIVA = 3, fADCI = 30 MHz i.e. tADCI = 33.3 ns
According to the given formulas the following minimum conversion times can be
achieved:
12-bit calibrated conversion:
tCN12C = (2 + 12 + 2) tADCI + 2 tADC = 16 33.3 ns + 2 8.3 ns = 550 ns
10-bit uncalibrated conversion:
tCN10 = (2 + 10) tADCI + 2 tADC = 12 33.3 ns + 2 8.3 ns = 417 ns
Fast comparison:
tFCM = (2 + 2) tADCI + 2 tADC = 4 33.3 ns + 2 8.3 ns = 150 ns
1) The minimum prescaler factor for calibrated converters is 2.

XMC4500
XMC4000 Family
19.7.3 Alias Feature

The Alias Feature redirects conversion requests for channels CH0 and/or CH1 to other
channel numbers. This feature can be used to trigger conversions of the same input
channel by independent events and to store the conversion results in different result
registers.
The same signal can be measured twice without the need to read out the conversion
result to avoid data loss. This allows triggering both conversions quickly one after the
other and being independent from CPU/DMA service request latency.
The sensor signal is connected to only one analog input (instead of two analog
inputs). This saves input pins in low-cost applications and only the leakage of one
input has to be considered in the error calculation.
Even if the analog input CH0 is used as alternative reference (see Figure 19-10), the
internal trigger and data handling features for channel CH0 can be used.
The channel settings for both conversions can be different (boundary values, service
requests, etc.).
In typical low-cost AC-drive applications, only one common current sensor is used to
determine the phase currents. Depending on the applied PWM pattern, the measured
value has different meanings and the sample points have to be precisely located in the
PWM period. Figure 19-10 shows an example where the sensor signal is connected to
one input channel (CHx) but two conversions are triggered for two different channels
(CHx and CH0). With the alias feature, a conversion request for CH0 leads to a
conversion of the analog input CHx instead of CH0, but taking into account the settings
for CH0. Although the same analog input (CHx) has been measured, the conversion
results can be stored and read out from the result registers RESx (conversion triggered
for CHx) and RESy (conversion triggered for CH0). Additionally, different interrupts or
limit boundaries can be selected, enabled or disabled.
sensor CHx RESRx

ADC
reference CH0 RESRy
PWM
timer trigger CH0
trigger CHx
ADC_alias
Figure 19-10 Alias Feature

XMC4500
XMC4000 Family
19.7.4 Conversion Modes

A conversion can be executed in several ways. The conversion mode is selected
according to the requested resolution of the digital result and according to the acceptable
conversion time (Section 19.7.2).
Use bitfield CMS/CME in register GxICLASS0 (x = 0 - 3) etc. to select a mode.
Standard Conversions
A standard conversion returns a result value with a predefined resolution. 8-bit, 10-bit,
and 12-bit resolution can be selected.
These result values can be accumulated, filtered, or used for digital limit checking.
Note: The calibrated converters can operate with and without post-calibration.
Fast Compare Mode

In Fast Compare Mode, the selected input voltage is directly compared with a digital
value that is stored in the corresponding result register. This compare operation returns
a binary result indicating if the compared input voltage is above or below the given
reference value. This result is generated quickly and thus supports monitoring of
boundary values.
Fast Compare Mode uses a 10-bit compare value stored left-aligned at bit position 11.
Separate positive and negative delta values define an arbitrary hysteresis band.
Selecting Compare Values

Values for digital or analog compare operations can be selected from several sources.
The separate GxBOUND registers provide software-defined compare values.
In Fast Compare Mode, the result registers provide the compare value while the bitfields
of local GxBOUND registers define positive and negative delta values.

XMC4500
XMC4000 Family
19.7.5 Compare with Standard Conversions (Limit Checking)

The limit checking mechanism can automatically compare each digital conversion result
to an upper and a lower boundary value. A channel event can then be generated when
the result of a conversion/comparison is inside or outside a user-defined band (see
bitfield CHEVMODE and Figure 19-11).
This feature supports automatic range monitoring and minimizes the CPU load by
issuing service requests only under certain predefined conditions.
Note: Channel events can also be generated for each result value (ignoring the band) or
they can be suppressed completely.
The boundary values to which results are compared can be selected from several
sources (see register GxCHCTRy).
Bitfields BNDSELU and BNDSELL select the valid upper/lower boundary value either
from the group-specific boundary register GxBOUND (x = 0 - 3) or from the global
boundary register GLOBBOUND. The group boundary register can be selected for each
channel of the respective group, the global boundary register can be selected by each
available channel.
2 n -1
Result Range
Upper Boundary
Lower Boundary
Results outside band Results inside band
MC_VADC_LIMITBAND
Figure 19-11 Result Monitoring through Limit Checking

XMC4500
XMC4000 Family
A result value is considered inside the defined band when both of the following
conditions are true:
the value is less than or equal to the selected upper boundary
the value is greater than or equal to the selected lower boundary
The result range can also be divided into two areas:
To select the lower part as valid band, set the lower boundary to the minimum value
(000H) and set the upper boundary to the highest intended value.
To select the upper part as valid band, set the upper boundary to the maximum value
(FFFH) and set the lower boundary to the lowest intended value.

XMC4500
XMC4000 Family
19.7.6 Utilizing Fast Compare Mode

In Fast Compare Mode, the input signal is directly compared to a value in the associated
result register. This comparison just provides a binary result (above/below). If the exact
result value is not required, this saves conversion time. A channel event can then be
generated when the input signal becomes higher (or lower) than the compare value (see
bitfield CHEVMODE and Figure 19-12).
The compare value in Fast Compare Mode is taken from the result register. Bitfields
BOUNDARY1 and BOUNDARY0 in register GxBOUND (x = 0 - 3) define delta limits in
this case. These deltas are added to (or subtracted from) the original compare value and
allow defining an arbitrary hysteresis band.
The actual used compare value depends on the Fast Compare Result FCR (see
registers G0RESy (y = 0 - 15), etc.):
GxRESy.FCR = 0: reference value + upper delta
(GxRESy.RESULT + GxBOUND.BOUNDARY0)
GxRESy.FCR = 1: reference value - lower delta
(GxRESy.RESULT - GxBOUND.BOUNDARY1)
2 n -1
Result Range
Upper Delta
Reference Value
Lower Delta
Results below Results above
MC_VADC_LIMITHYST
Figure 19-12 Result Monitoring through Compare with Hysteresis

XMC4500
XMC4000 Family
19.7.7 Boundary Flag Control

Both limit checking mechanisms can be configured to automatically control the boundary
flags. These boundary flags are also available as control signals for other modules. The
flags can be set or cleared when the defined level is exceeded.
For standard conversions, a boundary flag will be set when the conversion result is
above the defined band, and will be cleared when the conversion result is below the
defined band.
The band between the two boundary values defines a hysteresis for setting/clearing the
boundary flags.
Using this feature on three channels that monitor linear hall elements can produce
signals to feed the three hall position inputs of a CCU6x unit.
In Fast Compare Mode, a boundary flag reflects the result of the comparisons, i.e. it will
be set when the compared signal level is above the compare value, and will be cleared
when the signal level is below the compare value.
Upper boundary
Lower boundary
Flag BFx
MC_VADC_BFLAG
Figure 19-13 Boundary Flag Switching

XMC4500
XMC4000 Family
19.8 Conversion Result Handling

The A/D converters can preprocess the conversions result data to a certain extent before
storing them for retrieval by the CPU or a DMA channel. This supports the subsequent
handling of result data by the application software.
Conversion result handling comprises the following functions:
Storage of Conversion Results to user-configurable registers
Data Alignment according to result width and endianess
Wait-for-Read Mode to avoid loss of data
Result Event Generation
Data reduction or anti-aliasing filtering (see Section 19.8.6)
19.8.1 Storage of Conversion Results

The conversion result values of a certain group can be stored in one of the 16 associated
group result registers or in the common global result register (can be used, for example,
for the channels of the background source (see Selecting a Result Register).
This structure provides different locations for the conversion results of different sets of
channels. Depending on the application needs (data reduction, auto-scan, alias feature,
etc.), the user can distribute the conversion results to minimize CPU load and/or optimize
the performance of DMA transfers.
Each result register has an individual data valid flag (VF) associated with it. This flag
indicates when new valid data has been stored in the corresponding result register and
can be read out.
For standard conversions, result values are available in bitfield RESULT. Conversions
in Fast Compare Mode use bitfield RESULT for the reference value, so the result of the
operation is stored in bit FCR.
Result registers can be read via two different views. These views use different addresses
but access the same register data:
When a result register is read via the application view, the corresponding valid flag
is automatically cleared when the result is read. This provides an easy handshake
between result generation and retrieval. This also supports wait-for-read mode.
When a result register is read via the debug view, the corresponding valid flag
remains unchanged when the result is read. This supports debugging by delivering
the result value without disturbing the handshake with the application.
The application can retrieve conversion results through several result registers:
Group result register:
Returns the result value and the channel number
Global result register:
Returns the result value and the channel number and the group number

XMC4500
XMC4000 Family
Result
Converter Data
Reduction Result
Unit Registers
Set
Valid Flags
MC_ VADC_RESULTHANDLING
Figure 19-14 Conversion Result Storage
Selecting a Result Register

Conversion results are stored in result registers that can be assigned by the user
according to the requirements of the application. The following bitfields direct the results
to a register:
RESTGT in register G0CHCTRy (y = 0 - 7) etc.
Selects the global result register
RESREG in register G0CHCTRy (y = 0 - 7) etc.
Selects the group-specific result register GxRES0 GxRES15
when channel-specific result registers are used

XMC4500
XMC4000 Family
19.8.2 Data Alignment

The position of a conversion result value within the selected result register depends on
3 configurations (summary in Figure 19-15):
The selected result width (12/10/8 bits, selected by the conversion mode)
The selected result position (Left/Right-aligned
The selected data accumulation mode (data reduction)
These options provide the conversion results in a way that minimizes data handling for
the application software.
Bit in Result Register 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
12-Bit 0 0 0 0 11 10 9 8 7 6 5 4 3 2 1 0
Conversions
Standard
10-Bit Left-Aligned 0 0 0 0 9 8 7 6 5 4 3 2 1 0 0 0
10-Bit Right-Aligned 0 0 0 0 0 0 9 8 7 6 5 4 3 2 1 0
8-Bit Left-Aligned 0 0 0 0 7 6 5 4 3 2 1 0 0 0 0 0
12-Bit 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Accumulated
Conversions
10-Bit Left-Aligned 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0 0
8-Bit Left-Aligned 11 10 9 8 7 6 5 4 3 2 1 0 0 0 0 0
MC_ VADC_RESPOS
Figure 19-15 Result Storage Options

Bitfield RESULT can be written by software to provide the reference value for Fast
Compare Mode. In this mode, bits 11-2 are evaluated, the other bits are ignored.

XMC4500
XMC4000 Family
19.8.3 Wait-for-Read Mode

The wait-for-read mode prevents data loss due to overwriting a result register with a new
conversion result before the CPU (or DMA) has read the previous data. For example,
auto-scan conversion sequences or other sequences with relaxed timing requirements
may use a common result register. However, the results come from different input
channels, so an overwrite would destroy the result from the previous conversion1).
Wait-for-read mode automatically suspends the start of a conversion for this channel
from this source until the current result has been read. So a conversion or a conversion
sequence can be requested by a hardware or software trigger, while each conversion is
only started after the result of the previous one has been read. This automatically aligns
the conversion sequence with the CPU/DMA capability to read the formerly converted
result (latency).
If wait-for-read mode is enabled for a result register (bit GxRCRy.WFR = 1), a request
source does not generate a conversion request while the targeted result register
contains valid data (indicated by the valid flag VF = 1) or if a currently running conversion
targets the same result register.
If two request sources target the same result register with wait-for-read mode selected,
a higher priority source cannot interrupt a lower priority conversion request started
before the higher priority source has requested its conversion. Cancel-inject-repeat
mode does not work in this case. In particular, this must be regarded if one of the
involved sources is the background source (which usually has lowest priority). If the
higher priority request targets a different result register, the lower priority conversion can
be cancelled and repeated afterwards.
Note: Wait-for-read mode is ignored for synchronized conversions of synchronization
slaves (see Section 19.9).
Due to its specific structure, wait-for-read mode does not work on the global result
register GLOBRES.
1) Repeated conversions of a single channel that use a separate result register will not destroy other results, but
rather update their own previous result value. This way, always the actual signal data is available in the result
register.

XMC4500
XMC4000 Family
19.8.4 Result FIFO Buffer

Result registers can either be used as direct target for conversion results or they can be
concatenated with other result registers of the same ADC group to form a result FIFO
buffer (first-in-first-out buffer mechanism). A result FIFO stores several measurement
results that can be read out later with a relaxed CPU response timing. It is possible to
set up more than one FIFO buffer structure with the available result registers.
Result FIFO structures of two or more registers are built by concatenating result registers
to their following neighbor result register (with next higher index, see Figure 19-16).
This is enabled by setting bitfield GxRCRy.FEN = 01B.
Conversion results are stored to the register with the highest index of a FIFO structure.
Software reads the values from the FIFO register with the lowest index.
Conv. Results
CH2, 7, 10 Result Reg. 7
Result Reg. 6 F Read access
Conv. Results
CH8
Result Reg. 5 Read access
A/D Conv. Results

all other channels
Result Reg. 4
Converter (e.g. for scan) Result Reg. 3 F
Conv. Results
CH3
Result Reg. 1
MC_VADC_RESFIFO
Figure 19-16 Result FIFO Buffers

In the example shown the result registers have been configured in the following way:
2-stage buffer consisting of result registers 7-6
dedicated result register 5
3-stage buffer consisting of result registers 4-3-2
2-stage buffer consisting of result registers 1-0
Table 19-3 summarizes the required configuration of result registers if they are
combined to build result FIFO buffers.

XMC4500
XMC4000 Family
Table 19-3 Properties of Result FIFO Registers

Function Input Stage Intermed. Stage Output Stage
Result target YES no no
Application read no no YES
Data reduction mode YES no no
Wait-for-read mode YES no no
Result event interrupt no no YES
FIFO enable (FEN) 00B 01B 01B
Registers in example 7, 4, 1 3 6, 2, 0
Note: If enabled, a result interrupt is generated for each data word in the FIFO.
19.8.5 Result Event Generation

A result event can be generated when a new value is stored to a result register. Result
events can be restricted due to data accumulation and be generated only if the
accumulation is complete.
Result events can also be suppressed completely.

XMC4500
XMC4000 Family
19.8.6 Data Modification

The data resulting from conversions can be automatically modified before being used by
an application. Several options can be selected (bitfield DMM in register G0RCRy (y =
0 - 15) etc.) which reduce the CPU/DMA load required to unload and/or process the
conversion data.
Standard Data Reduction Mode (for GxRES0 GxRES15):
Accumulates 2, 3, or 4 result values within each result register before generating a
result interrupt. This can remove some noise from the input signal.
Result Filtering Mode (FIR, for GxRES7, GxRES15):
Applies a 3rd order Finite Impulse Response Filter (FIR) with selectable coefficients
to the conversion results for the selected result register.
Result Filtering Mode (IIR, for GxRES7, GxRES15):
Applies a 1st order Infinite Impulse Response Filter (IIR) with selectable coefficients
to the conversion results for the selected result register.
Difference Mode (for GxRES1 GxRES15):
Subtracts the contents of result register GxRES0 from the conversion results for the
selected result register. Bitfield DRCTR is not used in this mode.
Table 19-4 Function of Bitfield DRCTR

DRCTR Standard Data Reduction DRCTR Result Filtering Mode
Mode (DMM = 00B) (DMM = 01B)1)
0000B Data Reduction disabled 0000B FIR filter: a=2, b=1, c=0
0001B Accumulate 2 result values 0001B FIR filter: a=1, b=2, c=0
0100B Reserved 0100B FIR filter: a=1, b=0, c=2

XMC4500
XMC4000 Family
Table 19-4 Function of Bitfield DRCTR (contd)

DRCTR Standard Data Reduction DRCTR Result Filtering Mode
Mode (DMM = 00B) (DMM = 01B)1)
1110B Reserved 1110B IIR filter: a=2, b=2
1111B Reserved 1111B IIR filter: a=3, b=4
1) The filter registers are cleared while bitfield DMM 01B.

XMC4500
XMC4000 Family
Standard Data Reduction Mode

The data reduction mode can be used as digital filter for anti-aliasing or decimation
purposes. It accumulates a maximum of 4 conversion values to generate a final result.
Each result register can be individually enabled for data reduction, controlled by bitfield
DRCTR in registers G0CHCTRy (y = 0 - 7). The data reduction counter DRC indicates
the actual status of the accumulation.
Note: Conversions for other result registers can be inserted between conversions to be
accumulated.
Conversion
r0 r1 r2 r3 r4 r5 r6 r7 r8 Results
0 3 2 1 0 3 2 1 0 DRC
r0 + r4 +
r0 + r4 +
r0 + r1 + r4 + r5 + Contents of
0 r0 r1 + r4 r5 +
r1 r2 + r5 r6 + Result Reg.
r2 r6
r3 r7
VF
t1 t2 t3 t4 t5 t6 t7 t8 t9
MC_VADC_DRC
Figure 19-17 Standard Data Reduction Filter

This example shows a data reduction sequence of 4 accumulated conversion results.
Eight conversion results (r0 r7) are accumulated and produce 2 final results.
When a conversion is complete and stores data to a result register that has data
reduction mode enabled, the data handling is controlled by the data reduction counter
DRC:
If DRC = 0 (t1, t5, t9 in the example), the conversion result is stored to the register.
DRC is loaded with the contents of bitfield DRCTR (i.e. the accumulation begins).
If DRC > 0 (t2, t3, t4 and t6, t7, t8 in the example), the conversion result is added to
the value in the result register.
DRC is decremented by 1.
If DRC becomes 0, either decremented from 1 (t4 and t8 in the example) or loaded
from DRCTR, the valid bit for the respective result register is set and a result register
event occurs.

XMC4500
XMC4000 Family
The final result must be read before the next data reduction sequence starts (before
t5 or t9 in the example). This automatically clears the valid flag.
Note: Software can clear the data reduction counter DRC by clearing the corresponding
valid Flag (via GxVFR (x = 0 - 3)).
The response time to read the final data reduction results can be increased by
associating the adjacent result register to build a result FIFO (see Figure 19-18). In this
case, the final result of a data reduction sequence is loaded to the adjacent register. The
value can be read from this register until the next data reduction sequence is finished (t8
in the 2nd example).
r0+r1 r0+r1 r4+r5 r4+r5

0 r0 r0+r1 + + r4 r4+r5 + + Contents of
Result Reg. z
r2 r2+r3 r6 r6+r7
VFz
r0+r1 r4+r5
Contents of
0 + + Result Reg. x
r2+r3 r6+r7
VFx
t1 t2 t3 t4 t5 t6 t7 t8 t9
MC_VADC_DRC_FIFO
Figure 19-18 Standard Data Reduction Filter with FIFO Enabled

XMC4500
XMC4000 Family
Finite Impulse Response Filter Mode (FIR)

The FIR filter (see Figure 19-19) provides 2 result buffers for intermediate results (RB1,
RB2) and 3 configurable tap coefficients (a, b, c).
The conversion result and the intermediate result buffer values are added weighted with
their respective coefficients to form the final value for the result register. Several
predefined sets of coefficients can be selected via bitfield DRCTR (coding listed in
Table 19-4) in registers G0RESy (y = 0 - 15) and GLOBRES. These coefficients lead to
a gain of 3 or 4 to the ADC result producing a 14-bit value. The valid flag (VF) is activated
for each sample after activation, i.e. for each sample generates a valid result.
filtered.
Conversion Result Buffer Result Buffer

Result 1 2
a b c
Result Register
+ +
x
FIR filter x
Conversion
0 r0 r1 r2 r3 r4 r5 r6 r7 Result Buffer 1
0 0 r0 r1 r2 r3 r4 r5 r6 Result Buffer 2
0+ 0+ 0+ c*r0 + c*r1 + c*r2 + c*r3 + c*r4 + c*r5 +

Contents of
0+ 0+ b*r0 + b*r1 + b*r2 + b*r3 + b*r4 + b*r5 + b*r6 +
Result Reg.
0 a*r0 a*r1 a*r2 a*r3 a*r4 a*r5 a*r6 a*r7
VF
t1 t2 t3 t4 t5 t6 t7 t8 t9
MC_VADC_FIR
Figure 19-19 FIR Filter Structure

Note: The filter registers are cleared while bitfield DMM 01B.

XMC4500
XMC4000 Family
Infinite Impulse Response Filter Mode (IIR)

The IIR filter (see Figure 19-20) provides a result buffer (RB) and 2 configurable
coefficients (a, b). It represents a first order low-pass filter.
The conversion result, weighted with the respective coefficient, and a fraction of the
previous result are added to form the final value for the result register. Several
predefined sets of coefficients can be selected via bitfield DRCTR (coding listed in
Table 19-4) in registers G0RESy (y = 0 - 15) and GLOBRES. These coefficients lead to
a gain of 4 to the ADC result producing a 14-bit value. The valid flag (VF) is activated for
each sample after activation, i.e. for each sample generates a valid result.
filtered.
:b
Conversion Result Register

a + Result Buffer
Result x
IIR filter x
Conversion
0 R0/b R1/b R2/b R3/b R4/b R5/b R6/b R7/b

Contents of
+ + + + + + + + +
Result Reg.
0 a*r0 a*r1 a*r2 a*r3 a*r4 a*r5 a*r6 a*r7
VF
t1 t2 t3 t4 t5 t6 t7 t8 t9
MC_VADC_IIR
Figure 19-20 IIR Filter Structure

Note: The filter registers are cleared while bitfield DMM 01B.

XMC4500
XMC4000 Family
Difference Mode
Subtracting the contents of result register 0 from the actual result puts the results of the
respective channel in relation to another signal. No software action is required.
The reference channel must store its result(s) into result register 0. The reference value
can be determined once and then be used for a series of conversions, or it can be
converted before each related conversion.
Conversion Result Register

-
Result x
Difference
Result Register
0
MC_ VADC_DIFF
Figure 19-21 Result Difference

XMC4500
XMC4000 Family
19.9 Synchronization of Conversions

The conversions of an ADC kernel can be scheduled either self-timed according to the
kernels configuration or triggered by external (outside the ADC) signals:
Synchronized conversions support parallel conversion of channels within a
synchronization group1). This optimizes e.g. the control of electrical drives.
Equidistant sampling supports conversions in a fixed raster with minimum jitter. This
optimizes e.g. filter algorithms or audio applications.
19.9.1 Synchronized Conversions for Parallel Sampling

Several independent ADC kernels1) implemented in the XMC4500 can be synchronized
for simultaneous measurements of analog input channels. While no parallel conversion
is requested, the kernels can work independently.
The synchronization mechanism for parallel conversions ensures that the sample
phases of the related channels start simultaneously. Synchronized kernels convert the
same channel that is requested by the master. Different values for the resolution and the
sample phase length of each kernel for a parallel conversion are supported.
A parallel conversion can be requested individually for each input channel (one or more).
In the example shown in Figure 19-22, input channels CH3 of the ADC kernels 0 and 1
are converted synchronously, whereas other input channels do not lead to parallel
conversions.
One kernel operates as synchronization master, the other kernel(s) operate(s) as
synchronization slave. Each kernel can play either role. Master and slave kernels form
a conversion group to control parallel sampling:
The synchronization master ADC kernel can request a synchronized conversion of
a certain channel (SYNC = 1 in the corresponding channel control register
G0CHCTRy (y = 0 - 7) etc.), which is also requested in the connected slave ADC
kernel.
Wait-for-read mode is supported for the master.
The synchronization slave ADC kernel reacts to incoming synchronized conversion
requests from the master. While no synchronized conversions are requested, the
slave kernel can execute local conversions.
The slave timing must be configured according to the master timing (ARBRND in
register GxARBPR (x = 0 - 3)) to enable parallel conversions.
A parallel conversion request is always handled with highest priority and cancel-
inject-repeat mode.
Wait-for-read mode is ignored in the slave. Previous results may be overwritten, in
particular, if the same result register is used by other conversions.
1) For a summary, please refer to Synchronization Groups in the XMC4500 on Page 19-128.

XMC4500
XMC4000 Family
The arbiter must run permanently (bit GxARBPR (x = 0 - 3).ARBM = 0) for the
synchronization slave.
Initialize the slave before the master to have the arbiters run synchronously.
Once started, a parallel conversion cannot be aborted.
parallel conversions
requested by ADC0
conversions
CH0 CH2 CH3 CH7 CH8 CH3
kernel ADC0
parallel conversions
triggering ADC1
conversions
CH2 CH5 CH3 CH4 CH3 CH1
kernel ADC1
running conversion is aborted and repeated afterwards

ADC_parallel_conv
Figure 19-22 Parallel Conversions

The shown example uses synchronized conversions for channel CH3. The other channel
conversions are controlled by their own kernels. ADC0 is the master, ADC1 is the slave.
The synchronization master controls the slave by providing the control information
GxARBCFG (x = 0 - 3).ANONS (see Figure 19-23) and the requested channel number.
Bitfields GxSYNCTR (x = 0 - 3).STSEL select the source of the ANON information for
the master (00B) and the slave(s) (01B/10B/11B).
STSEL = 00B always selects the own ANON information, and is, therefore, meant for the
synchronization master or for stand-alone operation. The other control inputs
(STSEL = 01B/10B/11B) are connected to the other kernels of a synchronization group in
ascending order (see also Table 19-11 Synchronization Groups in the XMC4500
on Page 19-128).
The ready signals indicate when a slave kernel is ready to start the sample phase of a
parallel conversion. Bit GxSYNCTR (x = 0 - 3).EVALR1 = 1 enables the control by the
ready signal.
Note: Synchronized conversions request the same channel number, defined by the
master. Using the alias feature (see Section 19.7.3), analog signals from different
input channels can be converted. This is advantageous if e.g. CH0 is used as
alternate reference.

XMC4500
XMC4000 Family
ADC3_ANON
ADC2_ANON
ADC1_ANON
ADC0_ANON
CI1
CI2
CI3
CI1
CI2
CI3
CI1
CI2
CI3
CI1
CI2
CI3
GLOBCTR. GLOBCTR. GLOBCTR. GLOBCTR.
ANON ANON ANON ANON
SYNCTR. SYNCTR. SYNCTR. SYNCTR.

00
01
10
11
00
01
10
11
00
01
10
11
00
01
10
11
STSEL STSEL STSEL STSEL
GLOBSTR . GLOBSTR . GLOBSTR. GLOBSTR.

ANON ANON ANON ANON
kernel kernel kernel kernel
control control control control
SYNCTR. SYNCTR. SYNCTR. SYNCTR.
EVALR1-3 EVALR1-3 EVALR1-3 EVALR1-3
R1
R2
R3
R1
R2
R3
R1
R2
R3
R1
R2
R3
ADC0 kernel ADC1 kernel ADC2 kernel ADC3 kernel
ADC0_READY
ADC1_READY
ADC2_READY
ADC3_READY
ADC_ANON_sync
Figure 19-23 Synchronization via ANON and Ready Signals

XMC4500
XMC4000 Family
19.9.2 Equidistant Sampling

To optimize the input data e.g. for filter or audio applications, conversions can be
executed in a fixed timing raster. Conversions for equidistant sampling are triggered by
an external signal (e.g. a timer). To generate the trigger signal synchronous to the
arbiter, the ADC provides an output signal (ARBCNT) that is activated once per
arbitration round and serves as timing base for the trigger timer. In this case, the arbiter
must run permanently (GxARBPR (x = 0 - 3).ARBM = 0). If the timer has an independent
time base, the arbiter can be stopped while no requests are pending. The preface time
(see Figure 19-24) must be longer than one arbitration round and the highest possible
conversion time.
Select timer mode (TMEN = 1 in register GxQCTRL0 (x = 0 - 3) or GxASCTRL (x = 0 -
3)) for the intended source of equidistant conversions. In timer mode, a request of this
source is triggered and arbitrated, but only started when the trigger signal is removed
(see Figure 19-24) and the converter is idle.
To ensure that the converter is idle and the start of conversion can be controlled by the
trigger signal, the equidistant conversion requests must receive highest priority. The
preface time between request trigger and conversion start must be long enough for a
currently active conversion to finish.
The frequency of signal REQTRx defines the sampling rate and its high time defines the
preface time interval where the corresponding request source takes part in the
arbitration.
Depending on the used request source, equidistant sampling is also supported for a
sequence of channels. It is also possible to do equidistant sampling for more than one
request source in parallel if the preface times and the equidistant conversions do not
overlap.
preface time preface time
REQTRx
equidistant
ed ed ed
conversions
lower priority
c c c c
conversions
equidistant sampling equidistant sampling
period period
ADC_timer_mode
Figure 19-24 Timer Mode for Equidistant Sampling

XMC4500
XMC4000 Family
19.10 Safety Features

Several test features can be enabled to verify the validity of the analog input signals of
an application. These test features aim at different sections of the signal flow:
Broken Wire Detection validates the connection from the sensor to the input pin,
Multiplexer Diagnostics validates the operation of the internal analog input
multiplexer,
Converter Diagnostics validates the operation of the Analog/Digital converter itself.
19.10.1 Broken Wire Detection

To test the proper connection of an external analog sensor to its input pin, the converters
capacitor can be precharged to a selectable value before the regular sample phase. If
the connection to the sensor is interrupted the subsequent conversion value will rather
represent the precharged value than the expected sensor result. By using a precharge
voltage outside the expected result range (broken wire detection preferably uses VAGND
and/or VAREF) a valid measurement (sensor connected) can be distinguished from a
failure (sensor detached).
While broken wire detection is disabled, the converters capacitor is precharged to
VAREF/2.
Note: The duration of the complete conversion is increased by the preparation phase
(same as the sample phase) if the broken wire detection is enabled. This
influences the timing of conversion sequences.
Broken wire detection can be enabled for each channel separately by bitfield BWDEN in
the corresponding channel control register (G0CHCTRy (y = 0 - 7)). This bitfield also
selects the level for the preparation phase.
Duration of a Standard Conversion
Sample Phase Conversion Phase
Duration of a Conversion with Broken Wire Detection
Prep. Phase Sample Phase Conversion Phase
MC_VADC_BWD
Figure 19-25 Broken Wire Detection

XMC4500
XMC4000 Family
19.10.2 Signal Path Test Modes

Additional test structures can be activated to test the signal path from the sensor to the
input pin and the internal signal path from the input pin through the multiplexer to the
converter. These test structures apply additional loads to the signal path (see summary
in Figure 19-26).
Multiplexer Diagnostics
To test the proper operation of the internal analog input multiplexer, additional test
signals can be connected to channels CH1 and CH2. In combination with a known
external input signal this test function shows if the multiplexer connects any pin to the
converter input and if this is the correct pin.
Pull-Down Diagnostics
One single input channel provides a further strong pull-down (RPDD) that can be activated
to verify the external connection to a sensor.
Converter Diagnostics
To test the proper operation of the converter itself, several signals can be connected to
the converter input. The test signals can be connected to the converter input either
instead of the standard input signal or in parallel to the standard input signal.
The test signal can be selected from four different signals as shown in Figure 19-26.

XMC4500
XMC4000 Family
VDDP
VAREF
ADC Kernel
CHx
RPDD
VAGND
VSS
Pull-Down Multiplexer Converter

Diagnostics Diagnostics Diagnostics MC_VADC_DIAG
Figure 19-26 Signal Path Test
19.10.3 Configuration of Test Functions

The pull-up and pull-down devices for the test functions can be enabled individually
under software control. Various test levels can be applied controlling the devices in an
adequate way. Because these test functions interfere with the normal operation of the
A/D Converters, they are controlled by a separate register set.
Not all test options are available for each channel. Selecting an unavailable function has
no effect.

XMC4500
XMC4000 Family
19.11 External Multiplexer Control

The number of analog input channels can be increased by connecting external analog
multiplexers to an input channel. The ADC can be configured to control these external
multiplexers automatically.
For each available EMUX interface (see register EMUXSEL) one channel can be
selected for this operating mode. The ADC supports 1-out-of-8 multiplexers with several
control options:
Sequence mode automatically converts all configured external channels
when the selected channel is encountered. In the example in Figure 19-27 the
following conversions are done: --4-32-31-30-2-1-0--4-32-31-30-2-1-0--
Single-step mode converts one external channel of the configured sequence
following conversions are done: --4-32-2-1-0--4-31-2-1-0--4-30-2-1-0--4-32-
(Single-step mode works best with one channel)
Steady mode converts the configured external channel
following conversions are done: --4-32-2-1-0--4-32-2-1-0--4-32-2-1-0--
Note: The example in Figure 19-27 has an external multiplexer connected to channel
CH3. The start selection value EMUXSET is assumed as 2.
CH0 ADC kernel

input signals
REXT CEXT
Internal MUX
. ..
Direct
CH3
ADC
REXT1 CEXT1
CH4
REXT CEXT channel
External analog
8-to-1 multiplexer control
CH30
Extended input
REXT2 CEXT2 EMUX[2:0]

signals
CH31
REXT2 CEXT2 EMUX

...
CH37
control
REXT2 CEXT2
MC_ADC_EXTMUX
Figure 19-27 External Analog Multiplexer Example

XMC4500
XMC4000 Family
Bitfield EMUXACT determines the control information sent to the external multiplexer.
In single-step mode, EMUXACT is updated after each conversion of an enabled channel.
If EMUXACT = 000B it is reloaded from bitfield EMUXSET, otherwise it is decremented
by 1.
Additional external channels may have different properties due to the modified signal
path. Local filters may be used at the additional inputs (REXT2-CEXT2 on CH3x in
Figure 19-27). For applications where the external multiplexer is located far from the
ADC analog input, it is recommended to add an RC filter directly at the analog input of
the ADC (REXT1-CEXT1 on CH3 in Figure 19-27).
Note: Each RC filter limits the bandwidth of the analog input signal.
Conversions for external channels, therefore, use the alternate conversion mode setting
CME. This automatically selects a different conversion mode if required.
Switching the external multiplexer usually requires an additional settling time for the input
signal. Therefore, the alternate sample time setting STCE is applied each time the
external channel is changed. This automatically fulfills the different sampling time
requirements in this case.
In each group an arbitrary channel can be assigned to external multiplexer control
(register GxEMUXCTR (x = 0 - 3)). Each available port interface selects the group whose
control lines are output (register EMUXSEL).
Control Signals
The external channel number that controls the external multiplexer can be output in
standard binary format or Gray-coded. Gray code avoids intermediate multiplexer
switching when selecting a sequence of channels, because only one bit changes at a
time. Table 19-5 indicates the resulting codes.
Table 19-5 EMUX Control Signal Coding

Channel 0 1 2 3 4 5 6 7
Binary 000B 001B 010B 011B 100B 101B 110B 111B
Gray 000 001 011 010 110 111 101 100
Operation Without External Multiplexer

If no external multiplexers are used in an application, the reset values of the control
registers provide the appropriate setup.
EMUXMODE = 00B disables the automatic EMUX control.
Since the control output signals are alternate port output signals, they are only visible at
the respective pins if explicitly selected.

XMC4500
XMC4000 Family

Each A/D Converter can activate up to 4 group-specific service request output signals
and up to 4 shared service request output signals to issue an interrupt or to trigger a DMA
channel. Two common service request groups are available, see Table 19-10 General
Converter Configuration in the XMC4500 on Page 19-127.
Several events can be assigned to each service request output. Service requests can be
generated by three types of events:
Request source events: indicate that a request source completed the requested
conversion sequence and the application software can initiate further actions.
For a scan source (group or background), the event is generated when the complete
defined set of channels (pending bits) has been converted.
For a group queue source, the event is generated according to the programming, i.e.
when a channel with enabled source interrupt has been converted or when an invalid
entry is encountered.
Channel events: indicate that a conversion is finished. Optionally, channel events
can be restricted to result values within a programmable value range. This offloads
the CPU/DMA from background tasks, i.e. a service request is only activated if the
specified conversion result range is met or exceeded.
Result events: indicate a new valid result in a result register. Usually, this triggers a
read action by the CPU (or DMA). Optionally, result events can be generated only at
a reduced rate if data reduction is active.
For example, a single DMA channel can read the results for a complete auto-scan
sequence, if all channels of the sequence target the same result register and the
transfers are triggered by result events.
Each ADC event is indicated by a dedicated flag that can be cleared by software. If a
service request is enabled for a certain event, the service request is generated for each
event, independent of the status of the corresponding event indication flag. This ensures
efficient DMA handling of ADC events (the ADC event can generate a service request
without the need to clear the indication flag).
Event flag registers indicate all types of events that occur during the ADCs operation.
Software can set each flag by writing a 1 to the respective position in register
GxCEFLAG/GxRFLAG to trigger an event. Software can clear each flag by writing a 1 to
the respective position in register GxCEFCLR/GxREFCLR. If enabled, service requests
are generated for each occurrance of an event, even if the associated flag remains set.
Node Pointer Registers

Requests from each event source can be directed to a set of service request nodes via
associated node pointers. Requests from several sources can be directed to the same
node; in this case, they are ORed to the service request output signal.

XMC4500
XMC4000 Family
Software Service Request Activation

Each service request can be activated via software by setting the corresponding bit in
register GxSRACT (x = 0 - 3). This can be used for evaluation and testing purposes.
Note: For shared service request lines see common groups in Table 19-10.

XMC4500
XMC4000 Family
19.13 Registers
The Versatile ADC is built from a series of converter blocks that are controlled in an
identical way. This makes programming versatile and scalable. The corresponding
registers, therefore, have an individual offset assigned (see Table 19-7). The exact
register location is obtained by adding the respective register offset to the base address
(see Table 19-6) of the corresponding group.
Due to the regular group structure, several registers appear within each group. Other
registers are provided for each channel. This is indicated in the register overview table
by placeholders:
X###H means: x 0400H + 0###H, for x = 0 - 3
###YH means: ###0H + y 0004H, for y = 0 - N (depends on register type)

VADC 4000 4000H 4000 7FFFH

Register Short Register Long Name Offset Access Mode Page
Name Addr. Read Write Num.
ID Module Identification Register 0008H U, PV BE 19-60
CLC Clock Control Register 0000H U, PV PV 19-61
OCS OCDS Control and Status Register 0028H U, PV PV 19-62
GLOBCFG Global Configuration Register 0080H U, PV U, PV 19-64
GxARBCFG Arbitration Configuration Register X480H U, PV U, PV 19-66
GxARBPR Arbitration Priority Register X484H U, PV U, PV 19-68
GxCHASS Channel Assignment Register, X488H U, PV U, PV 19-65
Group x
GxQCTRL0 Queue 0 Source Control Register, X500H U, PV U, PV 19-70
Group x
GxQMR0 Queue 0 Mode Register, Group x X504H U, PV U, PV 19-72
GxQSR0 Queue 0 Status Register, Group x X508H U, PV U, PV 19-74
GxQINR0 Queue 0 Input Register, Group x X510H U, PV U, PV 19-76
GxQ0R0 Queue 0 Register 0, Group x X50CH U, PV U, PV 19-78
GxQBUR0 Queue 0 Backup Register, Group x X510H U, PV U, PV 19-80

XMC4500
XMC4000 Family

GxASCTRL Autoscan Source Control Register, X520H U, PV U, PV 19-82
Group x
GxASMR Autoscan Source Mode Register, X524H U, PV U, PV 19-84
Group x
GxASSEL Autoscan Source Channel Select X528H U, PV U, PV 19-86
Register, Group x
GxASPND Autoscan Source Pending Register, X52CH U, PV U, PV 19-87
Group x
BRSCTRL Background Request Source Control 0200H U, PV U, PV 19-88
Register
BRSMR Background Request Source Mode 0204H U, PV U, PV 19-90
Register
BRSSELx Background Request Source 018YH U, PV U, PV 19-92
Channel Select Register, Group x
BRSPNDx Background Request Source 01CYH U, PV U, PV 19-93
Channel Pending Register, Group x
GxCHCTRy Channel x Control Register X60YH U, PV U, PV 19-94
GxICLASS0 Input Class Register 0, Group x X4A0H U, PV U, PV 19-96
GxICLASS1 Input Class Register 1, Group x X4A4H U, PV U, PV 19-96
GLOBICLASS0 Input Class Register 0, Global 00A0H U, PV U, PV 19-96
GLOBICLASS1 Input Class Register 1, Global 00A4H U, PV U, PV 19-96
GxALIAS Alias Register X4B0H U, PV U, PV 19-10
8
GxBOUND Boundary Select Register, Group x X4B8H U, PV U, PV 19-10
9
GLOBBOUND Global Boundary Select Register 00B8H U, PV U, PV 19-10
9
GxBFL Boundary Flag Register, Group x X4C8H U, PV U, PV 19-11
0
GxRCRy Group x Result Control Register y X68YH U, PV U, PV 19-99
GxRESy Group x Result Register y X70YH U, PV U, PV 19-10
1

XMC4500
XMC4000 Family

GxRESDy Group x Result Register y (debug X78YH U, PV U, PV 19-10
view) 3
GLOBRCR Global Result Control Register 0280H U, PV U, PV 19-10
4
GLOBRES Global Result Register 0300H U, PV U, PV 19-10
5
GLOBRESD Global Result Register (debug view) 0380H U, PV U, PV 19-10
5
GxVFR Valid Flag Register, Group x X5F8H U, PV U, PV 19-10
7
GxSYNCTR Synchronization Control Register X4C0H U, PV U, PV 19-11
1
GLOBTF Global Test Functions Register 0160H U, PV U, PV 19-11
2
GxEMUXCTR External Multiplexer Control X5F0H U, PV U, PV 19-11
Register, Group x 3
EMUXSEL External Multiplexer Select Register 03F0H U, PV U, PV 19-11
5
GxSEFLAG Source Event Flag Register, Group x X588H U, PV U, PV 19-11
5
GxCEFLAG Channel Event Flag Register, Group X580H U, PV U, PV 19-11
x 6
GxREFLAG Result Event Flag Register, Group x X584H U, PV U, PV 19-11
7
GxSEFCLR Source Event Flag Clear Register, X598H U, PV U, PV 19-11
Group x 7
GxCEFCLR Channel Event Flag Clear Register, X590H U, PV U, PV 19-11
Group x 8
GxREFCLR Result Event Flag Clear Register, X594H U, PV U, PV 19-11
Group x 9
GLOBEFLAG Global Event Flag Register 00E0H U, PV U, PV 19-11
9

XMC4500
XMC4000 Family

GxSEVNP Source Event Node Pointer Register, X5C0H U, PV U, PV 19-12
Group x 0
GxCEVNP0 Channel Event Node Pointer X5A0H U, PV U, PV 19-12
Register 0, Group x 1
GxREVNP0 Result Event Node Pointer Register X5B0H U, PV U, PV 19-12
0, Group x 2
GxREVNP1 Result Event Node Pointer Register X5B4H U, PV U, PV 19-12
1, Group x 3
GLOBEVNP Global Event Node Pointer Register 0140H U, PV U, PV 19-12
4
GxSRACT Service Request Software Activation X5C8H U, PV U, PV 19-12
Trigger, Group x 6
19.13.1 Module Identification

The module identification register indicates the version of the ADC module that is used
in the XMC4500.
ID
Module Identification Register (0008H) Reset Value: 00C5 C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
r r r

(00C5H = SARADC).

XMC4500
XMC4000 Family
19.13.2 System Registers

A set of standardized registers provides general access to the module and controls basic
system functions.
The Clock Control Register CLC allows the programmer to adapt the functionality and
power consumption of the module to the requirements of the application. Register CLC
controls the module clock signal and the reactivity to the sleep mode signal.
CLC
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
E DIS DIS
0 0 0 0 0 0 0 0 0 0 0 0 0
DIS S R
r r r r r r r r r r r r rw r r rw

Used for enable/disable control of the module. Also the
analog section is disabled by clearing ANONS.
0B On request: enable the module clock
1B Off request: stop the module clock
0B Module clock is enabled
1B Off: module is not clocked
0 2 r Reserved, write 0, read as 0
Used to control modules reaction to sleep mode.
0B Sleep mode request is enabled and functional
1B Module disregards the sleep mode control signal
0 [31:4] r Reserved, write 0, read as 0

XMC4500
XMC4000 Family
The OCDS control and status register OCS controls the modules behavior in suspend
mode (used for debugging) and includes the module-related control bits for the OCDS
Trigger Bus (OTGB).
The OCDS Control and Status (OCS) register is cleared by Debug Reset.
The OCS register can only be written when the OCDS is enabled.
If OCDS is being disabled, the OCS register value will not change.
When OCDS is disabled the OCS suspend control is ineffective.
Write access is 32 bit wide only and requires Supervisor Mode.
OCS
OCDS Control and Status Register (0028H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SUS SUS
0 0 SUS 0 0 0 0 0 0 0 0
STA _P
r r rh w rw r r r r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TG
0 0 0 0 0 0 0 0 0 0 0 0 TGB TGS
_P
r r r r r r r r r r r r w rw rw

TGS [1:0] rw Trigger Set for OTGB0/1
00B No Trigger Set output
01B Trigger Set 1: TS16_SSIG, input sample signals
10B Reserved
11B Reserved
TGB 2 rw OTGB0/1 Bus Select
0B Trigger Set is output on OTGB0
1B Trigger Set is output on OTGB1
TG_P 3 w TGS, TGB Write Protection
TGS and TGB are only written when TG_P is 1, otherwise
unchanged. Read as 0.

XMC4500
XMC4000 Family

SUS [27:24] rw OCDS Suspend Control
Controls the sensitivity to the suspend signal coming from
the OCDS Trigger Switch (OTGS)
0000BWill not suspend
0001BHard suspend: Clock is switched off immediately.
0010BSoft suspend mode 0:
Stop conversions after the currently running one is
completed and its result has been stored.
No change for the arbiter.
0011BSoft suspend mode 1:
Stop conversions after the currently running one is
completed and its result has been stored.
Stop arbiter after the current arbitration round.
others: Reserved
SUS_P 28 w SUS Write Protection
SUS is only written when SUS_P is 1, otherwise
SUSSTA 29 rh Suspend State
0B Module is not (yet) suspended
1B Module is suspended
Table 19-8 TS16_SSIG Trigger Set VADC

Bits Name Description
[3:0] GxSAMPLE Input signal sample phase of converter group x (x = 3-0)
[15:4] 0 Reserved

XMC4500
XMC4000 Family
19.13.3 General Registers

The global configuration register provides global control and configuration options that
are valid for all converters of the cluster.
GLOBCFG
Global Configuration Register (0080H) Reset Value: 0000 000FH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
DP DP DP DP
SU
0 0 0 0 0 0 0 0 0 0 0 CAL CAL CAL CAL
CAL
3 2 1 0
w r r r r r r r r r r r rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
DIV DC
0 0 0 0 0 DIVD 0 0 DIVA
WC MSB
w r r r r r rw rw r r rw

DIVA [4:0] rw Divider Factor for the Analog Internal Clock
Defines the frequency of the basic converter clock
fADCI (base clock for conversion and sample phase).
00H fADCI = fADC / 2
...
1FH fADCI = fADC / 32
DCMSB 7 rw Double Clock for the MSB Conversion
Selects an additional clock cycle for the conversion
step of the MSB.1)
0B 1 clock cycles for the MSB (standard)
1B 2 clock cycles for the MSB (fADCI > 20 MHz)
DIVD [9:8] rw Divider Factor for the Arbiter Clock
Defines the frequency of the arbiter clock fADCD.
00B fADCD = fADC
01B fADCD = fADC / 2

XMC4500
XMC4000 Family

DIVWC 15 w Write Control for Divider Parameters
0B No write access to divider parameters
1B Bitfields DIVA, DCMSB, DIVD can be written
DPCALx x+16 rw Disable Post-Calibration
(x = 0 - 3) 0B Automatic post-calibration after each
conversion of group x
1B No post-calibration
Note: This bit is only valid for the calibrated
converters within the given product type.
SUCAL 31 w Start-Up Calibration
The 0-1 transition of bit SUCAL initiates the start-up
calibration phase of all calibrated analog converters.
0B No action
1B Initiate the start-up calibration phase
(indication in bit GxARBCFG.CAL)
1) Please also refer to section Conversion Timing on Page 19-26.
GxCHASS (x = 0 - 3)
Channel Assignment Register, Group x
(x * 0400H + 0488H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ASS ASS ASS ASS ASS ASS ASS ASS
0 0 0 0 0 0 0 0 CH CH CH CH CH CH CH CH
7 6 5 4 3 2 1 0
r r r r r r r r rw rw rw rw rw rw rw rw

ASSCHy y rw Assignment for Channel y
(y = 0 - 7) 0B Channel y can be a background channel
converted with lowest priority
1B Channel y is a priority channel within group x

XMC4500
XMC4000 Family

19.13.4 Arbitration and Source Registers

The Arbitration Configuration Register selects the timing and the behavior of the arbiter.
GxARBCFG (x = 0 - 3)
Arbitration Configuration Register, Group x
(x * 0400H + 0480H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SAM BU
0 CAL 0 0 0 0 0 0 0 0 0 0 ANONS
PLE SY
rh rh r rh r r r r r r r r r r rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ARB
0 0 0 0 0 0 0 0 0 ARBRND 0 0 ANONC
M
r r r r r r r r rw r rw r r rw

ANONC [1:0] rw Analog Converter Control
Defines the value of bitfield ANONS in a stand-alone
converter or a converter in master mode.
Coding see ANONS or Section 19.4.
ARBRND [5:4] rw Arbitration Round Length
Defines the number of arbitration slots per arb. round
(arbitration round length = tARB).1)
00B 4 arbitration slots per round (tARB = 4 / fADCD)

XMC4500
XMC4000 Family

ARBM 7 rw Arbitration Mode
0B The arbiter runs permanently.
This setting is required for a synchronization
slave (see Section 19.9.1) and for equidistant
sampling using the signal ARBCNT (see
Section 19.9.2).
1B The arbiter only runs if at least one conversion
request of an enabled request source is
pending.
This setting ensures a reproducible latency
from an incoming request to the conversion
start, if the converter is idle. Synchronized
conversions are not supported.
ANONS [17:16] rh Analog Converter Control Status
Defined by bitfield ANONC in a stand-alone kernel or
a kernel in master mode.
In slave mode, this bitfield is defined by bitfield
ANONC of the respective master kernel.
See also Section 19.4.
00B Analog converter off
01B Reserved
10B Reserved
11B Normal operation (permanently on)
CAL 28 rh Start-Up Calibration Active Indication
Indicates the start-up calibration phase of the
corresponding analog converter.
0B Completed or not yet started
1B Start-up calibration phase is active
Note: Start conversions only after the start-up
calibration phase is complete.
BUSY 30 rh Converter Busy Flag
0B Not busy
1B Converter is busy with a conversion

XMC4500
XMC4000 Family

SAMPLE 31 rh Sample Phase Flag
0B Converting or idle
1B Input signal is currently sampled
1) The default setting of 4 arbitration slots is sufficient for correct arbitration. The duration of an arbitration round
can be increased if required to synchronize requests.
The Arbitration Priority Register defines the request source priority and the conversion
start mode for each request source.
Note: Only change priority and conversion start mode settings of a request source while
this request source is disabled, and a currently running conversion requested by
this source is finished.
GxARBPR (x = 0 - 3)
Arbitration Priority Register, Group x
(x * 0400H + 0484H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
AS AS AS
0 0 0 0 0 0 0 0 0 0 0 0 0
EN2 EN1 EN0
r r r r r rw rw rw r r r r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CSM PRIO CSM PRIO CSM PRIO
0 0 0 0 0 0 0
2 2 1 1 0 0
r r r r rw r rw rw r rw rw r rw

PRIO0, [1:0], rw Priority of Request Source x
PRIO1, [5:4], Arbitration priority of request source x (in slot x)
PRIO2 [9:8] 00B Lowest priority is selected.
...
11B Highest priority is selected.
CSM0, 3, rw Conversion Start Mode of Request Source x
CSM1, 7, 0B Wait-for-start mode
CSM2 11 1B Cancel-inject-repeat mode, i.e. this source can
cancel conversion of other sources.

XMC4500
XMC4000 Family

0 2, 6, r Reserved, write 0, read as 0
10,
[23:12]
ASENy 24 + y rw Arbitration Slot y Enable
(y = 0 - 2) Enables the associated arbitration slot of an arbiter
round. The request source bits are not modified by
write actions to ASENR.
0B The corresponding arbitration slot is disabled
and considered as empty. Pending conversion
requests from the associated request source
are disregarded.
1B The corresponding arbitration slot is enabled.
Pending conversion requests from the
associated request source are arbitrated.

XMC4500
XMC4000 Family
The control register of the queue source selects the external gate and/or trigger signals.
Write control bits allow separate control of each function with a simple write access.
GxQCTRL0 (x = 0 - 3)
Queue 0 Source Control Register, Group x
(x * 0400H + 0500H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TM TM GT GT GT
0 0 0 0 0 0 0 0
WC EN WC LVL SEL
w r r rw r r r r w r r rh rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
XT XT XT XT
0 0 0 0 0 0 0 0
WC MODE LVL SEL
w rw rh rw r r r r r r r r

XTSEL [11:8] rw External Trigger Input Selection
The connected trigger input signals are listed in
Table 19-13 Digital Connections in the
XMC4500 on Page 19-131
Note: XTSEL = 1111B uses the selected gate input
as trigger source (ENGT must be 0XB).
XTLVL 12 rh External Trigger Level
Current level of the selected trigger input
XTMODE [14:13] rw Trigger Operating Mode
00B No external trigger
01B Trigger event upon a falling edge
10B Trigger event upon a rising edge
11B Trigger event upon any edge
XTWC 15 w Write Control for Trigger Configuration
0B No write access to trigger configuration
1B Bitfields XTMODE and XTSEL can be written
GTSEL [19:16] rw Gate Input Selection
The connected gate input signals are listed in

XMC4500
XMC4000 Family

GTLVL 20 rh Gate Input Level
Current level of the selected gate input
GTWC 23 w Write Control for Gate Configuration
0B No write access to gate configuration
1B Bitfield GTSEL can be written
TMEN 28 rw Timer Mode Enable
0B No timer mode:
standard gating mechanism can be used
1B Timer mode for equidistant sampling enabled:
standard gating mechanism must be disabled
TMWC 31 w Write Control for Timer Mode
0B No write access to timer mode
1B Bitfield TMEN can be written

XMC4500
XMC4000 Family
The Queue Mode Register configures the operating mode of a queued request source.
GxQMR0 (x = 0 - 3)
Queue 0 Mode Register, Group x
(x * 0400H + 0504H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RPT
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
DIS
r r r r r r r r r r r r r r r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
FLU TR CLR EN
0 0 0 0 CEV 0 0 0 0 0 ENGT
SH EV V TR
r r r r w w w w r r r r r rw rw

ENGT [1:0] rw Enable Gate
Selects the gating functionality for source 0/2.
00B No conversion requests are issued
01B Conversion requests are issued if a valid
conversion request is pending in the queue 0
register or in the backup register
register or in the backup register and
REQGTx = 1
register or in the backup register and
REQGTx = 0
Note: REQGTx is the selected gating signal.
ENTR 2 rw Enable External Trigger
0B External trigger disabled
1B The selected edge at the selected trigger input
signal REQTR generates the trigger event

XMC4500
XMC4000 Family

CLRV 8 w Clear Valid Bit
0B No action
1B The next pending valid queue entry in the
sequence and the event flag EV are cleared.
If there is a valid entry in the queue backup
register (QBUR.V = 1), this entry is cleared,
otherwise the entry in queue register 0 is
cleared.
TREV 9 w Trigger Event
0B No action
1B Generate a trigger event by software
FLUSH 10 w Flush Queue
0B No action
1B Clear all queue entries (including backup
stage) and the event flag EV. The queue
contains no more valid entry.
CEV 11 w Clear Event Flag
0B No action
1B Clear bit EV
RPTDIS 16 rw Repeat Disable
0B A cancelled conversion is repeated
1B A cancelled conversion is discarded

XMC4500
XMC4000 Family
The Queue Status Register indicates the current status of the queued source. The filling
level and the empty information refer to the queue intermediate stages (if available) and
to the queue register 0. An aborted conversion stored in the backup stage is not
indicated by these bits (therefore, see QBURx.V).
GxQSR0 (x = 0 - 3)
Queue 0 Status Register, Group x
(x * 0400H + 0508H) Reset Value: 0000 0020H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
REQ EMP
0 0 0 0 0 0 0 EV 0 0 FILL
GT TY
r r r r r r r rh rh r rh r rh

FILL [3:0] rh Filling Level for Queue 2
Indicates the number of valid queue entries.
It is incremented each time a new entry is written to
QINRx or by an enabled refill mechanism.
It is decremented each time a requested conversion
has been started. A new entry is ignored if the filling
level has reached its maximum value.
0000BThere is 1 ( if EMPTY = 0) or
no (if EMPTY = 1) valid entry in the queue
0001BThere are 2 valid entries in the queue

others: Reserved
EMPTY 5 rh Queue Empty
0B There are valid entries in the queue (see FILL)
1B No valid entries (queue is empty)

XMC4500
XMC4000 Family

REQGT 7 rh Request Gate Level
Monitors the level at the selected REQGT input.
0B The gate input is low
1B The gate input is high
EV 8 rh Event Detected
Indicates that an event has been detected while at
least one valid entry has been in the queue (queue
register 0 or backup stage). Once set, this bit is
cleared automatically when the requested
conversion is started.
0B No trigger event
1B A trigger event has been detected

XMC4500
XMC4000 Family
The Queue Input Register is the entry point for conversion requests of a queued request
source.
GxQINR0 (x = 0 - 3)
Queue 0 Input Register, Group x
(x * 0400H + 0510H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EX EN
0 0 0 0 0 0 0 0 RF REQCHNR
TR SI
r r r r r r r r w w w w

REQCHNR [4:0] w Request Channel Number
Defines the channel number to be converted
RF 5 w Refill
0B No refill: this queue entry is converted once
and then invalidated
1B Automatic refill: this queue entry is
automatically reloaded into QINRx when the
related conversion is started
ENSI 6 w Enable Source Interrupt
0B No request source interrupt
1B A request source event interrupt is generated
upon a request source event (related
conversion is finished)
EXTR 7 w External Trigger
Enables the external trigger functionality.
0B A valid queue entry immediately leads to a
conversion request.
1B A valid queue entry waits for a trigger event to
occur before issuing a conversion request.

XMC4500
XMC4000 Family
Note: Registers QINRx share addresses with registers QBURx.

Write operations target the control bits in register QINRx. Read operations return
the status bits from register QBURx.

XMC4500
XMC4000 Family
The queue registers 0 monitor the status of the pending request (queue stage 0).
GxQ0R0 (x = 0 - 3)
Queue 0 Register 0, Group x (x * 0400H + 050CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EX EN
0 0 0 0 0 0 0 V RF REQCHNR
TR SI
r r r r r r r rh rh rh rh rh

REQCHNR [4:0] rh Request Channel Number
Stores the channel number to be converted.
RF 5 rh Refill
Selects the handling of handled requests.
0B The request is discarded after the conversion
start.
1B The request is automatically refilled into the
queue after the conversion start.
ENSI 6 rh Enable Source Interrupt
1B A request source event interrupt is generated
upon a request source event (related
conversion is finished)
EXTR 7 rh External Trigger
Enables external trigger events.
0B A valid queue entry immediately leads to a
conversion request
1B The request handler waits for a trigger event
V 8 rh Request Channel Number Valid
Indicates a valid queue entry in queue register 0.
0B No valid queue entry
1B The queue entry is valid and leads to a
conversion request

XMC4500
XMC4000 Family


XMC4500
XMC4000 Family
The Queue Backup Registers monitor the status of an aborted queued request.
GxQBUR0 (x = 0 - 3)
Queue 0 Backup Register, Group x
(x * 0400H + 0510H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EXT EN
0 0 0 0 0 0 0 V RF REQCHNR
R SI
r r r r r r r rh rh rh rh rh

REQCHNR [4:0] rh Request Channel Number
The channel number of the aborted conversion that
has been requested by this request source
RF 5 rh Refill
The refill control bit of the aborted conversion
ENSI 6 rh Enable Source Interrupt
The enable source interrupt control bit of the aborted
conversion
EXTR 7 rh External Trigger
The external trigger control bit of the aborted
conversion
V 8 rh Request Channel Number Valid
Indicates if the entry (REQCHNR, RF, TR, ENSI) in
the queue backup register is valid.
Bit V is set when a running conversion (that has been
requested by this request source) is aborted, it is
cleared when the aborted conversion is restarted.
0B Backup register not valid
1B Backup register contains a valid entry.
This will be requested before a valid entry in
queue register 0 (stage 0) will be requested.
r [31:9] r Reserved, write 0, read as 0

XMC4500
XMC4000 Family
Note: Registers QBURx share addresses with registers QINRx.

Read operations return the status bits from register QBURx. Write operations
target the control bits in register QINRx.

XMC4500
XMC4000 Family
Registers of Group Scan Source

There is a separate register set for each group scan source. These sources can be
operated independently.
The control register of the autoscan source selects the external gate and/or trigger
signals.
GxASCTRL (x = 0 - 3)
Autoscan Source Control Register, Group x
(x * 0400H + 0520H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
TM TM GT GT GT
0 0 0 0 0 0 0 0
WC EN WC LVL SEL
w r r rw r r r r w r r rh rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
XT XT XT XT
0 0 0 0 0 0 0 0
WC MODE LVL SEL


XMC4500
XMC4000 Family

TMEN 28 rw Timer Mode Enable
0B No timer mode:
standard gating mechanism can be used
1B Timer mode for equidistant sampling enabled:
standard gating mechanism must be disabled
TMWC 31 w Write Control for Timer Mode
0B No write access to timer mode
1B Bitfield TMEN can be written

XMC4500
XMC4000 Family
The Conversion Request Mode Register configures the operating mode of the channel
scan request source.
GxASMR (x = 0 - 3)
Autoscan Source Mode Register, Group x
(x * 0400H + 0524H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RPT
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
DIS
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
LD CLR REQ SCA EN EN
0 0 0 0 0 0 0 LDM ENGT
EV PND GT N SI TR
r r r r r r w w rh r rw rw rw rw rw

Selects the gating functionality for source 1.
01B Conversion requests are issued if at least one
pending bit is set
pending bit is set and REQGTx = 1.
signal REQTR generates the load event
ENSI 3 rw Enable Source Interrupt
1B A request source interrupt is generated upon a
request source event (last pending conversion
is finished)

XMC4500
XMC4000 Family

SCAN 4 rw Autoscan Enable
0B No autoscan
1B Autoscan functionality enabled:
a request source event automatically
generates a load event
LDM 5 rw Autoscan Source Load Event Mode
0B Overwrite mode:
Copy all bits from the select registers to the
pending registers upon a load event
1B Combine mode:
Set all pending bits that are set in the select
registers upon a load event (logic OR)
CLRPND 8 w Clear Pending Bits
0B No action
1B The bits in register GxASPNDx are cleared
LDEV 9 w Generate Load Event
0B No action
1B A load event is generated

XMC4500
XMC4000 Family
The Channel Select Register selects the channels to be converted by the group scan
request source. Its bits are used to update the pending register, when a load event
occurs.
The number of valid channel bits depends on the channels available in the respective
product type (please refer to Product-Specific Configuration on Page 19-127).
GxASSEL (x = 0 - 3)
Autoscan Source Channel Select Register, Group x
(x * 0400H + 0528H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CH CH CH CH CH CH CH CH
0 0 0 0 0 0 0 0 SEL SEL SEL SEL SEL SEL SEL SEL
7 6 5 4 3 2 1 0

CHSELy y rw Channel Selection
(y = 0 - 7) Each bit (when set) enables the corresponding input
channel of the respective group to take part in the
scan sequence.
0B Ignore this channel
1B This channel is part of the scan sequence
The Channel Pending Register indicates the channels to be converted in the current
conversion sequence. They are updated from the select register, when a load event
occurs.

XMC4500
XMC4000 Family
GxASPND (x = 0 - 3)
Autoscan Source Pending Register, Group x
(x * 0400H + 052CH) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 PND PND PND PND PND PND PND PND
7 6 5 4 3 2 1 0

CHPNDy y rw Channels Pending
(y = 0 - 7) Each bit (when set) request the conversion of the
corresponding input channel of the respective group.
1B Request conversion of this channel

XMC4500
XMC4000 Family
Registers of Background Scan Source

There is a single register set for the background scan source. This source is ccommon
for the complete VADC.
The control register of the background request source selects the external gate and/or
trigger signals.
BRSCTRL
Background Request Source Control Register
(0200H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
GT GT GT
0 0 0 0 0 0 0 0 0 0
WC LVL SEL
r r r r r r r r w r r rh rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
XT XT XT XT
0 0 0 0 0 0 0 0
WC MODE LVL SEL


XMC4500
XMC4000 Family


XMC4500
XMC4000 Family
The Conversion Request Mode Register configures the operating mode of the
background request source.
BRSMR
Background Request Source Mode Register
(0204H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
RPT
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
DIS
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
LD CLR REQ SCA EN EN
0 0 0 0 0 0 0 LDM ENGT
EV PND GT N SI TR
r r r r r r w w rh r rw rw rw rw rw

Selects the gating functionality for source 1.
pending bit is set
signal REQTR generates the load event
ENSI 3 rw Enable Source Interrupt
1B A request source interrupt is generated upon a
request source event (last pending conversion
is finished)

XMC4500
XMC4000 Family

SCAN 4 rw Autoscan Enable
0B No autoscan
1B Autoscan functionality enabled:
a request source event automatically
generates a load event
LDM 5 rw Autoscan Source Load Event Mode
0B Overwrite mode:
Copy all bits from the select registers to the
pending registers upon a load event
1B Combine mode:
Set all pending bits that are set in the select
registers upon a load event (logic OR)
CLRPND 8 w Clear Pending Bits
0B No action
1B The bits in registers BRSPNDx are cleared
LDEV 9 w Generate Load Event
0B No action
1B A load event is generated

XMC4500
XMC4000 Family
The Channel Select Registers select the channels to be converted by the background
request source (channel scan source). Its bits are used to update the pending registers,
when a load event occurs.
The number of valid channel bits depends on the channels available in the respective
product type (please refer to Product-Specific Configuration on Page 19-127).
Note: Priority channels selected in registers GxCHASS (x = 0 - 3) will not be converted.
BRSSELx (x = 0 - 3)
Background Request Source Channel Select Register, Group x
(0180H + x * 0004H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 SEL SEL SEL SEL SEL SEL SEL SEL
G7 G6 G5 G4 G3 G2 G1 G0

CHSELGy y rw Channel Selection Group x
(y = 0 - 7) Each bit (when set) enables the corresponding input
channel of the respective group to take part in the
background scan sequence.
1B This channel is part of the scan sequence

XMC4500
XMC4000 Family
The Channel Pending Registers indicate the channels to be converted in the current
conversion sequence. They are updated from the select registers, when a load event
occurs.
BRSPNDx (x = 0 - 3)
Background Request Source Pending Register, Group x
(01C0H + x * 0004H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 PND PND PND PND PND PND PND PND
G7 G6 G5 G4 G3 G2 G1 G0

CHPNDGy y rw Channels Pending Group x
(y = 0 - 7) Each bit (when set) request the conversion of the
corresponding input channel of the respective group.
1B Request conversion of this channel
Note: Writing to any of registers BRSPNDx generates a load event that copies all bits
from registers BRSSELx to BRSPNDx.
Use this shortcut only when writing the last word of the request pattern.

XMC4500
XMC4000 Family
19.13.5 Channel Control Registers
G0CHCTRy (y = 0 - 7)
Group 0, Channel y Ctrl. Reg. (0600H + y * 0004H) Reset Value: 0000 0000H
Group 1, Channel y Ctrl. Reg. (0A00H + y * 0004H) Reset Value: 0000 0000H
Group 2, Channel y Ctrl. Reg. (0E00H + y * 0004H) Reset Value: 0000 0000H
Group 3, Channel y Ctrl. Reg. (1200H + y * 0004H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
BWD BWD RES RES
0 0 0 0 0 0 0 RESREG
EN CH POS TBS
r rw rw r r r r r r rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
REF SY CHEV
0 0 0 0 BNDSELU BNDSELL 0 0 ICLSEL
SEL NC MODE
r r r r rw rw rw rw rw r r rw

ICLSEL [1:0] rw Input Class Select
00B Use group-specific class 0
01B Use group-specific class 1
10B Use global class 0
11B Use global class 1
BNDSELL [5:4] rw Lower Boundary Select
00B Use group-specific boundary 0
10B Use global boundary 0
BNDSELU [7:6] rw Upper Boundary Select

XMC4500
XMC4000 Family

CHEVMODE [9:8] rw Channel Event Mode
Generate a channel event in normal compare mode
with limit checking1)
00B Never
01B If result is inside the boundary band
10B If result is outside the boundary band
11B Always (ignore band)
Generate a channel event in Fast Compare Mode2)
00B Never
01B If result switches to high (above comp. value)
10B If result switches to low (below comp. value)
11B If result switches to either level
SYNC 10 rw Synchronization Request
0B No synchroniz. request, standalone operation
1B Request a synchronized conversion of this
channel (only taken into account for a master)
REFSEL 11 rw Reference Input Selection
Defines the reference voltage input to be used for
conversions on this channel.
0B Standard reference input VAREF
1B Alternate reference input from CH03)
0 [15:12] rw Reserved, write 0, read as 0
RESREG [19:16] rw Result Register
0000BStore result in group result register GxRES0

1111BStore result in group result register GxRES15
RESTBS 20 rw Result Target for Background Source
0B Store results in the selected group result
register
1B Store results in the global result register
RESPOS 21 rw Result Position
0B Store results left-aligned
1B Store results right-aligned

XMC4500
XMC4000 Family

BWDCH [29:28] rw Broken Wire Detection Channel
00B Select VAGND
01B Select VAREF
10B Reserved
11B Reserved
BWDEN 30 rw Broken Wire Detection Enable
0B Normal operation
1B Additional preparation phase is enabled
1) The boundary band is defined as the area where the result is less than or equal to the selected upper boundary
and greater than or equal to the selected lower boundary, see Section 19.7.5.
2) The result is bit FCR in the selected result register.
3) Some channels cannot select an alternate reference.
GxICLASS0 (x = 0 - 3)
Input Class Register 0, Group x
(x * 0400H + 04A0H) Reset Value: 0000 0000H
GxICLASS1 (x = 0 - 3)
Input Class Register 1, Group x
GLOBICLASSy (y = 0 - 1)
Input Class Register y, Global
(00A0H + y * 0004H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 CME 0 0 0 STCE
r r r r r rw r r r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 CMS 0 0 0 STCS
r r r r r rw r r r rw

XMC4500
XMC4000 Family

STCS [4:0] rw Sample Time Control for Standard Conversions
Number of additional clock cycles to be added to the
minimum sample phase of 2 analog clock cycles:
Coding and resulting sample time see Table 19-9.
For conversions of external channels, the value from
bitfield STCE can be used.
CMS [10:8] rw Conversion Mode for Standard Conversions
000B 12-bit conversion
011B Reserved
100B Reserved
101B 10-bit fast compare mode
110B Reserved
111B Reserved
STCE [20:16] rw Sample Time Control for EMUX Conversions
Number of additional clock cycles to be added to the
minimum sample phase of 2 analog clock cycles:
Coding and resulting sample time see Table 19-9.
For conversions of standard channels, the value
from bitfield STCS is used.
CME [26:24] rw Conversion Mode for EMUX Conversions
011B Reserved
100B Reserved
101B 10-bit fast compare mode
110B Reserved
111B Reserved

XMC4500
XMC4000 Family
Table 19-9 Sample Time Coding

STCS / STCE Additional Clock Cycles Sample Time
0 0000B 0 2 / fADCI
0 0001B 1 3 / fADCI

0 1111B 15 17 / fADCI
1 0000B 16 18 / fADCI
1 0001B 32 34 / fADCI

1 1110B 240 242 / fADCI
1 1111B 256 258 / fADCI

XMC4500
XMC4000 Family
19.13.6 Result Registers

The group result control registers select the behavior of the result registers of a given
group.
G0RCRy (y = 0 - 15)
Group 0 Result Control Reg. y (0680H + y * 0004H) Reset Value: 0000 0000H
G1RCRy (y = 0 - 15)
Group 1 Result Control Reg. y (0A80H + y * 0004H) Reset Value: 0000 0000H
G2RCRy (y = 0 - 15)
Group 2 Result Control Reg. y (0E80H + y * 0004H) Reset Value: 0000 0000H
G3RCRy (y = 0 - 15)
Group 3 Result Control Reg. y (1280H + y * 0004H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SRG
0 0 0 0 FEN WFR 0 0 DMM DRCTR
EN
rw r r r r rw rw r r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

DRCTR [19:16] rw Data Reduction Control
Defines how result values are stored/accumulated in
this register for the final result. The data reduction
counter DRC can be loaded from this bitfield.
The function of bitfield DRCTR is determined by
bitfield DMM.
DMM [21:20] rw Data Modification Mode
00B Standard data reduction (accumulation)
01B Result filtering mode1)
10B Difference mode
11B Reserved
See Data Modification on Page 19-39

XMC4500
XMC4000 Family

WFR 24 rw Wait-for-Read Mode Enable
0B Overwrite mode
1B Wait-for-read mode enabled for this register
FEN [26:25] rw FIFO Mode Enable
00B Separate result register
01B Part of a FIFO structure:
copy each new valid result
1XB Reserved
SRGEN 31 rw Service Request Generation Enable
0B No service request
1B Service request after a result event
1) The filter registers are cleared while bitfield DMM 01B.

XMC4500
XMC4000 Family
The group result registers provide a selectable storage location for all channels of a
given group.
Note: The preset value used in fast compare mode is written to the respective result
register. The debug result registers are not writable.
G0RESy (y = 0 - 15)
Group 0 Result Register y (0700H + y * 0004H) Reset Value: 0000 0000H
G1RESy (y = 0 - 15)
Group 1 Result Register y (0B00H + y * 0004H) Reset Value: 0000 0000H
G2RESy (y = 0 - 15)
Group 2 Result Register y (0F00H + y * 0004H) Reset Value: 0000 0000H
G3RESy (y = 0 - 15)
Group 3 Result Register y (1300H + y * 0004H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
VF FCR CRS EMUX CHNR DRC
rh rh rh rh rh rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RESULT
rwh

RESULT [15:0] rwh Result of Most Recent Conversion
The position of the result bits within this bitfield
depends on the configured operating mode.
Please, refer to Section 19.8.2.
DRC [19:16] rh Data Reduction Counter
Indicates the number of values still to be
accumulated for the final result. The final result is
available and valid flag VF is set when bitfield DRC
becomes zero (by decrementing or by reload).
CHNR [24:20] rh Channel Number
Indicates the channel number corresponding to the
value in bitfield RESULT.

XMC4500
XMC4000 Family

EMUX [27:25] rh External Multiplexer Setting
Indicates the setting of the external multiplexer,
corresponding to the value in bitfield RESULT.
Note: Available in GxRES0 only.
Use GxRES0 if EMUX information is required.
CRS [29:28] rh Converted Request Source
Indicates the request source that as requested the
conversion to which the result value in bitfield
RESULT belongs.
00B Request source 0
11B Reserved
FCR 30 rh Fast Compare Result
Indicates the result of an operation in Fast Compare
Mode.
0B Signal level was below compare value
1B Signal level was above compare value
VF 31 rh Valid Flag
Indicates a new result in bitfield RESULT or bit FCR.
0B No new result available
1B Bitfield RESULT has been updated with new
result value and has not yet been read, or bit
FCR has been updated
The debug view of the group result registers provides access to all result registers of a
given group, however, without clearing the valid flag.

XMC4500
XMC4000 Family
G0RESDy (y = 0 - 15)
Group 0 Result Reg. y, Debug (0780H + y * 0004H) Reset Value: 0000 0000H
G1RESDy (y = 0 - 15)
Group 1 Result Reg. y, Debug (0B80H + y * 0004H) Reset Value: 0000 0000H
G2RESDy (y = 0 - 15)
Group 2 Result Reg. y, Debug (0F80H + y * 0004H) Reset Value: 0000 0000H
G3RESDy (y = 0 - 15)
Group 3 Result Reg. y, Debug (1380H + y * 0004H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
VF FCR CRS EMUX CHNR DRC
rh rh rh rh rh rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RESULT
rh

RESULT [15:0] rh Result of Most Recent Conversion
depends on the configured operating mode.
DRC [19:16] rh Data Reduction Counter
Indicates the number of values still to be
accumulated for the final result. The final result is
available and valid flag VF is set when bitfield DRC
becomes zero (by decrementing or by reload).
Note: Available in GxRESD0 only.
Use GxRESD0 if EMUX information is
required.

XMC4500
XMC4000 Family

RESULT belongs.
11B Reserved
Mode.
VF 31 rh Valid Flag
1B Bitfield RESULT has been updated with new
result value and has not yet been read, or bit
FCR has been updated
The global result control register selects the behavior of the global result register.
GLOBRCR
Global Result Control Register (0280H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SRG
0 0 0 0 0 0 WFR 0 0 0 0 DRCTR
EN
rw r r r r r r rw r r r r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


XMC4500
XMC4000 Family

DRCTR [19:16] rw Data Reduction Control
Defines how result values are stored/accumulated in
this register for the final result. The data reduction
counter DRC can be loaded from this bitfield.
0000BData reduction disabled
others: see Function of Bitfield DRCTR on
Page 19-391)
WFR 24 rw Wait-for-Read Mode Enable
0B Overwrite mode
1B Wait-for-read mode enabled for this register
SRGEN 31 rw Service Request Generation Enable
0B No service request
1B Service request after a result event
1) Only standard data reduction is available for the global result register, i.e. DMM is assumed as 00B.
The global result register provides a common storage location for all channels of all
groups.
GLOBRES
Global Result Register (0300H) Reset Value: 0000 0000H
GLOBRESD
Global Result Register, Debug (0380H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
VF FCR CRS EMUX CHNR GNR
rwh rh rh rh rh rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RESULT
rwh

XMC4500
XMC4000 Family

RESULT [15:0] rwh Result of most recent conversion
depends on the configured operating mode.1)
GNR [19:16] rh Group Number
Indicates the group to which the channel number in
bitfield CHNR refers.
RESULT belongs.
Mode.
VF 31 rwh Valid Flag
Read access:
0B No new valid data available
1B Bitfield RESULT contains valid data and has
not yet been read, or bit FCR has been
updated
Write access:1)
0B No effect
1B Clear this valid flag and the data reduction
counter (overrides a hardware set action)
1) Only writable in register GLOBRES, not in register GLOBRESD.
The valid flag register summarizes the valid flags of all result registers.

XMC4500
XMC4000 Family
GxVFR (x = 0 - 3)
Valid Flag Register, Group x (x * 0400H + 05F8H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VF15 VF14 VF13 VF12 VF11 VF10 VF9 VF8 VF7 VF6 VF5 VF4 VF3 VF2 VF1 VF0

VFy y rwh Valid Flag of Result Register x
(y = 0 - 15) Indicates a new result in bitfield RESULT or in bit
FCR.
Read access:
0B No new valid data available
1B Result register x contains valid data and has
not yet been read, or bit FCR has been
updated
Write access:
0B No effect
1B Clear this valid flag and bitfield DRC in register
GxRESy/GLOBRES (overrides a hardware set
action)
19.13.7 Miscellaneous Registers

The alias register can replace the channel numbers of channels CH0 and CH1 with
another channel number. The reset value disables this redirection.

XMC4500
XMC4000 Family
GxALIAS (x = 0 - 3)
Alias Register, Group x (x * 0400H + 04B0H) Reset Value: 0000 0100H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ALIAS1 0 0 0 ALIAS0
r r r r r r r r r r r r r r r r r r r rw r r r rw

ALIAS0 [4:0] rw Alias Value for CH0 Conversion Requests
Indicates the channel that is converted instead of
channel CH0. The conversion is done with the
settings defined for channel CH0.
ALIAS1 [12:8] rw Alias Value for CH1 Conversion Requests
Indicates the channel that is converted instead of
channel CH1. The conversion is done with the
settings defined for channel CH1.

XMC4500
XMC4000 Family
The local boundary register GxBOUND defines group-specific boundary values or delta
limits for Fast Compare Mode.
The global boundary register GLOBBOUND defines general compare values for all
channels.
Depending on the conversion width, the respective left 12/10/8 bits of a bitfield are used.
For 10/8-bit results, the lower 2/4 bits must be zero!
GxBOUND (x = 0 - 3)
Boundary Select Register, Group x
(x * 0400H + 04B8H) Reset Value: 0000 0000H
GLOBBOUND
Global Boundary Select Register (00B8H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 BOUNDARY1 0 0 0 0 BOUNDARY0
r r r r rw r r r r rw

BOUNDARY0 [11:0] rw Boundary Value 0 for Limit Checking
Standard Mode: This value is compared against the
left-aligned conversion result.
Fast Compare Mode: This value is added to the
reference value (upper delta).
BOUNDARY1 [27:16] rw Boundary Value 1 for Limit Checking
Standard Mode: This value is compared against the
left-aligned conversion result.
Fast Compare Mode: This value is subtracted from
the reference value (lower delta).

XMC4500
XMC4000 Family
The Boundary Flag Register holds the boundary flags themselves together with bits to
select the activation condition and the output signal polarity for each flag.
GxBFL (x = 0 - 3)
Boundary Flag Register, Group x
(x * 0400H + 04C8H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
BFE BFE BFE BFE
0 0 0 0 0 0 0 0 0 0 0 0
3 2 1 0
r r r r r r r r r r r r rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BFL BFL BFL BFL
0 0 0 0 0 0 0 0 0 0 0 0
3 2 1 0
r r r r r r r r r r r r rh rh rh rh

BFLy y rh Boundary Flag y
(y = 0 - 3) 0B Passive state:
result has not yet crossed the activation
boundary (see bitfield BFAy),
or selected gate signal is inactive,
or this boundary flag is disabled
1B Active state:
result has crossed the activation boundary
BFEy 16 + y rw Enable Bit for Boundary Flag y
(y = 0 - 3) 0B Output 0 on this channel
1B Output BFLy on this channel

XMC4500
XMC4000 Family
The Synchronization Control Register controls the synchronization of kernels for parallel
conversions.
Note: Program register GxSYNCTR only while bitfield GxARBCFG.ANONS = 00B in all
ADC kernels of the conversion group. Set the masters bitfield ANONC to 11B
afterwards.
GxSYNCTR (x = 0 - 3)
Synchronization Control Register, Group x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EVA EVA EVA
0 0 0 0 0 0 0 0 0 0 0 STSEL
LR3 LR2 LR1
r r r r r r r r r rw rw rw r r rw

STSEL [1:0] rw Start Selection
Controls the synchronization mechanism of the ADC
kernel.
00B Kernel is synchronization master:
Use own bitfield GxARBCFG.ANONC
01B Kernel is synchronization slave:
Control information from input CI1
Note: Control inputs CIx see Figure 19-23,
connected kernels see Table 19-11.

XMC4500
XMC4000 Family

EVALR1, 4, rw Evaluate Ready Input Rx
EVALR2, 5, Enables the ready input signal for a kernel of a
EVALR3 6 conversion group.
0B No ready input control
1B Ready input Rx is considered for the start of a
parallel conversion of this conversion group
GLOBTF
Global Test Functions Register (0160H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MD
0 0 0 0 0 0 0 0 0 0 0 0 0 0 PDD
WC
r r r r r r r r w r r r r r r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CD CD CD
0 0 0 0 CDGR 0 0 0 0
WC SEL EN
w r r r r rw rw rw r r r r

CDGR [7:4] rw Converter Diagnostics Group
Defines the group number to be used for converter
diagnostics conversions.
CDEN 8 rw Converter Diagnostics Enable
0B All diagnostic pull devices are disconnected
1B Diagnostic pull devices connected as selected
by bitfield CDSEL
CDSEL [10:9] rw Converter Diagnostics Pull-Devices Select
00B Connected to VAREF
01B Connected to VAGND
10B Connected to 1/3rd VAREF
11B Connected to 2/3rd VAREF

XMC4500
XMC4000 Family

CDWC 15 w Write Control for Conversion Diagnostics
0B No write access to parameters
1B Bitfields CDSEL, CDEN, CDGR can be written
PDD 16 rw Pull-Down Diagnostics Enable
0B Disconnected
1B The pull-down diagnostics device is active
Note: Channels with pull-down diagnostics device
are marked in Table 19-12.
MDWC 23 w Write Control for Multiplexer Diagnostics
0B No write access to parameters
1B Bitfield PDD can be written
GxEMUXCTR (x = 0 - 3)
External Multiplexer Control Register, Group x
(x * 0400H + 05F0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
EMX EMX EMX EMX EMUX EMUX
0 0 0 0 0
WC CSS ST COD MODE CH
w rw rw rw rw r r r r r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EMUX EMUX
0 0 0 0 0 0 0 0 0 0
ACT SET
r r r r r rh r r r r r rw

EMUXSET [2:0] rw External Multiplexer Start Selection1)
Defines the initial setting for the external multiplexer.

XMC4500
XMC4000 Family

EMUXACT [10:8] rh External Multiplexer Actual Selection
Defines the current value for the external multiplexer
selection. This bitfield is loaded from bitfield
EMUXSET and modified according to the operating
mode selected by bitfield EMUXMODE.
EMUXCH [20:16] rw External Multiplexer Channel Select
Defines the channel(s) to which the external
multiplexer control is applied.
EMUXMODE [27:26] rw External Multiplexer Mode
00B Software control (no hardware action)
01B Steady mode (use EMUXSET value)
10B Single-step mode1)2)
11B Sequence mode1)
EMXCOD 28 rw External Multiplexer Coding Scheme
0B Output the channel number in binary code
1B Output the channel number in Gray code
EMXST 29 rw External Multiplexer Sample Time Control
0B Use STCE whenever the setting changes
1B Use STCE for each conversion of an external
channel
EMXCSS 30 r External Multiplexer Channel Selection Style
0B Channel number:
Bitfield MUXCH selects an arbitrary channel
1B Channel enable:
Each bit of bitfield EMUXCH selects the
associated channel for EMUX control
EMXWC 31 w Write Control for EMUX Configuration
0B No write access to EMUX cfg.
1B Bitfields EMXMODE, EMXCOD, EMXST,
EMXCSS can be written
1) For single-step mode and sequence mode: Select the start value before selecting the respective mode.
2) Single-step mode modifies the EMUX channel number each time an EMUX-enabled channel is converted.
Therefore, single-step mode works best with a single channel, because otherwise some external channels
may be skipped.

XMC4500
XMC4000 Family
Register EMUXSEL is a global register which assigns an arbitrary group to each of the
EMUX interfaces.
EMUXSEL
External Multiplexer Select Register
(03F0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EMUX EMUX
0 0 0 0 0 0 0 0
GRP1 GRP0
r r r r r r r r rw rw

EMUXGRP0, [3:0], rw External Multiplexer Group for Interface x
EMUXGRP1 [7:4] Defines the group whose external multiplexer control
signals are routed to EMUX interface x.1)
1) The pins that are associated with each EMUX interface are listed in Table 19-13 Digital Connections in the
XMC4500 on Page 19-131.
19.13.8 Service Request Registers
GxSEFLAG (x = 0 - 3)
Source Event Flag Register, Group x
(x * 0400H + 0588H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SEV SEV
0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0
r r r r r r r r r r r r r r rwh rwh

XMC4500
XMC4000 Family

SEV0, 0, rwh Source Event 0/1
SEV1 1 0B No source event
1B A source event has occurred
Note: Software can set all flags in register GxSEFLAG and trigger the corresponding
event by writing 1 to the respective bit. Writing 0 has no effect.
Software can clear all flags in register GxSEFLAG by writing 1 to the respective
bit in register GxSEFCLR.
GxCEFLAG (x = 0 - 3)
Channel Event Flag Register, Group x
(x * 0400H + 0580H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CEV CEV CEV CEV CEV CEV CEV CEV
0 0 0 0 0 0 0 0
7 6 5 4 3 2 1 0
r r r r r r r r rwh rwh rwh rwh rwh rwh rwh rwh

CEVy y rwh Channel Event for Channel y
(y = 0 - 7) 0B No channel event
1B A channel event has occurred
Note: Software can set all flags in register GxCEFLAG and trigger the corresponding
Software can clear all flags in register GxCEFLAG by writing 1 to the respective
bit in register GxCEFCLR.

XMC4500
XMC4000 Family
GxREFLAG (x = 0 - 3)
Result Event Flag Register, Group x
(x * 0400H + 0584H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
REV REV REV REV REV REV REV REV REV REV REV REV REV REV REV REV
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

REVy y rwh Result Event for Result Register y
(y = 0 - 15) 0B No result event
1B New result was stored in register GxRESy
Note: Software can set all flags in register GxREFLAG and trigger the corresponding
Software can clear all flags in register GxREFLAG by writing 1 to the respective
bit in register GxREFCLR.
GxSEFCLR (x = 0 - 3)
Source Event Flag Clear Register, Group x
(x * 0400H + 0598H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SEV SEV
0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0
r r r r r r r r r r r r r r w w

XMC4500
XMC4000 Family

SEV0, 0, w Clear Source Event 0/1
SEV1 1 0B No action
1B Clear the source event flag in GxSEFLAG
GxCEFCLR (x = 0 - 3)
Channel Event Flag Clear Register, Group x
(x * 0400H + 0590H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CEV CEV CEV CEV CEV CEV CEV CEV
0 0 0 0 0 0 0 0
7 6 5 4 3 2 1 0
r r r r r r r r w w w w w w w w

CEVy y w Clear Channel Event for Channel y
(y = 0 - 7) 0B No action
1B Clear the channel event flag in GxCEFLAG

XMC4500
XMC4000 Family
GxREFCLR (x = 0 - 3)
Result Event Flag Clear Register, Group x
(x * 0400H + 0594H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
REV REV REV REV REV REV REV REV REV REV REV REV REV REV REV REV
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
w w w w w w w w w w w w w w w w

REVy y w Clear Result Event for Result Register y
1B Clear the result event flag in GxREFLAG
GLOBEFLAG
Global Event Flag Register (00E0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
REV SEV
0 0 0 0 0 0 0 GLB 0 0 0 0 0 0 0 GLB
CLR CLR
r r r r r r r w r r r r r r r w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
REV SEV
0 0 0 0 0 0 0 0 0 0 0 0 0 0
GLB GLB
r r r r r r r rwh r r r r r r r rwh

SEVGLB 0 rwh Source Event (Background)
0B No source event
1B A source event has occurred

XMC4500
XMC4000 Family

REVGLB 8 rwh Global Result Event
0B No result event
1B New result was stored in register GLOBRES
SEVGLBCLR 16 w Clear Source Event (Background)
0B No action
1B Clear the source event flag SEVGLB
REVGLBCLR 24 w Clear Global Result Event
0B No action
1B Clear the result event flag REVGLB
Note: Software can set flags REVGLB and SEVGLB and trigger the corresponding event
by writing 1 to the respective bit. Writing 0 has no effect.
Software can clear these flags by writing 1 to bit REVGLBCLR and SECGLBCLR,
respectively.
GxSEVNP (x = 0 - 3)
Source Event Node Pointer Register, Group x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 SEV1NP SEV0NP
r r r r r r r r rw rw

XMC4500
XMC4000 Family

SEV0NP, [3:0], rw Service Request Node Pointer Source Event i
SEV1NP [7:4] Routes the corresponding event trigger to one of the
service request lines (nodes).
0000BSelect service request line 0 of group x

0011BSelect service request line 3 of group x
0100BSelect shared service request line 0

1xxxB Reserved
Note: For shared service request lines see common
groups in Table 19-10.
GxCEVNP0 (x = 0 - 3)
Channel Event Node Pointer Register 0, Group x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CEV7NP CEV6NP CEV5NP CEV4NP
rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CEV3NP CEV2NP CEV1NP CEV0NP
rw rw rw rw

XMC4500
XMC4000 Family

CEV0NP, [3:0], rw Service Request Node Pointer Channel Event i
CEV1NP, [7:4], Routes the corresponding event trigger to one of the
CEV2NP, [11:8], service request lines (nodes).
CEV3NP, [15:12], 0000BSelect service request line 0 of group x
CEV4NP, [19:16],
CEV5NP, [23:20], 0011BSelect service request line 3 of group x
CEV6NP, [27:24], 0100BSelect shared service request line 0
CEV7NP [31:28]
1xxxB Reserved
GxREVNP0 (x = 0 - 3)
Result Event Node Pointer Register 0, Group x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
REV7NP REV6NP REV5NP REV4NP
rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
rw rw rw rw

XMC4500
XMC4000 Family

REV0NP, [3:0], rw Service Request Node Pointer Result Event i
REV1NP, [7:4], Routes the corresponding event trigger to one of the
REV2NP, [11:8], service request lines (nodes).
REV3NP, [15:12], 0000BSelect service request line 0 of group x
REV4NP, [19:16],
REV6NP, [27:24], 0100BSelect shared service request line 0
REV7NP [31:28]
1xxxB Reserved
GxREVNP1 (x = 0 - 3)
Result Event Node Pointer Register 1, Group x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
rw rw rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
rw rw rw rw

XMC4500
XMC4000 Family

REV8NP, [3:0], rw Service Request Node Pointer Result Event i
REV9NP, [7:4], Routes the corresponding event trigger to one of the
REV10NP, [11:8], service request lines (nodes).
REV12NP, [19:16],
REV14NP, [27:24], 0100BSelect shared service request line 0
REV15NP [31:28]
1xxxB Reserved
GLOBEVNP
Global Event Node Pointer Register
(0140H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 REV0NP
r r r r r r r r r r r r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 SEV0NP
r r r r r r r r r r r r rw

XMC4500
XMC4000 Family

SEV0NP [3:0] rw Service Request Node Pointer Backgr. Source
Routes the corresponding event trigger to one of the
0000BSelect shared service request line 0 of
common service request group 0


1xxxB Reserved
REV0NP [19:16] rw Service Request Node Pointer Backgr. Result
Routes the corresponding event trigger to one of the


1xxxB Reserved

XMC4500
XMC4000 Family
GxSRACT (x = 0 - 3)
Service Request Software Activation Trigger, Group x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
AS AS AS AS AG AG AG AG
0 0 0 0 0 0 0 0
SR3 SR2 SR1 SR0 SR3 SR2 SR1 SR0
r r r r w w w w r r r r w w w w

AGSRy y w Activate Group Service Request Node y
1B Activate the associated service request line
ASSRy 8+y w Activate Shared Service Request Node y
1B Activate the associated service request line

XMC4500
XMC4000 Family
19.14 Interconnects
This section describes the actual implementation of the ADC module into the XMC4500,
i.e. the incorporation into the microcontroller system.
19.14.1 Product-Specific Configuration

The functional description describes the features and operating modes of the A/D
Converters in a general way. This section summarizes the configuration that is available
in this product (XMC4500).
Each converter group is equipped with a separate analog converter module and a
dedicated analog input multiplexer.
Table 19-10 General Converter Configuration in the XMC4500

Converter Input Channels with 12-bit Common Service
Group Channels Alternate Performance Request Group
Reference
G0 07 4 Calibrated C0

XMC4500
XMC4000 Family
Synchronization Groups in the XMC4500

The converter kernels in the XMC4500 can be connected to synchronization groups to
achieve parallel conversion of several input channels.
Table 19-11 summarizes which kernels can be synchronized for parallel conversions.
Table 19-11 Synchronization Groups in the XMC4500

ADC Kernel Synchr. Master selected by control input CIx1)
Group CI02) CI1 CI2 CI3
ADC00 A ADC00 ADC01 ADC02 ADC03
1) The control input is selected by bitfield STSEL in register GxSYNCTR (x = 0 - 3).
Select the corresponding ready inputs accordingly by bits EVALRx.
2) Control input CI0 always selects the own control signals of the corresponding ADC kernel. This selection is
meant for the synchronization master or for stand-alone operation.

XMC4500
XMC4000 Family
19.14.2 Analog Module Connections in the XMC4500

The VADC module accepts a number of analog input signals. The analog input
multiplexers select the input channels to be converted from the signals available in this
product.
The exact number of analog input channels and the available connection to port pins
depend on the employed product type (see also Table 19-10). A summary of channels
enclosing all versions of the XMC4500 can be found in Table 19-12.
Input channels marked PDD provide a pull-down device for pull-down diagnostics.
Input channels marked noAltref cannot select the alternate reference voltage from
channel 0 of the corresponding converter.
Table 19-12 Analog Connections in the XMC4500

Signal Dir. Source/Destin. Description
VAREF I VAREF1 / positive analog reference
VAREF2
VAGND I VAGND1 / negative analog reference
VAGND2
G0CH0 I P14.0 analog input channel 0 of group 0
G0CH7 (PDD) I P14.7 analog input channel 7 of group 0

XMC4500
XMC4000 Family
Table 19-12 Analog Connections in the XMC4500 (contd)


XMC4500
XMC4000 Family
19.14.3 Digital Module Connections in the XMC4500

The VADC module accepts a number of digital input signals and generates a number of
output signals. This section summarizes the connection of these signals to other on-chip
modules or to external resources via port pins.
Table 19-13 Digital Connections in the XMC4500

Gate Inputs for Each Group
VADC.GxREQGTA I CCU40.ST3 Gating input A
VADC.GxREQGTB I CCU41.ST3 Gating input B
VADC.GxREQGTC I CCU40.SR0 Gating input C
VADC.GxREQGTD I CCU41.SR1 Gating input D
VADC.GxREQGTE I CCU80.ST3A Gating input E
VADC.GxREQGTF I CCU80.ST3B Gating input F
VADC.GxREQGTG I CCU81.ST3A Gating input G
VADC.GxREQGTH I CCU81.ST3B Gating input H
VADC.G0REQGTI I (s) DAC0.SGN Gating input I
VADC.GxREQGTJ I (s) LEDTS.FN Gating input J
VADC.G0REQGTK I (s) VADC.G1BFLOUT0 Gating input K
VADC.G0REQGTL I (s) VADC.G3SAMPLE Gating input L
VADC.GxREQGTM I CCU80.SR0 Gating input M
VADC.GxREQGTN I CCU80.SR1 Gating input N
VADC.GxREQGTO I ERU1.PDOUT0 Gating input O
VADC.GxREQGTP I ERU1.PDOUT1 Gating input E

XMC4500
XMC4000 Family
Table 19-13 Digital Connections in the XMC4500 (contd)

VADC.GxREQGTyS O VADC.GxREQTRyP Selected gating signal of the
1)
EL respective source
Gate Inputs for Global Background Source
VADC.BGREQGTA I CCU40.ST3 Gating input A, background source
VADC.BGREQGTB I CCU41.ST3 Gating input B, background source
VADC.BGREQGTC I CCU40.SR0 Gating input C, background source
VADC.BGREQGTD I CCU41.SR1 Gating input D, background source
VADC.BGREQGTE I CCU80.ST3A Gating input E, background source
VADC.BGREQGTF I CCU80.ST3B Gating input F, background source
VADC.BGREQGTG I CCU81.ST3A Gating input G, background source
VADC.BGREQGTH I CCU81.ST3B Gating input H, background source
VADC.BGREQGTI I (s) DAC0.SGN Gating input I, background source
VADC.BGREQGTJ I (s) LEDTS.FN Gating input J, background source
VADC.BGREQGTK I (s) VADC.G1BFLOUT0 Gating input K, background source
VADC.BGREQGTL I (s) - Gating input L, background source
VADC.BGREQGTM I CCU80.SR0 Gating input M, background source
VADC.BGREQGTN I CCU80.SR1 Gating input N, background source
VADC.BGREQGTO I ERU1.PDOUT0 Gating input O, background source
VADC.BGREQGTP I ERU1.PDOUT1 Gating input E, background source
VADC.BGREQGTSE O VADC.BGREQTRP1 Selected gating signal
)
L
Trigger Inputs for Each Group
VADC.GxREQTRA I CCU40.SR2 Trigger input A
VADC.GxREQTRB I CCU40.SR3 Trigger input B
VADC.GxREQTRC I CCU41.SR2 Trigger input C
VADC.GxREQTRD I CCU41.SR3 Trigger input D
VADC.GxREQTRE I CCU42.SR3 Trigger input E
VADC.GxREQTRF I CCU43.SR3 Trigger input F
VADC.GxREQTRG I - Trigger input G
VADC.GxREQTRH I - Trigger input H
VADC.GxREQTRI I (s) CCU80.SR2 Trigger input I

XMC4500
XMC4000 Family

VADC.GxREQTRJ I (s) CCU80.SR3 Trigger input J
VADC.GxREQTRK I (s) CCU81.SR2 Trigger input K
VADC.GxREQTRL I (s) CCU81.SR3 Trigger input L
VADC.GxREQTRM I ERU1.IOUT0 Trigger input M
VADC.G0REQTRN I ERU1.IOUT1 Trigger input N
VADC.G0REQTRO I POSIF0.SR1 Trigger input O
VADC.GxREQTRyP I VADC.GxREQGTyS Extend triggers to selected gating
EL1) input of the respective source
VADC.GxREQTRyS O - Selected trigger signal of the
EL respective source
Trigger Inputs for Global Background Source
VADC.BGREQTRA I CCU40.SR2 Trigger input A, background source
VADC.BGREQTRB I CCU40.SR3 Trigger input B, background source
VADC.BGREQTRC I CCU41.SR2 Trigger input C, background source
VADC.BGREQTRD I CCU41.SR3 Trigger input D, background source
VADC.BGREQTRE I CCU42.SR3 Trigger input E, background source
VADC.BGREQTRF I CCU43.SR3 Trigger input F, background source
VADC.BGREQTRG I - Trigger input G, background source
VADC.BGREQTRH I - Trigger input H, background source
VADC.BGREQTRI I (s) CCU80.SR2 Trigger input I, background source
VADC.BGREQTRJ I (s) CCU80.SR3 Trigger input J, background source
VADC.BGREQTRK I (s) CCU81.SR2 Trigger input K, background source
VADC.BGREQTRL I (s) CCU81.SR3 Trigger input L, background source
VADC.BGREQTRM I ERU1.IOUT0 Trigger input M, background source
VADC.BGREQTRN I ERU1.IOUT1 Trigger input N, background source

XMC4500
XMC4000 Family

VADC.BGREQTRO I POSIF0.SR1 Trigger input O, background source
VADC.BGREQTRP I VADC.BGREQGTS Extend triggers to selected gating
EL1) input of the background source
VADC.BGREQTRSE O - Selected trigger signal of the
L background source
System-Internal Connections
VADC.G0SAMPLE O VADC.G1REQGTL Indicates the input signal sample
phase
phase
phase
phase
VADC.G0ARBCNT O CCU40.IN3G Outputs a (count) pulse for each
arbiter round
arbiter round
arbiter round
arbiter round
VADC.GxSR0 O NVIC, GPDMA Service request 0 of group x
VADC.GxSR1 O NVIC, GPDMA Service request 1of group x
VADC.GxSR2 O NVIC, GPDMA Service request 2 of group x
VADC.G0SR3 O NVIC, GPDMA Service request 3 of group 0
CCU80.IN0F
CCU81.IN0J
CCU81.IN1J
CCU81.IN2J
CCU81.IN3J

XMC4500
XMC4000 Family

VADC.C0SR0 O NVIC, GPDMA Service request 0 of common block
ERU1.OGU01 0
POSIF0.IN2C
ERU1.OGU11 0
POSIF1.IN2C
ERU1.OGU21 0
ERU1.OGU31 0
VADC.EMUX00 O GPIO Control of external analog
VADC.EMUX01 O GPIO multiplexer interface 0
VADC.EMUX02 O GPIO
VADC.EMUX10 O GPIO Control of external analog
VADC.EMUX11 O GPIO multiplexer interface 1
VADC.EMUX12 O GPIO
VADC.G0BFLOUT0 O VADC.G1REQGTK Boundary flag 0 output of group 0
VADC.BGREQGTK
CCU41.IN0L
CCU80.IN0I
CCU43.IN0H
CCU43.IN1H
POSIF0.IN0C
POSIF1.IN0C
CCU43.IN2H
CCU43.IN3H
VADC.GxBFL0 O - Boundary flag 0 level of group x
VADC.GxBFSEL0 I 0 Boundary flag 0 (group x) source
select
VADC.GxBFDAT0 I 0 Boundary flag 0 (group x) alternate
data

XMC4500
XMC4000 Family

CCU41.IN2L
CCU80.IN1I
VADC.G1BFLOUT1 O POSIF0.IN1C Boundary flag 1 output of group 1
POSIF1.IN1C
VADC.G2BFLOUT1 O - Boundary flag 1 output of group 2
select
data
CCU41.IN3L
CCU80.IN2I
VADC.G1BFLOUT2 O POSIF0.EWHEA Boundary flag 2 output of group 1
POSIF1.EWHEA
select
data
CCU80.IN3I
ERU1.0B2
ERU1.2B2
VADC.G1BFLOUT3 O ERU1.1B2 Boundary flag 3 output of group 1
ERU1.3B2

XMC4500
XMC4000 Family

select
data
1) Internal signal connection.

XMC4500
XMC4000 Family
Delta-Sigma Demodulator (DSD)
20 Delta-Sigma Demodulator (DSD)

The Delta-Sigma Demodulator module (DSD) of the XMC4500 provides a series of
digital input channels accepting data streams from external modulators using the
Delta/Sigma (DS) conversion principle.
The on-chip demodulator channels convert these inputs to discrete digital values.
The number of inputs and DSD channels depends on the chosen product type (please
refer to Interconnects on Page 20-39).
Table 20-1 Abbreviations used in the DSD Chapter

ADC Analog to Digital Converter
DMA Direct Memory Access (controller)
DNL Differential Non-Linearity (error)
DS Delta-Sigma (conversion principle)
INL Integral Non-Linearity (error)
LSBn Least Significant Bit: finest granularity of the analog value in digital
format, represented by one least significant bit of the conversion result
with n bits resolution (measurement range divided in 2n equally
distributed steps)
OSR Oversampling Ratio
PWM Pulse Width Modulation
20.1 Overview
Each converter channel can operate independent of the others, controlled by a
dedicated set of registers. The results of each channel can be stored in a dedicated
channel-specific result register.
The on-chip filter stages generate digital results from the selected modulator signal.
The DSD accepts data from different types of external modulators. Their data streams
can be fed to selectable input pins.
Features
The following features describe the functionality of a Delta-Sigma Converter:
Options to connect external standard Delta-Sigma modulators
Selectable data stream inputs
Selectable DS clock input or output
Main demodulator (concatenated hardware filter stages)

DSD, V1.3 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Configurable comb filter with decimation rates of 4256

Automatic offset compensation
Parallel auxiliary demodulator for limit checking
Configurable comb filter with decimation rates of 432
Two-level boundary comparator
Carrier signal generator for resolver applications
Table 20-2 DSD Applications

Use Case DSD Application
Galvanically decoupled phase current measurement Motor control,
Power
conversion
Resolver signal evaluation and generation of excitation signal Motor control
Adjustable resolution for input signals with wide dynamic range Motorcontrol,
Metering,
Medical

XMC4500
XMC4000 Family
Dec.: 4...32
Service Req.
Digital Auxiliary Filter
Input and Comparator
Input Dig. Result
Select Dec.: 4...256
Adjust Service Req.
Main Filter Chain
Dig. Result
Dec.: 4...32
Service Req.
Digital Auxiliary Filter
Input and Comparator
Input Dig. Result
Select Dec.: 4...256
Adjust Service Req.
Main Filter Chain
Dig. Result
Digital
Output
PWM
Carrier Generator
MC_DSADC_CH4
Figure 20-1 DSD Module Overview

XMC4500
XMC4000 Family
20.2 Introduction and Basic Structure

The Delta-Sigma Analog to Digital Converter module of the XMC4500 provides several
channels with a main and an auxiliary demodulator including configurable filters for
decimation (see Figure 20-2).
Several types of external modulators can be connected to the input path. The modulator
clock signal can be generated internally or can be fed from an external clock source.
The main chain of digital filters builds the demodulator which produces result values at
a configurable output rate. The elements of the filter chain can be selected according to
the requirements of the application. The filter chain configuration determines the
attenuation and delay properties of the filter. The decimation at a configurable rate
reduces the input sampling rate to a lower result data rate.
The configurable comb filter provides the basic filtering and decimation with a selectable
decimation rate.
The integrator accumulates a configurable amount of result values. The number of
samples is programmable or can be controlled by a hardware signal. This function
supports resolver applications to get the baseband signal for the motor position
calculation. Furthermore, the integrator can be also used in shunt current measurement
applications.
A smaller but quicker parallel auxiliary filter with a comparator supports limit checking,
e.g. for overcurrent detection. Two limit values can be defined to restrict the generation
of service requests to result values within a configurable area. This saves CPU
performance and/or DMA bandwidth.
A carrier signal can be generated to support resolver applications.
The on-chip carrier signal generator produces a selectable output signal (sine, triangle,
rectangle) which can be used to drive a resolver. Synchronization of each input signal to
the carrier signal ensures correct integration of the resolver input signals.
Service requests can be generated to trigger DMA transfers or to request CPU service.
The basic module clock fDSD is connected to the system clock signal fPB.

XMC4500
XMC4000 Family
Dec.: 4...32 Service

Request
Comb Compa-
Filter rator
Dec.: 4...256
Digital Digital
Input Input Result
Comb Data
Select/ Integrator
Filter Shift
Adjust
Bypass Bypass
MC_DSADC_OVERVM
Figure 20-2 DSD Structure Overview
20.3 Configuration of General Functions

Several parameters can be configured to adapt the functionality of the DSD to the
requirements of the actual application.
The DSD of the XMC4500 can operate in several configurations:
Using an external modulator, running on a clock generated on-chip
Using an external modulator, running on its own clock
The global configuration register GLOBCFG selects the source for the internal clock
signal which can be used to drive the modulators (alternatively, a clock signal can be
input from an external modulator).
The global run control register GLOBRC controls the general operation of the available
channels.
20.4 Input Channel Configuration

The input data for a channel can be obtained from different sources:
External Modulator Without Clock Source: This type of modulator requires a
modulator clock signal. This clock signal is provided by the XMC4500, the data
stream produced by the modulator is input as a digital signal.
External Modulator With Clock Source: This type of modulator generates the
modulator clock signal along with the data stream. In this case, both the modulator
clock and the data stream produced by the modulator are input as digital signals.

XMC4500
XMC4000 Family
Note: An external modulator can be used, in particular, in systems where high voltages
are to be sampled. This allows for galvanic decoupling.
Several input pins can be selected.
The modulator clock can be generated in different ways:
The modulator clock can be derived on-chip from the module clock and is output via
a modulator clock pin to be used by an external modulator.
The external modulator can generate the clock signal which is then input via one of
the modulator clock pins.
The used modulator clock also drives the on-chip carrier generator. This enables
synchronous operation of carrier generator and integrator.
A trigger signal can be input from a selectable pin. This trigger signal can be used for
different purposes:
Integration trigger:
The external signal defines the integration window, i.e. the timespan during which
result values are integrated.
Timestamp trigger:
The external signal requests the actualization of the timestamp register.
Input multiplexer trigger:
The external signal requests the switching of the analog input multiplexer to the next
lower input or to the defined start value, respectively.
Service request gate:
Service requests for the main filter chain can be restricted to the high or low times of
the selected trigger signal.
The figure below summarizes these three signal paths and indicates the source of the
corresponding control information.

XMC4500
XMC4000 Family
DICFG MODCFG GLOBCFG

DSRC CSRC TRSEL STROBE DIVM MCSEL
Data Strobe
Data
Data
Sampling Data Value
0
Clock
Clock
Control fDSD
Carrier Gen.
Integrator
.
Trigger
Timestamp
.
.
MUX ctrl.
S. Request
XOR
ITR TSTR IN
SRGM
MODE MODE MODE
DICFG MODCFG FCFGC
MC_DSD_INPUTPATHS
Figure 20-3 Input Path Summary
20.4.1 Modulator Clock Selection and Generation

The modulator clock signal can be generated on-chip by a programmable prescaler
(clock output) or can be generated by an external modulator and be input through a pin
(clock input). For internal clock generation, the on-chip clock signal is enabled by bitfield
MCSEL.

XMC4500
XMC4000 Family
Clock
Outputs
50 %
prescaler
0 duty cycle
fMOD
N:1 2:1
Modulator Clock
fDSD
MCSEL
To
Demodulator
DIVM
MC_DSADC_ MODCLOCKM
Figure 20-4 Modulator Clock Configuration

The selected clock source is synchronized to the module clock. A configurable edge
detector selects the clock signal edges that generate the data strobes which read the
next input data and trigger the demodulator (see Figure 20-5).
Note: To ensure proper synchronization, an external clock signal must have high/low
phases of at least one period of fDSD to be safely synchronized (fIN < fDSD/2).
When the clock signal is generated on-chip (see Figure 20-4) and is selected as an
output signal at a connected pin (see connection list in Section 20.12), this clock signal
can drive an external modulator.
Bitfield CSRC in register DICFGx (x = 0 - 3) selects the clock source for each channel.
Bitfield STROBE selects the clocking mode, i.e. the clock edges that put a new input data
sample into the filter chain.

XMC4500
XMC4000 Family
Data Strobe for

Demodulator
Sync
fMOD
CSRC
fDSD
STROBE
MC_DSADC_DSTROBEU
Figure 20-5 Demodulator Data Strobe Selection
20.4.2 Input Data Selection

The data stream of an external modulator can be input from a selectable pin. This signal
can optionally be inverted.
The selected input datastream is converted to the comb filters input format.

XMC4500
XMC4000 Family
Modulator
Data Input Data Samples
(DINx)
Input
Select/
Modulator Adjust Sample Clock
Clock Signal
(MCLKx)
Module Clock
CLK Divider
MC_DSADC_ INPUT_ADJUSTM
Figure 20-6 Input Control Unit

All options are configured by the demodulator input configuration register DICFGx (x =
0 - 3).
20.4.3 External Modulator

The input data stream can be obtained from an external modulator via a selectable pin.
This modulator may, for example, be connected to a high driving voltage and be
galvanically decoupled.
In this case, the modulators data output is connected to the selected pin. The Input
Select/Adjust block will then format the selected input data stream to the format required
by the subsequent filter.
The source of the 1-bit input data can be selected as well as the source of the sample
clock signal. The data strobe that enters a new value into the filter chain can be
generated upon configurable clock edges of the modulator clock to support different
types of modulators.
20.4.4 Input Path Control

The input for the DSD is fed through several stages before being evaluated and filtered.
Registers MODCFGx and DICFGx select the available options for these signal stages.
The following features can be configured:
Signal input pin selection

XMC4500
XMC4000 Family
Generation method of input data

Modulator clock source and/or frequency
Trigger input pin selection
With this flexibility the DSD can be adjusted to many available types of modulators.
20.5 Main Filter Chain

The result data words are generated by feeding the input data stream through a chain of
filter elements and decimating it by a selectable ratio.
Decim.: N
Digital Digital
Input x(n) Output y(m)
Comb Result
N:1 Integrator
Filter Register
Input Output
Sample Sample
Rate fS Rate fS/N
Bypass Bypass
MC_DSADC_MAINFILTER
Figure 20-7 Structure of the Main Filter Chain

The elements of the filter can be bypassed, i.e. the filter chain is configurable and its
behavior can be adapted to the requirements of the actual application. This comprises
the frequency attenuation as well as the total decimation rate.
Note: Only configure or reconfigure filter parameters while the channel is inactive. After
the configuration, start the channel by setting the corresponding bit CHxRUN.
20.5.1 Comb Filter

The comb filter (a.k.a. SINC filter) is a simple but very efficient low-pass filter. Up to three
comb filter stages can be cascaded to improve the frequency characteristics. The
number of active filter stages can be selected (Comb1, Comb2, Comb3) to find the
optimum tradeoff between delay and frequency characteristics.
In addition, a combined mode can be selected (CombF) which represents a compromise
between a 2-stage and a 3-stage filter.
To synchronize filters of different channels with fine granularity, the decimation counter
starts from an arbitrary start value. This start value can be different from the decimation
factor and is loaded only once when the counter is started.

XMC4500
XMC4000 Family
The decimation counter is also restarted (i.e. loaded with the start value) when the
selected integration trigger event occurs (see Section 20.5.2).
The decimation factor can be selected in a wide range from 4 to 256.
Table 20-3 Data Shifter Position1) Dep. on Filter Mode and Decimation
Decimation Comb1 Comb2 Comb3 CombF
4 - 32 15:0 15:0 15:0 15:0
33 - 40 15:0 15:0 16:1 * 15:0
41 - 50 15:0 15:0 17:2 * 15:0
51 - 64 15:0 15:0 18:3 * 15:0
65 - 80 15:0 15:0 19:4 * 15:0
81 - 101 15:0 15:0 20:5 * 15:0
102 - 128 15:0 15:0 21:6 * 15:0
129 - 181 15:0 15:0 22:7 * 16:1 *
182 - 203 15:0 16:1 * 23:8 * 17:2
204 - 256 15:0 16:1 24:9 * 17:2
1) * indicates a change. Input data width is 1 bit.
20.5.2 Integrator Stage

The integrator integrates the result values generated during the defined integration
window by adding a configurable number of values to build the final result value. The
integration window can be started triggered by an internal or external signal.
A configurable number of values can automatically be discarded after the trigger before
the integration window is started. This positions the integration window exactly into a
timeframe where the filter is stable or where the signal to be measured is free of system-
generated noise.
Integration can be used to measure currents through shunt resistors at defined positions
in the signal waveform. It also can remove the carrier signal component in resolver
applications. In this case, the values to be integrated can be rectified to yield the
maximum amplitude of the receiver signal. The delay between the carrier signal
(generated by the on-chip carrier generator) and the received position signals can be
compensated automatically. Please refer to Section 20.9.
Upon the selected integration trigger (INTEN becomes 1) the integration counter starts
counting. After NVALDIS values the integrator is started and the counter is reset (if
NVALDIS is zero the integration starts immediately). After NVALINT values the
integration result is stored in the result register and the integrator and the counter are

XMC4500
XMC4000 Family
cleared. As selected by bit IWS the integration window is either restarted or the
integration is stopped (INTEN = 0).
Also, the decimation counter of the comb filter is restarted, i.e. loaded with its start value
(see Section 20.5.1).
Sample
Operation
idle discard integrate integrate integrate idle
int. control
Sample
Operation
ext. control
idle discard integrate integrate int idle
Trigger active
MC_DSADC_INTEGRATOR
Figure 20-8 Integrator Operation

The external integration trigger signal is selected by bitfield TRSEL in register DICFGx
(x = 0 - 3). Bit ITRMODE selects the transition of the selected signal to generate a trigger
event. This event starts the integrator by setting bit INTEN. The inverse transition of the
selected signal clears bit INTEN.
Note: When the integration window is closed by an external signal (INTEN cleared by
inverse trigger), the integrator and the counter are cleared also.
20.6 Auxiliary Filter

The parallel auxiliary filter uses a comb filter for decimation, similar to the one used in
the main filter chain. The decimation rate is restricted to 32. This also reduces the filter
delay, so the auxiliary filter can be used to supervise the input signal and detect
abnormal input values earlier than the main filter chain.
The subsequent comparator provides automatic limit checking by comparing each result
to two configurable reference values. The comparator can generate a separate service
request.
The two values are defined in the boundary select register and determine the valid result
value band if limit checking is enabled.

XMC4500
XMC4000 Family
2 n -1
Result Range
Upper Boundary
Lower Boundary
Results outside band Results inside band
MC_VADC_LIMITBAND
Figure 20-9 Result Monitoring through Limit Checking

A result value is considered inside the defined band when both of the following
conditions are true:
the value is less than or equal to the selected upper boundary
the value is greater than or equal to the selected lower boundary
The result range can also be divided into two areas:
To select the lower part as valid band, set the lower boundary to the minimum value
(000H) and set the upper boundary to the highest intended value.
To select the upper part as valid band, set the upper boundary to the maximum value
(FFFH) and set the lower boundary to the lowest intended value.
The auxiliary filter can generate two types of output:
Service requests, optionally restricted by the comparators
Range signals, indicating when the results are above the upper limit (SAULx) or
below the lower limit (SBBLx)
An alarm event can be generated when a new conversion result becomes available.
Alarm events can be restricted to result values that are inside or outside a user-defined
band (see Figure 20-9). This feature supports automatic range monitoring and
minimizes the CPU load by issuing service requests only under certain conditions. For
example, an input value can be monitored and an alarm indicates a certain threshold.
Note: Limit checking uses the parallel auxiliary filter at a low decimation rate and,
therefore, the alarm is generated earlier than the threshold values are seen at the
output of the regular filter chain.
Alarm events can also be suppressed completely (see FCFGAx (x = 0 - 3)).
The range signals are generated independent of service requests.

XMC4500
XMC4000 Family
Signal SAUL is active while the results are above the upper limit,
signal SBLL is active while the results are below the lower limit.
Upper Limit
Decim.: N
Digital > upper
Input x(n) Comb
N:1 Select
Filter
Input < lower
Sample
Rate f S
Lower Limit
Figure 20-10 Comparator Structure
20.7 Conversion Result Handling

The DSD preprocesses the conversion result data before storing them for retrieval by the
CPU or a DMA channel.
Conversion result handling comprises the following functions:
Filtering and Post-Processing
Storage of Conversion Results
Result Event Generation
A programmable offset is subtracted automatically from each result value before being
stored in the result register. This offset value is stored in the corresponding register
OFFMx. It may be an arbitrary value defined by the application. Usually, the offset value
is measured for each channel separately.
The result values of the auxiliary filter are also available for the application, although in
many cases the comparator output signal will be sufficient.
The conversion result values are stored in result register RESMx and RESAx,
respectively.

The DSD can activate service request output signals to issue an interrupt, to trigger a
DMA channel, or to trigger other on-chip modules.
Service request connections can be found in Table 20-7 Digital Connections in the
XMC4500 on Page 20-40.

XMC4500
XMC4000 Family
Several events are assigned to each service request output. Service requests can be
generated by two types of events:
Result events: indicate a new valid result in a result register. Usually, this triggers a
read action by the CPU (or DMA). Result events are generated at the output rate of
the configured filter chain.
Alarm events: indicate that a conversion result value is within a programmable value
range. This offloads the CPU/DMA from background tasks, i.e. a service request is
only activated if the specified conversion result range is met or exceeded.
Each event is indicated by a dedicated flag that can be cleared by software. If a service
request is enabled for a certain event, the service request is generated for each event,
independent of the status of the corresponding event indication flag. This ensures
efficient DMA handling of DSD events (the event can generate a service request without
the need to clear the indication flag).
Note: The Service Request Registers provide a set of bits for each available channel.
The number of available channels depends on the chosen device type.
20.9 Resolver Support

Resolver applications determine the rotation angle by evaluating the signals from two
orthogonally placed coils. These coils are excited by the magnetic field of a third coil.
The DSD can read the two return signals using two input channels and can also generate
the excitation sine signal (carrier). It also provides synchronization logic to compensate
the delay between the generated carrier signal and the received position signals. The
integrator stage converts the carrier-based return signals to position-based values
(carrier cancellation).
20.9.1 Carrier Signal Generation

The carrier signal generator (CG) outputs a PWM signal that induces a sine signal in the
excitation coil of the resolver. Alternatively, it can generate PWM patterns that resemble
triangle or square signals (see Figure 20-11). The polarity of the carrier signal can be
selected.
A carrier signal period consists of 32 steps. Each step equals a PWM period of 32 cycles.
Bit-reverse generation mode increases the frequency spectrum to yield a smoother
induced sine signal. This is done by distributing the 0 and 1 bits over the 32 cycles of a
PWM period.
The generated pattern is actually a cosine signal, i.e. it starts at the maximum output
value. This is advantageous if the output pin is pulled high before the carrier signal is
generated. In case of a pull-down the inverted output signal should be selected.

XMC4500
XMC4000 Family
UP_DOWN=0 UP_DOWN=0 UPDOWN=1 UPDOWN=1

SIGN=0 SIGN=1 SIGN=1 SIGN=0
MC_DSADC_ CPG_EXAMPLE
Figure 20-11 Example Pattern/Waveform Outputs
20.9.2 Return Signal Synchronization

In a resolver, the received return signals are induced by the carrier signal and their
amplitudes are modulated with the sine and cosine magnitudes corresponding to the
current resolver position. These amplitudes are determined by integrating the return
signals over a carrier signal period.
To properly integrate their magnitude, the return signals must be rectified. For this
purpose the carrier generator provides the sign information of the generated carrier
signal (SGNCG in register CGCFG).
Alternatively, an external carrier signal generator can be used. If this generator delivers
a sign signal, this can be input to a pin and is then used as external carrier sign signal.
If no sign signal is available, the carrier signal itself can be converted by the next
adjacent input channel and its sign signal is then used as alternate carrier sign signal.
The rectification of the received signals must be delayed to compensate the round trip
delay through the system (driver, resolver coils, cables, etc.). For the rectification, the
received values are multiplied with the delayed carrier sign signal (SGND in register
RECTCFGx (x = 0 - 3)). This synchronization is done for each channel separately, to
achieve the maximum possible amplitudes for each signal.

XMC4500
XMC4000 Family
The delay is realized with the sign delay counter SDCOUNT. SDCOUNT is cleared and
started upon a falling edge of the carrier generators sign signal (SGNCG), i.e. at the
begin of the positive halfwave of the carrier signal. After counting SDPOS results from
the filter chain, also the rectification signal (SGND) is cleared, indicating positive values
from now on. After counting SDNEG values, the rectification signal is set, indicating
negative values (see also Figure 20-12).
The compare values SDPOS and SDNEG are stored by the application software.
SDPOS is the delay value that accounts for the resolver signals round trip delay. This
delay is constantly measured by capturing the current counter value into bitfield SDCAP
when the first positive result (after negative results) is received in the respective channel.
Software can read these value and compute a delay value e.g. by averaging a series of
measured values to compensate noise. The delay for the negative halfwave (SGND = 0)
is determined by adding the duration of a carrier signal halfwave. This value is written to
bitfield SDNEG.
A new captured value is indicated by setting the flag SDVAL. This flag is cleared when
reading register CGSYNCx.
Capturing a new value can trigger a service request. The service request line of the
auxiliary channel is used for this purpose. This alternate request source is selected by
bitfield SRGA in register FCFGAx (x = 0 - 3).
SDNEG
SDPOS/NEG
COMP
SDPOS
SDCOUNT
SIGNCG
SDCAP
SIGND
Registers Timing Example
MC_DSADC_SIGNDELAY
Figure 20-12 Sign Delay Example

XMC4500
XMC4000 Family
20.10 Time-Stamp Support

Some applications need to determine the result value at certain points of time inbetween
two regular output values. The interpolation algorithm needs to determine the position of
the required point of time in relation to the regular results.
This interpolation is supported by providing a timestamp that marks the delay since the
last regular output value. This timestamp is composed of:
the last regular result value
the current decimation counter value
the current integrator counter value
All timestamp information is combined into one register, so the complete timestamp can
easily be stored away by a single DMA transfer. The timestamp information is captured
into register TSTMPx upon a hardware trigger. For this purpose, the trigger signal is
used, which is selected by bitfield TRSEL in register DICFGx (x = 0 - 3). Bitfield
TSTRMODE selects the edge(s) that capture timestamp information.
20.11 Registers
The DSD is built from a series of channels that are controlled in an identical way. This
makes programming versatile and scalable. The corresponding registers, therefore,
have an individual offset assigned (see Table 20-5). The exact register location is
obtained by adding the respective register offset to the base address (see Table 20-4)
of the corresponding channel.
Due to the regular structure, several registers appear within each channel. This is
indicated in the register overview table by placeholders:
0X##H means: x 0100H + 01##H, for x = 0 - 3

DSD 4000 8000H 4000 BFFFH

ID Module Identification Register 0008H U, PV BE 20-21
CLC Clock Control Register 0000H U, PV PV 20-21
OCS OCDS Control and Status Register 0028H U, PV PV 20-22
GLOBCFG Global Configuration Register 0080H U, PV U, PV 20-23

XMC4500
XMC4000 Family

GLOBRC Global Run Control Register 0088H U, PV U, PV 20-24
MODCFGx Modulator Configuration Register x 0X00H U, PV U, PV 20-25
(x = 0 - 3)
DICFGx Demodulator Input Configuration 0X08H U, PV U, PV 20-26
(x = 0 - 3) Register x
BOUNDSELx Global Boundary Select Register 0X28H U, PV U, PV 20-32
(x = 0 - 3
IWCTRx Integration Window Control Register 0X20H U, PV U, PV 20-31
(x = 0 - 3)
FCFGCx Filter Configuration Register Main 0X14H U, PV U, PV 20-28
(x = 0 - 3) Filter
FCFGAx Filter Configuration Register 0X18H U, PV U, PV 20-29
(x = 0 - 3) Auxiliary Filter
RESMx Result Register x Main Filter 0X30H U, PV U, PV 20-32
(x = 0 - 3)
OFFMx Offset Register x Main Filter 0X38H U, PV U, PV 20-33
(x = 0 - 3)
RESAx Result Register x Auxiliary Filter 0X40H U, PV U, PV 20-33
(x = 0 - 3)
EVFLAG Event Flag Register 0XE0H U, PV U, PV 20-34
EVFLAGCLR Event Flag Clear Register 0XE4H U, PV U, PV 20-34
CGCFG Carrier Generator Configuration 00A0H U, PV U, PV 20-35
Register
RECTCFGx Rectification Configuration Register 0XA8H U, PV U, PV 20-37
(x = 0 - 3)
CGSYNCx Carrier Generator Synchronization 0XA0H U, PV U, PV 20-38
(x = 0 - 3) Register
TSTMPx Time Stamp Register 0X50H U, PV U, PV 20-39
(x = 0 - 3)
20.11.1 Module Identification

The module identification register indicates the version of the DSD module that is used
in the XMC4500.

XMC4500
XMC4000 Family
ID
Module Identification Register (0008H) Reset Value: 00A4 C0XXH
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
r r r

(00A4H = DSD)
20.11.2 System Registers

A set of standardized registers provides general access to the module and controls basic
system functions.
The Clock Control Register CLC allows the programmer to adapt the functionality and
power consumption of the module to the requirements of the application. Register CLC
controls the module clock signal and the reactivity to the sleepde signal.
CLC
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
E DIS DIS
0 0 0 0 0 0 0 0 0 0 0 0 0
DIS S R
r r r r r r r r r r r r rw r r rw

XMC4500
XMC4000 Family

0B On request: enable the module clock
1B Off request: stop the module clock
0B Module clock is enabled
1B Off: module is not clocked
Used to control modules reaction to sleep mode.
0B Sleep mode request is enabled and functional
1B Module disregards the sleep mode control signal
The OCDS control and status register OCS controls the modules behavior in suspend
mode (used for debugging).
The OCDS Control and Status (OCS) register is cleared by Debug Reset.
The OCS register can only be written when the OCDS is enabled.
If OCDS is being disabled, the OCS register value will not change.
When OCDS is disabled the OCS suspend control is ineffective.
Write access is 32 bit wide only and requires Supervisor Mode.
OCS
OCDS Control and Status Register (0028H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SUS SUS
0 0 SUS 0 0 0 0 0 0 0 0
STA _P
r r rh w rw r r r r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


XMC4500
XMC4000 Family

SUS [27:24] rw OCDS Suspend Control
Controls the sensitivity to the suspend signal coming from
the OCDS Trigger Switch (OTGS)
0000BWill not suspend
0001BHard suspend: Clock is switched off immediately.
0010BSoft suspend channel 0

Others Reserved
Note: In soft suspend mode, the respective channel is
stopped after the next result has been stored.
SUS_P 28 w SUS Write Protection
SUS is only written when SUS_P is 1, otherwise
SUSSTA 29 rh Suspend State
0B Module is not (yet) suspended
1B Module is suspended
20.11.3 General Registers

The global configuration register GLOBCFG selects the source for the internal clock
signal which can be used to drive the modulators (alternatively, a clock signal can be
input from an external modulator).
GLOBCFG
Global Configuration Register (0080H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 MCSEL
r r r r r r r r r r r r r rw

XMC4500
XMC4000 Family

MCSEL [2:0] rw Modulator Clock Select
Selects the source for the on-chip clock source for
the modulator clock.
000B Internal clock off, no source selected
001B fDSD
All other combinations are reserved.
GLOBRC
Global Run Control Register (0088H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CH3 CH2 CH1 CH0
0 0 0 0 0 0 0 0 0 0 0 0
RUN RUN RUN RUN
r r r r r r r r r r r r rw rw rw rw

CHxRUN x rw Channel x Run Control
x=0-3 Each bit (when set) enables the corresponding
demodulator channel.
0B Stop channel x
1B Demodulator channel x is enabled and runs
When CHxRUN is set, all filter blocks are cleared.
20.11.4 Input Path Control

The modulator configuration register selects the Divider factor for modulator clock.

XMC4500
XMC4000 Family
MODCFGx (x = 0 - 3)
Modulator Configuration Register x
(x * 0100H + 0100H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
D
0 0 0 0 0 0 0 0 0 0 0 DIVM
WC
r r r r r r r r w r r r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

DIVM [19:16] rw Divider Factor for Modulator Clock
Defines the operation frequency for the modulator,
derived from the selected internal clock source.1)
0H fMOD = fCLK / 2
1H fMOD = fCLK / 4
2H fMOD = fCLK / 6
...
FH fMOD = fCLK / 32
DWC 23 w Write Control for Divider Factor
0B No write access to divider factor
1B Bitfield DIVM can be written
1) The limit values for fMOD must not be exceeded when selecting the module input frequency and the prescaler
setting.
The demodulator input configuration register selects input signal sources for each
channel:
Source of data stream
Trigger signal source and mode
Sample clock source
Data strobe generation mode

XMC4500
XMC4000 Family
DICFGx (x = 0 - 3)
Demodulator Input Configuration Register x
(x * 0100H + 0108H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SC
0 0 0 0 0 0 0 STROBE CSRC
WC
w r r r r r r r rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
TR TSTR ITR DS
TRSEL 0 0 0 DSRC
WC MODE MODE WC
w rw rw rw w r r r rw

DSRC [3:0] rw Input Data Source Select
000XBDisconnected
0010BExternal, from input A, direct
0011BExternal, from input A, inverted
0100BExternal, from input B, direct
0101BExternal, from input B, inverted
Other combinations are reserved.
Note: Pin association is described in
Section 20.12.2
DSWC 7 w Write Control for Data Selection
0B No write access to data parameters
1B Bitfield DSRC can be written
ITRMODE [9:8] rw Integrator Trigger Mode1)
00B No integration trigger, integrator bypassed
11B No trigger, integrator active all the time
Note: To ensure proper operation, ensure that
bitfield ITRMODE is 00B before selecting any
other trigger mode.

XMC4500
XMC4000 Family

TSTRMODE [11:10] rw Timestamp Trigger Mode2)
00B No timestamp trigger
11B Trigger event upon each edge
TRSEL [14:12] rw Trigger Select
Selects an input for the trigger signal (for integrator,
timestamp, multiplexer control, service request
gating).
Section 20.12.2
TRWC 15 w Write Control for Trigger Parameters
0B No write access to trigger parameters
1B Bitfields TRSEL, TSTRMODE, ITRMODE can
be written
CSRC [19:16] rw Sample Clock Source Select
0000BReserved
0001BExternal, from input A
0010BExternal, from input B
1111BInternal clock
Note: Pin association is described in
Section 20.12.2
STROBE [23:20] rw Data Strobe Generatoion Mode
0000BNo data strobe
0001BDirect clock, a sample trigger is generated
at each rising clock edge
0010BDirect clock, a sample trigger is generated
at each falling clock edge
0011BDouble data, a sample trigger is generated
at each rising and falling clock edge
0100BReserved
0101BDouble clock, a sample trigger is generated
at every 2nd rising clock edge
0110BDouble clock, a sample trigger is generated
at every 2nd falling clock edge
0111BReserved

XMC4500
XMC4000 Family

SCWC 31 w Write Control for Strobe/Clock Selection
0B No write access to strobe/clock parameters
1B Bitfields STROBE, CSRC can be written
1) The integration trigger mode controls bit INTEN in register IWCTRx (x = 0 - 3) and hence the operation of the
integrator:
Bit INTEN is set when ITRMODE = 11B or when the selected trigger signal transition occurs.
Bit INTEN is cleared when ITRMODE = 00B or when the inverse trigger signal transition occurs.
2) The timestamp trigger mode controls capturing the timestamp information to register TSTMPx (x = 0 - 3).
20.11.5 Filter Configuration
FCFGCx (x = 0 - 3)
Filter Configuration Register x, Main Comb Filter
(x * 0100H + 0114H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CFMDCNT CFMSV
rh rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CF
SRGM 0 0 0 CFMC CFMDF
EN
rw r r r rw rw rw

CFMDF [7:0] rw Comb Filter (Main Chain) Decimation Factor
The decimation factor of the Main comb filter is
CFMDF + 1.
Valid values are 03H to FFH (4 to 256).
CFMC [9:8] rw Comb Filter (Main Chain) Configuration
00B Comb1
01B Comb2
10B Comb3
11B CombF
CFEN 10 rw Comb Filter Enable
0B Comb filter disabled and bypassed
1B Enable comb filter

XMC4500
XMC4000 Family

SRGM [15:14] rw Service Request Generation Main Chain
00B Never, service requests disabled
01B While gate (selected trigger signal) is high
10B While gate (selected trigger signal) is low
11B Always, for each new result value
CFMSV [23:16] rw Comb Filter (Main Chain) Start Value
The decimation counter begins counting at value
CFMSV, when started or restarted.
Valid values are 03H to CFMDF (4 to selected
decimation factor).
CFMDCNT [31:24] rh Comb Filter (Main Chain) Decimation Counter
The decimation counter counts the filter cycles until
an output is generated, i.e. the oversampling rate.
FCFGAx (x = 0 - 3)
Filter Configuration Register x, Auxiliary Filter
(x * 0100H + 0118H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
CFADCNT 0 0 0 0 0 0 0 0
rh r r r r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 EGT ESEL SRGA CFAC CFADF
r rw rw rw rw rw

CFADF [7:0] rw Comb Filter (Auxiliary) Decimation Factor
The decimation factor of the Auxiliary comb filter is
CFADF +1.
Valid values are 03H to 3FH (4 to 64). 1)

XMC4500
XMC4000 Family

CFAC [9:8] rw Comb Filter (Auxiliary) Configuration
00B Comb1
01B Comb2
10B Comb3
11B CombF
SRGA [11:10] rw Service Request Generation Auxiliary Filter
00B Never, service requests disabled
01B Auxiliary filter: As selected by bitfield ESEL
10B Alternate source: Capturing of a sign delay
value to register CGSYNCx (x = 0 - 3)
11B Reserved
ESEL [13:12] rw Event Select
Defines when an event for the auxiliary filter is
generated.
00B Always, for each new result value
01B If result is inside the boundary band
10B If result is outside the boundary band
11B Reserved
EGT 14 rw Event Gating
Defines if events for the auxiliary filter are coupled to
the integration window.
0B Separate: generate events according to ESEL
1B Coupled: generate events only when the
integrator is enabled and after the discard
phase defined by bitfield NVALDIS2)
CFADCNT [31:24] rh Comb Filter (Auxiliary) Decimation Counter
The decimation counter counts the filter cycles until
an output is generated, i.e. the oversampling rate.
1) Most probably the maximum value for the OSR will be limited to 32.
2) While the integrator is bypassed, it does not influence the auxiliary channel. The event gating suppresses
service requests, result values are still stored in register RESAx.

XMC4500
XMC4000 Family
IWCTRx (x = 0 - 3)
Integration Window Control Register x
(x * 0100H + 0120H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 NVALINT IWS 0 NVALDIS
r r rw rw r rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
INT
REPVAL REPCNT 0 NVALCNT
EN
rw rh rh r rh

NVALCNT [5:0] rh Number of Values Counted
Counts the number of values until integration is
started (NVALDIS) or completed (NVALINT)
INTEN 7 rh Integration Enable1)
0B Integration stopped. INTEN is cleared at the
end of the integration window, i.e. upon the
inverse trigger event transition of the external
trigger signal.
1B Integration enabled. INTEN is set upon the
defined trigger event.
REPCNT [11:8] rh Integration Cycle Counter
Counts the number of integration cycles if activated
(IWS = 0).
This number is selected via bitfield REPVAL.
REPVAL [15:12] rw Number of Integration Cycles
Defines the number of integration cycles to be
counted by REPCNT if activated (IWS = 0).
The number of cycles is REPVAL+1.
NVALDIS [21:16] rw Number of Values Discarded
Start the integration cycle after NVALDIS values

XMC4500
XMC4000 Family

IWS 23 rw Integration Window SIze
0B Internal control: stop integrator after
REPVAL+1 integration cycles
1B External control: stop integrator when bit
INTEN becomes 0
NVALINT [29:24] rw Number of Values Integrated
Stop the integration cycle after NVALINT+1 values
1) For the control of bit INTEN, see also bitfield ITRMODE in register DICFGx (x = 0 - 3).
BOUNDSELx (x = 0 - 3)
Boundary Select Register x (x * 0100H + 0128H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BOUNDARYU BOUNDARYL
rw rw

BOUNDARYL [15:0] rw Lower Boundary Value for Limit Checking
This (twos complement) value is compared to the
results of the parallel filter.
BOUNDARYU [31:16] rw Upper Boundary Value for Limit Checking
This (twos complement) value is compared to the
results of the parallel filter.
20.11.6 Conversion Result Handling
RESMx (x = 0 - 3)
Result Register x Main Filter (x * 0100H + 0130H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 RESULT
r r r r r r r r r r r r r r r r rh

XMC4500
XMC4000 Family

RESULT [15:0] rh Result of most recent conversion
OFFMx (x = 0 - 3)
Offset Register x Main Filter (x * 0100H + 0138H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 OFFSET

OFFSET [15:0] rw Offset Value
This signed value is subtracted from each result
before being written to the corresponding result
register RESMx.
RESAx (x = 0 - 3)
Result Register x Auxiliary Filter
(x * 0100H + 0140H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 RESULT


XMC4500
XMC4000 Family
20.11.7 Service Request Registers
EVFLAG
Event Flag Register (00E0H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
AL AL AL AL
0 0 0 0 0 0 0 0 0 0 0 0
EV3 EV2 EV1 EV0
r r r r r r r r r r r r rwh rwh rwh rwh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RES RES RES RES
0 0 0 0 0 0 0 0 0 0 0 0
EV3 EV2 EV1 EV0
r r r r r r r r r r r r rwh rwh rwh rwh

RESEVx (x=0-3) x rwh Result Event
0B No result event
1B A new result has been stored in register
RESMx
ALEVx (x=0-9) x+16 rwh Alarm Event
0B No alarm event
1B An alarm event has occurred
EVFLAGCLR
Event Flag Clear Register (00E4H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
AL AL AL AL
0 0 0 0 0 0 0 0 0 0 0 0
EC3 EC2 EC1 EC0
r r r r r r r r r r r r w w w w
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RES RES RES RES
0 0 0 0 0 0 0 0 0 0 0 0
EC3 EC2 EC1 EC0
r r r r r r r r r r r r w w w w

XMC4500
XMC4000 Family

RESECx (x=0-3) x w Result Event Clear
0B No action
1B Clear bit RESEVx
ALECx (x=0-3) x+16 w Alarm Event Clear
0B No action
1B Clear bit ALEVx
Note: Software can set flags RESEVx and ALEVx and trigger the corresponding event
by writing 1 to the respective bit. Writing 0 has no effect.
Software can clear these flags by writing 1 to bit RESECx and ALECx,
respectively.
20.11.8 Miscellaneous Registers
CGCFG
Carrier Generator Configuration Register
(00A0H) Reset Value: 0710 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SGN STE STE
0 STEPCOUNT 0 0 0 BITCOUNT
CG PD PS
r rh rh rh rh r r r rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SIG B CG
RUN 0 0 0 0 0 0 0 DIVCG
POL REV MOD
rh r r r r r r r rw rw rw rw

XMC4500
XMC4000 Family

CGMOD [1:0] rw Carrier Generator Operating Mode
00B Stopped
01B Square wave
10B Triangle
11B Sine wave
Stopping the carrier generator (CGMOD = 00B)
terminates the PWM output after completion of the
current period (indicated by bit RUN = 0).
BREV 2 rw Bit-Reverse PWM Generation
0B Normal mode
1B Bit-reverse mode
SIGPOL 3 rw Signal Polarity
0B Normal: carrier signal begins with +1
1B Inverted: carrier signal begins with -1
DIVCG [7:4] rw Divider Factor for the PWM Pattern Signal
Generator
Defines the the carrier signal frequency from the
selected internal clock source.
0H fCG = fCLK / 2
1H fCG = fCLK / 4
2H fCG = fCLK / 6
...
FH fCG = fCLK / 32
RUN 15 rh Run Indicator
0B Stopped (cleared at the end of a period)
1B Running
BITCOUNT [20:16] rh Bit Counter
Counts the 32 cycles generated for each step
STEPCOUNT [27:24] rh Step Counter
Counts the 16 steps generated for each carrier
signal period
STEPS 28 rh Step Counter Sign
Indicates the sign of the step counter value
0B Step counter value is positive
1B Step counter value is negative

XMC4500
XMC4000 Family

STEPD 29 rh Step Counter Direction
0B Step counter is counting up
1B Step counter is counting down
SGNCG 30 rh Sign Signal from Carrier Generator
0B Positive values
1B Negative values
RECTCFGx (x = 0 - 3)
Rectification Configuration Register x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SGN SGN
0 0 0 0 0 0 0 0 0 0 0 0 0 0
D CS
rh rh r r r r r r r r r r r r r r
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SDC RF
0 0 0 0 0 0 0 0 0 SSRC 0 0 0
VAL EN
rh r r r r r r r r r rw r r r rw

RFEN 0 rw Rectification Enable
General control of the rectifier circuit.
0B No rectification, data not altered
1B Data are rectified according to SGND
SSRC [5:4] rw Sign Source
Selects the sign signal that is to be delayed.
00B On-chip carrier generator
01B Sign of result of next channel
10B External sign signal A
11B External sign signal B

XMC4500
XMC4000 Family

SDVAL 15 rh Valid Flag
Indicates a new value in bitfield SDCAP.
1B Bitfield SDCAP has been updated with a new
captured value and has not yet been read
SGNCS 30 rh Selected Carrier Sign Signal
0B Positive values
1B Negative values
SGND 31 rh Sign Signal Delayed
0B Positive values
1B Negative values
CGSYNCx (x = 0 - 3)
Carrier Generator Synchronization Register x
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
SDNEG SDPOS
rw rw
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SDCAP SDCOUNT
rh rh

SDCOUNT [7:0] rh Sign Delay Counter
Counts the values to delay the carrier sign signal
SDCAP [15:8] rh Sign Delay Capture Value
Indicates the values counted between the begin of
the positive halfwave of the carrier signal and the first
received positive value.
SDPOS [23:16] rw Sign Delay Value for Positive Halfwave
Defines the content of SDCOUNT to generate a
negative delayed sign signal (SGND).

XMC4500
XMC4000 Family

SDNEG [31:24] rw Sign Delay Value for Negative Halfwave
Defines the content of SDCOUNT to generate a
positive delayed sign signal (SGND).
TSTMPx (x = 0 - 3)
Time-Stamp Register x (x * 0100H + 0150H) Reset Value: 0000 0000H
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 NVALCNT CFMDCNT
r r rh rh
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RESULT
rh

This value is copied from register RESMx (x = 0 - 3).
CFMDCNT [23:16] rh Comb Filter (Main Chain) Decimation Counter
This value is copied from register FCFGCx (x = 0 -
3).
NVALCNT [29:24] rh Number of Values Counted
This value is copied from register IWCTRx (x = 0 - 3).
20.12 Interconnects
This section describes the actual implementation of the DSD module into the XMC4500,
i.e. the incorporation into the microcontroller system.
20.12.1 Product-Specific Configuration

The functional description describes the features and operating modes of the DSD in a
general way. This section summarizes the configuration that is available in this product
(XMC4500).

XMC4500
XMC4000 Family
Table 20-6 General Converter Configuration in the XMC4500

Channel Digital Inputs Notes
0 4
1 4
2 4
3 4
20.12.2 Digital Module Connections in the XMC4500

The DSD module accepts a number of digital input signals and generates a number of
output signals. This section summarizes the connection of these signals to other on-chip
modules or to external resources via port pins.
Note: The exact port connections (pins) are listed in the ports chapter.
Table 20-7 Digital Connections in the XMC4500

Channel 0
DIN0A I GPIO Data bitstream channel 0 input A
DIN0B I GPIO Data bitstream channel 0 input B
MCLK0A I/O GPIO Modulator clock channel 0 input/output A

MCLK0B I/O GPIO Modulator clock channel 0 input/output B
ITR0A I ERU1.PDOUT0 Trigger signal, channel 0, input A
ITR0B I ERU1.PDOUT1 Trigger signal, channel 0, input B
ITR0C I ERU1.PDOUT2 Trigger signal, channel 0, input C
ITR0D I ERU1.PDOUT3 Trigger signal, channel 0, input D
ITR0E I - Trigger signal, channel 0, input E
ITR0F I - Trigger signal, channel 0, input F
ITR0G I - Trigger signal, channel 0, input G
ITR0H I - Trigger signal, channel 0, input H
SRM0 O NVIC, GPDMA Service request output main channel 0
SRA0 O NVIC Service request output aux. channel 0
Channel 1

XMC4500
XMC4000 Family


Channel 2


XMC4500
XMC4000 Family

Channel 3

General
MODCLK I SCU: fPB Module clock
RESET I SCU Reset signal (general)
SGNA I ERU1.PDOUT2 Sign input A (carrier signal)
SGNB I ERU1.PDOUT3 Sign input B (carrier signal)
CGPWMP O GPIO Positive PWM signal of carrier generator
CGPWMN O GPIO Negative PWM signal of carrier generator

XMC4500
XMC4000 Family
Digital to Analog Converter (DAC)
21 Digital to Analog Converter (DAC)

This chapter describes the two Digital to Analog Converter (DAC) channels available in
the module.
21.1 Overview
The module consists of two separate 12-bit digital to analog converters (DACs). It
converts two digital input signals into two analog voltage signal outputs at a maximum
conversion rate of 5 MHz. The available design structure is based on a current steering
architecture with internal reference generation and provides buffered voltage outputs. In
order to reduce power consumption during inactive periods, a power down mode is
available.
A built-in wave generator mode allows the CPU free generation of a selectable choice of
wave forms. Alternatively values can be feed via CPU or DMA directly to one or both
DAC channels. Additionally an offset can be added and the amplitude can be scaled.
Several time trigger sources are possible.
21.1.1 Features
Analog features
DAC resolution 12 bit;
Conversion rate up to 5 MHz with reduced accuracy;
Conversion rate up to 2 MHz at full accuracy;
Maximum settling time of 2 us for a full scale 12-bit input code transition;
Buffered voltage output;
Direct drive of 5 kOhm / 50 pF terminated load;
Segmented current steering architecture;
Low glitch energy;
Power down mode;
DAC output and ADC input share the same analog input pin. ADC measurement is
possible in parallel to DAC usage.
3.3 V analog supply;
Digital features
One Advanced Microcontroller Bus Architecture (AMBA) 32-bit AHB-Lite bus
interface for data transfer and control of both DACs;
Self triggered Direct Memory Access (DMA) handling capability with independent or
simultaneous data handling for the two DAC channels (see Chapter 21.2.4);
First In First Out (FIFO) data buffers to allow a longer service request latency and to
guarantee a continuous data transfer to the DACs (see Chapter 21.2.4);

DAC, V2.3.1 Subject to Agreement on the Use of Product Information
XMC4500
XMC4000 Family
Pattern generators available with freely programmable waveforms for both DACs
(see Chapter 21.2.5);
Independent noise generators available for both DACs (see Chapter 21.2.6);
Data scaling by shift operation (multiplication and division by 2, 4, 8,..., 128) of the
DACs input data;
Data offset value addition to the DACs input data;
8 selectable external trigger inputs;
Internal integer clock divider for DAC trigger generation;
Software trigger option;
1.2 V digital supply;
DIGDAC
DAC.SIGN_0 BANDG.
DAC_0_PAT_L
PATGEN 0 Config
DAC_0_PAT_H CONTROL
FSM 0
OUTPUT STAGE 0
DAC_0_CFG_0 Config
NOISEGEN 0
DAC_0_CFG_1
DAC0.SR0 DAC.OUT_0
AHB Slave TRIGGEN 0 RAMPGEN 0 DAC 0 P14.8
Registers
to ADC
DAC_0_DATA Clock
FIFO 0 Data[11..0]
AHB
DAC_01_DATA
FIFO 1 Data[11..0]
DAC.TRIGGER[7:0] DAC_1_DATA Clock
OUTPUT STAGE 1
DAC.OUT_1
TRIGGEN 1 RAMPGEN 1 DAC 1 P14.9
DAC0.SR1
DAC_1_CFG_1 to ADC
NOISEGEN 1 Config
DAC_1_CFG_0
CONTROL
DAC_1_PAT_H FSM 1
PATGEN 1
DAC_1_PAT_L
DAC.SIGN_1
Figure 21-1 Block diagram of DAC module including digdac submodule

XMC4500
XMC4000 Family
21.2 Operating Modes

The following chapters describe all the DACs functional operating modes and how to
use them. All used configuration parameters in this chapter are part of the registers
described in Chapter 21.6.
21.2.1 Hardware features

To facilitate the understanding of the different operating modes, a brief description of the
supporting hardware features is given here:
Control and Data Registers

All control and data registers shown on the left hand side of Figure 21-1 are described
in Chapter 21.6 in detail. They are connected to the AHB-Lite bus via an AHB-Lite slave
interface. The interface also handles the necessary error response generation without
introducing any latency.
Control Logic - Finite State Machines (FSM)

The two control finite state machines control all data processing modes of the DAC (see
Figure 21-1). This means that they are responsible for the start and stop operating
sequence, the service request generation for DMA handling for the so called data-mode
and the control of the data FIFOs, the pattern generators, the noise generators and the
ramp generators. Both FSMs are equivalent in structure and both are able to operate
fully independent for the two DAC channels. For the simultaneous data-mode both FSMs
are active, but only the service request signal of channel 0 (DAC0.Service
Request(SR)0) should be evaluated by the DMA controller. Of course in that
simultaneous data-mode the trigger source has to be the same for both channels.
21.2.1.1 Trigger Generators (TG)

The block diagram in Figure 21-2 shows one of the two DIGDACs trigger generators.

XMC4500
XMC4000 Family
TRIGGER GENERATOR (TG)
CLOCK
RESET Frequency Counter
ENABLE (20 bit)
FREQUENCY
ext_trigger
EXT_TRIGGER_0 int_trigger
EXT_TRIGGER_1
EXT_TRIGGER_2 Sync. &
TRIGGER
Edge-Detect .
sw_trigger
EXT_TRIGGER_7
TRIGSEL
SW_TRIGGER
TRIGMOD
Figure 21-2 Trigger generator block diagram

The TG consists of two multiplexers and one frequency counter. The first multiplexer
selects between one of the eight external trigger sources whereas the second one
enables switching between this selected external trigger source, an internally generated
trigger and an additional software trigger input. The internal trigger is generated by the
frequency counter which operates as a simple integer clock divider. So the internal
trigger period can only be a multiple of the DACs system clock period. In order to
guarantee correct operation of the analog part of the DAC the smallest frequency divider
value is limited to 16 by hardware.
The external trigger inputs are synchronized to the system clock and only the rising edge
is evaluated by the TG.
The software trigger input is connected to a register bit which is automatically cleared
after it has been set to one. For this reason the output trigger of the TG is always a pulse
with a pulse width of one system clock cycle for all three trigger possible modes.
21.2.1.2 Data FIFO buffer (FIFO)

The block diagram in Figure 21-3 shows one of the two data FIFO buffers, one for each
DAC.

XMC4500
XMC4000 Family
CLOCK FULL
FIRST IN FIRST OUT
RESET EMPTY
DATA BUFFER (FIFO)
ALMOST_FULL
WRITE
ALMOST_EMPTY
READ
INDEX
DATA0 FIFO FIFO FIFO FIFO
ERROR
REG 3 REG 2 REG 1 REG 0
DATA01 (12 bit) (12 bit) (12 bit) (12 bit) DATA_FIFO
DATMOD
BYPASS
Figure 21-3 Data FIFO block diagram

This data FIFO buffer with four FIFO registers is introduced to allow a longer service
request latency and to guarantee a continuous data processing for the DAC channels. It
is used for DACs so called data processing mode described in Chapter 21.2.4. All
FIFOs read and write operations are controlled by the corresponding Control FSM. A
read operation is triggered by the chosen trigger and a write operation is initiated by an
Advanced High-performance Bus (AHB) write operation to the currently used data
register. The FIFOs status outputs named full, empty and index can be read by the
software. A FIFO bypass used for all other DACs operating modes is also available.
21.2.1.3 Data output stage

The block diagram in Figure 21-4 shows one of the two DACs data output stages.
CLOCK
OUTPUT STAGE
RESET
DATA[11..0]
DATA_FIFO[11..0] (shift operation )
PATTERN[11..0]
REG DAC_DATA
(12 bit)
NOISE[11..0]
RAMP[11..0]
MODE[2..0]
OFFS[7..0]
SCALE[2..0]
MULDIV Delay
SIGN &
TRIGGER Stretch DAC_CLOCK
Figure 21-4 Data output stage block diagram

XMC4500
XMC4000 Family
This output stage is the last element in the DACs data path before the data is converted
to the analog. It consists of a multiplexer, an adder, a multiplier, an output register and
the generation of the DAC clock output.
The multiplexer selects between the five possible data sources and is programmed with
the mode parameter. The adder stage gives the possibility to add an 8-bit offset value
which is mainly needed for the PG mode in order to also process unsigned signal
patterns to the DACs. In that case a certain offset value can be added to the signed
output pattern values. The multiplier enables scaling by simple binary shifting of the data
values. Therefore it allows multiplication and division by a programmed 2n scale value.
The offset and scaling operations are possible in all functional operating modes. The
output register contains the final sample delivered together with the corresponding
trigger to the analog converter.
The clock output for operating the analog part of the DAC is generated using the DACs
trigger generator (TG). For that purpose the TGs trigger output is delayed by four system
clock periods and stretched to a high-length of eight system clock periods.
21.2.1.4 Pattern Generators (PG) - Waveform Generator

The block diagram in Figure 21-5 shows one of the two DACs pattern generators.
PATTERN GENERATOR (PG)
CLOCK Pattern Counter

RESET (4xdiv8->div32)
TRIGGER up/down
ENABLE
count 0 - 8 RUN
sign
sel sign
SYNC
PATTERN_0 pattern[6..0]
pattern[5..0] (signed)
PATTERN_1
(unsigned) PATTERN
PATTERN_2
PATTERN_8
Figure 21-5 Pattern generator block diagram

The nine pattern inputs on the left side of the PG block diagram are directly connected
to the pattern registers described in Chapter 21.6.3.4. The pattern registers contain only
one quarter of the actual programmed periodic pattern. The output of the pattern counter

XMC4500
XMC4000 Family
in the PG is used to select one of the nine input patterns. This pattern counter is an up-
down counter with an additional sign output which is inverted every time the counter
reaches zero. Since the sign information is concatenated with the currently selected
pattern, it is possible to generate a complete pattern sequence for a full period of any 2*
periodic waveform. For a detailed description how to operate the pattern generator
please also refer to Chapter 21.2.5.
21.2.1.5 Noise Generators (NG) - Pseudo Random Number Generator

The block diagram in Figure 21-6 shows one of the two DACs noise generators.
PSEUDO RANDOM NOISE

GENERATOR (PRNG)
CLOCK Linear Feedback Shift
Register (LFSR)
RESET
(20 bit -> xnor taps 20 & 17)
ENABLE RUN
noise[11..0]
Reg unsigned
TRIGGER NOISE
(12 bit)
Figure 21-6 Noise generator block diagram

The NG outputs a 12-bit pseudo random number. A 20-bit LFSR (linear feedback shift
register) operating at the system clock frequency and a sample output register which is
triggered by the NGs trigger inputs are used for this purpose. After enabling the NG, the
LFSR is set back to its reset value and therefore it always starts outputting the same
pseudo random number sequence.
21.2.1.6 Ramp Generators (RG)

The block diagram in Figure 21-7 shows one of the two DIGDACs ramp generators.

XMC4500
XMC4000 Family
RAMP GENERATOR (RG)

CLOCK
RUN
RESET
ramp[11..0]
ENABLE Full Scale Ramp unsigned
RAMP
Counter
MIN_VALUE
(12 bit)
MAX_VALUE
TRIGGER
Figure 21-7 Ramp generator block diagram

The ramp generator is basically an 12-bit up counter representing the full DAC range. If
the RG is enabled it always starts at the programmed minimum value. The up-counting
by ones is triggered by the selected trigger of the DAC channel. If the ramp counter
reaches the programmed maximum value it restarts from the minimum value. This allows
the generation of ramps within any desired value range and by variation of the trigger
frequency also the ramps slope can be modified.
21.2.2 Entering any Operating Mode

Before entering the desired operating mode with the MODE parameter, the
corresponding analog DAC channel should be enabled with ANAEN and the startup time
of the analog DAC channel should be considered.
Setting the DATMOD parameter to one enables simultaneous data processing. This
means that both DAC channels use the same trigger source and both channels are
always started and stopped synchronously. Hence the parameter setting of MODE,
TRIGMOD, TRIGSEL and FREQ for DAC channel 0 is used for DAC channel 1 also.
21.2.3 Single Value Mode

By setting MODE to single value mode, it is possible to convert only one single data
value by the DACs. To start a conversion, a data value can be written to either DATA0
or DATA1 in DAC0DATA or DAC1DATA registers. This write operation itself then
initiates a single trigger pulse and the value gets processed by DAC0 or DAC1. Only for
this mode, no further external, internal or software trigger pulse is necessary. The DAC
holds the processed value until a new value is written to DATA0 or DATA1. This
operating mode is intended for outputting static DAC output values. For processing
sequential data streams in this self triggered, single value mode, it is important not to
exceed the maximum DAC data rate. If the DATMOD parameter is set to zero, data from
the independent data registers DAC0DATA or DAC1DATA is processed. Whereas if

XMC4500
XMC4000 Family
DATMOD is set to one, data from the simultaneous data register DAC01DATA is
processed for both DACs.
21.2.4 Data Processing Mode

This operating mode is intended for continuous data processing from the system
memory to DAC0 and/or DAC1. To enable it, the MODE parameter has to be set to data
mode. Also, the desired trigger source has to be selected by setting TRIGMOD,
TRIGSEL and FREQ in the configuration registers. The DIGDAC can operate either with
an internal generated trigger, one of the eight external trigger sources (see Figure 21-2)
or the software trigger bit SWTRIG.
Simultaneous and independent Data Modes

With the DATMOD parameter, either the simultaneous or the independent data mode
can be selected. In the simultaneous mode, both DACs receive their data from the same
register DAC01DATA. In the independent data mode DAC0 gets its data from
DAC0DATA and DAC1 from DAC1DATA. The two data paths are shown in Figure 21-8
and also in Figure 21-3. Both DAC channels can activate a service request output signal
to trigger a DMA channel, if they are configured in this mode and if the corresponding
SREN bit is set to one. The service requests are DAC0.SR0 for the DAC0 channel and
DAC0.SR1 for the DAC1 channel. For the simultaneous mode either DAC0.SR0 or
DAC0.SR1 can be used by the DMA controller.
Start-Stop Operation
Before the DAC is started in data mode, all configuration registers DACx_CFG_x
should be set according to the desired processing mode (see Chapter 21.6.3.2). Once
this has been done, the DAC can be started by setting the MODE parameter to data
mode. The control FSM will then start its operation until it reaches the run status
indicated by the read parameter RUN. The run state can be left either by an operation
error or by setting the MODE parameter to disable DAC again. An operation error can
be a FIFO overflow or a FIFO underflow (see Figure 21-3 and Figure 21-8).
21.2.4.1 FIFO Data Handling

Figure 21-8 shows the data handling for the FIFO of the DAC0 channel. Certainly the
same structure also exists for the DAC1 channel (see Figure 21-1 and Figure 21-3
also). The data word DATA0 from either data register DAC0DATA or DAC01DATA on
the left hand side in Figure 21-8 is loaded into one of the FIFO buffers registers. The
load position in the FIFO depends on its actual filling level represented by the read
parameters FIFOIND, FIFOEMP and FIFOFUL. If the FIFO is empty, FIFOIND = 0. If it
is full, FIFOIND = 3. If a trigger occurs and the FIFO is not empty, the data is shifted to
the next register (from left to right). At the same time, a service request (DAC0.SR0 or
DAC0.SR1) is initiated in order to fill up the FIFO again. The service request should end

XMC4500
XMC4000 Family
with a write operation to DAC0DATA or DAC01DATA. This write operation itself then
triggers a write from the data registers to the FIFO buffer registers. If the FIFO stores
only one last element (FIFOIND = 0 and FIFOEMP = 0) and a trigger has occurred, a
service request is initiated and additionally FIFOEMP is set to 1. On the other hand, if
there is only one last free register in the FIFO (FIFOIND = 2) and a write operation has
been initiated, the FIFOFUL bit is set to 1. All the control signals for the FIFO handling
are generated by the DACs control FSM. This includes filling up the FIFO when data
mode is entered and emptying the FIFO when leaving data mode.
DATMOD
DATA0
DAC_01_DATA Register
TRIGGER DETECTED = 1 => INDEX = INDEX 1=> DMA_REQUEST = 1 => WRITE OPERATION= 1 => INDEX = INDEX + 1
DATA1
1 0 1 0 1 0
FIFO FIFO FIFO
RegN RegN-1 Reg0
to DAC
0 1 0 1 0 1
WRITE OPERATION=1 TRIGGER

DATA0
and DETECTED = 1
DAC_0_DATA Register
INDEX=N and
=> FIFO_FULL = 1 INDEX=0
=> FIFO_EMPTY = 1
TRIGGER WRITE OPERATION=1 TRIGGER WRITE OPERATION=1 ( TRIGGER DETECTED = 1

DETECTED = 1 and DETECTED = 1 and and
or INDEX=N-1 or INDEX=0 INDEX != 0 )
WRITE OPERATION = 1 WRITE OPERATION = 1 or
WRITE OPERATION = 1
Figure 21-8 Data handling for the FIFO Buffer
21.2.5 Pattern Generation Mode

This chapter describes the operation of the pattern generator. This mode is used to
output a pattern or waveform to the DACs and it is activated by setting the MODE
configuration parameter to patgen mode.
Like in the data mode (see Chapter 21.2.4), the DIGDAC in patgen mode" can
operate either with an internally generated trigger, one of the eight external trigger
sources or a software trigger bit.
The desired pattern or waveform is freely programmable with the 5-bit parameters PAT0
to PAT8. The pattern registers contain only one quadrant of the full waveform. The other
quadrants of the 2* periodic odd function are generated out of the first one with the help
of a counter. The counter generates also the sign bit of the output pattern, therefore the
6-bit output signed values are in the range of -31 to +31.
In order to use the full range of the DAC in signed mode, a scaling by 32 by setting
SCALE to 101 in the output stage is necessary. If the DAC should output a full range

XMC4500
XMC4000 Family
pattern in unsigned mode, it is also possible to add an offset value programmed with
OFFS to the output stage before doing the scaling. All the control signals for the pattern
generators are generated by the DIGDACs control FSM.
Figure 21-9 Example 5-bit patterns and their corresponding waveform output
Figure 21-9 gives examples of lookup table entries for triangular, sine and rectangular
pattern. These values can be programmed to PAT0 to PAT8 in order to get the
corresponding waveforms at the DACs output like shown in the chart on the right hand
side. If the pattern generation is restarted / enabled again, it always starts with the first
value of the first quarter of the actual programmed pattern (positive value and up-
counting). The current sign information of the generated pattern is one of the DACs
system on chip outputs (see Chapter 21.7.2.3) and can be enabled using the parameter
SIGNEN.
21.2.6 Noise Generation Mode

A 20-bit linear feedback shift register (LFSR) is used to produce a pseudo random
number. In order to enable the noise generator, the MODE parameter has to be set to
noise mode. The LFSR itself runs with the system clock. The 12-bit random numbers
is sampled with the preselected trigger source using TRIGMOD, TRIGSEL and
optionally also FREQ or SWTRIG into an output register. The 12-bit values can be
interpreted as signed or unsigned values. By setting the MODE parameter to disable
DAC again, the noise generation stops and the DAC holds its last processed value.
Figure 21-10 shows an example pseudo random noise output. After restarting the noise
generation mode, the LFSR is set back to its reset value and therefore it always starts
outputting the same pseudo random number sequence.

XMC4500
XMC4000 Family
Figure 21-10 Signed 12-bit pseudo random noise example output
21.2.7 Ramp Generation Mode

A 12-bit ramp counter is also part of the DAC. It is activated by setting the MODE
parameter to ramp mode. The trigger source can be selected using TRIGMOD,
TRIGSEL and optionally also FREQ or SWTRIG. The ramp counter starts at a
programmed start value and each trigger pulse increments the counter by one. The start
values are programmable via DATA0 for DAC channel 0 and DATA1 for DAC channel
1 of the independent data registers. The stop values are programmable via DATA0 or
DATA1 of the simultaneous data register. If the ramp counter reaches its stop value, it
restarts from the start value with the next trigger pulse. This allows the generation of
ramps within any desired value range. The ramps slope can be modified by varying the
trigger frequency. Figure 21-11 shows two examples of ramp generation output
waveforms.
12 bit DATA
STOP VALUE 2
STOP VALUE 1
START VALUE 2
START VALUE 1 TIME

HIGHER TRIGGER FREQUENCY1
LOWER TRIGGER FREQUENCY 2
Figure 21-11 Unsigned 12-bit ramp generator example output

Service Requests are available in Data Processing Mode only.

XMC4500
XMC4000 Family

As long as ANAEN is set to default value standby, the corresponding DAC stays in
power down mode, and its output is floating.
The DAC module reset is shared with the peripheral bus reset line, as well as the module
clock is shared with the peripheral bus clock line.
With FREQ the clock divider ratio of the internal trigger generator is set.
21.5 Initialisation
A feasible initialisation sequence of the DAC reads as follows:
1st Step: De-assert the reset of DAC module by setting DACRS bit in PRCLR1 register
2nd Step: Write the DACxCFG0 register values. Here you select the operating mode of
the corresponding DAC channel by writing the MODE field, e.g. Patgen mode. By setting
or clearing the SIGN bit, the choice between signed and unsigned input data format is
made.
In the same step service request generation can be enabled with the SREN bit, as well
as sign output with SIGNEN bit. Also the frequency divider of the internal trigger
generator can be set up by writing the FREQ field.
3rd Step: Write the DACxCFG1 register values. Here you select the trigger source by
writing the TRIGMOD field, e.g. software trigger. The DAC channel output is enabled by
setting the ANAEN bit. You also need to choose now your values for SCALE, MULDIV,
OFFS, and DATMOD fields.
4th Step

Infineon XMC4500 RM

Uploaded by

Copyright:

Available Formats

Infineon XMC4500 RM

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Infineon XMC4500 RM

Uploaded by

Copyright:

Available Formats

XMC4500

XMC4500 Reference Manual

Revision History: V1.0 2012-02

We Listen to Your Comments

Reference Manual V1.0, 2012-02

Reference Manual L-1 V1.0, 2012-02

2.6.2 Fault Escalation and Hard Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-38

Reference Manual L-2 V1.0, 2012-02

4.4.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

Reference Manual L-3 V1.0, 2012-02

5.3.1 Illegal Register Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39

Reference Manual L-4 V1.0, 2012-02

6.7 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11

Reference Manual L-5 V1.0, 2012-02

8.4.9 Data Integrity and Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20

Reference Manual L-6 V1.0, 2012-02

9.8.2 Reconfiguration & Restart of Operation . . . . . . . . . . . . . . . . . . . . . . . . 9-8

Reference Manual L-7 V1.0, 2012-02

11.3.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12

Reference Manual L-8 V1.0, 2012-02

11.11 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-150

Reference Manual L-9 V1.0, 2012-02

13.11.1 Setup SDMMC Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-12

Reference Manual L-10 V1.0, 2012-02

14.7.7 Address Alignment During Bus Accesses . . . . . . . . . . . . . . . . . . . . 14-23

Reference Manual L-11 V1.0, 2012-02

14.12.10 Page Mode Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-58

Reference Manual L-12 V1.0, 2012-02

14.17.5 Bus Write Configuration Register, BUSWCONx . . . . . . . . . . . . . . 14-106

Reference Manual L-13 V1.0, 2012-02

15.2.9 Media Independent interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-65

Reference Manual L-14 V1.0, 2012-02

16.2.3 USB Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4

Reference Manual L-15 V1.0, 2012-02

16.5.6.3 Periodic Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-64

Reference Manual L-16 V1.0, 2012-02

16.7.8.1 Interrupt usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-175

Reference Manual L-17 V1.0, 2012-02

17 Universal Serial Interface Channel (USIC) . . . . . . . . . . . . . . . . . . . . . 17-1

Reference Manual L-18 V1.0, 2012-02

17.2.8.2 Transmit Buffer Events and Interrupts . . . . . . . . . . . . . . . . . . . . . 17-40

Reference Manual L-19 V1.0, 2012-02

17.4.2.4 Data Frame Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-81

Reference Manual L-20 V1.0, 2012-02

17.5.3.1 Start Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-117

Reference Manual L-21 V1.0, 2012-02

17.9 Power, Reset and Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-151

Reference Manual L-22 V1.0, 2012-02

18.1.2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-4

Reference Manual L-23 V1.0, 2012-02

18.3.9.7 Gateway Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-50

Reference Manual L-24 V1.0, 2012-02

19.8.3 Wait-for-Read Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-36

Reference Manual L-25 V1.0, 2012-02

20.9.1 Carrier Signal Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-16

Reference Manual L-26 V1.0, 2012-02

21.6.3.2 DAC Configuration Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-17

Reference Manual L-27 V1.0, 2012-02

22.2.12.1 PWM Signal Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-55

Reference Manual L-28 V1.0, 2012-02