XMC4xxx series

This article describes device specifics of the Infineon XMC4500 microcontroller.

Flash sector limitations

The Infineon XMC4500 device series comes with the following physical sector layout:

• 2 * 64 KiB
• 1 * 128 KiB
• x * 256 KiB

The first 64 KiB physical sector consists of four logical 16 KiB sectors which can be accessed (erased) individually. Therefore instead of erasing the whole 64 KiB physical sector, the first physical sector can be erased 16 KiB wise and therefore, e.g. used to have a bootloader which does not change in the first 16 KiB logical sector while having the application starting in the second logical sector (offset 16 KiB). This way, the application can be exchanged without erasing the bootloader.

However, the J-Link software uses the physical sector layout for two reasons:

• Writing into logical flash sectors disturbs adjacent data in the remaining logical sectors and thus increasing the risk of having incorrect data stored in the remaining memory sectors
• Decrease of total flash erase cycles possible as a logical sector access promotes uneven memory degradation

For further information regarding this, please refer to the technical reference manual of the Infineon XMC4500 series.

However, under special circumstances customers may want to use the logical sector layout. For such scenarios, the J-Link DLL allows to perform a read-modify-write to a flash sector in order to *not* erase certain parts of the physical sector when programming / erasing logical sectors.

Further information regarding this as well as an example can be found here.

Attach to running application

For the Infineon XMC4xxx series devices it is not supported to attach to a running target. J-Link needs to perform a reset during the connect phase, to guarantee a stable debug connection and session. This behavior was requested by Infineon when support for the XMC4xxx series was implemented by SEGGER. Without a reset being performed at start of the debug connection, unexpected behavior of target applications have been seen because the MCU seemed to not behave correctly from the debug side.

JTAG chain

The XMC 4xxx-series requires a specific connect sequence in which the JTAG chain is configured. By default, the XMC4xxx device is expected to be at the first position of the chain with one different, unknown device behind it. Therefore, when using a different setup, the JTAG chain has to be configured manually since there is no way to auto-detect the position reliably. In such cases, please get in touch with SEGGER directly via our support system: https://www.segger.com/ticket/.

User application triggered resets

In some test setups, the user application may trigger resets of the devíce to give it a fresh start or reboot it after enabling another test mode etc.
So, the application would basically cause a reset asynchronously to J-Link ("behind the back of J-Link").
While these kinds of resets are no problem for most devices, it is problematic on the Infineon XMC4xxx series.
This is because the XMC4xxx has a ROM bootloader that runs after reset and which samples the debug pins TCK/SWCLK and TMS/SWDIO and depending on their value, the boot ROM boots the chip in a specific mode.
If for example such an asynchronous reset is triggered by the application while J-Link currently serves a "IsHalted" request or similar from the debugger, there is activity on the debug pins,
so depending on when the reset becomes active, the boot ROM may sample different states of the debug pins and boot the chip into an unexpected more, causing unpredictable behavior during the test setup.

Therefore, asynchronous resets during debug should be avoided on this device series.
It is strongly recommended to perform a cooperative reset issued by J-Link, so it has a chance to bring the debug lines into the expected state, before the boot ROM samples them.