Version: **

In addition to DMA descriptors for Single, 1D and 2D transfers the Peripheral DMA (P-DMA) in TRAVEO™ T2G also supports a Cyclic Redundancy Code (CRC) transfer descriptor type.

Following hints and considerations may be helpful when using this descriptor type:

Post-processing of CRC result

CRC standards define the following post-processing operations that must be applied to the result of a CRC calculation:

• A value that must be XOR’ed with the result (DWx_CRC_REM_CTL0)
• Whether the bit order of the result (after XOR) must be reversed or not (DWx_CRC_CTL0. REM_REVERSE)

The post-processed result of a completed P-DMA CRC calculation is only available in the DWx_CRC_REM_RESULT0 register, where the configured destination address (DST_ADDR) of the CRC transfer will only hold the result without post-processing (matching DWx_CRC_LFSR_CTL0).

By using the feature of DMA descriptor chaining, it is possible to transfer the post-processed result to the desired target memory as well. This may be useful when the CRC result shall be appended to the memory buffer that holds the data for which the CRC had been calculated (for example, before transmitting it over SPI).

Consider the following three common scenarios:

1.CRC length is 32-bit.

A descriptor for a Single transfer can be chained with the following parameters:

• DATA_SIZE:                                 32-bit
• SRC_TRANSFER_SIZE:            DATA_SIZE (or 32-bit)
• DST_TRANSFER_SIZE:            DATA_SIZE (or 32-bit)
• SRC_ADDR:                                 DWx_CRC_REM_RESULT0
• DST_ADDR:                                  Desired target address, 32-bit aligned

2. CRC length is 8-bit or 16-bit and DWx_CRC_CTL0. REM_REVERSE == 0 (no bit reversal)

A descriptor for a Single transfer can be chained with the following parameters:

• DATA_SIZE:                                 8-bit or 16-bit as required
• SRC_TRANSFER_SIZE:            32-bit (register needs to be accessed with 32-bit width!)
• DST_TRANSFER_SIZE:            DATA_SIZE
• SRC_ADDR:                                 DWx_CRC_REM_RESULT0
• DST_ADDR:                                  Desired target address, aligned to DATA_SIZE

3.CRC length is 8-bit or 16-bit and DWx_CRC_CTL0. REM_REVERSE == 1 (bit reversal)

Due to the bit reversal, the relevant result value is stored in the most significant byte(s) of DWx_CRC_REM_RESULT0. This register can be only accessed with 32-bit and the type casting via DATA_SIZE would only operate on the least significant byte(s). Therefore, an intermediate step is necessary that copies the DWx_CRC_REM_RESULT0 value somewhere to SRAM, because the SRAM would then allow arbitrary access width in the second step.
This means two descriptors for Single transfers should be chained with the following parameters:

• Descriptor #1 (copy value from register to temporary SRAM location)
  • DATA_SIZE:                        32-bit
  • SRC_TRANSFER_SIZE:  DATA_SIZE (or 32-bit)
  • DST_TRANSFER_SIZE:  DATA_SIZE (or 32-bit)
  • SRC_ADDR:                        DWx_CRC_REM_RESULT0
  • DST_ADDR:                        Temporary address X in SRAM, 32-bit aligned
• Descriptor #2 (extract relevant bytes from temporary SRAM location and copy to target address)
  • DATA_SIZE:                        8-bit or 16-bit as required
  • SRC_TRANSFER_SIZE:  DATA_SIZE
  • DST_TRANSFER_SIZE:  DATA_SIZE
  • SRC_ADDR:                        X+2 for 16-bit, or X+3 for 8-bit
  • DST_ADDR:                        Desired target address, aligned to DATA_SIZE

Additional notes:

• CRC standards with a CRC length not equal to 8, 16, or 32 bits need some extra steps which could also require the CPU (for example, for bit shifting)
• A sophisticated DMA descriptor chain to send CRC protected data through SPI consists of these descriptors:
  1. Initialize CRC settings (for example, write CRC seed to DWn_CRC_LFSR_CTL0).
  2. Calculate CRC of transmit data.
  3. Append post-processed CRC result to transmit data (according to the description above).
  4. Transfer data to SCB TX FIFO.

Shared CRC unit / Mutual exclusive CRC calculations

There is only one single CRC register set per P-DMA instance, which holds the state and the settings for a CRC calculation. To prevent corruptions, a channel with an active CRC calculation must not be preempted by another channel executing a CRC descriptor before the post-processed CRC result from DWx_CRC_REM_RESULT0 has been backed-up or evaluated by the user.

