Code Composer Studio forum - Recent Threads

TMDSEMU200-U: Error 2131

M R Tyagi — Fri, 24 Jul 2026 11:19:51 GMT

Theese is an Error -2131 (Unable to access device register) which indicate that Code Composer Studio (CCS) is communicating successfully with the XDS200 debugger, but the debugger cannot establish a stable connection with the target chip on your card.

AM263P4: Doubt regarding variables getting updated live without pausing the debugger

Rishabh Kumar Bhakta — Fri, 24 Jul 2026 09:29:11 GMT

Part Number: AM263P4

Hi ti team
is there any way can i watch my global values being updated in real time instead of pausing it to watch the latest value. I am using the ccs 20.4.1 version

MSPM33-SDK: MCAN module and filters

Sebastien Le Diouris — Thu, 23 Jul 2026 13:02:44 GMT

Part Number: MSPM33-SDK
Other Parts Discussed in Thread: MSPM33C321A, SYSCONFIG

Hello,

I am working on MSPM33C321A eval board, especially on MCAN module. I have several messages to monitor but I see the .syscfg file, limits the number of filters at 2 only:

Here, only message with ID 3 and 4 will be filtered.

How can I do to add filters (means more messages which can monitor) ?

Thanks

AM6442: R5 Core Global Variable view refresh in debug mode

Bhaskar Reddy — Wed, 22 Jul 2026 07:52:17 GMT

Part Number: AM6442

Further to below link, is there any update in CCS that makes the viewing of global expressions added to watch window or memory window refresh continuosly.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1313986/tmds64evm-am6442

As of now, I need to halt manually or with a breakpoint to be able to see the value in global expression or memory.

UNIFLASH: UniFlash 9.6 / CCS DebugServer (DSLite) fails with boost::filesystem::create_directories when Windows username contains non-ASCII characters

승현 박 — Wed, 22 Jul 2026 00:39:17 GMT

Part Number: UNIFLASH
Other Parts Discussed in Thread: TMS320F280039C

Environment

OS: Windows 11 Pro (64-bit)
User account: Windows username contains Korean (non-ASCII) characters
UniFlash: 9.6.0.5764
CCS: Latest CCS (same issue)
Device: TMS320F280039C
Emulator: XDS110 (or your actual emulator)

I cannot use either CCS or UniFlash to connect to or program my F280039C device.

Both CCS and UniFlash fail before attempting to connect to the target.

The problem appears to occur inside DebugServer (DSLite).

[ Error ]

Version: 9.6.0.5764

Executing the following command:
> "...DebugServer\bin\DSLite" flash flash --config ... --list-cores

boost::filesystem::create_directories:
[system:123]:
"C:\Users\?\ti",
"C:\Users\?"

If this continues, please run fsclean or set TI_APPDATA_DIR to directory you have permissions to access

The Korean username is displayed as "?".

It appears DebugServer cannot create its working directory because the Windows user profile contains non-ASCII characters.

I verified that:

DSLite itself launches correctly.
The .ccxml file is valid.
The project path contains only ASCII characters.
The error occurs before any JTAG connection.
The same problem occurs in CCS and UniFlash.

I also tried all of the following environment variables:

TI_APPDATA_DIR
USERPROFILE
HOME
TEMP
TMP
HOMEDRIVE
HOMEPATH

But, The error remains exactly the same.

*Questions*

Is this a known limitation or bug in UniFlash 9.6 / DebugServer?
Is there any workaround without creating a new Windows account that has an ASCII-only username?
Is there a newer DebugServer or patch that correctly supports Unicode Windows usernames?
Why does TI_APPDATA_DIR appear to be ignored?

Thank you.

CODECOMPOSER: Where should gitignore go?

Keith Barkley — Tue, 21 Jul 2026 02:02:14 GMT

Part Number: CODECOMPOSER

While git integration seems to be improved in 21, I am still confused.

