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

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

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

Part Number: TMS320F280049

我当前程序分为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程序

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

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

chen xinyu — Sun, 20 Sep 2026 02:21:43 GMT

需要我提供一下APP程序与boot程序的cmd文件吗，
我之前按照ai的引导，在 SysCtl_resetDevice()；执行之前：
执行了程序
EALLOW;
*(volatile uint16_t *)0x0D00 = 0x5AFF;
*(volatile uint16_t *)0x0D01 = 0xFFFF;
EDIS;
这个会影响不连接仿真器的情况吗

当前0xD00地址的数据如上图;

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

chen xinyu — Sun, 20 Sep 2026 01:27:32 GMT

您好，

谢谢你的回复，当前在不连接仿真器的情况下还是有问题，map文件中：“ENTRY POINT SYMBOL: "code_start" address: 00080000”

检测了复位电路也是没问题的，DSP上电之后可以先加载BOOT程序，然后从boot跳转到app程序，在APP程序中执行复位语句后还是卡住，我确认 GPIO24 和 GPIO32 都为高电平，使用示波器量是没问题的；

我原本猜测可能是跳入boot程序后跳入非法中断了，然后将程序从SysCtl_resetDevice();改为 asm(" LB #0x080000 ");程序是可以跳到BOOT程序的，并且运行没问题；不过此处我需要使用复位形式；

当前现象是DSP在执行完SysCtl_resetDevice();后程序停止运行，如果此刻带电直接连接仿真器后程序立刻运行boot程序，然后在CCS中连接仿真器观察寄存器CpuSysRegs.RESC，结果如下：

我应该如何实现不连接仿真器，程序正常复位到boot程序中？

辛苦帮忙看一下

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时，有漏帧的问题。

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

liu Gaosong — Sun, 20 Sep 2026 01:10:56 GMT

问题1：是否是等Mcal下个版本才能迭代。

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

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

Part Number: TMS320F2800157

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

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

Prajakta Potadar — Fri, 18 Sep 2026 14:14:23 GMT

问题1：你的观察和修正都正确。我们应该检查这两项。canBusOffRecoveryStatus and MCAN_PSR_BO before triggering the notification in order to ensure only one bus off notification is triggered for every bus off event.
问题 2：我们正在努力重现该问题，分析完成后会通知您。

RE: TMS320F28035: TMS320F28035PNT 芯片ADC非线性问题

Alice — Fri, 18 Sep 2026 08:12:55 GMT

您好，已经收到了您的案例，调查需要些时间，感谢您的耐心等待。

TMS320F28035: TMS320F28035PNT 芯片ADC非线性问题

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

Part Number: TMS320F28035

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

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

Arpit Varahmihir — Thu, 17 Sep 2026 07:18:25 GMT

你好，

- 请参阅 TRM TMS320F28004x 实时微控制器技术参考手册（修订版 H）第 4.4.1 节，了解仿真启动流程。请务必按照这些步骤操作。

原因是F28004x在仿真模式下的启动模式（仿真启动）尚未配置，因此启动过程无法顺利完成。当芯片再次上电或接收到复位信号时，需要执行启动程序，选择程序入口地址或使用外设加载器（引导加载程序）才能运行应用程序。复位后，芯片从地址0x3FFFC0运行复位向量，跳转到启动ROM以开始执行InitBoot函数。芯片将判断当前仿真器是否连接，并进入不同的启动过程。图4.3和图4.2分别显示了芯片在离线模式和仿真调试模式下的启动过程。

（1）如果芯片未连接到仿真器，系统将进入离线模式启动过程。默认情况下，F28004x 通过 GPIO24 和 GPIO32 的启动模式选择引脚 (BMPS) 电平来选择不同的启动模式，如表 1 所示。与 F2803x 等老款芯片不同，F28004x 还支持用户自定义 BMPS 和启动模式，可通过重写 DCSM OTP 中的 Z1-OTP-BOOTPIN-CONFIG 和 Z1-OTP-BOOTDEF 值来实现自定义启动功能，最多支持 3 个 BMPS 引脚和 8 种启动模式。

