C2000™︎ 微控制器论坛 - 最近的话题

TMS320F280049C: 请问有给电池充电的buck电路的例程吗

John Pan — Wed, 23 Sep 2026 03:51:30 GMT

Part Number: TMS320F280049C

请问有给电池充电的buck电路的例程吗

TMS320F28388S: TMS320F28388S Rev A — Guaranteed CPU-cycle bounds for Fatal NMI WCET analysis

wang george — Wed, 23 Sep 2026 02:59:04 GMT

Part Number: TMS320F28388S

Hello TI Support,

We are performing a formal CPU-cycle worst-case execution-time analysis for a Fatal NMI handler on:

Device: TMS320F28388S
Silicon revision: Rev A
Core: CPU1 C28x
NMI watchdog period: NMIWDPRD = 0xFFFF

The analysis requires guaranteed maximum timing bounds suitable for formal WCET analysis.

We are not looking for typical values, measured latency, or GPIO pad propagation timing.

For each item below, please identify the applicable TI document, section, table, erratum, or other authoritative guaranteed source, together with any required operating conditions such as SYSCLK, peripheral clock, power state, arbitration state, or debug/emulation restrictions.

1. CPU1 NMI register read stall / ready-extension bound

The Fatal NMI handler performs the following CPU1 C28x reads:

MOV *-SP[7], *(0:0x7061)   ; CPU1 NMIFLG
MOV *-SP[8], *(0:0x7066)   ; CPU1 NMISHDFLG

For these reads, what is the guaranteed maximum additional CPU stall or ready-extension latency, beyond the documented C28x instruction base timing, under all documented valid operating conditions for TMS320F28388S Rev A?

If the latency depends on a peripheral bus, bridge, arbitration condition, or ready-extension mechanism, please specify:

the relevant condition;
the guaranteed worst-case additional latency;
the unit of that bound;
whether any additional pipeline stall must be included separately.

If no published guaranteed maximum exists, please state that explicitly.

2. GPIO CLEAR write CPU-visible completion / stall bound

The Fatal NMI handler performs the following CPU1 C28x 32-bit writes:

VMOV32 *(0:0x7F04), ACC
VMOV32 *(0:0x7F24), ACC
VMOV32 *(0:0x7F2C), ACC

These accesses target GPIO CLEAR registers.

For each write, what is the guaranteed maximum CPU-visible instruction completion / stall latency, beyond the documented C28x instruction base timing, under all documented valid operating conditions for TMS320F28388S Rev A?

Please also clarify whether these GPIO writes are posted or non-posted.

If they are posted, please distinguish the following events:

the point at which the issuing C28x instruction is considered complete;
the point at which the write is accepted by the GPIO peripheral;
any later GPIO output/pad effect.

For our current WCET endpoint, item 3 is outside the CPU-cycle interval of interest. We need the guaranteed CPU-visible timing associated with items 1 and, where relevant to instruction completion, item 2.

Please provide a guaranteed maximum suitable for formal WCET analysis, or state explicitly if no such guaranteed bound is published.

3. NMI watchdog counter headroom at Fatal-handler entry

According to the F2838x documentation, assertion of an enabled NMI FAIL flag starts the NMI watchdog counter NMIWDCNT, which is clocked from SYSCLKOUT.

Our formal WCET interval begins at the first executed instruction of the Fatal NMI handler:

CPU1 address 0x1A0AD
M2Safety_fatalNmiHandler
instruction: ASP

The interval ends before the terminal self-loop, after completion of the final Fatal-state store.

NMI acceptance latency and hardware automatic-context-save execution occur before our formal WCET start point, but they consume watchdog headroom before execution reaches 0x1A0AD.

For TMS320F28388S Rev A with:

NMIWDPRD = 0xFFFF

what is the guaranteed maximum elapsed SYSCLKOUT-cycle count from the enabled NMI FAIL-flag assertion that starts NMIWDCNT until CPU1 begins execution at address 0x1A0AD?

Alternatively, if TI specifies this behavior directly in watchdog-counter terms:

What is the guaranteed maximum possible value of NMIWDCNT when CPU1 begins executing address 0x1A0AD?

Please provide the result as a guaranteed upper bound suitable for formal WCET analysis.

Please also clarify the relationship between:

one NMIWDCNT increment;
one SYSCLKOUT cycle;
C28x CPU execution cycles

for this device/configuration.

If conversion from watchdog counter ticks to C28x execution cycles requires any additional assumption, please identify that assumption explicitly.

In addition, while NMIWDCNT is already running, can assertion of another enabled NMI FAIL flag:

reset the counter;
restart the counter;
reload the counter;
delay its progression;
alter its count value;
or otherwise change the watchdog timeout timing?

If so, please describe the guaranteed behavior.

Please identify all conditions qualifying the guarantee, including as applicable:

device revision;
SYSCLK / SYSCLKOUT configuration;
interrupt recognition conditions;
NMI source;
power/clock state;
debug/emulation state.

Typical latency, measured latency, or nominal interrupt-response values are not sufficient for this analysis.

Purpose of the request

The formal property we need to establish is:

For every admitted Fatal-NMI execution beginning at 0x1A0AD,
the handler reaches its defined WCET endpoint before any
NMI-watchdog reset, and within <= 4096 C28x CPU cycles.

The entry-headroom precondition is defined independently and cannot be inferred retrospectively from successful execution.

Therefore, we require guaranteed upper bounds rather than empirical or typical timing values.

Backgroud:

We have already closed CPU1 DMA, CLA, GS13/GS14/LS5 contention and the core instruction/pipeline/branch/call timing model. The remaining blockers are limited to the three hardware timing authorities requested above.

Thank you.

TMS320F2800157: Debug 时，eeprom读取错误，上电直接运行，eeprom读取正常

yundong zou — Sat, 19 Sep 2026 08:37:14 GMT

Part Number: TMS320F2800157

ccs12 Debug 时，eeprom读取错误，直接上电直接运行，eeprom读取正常

TMS320F28035: TMS320F28035PNT 芯片ADC非线性问题

Dora CAI — Fri, 18 Sep 2026 07:02:19 GMT

Part Number: TMS320F28035

你好， TMS320F28035PNT 使用片上ADC测试，发现ADC存在线性误差，不同芯片之间一致性差异较大。相同问题在TMS320F28377SPZPT 上面也有出现。想看看怎么调整可以解决问题，谢谢！TMS320F28035PNT 芯片 ADC非线性问题.pdf

TMS320F2800137: Phase Current Sawtooth Wave

zhou qicheng — Wed, 16 Sep 2026 10:22:53 GMT

Part Number: TMS320F2800137

C:\Users\chao.zhou\TI_FUZAI\universal_motorcontrol_lab_f280013x I'm using the official example, and the current bandwidth seems to be 200 by default. The board is a new design by the company. Right now, I found that the phase current has serious ripple, causing the sampled amplitude to be asymmetrical. How can I tell if it's caused by software or hardware? I tried using voltage open-loop as well, and it's still the same.

TMS320F280039C: 无法使用ccs内置的syscfg生成mcu control center功能

ronghe feng — Tue, 15 Sep 2026 03:16:16 GMT

Part Number: TMS320F280039C
Other Parts Discussed in Thread: C2000WARE, SYSCONFIG