I added all the /debug files into gitignore by rightclicking them, and when I saved it, it offered up the project file.

But when I closed and opened CCS, all the /debug files were still there, and when I right clicked to add them to gitignore, it was empty!

Where should the gitignore file go?

TMDSEMU110-U: TMDSEMU110-U: nonfunctional

Saad Thabit49 — Mon, 20 Jul 2026 14:38:17 GMT

Part Number: TMDSEMU110-U
Other Parts Discussed in Thread: UNIFLASH

Product name & part number: XDS110 Debug Probe / TMDSEMU110-U

Description of the issue: The unit stopped working. It is unable to program the target device. When attempting to push the code, received "Error -267 @ 0x0." We are lucky to have purchased two XDS110, the second unit is working fine.

Purchase details:

Order number: T06402857
Date of purchase April 30, 2026

Environment:

Operating System (OS): macOS
IDE / Software Version: UniFlash v8.x / Emulation Package 20.5.0.3900
Connection Method: USB via a multi-port USB-C Hub.

TMS320F280037: rom symbmol libs location

DTruex — Sun, 19 Jul 2026 19:24:51 GMT

Part Number: TMS320F280037
Other Parts Discussed in Thread: C2000WARE

I can't find the CCS project to rebuild this library in COFF format. Where is it located?C2000Ware_5_05_00_00

#10373-D library "C:/ti/c2000/C2000Ware_5_05_00_00/libraries/boot_rom/f28003x/rev0/rom_symbol_libs/bootROM/F28003xCPU1_BootROM_Symbols.lib" contains ELF object files which are incompatible with the TI-COFF output file. Ensure you are using the proper library. BF100 C/C++ Problem

Thanks

ARM-CGT-CLANG: TM4C1294NCPDT: TivaWare 2.2.0.295 DriverLib cannot be rebuilt with TI Arm Clang 4.0.4 due to legacy assembly directives

Arthur Yang — Fri, 17 Jul 2026 17:47:59 GMT

Part Number: ARM-CGT-CLANG
Other Parts Discussed in Thread: TM4C1294NCPDT

I am trying to migrate a TM4C1294NCPDT project from the legacy TI ARM Compiler (armcl) to TI Arm Clang 4.0.4.

The project is based on the TivaWare 2.2.0.295 Ethernet/lwIP examples (enet_io).

Initially, the application failed to link because the prebuilt DriverLib was compiled with

--wchar_t=16

while the TI Clang application objects were built with:

--wchar_t=32

resulting in the linker warning/error:

#16032-D: object files have incompatible wchar_t types

driverlib.lib<emac.obj> = --wchar_t=16

cgifuncs.o = --wchar_t=32

To avoid ABI mismatches, I attempted to rebuild DriverLib using TI Arm Clang 4.0.4.

DriverLib rebuild issues

Issue 1: epi_workaround_ccs.s

The DriverLib build initially failed on:

epi_workaround_ccs.s

with errors indicating unsupported assembly syntax.

Since my application does not use the EPI peripheral, I excluded this file from the build and continued.

Issue 2: Undefined CPUcpsid(), CPUcpsie(), SysCtlDelay()

After rebuilding DriverLib, the application link failed with:

undefined symbol CPUcpsid

undefined symbol CPUcpsie

undefined symbol SysCtlDelay

Tracing the source code showed that these functions are conditionally compiled under:

#if defined(ccs)

For example:

#if defined(ccs)

uint32_t

CPUcpsid(void)

{

__asm(" mrs r0, PRIMASK\n"

" cpsid i\n"

" bx lr\n");

return(0);

}

#endif

I therefore added: -Dccs to the DriverLib project.

Issue 3: TI Clang rejects legacy assembly directives

After defining ccs, DriverLib compilation fails in sysctl.c:

<inline asm>:1:5: error: unknown directive

.sect ".text:SysCtlDelay"

