AM2612: Unstable Debugging Operation

Ted Huh

Part Number: AM2612
Other Parts Discussed in Thread: TIDA-010979, TMDSEMU110-U, XDS110ISO-EVM, LP-XDS110

Hello Champs,

I'm using XDS110 and AM2612. while debugging I found out some unstable operation of XDS110 and CCS 20.5

Debug session operate as if it got caught by breakpoint sometimes, even if I didn't set the breakpoint
on the watch, if i try to change the value, sometimes it does not change and while running it shows only 0. only when I pause, it shows right value. changing the value only works well on pause.
When running the board for a long time(3min), suddenly board operate stops and log also stops, but debug session also does not shows anyting. at this time, PC counter value is 0x000068xx which is user never sets up.

Could you let me know how to resolve these issues? Ore if I use more high performance debugger, are these issues going away?

Regards,

Ted

1 month ago

0 Fleenor 1 month ago

TI__Mastermind 37573 points

Hi Ted,

Are you using a TI EVM with the onboard XDS110? Or is this custom hardware?

Best Regards,

Zackary Fleenor

0 Ted Huh 1 month ago in reply to Fleenor

TI__Expert 3555 points

This happens on

1. TIDA-010979 board

2.Customer's board

with XDS110.

Regards,

Ted

0 Fleenor 1 month ago in reply to Ted Huh

TI__Mastermind 37573 points

Thank you for the info Ted,

By XDS110 here, are your referring to the TMDSEMU110-U? (TMDSEMU110-U Debug probe | TI.com) device?

Have you tried running the same code on a launchpad or similar EVM and experienced the same issues?

Best Regards,

Zackary Fleenor

0 Ted Huh 1 month ago in reply to Fleenor

TI__Expert 3555 points

TMDSEMU110-U, LP-XDS110, XDS110ISO-EVM, all the same.

global variables are not updated in real-time and ghost breakpoint happens. about the PC counter, exact address is

PC 0x0000866E Program Counter

What is in here?

Regards,

Ted

0 Fleenor 1 month ago in reply to Ted Huh

TI__Mastermind 37573 points

Hey Ted,

A few points of feedback based on what you've shared:

PC at 0x0000866E — Check your linker map file to determine what code or exception handler resides at this address. On AM261x, low addresses in the 0x0000xxxx range typically correspond to the R5F TCM-A (local view). This could be an abort handler or uninitialized exception vector.
Watch variables showing 0 while running —

This is not a bug — it's expected behavior for the AM26x ARM Cortex-R5 core. On some devices, the JTAG debug architecture supports real-time mode — a hardware feature that allows the debugger to read registers and memory without halting the CPU. The AM26x Cortex-R5 debug architecture does not have this capability. However, the following options are available:
You can implement real-time debug on AM26x devices (including the AM261x) using the CS_DAP connection. Here's the procedure:

Real-Time Debug via CS_DAP

Launch your target configuration (.ccxml) in CCS

Connect to R5_0 core, load your program, and resume execution (the core must be running)

Right-click on the .ccxml in the Debug window → select "Show all cores" to expose CS_DAP_0

Connect to CS_DAP_0

Open View → Memory Browser, select CS_DAP_0 context with "System View" and enable "Continuous Refresh"

Important Caveats

Variables must be global for the DAP to access them

RAM variables: Call CacheP_wbInv() in your code to flush cache to memory, otherwise the DAP won't see updated values

TCM variables: You must translate the CPU address to the System/DAP address using the device TRM memory map

Variable names won't resolve in the DAP context—use direct memory addresses cast as pointers in the Expressions view

(e.g., (unsigned int *)0x70000000)

Board initialization matters: If the Memory Browser shows ?? ?? ?? ??, ensure proper board initialization

(e.g., flash SBL_NULL to QSPI first)
Ghost breakpoints — Verify:
- No hardware breakpoints are being set by the GEL file or startup scripts
- The JTAG clock speed is not too high for your board (try reducing to 1 MHz or lower)
- The debug connection type is set correctly (e.g., SWD vs JTAG, 4-pin vs 2-pin)
3-minute timeout/freeze — Check whether a watchdog timer (RTI WDT) is enabled and not being serviced during debug. Also verify power supply stability under sustained operation.
XDS110 firmware — Ensure the TMDSEMU110-U firmware is updated to the latest version bundled with CCS 20.5.0