具体流程：如果 Z1-OTP-BOOTPIN-CONFIG.Key=0x5A，则进入自定义启动模式。

芯片根据 Z1-OTP-BOOTPIN-CONFIG.BMPSx 中设置的 BMPS 引脚和电平状态来确定要执行的启动模式（相应的启动模式由 Z1-OTP-BOOTDEF.BOOTDEFx 设置）。否则，芯片将根据 GPIO24 和 GPIO32 的电平状态选择默认启动模式。

(2) 如果芯片未连接到仿真器，则会进入启动模式进行仿真调试，该模式通过读取 EMU-BOOTPIN-CONFIG 和 EMU_BOOTDEF 的值来执行特定的启动模式。值得注意的是，上述 OTP 中的自定义模式配置修改是一次性的，无法再次擦除。因此，系统提供了 EMU-BOOTPIN-CONFIG 和 EMU_BOOTDEF 用于模拟自定义启动过程，作为实际修改 DCSM OTP 之前的参考。

具体流程：如果 EMU-BOOTPIN-CONFIG.Key=0x5A，则选择自定义启动模式。芯片会根据 EMU-BOOTPIN-CONFIG.BMPSx 设置的 BMPS 引脚及其电平状态来确定启动模式。需要注意的是，如果 EMU-BOOTPIN-CONFIG.Key=0xA5，则表示芯片在连接仿真器的情况下可以进入离线启动模式，即根据 Z1-OTP-BOOTPIN-CONFIG 和 Z1-OTP-BOOTDEF 对应的值进行启动；此模式与 F2803x 在连接仿真器时将 EMU_BMODE 配置为 GetMode() 的原则一致。如果 EMU-BOOTPIN-CONFIG.Key 的值配置不正确，芯片将进入等待启动模式，陷入循环等待状态，无法完成启动过程。

表 1 默认启动模式

如果芯片成功完成启动模式，它将通过外设加载程序，或者直接跳转到与启动模式对应的程序入口地址，以开始运行应用程序，即 main() 函数。例如，如果从 Flash 启动，它将跳转到地址 0x80000（在这种情况下，您需要在 CMD 文件中配置“codestart”部分，以链接到相应的 Flash 空间地址）。

基于以上对F28004x芯片启动过程的介绍，我们回过头来分析连接仿真器进行调试时的复位问题。以C2000ware提供的LED程序为例：(C:\ti\c2000\C2000Ware_DigitalPower_SDK_1_02_00_00\c2000ware\device_support\f28004x\examples\led) 编写程序。根据表2中提供的Boot ROM寄存器地址，可以在内存浏览器窗口中查看EMU_BOOTPIN_CONFIG的Key值（高8位）。结果如图3所示：由于EMU_BOOTPIN_CONFIG.Key = 0xEE，芯片将进入等待启动模式。如果在复位后立即运行，反汇编窗口显示程序卡在 0x3FB02A，处于 ESTOP0 循环等待状态，该状态位于等待启动运行地址范围 (0x3FAD74 – 0x3FB0CD) 内，如图 4 所示。

表 2. 启动 ROM 寄存器地址

图 3 显示了 EMU_BOOTPIN_CONFIG 的值

图 4 程序运行后的停止位置

因此，如果要在复位后立即恢复运行，解决方法是在仿真状态下正确配置启动模式。以启动到闪存为例（参见 F28004x TRM 手册 4.3.3.1），有两种方法：

1) 在 EMU_BOOTPIN_CONFIG 地址处写入 0x5AFFFFFF，并在对应于 EMU_BOOTDEF_LOW 地址的低 8 位处写入 0x03 (BOOTDEF.BOOTDEF0=0x03)