Following possibilities exist:

• Arbitrate the usage of the CRC unit through SW (only setup and trigger a new CRC calculation after the last one has completed and the result has been evaluated).
• Implement the following solution that relies on HW mechanisms:
  • Disable preemption for the channels performing CRC calculations or assign them the same channel priority
  • Initialize all relevant CRC control registers as part of the descriptor chain (at least the CRC seed value must be written to DWn_CRC_LFSR_CTL0 even if all channels involved in CRC calculations use the same CRC standard)
  • The descriptor chain must also store the post-processed CRC result in SRAM after the CRC calculation has completed.
  • Ensure that the whole descriptor chain is executed by a single input trigger, otherwise another channel performing CRC calculations could become active during the individual trigger events.

Version: **

GTM (Generic Timer Module) implemented in AURIX™ TC2xx supports only up counter mode. GTM implemented in AURIX™ TC3xx supports up-down counter mode.

Note: This KBA applies to the following series of AURIX™ MCUs:

• AURIX™ TC2xx series
• AURIX™ TC3xx series

Version: **

In the VADC module, one ADC converter has one dedicated Sample&Hold unit (no multiple S&H units).

Therefore, the maximum number of analog input channels that can be measured simultaneously is up to the maximum number of the AD converters implemented in the VADC module.

(For example, VADC of TC27x has eight AD converters. Therefore, up to eight analog input channels can be measured simultaneously.)

For more details, see the “Summary of Features” section in the datasheet.

Note:   This KBA applies to the following series of AURIX™ MCUs:

• AURIX™ TC2xx series
• AURIX™ TC3xx series

Version: **

There is no specific crystal recommendation for AURIX™ MCUs. All typical crystals in the market in the specified frequency range should run with these MCUs. The crystal specifications can be found in the device-specific datasheet. For more details on crystal fundamentals, see the AP56002 application note.

Note :  This KBA applies to the following series of AURIX™ MCUs:

• AURIX™ TC2xx series
• AURIX™ TC3xx series

Version: **

To create a library project in AURIX™ Development Studio, do the following:

1. Click File > New > New AURIX™ Project from the AURIX™ Development Studio toolbar as Figure 1 shows.

2. Select Infineon > New AURIX™ Library Project > Next from the New Project window as Figure 2 shows.

3. Follow the wizard steps, to select the project name and the target device as shown in Figure 3 and Figure 4 respectively.

4. By default, AURIX™ Development Studio creates an empty library project with a static library archive (.a file) as Figure 5 shows, which can be filled with the decided content.

Figure 5    Library project

Version: **

The metadata of an object can be changed if the Life cycle state Object (LcsO) of the object is not in operational or termination state. If the object is in operational state, use the protected update with necessary access conditions for the metadata update.

The Protected Update feature allows you to make an integrity protected update of any data object (not key objects) on the OPTIGA™ Trust M V1. OPTIGA™ Trust M V3 allows integrity and confidentiality protected update of any data objects including key objects. The following objects are excluded from the integrity protected update:

• Life Cycle Status (Global or Application)
• Security Status (Global or Application)
• Coprocessor UID
• Sleep mode activation delay
• Current Limitation
• Security Event Counter
• Last Error Code
• Maximum Com Buffer Size

Figure 1 shows the high-level structure of the updated data set for data or key objects along with manifest and the connected binary data.

Figure 1    Structure of the Manifest

The coding of the structure is according to [CBOR]. The [CDDL] format for the manifest and signature structures are provided in the package.

Manifest is a top-level construct that ties all other structures together and is signed by an authorized entity whose identity is represented by a trust anchor installed in OPTIGA™. The trust anchor is addressed by its unique Object Identifier (OID), which is contained in the metadata of the manifest.

Manifest consists of the metadata in plain text, the payload or fragment binding, and the signature over metadata and payload binding. Data to be updated is organized in the form of fragments. Each fragment consists of data and hash of next fragment except the last fragment. Payload binding is the hash of the first fragment.

The integrity protection of the object data is based on the successful verification of the signature over the metadata and fragment binding hash value. 

The confidentiality protection is based on a shared secret installed at OPTIGA™. See section 6.7.1 of the Solution Reference Manual for the details regarding key derivation, encryption, and decryption.

In order to generate manifest according to [CBOR], you can use the tool present in GitHub.

Manifest generation using the CBOR tool needs inputs such as Trust Anchor OID (the public key for verification), Target OID, private key for signing the manifest, payload type (data or key or metadata), which are described in GitHub. See GitHub for sample update datasets.

