TI AM243x
The TI AM243x are industrial‑grade real‑time microcontrollers based on Arm® Cortex‑R5F cores, designed for deterministic control and high‑performance industrial networking applications.
Supported devices
Refer to the supported device list for a full list of all supported AM243x family devices, their corresponding names and connection diagrams.
Target interfaces
| Interface | J-Link support | Flasher support |
|---|---|---|
| JTAG |  |
|
Flash banks
| Flash bank | Base address | J-Link support | Flasher support | Loader | |
|---|---|---|---|---|---|
| Name | Bank size | ||||
| OSPI flash | 0x60000000 | |
|
Default | Up to 64 MB |
Note that flash programming is only supported through R5FSS0_CORE0.
Watchdog handling
- The device has a dedicated watchdog for each of the cores (MCU_RTI0, RTI8, RTI9, RTI10, RTI11).
- As flash programming is only handled from R5FSS0_CORE0, only watchdog RTI8 is handled.
- If the watchdog RTI8 is enabled, it is fed during flash programming, taking the configured window size into account.
Device specific handling
Connect
As the AM243x device series features multiple cores, certain initialization steps needs to be performed to connect to some of the cores. Please refer to the section Multi-core support for instructions on how to connect to each of the cores.
Reset
- In multi-core based setups, reset of the secondary cores is usually very use case specific (e.g. reset selected core only; reset other cores / peripherals as well). The standard reset strategy for Cortex-A/R is based on a pin reset which would mess up the entire debug session. For that reason, the J-Link SW does not perform anything on reset. If a device specific reset handling is required, it needs to be implemented using a J-Link script file.
Attach
Attach is a debugging feature which exclusively applies to J-Link and J-Trace and does not apply to Flasher.
- Attach is supported
Multi-core support
Before proceeding with this article, please refer to the generic article regarding multi-core debugging here.
The AM243x family comes with one M4F core and 1, 2 or 4 R5F cores.
| Core | J-Link support |
|---|---|
| MCU_M4FSS0 |
|
| R5FSS0_CORE0 |
|
| R5FSS0_CORE0 |
|
| R5FSS1_CORE0 |
|
| R5FSS1_CORE1 |
|
By default, only R5FSS0_CORE0 and (if present) R5FSS0_CORE1 are running after reset. In the case of SPI boot, the other cores are started by the Secondary Bootloader (SBL), which is executed by the core R5FSS0_CORE0.
Below the debug related multi-core behavior of the J-Link is described for each core:
R5FSS0_CORE0 / R5FSS0_CORE1
These two cores are running by default after reset.
Init/Setup
- R5FSS0_CORE0 and R5FSS0_CORE1 are by default running after reset and can be connected to without further initialization steps.
- If the target is in DEV boot mode, some peripherals may be uninitialized and inaccessible. In order to gain full access to all peripherals, the DMSC needs to be initialized. Please refer to the section Initializing the DMSC for instructions on how to do this.
Reset
No reset is performed.
- A generic reset of this core is currently not supported by J-Link. This means that a core reset is not performed when issued by a debugger (e.g. SEGGER Ozone).
If a reset of this core is required, this needs to be implemented via a customized ResetTarget() J-Link script file function.
If you are interested in a customized ResetTarget() implemented by SEGGER, please get in touch with us directly: https://www.segger.com/support/technical-support/.
Attach
- Attach is supported.
R5FSS1_CORE0 / R5FSS1_CORE1
Init/Setup
- If the target is in SPI boot mode and the Secondary Bootloader (SBL) is configured to start this core by default, nothing further needs to be done. The core can be accessed as-is.
- If the target is in DEV boot mode, the core has to be started by loading the DMSC firmware. Please refer to the section Initializing the DMSC for instructions on how to do this.
Reset
No reset is performed.
- A generic reset of this core is currently not supported by J-Link. This means that a core reset is not performed when issued by a debugger (e.g. SEGGER Ozone).
If a reset of this core is required, this needs to be implemented via a customized ResetTarget() J-Link script file function.
If you are interested in a customized ResetTarget() implemented by SEGGER, please get in touch with us directly: https://www.segger.com/support/technical-support/.
Attach
- Attach is supported.
MCU_M4FSS0
Init/Setup
- If the target is in SPI boot mode and the Secondary Bootloader (SBL) is configured to start this core by default, nothing further needs to be done. The core can be accessed as-is.
- If the target is in DEV boot mode, the core has to be started by loading the DMSC firmware. Please refer to the section Initializing the DMSC for instructions on how to do this.
Reset
No reset is performed.
- A generic reset of this core is currently not supported by J-Link. This means that a core reset is not performed when issued by a debugger (e.g. SEGGER Ozone).
If a reset of this core is required, this needs to be implemented via a customized ResetTarget() J-Link script file function.
If you are interested in a customized ResetTarget() implemented by SEGGER, please get in touch with us directly: https://www.segger.com/support/technical-support/.
Attach
- Attach is supported.
Initializing the DMSC
The TI AM243x device family features the Device Management and Security Control (DMSC) subsystem, which performs centralized boot, power, security, and resource management functions. This runs on an auxiliary Cortex-M3 core. This core needs to run a precompiled, TI-provided SYSFW image. In SPI boot mode, the SYSFW image is loaded to the DMSC by the Secondary Bootloader (SBL) executed by the R5FSS0_CORE0 core after reset. In DEV boot mode the SBL is not executed, and thus DMSC is not running by default. In order to start the DMSC, the SYSFW needs to be loaded by executing a precompiled binary for the R5FSS0_CORE0. This file is included in the MCU-PLUS-SDK-AM243X, under mcu_plus_sdk_am243x_XX_XX_XX_XX/tools/ccs_load/am243x/sciclient_ccs_init.release.out. This file can be executed on the R5FSS0_CORE0 by running the following J-Link commands, after connecting to the R5FSS0_CORE0:
halt // Halt R5FSS0_CORE0
//
// !!! TODO: Update TI AM243x SDK path !!!
//
loadfile "C:\TI\mcu_plus_sdk_am243x_11_01_00_19\tools\ccs_load\am243x\sciclient_ccs_init.release.out" // Load TI sciclient_init program to RAM
setpc 0x0 // Set program counter to start of RAM
go // Start R5FSS0_CORE0
exit // Close J-Link Commander
As the DMSC initialization needs to be performed after every power cycle, the commands can be saved as a J-Link Command File and executed by running a batch script:
REM !!! TODO: Update path to JLink.exe executable !!!
start /wait JLink.exe -device AM2431_R5 -if jtag -jtagconf -1,-1 -speed 4000 -autoconnect 1 -commandfile am243x_load_dmsc.jlink
exit
An .zip file containing the J-Link Command file and the batch script can be downloaded under the following link:
After downloading the zip file, following steps are required:
- Unzip the .zip file
- In am243x_load_dmsc.jlink: Update the path to TI MCU-PLUS-SDK-AM243X
- In am243x_load_dmsc.bat: Update the path to the JLink.exe executable. For a default installation, this should be "C:\Program Files\SEGGER\JLink_VXXX\JLink.exe"
Once the paths are set, the DMSC initialization should be run by executing the batch file am243x_load_dmsc.bat after every power-on reset.
EMU0 & EMU1
In addition to the standard JTAG signals, the debug interface on AM243x features two extra signals, EMU0 and EMU1. These two signals control the following:
| Sampling Time | EMU1 | EMU0 | Boot Mode / Boundary Scan Compliance |
|---|---|---|---|
| MCU_PORz deassertion | 0 | 0 | Reserved for future use |
| MCU_PORz deassertion | 0 | 1 | Reserved for future use |
| MCU_PORz deassertion | 1 | 0 | Wait-In-Reset (WIR) |
| MCU_PORz deassertion | 1 | 1 | Normal |
| TRSTn deassertion | 0 | 0 | Boundary Scan Enabled |
| TRSTn deassertion | 0 | 1 | Boundary Scan Enabled |
| TRSTn deassertion | 1 | 0 | Boundary Scan Disabled |
| TRSTn deassertion | 1 | 1 | Boundary Scan Disabled |
Please refer to the AM64xx/AM243x Technical Reference Manual for a detailed description of these signals.
When using a TI evaluation board with an onboard XDS110 debug probe, these signals are by default pulled high. This results in the configuration Normal Boot, Boundary Scan Disabled, which is appropriate for debugging each of the cores. If using J-Link and connecting to an AM243x evaluation board using the TI-CTI-20 connector, the signals are left unconnected, thus the connection with J-Link does not interfere with the board configuration. For custom use-cases where these signals might need to be manipulated during debugging, the signals can be connected to J-Link and controlled using custom J-Link script files. If you are interested in a customized J-Link script file which handles EMU0 and EMU1 implemented by SEGGER, please get in touch with us directly: https://www.segger.com/support/technical-support/.
Device Provisioning
Device provisioning on AM243x devices is possible using J-Link and Flasher, by integrating OTP key writing into the final executable image.
- Key provisioning can only be performed using the official OTP Keywriter Package provided by TI. This includes the SYSFW keywriter, which is provided as a binary blob and runs on the DMSC, as well as the keywriter application, provided as source code running on the R5_0 core. Both components are integrated into the final ROM-bootable image tiboot3.bin.
- One additional constraint for eFuse burning during OTP key writing is a VPP voltage of 1.8V. The VPP enable sequence can be integrated into the keywriter application running on the R5_0 core.
- In order to handle device provisioning using J-Link, this final image can be programmed to the OSPI flash.
- After the device boots from the OSPI flash, the TI OTP Keywriter application and the associated keywriter SYSFW automatically perform the provisioning process on-device, including programming OTP keys and enabling secure boot.