2) 如果芯片在单个引脚时可以正常工作，例如 GPIO24 和 GPIO32 都为高电平（默认从闪存启动），则写入 0xA5FFFFFF 0xD00 EMU_BOOTPIN_CONFIG 地址。

请务必同时检查以下内容：

1)检查 XRSn 电路。看门狗复位会将 XRSn 拉低 512 个 OSCCLK 周期。根据数据手册，这需要：

-从 XRSn 到 VDDIO 的 2.2–10 kΩ 上拉电阻；

-如果使用电容器，则VSS的电容器容量应为100 nF或更小；

-仅当外部设备驱动 XRSn 时才允许开漏驱动。

2) 请注意，看门狗复位会清除此设备上的所有 RAM。

问候
阿尔皮特

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

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

Part Number: TMS320F280039C

在我已有的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

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

ronghe feng — Thu, 17 Sep 2026 02:19:01 GMT

你好，
使用的是CCS21安装时自带的编译器，版本是ti-cgt-c2000_25.11.1.LTS

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

liu Gaosong — Thu, 17 Sep 2026 01:30:26 GMT

您好，

1.您是否收到两次总线关闭中断，一次是总线关闭后，一次是恢复后？还是两次都是总线关闭后的中断？

答：中断函数Can_ProcessLine0ISR()进入2次，Busoff产生和恢复都会进入，Can_CheckBusOffPriv()也进了2次，这看一下代码也就知道了，手册也说了Mcan_IR的BO寄存器置位1是busoff状态发生改变都会置位，Can_ProcessLine0ISR()中断函数里面只判断了Mcan_IR寄存器，所以会进2次，Can_CheckBusOffPriv()也会进2次。

2.当您配置了 CanHwObjectCount > 1 的 BASIC CAN 硬件对象时，请您描述一下您的负载测试条件，以便我们能够重现该问题：

您是否缺少发送帧或接收帧？丢失了多少条消息？
您的 TxProcessing 和 RxProcessing 类型是什么？
信息发送和接收的周期是什么？
Tx FIFO 配置的深度是多少（即 CanHwObjectCount）？您是否还有其他专用的发送消息缓冲区？

答：总线负载率在50%-60%之间，可以复现。

1、can总线上Tx报文漏发一帧

2、TxProcessing和Rxprocessing配置的都是interrupt

3、Tx报文的周期，10ms周期2帧报文，25ms周期2帧报文，50ms周期1帧报文，100ms周期2帧报文，200ms周期3帧报文，漏帧报文的周期是200ms

4、CanHwObjectCount为10，还有一个TxObject是另一路CAN。

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.

RE: TMS320F2800137: Phase Current Sawtooth Wave

Alice — Wed, 16 Sep 2026 23:32:26 GMT

您好，
已经收到了您的案例，调查需要些时间，感谢您的耐心等待。

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

Joseph Casuga — Wed, 16 Sep 2026 14:15:42 GMT

你好，

以下转述MCAL专家提出的问题：

请您提供以下信息，以便我们进一步分析问题？

您是否收到两次总线关闭中断，一次是总线关闭后，一次是恢复后？还是两次都是总线关闭后的中断？
当您配置了 CanHwObjectCount > 1 的 BASIC CAN 硬件对象时，请您描述一下您的负载测试条件，以便我们能够重现该问题：
1. 您是否缺少发送帧或接收帧？丢失了多少条消息？
2. 您的 TxProcessing 和 RxProcessing 类型是什么？
3. 信息发送和接收的周期是什么？
4. Tx FIFO 配置的深度是多少（即 CanHwObjectCount）？您是否还有其他专用的发送消息缓冲区？

问候，

约瑟夫

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

Joseph Casuga — Wed, 16 Sep 2026 12:30:09 GMT

您好，我已经联系了专家，并将此问题分配给相关人员处理。

问候，

约瑟夫

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

chen xinyu — Wed, 16 Sep 2026 08:59:49 GMT

您好，请问可以帮忙解决一下这个问题嘛，麻烦了

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