Have you tested this with an AM261x Launchpad?

Best Regards,

Zackary Fleenor

0 Ted Huh 28 days ago in reply to Fleenor

TI__Expert 3555 points

Hello Zackary,

about the Real-tim debug thing, could you lead me to a original document? CS_DAP_0 connection seems not work.

also, using memory browser is not proper since it is not watch.

about CacheP_wbInv(), where should I call it?

in conclusion, watch cannot show the real values because AM2612 has a cache. is this right understanding? I need to understand this.

Regards,

Ted

0 Fleenor 27 days ago in reply to Ted Huh

TI__Mastermind 37573 points

Hey Ted,

Yes, your understanding is essentially correct. The AM2612 Cortex-R5F has a 16KB D-cache per core 1. When the CPU writes to a variable, the updated value may reside only in the data cache and not yet be written back to physical memory. The JTAG debugger (XDS110) reads from physical memory, not from the CPU's cache — so while the core is running, the debugger sees stale values (often 0). When you pause, the debugger can access the CPU registers and cache directly, which is why correct values appear only on halt.

Where to Call CacheP_wbInv()

Per the SDK documentation, call it after writing the variable you want to observe 2:

#include <kernel/dpl/CacheP.h>

// After updating your global variable:
myGlobalVar = newValue;
CacheP_wbInv(&myGlobalVar, sizeof(myGlobalVar), CacheP_TYPE_ALL);

The address must be cache-line aligned (32 bytes on R5F) and size should be a multiple of 32 bytes for best practice 2. This flushes the cache contents to memory so the DAP/debugger can see updated values.

Real-Time Debug — Official Document

The official AM261x SDK documents a UART-based Real-Time Debug approach (not CS_DAP). It uses a Serial Command Monitor that allows CCS to read/write global variables while the program runs continuously 3. This requires adding SerialCmd_init() at initialization and SerialCmd_read() in your background loop, then connecting via UART in CCS to observe variables in the Expressions window with continuous refresh enabled.

3-Minute Freeze / PC at 0x0000866E

This address falls within the R5F ATCM region (base 0x00000000) 4. A documented and common cause of random halts after seconds-to-minutes on AM2612 boards is an unconfigured PMIC watchdog timer triggering system resets 5. Ensure the PMIC watchdog is disabled or serviced, and verify boot mode switch positions are correct.

CS_DAP Not Working

I was unable to retrieve official TI documentation specifically covering CS_DAP real-time debug procedures for AM261x. The documented real-time debug method for this device family is the UART-based Serial Command Monitor approach referenced above 3.

Best Regards,

Zackary Fleenor

0 Ted Huh 4 days ago in reply to Fleenor

TI__Expert 3555 points

Hello Zackary,

I'm trying to implement the UART-based Real time debug. but the all the settings in user guide is for the eclipse version ccs. in 21.0 it does not works as indicated. How can we make this works in CCS Theia?

AM261x MCU+ SDK: Enabling Real Time Debug

About the reset or Freeze, if JTAG is not connected, it never occurs.

Regards,

Ted

0 Ted Huh 4 days ago in reply to Ted Huh

TI__Expert 3555 points

There's no alternate connection menu so I tried this, and now core cannot be selected.

Regards,

Ted

0 Ted Huh 4 days ago in reply to Ted Huh

TI__Expert 3555 points

I built .ccxml using CCSv12 and copied it to CCS21.0 project but when I open that .ccxml file it does not display the same structure.

Regards,

Ted

0 Fleenor 3 days ago in reply to Ted Huh

TI__Mastermind 37573 points

Hi Ted,

Thanks for the detailed follow-up. I can see you're hitting a specific pain point: CCS Theia doesn't yet fully support the UART-based Real-Time Debug workflow that's documented for the Eclipse-based CCS versions.

Current State of CCS Theia Support for AM261x Debugging

