AURIX_code_examples: Infineon's sample projects for AURIX Development Studio

A gallery of examples, each with a tutorial attached

The repository description says it plainly: it contains code example projects for the AURIX Development Studio, and the README says more than hundreds of code examples are available for AURIX devices.

The unit of the repository is a pair. Each example is made up of the source code and the corresponding tutorial, and the tutorial is either a downloadable PDF or a README.md file that lives inside the project. That pairing is what makes the collection usable, because a bare snippet of peripheral setup code is close to worthless without the board wiring and the register sequence that goes with it.

The audience is a developer working with AURIX silicon, and the tone is reference material rather than library. The examples are written in C, and the source of each one is based on Infineon Low Level Drivers, with the driver documentation hosted on a separate Infineon page. There is no package to install, no API to call and no versioning contract, which is both the strength and the limitation: you can read and adapt any example, but nothing here is meant to be depended on.

The repository layout is minimal. Beyond the README there is a code_examples directory and an img directory holding the screenshots the README refers to.

Every example carries a metadata block in Cpu0_Main.c

Each code example ships with a comment section called metadata in its Cpu0_Main.c file, and the README enumerates what that block contains. Title is the name of the example, Abstract is a short description of its scope, and Description is the detailed version. Name is the example's univocal name, and Version is a version number formatted as major changes, minor changes and bugfixes, for example V1.0.2.

The remaining fields are about hardware and search rather than about the code. Board is a list of boards the code supports, Keywords is a list of terms to ease searching, Documents is a list of links to further reading, and Last Updated is the date of the last modification.

This block is the reason the collection is navigable at all. A repository with hundreds of peripheral examples would be unusable without a way to ask which board a snippet was validated on, and the Board field is the answer to that. Placing the metadata in Cpu0_Main.c means the block travels with the source code wherever the example is imported.

The name encodes code, ID, board and framework

Examples are named by a scheme rather than by folder listing alone, and the README gives two forms:

Two forms are given, one of the shape code name, ID number and board short name, and one of the shape framework, board short name, ADS and code name. The two real examples the README shows are ADC_Filtering_1_KIT_TC375_LK and iLLD_TC375_ADS_Blinky_LED_CPP, which make the pattern legible.

The code name summarises the scope and the module used in the example, and the ID number identifies the example scope, so that two examples achieving the same scope with different code are called _1 and _2 to tell them apart. The board short name says which board the code was developed for, using board-specific pins such as LEDs and communication lines. The framework field names the software framework: iLLD for Infineon Low Level Drivers, or BMETAL for bare metal implementations.

That last field is the one to check first when you copy something. BMETAL means the example talks to the hardware without the driver layer, and iLLD means it goes through the structured driver API. The two styles of code teach different things about the silicon, and the name tells you which you are about to read before you have opened a single file.

The topic map covers the peripherals and the safety hardware

The README organises the collection into macro categories, and the table is a compact map of what an AURIX part contains. Communication protocols cover ASCLIN module handling for LIN, UART and SPI, Ethernet, I2C, CAN and SPI. Data handling covers the Flexible CRC Engine, the Input-Output Monitor, BUS register protection, Memory Protection control, Data and Program Flash programming, DMA control and memory test. Timers cover the Capture and Compare Unit, Clock System, General Purpose Timer, Generic Timer Module and System Timer Module. Analog and digital signals cover the Versatile Analog-to-Digital converter, the Delta-Sigma Analog-to-Digital converter and GPIO port control.

The CPU management column is the one that goes beyond peripherals. It lists assembly code execution, code execution from SRAM, performance registers usage, Power Management System control, Multicore, Trap recognition and Watchdog handling. The final column, alarms, interrupts and resets, covers device reset type trigger and detection, interrupt handling and Safety Management Unit control.

The presence of the Safety Management Unit, trap recognition and watchdog handling in the same list as the timers and the ADCs tells you the collection is not only about driving pins. It also covers the mechanisms that keep a controller honest, which is where most of the value sits for anyone doing functional safety work on AURIX.

Tutorials come in two formats with a fixed set of sections