Rich Chen — Wed, 16 Sep 2026 01:31:12 GMT

Alice,

This is TI field FAE.

Is there any update or finding on customer questions since it has been two weeks?

I see the status show waiting for customer.

Any further information or input you need from customer side? I can help to get inputs.

BR, Rich

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

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)

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:fb74206e-476e-472d-95e8-1b3141780e0f:type=c_cpp&text=%2F%2A%20first%20%2A%2F%0D%0Asta_tests_testdevice_handle%28STA_RAM_DETECT%29%3B%0D%0A%2F%2A%20immediately%20after%20%2A%2F%0D%0Asta_tests_testdevice_handle%28STA_MARCH_COPY%29%3B]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:713093f0-5d64-427f-af88-4774050c4638:type=c_cpp&text=STA_User_ramErrDetectObj.corrErrorThreshold%20%3D%201U%3B%0D%0ASTA_User_ramErrDetectObj.corrErrorIntVector%20%3D%20STA_Util_corrErrorISR_RAM%3B%0D%0ASTA_User_ramErrDetectObj.uncNMIVector%20%20%20%20%20%20%20%3D%20STA_Util_uncorrErrorNMIISR_RAM%3B%0D%0ASTA_User_ramErrDetectObj.startAddress%20%3D%0D%0A%20%20%20%20STA_RAMTest_StartAddr%5BSTA_User_ramErrDetect_Count%5D%3B%0D%0ASTA_User_ramErrDetectObj.endAddress%20%20%20%3D%0D%0A%20%20%20%20STA_RAMTest_EndAddr%5BSTA_User_ramErrDetect_Count%5D%3B%0D%0A%2F%2A%20then%20advance%20STA_User_ramErrDetect_Count%3B%20skip%20indices%20for%20M1%20%2F%20GS3%20%2F%0D%0A%20%20%20CLA-to-CPU%20MSGRAM%20%2A%2F%0D%0A%0D%0AMemCfg_setTestMode%28memSection%2C%20MEMCFG_TEST_FUNCTIONAL%29%3B%0D%0A%0D%0AtestStatus%20%3D%20STL_RAM_detectError%28STA_User_ramErrDetectHandle%29%3B%0D%0Aif%20%28STL_RAM_DETECT_PASS%20%3D%3D%20testStatus%29%0D%0A%7B%0D%0A%20%20%20%20%2F%2A%20PASS%20%2A%2F%0D%0A%7D%0D%0Aelse%0D%0A%7B%0D%0A%20%20%20%20%2F%2A%20FAIL%20-%3E%20enter%20safe%20state%20%2A%2F%0D%0A%7D]

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

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:70294488-2ebb-4813-b87e-ca1001b03586:type=c_cpp&text=%2F%2A%20clear%20status%20%2F%20interrupt%20flags%20%28also%20clears%20single-bit%20error%20count%29%20%2A%2F%0D%0AHWREG%28...CERRCLR%29%20%20%3D%200xFFFFFFFFU%3B%0D%0AHWREG%28...CEINTCLR%29%20%3D%20...%3B%0D%0AHWREG%28...UCERRCLR%29%20%3D%200xFFFFFFFFU%3B%0D%0A%0D%0AMemCfg_setCorrErrorThreshold%28ramErrDetectHandle-%3EcorrErrorThreshold%29%3B%0D%0A%0D%0A%2F%2A%20dummy-read%2032%20bits%20at%20a%20time%20from%20startAddress%20to%20endAddress%20%2A%2F%0D%0Afor%20%28address%20%3D%20start%3B%20address%20%3C%3D%20end%3B%20address%20%2B%3D%202U%29%0D%0A%20%20%20%20dummyRead%20%3D%20HWREG%28address%29%3B%0D%0A%0D%0AramErrDetectHandle-%3EcorrErrorCount%20%3D%20MemCfg_getCorrErrorCount%28%29%3B%0D%0A%2F%2A%20corrErrorCount%20is%20stored%20but%20not%20used%20for%20pass%2Ffail%20%2A%2F%0D%0A%0D%0Aif%20%28%28%28MemCfg_getUncorrErrorStatus%28%29%20%26%20MEMCFG_UCERR_CPUREAD%29%20%21%3D%200U%29%20%7C%7C%0D%0A%20%20%20%20%28%28MemCfg_getCorrErrorStatus%28%29%20%20%20%26%20MEMCFG_CERR_CPUREAD%29%20%20%21%3D%200U%29%29%0D%0A%20%20%20%20testStatus%20%3D%20STL_RAM_DETECT_FAIL%3B%0D%0Aelse%0D%0A%20%20%20%20testStatus%20%3D%20STL_RAM_DETECT_PASS%3B]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:02436f95-037a-4d61-a0eb-21cdc6ca7c79:type=c_cpp&text=MemCfg_clearUncorrErrorStatus%28MEMCFG_CERR_CPUREAD%20%7C%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20MEMCFG_CERR_DMAREAD%20%7C%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20MEMCFG_CERR_CLA1READ%29%3B%0D%0AMemCfg_clearCorrErrorStatus%28MEMCFG_CERR_CPUREAD%20%7C%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20MEMCFG_CERR_DMAREAD%20%7C%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20MEMCFG_CERR_CLA1READ%29%3B%0D%0A%0D%0ASTA_User_initMarch%28%29%3B%0D%0ASetup_March_Interrupt%28%29%3B%0D%0A%0D%0A%2F%2A%20pattern%20ONE%20%28TWO%20%2F%20THREE%20%2F%20FOUR%20are%20the%20same%3B%20clear%20CERR%2FUCERR%20between%29%20%2A%2F%0D%0ASTL_March_testRAMCopy%28STL_MARCH_PATTERN_ONE%2C%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20STA_User_marchErrorObj.address%2C%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2063U%2C%20%28uint32_t%29STA_User_ramTestGS3Data%29%3B%0D%0AreturnVal%20%7C%3D%20STL_March_checkErrorStatus%28%29%3B%0D%0A%2F%2A%20then%20PATTERN_TWO%20%2F%20THREE%20%2F%20FOUR%20the%20same%20way%20%2A%2F]

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.

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