在我已有的ccs+sysccfg工程中添加mcu control center中的log功能编译时出现如下错误：
Generating Code (Electrosurgical_knife.syscfg)...
undefined
TypeError: sysctlModExports.bitfieldInstanceNames[exportInfo.bitfieldInstance] is not a function
at templateFunc (D:\software\ti\ccs2100\C2000Ware_26_01_00_00\utilities\transfer\.meta\gui\index.gui.xdt:137:92)
at func (D:\software\ti\ccs2100\ccs\utils\sysconfig_1.28.0\dist\src\pinmux\services\codeGeneration\templateRunner.ts:29:39)
at t.allowPathVisibility (D:\software\ti\ccs2100\ccs\utils\sysconfig_1.28.0\dist\src\pinmux\services\pathsVisibility.ts:11:10)
at t.runTemplate (D:\software\ti\ccs2100\ccs\utils\sysconfig_1.28.0\dist\src\pinmux\services\codeGeneration\templateRunner.ts:29:32)
at t.CodeGenerator.generate (D:\software\ti\ccs2100\ccs\utils\sysconfig_1.28.0\dist\src\pinmux\services\codeGeneration\codeGenerator.ts:142:21)
at iteratee (D:\software\ti\ccs2100\ccs\utils\sysconfig_1.28.0\dist\src\pinmux\services\codeGeneration\codeGenerator.ts:147:26)
at tA (D:\software\ti\ccs2100\ccs\utils\sysconfig_1.28.0\dist\node_modules\lodash\lodash.js:653:23)
at Function.map (D:\software\ti\ccs2100\ccs\utils\sysconfig_1.28.0\dist\node_modules\lodash\lodash.js:9621:57)
at t.CodeGenerator.generateAll (D:\software\ti\ccs2100\ccs\utils\sysconfig_1.28.0\dist\src\pinmux\services\codeGeneration\codeGenerator.ts:146:12)
at D:\software\ti\ccs2100\ccs\utils\sysconfig_1.28.0\dist\src\cli\cli_core.ts:133:38
[2]gmake: Target 'all' not remade because of errors.

但是在导入使用D:\software\ti\ccs2100\C2000Ware_26_01_00_00\driverlib\f28003x\examples\transfer\CCS\transfer_ex1_customlog_export_sci.projectspec这个demo工程是可以正常生成和编译的，不过也有一个问题，这个demo我修改了sci输出IO就编译出错，如上述工程一样的错误，即便clean工程也无法编译。

什么问题呢？
SDK:C2000Ware_26_01_00_00
SYSCFG:1.28.0

TMS320F280049C: ADC采样误差

John Pan — Mon, 14 Sep 2026 10:37:23 GMT

Part Number: TMS320F280049C

如下图，在C2管脚上输入1.7V电压，ADC读数最大值为2224，最小值为2103，相差100多

这个误差属于正常？还是过大了？是不是ADC有什么配置可以让误差缩小？

F29H859TU-Q1: F29 Can发送和Busoff中断处理问题

liu Gaosong — Mon, 14 Sep 2026 05:56:44 GMT

Part Number: F29H859TU-Q1

Hi,

问题一：F29H85x，Busoff中断里只判断Mcan_IR寄存器，Busoff状态发生变化都会进中断，一次Busoff会进2次中断且都会报告给上层（即使第二次中断，Busoff的状态以及恢复，即MCan_PSR_BO为0），这不符合规范；但是Busff轮询处理的时候，会先判断MCan_PSR_BO寄存器，确认MCan_PSR_BO为1后再报告上层；中断静态代码是缺少MCan_PSR_BO状态判断的。

问题二：F29H85x，Mcal Can配置Tx邮箱类型为BASIC_CAN，CanHwObjectCount不为1，压测发送报文周期时，发现存在漏帧，是因为报文请求发送时，读取空闲object的索引，跟最终发送时使用的索引不一致，导致发出的报文不对；把CanHwObjectCount改为1，问题解决了，但是为什么CanHwObjectCount大于1时，有漏帧的问题。

TMS320F280049: 关于280049的bootloader功能的问题

chen xinyu — Fri, 11 Sep 2026 08:07:55 GMT

Part Number: TMS320F280049
Other Parts Discussed in Thread: C2000WARE

我当前程序分为boot程序与APP程序；

要实现OTA升级的功能，从boot程序跳转到APP程序是正常的；但是在APP程序跳转到boot中程序出现了一些问题：

具体描述如下：
我在APP程序中执行

DINT;
IER = 0x0000;
IFR = 0x0000;
InitPieCtrl();
SysCtl_disablePeripheral(SYSCTL_PERIPH_CLK_CLA1);

SysCtl_resetDevice();
来进入软件复位，在不连接仿真器的情况下，程序执行完这段后就停止运行或者跑飞（我的判断依据是APP程序是LED灯慢闪，boot程序是LED灯快闪），连接仿真器后程序运行到这个语句后就出现：

