XMC Peripheral Library for XMC1000 Family
Personalities Reference

Personality Introduction

The XMC Peripheral Library includes a set of files to enable the ModusToolbox™ Device Configurator functionality. These files are known as personalities. They describe the GUI to the microcontroller hardware resources for the Device Configurator in the xml format. Each hardware resource of a microcontroller has its own personality.
Based on the user settings, personalities generate initialization code (configuration structures and initialization API calls) executed within the init_cycfg_all() function. The init_cycfg_all() function is usually executed within the cybsp_init() function or may be called directly in the main() function by the user. The system clock personalities generate a strong definition of the SystemCoreClockSetup() function executed at a startup (before jumping to main.c, not within the init_cycfg_all() unlike other ModusToolbox™ PDL products).

For more details, refer to:

Common Groups

The parameters of microcontroller resources are allocated in groups. Most of the personalities have groups named: Documentation, Connections, Advanced.

Documentation
The "Documentation" group displays one or more links to the documentation:
  • API Help: is the link to the application programing interface (API) documentation of the hardware resource to which the current displayed personality is related.
  • Personality Help: is the link to the documentation of the current personality.

Connections
The "Connections" group contains the parameters, which link different personalities and different hardware resources. This way, configurations chains are formed.

Advanced

The "Advanced" group may contain all or one of the listed parameters:

  • Start After Initialization: If enabled, the peripheral will start at the end of the peripheral initialization.
  • Store Config in Flash: Controls whether the configuration structure is stored in flash (const, true) or SRAM (not const, false).

Pin Personality

The pins of the Pin personality for XMC family microcontrollers do not generate service requests. This feature is determined by the hardware architecture of the XMC family.
However, pins can be configured as event resources for the Event Request Unit (ERU), and ERU will generate a service request instead of Pin.

To adjust an Interrupt from a pin (GPIO) requires the adjustments by the configurations chain: Pin - ERU_ERS - ERU_ETL - ERU_OGU/Service Request.

pin_interrupt_config.png

Refer to the ERU Personality section for Interrupt configuration details.
Refer to the API reference General Purpose Input Output (GPIO) for the API details.
Refer to the device Datasheet and Reference Manual for HW details.

ERU Personality

The Event Request Unit (ERU) architecture includes three subunits: Event Request Select (ERS), Event Trigger Logic (ETL), and Output Gating Unit (OGU).
Thus, the ERU personality is represented as the three personalities of the ERU subunits.

For more details, refer to:

ERS Personality

The ERS personality provides a graphical interface to connect a corresponding ERS input channel to a specific event source, to determine the ERS output signal Combination Logic, and to connect an ERS unit with a corresponding ETL unit.

ers_personality_connections.png

After ERS is set, the next step of the ERU adjustment by the configuration chain is configuration of the ETL.

ETL Personality

The ETL personality provides a graphical interface to determine the conditions of incoming signal processing. If the incoming signal satisfies the conditions defined by the "Edge Detection" parameter, the signal is regarded as a true event.
The event generates a trigger, whose distribution path to OGU is also controlled by the parameters of the ETL personality GUI.

etl_personality_connections.png

To continue ERU adjustments, go to the OGU personality configuration by the configuration chain.

OGU Personality.

An OGU unit combines trigger events and status information and gates the Output. The OGU personality provides a graphical interface to determine in which way that will occurs.

Note
The OGU settings may be set so that an event of one Input will lead to reactions on several Outputs.

OGU Outputs may be used as triggers for the other units, for example, to DMA.
An OGU reaction may be setting the service request generation. To enable the service request generation, check the "Pattern Detection" parameter.

ogu_personality_connections.png

Refer to the API reference Event Request Unit (ERU) for the API details.
Refer to the XMC 1000, XMC 4000 Event Request Unit (ERU) Application Note.
Refer to the device Datasheet and Reference Manual for HW details.

CCU4 Personality

There are two major revisions: 1.0 and 2.0.

CCU4 1.0 is legacy and contains old-style EVENT_HANDLER definitions, which are deprecated and not recommended for usage in new applications.

CCU4 1.0 is left in XMCLib for the backward compatibility with already created projects not to be updated by the user.

The CCU4 1.0 support will be removed in the next major XMCLib revision.

CCU4 2.0 is almost the same as 1.0 but without the deprecated items, so it is recommended for new applications.

Code Generation

Modern INTERRUPT_HANDLER definitions recommended for usage in applications are generated instead of the deprecated items:

ccu4_sr0_setting.png
ccu4_sr0_handler.png

These newly generated definitions can be used in the application code, for example for the xmc4xxx devices:

void MyCCU4_SR0_INTERRUPT_HANDLER(void)
{
XMC_CCU4_SLICE_ClearEvent(MyCCU4Slice_HW, XMC_CCU4_SLICE_IRQ_ID_PERIOD_MATCH);
}