[Official TI guidance explicitly recommends CCS v12.8.x over CCS Theia until the AM261x MCU+ SDK v11.0 release (expected H2 2025)][1]. The documentation you're referencing—the Real Time Debug Support Guide—was written for Eclipse-based CCS and includes UI steps (like "Alternate Connection" menus) that don't exist in Theia's non-Eclipse interface.

The three problems you're experiencing are actually interconnected:

Watch variables showing 0 while running — This is the R5F D-cache issue we discussed. Your understanding is correct: [the AM2612 Cortex-R5F has a 16KB D-cache per core, and the JTAG debugger reads from physical memory, not the cache][2]. When paused, the debugger accesses the cache directly, which is why you see correct values only on halt.
3-minute freeze with JTAG connected — You've already identified the root cause: "if JTAG is not connected, it never occurs." This strongly suggests a watchdog timer or power delivery issue triggered by debug activity, not by your code.
CCS Theia .ccxml compatibility — The .ccxml file format differs between CCS v12 and Theia, so copying configurations between versions won't work.

For immediate stability, I'd suggest:

Switch to CCS v12.8.x for AM261x debugging until Theia support matures. The Eclipse-based version has complete, tested workflows for UART Real-Time Debug and XDS110 integration.
If you must use Theia, document your workaround (disconnect JTAG when not actively debugging) and file a new E2E thread with your Theia-specific .ccxml issues—this will help TI prioritize the Theia implementation fixes.

For the cache/watch variable issue, if you stay with your current setup:

Wrap critical global variables with [CacheP_wbInv(&myVar, sizeof(myVar), CacheP_TYPE_ALL)][3] after writes (ensure 32-byte alignment).
Or implement lightweight polling via UART instead of relying on live watch inspection during execution.

Best Regards,

Zackary Fleenor

0 Ted Huh 3 days ago in reply to Fleenor

TI__Expert 3555 points

Hello Zackary,

MCU+SDK 26 is already guide the proper CCS version is 20.5 which is Theia base.

In customer side, almost 20 enginners are already using CCS Theia. we cannot tell them to make them use 12.8 again.

Please fix the user's guide or tell the CCS team add alternate connection.

Regards,

Ted

0 Fleenor 2 days ago in reply to Ted Huh

TI__Mastermind 37573 points

Hey Ted,

Thanks for the feedback! I will assign this thread to the SDTO team for them to evaluate.

Best Regards,

Zackary Fleenor

0 Ki 2 days ago in reply to Ted Huh

TI__Guru**** 485731 points

Hi Ted,

We had a few breakpoint fixes and other debugger stability improvements in CCS 21. Are they willing to try the latest CCS 21.0.1?

Thanks

0 Ted Huh 7 hours ago in reply to Ki

TI__Expert 3555 points

Hello Ki,

Today Customer and I will test the new version. Thanks.

Ted

0 Ted Huh 6 hours ago in reply to Ted Huh

TI__Expert 3555 points

Hello Ki,

False Breakpoint halt still happens. it makes pause on

static inline uint16_t HW_RD_REG16_RAW(uint32_t addr)

{

uint16_t regVal = *(volatile uint16_t *) ((uintptr_t) addr);

return (regVal);

}

Operation.

or sometimes

void TEXT_HWI WEAK HwiP_user_prefetch_abort_handler_c(IFSR ifsr, AIFSR aifsr, volatile uint32_t IFAR,

volatile uint32_t LR,volatile uint32_t SPSR)

{

volatile uint32_t loop = 1U;

while(loop != 0U){ ; }

}

JTAG Disconnection also happens

Before the first stop, it works well so it seems like it is imporved.

no reset I run the code for a long time, if I didn't halt the board at all.

at 20.5, even if I didn't pause at all, it still made halt.

Regards,

Ted

Arm-based microcontrollers

Arm-based microcontrollers forum

AM2612: Unstable Debugging Operation

Real-Time Debug via CS_DAP

Important Caveats

Where to Call CacheP_wbInv()

Real-Time Debug — Official Document

3-Minute Freeze / PC at 0x0000866E

CS_DAP Not Working

Current State of CCS Theia Support for AM261x Debugging