我BOOT的map文件开头：ENTRY POINT SYMBOL: "code_start" address: 00080000
在开头就关闭了看门狗

我应该怎么做，让280049正确的进行复位，正确的执行boot程序

不要只给发一个例程，帮我分析一下原因和解决办法，辛苦

TMS320F280049: 关于280049的FSI通信方面的问题

chen xinyu — Fri, 11 Sep 2026 07:14:32 GMT

Part Number: TMS320F280049

你好，

我想问一个关于DSP 280049的FSI通信相关的问题：
我原本调试好了FSI通信，在后续的调试控制部分中，突然FSI输出不正常，目前排查是硬件的问题，因为我换了一个程序，FSI输出是好用的；

我配置了一帧发送16个word，配置时钟为25M的时钟，配置为数据帧；配置只使用D0作为数据信号；

正常的FSI输出图片：

现在的FSI输出图片：

其中黄色的是输出时钟信号，蓝色的是数据信号

关于配置我没有更改，在这个错误的FSI输出情况下，DSP也可以进入发送中断，在中断清除标志位前打断点，通过观察 TX_EVT_STS Register寄存器，该寄存器值为1；即没有故障并且发送完成，并且 TX_FRAME_CTRL寄存器为0xF3,即配置为数据帧，发送16个word;

我的调用函数：
uint16_t txBufData[16] = {0};
FSI_setTxBufferPtr(FSITXA_BASE, 0U);
FSI_writeTxBuffer(FSITXA_BASE, txBufData, nWords, 0U);
FSI_startTxTransmit(FSITXA_BASE);

帮我分析原因，不要发一个例程，例程我了解过了，请详细说一下可以的原因，不要敷衍

TMS320F2800137: SPI,i2c的boot问题

TI Thanks — Fri, 11 Sep 2026 00:27:51 GMT

Part Number: TMS320F2800137

2800137怎么选择spi或i2c的boot？这个流程我没有看懂。

F28E120SC: mcpwm如何通过软件快速关断

ruiwen pang — Thu, 10 Sep 2026 05:53:28 GMT

Part Number: F28E120SC

f28e12x中没有类似EPwm1Regs.TZFRC.bit.OST = 1;的寄存器，那么软件可以通过什么方式快速的关断mcpwm呢

TMS320F28335-Q1: 存储显式初始化且不为0的全局变量第一次数据加载错误

Tong Qian — Thu, 10 Sep 2026 00:52:18 GMT

Part Number: TMS320F28335-Q1

第一次上电，数据如下图所示

第1次复位后未运行，数据下方所示

F28M36P53C2: C2prog烧录串口软件出现Unable to set baudrate

user4724755 — Wed, 09 Sep 2026 06:38:30 GMT

Part Number: F28M36P53C2

我现在正在用C2prog烧录串口软件出现Unable to set baudrate ，我boot也按照说明书进行了高低电平处理，用的是F28M36双核芯片，用UARTO口调用双核默认的BOOTLOOD程序进行串口烧录，请问下为什么会一直出现该问题，同时能请教下，C2prog的晶振频率为只能选择20M我设计的是30M。是这个原因吗，还有是否不需要波特率的设计

F29P329SM-Q1: 关于ERRORSTS管脚配置为PWM模式的问题

Jiandong Sun — Mon, 07 Sep 2026 05:20:24 GMT

Part Number: F29P329SM-Q1
Other Parts Discussed in Thread: SYSCONFIG

您好：

我在使用sysconfig配置ESM System模块时将ERRORSTS管脚配置为PWM模式后，然后芯片在上电后需要大约84ms才能够正常发出方波信号，这个时间已经影响了外部SBC的运行，而ESMSYSTEM的初始化已经在程序运行的最开始，需要怎么配置才能让ERRORSTS管脚尽早的发出方波信号。

TMS320F28335: XINTF Registers的XINTCNF2寄存器介绍

JIE WANG — Sat, 05 Sep 2026 07:50:35 GMT