Necessary access conditions for update:

1. For Metadata update, Metadata Update Descriptor tag (0xD8) with the respective trust anchor OID must be present in the target OID metadata.
2. For confidentiality protected update, Protected update descriptor tag (0x23) should be the data object type of the shared secret OID.
3. For Metadata update of an object, Reset type tag (0xF0) must be present which determines what will happen to data object.
4. The Trust anchor, which is used for verification of manifest, must contain the data object type tag with the respective tag type. For example, if you are using a 0xE0E3 as Trust Anchor for verification, the data object type tag must be of the Public key certificate type.

Metadata Update Process:

Following is an example of updating the metadata of an object with OID as 0xE0E2 (Public Key Certificate) and whose LcsO status is in operational:

1. Necessary conditions:

• As shown in Figure 2, the data followed by the Metadata Update Descriptor tag (0xD8) and Reset type tag (0xF0) are present in the metadata of the target OID, so that metadata can be updated.

• In Figure 3, metadata of 0xE0E8 has a data object type tag (0xE8) with a value of 0x11 (Trust Anchor type), to use the stored public key certificate for signature verification.

Figure 3      Metadata of Trust Anchor OID

2. Manifest generation:

• Manifest is a structure which contains metadata in plain text, payload binding, and signature over metadata and payload binding.
• Manifest is generated using the CBOR tool as follows:
• priv_key: This specifies the path of the private key file (pem format) which is used for signing.
• trust_anchor_oid: This must containa public key certificate for the corresponding private key specified above. This certificate stored in trust_anchor_oid is used to verify the signature. Here, we use 0xE0E8 as trust_anchor_oid.
• sign_algo: This specifies the algorithm to be used for signing.
• payload_type: This specifies the type of update. Since we are doing metadata update, we specify it as metadata.
• metadata: This specifies the path of metadata file (text format) which contains the metadata that has to be updated.
• content_reset: This specifies what should happen to data in the object if metadata is changed. Here we specify it to change as per the reset type flag in updated metadata.
• In case of data or key update, manifest generation is done using different options described in GitHub.

Figure 4    Generating Manifest

• Manifest and data fragment is generated upon successful execution as shown in Figure 4.
• Every time you want to update the metadata of a particular object, the payload version must increase. For example, if you update the metadata of an object with payload version as 3, the next time when you update the metadata of the same object, the payload version must be greater than 3.

Figure 5    Generated Manifest

• Generated manifest and fragments are passed as parameters to the Protected update API’s to start the update of an object as shown in Figure 5.

3. Protected update operations:

• Follow the sequence of operations as shown in Figure 6 for a protected update.

Figure 6    Protected Update Process

•  Further the update process is done by optiga_util - Protected update APIs.
• optiga_util_protected_update_start(optiga_util_instance, manifest_version, manifest, manifest_length):
• This operation initiates the protected update of data or key objects in OPTIGA™.
• The manifest provided will be validated by OPTIGA™.
• Upon successful validation, it checks whether the access conditions of the object permit protected update or not.
• If access conditions are satisfied, the data fragments are sent to the object by using the following functions.
  -optiga_util_protected_update_continue(optiga_util_instance,fragment , fragment_length): This operation sends the fragments to OPTIGA™. If number of fragments is n, the first (n-1) fragments are sent.
  -optiga_util_protected_update_final(optiga_util_instance,fragment , fragment_length): This operation sends the final fragment to OPTIGA™ and finalizes the protected update of OPTIGA™ object.

Version: **

In AURIX™ MCUs, program flash has 20 years of data retention time while the data flash has 10 years. Because the program flash is written only a few times or maybe only once during production while data flash is written continuously in some applications. Both flash types use different technologies, so the retention time is also different.

Note that the 10-years data retention for data flash is valid only in the case of data written once and never updated again.

Table 1 Flash target parameters for TC29x

Note: This KBA applies to the following series of AURIX™ MCUs:

• AURIX™ TC2xx series
• AURIX™ TC3xx series

Version: **

The tools available in the toolchain, enables the user to manually add flags by editing the Command line pattern under the Expert settings.

Open the Build settings of a project, right-click on a project, then select the Properties -> C/C++ Build -> Settings -> TASKING C/C++ Compiler.

Additional flags can be added manually after the placeholder ${FLAGS} in the Command line pattern text field, as shown in the figure below.

Note:   This KBA applies to the following series of AURIX™ MCUs:

• AURIX™ TC2xx series
• AURIX™ TC3xx series

Version: **

The exposed die pad is used for cooling purposes and to allow better heat dissipation. It should be placed on the bottom side of the VQFN-8-4 package layout. The exposed die pad, referenced as (C) in the following figure, must be connected to the common ground reference (GND) for heat distribution. This ensures a big copper plane for optimal thermal dissipation and avoids electrostatic discharge (ESD).

The contacts and their functionality are given in the following table

Version: **

The net bandwidth, which can be achieved with HSSL, varies in a wide range from just a fraction up to ~82% of the maximal available bandwidth of 320 MBaud. By knowing the deterministic timings of the different HSSL commands, the feasibility of an intended application use case can be planned and optimized.

Here, the timings are summarized as bare metal, which means, the impact of the less deterministic and application-specific software timings are not considered to the most extent possible.

READ transaction timings

A READ request/response-pair is triggered from the initiator’s side by writing to the Initiator Read Write Address register IRWA.ADDRESS of the respective channel. The processing within the initiator’s HSSL peripheral takes some latency until the READ frame appears on the wire. Once the last bit appears on the wire, the target’s HSSL peripheral processes the request, executes the read command - which adds some more latency - until the target responds with a READRESPONSE frame, which is sent back to the initiator. After the initiator processes the response, the transaction is completed by resetting the ICON.BSY-flag of the respective channel. This is illustrated in the following figure.

Note:      The timings above do not include the register access time of the local CPU to configure and set up the HSSL READ-command itself. Those timings are left out intentionally, because of their software architecture and application-specific nature. To take the access time to the HSSL registers roughly into account, an add-on of approximately 0.35 µs is a good estimation or indication for both, the TC3xx and TC4xx families.

From the table above, it is clear that reducing the baud rate (160 Mbaud, 80 Mbaud) increases the hardware latencies. This increase does not scale linearly, because only a portion of the HSSL peripheral module  operates on the selected baud rate, while a major part of the module still operates on the nominal peripheral’s module clock of 320 MHz. Therefore, the net bus utilization (in the range from ~11% to ~15%) is slightly better on lower baud rates than on higher baudrates.

WRITE transaction timings

Similar to the READ command, a WRITE request/response-pair is triggered from the initiator’s side by writing to the Initiator Read Write Address register IRWA.ADDRESS of the respective channel. The hardware latency characteristics are the same as those in the READ-commands. When the initiator has received and processed the ACK-response from the target, the transaction is completed, by resetting the ICON.BSY-fla of the respective channel. This is illustrated in the following figure.

In the following table, the theoretical bus_active time is the calculated time, which is consumed for the bits on the wire at the given baud rate. The hardware latencies add to further delays to the total transaction time which is needed for the complete request/response pair. The total transaction time for writing 32 bits is then set in relation with the baud rate to calculate the utilization of the bus:  

Note :    The timings above do not include the register access time of the local CPU to configure and set up the HSSL READ-command itself. Those timings are left out intentionally, because of their software architecture and application-specific nature. To take the access time to the HSSL registers roughly into account, an add-on of approximately 0.35 µs is a good estimation or indication for both, the TC3xx and TC4xx families.

Latencies and timings of a WRITE-transaction are largely comparable to those of a READ-transaction. Also, for WRITE-transactions, the net bandwidth utilization (in the range from ~11% to ~15%) is slightly better on lower baud rates than on higher baud rates.

STREAMING transaction timings

The Streaming mode is preferred to reach the maximum net bandwidth utilization. Within one STREAM-frame of 313 bits, a total payload of 256 bits is transferred as shown in the following figure.

For a high number of STREAM frames, the overhead of the last ACK-frame and the bus latencies can be ignored. In this case the net bandwidth utilization approximates to its maximum. To calculate it, only the STREAM frames and the payload they carry need to be considered:

                                  Max. net bandwidth utilization = 256 bits / 313 bits = 81.8%

Before starting the streaming, ensure the following:

• The source address is programmed into ISSA0.START register of the initiator device
• The destination address is programmed into the TSSA0.ADDR register of target device
• The frame count (transaction size) is programmed into the ISFC.RELCOUNT register (initiator) and the TSFC.RELCOUNT register (target)
• MFLAGSSET.TSES is set to enable the target for receiving a streaming transaction

Once both devices are configured for the streaming transaction, the streaming is triggered by the initiator, by setting MFLAGSSET.ISBS. Once the streaming is complete, the MFLAGS.ISB flag is reset by the initiator’s HSSL module peripheral as shown in the following figure:

Hardware latency overhead on streaming transactions

As shown in the figure above, for unidirectional streaming, hardware latency adds overhead to the total transaction time at the beginning, when the streaming is triggered and at the end, when the last ACK-frame is received and processed by the initiator.

The overall hardware latency duration is not influenced by the total transaction size but it is influenced by the selected baud rate.

In the following tables, the theoretical bus_active time is the calculated time, which is consumed for the bits on the wire at the given baud rate. The hardware latencies add further delays to the total transaction time, which is needed for the complete streaming transfer. The total transaction time for transferring the data, which is carried inside the STREAM frames is then set in relation with the baud rate to calculate the net bandwidth utilization. The timings for 320 MBaud, 160 MBaud, and 80 MBaud can be found in separate tables below:  

The following figure provides a good overview of the bus utilization as a function of the total transferred payload at different baud rates:

Target setup time overhead on streaming transaction

To set up a streaming transaction, both the initiator and target need to be configured for the transfer. For setting up the target, typically the following registers need to be written:

• Configuration register CFG
• Target Streaming Start Address register TSSA0
• Target Stream Frame Count register TSFC
• Miscellaneous Flags Set register MFLAGSSET

From a software perspective it is useful, if the initiator takes full control of setting up the complete streaming transaction. For this purpose, these registers can be set up on the target remotely, by the initiator, using four HSSL WRITE-commands.

These four HSSL WRITE-commands from the initiator to the target consume a considerable time overhead for every streaming transaction. Therefore, this option and the impact on net bus utilization is considered here:  

The typical timing, to set up and execute four HSSL WRITE-commands are:

Note :         The timings above also include the typical register access time of the local CPU (each ~0,35 µs) to the HSSL-registers needed to set up the HSSL WRITE-command itself on the initiator. In general, those timings depend on the software architecture and have an application-specific nature. The timings provided here do serve as a good estimation or indication for both the TC3xx and TC4xx families.

Now, taking the overhead of the configurational HSSL WRITE-commands from the initiator to target into account, the following net bus utilization can be reached:

Version: **

This KBA presents the results of performance measurements performed on different combinations of locations of source and store buffers using image-based rendering mode (IBO) and line-based rendering mode (LBO).

Software environment used:

• Green Hills MULTI 2017.14
• TRAVEO™ T2G graphics driver v1e.1.0

Reference documents:

• 002-27763: CYT3DL datasheet
• 002-25454: Graphics Driver for TRAVEO(TM) T2G Cluster Series User Guide

Software setup:

Figure 1 is a sample image used as the source surface for blitting. The image resolution is 400x480 PPI. Depending on the store and source surfaces configuration, this image is stored in either Video RAM (VRAM), HYPERRAM™, or HYPERFLASH™.

The color format of both source and store surface is chosen as R8G8B8A8.
Every result is recorded over a blit of 300 iterations.

Figure 1   Source image taken for blit (400x480)

Table 1 shows the surface configurations used.

Table 1  Timing results captured for different source and store combination

Timing results:

Table 3  Internal flash to VRAM

 
Table 4  VRAM to VRAM

 
Table 5   VRAM to HYPERRAM™

 
Table 6   HYPERRAM™ to VRAM

 
Table 7  HYPERRAM™ to HYPERRAM™

 
Table 8   HYPERFLASH™ to VRAM

Notes:

• Memory Bandwidth reducing LBO performance: Memories other than VRAM can transfer only less than or equal to 32 bits in one clock cycle. In additional, in LBO mode three fetches may happen at different locations in memory which can create additional overhead of non-sequential memory access for external memories. Hence LBO is even slower compared with IBO when all the source images are in external memories (e.g.: internal flash). The performance LBO/IBO becomes better if you use smaller bits per pixel (BPP) sources.
• For example, if you compare for blending to target HRAM, LBO/IBO ratio is larger than factor 3. This is because blending of multiple single images requires to read and write the target buffer for each single blit. LBO blends all images in internal buffer together and writes the result only one time.
• When using LBO, disabling Object Partitioning may sometimes make the blit a little faster.

 
Note:     This KBA applies to the following series of TRAVEO™ MCUs:

TRAVEO™ T2G Cluster CYT3DL series

In the magnetic sensor development tool, Infineon provides complete supporting software and source code based on Arduino platform; However, this article summarizes the usage of MS2GO EVM board based on Dave IDE, and provides the method of using printf() function to output in the console column.

Part 1: How to use printf() in console?