<inline asm>:2:5: error: unknown directive

.clink

<inline asm>:3:5: error: unknown directive

.thumbfunc SysCtlDelay

The errors indicate that TI Clang does not recognize the legacy assembler directives used in the TivaWare implementation of SysCtlDelay().

Questions

Is TivaWare 2.2.0.295 officially supported for rebuilding with TI Arm Clang?
Is there a TI-provided Clang-compatible version of DriverLib for TM4C devices?
Are there recommended replacements for the legacy implementations of:

CPUcpsid()

CPUcpsie()

SysCtlDelay()

when building DriverLib with TI Arm Clang?

Is there any migration guide specifically for rebuilding TM4C DriverLib libraries using TI Arm Clang?
Is the recommended approach to:
- continue using the legacy armcl-compiled DriverLib, or
- modify DriverLib sources for TI Clang compatibility?

Environment

Device: TM4C1294NCPDT
CCS: 20.4.1.4
Compiler: TI Arm Clang 4.0.4.LTS
TivaWare: 2.2.0.295
Example: enet_io (lwIP)

Any guidance on the recommended migration path from armcl to TI Arm Clang for TM4C/TivaWare projects would be greatly appreciated.

Thank you.

MSP430-GCC-OPENSOURCE: Possible compiler bug: caller-saved register is not saved across indirect call

Christian Frey — Fri, 17 Jul 2026 12:20:13 GMT

Part Number: MSP430-GCC-OPENSOURCE
Other Parts Discussed in Thread: MSP430F249

I iterate over a table of function-pointers, placed inside the flash-memory using the linker-script. GCC keeps the loop/iteration pointer in r12 across the indirect call. I understand r12 to be a caller-saved register, so the called function if free to clobber the register and the caller should preserve it across the call.

Here is my example application:

typedef void(*sys_init_t)(void);

static void init_fn_0(void) {
    /* trivial, does not disturb r12 */
}

static void init_fn_1(void) {
    volatile int a = 1, b = 2, c = 3, d = 4, e = 5;
    (void)a; (void)b; (void)c; (void)d; (void)e;
    /* enough live locals at -Os to force r12 use as scratch */
}

__attribute__((section(".sys_init"), used))
static const sys_init_t init0 = init_fn_0;

__attribute__((section(".sys_init"), used))
static const sys_init_t init1 = init_fn_1;

extern const sys_init_t __sys_init_start;
extern const sys_init_t __sys_init_end;

void sys_init(void) {
    for(const sys_init_t* fn = &__sys_init_start; fn < &__sys_init_end; fn++) {
        (*fn)();
    }
}

int main() {
    sys_init();
    return 0;
}

I use the original linker-script for the MSP430F249 with the following addition to the SECTIONS part:

.sys_init :
{
  __sys_init_start = .;
  KEEP(*(.sys_init));
  __sys_init_end = .;
} > ROM

I'm building the application like this:


msp430-elf-gcc -mcpu=msp430 -mmcu=msp430f249 -g0 -Os -D__MSP430F249__=1 -c main.c -o main.o
msp430-elf-gcc -mcpu=msp430 -mmcu=msp430f249 -g0 -Os -D__MSP430F249__=1 -T linker.ld main.o -o example.out

The generated assembly code for the sys_init function is this:

00001148 <sys_init>:
    1148:    3c 40 00 11     mov    #4352,    r12    ;#0x1100

0000114c <.L4>:
    114c:    3c 90 04 11     cmp    #4356,    r12    ;#0x1104
    1150:    01 28           jnc    $+4          ;abs 0x1154
    1152:    30 41           ret            

00001154 <.L5>:
    1154:    3d 4c           mov    @r12+,    r13    ;
    1156:    8d 12           call    r13        ;
    1158:    f9 3f           jmp    $-12         ;abs 0x114c

As one can see, after the call r13 we jump right back to 0x114c, where r12 is evaluated again, even though the called function could have clobbered the register. In that case, the code will crash.