Part Number: TMS320F28335

示例代码里有XINTCNF2寄存器但是SPRUI07手册里面没有介绍

TMS320F28374S: TMS320F28374S: periodic STA/STL RAM diagnostics — CERRTHRES / FMEDA Diagnostic Used in Application, and STA_MARCH_COPY false-fail risk

jason Su — Wed, 02 Sep 2026 03:03:18 GMT

Other Parts Discussed in Thread: TMS320F28374S, C2000-SAFETI-DIAGNOSTICS-LIB

Device: TMS320F28374S
Software: C2000 SafeTI Diagnostic Library / Self-Test Application (STA) v1.00.02.00
Use case: industrial, IEC 61508
Periodic calls (runtime / PEST):
STA_RAM_DETECT -> STL_RAM_detectError()
STA_MARCH_COPY -> STL_March_testRAMCopy() + STL_March_checkErrorStatus()

We recently received several field reports of periodic RAM diagnostic FAIL.
Below is how we call STA/STL at runtime; we have a few questions on usage,
pass/fail severity, FMEDA, and possible March false FAIL.

Periodic entry (application)

/* first */
sta_tests_testdevice_handle(STA_RAM_DETECT);
/* immediately after */
sta_tests_testdevice_handle(STA_MARCH_COPY);

A. STA_RAM_DETECT (Dummy Read / ECC-Parity observation)

Each STA_RAM_DETECT call dummy-reads one SRAM block (32-bit reads), then
rotates through the on-chip SRAM map.

Per SPRS881K Table 7-6:
ECC blocks: M0, D0, D1 -> SPRUI78C SRAM1 (6.3.9)
Parity blocks: LSx, GSx, MSGRAM -> SPRUI78C SRAM2 (6.3.10)
The Dummy Read itself is the method in SPRUI78C 6.3.3 (SRAM7).

Sectors in rotation (STA init):
M0, M1, D0, D1, LS0-LS5, GS0-GS11, CLA-to-CPU MSGRAM, CPU-to-CLA MSGRAM
Skipped after increment (same as March):
- M1 (stack)
- GS3 (STA variables / March copy buffer)
- CLA-to-CPU MSGRAM (CPU has no write access)

From sta_user.c (STA_User_initRAMErrDetectTest) + sta_tests.c:

STA_User_ramErrDetectObj.corrErrorThreshold = 1U;
STA_User_ramErrDetectObj.corrErrorIntVector = STA_Util_corrErrorISR_RAM;
STA_User_ramErrDetectObj.uncNMIVector       = STA_Util_uncorrErrorNMIISR_RAM;
STA_User_ramErrDetectObj.startAddress =
    STA_RAMTest_StartAddr[STA_User_ramErrDetect_Count];
STA_User_ramErrDetectObj.endAddress   =
    STA_RAMTest_EndAddr[STA_User_ramErrDetect_Count];
/* then advance STA_User_ramErrDetect_Count; skip indices for M1 / GS3 /
   CLA-to-CPU MSGRAM */

MemCfg_setTestMode(memSection, MEMCFG_TEST_FUNCTIONAL);

testStatus = STL_RAM_detectError(STA_User_ramErrDetectHandle);
if (STL_RAM_DETECT_PASS == testStatus)
{
    /* PASS */
}
else
{
    /* FAIL -> enter safe state */
}

From stl_ram.c STL_RAM_detectError() (Diag Lib v1.00.02.00), as we read it:

/* clear status / interrupt flags (also clears single-bit error count) */
HWREG(...CERRCLR)  = 0xFFFFFFFFU;
HWREG(...CEINTCLR) = ...;
HWREG(...UCERRCLR) = 0xFFFFFFFFU;

MemCfg_setCorrErrorThreshold(ramErrDetectHandle->corrErrorThreshold);

/* dummy-read 32 bits at a time from startAddress to endAddress */
for (address = start; address <= end; address += 2U)
    dummyRead = HWREG(address);

ramErrDetectHandle->corrErrorCount = MemCfg_getCorrErrorCount();
/* corrErrorCount is stored but not used for pass/fail */