A PDF tutorial is downloaded by following the link inside the metadata, and each one contains a summary with an abstract and a detailed description of the scope, an introduction to the module and its main features, a hardware section covering what is used and how to configure it, an implementation section explaining how to configure the module using iLLDs and exploit their features, a run and test section with the steps to confirm the code works and interact with it, and references.

The README.md format carries the same information in a different arrangement, and it is the more convenient of the two in practice. The file is provided inside the project and is opened automatically when the example is imported into AURIX Development Studio, so the documentation appears next to the source without a download step. Its sections are abstract, device, board, scope of work, hardware setup, implementation, and compiling and programming.

Both formats describe hardware setup in detail, which is the part you cannot skip. An example that configures a peripheral on specific board pins is only reproducible if you know which pins and which configuration the tutorial assumes.

Importing is the only setup step, and boards are the filter

There is no installation in the usual sense. The README tells you to import a code example into AURIX Development Studio and points to a guide at the end of the page for the procedure, and the auto-opened README.md is the payoff of that import, since the documentation arrives with the project rather than as a separate download.

The practical filter is the board. The README lists the supported board types, and a table names the specific kits across the three AURIX families: for TC2xx there are KIT_AURIX_TC234_TFT, KIT_AURIX_TC237_TFT, KIT_AURIX_TC265_TFT, KIT_AURIX_TC275_ARD_SB, KIT_AURIX_TC275_LITE, KIT_AURIX_TC277_TFT and KIT_AURIX_TC297_TFT; for TC3xx there are KIT_A2G_TC334_LITE, KIT_A2G_TC367_5V_TFT, KIT_A2G_TC375_ARD_SB, KIT_A2G_TC375_LITE, KIT_A2G_TC377_5V_TFT, KIT_A2G_TC387_5V_TFT, KIT_A2G_TC397_5V_TFT and KIT_A2G_TC3xx_5V_TRB_S; and for TC4xx there are KIT_A3G_TC4D7_LITE, KIT_A3G_TC497_LITE, KIT_A3G_TC487_LITE and KIT_A3G_TC467_LITE.

Support for questions and requests is routed to a dedicated Infineon AURIX forum, and the README instructs you to use it rather than the repository for anything beyond the code itself.

iLLD is the base layer, and the framework tag tells you which

The source code of each example is based on Infineon Low Level Drivers, which the README describes as the structured layer the implementation sections teach you to configure and exploit. The iLLD documentation lives on a separate Infineon page rather than in this repository, so this is a companion to the driver documentation rather than a replacement for it.

The distinction that runs through the whole collection is between that driver-based code and bare metal code. The naming scheme encodes it, with iLLD marking examples built on the drivers and BMETAL marking bare metal implementations,

Assembly code execution and code execution from SRAM appear under CPU management, which tells you the collection is not limited to peripheral configuration either. If your problem is getting the core to start from a RAM block or to run a hand written routine, there is an example for that, and it will be tagged by framework and board like everything else.

No releases, no stated licence, and a recent push

The repository is not archived and the last push was on 2026-09-30, so the collection is being added to. The repository has no GitHub releases, and there is no version file at the root, so the state of the collection is defined by the master branch rather than by a tag. For a repository of examples that is a mild inconvenience: there is no way to pin the revision you read, and no changelog to consult when an example changes.

The licence situation is the more consequential gap. The licence is not identified anywhere in the repository listing, and there is no LICENSE file among the top-level entries, which are README.md, code_examples and img. A team that intends to copy an example into a product therefore has no stated terms to point at, which is a question for Infineon through the AURIX forum rather than something the repository answers.

The topic tags are narrow and descriptive: 32-bit, aurix and multicore-cpu. That matches what the collection is, a vendor reference shelf for one microcontroller family rather than a general embedded repository.

Editorial conclusion

AURIX_code_examples fits an engineer starting an AURIX project who needs a working reference for a peripheral, a board pinout or an iLLD configuration before the vendor documentation is second nature. It is the wrong choice as a dependency, since it is a gallery of examples rather than a library, and the licence is not identified anywhere in the repository listing. Verify first which board you actually have against the supported board table, which framework the example is written against, iLLD or BMETAL, and whether the tutorial you need exists as a PDF, a README, or neither.

Frequently asked questions

Official sources

1. Infineon/AURIX_code_examples on GitHub
2. Issues
3. README