msp430-elf-gcc --version:

msp430-elf-gcc (Mitto Systems Limited - msp430-gcc 9.3.1.11) 9.3.1

CCSTUDIO-THEIA: CCS 20.4.1.4 Disassembly view binary output is incorrect for 48-bit+ packets

William Rose — Wed, 15 Jul 2026 16:38:22 GMT

Part Number: CCSTUDIO-THEIA
Other Parts Discussed in Thread: F29H85X-SOM-EVM

In CCS theia version 20.4.1.4__1.10.1 when debugging an F29H85X-SOM-EVM, the binary of 48-bit or larger instruction packets in the 'Disassembly View' displays the second halfword twice, rather than displaying the third halfword. For example:

0x10002172 0fa8 2f47 2f47      CALL    @#0x10108000
0x10002178 0a44 0004 0004      MV      A4,#0x30180004

In the 'Memory View', this shows correctly as `2F470FA8 0A440008 30180004`, which corrected for little endian would display as:

0fa8 2f47 0008
0a44 0004 3018

This is correct (as the operand of 48-bit instructions is little endian, and `CALL` instructions are calculated as signed offsets), however the displayed disassembly is not.

This always applies to the third halfword of the packet, even when it is not the third in an instruction, for example:

0x1000227C 8f66 a911 a911 7325 0048 0120
                                     BCMP    @#0x1000230c,A.LT,A9,A0
                                  || SUBR.U16        A1,A1,#0x4
                                  || MV      A2,A5

CCSTUDIO-OPENOCD: Question regarding device support roadmap for the TI Embedded Debug VS Code extension

Sang-il Nam — Wed, 15 Jul 2026 01:46:42 GMT

Part Number: CCSTUDIO-OPENOCD

Hi,

I confirmed via the link below that TI provides an Embedded Debug extension for VS Code.
In the list of supported devices, I found the MSPM0, MSPM33, and SimpleLink series. I would like to know whether support for other MCU/DSP families—including the C2000 MCUs—is planned to be added, or whether the extension will continue to support only low-power application MCUs and wireless connectivity devices as it currently does.

TI Embedded Debug for VS Code

Best regards,
Sang-il

CCSTUDIO-THEIA: C2000 Performance Advisor Option Change

David Messerschmidt — Tue, 14 Jul 2026 19:00:14 GMT

Part Number: CCSTUDIO-THEIA

Hi,

I recently updated to 21.0.0.14__1.12.0 from 20.5.0.28__1.11.0 and noticed that my existing .cproject files for my 2805x project has a build error. It looks like all previous versions of CCS expected the "Provide advice on optimization techniques (--advice:performance) " textbox to read in the format of "--advice:performance=all", but the 21.0.0 version expects "all". This breaks backwards compatibility with my team, some of which are stuck using older CCS versions but sharing the same .cproject files.

Pre CCS 21 expects this:

CCS 21 expects this:

CCS 21 error when building with the "--advice:performance=all" in the textbox:

C:/ti/compilers/ti-cgt-c2000_22.6.1.LTS/bin/cl2000" ... --advice:performance=--advice:performance=all ...

CCS 20 error when building with the "all" in the textbox:

C:/ti/compilers/ti-cgt-c2000_22.6.1.LTS/bin/cl2000" ... all ...

CCSTUDIO-THEIA: CCS 21.0.0 Project cannot be found / Cannot read properties of undefined

David Messerschmidt — Tue, 14 Jul 2026 18:46:38 GMT

Part Number: CCSTUDIO-THEIA

Hi,

I recently updated to 21.0.0.14__1.12.0 from 20.5.0.28__1.11.0, and have been trying it on projects that I have been using for years.

I am often running into an issue where I build, start debugging for a while, then I make changes and try to rebuild, but the "Building..." notification appears and goes away after half a second and nothing happens. If I disconnect the debugger and try to start debugging again, I get the "Project 'x' cannot be found" error in Output ccs: executable-actions log.