if (((MemCfg_getUncorrErrorStatus() & MEMCFG_UCERR_CPUREAD) != 0U) ||
    ((MemCfg_getCorrErrorStatus()   & MEMCFG_CERR_CPUREAD)  != 0U))
    testStatus = STL_RAM_DETECT_FAIL;
else
    testStatus = STL_RAM_DETECT_PASS;

So (please confirm): a hardware-corrected 1-bit ECC data error still sets
CERRFLG / CPUREAD and returns FAIL; we do not use CERRCNT as the criterion.

We understand from the documents (please confirm):
- SPRUHX5H 3.11.1.7: a 1-bit error in one 16-bit ECC data word is corrected
and written back; address ECC, ECC double-bit, and all parity errors
are uncorrectable (UCERR / NMI). Parity memories have no correctable path.
- After correction, CERRFLG is still set and CERRCNT increments.
- SPRUHX5H 3.11.1.7.2: CERRTHRES controls when the correctable-error
interrupt is generated (if enabled), not whether a flag is set.
- SPRUHX5H 3.6.6: "A typical threshold setting to avoid triggering on
transient errors which are corrected, but identify persistent faults is 10."

B. STA_MARCH_COPY (non-destructive March13N) — our implementation

This follows Diag Lib UG v1.00.02.00 Section 5.15 and SPRACB9:
STL_March_testRAMCopy() copies the window, writes/reads the March patterns,
then restores the original contents.
STL_March_checkErrorStatus() then reads CERRFLG / UCERRFLG.

1) Periodic call order
STA_RAM_DETECT (first)
STA_MARCH_COPY (immediately after)

2) Sectors / window
Each call tests one window only:
length = 63 -> 64 x 32-bit = 128 x 16-bit
Address advances inside the current sector (AddrCnt); when the sector
end is reached, move to the next sector.

Tested:
M0, D0, D1,
LS0-LS5,
GS0-GS2, GS4-GS11,
CPU-to-CLA MSGRAM

Skipped:
M1 (stack)
GS3 (STA variables / copy buffer STA_User_ramTestGS3Data)
CLA-to-CPU MSGRAM (CPU cannot write)

3) Patterns on the same window (fixed order inside one call)
1. STL_MARCH_PATTERN_ONE -> STL_March_checkErrorStatus()
2. STL_MARCH_PATTERN_TWO -> check (CERR/UCERR cleared between patterns)
3. STL_MARCH_PATTERN_THREE -> check
4. STL_MARCH_PATTERN_FOUR -> check
Any non-PASS check is ORed into FAIL.

4) Source — init (sta_user.c STA_User_initMarch), simplified:

uint32_t addrInterval =
sizeof(STA_User_ramTestGS3Data) / sizeof(uint16_t); /* 128 x 16-bit */

STA_User_marchErrorObj.address =
STA_RAMTest_Addr[STA_User_RamMarchCopy_Count]
+ STA_User_RamMarchCopy_AddrCnt * addrInterval;
STA_User_marchErrorObj.ramSection =
STA_RAMTest_Sect[STA_User_RamMarchCopy_Count];
STA_User_marchErrorObj.xorMask = 0x00000000U;
STA_User_marchErrorObj.testMode = MEMCFG_TEST_FUNCTIONAL;
/* then advance AddrCnt / sector count; skip M1, GS3, CLA-to-CPU MSGRAM */

5) Source — body (sta_tests.c case STA_MARCH_COPY), simplified:

MemCfg_clearUncorrErrorStatus(MEMCFG_CERR_CPUREAD |
                              MEMCFG_CERR_DMAREAD |
                              MEMCFG_CERR_CLA1READ);
MemCfg_clearCorrErrorStatus(MEMCFG_CERR_CPUREAD |
                            MEMCFG_CERR_DMAREAD |
                            MEMCFG_CERR_CLA1READ);

STA_User_initMarch();
Setup_March_Interrupt();