and for enabling the CCU4 interrupt before starting the block:

NVIC_EnableIRQ(MyCCU4_SR0_IRQN);
XMC_CCU4_SLICE_StartTimer(MyCCU4Slice_HW);

Refer to the API reference Capture Compare Unit 4(CCU4) for the API details.

Refer to the device Datasheet and Reference Manual for the HW details.

POSIF Personality

Quadrature Decoder Mode

Quadrature Decoder mode is used to find the position and speed of the motor using the incremental encoder. The profile is designed so that it can estimate the angle by consuming 3 CCU4 slices and an optional CCU4 slice along with POSIF and its interconnections.

Four CCU4 slices are consumed for the following purposes:

  1. Position Counter
    • Set the slice to be in Counter mode, which starts ticking based on encoder pulses to provide the absolute position:
    • Connect the Status Signal of the Position Counter CCU4 to an optional Revolution Counter CCU4 slice Event 0 Input Signal.
    • Set the Count Function of the Revolution Counter CCU4 slice to Triggered by Event 0.
    • Set the Event 0 Edge Selection of the Revolution Counter CCU4 slice to Signal Active on Falling Edge.
    • Set the Event 0 Level Selection of the Revolution Counter CCU4 slice to Active on the High Level.
  2. Revolution Counter (optional)
    • Set the slice to be in Counter mode, which ticks based on the Position Counter period match (Falling edge of ST signal).
  3. Time Between Ticks
    • The slice to measure time between ticks for the angle extrapolation.
  4. Time Stamp Trigger
    • The slice to generate a trigger at the time stamp point when the angle extrapolation is required.
    • Connect the Status Signal of the Time Stamp Trigger CCU4 slice to the Position Counter and Revolution Counter CCU4 slices Event 2 Input Signal, and the Time Between Ticks CCU4 slice Event 1 Input Signal.
    • Set the Capture 0 Function of the Position Counter and Revolution Counter CCU4 slices to Triggered by Event 2 and set the Capture 1 Function for the Time Between Ticks CCU4 slice to Triggered by Event 1.
    • Set the Event 2 Edge Selection of the Position Counter and Revolution Counter as well as Event 1 Edge Selection of the Time Between Ticks CCU4 slices to Signal Active on Falling Edge.
    • Set the Event 2 Level Selection of the Position Counter and Revolution Counter as well as Event 1 Level Selection of the Time Between Ticks CCU4 slices to Active on High Level.

The POSIF module and its interconnection with CCU4 are depicted in the following diagram:

posif_encoder_structure.png

Hall Sensor Mode

Hall Sensor mode is used to find the position and speed of the motor using 2 or 3 hall sensors. The POSIF personality in Hall Sensor mode uses two CCU4 slices - one to add a phase delay and one to capture the time between two correct hall patterns.

The personality supports 3 hall sensors and 2 hall sensors in the following use cases:

  1. Find the speed and position for the PMSM motor: In this use case, the speed and position of the PMSM motor is obtained based on the hall sensor input. It is used in the PMSM motor control, which drives the inverter as per SVM algorithm.
  2. Find the speed and position for the BLDC motor: In this use case, the speed and position of the BLDC motor is obtained based on the hall sensor input. It is used in the BLDC motor control, which drives the inverter as per multi-channel pattern sequence.

Refer to the API reference Position Interface Unit (POSIF) for the API details.

Refer to the device Datasheet and Reference Manual for the HW details.

WDT Personality

The Window boundaries configuration:

wdt_window.png
wdt_window_cfg.png

The Pre-Warning Alarm interrupt configuration:

wdt_prewarn.png
wdt_prewarn_cfg.png

Code Generation

The configurator performs the [name]_EventHandler registration in the generated code, so declare it in the application code, for example for the xmc4xxx devices:

void NMI_Handler(void)
{
XMC_SCU_IRQHandler((uint32_t)SCU_0_IRQn);
}
void MyWDT_EventHandler(void)
{
XMC_WDT_Service();
}

and then start the block itself (the rest of configurations are performed in the generated code):

XMC_WDT_Start();

Refer to the API reference Watchdog driver (WDT) for the API details.

Refer to the device Datasheet and Reference Manual for HW details.

UART Personality

RXD Input Connection Signals

There is a possibility to extend the set of pins available as UART RXD input using pins from DX3 and DX5 input stages. By selecting DX3INS connection for RXD signal, the pin configured on DX3 input is used as RXD, for example:

uart_dx3.png

Additionally, the pin set for RXD connection could be extended further with DX5 inputs, if DX5INS connection is selected for DX3 input in the previous example:

uart_dx5.png

Refer to the API reference Universal Asynchronous Receiver/Transmitter (UART) for the API details.

Refer to the device Datasheet and Reference Manual for HW details.