Also, if I try to open the project properties at this point, I get the following notification: "Cannot read properties of undefined (reading 'activeBuildConfiguration')" even though the GUI shows I have a currently selected build config selected.

Refreshing Theia (Ctrl+R) or closing+opening the application fixes the issue. This doesnt happen every time (I can build and flash okay a few times), but I have never gone longer than about 10 minutes without this issue happening.

I think this may be similar to https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1657666/mspm0g1507-ccs-21-0-0-sporadic-error-when-debug, but I do not have any executable actions for this project. I followed the instructions to clear the CCS cache, but no luck.

CODECOMPOSER: Linker Issue Tag_DSP_extension with ti-cgt-armllvm_5.1.1.LTS

Luka Rahne — Tue, 14 Jul 2026 11:59:52 GMT

Part Number: CODECOMPOSER
Other Parts Discussed in Thread: SYSCONFIG

Issue is that linker from

ccs2100/ccs/tools/compiler/ti-cgt-armllvm_5.1.1.LTS

Fails linking our application with sysconfig shiped with simplelink_cc13xx_cc26xx_sdk_8_32_00_07

Error:
"C:/ti/simplelink_cc13xx_cc26xx_sdk_8_32_00_07/source/ti/ble5stack/libraries
/cc26x2r1/StackWrapper.a<osal_clock.o>" has a Tag_DSP_extension attribute
value of "1" that is different than one previously seen ("0"); combining
incompatible files

if we use linker from
ccs2020/ccs/tools/compiler/ti-cgt-armllvm_4.0.3.LTS

Then it works fine

Relevat libraries from generated sysconfig ti_utils_build_linker.cmd.genlibs

/* libraries required for /third_party/spiffs */
-l"third_party/spiffs/lib/ticlang/m4f/spiffs_cc26xx.a"

/* libraries required for /ti/ble5stack */
-l"ti/ble5stack/libraries/cc26x2r1/OneLib.a"
-l"ti/ble5stack/libraries/cc26x2r1/StackWrapper.a"
-l"ti/ble5stack/libraries/cc26x2r1/ble_r2.symbols"

/* libraries required for /ti/drivers/RF */
-l"ti/drivers/rf/lib/ticlang/m4f/rf_multiMode_cc26x2.a"

/* libraries required for /ti/drivers */
-l"ti/drivers/lib/ticlang/m4f/drivers_cc26x2.a"
-l"ti/grlib/lib/ticlang/m4f/grlib.a"

/* libraries required for /ti/devices */
-l"ti/devices/cc13x2_cc26x2/driverlib/bin/ticlang/driverlib.lib"

/* libraries required for /ti/sysbios */
-l"ti/sysbios/lib/ticlang/m4f/sysbios.a"

TMS570LS3137: Which CCS to use with TMS570LS31HDK

Zoltan Molnar — Mon, 13 Jul 2026 17:00:13 GMT

Part Number: TMS570LS3137

I would like to develop a new application on the TMS570LS3137. I got the development board, but the new CCS does not recognize the device or board.

The USB driver for the debugger installed fine, is visible on control panel.

Tried the lates CCS and the 12.8.1 version too, same behavior.

What would be a tool chain that gives out of the box working experience on this dev kit?

Is there a blinky led example project that can be compiled and loaded with a particular version of CCS for this processor / board?

Thank you

TMDSEMU200-U: Error -2131 connecting to TMS320DM6446AZWTA

Jay-J Hambling — Mon, 13 Jul 2026 11:09:11 GMT

Part Number: TMDSEMU200-U
Other Parts Discussed in Thread: CCSTUDIO, TMS320DM6446,

Hi I'm having somet trouble and would appreciate any help.