/* pattern ONE (TWO / THREE / FOUR are the same; clear CERR/UCERR between) */
STL_March_testRAMCopy(STL_MARCH_PATTERN_ONE,
                      STA_User_marchErrorObj.address,
                      63U, (uint32_t)STA_User_ramTestGS3Data);
returnVal |= STL_March_checkErrorStatus();
/* then PATTERN_TWO / THREE / FOUR the same way */

STA_Tests_testDevice() runs from Flash (not from the RAM under test).
The copy buffer is in GS3, which is excluded from the DUT.
We do not halt CLA or DMA around this March window during PEST.

Questions

Q1. Intended use
For periodic (PEST) RAM diagnostics on F28374S, is the combination below
the intended STA/STL usage? (SPRUI78C 6.3.3 / 6.3.9 / 6.3.10 / 6.3.12;
Diag Lib UG 5.15)
STA_RAM_DETECT -> SRAM1 / SRAM2 observation, and/or SRAM7 data scrubbing
STA_MARCH_COPY -> SRAM3 software test of SRAM (non-destructive March13N)
Is anything missing or incorrectly applied in the code above?

Q2. Correctable vs uncorrectable in STL_RAM_detectError()
The API returns FAIL for both correctable and uncorrectable flags.
For ECC memories (M0 / D0 / D1), may the application tolerate a bounded
number of correctable errors (hardware already corrected and wrote back)
and only enter the safe state on uncorrectable errors, or after the
correctable count reaches a threshold?
We understand this does not apply to parity memories (LSx / GSx / MSGRAM),
where every error is uncorrectable.

Q3. Role of corrErrorThreshold = 1
Does corrErrorThreshold / CERRTHRES only control the correctable-error
interrupt (SPRUHX5H 3.11.1.7.2), and not the return value of
STL_RAM_detectError()?
In other words: changing 1 -> 10 would change interrupt timing only,
and the API would still FAIL on the first CERRFLG?

Q4. FMEDA / threshold = 10
If we react only when CERRCNT >= 10 on ECC memories:
a) Is that the intended use of the typical value in SPRUHX5H 3.6.6?
b) Does TI recommend 10 for industrial / IEC 61508, or another value?
c) Versus treating every CERRFLG as FAIL, do the FMEDA
"Diagnostic Used in Application" settings need to change?
Our current FMEDA "Diagnostic Used in Application" settings for RAM System:
SRAM1 SRAM ECC = 1
SRAM2 SRAM Parity = 1
SRAM3 Software Test of SRAM = 0
SRAM7 Data scrubbing = 0
If we change the application reaction for correctable ECC to a
count-based threshold, do these Diagnostic Used in Application
values need to change (especially SRAM1 / SRAM7)?

Q5. STA_MARCH_COPY false-fail risk
Given the sector list, pattern order, and source above:
- STA wrapper in Flash
- M1 / GS3 / CLA-to-CPU MSGRAM skipped
- copy buffer in GS3
- CLA / DMA not halted during the March window
Can STL_March_testRAMCopy() still produce a false FAIL by writing /
restoring diagnostic state, or if CLA / DMA / an ISR accesses the same
window during the test?
Which additional regions or concurrent-access constraints does TI
require for PEST use of STL_March_testRAMCopy()?

We appreciate your guidance on the intended use, FMEDA Diagnostic Used in
Application settings, and whether our March implementation can false-fail.
We would rather keep the diagnostics as specified than invent a looser
pass/fail rule.

TMS320F28P650DK: C2000Ware_26_01_00_00的ai相关例程的mod.a文件错误，官方例程无法正确运行

Pop Tang — Tue, 01 Sep 2026 08:24:46 GMT

Part Number: TMS320F28P650DK
Other Parts Discussed in Thread: C2000WARE

使用c2000ware自带的例程， C:\ti\c2000\C2000Ware_26_01_00_00\libraries\ai\examples\arc_fault

。导入ccs12.8/ccs21.0，尝试更换编译器v22.6.3.LTS/v25.11.1.LTS，均会报错。

报错如下：

最后更换mod.a文件，更换成C2000Ware_6_00_01_00自带的mod.a文件后，报错解决。