Step 1: Debug -> Debug Configuration -> Startup, as shown in picture;

Step 3:  Add "initialise_monitor_handles();" into the main().

int main(void)
{
	initialise_monitor_handles();
......
        printf(...);
......
}

 Part 2: The source code of MS2GO for DAVE

The source code is attached and can output data in LSB form, the way to translate data into real value we need can be found in datasheet,

Version: **

The primary monitor operation is based on tracking an analog-to-digital converter (ADC) to measure the supply voltages. It is clocked and the clock cycle value is updated for every power management controller (PMC) for the AURIX™ TC2xx devices and power management system (PMS) for the AURIX™ TC3xx devices. However, the maximum real reaction time for a fast voltage spike is greater because of the tracking ADC nature. See the datasheet for the tMON (Max) parameter value for primary monitor reaction time.

The secondary monitor on AURIX™ MCU is based on a dedicated 8-bit SAR ADC for each channel VDD, VDDP3. Each channel is sampled with a maximum 600 ns period. In addition, there is a 3x spike filter applied. There is a maximum of 1.8 µs for the reaction time of supervisor mode (SVM).

For more details, see the following sections in the User’s manual:

• “Voltage Monitoring” section in the “System Control Units” chapter for AURIX™ TC2xx device
• “Supply Voltage Monitoring” section in the "Power Management System (PMS) chapter for AURIX™ TC3xx devices

Note:  This KBA applies to the following series of AURIX™ MCUs:

• AURIX™ TC2xx series
• AURIX™ TC3xx series

Version: **

On the AURIX™ TC2XX devices, the modulator and demodulator are used together; therefore, delta-sigma analog-to-digital converter (DSADC) does not interface with an external delta-sigma ADC modulator directly.

However, on AURIX™ TC3XX devices, demodulator can be used separately, so enhanced DSADC can interface with an external delta-sigma modulator to get the data stream.

 Figure 2 Enhanced delta-sigma analog-to-digital converter

For more details, please see the following sections of the User’s manual:

• For AURIX™ TC2xx series: “Delta-Sigma Analog-to-Digital Converter (DSADC)” section
• For AURIX™ TC3xx series: “Enhanced Delta-Sigma Analog-to-Digital Converter (EDSADC)” section

Note:  This KBA applies to the following series of AURIX™ MCUs:

• AURIX™ TC2xx series
• AURIX™ TC3xx series

Version: **

The default switching frequency is 1.5 MHz during embedded voltage regulator (EVR) start up and you can configure this frequency between 0.4 MHz to 2.0 MHz after ramp-up.

For details, see the “System Control Unit (SCU)” section for TC2xx and the “Power Management System (PMS)” section for TC3xx of the User’s manuals.

Note:  This KBA applies to the following series of AURIX™ MCUs:

• AURIX™ TC2xx series
• AURIX™ TC3xx series

Version: **

For a parallel conversion, up to four Analog-to-Digital Converter (ADC) in a synchronization group can be exactly synchronized.

In case of more than four ADCs, there are variations of each ADC start time with the range of a few cycle of analog clock (fADC). Therefore, they are almost synchronized, if the same ADC trigger source input to each ADCs.

For more details, refer to the “Versatile Analog-to-Digital Converter (VADC)” se

Note:   This KBA applies to the following series of AURIX™ MCUs:

• AURIX™ TC2xx series
• AURIX™ TC3xx series

Version: **

There are two types of NC balls:

• NC: Not Connected. These pins are reserved for future extensions and shall not be connected externally.
• NC1: Not Connected. These pins are not connected at the package level and will not be used for future extensions.

The general rule is that NC and NC1 must not be connected to any net including power supply or ground connections in the PCB routing.

Note:  This KBA applies to the following series of AURIX™ MCUs:

• AURIX™ TC2xx series
• AURIX™ TC3xx series

Version: **

Input voltage high for S pad (V_IHS) and input voltage low (V_ILS) for S pad are as follows:

1. For AURIX™ TC2xx MCU series:

• V_DDM = 5 V

• V_DDM = 3.3 V

2. For AURIX™ TC3xx MCU series:

• V_DDM = 5 V

• V_DDM = 3.3 V

Class S pads are powered by V_DDM and can also be 3.3 V and 5 V.

Where,

V_DDM = Analog power supply

For more details, see the “Electrical Specification” sections of the TC2xx series and TC3xx series datasheets.

Note: This KBA applies to the following series of AURIX™ MCUs:

• AURIX™ TC2xx series
• AURIX™ TC3xx series