Recieved XDS200 brand new friday to replace an older XDS510. Followed small quick start guide included, the desktop weuse is on CCStudio V5.3 which should be compatiable. Checked in device manager and the drivers look to have automatically assigned correctly. Created a new target confid selectring the right connection and device. Try to begin debug and get error -2131.

When I attempt to do the test congifuration this the output: [Start].txt

[Start]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -r -o -S pathlength -S integrity

[Result]

-----[Perform the standard path-length test on the JTAG IR and DR]-----------

This path-length test uses blocks of 512 32-bit words.

The test for the JTAG IR instruction path-length failed.
The many-ones then many-zeros tested length was 16384 bits.
The many-zeros then many-ones tested length was 0 bits.

The test for the JTAG DR bypass path-length failed.
The JTAG DR bypass scan-path is stuck-at-ones.

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 512 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Test 2 Word 0: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 1: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 2: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 3: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 4: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 5: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 6: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 7: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 2, skipped: 0, failed: 1
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 2
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 3
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 4
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 5
Some of the values were corrupted - 83.3 percent.

The JTAG IR Integrity scan-test has failed.

-----[Perform the Integrity scan-test on the JTAG DR]------------------------

This test will use blocks of 512 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Test 1 Word 0: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 1: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 2: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 3: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 4: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 5: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 6: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 7: scanned out 0xFFFFFFFF and scanned in 0x00000000.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 1, skipped: 0, failed: 1
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 1
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 2
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 3
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 4
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 5
Some of the values were corrupted - 83.3 percent.

The JTAG DR Integrity scan-test has failed.

[End]

TMS320F28379S: project files

HS FAE Germany — Mon, 13 Jul 2026 08:12:39 GMT

Part Number: TMS320F28379S

Hi,
customer uses CCS v21 and their own make files. He generates .elf output.
Which project files (.ccsproject, .cporject, .project, .settings. out) are still needed and needs to be stored in version control?
Which are used by the debugger?

Regards, Holger

AUDIO-AM62D-EVM: "Reconnecting to TI Cloud Agent" message in CCS

Aparna Dutta — Mon, 13 Jul 2026 07:30:44 GMT

Part Number: AUDIO-AM62D-EVM

Hello,

We have installed CCS (tried out versions 20+, 21+), but it continually shows the message "Reconnecting to TI Cloud Agent", and we are not able to proceed with connecting to the target (AUDIO-AM62D-EVM).

Please suggest steps to resolve this issue.

Regards,

Aparna

CCSTUDIO-THEIA: AI chat panel file links open in external browser instead of jumping to file/line in editor (CCS v21, Theia)

Nicolae Grigoras — Sun, 12 Jul 2026 17:21:25 GMT

Part Number: CCSTUDIO-THEIA

When the built-in AI agent references a source file (e.g. after analyzing or editing code), the file links it renders are not navigable within the IDE. Clicking them opens an external web browser instead of jumping to the referenced file and line in the CCS editor.
Example link produced by the AI panel:
`http://<random-uuid>.webview.localhost:<port>/webview/C2000-MPPT02-HRPWM.c#L397-L398`
Expected behavior:
Clicking the link (or the AI panel providing it) should open `C2000-MPPT02-HRPWM.c` in the CCS editor and navigate to lines 397–398, the same way file references behave elsewhere in Theia-based tooling (e.g. VS Code's `vscode.open` command with a range).
Actual behavior:
The link is a plain HTTP anchor pointing at the webview's own sandboxed local server (`webview.localhost:<port>`), with a GitHub/VS Code-style `#L397-L398` fragment appended. Since this is treated as a normal external URL rather than an IDE navigation command, the OS/default browser opens it as a web page. The fragment has no meaning outside the webview context, so even the browser tab doesn't land anywhere useful.
Suspected root cause:
The AI chat panel appears to be a Theia webview (each webview instance gets its own randomized `*.webview.localhost` origin for sandboxing). File references inside that webview are being rendered as ordinary `<a href="http://...">` anchors rather than being routed back through the Theia extension host via `postMessage` (or a registered command URI) to trigger an actual "open file at range" action. A plain anchor tag has no way to reach the IDE's file-opening API, so it falls through to default OS link handling.
Suggested fix:
Route file references generated by the AI panel through Theia's internal open-editor command (equivalent to VS Code's `vscode.open` with a `Range`) via the webview's message-passing API, instead of emitting them as external HTTP anchors.
Steps to reproduce:
Open CCS v21 with a C2000 project.
Ask the built-in AI agent to analyze/review a source file.
In the AI's response, note the file reference link (format: `http://<uuid>.webview.localhost:<port>/webview/<filename>#L<start>-L<end>`).
Click the link.
Observe: opens in external browser instead of the CCS editor at the specified line.
Impact:
Breaks the intended workflow of jumping directly from an AI code review to the referenced location in source — users must manually locate the file and line number instead.