liu Gaosong — Wed, 16 Sep 2026 01:28:02 GMT

你好，希望尽快确认以上2个问题，例如问题1，要是带上Autosar的话，肯定不会按照这个临时方案处理的。

RE: TMS320F28027F: 28027F 的TZ1 问题

Allison Nguyen — Tue, 15 Sep 2026 20:15:26 GMT

您好，有几个背景问题：

这段代码是新写的，您遇到这个问题了吗？还是您发现这段旧代码/现有代码出现了新问题（代码是否有任何更改）？
您能否分享一下您的配置？
您是否对比过 instaspin 和您的 PWM 配置，以检查这些差异可能会如何影响其性能？
跳闸问题（存在跳闸条件但 PWM 未跳闸）发生的频率是多少？

此致，

艾莉森

TMS320F28027F: 28027F 的TZ1 问题

Lance Zhang — Mon, 14 Sep 2026 02:20:49 GMT

Part Number: TMS320F28027F

我的配置几乎与instaSPIN 的配置一样但是在实际应用过程中发现 TZ的保护偶尔会失效如图通道2（青色）为 TZ1 信号（与DSP引脚直通的地方），通道4（深蓝色）为当前电流，通道1（黄色）与通道3（玫红色）为 PWM1 的上下桥出，测试位置为IGBT的GE端。TZ的低电平超过20us ，但是未触发我不知道是什么原因。这种现象比较偶然。

GPIO_setPullUp(obj->gpioHandle,GPIO_Number_12,GPIO_PullUp_Enable);
GPIO_setQualificationPeriod(obj->gpioHandle,GPIO_Number_12,5);
GPIO_setQualification(obj->gpioHandle,GPIO_Number_12,GPIO_Qual_ASync);
GPIO_setMode(obj->gpioHandle, GPIO_Number_12, GPIO_12_Mode_TZ1_NOT);

