Part Number: AM2612
Announcement: Zephyr RTOS Pre-release available on the AM261x SoC!We’re excited to announce that preliminary support for Zephyr RTOS is now available on Athe M261x microcontroller. This integration unlocks a modern, highly scalable, open-source operating system for developers building industrial networking and real-time applications on the AM261x platform.
---
Why Zephyr on AM261x?| Benefit | What it means for you |
| Low‑Latency Real‑Time Performance | Deterministic scheduling and submillisecond interrupt latency for time‑critical workloads |
| Modular Architecture | Pull in only the kernel features you need, keeping binary size minimal (as low as a few KB) |
| Device‑Tree‑Driven Configuration | Simplifies board bring‑up and peripheral enablement with a single source of truth |
| Extensive Community & Vendor Ecosystem | Leverage a growing library of drivers, middleware, and sample applications |
Getting Started
- Install the Zephyr SDK (v0.16.1 or newer).
- Use the recommended GCC‑Arm Embedded toolchain (`arm-none-eabi-gcc >= 10.3`).
west init -m https://github.com/TexasInstruments/zephyr/tree/am261x/release zephyrproject cd zephyrproject west update
Zephyr now ships a ready‑to‑use board definition: `am261x_lp`
west build -b am261x_lp samples/hello_world
Use existing tools like TI Uniflash GUI tool to flash the image. Steps here
More info - Link
It is recommended to use CCS for flashing & debugging binary.the image. Steps here
More info - Link
Launch Pad support for AM261x
R5F (arch) support for interrupts, Cache, MPU configs
IOMUX controls via pinctrl
Systick support with RTI as Tickless Kernel enablement
MBox Driver enabled in compatibility with IPC notify Layer
UART, GPIO Peripheral Support
Resources| Resource | Links |
| Zephyr RTOS Documentation | https://docs.zephyrproject.org |
| AM261x Hardware Reference | www.example.com/.../hwref |
| Getting Started Guide (PDF) | www.example.com/.../zephyr‑quick‑start.pdf |
| Community Forum | forum.zephyrproject.org/.../am261x |
| Sample Repository | github.com/.../am261x-zephyr-samples |
Support & Feedback- Technical Support: Open a ticket in E2E forum (Tags “Zephyr – AM261x”).
- Community Contributions: Pull requests adding drivers, board configurations, or sample applications are always welcome!
---
Let’s Build the Future Together!The AM261x series now has the power and flexibility of Zephyr RTOS at its fingertips. Whether you’re prototyping a Motor Controller or a small robot, Zephyr gives you a modern, open‑source foundation to accelerate development.
Happy coding!
The AM261x & Zephyr Integration Team
Part Number: AM2612
1. IND COMMS SDK
2. CCS
3. Compiler
4. Syscfg
5. Uniflash GUI
7. LP-AM261x
Install all requirements mentioned in requirements.txt (Location - ind_comms_sdk/mcu_plus_sdk/requirements.txt)
/*Navigate to mcu_plus_sdk folder and then run the following command*/ pip install -r requirements.txt
Overview- The Profinet demo on AM261x-LP supports execution from external flash i.e XIP. So to properly run the example we need to program the sbl_ospi_mcelf and application image(.mcelf) into flash using Uniflash tool, then set boot mode to OSPI, and then we can see successful run logs. Follow the below steps:
[172] Boot multi-core ELF image: am261x:r5fss0-0:freertos:ti-arm-clang C:/Users/a0492123/workspace_ccstheia/profinet_device_demo_am261x-lp_r5fss0-0_freertos_ti-arm-clang/Release/profinet_device_demo_am261x-lp_r5fss0-0_freertos_ti-arm-clang.mcelf ... [173]python C:/ti/ind_comms_sdk_am261x_10_02_00_15/mcu_plus_sdk/tools/boot/multicore-elf/genimage.py --core-img=0:Release/profinet_device_demo_am261x-lp_r5fss0-0_freertos_ti-arm-clang.out --output=C:/Users/a0492123/workspace_ccstheia/profinet_device_demo_am261x-lp_r5fss0-0_freertos_ti-arm-clang/Release/profinet_device_demo_am261x-lp_r5fss0-0_freertos_ti-arm-clang.mcelf --merge-segments=true --tolerance-limit=0 --ignore-context=false --xip=0x60000000:0x68000000 --xlat=none --max-segment-size=8192 [174] Boot multi-core ELF image: C:/Users/a0492123/workspace_ccstheia/profinet_device_demo_am261x-lp_r5fss0-0_freertos_ti-arm-clang/Release/profinet_device_demo_am261x-lp_r5fss0-0_freertos_ti-arm-clang.mcelf Done !!! [175] . [176] Boot image: am261x:r5fss0-0:freertos:ti-arm-clang C:/Users/a0492123/workspace_ccstheia/profinet_device_demo_am261x-lp_r5fss0-0_freertos_ti-arm-clang/Release/profinet_device_demo_am261x-lp_r5fss0-0_freertos_ti-arm-clang.appimage Done !!! [177] .
SBL - sbl_ospi_mcelf (location - ind_comms_sdk/mcu_plus_sdk/tools/boot/sbl_prebuilt/am261x-lp)
Application profinet_device_demo_am261x-lp_r5fss0-0_freertos_ti-arm-clang.mcelf (location - CCS workspace)
XIP Image - profinet_device_demo_am261x-lp_r5fss0-0_freertos_ti-arm-clang.mcelf_xip ((location - CCS workspace)
Click on load image.
Part Number: AM2612
Hi ASM team,
I get the following error after trying to build a simple GPIO toggle program on a clean install of the 10_02_00_15 SDK. Have we seen this before? 
All the best,
Ethan Cope
Part Number: MCU-PLUS-SDK-AM263X
Tool/software:
Hi TI experts,
I'm trying to run the sbl_qspi_enet application on AM263x. I see that the documentation (software-dl.ti.com/.../EXAMPLES_DRIVERS_SBL_QSPI_ENET_AM263X.html) mentions about the "enet_uniflash.py" file, which should be present in mcu_plus_sdk/tools/boot folder. I don't see any such file in the v10.02 and v11.0 SDK. Can you please help find the file.
Thanks
Part Number: MSPM0C1104
Tool/software:
Here provide an script to do factory reset with J-Link, there is an readme file to show you how to do it. Important thing is remember to modify the device in open factory_reset.bat and connect the reset pin with J-link.
Part Number: LP-AM261
Tool/software:
Hi TI experts,
I am using TI AM26x MCUs and trying to connect the board to my PC. When I try to connect to a CPU in CCS target configuration & debug window, I see the following error codes in the console:
CS_DAP_0: Error connecting to the target: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package xx.xx.xx.xx)
-----[An error has occurred and this utility has aborted]----
This error is generated by TI's USCIF driver or utilities.
The value is '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.
The explanation is:
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.
Can you please help me resolve the error?
Part Number: MSPM0L1306
Tool/software:
This thread just for update the BSL_GUI_EXE. Due to some software release limitation, we can't put the MSPM0_BSL_GUI.exe file into our SDK < …\mspm0_sdk_xxxx\tools\bsl\BSL_GUI_EXE >.
It need customer use the source file to generate the MSPM0_BSL_GUI.exe with the open source file in the folder BSL_GUI_source_code. More details please refer to README file. But it need to install some python and some support packages environment that may block some users. Here I will put the MSPM0_BSL_GUI.exe file here and you just need to download and unzip
Part Number: RM44L520
Tool/software:
I have been using Clang/LLVM, specifically ARM's ATfE distribution, to compile HALCoGen-generated code. It mostly works great, but there are a few issues that have to be worked around. I'm documenting them here in case anybody else finds it useful, and in case the engineers at TI want to fix these issues in a future version. In all cases I think these changes are all compatible with GCC, armcl, and armclang, and in most cases fix reliance on undefined behaviors deprecated instructions.
Pre-UAL assembly instructions in sys_core.s
I get these two assembler errors multiple times in sys_core.s:
fmxr error: invalid instruction
fmdrr error: invalid instruction
Root cause:
Workaround:
Assemble with -x assembler-with-cpp -Dfmxr=vmsr -Dfmdrr=vmov
Proposed upstream fix:
Find/replace in sys_core.s template(s): fmxr to vmsr, fmdrr to vmov
(Note: this issue also affects FreeRTOS portasm.s)
sys_core.s uses FP instructions but doesn't specify an FPU type
Once the above Pre-UAL instructions are fixed, I get the next set of errors on the same lines as in the previous issue:
vmsr error: instruction requires: VFP2
vmov error: instruction requires: fp registers
Root cause:
When the LLVM assembler encounters a .cpu directive, it ignores any -mcpu= or -mfp= flags specified on the command line.
Workaround:
Assemble with -x assembler-with-cpp -Dcpu=extern
This works by replacing the .cpu directive with a .extern directive, which doesn't wind up having any effect on the generated code since no symbol cortex-r4 exists in the project. The assembler then falls back on the command-line -mcpu= or -mfp= flags.
Proposed upstream fix:
Add a .fpu directive such as the following to the sys_core.s template(s):
.fpu vfpv3-d16
(Note: this issue also affects FreeRTOS portasm.s)
Non-ASM statement in naked function _c_int00
Compiling sys_startup.c results in the following error:
error: non-ASM statement in naked function is not supported
102 | _coreInitRegisters_();
Root cause:
_c_int00 has the naked attribute, but contains statements other than basic asm statements. This is undefined behavior in GCC. GCC's manual (https://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html#index-naked-function-attribute_002c-ARM) says:
Only basic asm statements can safely be included in naked functions. While using extended asm or a mixture of basic asm and C code may appear to work, they cannot be depended upon to work reliably and are not supported.
However, GCC doesn't attempt to prevent this unsupported usage. Clang enforces the requirement that naked functions only contain basic asm statements.
Fortunately, _c_int00 can be made into a non-naked C function with noreturn if _coreInitRegisters_ and _coreInitStackPointer_ are called before it is entered.
Workaround option 1:
Modify sys_startup.c USER CODE blocks 5 and 7 as follows:
__attribute__ ((naked))
/* SourceId : STARTUP_SourceId_001 */
/* DesignId : STARTUP_DesignId_001 */
/* Requirements : HL_SR508 */
void _c_int00(void)
{
/* USER CODE BEGIN (5) */
__asm__(
"bl _coreInitRegisters_\n\t"
"bl _coreInitStackPointer_\n\t"
"b _c_int00_c"
);
}
__attribute__ ((noreturn))
void _c_int00_c(void)
{
#if 0
/* USER CODE END */
/* Initialize Core Registers to avoid CCM Error */
_coreInitRegisters_();
/* USER CODE BEGIN (6) */
/* USER CODE END */
/* Initialize Stack Pointers */
_coreInitStackPointer_();
/* USER CODE BEGIN (7) */
#endif // 0
/* USER CODE END */
Workaround option 2:
To work around this issue without modifying any HALCoGen-generated files:
__attribute__((naked)) void __wrap__c_int00(void)
{
__asm__(
"bl __real__coreInitRegisters_\n\t"
"bl __real__coreInitStackPointer_\n\t"
"b __real__c_int00"
);
}
void __wrap__coreInitRegisters_(void)
{}
void __wrap__coreInitStackPointer_(void)
{}
Proposed upstream fix:
Calls to picolibc memcpy() in het.c cause data aborts
The program gets stuck in _dabort from a memcpy call in hetInit() when compiled against picolibc's memcpy.
Root cause:
I can't find any explicit documentation that hetRAM1 and hetRAM2 require word-aligned stores, but nevertheless that does appear to be the case. hetInit() is counting on memcpy to perform word-aligned stores into hetRAM1 and hetRAM2. However the spec for memcpy() makes no such guarantee, and recent versions of picolibc and newlib include memcpy() implementations that break this assumption, leading to data access faults.
Workaround:
void *device_memcpy(void *dest, const void *src, size_t n)
{
uint32_t *d = dest;
const uint32_t *s = src;
n /= 4;
while (n--) {
*d++ = *s++;
}
return dest;
}
Tip: I apply this workaround using the following CMake snippet to ensure the -D flag is only passed to the compiler when compiling het.c:
Proposed upstream fix:
Replace calls to memcpy() in hetInit() with calls to the above device_memcpy() implementation.
Part Number: AM263P4
Tool/software:
In this FAQ i will show you the configurations required to enable the interrupts for pins MCU_GPIO64 and MCU_GPIO63 in MCAL for AM263P4.
Part Number: LP-AM261
Tool/software:
Hi experts,
I am using the AM261x-LP. I am using the automotive-add-on board (DP83TG720/721) on top of the LaunchPad. I have followed all the steps mentioned in the documentation, checked syscfg pinmux, but I am unable to achieve a MAC port link up and establish a proper communication with the AM261x-LP.
Can you please help debug and provide the steps to achieve a successful link up, have MAC Port open and establish a successful ethernet communication?