TMS320F28377S: SysConfig support for LaunchPadXL F28377S

A K — Sun, 12 Jul 2026 08:36:53 GMT

Part Number: TMS320F28377S
Other Parts Discussed in Thread: SYSCONFIG, , C2000WARE, TMS320F28377D

Hi,

the SysConfig tool seems really helpful for configuring peripherals. Unfortunately, it seems that it does not support the LaunchPadXL F28377S board, only the F28377D.

I was wondering if it possible to add this somewhat older board to SysConfig.

Alternativerly, can I find some resource that tells me the difference between the LaunchPadXL F28377S and F28377D?

Thank you for your assistance,

Alex

MSPM0G3105-Q1: MSPM0G3105-Q1 Compatible tool for coding and compilation with Safety Compliance

Mary Infanta — Fri, 10 Jul 2026 09:30:33 GMT

Part Number: MSPM0G3105-Q1

Hello,

I have chosen MSPM0G3105-Q1 for one of the ASIL-B, ASIL-D system development. I need to qualify my product as functionally safe, for which I want the tool I use for coding and compilation also to be qualified as safety compliant.Please assist me in finding out the right software coding and compiler tool for developing a ASIL B,D compliant product.

AM6421: AM64 chip GPIO related issues

?? ? — Fri, 10 Jul 2026 02:36:23 GMT

Part Number: AM6421

Hello,

We are currently using the AM64 chip and have a question to ask.
The BUFFERTYPE, E9, and A10 in the data sheet are I2C OD FS, but the others are LVCMOS. My question is, can I2C OD FS and LVCMOS be switched through software configuration? Or do E9 and A10 have to be external pull up?

CODECOMPOSER: CCS TI Compiler x8.5.0.LTS -- can we configure CCS project to also generate coff file?

Sunny Ubergeek — Thu, 09 Jul 2026 17:51:00 GMT

Part Number: CODECOMPOSER

Hello,

We are using the CCS TI Compiler x8.5.0.LTS. can we configure to also generate coff file? if so how? When we tried to select output format of COFF, we could not save this option and rebuild on CCS GUI like we can with i.e., elf option. Is there another way to generate a COFF file with CCS?

See below screen shot with COFF

(below screen shot with elf)

CODECOMPOSER: CCS CMD File and gel files to fit larger code size

Sunny Ubergeek — Thu, 09 Jul 2026 17:29:30 GMT

Part Number: CODECOMPOSER
Other Parts Discussed in Thread: OMAP-L137

Hello,

Our code got too large for how the cmd file and gel files were configured, with error in CCS below, and configuration of cmd file below and gel file attached. When we tried to move .text and .far into the EMIFBSDRAM in the cmd file then when we start the CCS, the debugger cannot find main to stop at anymore. When we tried moving other sections, the debugger has a verification error. Can anyone explain in general how we can move the CCS code sections like .text and .far section to the larger memory in our memory map where the debugger can still find the main function (i.e., do certain sections always have to be together in the same memory map section)? Does this require modifying other files or the CCS debug configuration so the jtag can locate the code to single step through? Thank you again.