提问AI，将mod.a文件上传AI分析，发现判断是官方mod.a文件 lib1.obj 地址位偏移了1byte。

F29H850TU: f29h850tu外部晶振不启震

xiaoqi qi — Mon, 31 Aug 2026 18:51:53 GMT

Part Number: F29H850TU
Other Parts Discussed in Thread: LAUNCHXL-F29H85X

在使用launchxl-f29h85x时，simulink，mbd开发，使用内部时钟芯片可以正常运行，但是切换至外部20mhz无源晶体振荡器时，晶振没有工作，

TMS320F2800157-Q1: GPIO24和GPIO32悬空式MCU各端口的输出电平是什么状态？

Aiden zhang — Mon, 31 Aug 2026 08:27:56 GMT

Part Number: TMS320F2800157-Q1

按Datasheet的描述，MCU上电后，各个GPIO都默认为输入，对外表现为高阻状态。

我想问一下，如果的一个没有烧录过程序的全新MCU，如果GPIO24和GPIO32处于悬空状态，那么MCU上电后各GPIO端口特性是什么样的，还是默认为输入，对外变现为高阻状态吗？

我实际测试到很多GPIO输出一直是高电平。

TMS320F280049C: SFRA连接不上

John Pan — Fri, 28 Aug 2026 06:06:13 GMT

Part Number: TMS320F280049C
Other Parts Discussed in Thread: SFRA, LAUNCHXL-F280049C, C2000WARE

在SFRA GUI界面上进行连接时，

如果是TI的开发板，可以连接成功

如果是我们自己的板子，连接不上

请问是什么原因，是不是TI开发板上有什么特殊的电路，把SFRA用的串口转接到USB接口上？而我们的板子上缺少这个特殊的电路？

TMS320F280049C: SFRA扫描数据，是否可以修改为用其他的串口

John Pan — Fri, 28 Aug 2026 04:08:12 GMT

Part Number: TMS320F280049C
Other Parts Discussed in Thread: SFRA

如下图，SFRA用的串口是GPIO28和GPIO29，我可以修改为用别的串口吗，比如：GPIO25和GPIO8

LAUNCHXL-F280039C: LAUNCHXL-F280039C: Onboard XDS110 Debugger Not Detected

思宇賴 — Wed, 26 Aug 2026 00:54:12 GMT

Part Number: LAUNCHXL-F280039C

We purchased ten LAUNCHXL-F280039C boards, and six of them have an issue with the onboard XDS110 debugger.

When any of these six boards are connected to the PC via USB, the XDS110 is not detected by Windows Device Manager at all. In contrast, the other four boards are detected normally using the same PC, USB cable, and USB port. For the working boards, the XDS110 Class Application/User UART and XDS110 Class Auxiliary Data Port appear immediately in Device Manager.

All six affected boards were being used for the first time when this issue occurred. We tested them under the same conditions as the four working boards, but none of them were detected by the PC.

Has this issue been reported or encountered with the LAUNCHXL-F280039C before? Could you please advise whether there are any troubleshooting procedures or possible solutions we can try to recover the onboard XDS110 debugger?

If the issue cannot be resolved through troubleshooting, could you also help confirm whether this is likely a hardware failure of the onboard XDS110?

I have attached photos showing the Device Manager results for comparison between a working board and an affected board.

Thank you for your assistance.

TMS320F280049C: 请问有Boost的例程吗？

John Pan — Mon, 24 Aug 2026 08:01:02 GMT

Part Number: TMS320F280049C

请问有Boost的例程吗？

C2000-CGT: 不能进入debug

Hongtang Miao — Mon, 24 Aug 2026 03:09:10 GMT

Part Number: C2000-CGT

C28xx_CPU1: File Loader: Verification failed: Values at address 0x000000@Program do not match Please verify target memory and memory map.
C28xx_CPU1: GEL: File: D:\work_space\13.dsp\test_ethercat\program_i2c_ESC_eeprom_F28P65x\CPU1_RAM\program_i2c_ESC_eeprom_F28P65x.out: a data verification error occurred, file load failed.

出现了软件锁死