电机控制芯片实用反馈：F28335与先楫第四期
第四期：上一辑那条 F28335 批次 ADC 问题补齐数据后由 TI 判定增益超规，另有量产写 JTAGLOCK 锁死一颗芯片、双核分工下 CPU2 读不到 HRPWM 校准寄存器、C2000Ware 的 Debug 库把配 flash 的代码放进 flash，以及 MotorControl SDK 的 BiSS-C 库又查出四处缺陷。
上一辑收的是 2026-10-09 前后在 TI E2E 上新出现的四条 F28335 记录。这一辑接着往下记，检索窗口从 2026-10-16 到 2026-10-23 09:00。
本期收录 5 条，全部落在 C2000 侧：F28335 一条、F28377D 一条、F280049 一条、F28P65x 两条。F28335 那条是上一辑记过的问题有了进展，不是新帖。
先楫这一侧本期没有新增一手记录，检索走到哪一步、哪条入口没取到，正文末尾照写。
读之前仍是三个约定。
一条记录只说明有人这样用过。 帖子数量只表示有多少人把经历写了下来，本辑不拿它推算故障率，也不拿它推算市场份额。
作者没写的条件，这里留空。 温度、母线电压、负载、固件版本这些，原帖不提就写「未披露」，不替作者补一个看起来合理的值。
厂商材料只用来核验。 数据手册、参考设计和 SDK 更新说明能确认规格与设计意图，它们对芯片的评价不独立，凡属此类都标 V。
日期按北京时间记录。TI E2E 的回复楼层只显示相对时间，页面不给绝对日期，所以每条记录的「日期」写的是原帖时间，回复另作说明。
发帖人在帖子里能看到的身份，这里照写；看不到的就只说「发帖人」，不推测他是什么岗位。回复里的 TI 员工一律写出名字，方便对照同一批人在不同帖子里的说法。
| 层级 | 含义 |
|---|---|
| A | 用户一手实测，型号、板卡、条件与复现过程至少写到能被人照着查 |
| B | 用户一手陈述，型号或测试条件有明显缺口 |
| C | 二手转述、市场观察或行业媒体报道，只作背景 |
| V | 厂商材料，用于核验规格与设计 |
量产验证与供货
上一辑那条 ADC 批次问题有了下半段：TI 判定「增益超出规格」
上一辑记过这条帖子的前半段：一位工程师用 TMS320F28335ZJZS 做电源变换器控制，新批次芯片的 ADC 读数超过 95% 后直接跳到满码值，换回旧批次芯片就正常。当时帖子停在 TI 要求补条件的地方。
这一期复查，帖子里已经补上了完整数据。1
跟帖里出现的是同一家公司的设计团队，署名 MEDHA PE_AUX design team。补的第一批条件是参考源与温度：外部参考
Vref = 2.048 V，器件 REF5020IDR，环境温度约 +25 °C。所有通道都偏大，采样保持电路 A 与 B 没有差别。1第二批是七个电压点上正常片子与异常片子各自的码值。
| 输入电压（V） | 正常批次码值 | 异常批次码值 | 差值 |
|---|---|---|---|
| 0.6683 | 906 | 940 | 34 |
| 1.2725 | 1743 | 1798 | 55 |
| 1.8107 | 2470 | 2561 | 91 |
| 2.4136 | 3294 | 3412 | 118 |
| 2.8592 | 3899 | 4047 | 148 |
| 2.8984 | 3955 | 4095 | 140 |
| 2.9864 | 4077 | 4095 | 18 |
表里的码值来自发帖人的回复，差值是这一列按同一行两数相减得到的。最后两行已经贴到满码值，差值反而变小，那是饱和，不是误差变小。1
TI 的 Matthew 按这组数据给了判定：异常片子测到的增益误差是 122 LSB，规格是 30 LSB，超出规格；失调误差 -7 LSB，在规格内；传输函数是线性的。他的结论是这里遇到的是「预期之外的增益误差」。1
他还提了四件事要对：这片异常器件的失效率与样本量、故障是在什么时候被发现的、两颗芯片的上表面标记、以及把参考源改成内置参考后重测一次。1
发帖人回了其中一部分：问题在 PCB 测试阶段就被发现，属于首道在线测试；材料部门已开单，编号 CPR261157541；上表面标记是异常片
G4A-49APDYW、正常片 G4A-3AAC9IW。改内置参考重测这件事，他说测试流程与软件都没动过，打算往后放。1TI 最后追问的是：两颗器件有没有经历过已知的过压或应力事件。帖子停在这个问题上。
- 型号：TMS320F28335ZJZS（发帖人写法；帖子归属料号 TMS320F28335）
- 板或模块：电源变换器控制板，型号未披露
- 硬件或固件版本：未披露
- 测试条件：外部参考 2.048 V（REF5020IDR）；环境温度约 +25 °C；7 个输入电压点；正常批次
2340-G4A-3AAC9IW-NA，异常批次2437-G4A-49APDYW-4478989PHI；采样率与参考源之后的滤波未披露 - 日期：2026-10-09 发帖（上一辑已记）；本期读到的新跟帖，页面只给相对时间，检索截止 2026-10-23
- 证据层级：A（参考源、温度、逐个电压点的码值都写清了，能照着复算）
- 归因：器件侧，TI 回复确认增益误差超出规格；是否为批次性问题、根因在晶圆、封装还是测试环节，均未定
- 复现与解决状态：换回旧批次芯片读数正常；TI 已判定超规并要求补失效率与器件标记；根因未定位
- 待核实点：失效率与样本量；内置参考重测的结果；两颗器件是否经历过量应力；CPR261157541 的处理结论
- 原始链接：TMS320F28335: ADC Error Observed in TMS320F28335ZJZS DSP – Production Batch Investigation
量产时写 JTAGLOCK，把一颗芯片当场锁死
另一位工程师要做的是量产锁定：把 0x78018 处的数据从
0x9FFFFFFF 改成 0x9FFFFFF0，打开 F280049 的 JTAGLOCK。测试环境是 C2000Ware_1_00_05_00、CCS 12.7、一颗全新芯片。2他试了两条路。第一条是调 API，返回
InvalidAddress，写不进去。第二条是让程序自己去写：先用 UniFlash 把程序 A 烧到 0x100000–0x108000，烧完运行正常；然后在程序 B 里改那片区域，HEX 8 位模式，地址 0x108000–0x110000 加上 0xF0030。2烧程序 B 时报错。断电重启之后，原来的程序 A 也跑不起来了，JTAG 已经锁死。日志里先是 -1156、-2134、-1135，之后每一步都是「target is not connected」。2
TI 的 Zackary Fleenor 把两个问题分开。API 失败是地址与库版本的问题，不是流程写错。直接写 flash 失败，是因为一个 hex 文件里同时装了 OTP 块与应用区，UniFlash 边写边执行，OTP 一落地 JTAG 就断了，后面的镜像再没机会写进去。2
他给的理由很具体：擦除设置是整个 flash，整片擦完了，JTAG 却在写入新镜像之前断掉，所以程序 A 也没了。单次 UniFlash 装载控制不了各段的写入顺序，而 JTAGLOCK 必须是整个序列里最后一次写。2
TI 建议的量产顺序是四步：烧写并校验应用 flash；烧写并校验全部 USER OTP 与 DCSM 设置；做功能测试，这是最后一次还能用 JTAG 的机会；最后单独烧一个只含 JTAGLOCK 的镜像。这套配置要用 C2000Ware 5.02 或更新版本，由 SysConfig 生成独立输出文件。2
锁定之后的代价也写清了：JTAG 工具与内置引导都不可用，以后要升级固件，只能靠已经驻留在 flash 里的代码。所以锁定任何一片之前，先把应用内升级路径做完并验证。2
发帖人后来换了一颗新片，按这个思路做成了：先烧程序 A，校验通过；烧程序 B 时勾选「Necessary Sectors Only」，取消「Verify Flash after Program」，避开锁定后回读报错，永久锁定达成。2
他随后接着问了两件细节：这种写法是不是必须用 5.02 的工程生成的文件；用 Flash API 一次写 4 个 16 位字在实测里能成，而例程里写的是 8 个。TI 后续的答复里提到，
STATCMD 读到 3（CMDDONE|CMDPASS）表示命令成功，把任何非零当错误是流程图的写法有问题；F2800157 上 STATCMD 在 CCS 寄存器视图里看不到，要用 Fapi_getFsmStatus() 读。2- 型号：TMS320F280049
- 板或模块：未披露（自研板，程序 A 位于 0x100000–0x108000）
- 硬件或固件版本：C2000Ware_1_00_05_00、CCS 12.7、器件为全新件
- 测试条件：UniFlash 以 HEX 8 位模式烧写；OTP 块字地址 0x78018（字节地址 0xF0030）；目标值从
0x9FFFFFFF改为0x9FFFFFF0；擦除范围为整片 flash - 日期：2026-10-21
- 证据层级：A（版本、地址、烧写模式与失败日志齐全，换成新片后按改法成功锁定）
- 归因：工具链与操作流程。TI 确认原因是单次烧写把 OTP 与应用混在一起，且擦除设为整片；不是器件故障
- 复现与解决状态：第一颗芯片已锁死、未恢复；第二颗按 TI 的顺序与新设置成功永久锁定
- 待核实点：4 个与 8 个 16 位字的写入宽度是否都受支持；JTAGLOCK 是否只能来自 5.02 以后生成的工程；CPR 与锁死那颗的后续处理
- 原始链接：TMS320F280049: Issue with Enabling JTAGLOCK on the 280049
ADC 与 PWM 同步
把 EPWM 分给 CPU2 之后，HRPWM 的校准起不来
一位工程师在 F28377D 上做双核分工：EPWM1–EPWM6 分给 CPU2（
CPUSEL0），EPWM12 留给 CPU1。普通 PWM、ADC 触发与中断在两颗核上都正常。3系统时钟这边：EPWMCLK = 100 MHz，TBCLK = 50 MHz，增减计数，TBPRD = 625，即 40 kHz。EPWM1–3 要开高分辨率，
HRCNFG 设成两边沿、CTLMODE = CMP、HRLOAD = CTR_ZERO_PRD、AUTOCONV = 1；HRPCTL 的 HRPE 与 TBPHSHRLOADE 都置 1。3问题出在 SFO 校准。从 CPU2 调用 controlSUITE 里的那版库，6 次之后返回
SFO_ERROR；换成 C2000Ware 里 libraries/calibration/hrpwm/f2837xd 的 SFOv8fpulibbuildc28coff.lib（他说这份二进制在 5.01、6.00.01 与 26.01 里完全一样），6 次之后返回 SFO_COMPLETE，但并没有真的完成校准。3他在每次调用后回读库里用到的 EPWM1 寄存器：偏移 0x21（HRPWR）、0x22（校准周期数）、0x24（测得的计数）、0x26（HRMSTEP），从 CPU2 读全是 0，库刚写完也读 0。用调试器选中 CPU2 看，HRMSTEP 与 HRCNFG 同样是 0。3
他试过绕开：启动时先把 EPWM1–3 临时分给 CPU1，在 CPU1 上跑 SFO，校准正常完成，
MEP_ScaleFactor = 59，约合每个 MEP 步 170 ps；再把这三路交回 CPU2。交回之后，CPU2 侧仍然读 0，而 CPU1 侧（此时已不是所有者）调试器里 HRMSTEP 在 0 与 59 之间跳，HRCNFG 在 0 与 0x53 之间跳。3这条路径挡住了他真正想做的事：让 CPU2 周期性跑 SFO，跟温漂与电压漂移。他给 TI 的问题有三个层次——CPU2 访问 HRPWM 校准寄存器是不是本来就受限、通道 HR 寄存器（
HRCNFG、CMPAHR、HRPCTL）是否同样受限、以及如果 SFO 只能跑在 CPU1，那 CPU1 定期校准与 EPWM 归 CPU2 能不能共存。3截至本期检索，帖子里没有 TI 回复。这条记录的价值在于现象与条件完整可对照，结论仍在厂商那一侧。
- 型号：TMS320F28377D
- 板或模块：未披露
- 硬件或固件版本：硅片版本、CCS 版本、C2000 编译器版本作者自己在模板里留空；库为 controlSUITE 版与 C2000Ware
libraries/calibration/hrpwm/f2837xd的SFOv8fpulibbuildc28coff.lib - 测试条件：EPWMCLK 100 MHz、TBCLK 50 MHz、增减计数、TBPRD 625（40 kHz）；EPWM1–6 经
CPUSEL0归 CPU2；HRCNFG两边沿、CTLMODE= CMP、HRLOAD= CTR_ZERO_PRD、AUTOCONV= 1；HRPCTLHRPE = 1、TBPHSHRLOADE = 1；CMPA 在 0 与周期处装载；母线电压与功率级未披露 - 日期：2026-10-20
- 证据层级：B（寄存器级操作与回读值写得很细，但硅片版本、编译器版本留空，且没有厂商确认）
- 归因：外设／配置／驱动待定。现象是 CPU2 侧读不到 HR 寄存器，是否属于未文档化的访问限制，帖内没有结论
- 复现与解决状态：作者已复现；临时办法是 CPU1 完成校准后移交所有权，但周期性校准仍做不到
- 待核实点：CPU2 访问 HRPWR／HRMSTEP 的权限在 TRM、数据手册或勘误里有没有写；CPU1 校准的 MEP 值移交后是否仍然有效；通道 HR 寄存器是否同样受限
- 原始链接：TMS320F28377D: F28377D – HRPWM calibration (SFO) does not work from CPU2: HR register block of EPWM1 not accessible
工具链与调试器
Debug 库里，配 flash 的那段代码其实在 flash 里跑
还是在 F28P65x 上，同一批人换了问题：C2000Ware 26.02.00.00、C2000 CGT 25.11.1.LTS（EABI），TRM 是 SPRUIZ1B，数据手册 SPRSP69D，勘误 SPRZ545D。他们在设计内存映射与链接命令文件时，把 driverlib 的 Debug 库拆开看了段与重定位。4
发现是这样的：
Flash_initModule() 本身放在 .TI.ramfunc，但 Flash_writeTrims() 是 static inline，没有 CODE_SECTION 指示；Debug 库用 --opt_level=off 编译，内联不展开，于是这个函数连同两个校验函数落进了 .text 段。4后果是：在 FLASH 构建里，这段本该在 RAM 里执行的配 flash 代码，实际从 flash 执行，而 TRM 12.1.4 写的是「配置等待周期、cache／prefetch 这些 flash 设置的代码，只能在 RAM 里执行」。Release 库全部内联，不受影响。4
这条影响面比看上去大：C2000Ware 的空工程模板，FLASH 配置用的正是 Debug 库。也就是说，拿模板起一个 flash 工程，默认就落在这种组合上。4
同一个帖子里还有四项文档层面的问题。勘误 SPRZ545D 的文字说 prefetch 队列深 16×16 字，表 3-4 却只把 flash 末尾 8 个字列为不可靠近；链接文件给
RAMM1 留了余量，RAMLS9 没留；TRM 把 MCUCNF1 的 D2–D5 字段标成只读，而 driverlib 从 CPU1 写它；TRM 说所有专用 RAM 都有 ECC，数据手册的内存表把 D0–D5、LS0–LS9、GS0–GS4 标成 Parity。4文档问题里有一条带着实测：在 LAUNCHXL-F28P65X 上，上电复位后（开机时没接调试器）在
main() 开头读 D2–D5 的分配寄存器，全部读到 0，即这几块 RAM 上电后归 CPU1。TRM 给这几位的复位值写的是「X」，作者想请 TI 确认这是不是定义好的复位状态。4TI 的 Arpit 回了一句「我先看一下，稍后给你答复」。到本期检索为止，没有进一步结论。4
- 型号：TMS320F28P650DK
- 板或模块：LAUNCHXL-F28P65X（仅用于上电复位后读 D2–D5 的那一项实测）；其余为链接命令文件与库层面的检查
- 硬件或固件版本：C2000Ware 26.02.00.00、C2000 CGT 25.11.1.LTS（EABI）、TRM SPRUIZ1B、数据手册 SPRSP69D、勘误 SPRZ545D
- 测试条件：Debug 库
driverlib/ccs/Debug/driverlib.lib（--opt_level=off）；FLASH 构建；上电复位、开机时不接调试器 - 日期：2026-10-20
- 证据层级：A（版本、文件与行号、段与重定位的检查方法都写清了，且带一项上板实测）
- 归因：软件与工具链（SDK 的构建配置与文档不一致）。TI 尚未确认，也不能据此说芯片行为有偏差
- 复现与解决状态：作者已用 objdump 检查库并复现段归属；TI 收到，结论未出
- 待核实点：从 flash 执行
Flash_writeTrims()是否安全；prefetch 那条到底按 8 字还是 16 字留余量；RAMLS9要不要同样缩短；D2–D5 上电归属是否就是 CPU1 - 原始链接：TMS320F28P650DK: F28P65x C2000Ware 26.02 driverlib Debug build: Flash_initModule() calls Flash_writeTrims() from .text
移植与外设成本
MotorControl SDK 的 BiSS-C 库，又查出四处问题
同一批人在查 MotorControl SDK 6.00.00.00 的 BiSS-C 库，路径
libraries/position_sensing/bissc，例程是 solutions/absolute_encoder_boostxl_posmgr。上一轮他们报了 5 个问题，TI 的 Peter 确认并立了 bug；这一轮补的是第 6 到第 9 处。5第 6 处是拼接位时用 32 位做移位。
pm_bissc_source.c 第 617 行是 returnBits |= data[element] << tempIndex;，returnBits 是 uint64_t，data[element] 是 32 位，移位在 32 位里算完再或进去，越过第 31 位的部分就丢了。默认 42 位帧下不会碰到，但位置字段更长时（例如 MT 24 + ST 19）会拼出错的位置。5第 7 处是一个宏算错：
PM_BISSC_CD_RDATA_DATA_BITS = 12 − 1 − 1 = 10，于是 PM_BISSC_CD_RDATA_START_S 得 9，而 12 位字里的 Start 位实际是第 11 位，CDS_S = 10 才对得上。库自己没用这个宏，所以现在不报错；用它的应用代码会读错位。5第 8 处是同一个开关被两种写法判断。
PM_BISSC_ENCODER_HAS_CD_INTERFACE 在头文件里按「值」用，#if 判断；在 pm_bissc_source.c 与例程里又按「是否定义」用，#if defined() 判断。用户照文档把它设成 0，按定义判断的那几块仍然编译进去，还会引用被 #if 去掉声明的表，构建看起来会断。5第 9 处与实时性有关，正好落在控制环里：
bissc_getCRC() 在内部头文件里声明带了 ramfunc 属性，但定义所在的 pm_bissc_crc.c 只包含了公开头文件，属性在定义点不可见，函数就落进了 .text。5它在每一帧位置数据上都会被调用：
PM_bissc_receivePosition()（本身是 ramfunc）第 293 行调用它。所以在 FLASH 配置下，CRC 每帧从 flash 里算，作者判断这不是本意。他们给定义加上属性后，map 文件里这个函数确实进了 .TI.ramfunc。5他们还回头追了上一轮第 5 个问题：默认 MA 时钟
BISSC_MA_CLOCK 8.0 MHz，因整数分频变成 8.33 MHz，在 SPI 从机模式（时钟由 CLB 供给）下到底受哪条限制——TRM 的「不大于 LSPCLK / 4」（LSPCLK = 25 MHz 时是 6.25 MHz），还是数据手册的 4 tc(SYSCLK)（200 MHz 时是 50 MHz）。他们自己按 2 MHz 跑，所以这一条不卡进度，但仍想知道正确上限。5TI 的 Peter 回复说会逐条对照例程实现再给结论。本期检索时，这条还没有下文。5
- 型号：TMS320F28P650DK（库内另含 f28p55x 的副本）
- 板或模块：例程对应 BOOSTXL-POSMGR 绝对编码器方案；本次检查以库源码与例程构建为主，未跑电机
- 硬件或固件版本：C2000Ware MotorControl SDK 6.00.00.00；行号指未经修改的 6.00.00.00 文件
- 测试条件：以 Debug 与 FLASH 两种配置构建例程，比对 map 文件确认函数落段；帧格式默认 42 位；实际编码器型号、线缆长度与电缆速率未披露
- 日期：2026-10-20
- 证据层级：A（文件、行号、复现路径与修好后的 map 文件结果都在）
- 归因：软件（SDK 库代码）。上一轮 5 个问题已由 TI 确认并立案；本轮的 4 处仍在等确认
- 复现与解决状态：四处问题均已定位；第 9 处作者自行加上属性后验证有效；TI 书面表示会核对
- 待核实点：SPI 从机模式下该按哪条时钟上限；长位置字段下拼位的实际影响；
#if defined写法是否在后续版本统一；修复会落在哪个 SDK 版本 - 原始链接：TMS320F28P650DK: MotorControl SDK 6.00.00.00 PM BiSS-C library F28P65x: four more issues
中断与实时性
本期没有新增记录。检索到的中断相关帖子，没有一条同时给出能照着查的条件和结果。F28379D 上那条
.TI.ramfunc 的帖子与这一维度最近，现状列在文末。先楫这一侧
本期没有新增一手记录。
实际走过的地方：B 站按 HPM6P41 与电机相关词搜过，返回的仍是此前那几条（自研伺服驱动板、SEI 读多摩川编码器、I2C 热拔插），没有新投稿；GitHub 上 hpm_sdk 的 issue 列表，本期新增的一条是 HPM6E00 的 MCAN／TSU 时基寄存器地址问题，型号不在本期口径内。6
还有一条入口没走通：先楫官方公众号的文章列表，这次接口返回空，没有取到任何一篇。这不能当作「该账号本期没有发布」，只能说明这一期没读到它。
- 型号：HPM6P00 系列（hpm_sdk 与知识库）
- 证据层级：V
- 日期：2026-10-23 检索；hpm_sdk v1.13.0 为 2026-09-30，知识库最新一篇为 2026-06-04
- 待核实点：HPM6P00／HPM6P41 上的中断延迟实测；批量供货、产线验证与售后记录；首期记的 SEI 中断标志问题官方是否确认
本期核对了、没有展开的记录
条目已满 5 条。下面这几条与主题相关，只给链接与一句话现状。
- TMS320F28P650DK 上把 CLB 当软件跳闸闸门用，SYSCLK 200 MHz、tile 时钟按分频也是 200 MHz，作者逐条问 TRM 8.2.1 的 150 MHz 上限是否管这条路径。TI 的 Praneeth 回答很干脆：CLB 时钟不建议超过 150 MHz，寄存器时钟与 tile 时钟都算，任何路径都不行。9
- TMS320F28379D 上一个 PI 环放在
.TI.ramfunc，PI_Run()解析到 RAM 地址，但启动memcpy()之后 RAM 里反汇编出来仍是0000 ITRAP0。作者关心的是延迟，TI 的 Ira 说会看工程文件后再答，暂无结论。10
上一辑遗留线索的复查
产线 I/O 那条（TMS320F28335，约 6% 不合格，100–89 号引脚读不到）这次打开时，帖子顶部写着已被锁定，最后一条仍是 TI 的 ESD 保护二极管假设，没有失效分析结论。11
其余几条本期没有逐一复查，不下结论。
待核实点汇总
- ADC 批次那条：失效率与样本量；内置参考重测；两颗器件是否经历量应力；材料单的处理结果。
- JTAGLOCK 那条：4 个与 8 个 16 位字的写入宽度是否都受支持；锁定镜像是否必须来自 5.02 以后的工程。
- HRPWM 那条：CPU2 有没有访问 HR 寄存器的权限，文档在哪里写；移交后校准值是否有效。
- C2000Ware 那条：从 flash 执行配 flash 的代码是否安全；勘误表与链接文件按 8 字还是 16 字留余量。
- BiSS-C 那条：SPI 从机模式的时钟上限；修复落在哪个版本。
- 长期空白：F28335 在 2026 年的真实价格与交期；HPM6P00／HPM6P41 的批量供货、产线验证与售后记录。
References
- 1
- 2
- 3
- 4
- 5
- 6hpmicro/hpm_sdk Issues
github.com
- 7Releases · hpmicro/hpm_sdk
github.com
- 8HPMicro 知识库
kb.hpmicro.com
- 9
- 10
- 11TMS320F28335: I/O Input issue.
e2e.ti.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.