(error from CCS)

error #10099-D: program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section, or the section contains padded functions. run placement with alignment fails for section ".far" size 0x2082c. Available memory ranges:
IRAM size: 0x40000 unused: 0x18a0c max hole: 0x18a0c

(cmd file configuration)

MEMORY
{
DSPL2ROM : org = 0x700000, len = 0x100000
DSPL2RAM : org = 0x800000, len = 0x40000
DSPL1PRAM : org = 0xe00000, len = 0x8000
DSPLDPRAM : org = 0xf00000, len = 0x8000
SHDSPL2ROM : org = 0x11700000, len = 0x100000
IRAM : org = 0x11800000, len = 0x40000
CACHE_L1P : org = 0x11e00000, len = 0x8000
CACHE_L1D : org = 0x11f00000, len = 0x8000
EMIFASDRAM : org = 0x40000000, len = 0x8000000
EMIFACS2 : org = 0x60000000, len = 0x2000000
EMIFACS3 : org = 0x62000000, len = 0x2000000
EMIFACS4 : org = 0x64000000, len = 0x2000000
EMIFACS5 : org = 0x66000000, len = 0x2000000
L3_CBA_RAM_ID : org = 0x80000000, len = 0x1000
L3_CBA_RAM_BL : org = 0x80001000, len = 0xf000
L3_CBA_RAM : org = 0x80010000, len = 0x10000
EMIFBSDRAM : org = 0xc0000000, len = 0x10000000
}

SECTIONS
{
.text: load > IRAM
.ti.decompress: load > IRAM
.stack: load > IRAM
GROUP: load > L3_CBA_RAM
{
.bss:
.neardata:
.rodata:
}
.cinit: load > L3_CBA_RAM
.pinit: load > L3_CBA_RAM
.init_array: load > IRAM
.const: load > L3_CBA_RAM
.data: load > IRAM
.fardata: load > IRAM
.switch: load > L3_CBA_RAM
.sysmem: load > IRAM
.far: load > IRAM
.args: load > IRAM align = 0x4, fill = 0 {_argsize = 0x0; }
.cio: load > L3_CBA_RAM
.ti.handler_table: load > IRAM
.c6xabi.exidx: load > IRAM
.c6xabi.extab: load > IRAM
.id: load > L3_CBA_RAM_ID
.clk: load > IRAM
.prd: load > IRAM
.swi: load > IRAM
.tsk: load > IRAM
.idl: load > IRAM
.idlcal: load > IRAM
.hwi_vec: load > IRAM
.sysdata: load > IRAM
.dsm: load > IRAM
.mem: load > IRAMfreertosdsp.gel
.bios: load > IRAM
.gio: load > IRAM
.sys: load > IRAM
.sysregs: load > IRAM
.gblinit: load > IRAM
.sysinit: load > IRAM
.trcdata: load > IRAM
.hwi: load > IRAM
.rtdx_text: load > IRAM
.TSK_idle$stk: load > IRAM
.LOG_system$buf: load > IRAM
.rtdx_data: load > IRAM
.hst1: load > IRAM
.hst0: load > IRAM
.trace: load > IRAM
.hst: load > IRAM
.log: load > IRAM
.pip: load > IRAM
.sts: load > IRAM
.heap: load > L3_CBA_RAM
.L3_CBA_RAM_ID: load > L3_CBA_RAM
.l3_cba_ram_bl: load > L3_CBA_RAM_BL
.L3_CBA_RAM$heap: load > L3_CBA_RAM
.printf: load > L3_CBA_RAM
.ppinfo: load > IRAM
.ppdata: load > IRAM
.binit: load > IRAM
.vecs: load > IRAM
.obj: load > IRAM

}

Thank you again.