for (cnt = 0; cnt < 3; cnt++)
{
// PWM_enableTripZoneSrc(obj->pwmHandle[cnt], PWM_TripZoneSrc_CycleByCycle_TZ6_NOT);

PWM_enableTripZoneSrc(obj->pwmHandle[cnt], PWM_TripZoneSrc_OneShot_TZ1_NOT);

// What do we want the OST/CBC events to do?
// TZA events can force EPWMxA
// TZB events can force EPWMxB

PWM_setTripZoneState_TZA(obj->pwmHandle[cnt], PWM_TripZoneState_EPWM_Low);
PWM_setTripZoneState_TZB(obj->pwmHandle[cnt], PWM_TripZoneState_EPWM_Low);
}

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

Joseph Casuga — Tue, 15 Sep 2026 19:09:59 GMT

你好，

[quote userid="675191" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000-microcontrollers---internal/f/c2000-microcontrollers---internal-forum/1682154/f29h859tu-q1-f29-can-transmission-and-busoff-interruption-handling-issues"]问题 1：在 F29H85x 中，Busoff 中断仅检查 Mcan_IR 寄存器。Busoff 状态的任何变化都会触发中断，导致每个 Busoff 中断产生两个中断，这两个中断都会向上层报告（即使在第二个中断期间，Busoff 状态也会恢复，即 MCan_PSR_BO 为 0）。这不符合规范。然而，在总线关闭轮询期间，首先会检查 MCan_PSR_BO 寄存器，只有在确认 MCan_PSR_BO 为 1 后，才会将报告发送到上层。静态中断代码缺少 MCan_PSR_BO 状态检查。

中断路径中可能存在断点。MCAN 硬件会在总线关闭事件（PSR_BO 变为 1）和恢复事件（PSR_BO 变为 0）时都设置 IR 总线关闭标志，因此，如果 ISR 中没有 PSR_BO 检查，这两个事件都会被上报到上层。轮询路径通过在报告前检查 PSR_BO 是否等于 1 来正确处理这种情况——中断路径也应该这样做。我会将此问题转发给我们的 MCAL 专家，以便他们进行确认。同时，作为一种临时解决方案，您可以在应用程序级总线关闭回调中添加 PSR_BO == 1 检查，以过滤掉错误的恢复通知。

[quote userid="675191" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000-microcontrollers---internal/f/c2000-microcontrollers---internal-forum/1682154/f29h859tu-q1-f29-can-transmission-and-busoff-interruption-handling-issues"]问题 2：对于 F29H85x，当将 Mcal Can 邮箱类型配置为 BASIC_CAN 且 CanHwObjectCount 不为 1 时，在消息发送周期的负载测试期间，发现存在丢帧现象。这是因为请求发送消息时读取的空闲对象索引与最终发送时使用的索引不一致，导致消息错误。将 CanHwObjectCount 改为 1 解决了这个问题，但是为什么当 CanHwObjectCount 大于 1 时仍然会出现丢帧问题？

在选择空闲的 TX 缓冲区和实际写入之间可能存在竞争条件。当 CanHwObjectCount > 1 时，驱动程序会在索引 X 处找到一个空闲缓冲区，但当 Can_WriteRamPriv() 执行时，来自另一个任务的并发发送请求可能已经占用了该缓冲区。因此，最终写入时使用的索引与最初选择的索引不匹配，导致消息错误或丢失。建议使用 CanHwObjectCount = 1，这样就只有一个缓冲区，索引也确定，从而避免竞争条件。我也会将此问题转发给 MCAL 团队，以便他们进行调查。

问候，

约瑟夫

[/quote][/quote]

TMS320F280049C: ADC采样误差

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

Part Number: TMS320F280049C

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

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