CLA协处理器在数字电源移相控制中的应用与ADCOFFTRIM偏差修复

1. 相位实时联动控制：为什么主CPU直连中断这条路会先卡住

1.1 一个DAB电源项目暴露出的问题

先说实际场景。我手头有个双向有源全桥（DAB）数字电源项目，控制核心是TI C2000系列的F28069。DAB拓扑有原边全桥和副边全桥两套H桥，传输功率的大小直接由两套PWM波之间的移相角决定。负载变化时，你必须在几个开关周期内把移相角拉到一个新的目标值，否则电感电流就会出现明显的直流偏置，轻则效率掉下来，重则直接触发保护。

初期方案很常规：配置一个50kHz的PWM下溢中断，CPU进中断后读ADC电流采样值，跑增量式PI，计算结果更新副边全桥的相位寄存器。空载跑起来一切正常，一旦加到额定功率，问题就出来了——副边PWM的移相角肉眼可见地抖动，电感电流波形上出现很多不该有的毛刺，环路带宽怎么调都上不去。用示波器统计PWM周期抖动，发现最坏情况能到几百纳秒，这对20μs周期的开关频率来说已经不算小数目了。

后来我把整个采样和控制链路由CPU中断搬到了F28069片上那颗CLA协处理器上，同样工况下相位抖动消失，电流波形干净了，环路带宽也能继续往上推。这篇文章就是把这次改造的完整思路、代码和踩过的坑写出来，重点包括：CLA任务如何配置、如何用ePWM的SOC事件让ADC采样时刻严格锁定在PWM载波相位上、CLA怎样直接参与PWM相位实时调整，以及一个非常隐蔽的ADCOFFTRIM读取偏差问题。做电机控制、数字电源、并网逆变器的同学，这类问题大概率都会遇到。

1.2 中断延迟只是表面，流水线与外设仲裁才是主要矛盾

我一开始以为问题是PI算得不够快。F28069主频90MHz，50kHz中断周期下等于每个周期有1800个主频周期，做个电流环绰绰有余。真正的问题在于中断路径的时间不确定性。

C28x内核有流水线，进中断时如果正好遇到多周期指令，流水线要刷新，响应时间就会浮动；F28069的程序如果跑在Flash里，还有等待周期；再加上期间其他外设中断抢占、共享总线仲裁，这几十到几百纳秒的抖动就来了。单独看单次中断延迟不大，但相位控制最怕的就是这种随机抖动。DAB移相角每周期都在变，ADC采样时刻若和PWM载波之间的相对相位有抖动，你采到的电流值就不是你以为的那个时刻的电流。控制环相当于一直在“看走眼”。

1.3 CLA要解决的不是“算得快”，而是“不和CPU抢时间”

CLA是Control Law Accelerator，控制律加速器，F28069上自带一颗独立的32位浮点协处理单元。它不提高主CPU频率，也不是把CPU指令执行得更快，而是能独立运行自己的任务代码。你想让CPU去处理通信、显示、保护逻辑、故障记录，又想保证电流环/相位环有确定性的执行时序，这几个需求同时存在的时候，CLA的价值就出来了。

它和CPU并行跑，有自己的程序RAM、数据RAM和中断源。你把控制算法放进CLA任务里，由PWM/ADC这条硬件链路直接触发，CPU完全不参与逐周期的控制运算，控制律的执行时刻就不会再受其他软件任务干扰。这就从架构上把“实时性抖动”的问题抹掉了，而不是靠优化中断服务程序去“挤时间”。

2. F28069的CLA编程模型：任务、内存与直写外设的能力

2.1 八个任务和触发机制的关系

CLA上有Task1到Task8共八个任务入口，每个任务可以指向一段独立的控制算法。任务之间还能配置优先级，高优先级任务运行中可以打断低优先级任务，但正在执行的任务不会被更高优先级任务之外的任何东西打断，这个可以把它理解成协处理器内部的一套微型调度器。

任务的触发方式有两种。第一种是软件触发，比如你写一个CLAForceTask1()，CLA就会开始执行Task1；第二种是硬件映射触发，把某个外设中断线直接映射到某个CLA任务，比如ADC转换结束中断直接触发CLA，PWM周期事件直接触发CLA。第二种方式才是实时控制的关键，因为整条硬件链路完全不经过CPU中断的进出流程，时钟抖动最小。

具体到F28069，CLA有一组寄存器负责中断标志和触发源选择。任务执行完成后，硬件会把对应的完成标志位置起来，CPU可以查询这个标志或者响应CLA完成中断，去拿结果或者做下一次参数更新。

2.2 除了算得快，CLA还能直读ADC结果、直写PWM寄存器

很多第一次接触CLA的人会以为它只是个“增强版浮点加速器”，只能算数，然后跟CPU通过共享内存交换数据。其实F28069这颗芯片上，CLA的访问范围比想象中大不少。它通过独立的总线接入部分外设空间，可以绕过CPU直接读取ADC结果寄存器，也可以直接修改ePWM模块里的部分寄存器，比如比较值CMPA、时基相位TBPHS这类与占空比、移相角直接相关的寄存器。

这点非常重要。如果CLA只能算数，算完还得靠CPU把结果搬到PWM寄存器，那控制环路上依然有一个“CLA→CPU→PWM”的延迟；现在CLA可以直接在任务里写PWM相位，那么PWM触发ADC采样、ADC转换完成触发CLA、CLA算完直接把新相位写进副桥PWM，完全是一条不经过CPU的闭环硬件链路。TI官方不少电机控制例程里，就有CLA任务直接修改EPwmRegs.CMPA的先例，不是野路子。

不过也不能理解成CLA什么外设都能访问。它接的是外设帧PF0这部分空间，ADC结果寄存器、ePWM部分关键寄存器在里面，所以没问题；而像SCI、SPI、CAN这类通信外设的寄存器，CLA碰不着，数据交换还是得经CPU中转。

表格对比一下两种控制回路的差异会更直观：

2.3 软件触发还是外设中断直连，怎么选

整套链路刚调通的阶段，我建议先不要急着把CLA映射到ADC中断上。先用软件触发方式跑通一个CLA任务，让CPU强制执行一段CLA代码，在CCS里观察CLA任务是否正确执行、输出结果对不对。等CLA算法本身没问题了，再把触发源切到外设中断映射，这样排查问题的时候不会出现“到底是CLA代码写错了，还是触发没进来”这种两头不着边的状态。

F28069里每个CLA任务可以在软件触发和硬件映射触发之间自由配置，所以我在项目里保留了两种方式的切换开关，调试阶段用软件触发，实际运行时用硬件映射触发。

3. 相位对齐的基石：用ePWM的SOC事件把ADC采样钉在载波上

3.1 中心对齐PWM下，采样点该放在哪里

标题里的“相位实时联动控制”，核心就是让ADC采样的时刻始终和PWM载波保持确定性的相位关系。C2000里通常的做法是让PWM模块直接产生ADC的启动转换信号（SOC，Start Of Conversion），而不是靠软件在中断里去启动。

先看PWM计数模式。做DAB移相控制我通常用增减计数模式，也就是中心对齐PWM。时基计数器从0往上数到周期寄存器TBPRD，再往下数回0，PWM输出在一个周期内会产生对称的上升沿和下降沿。计数器等于0的时刻称为下溢（zero），等于TBPRD的时刻称为周期匹配。

中心对齐PWM下，电感电流纹波会在两个开关沿之间的中点附近出现峰值或谷值，这个点相对稳定，适合作为采样窗口。所以我把ADC触发点放在“计数器等于0”这个事件上，配合适当的采样窗口长度，保证采到的是开关周期中点附近的电流值。做电机控制的朋友应该很熟悉这个逻辑——FOC里常用CTR=0时刻采样相电流，就是为了避开PWM边沿附近的开关噪声和振铃。

3.2 关键寄存器配置实例

下面是我在F28069工程里的实际配置代码。系统主频90MHz，目标开关频率50kHz，所以周期寄存器TBPRD设为900：

// EPWM1：原边主桥，中心对齐模式 EPwm1Regs.TBSTS.all = 0; EPwm1Regs.TBPHS.all = 0; EPwm1Regs.TBCTR = 0; EPwm1Regs.TBPRD = 900; // 90MHz / (2 * 900) = 50kHz EPwm1Regs.TBCTL.bit.CTRMODE = 0b10; // Up-Down，增减计数 EPwm1Regs.TBCTL.bit.PHSEN = 0; // 主模块，不跟随外部同步 EPwm1Regs.TBCTL.bit.SYNCOSEL = 0b00; // 输出同步信号给从模块 EPwm1Regs.TBCTL.bit.HSPCLKDIV = 0; EPwm1Regs.TBCTL.bit.CLKDIV = 0; // 动作限定：增计数匹配CMPA时输出置高，减计数匹配时置低 EPwm1Regs.CMPA.bit.CMPA = 450; // 初始占空比50% EPwm1Regs.AQCTLA.bit.CAU = 0x02; // CAU -> set EPwm1Regs.AQCTLA.bit.CAD = 0x01; // CAD -> clear // EPWM1的SOCA事件：CTR=0事件触发ADC EPwm1Regs.ETSEL.bit.SOCAEN = 1; EPwm1Regs.ETSEL.bit.SOCASEL = 0x02; // 2 = TBCTR=0事件 EPwm1Regs.ETPS.bit.SOCAPRD = 1; // 每次事件都触发

ADC侧的核心配置是把ePWM的SOCA作为排序器SEQ1的启动源：

AdcRegs.ADCTRL3.bit.SMODE_SEL = 0; // 顺序采样模式 AdcRegs.ADCTRL3.bit.ADCCLKPS = 0x0A; // ADC时钟分频，按实际时钟折算 AdcRegs.ADCTRL1.bit.ACQ_PS = 0x06; // 采样窗口宽一些，留足采集时间 AdcRegs.ADCMAXCONV.bit.MAX_CONV1 = 1; // 两个转换通道 AdcRegs.ADCCHSELSEQ1.bit.CONV00 = 0; // 通道A0：原边电流 AdcRegs.ADCCHSELSEQ1.bit.CONV01 = 4; // 通道A4：副边电流 AdcRegs.ADCTRL2.bit.EPWM_SOCA_SEQ1 = 1; // ePWM SOCA启动SEQ1 AdcRegs.ADCTRL2.bit.INT_ENA_SEQ1 = 1; // SEQ1转换结束产生ADCINT1

这样ADC转换启动完全由PWM硬件事件决定，CPU软件只负责初始化，启动时刻和PWM载波相位的对齐精度就只取决于硬件本身，不再受任何软件延迟影响。

3.3 移相角的“实时联动”，靠主从PWM和TBPHS实现

DAB的移相控制要有一个主模块和一个从模块。EPWM1作为主桥，产生基准载波并输出同步信号；EPWM2作为副边桥，通过同步输入跟随EPWM1，然后利用TBPHS寄存器设置两桥之间的移相角。

TBPHS这个寄存器很关键。从模块收到同步信号后，硬件会把TBPHS里的值装进TBCTR计数器，从而实现载波相位的整体搬移。而且TBPHS有影子加载机制，你在这个周期往TBPHS写新值，硬件会在下一个同步加载点才把它应用到实际计数器上，这样就避免了一个周期内出现半个新相位、半个旧相位的情况。

也就是说，每周期更新一次TBPHS，PWM相位就能逐周期平滑调整，这就是“相位实时联动”的落点。CLA任务算出来的移相角最终就写到EPWM2的TBPHS上。

4. 踩坑实录：CLA读ADC结果寄存器时遇到的ADCOFFTRIM偏差

4.1 故障现象：CPU读出的和CLA读出的差一个固定常数

系统联调时发现一个怪现象。我把CPU和CLA分别读取同一路的ADC转换结果，在共享RAM里记录下来比对，发现两者总是相差一个固定值。空载、加载、改变母线电压，这个差始终存在，而且数值恰好等于ADCOFFTRIM寄存器里配置的偏置校正值。

一开始我怀疑是采样点错位了，比如CPU读的是这次转换的结果，CLA读的是上一次转换的结果，顺序上差了一拍。可是我把触发源改成软件触发、手动等转换完成后同时读取两边，差别依然存在，这就排除了时序错位的可能。然后我又觉得会不会是CLA数据线宽度问题，把12位结果读成16位导致高4位错误，可实际偏差值并不是256这类位宽错位应有的数值，而是实实在在的几十到上百个LSB，和ADCOFFTRIM值完全吻合。

4.2 根因：ADC结果寄存器有两条通路，CLA走的不是同一道门

翻TI的参考手册并在芯片上反复验证后，问题定位清楚了。F28069的ADC模块里，转换内核完成一次转换后，原始二进制结果会先锁存到一级原始结果锁存器里；在CPU读取最终结果寄存器ADCRESULTx之前，硬件还会做一步偏移校正操作，把ADCOFFTRIM值与原始结果相加，然后才把校正后的值呈现在CPU可见的结果寄存器中。

问题在于，CLA访问外设空间走的是另一条独立总线，它在ADC结果路径上的“快照点”更靠近转换内核，是在偏移校正加法逻辑之前的位置。所以CLA读到的原始结果并没有叠加ADCOFFTRIM。CPU看到的12位结果，和CLA看到的12位结果，之间差的就是这个ADCOFFTRIM值。

用照片来打比方的话：CPU拿到的是后期修过的成片，CLA拿到的是底片。底片不是不能用，但你得知道它没经过那层修图。

4.3 修复方案：把校正值提前搬到CLA能吃到的共享内存

知道了根因，修复就简单了。我不打算让CLA去读CPU那边的结果寄存器来碰运气，而是在初始化阶段让CPU把ADCOFFTRIM寄存器里的值读出来，放到一段CLA和CPU都能访问的共享RAM里。CLA任务在读取ADC结果后，自己在算法里补一次加法，得到和CPU侧一致的校正结果。

这样处理有两点好处：一是CLA侧不依赖总线和校正逻辑的先后关系，完全由自己的代码控制数值一致性；二是即便后续CPU侧换了校准策略、在运行中调整过偏置校正值，只要CPU把新的值同步到共享RAM，CLA下次任务就能用到最新校正量。

从成本上看，ADC本来就是12位结果，CLA做一次浮点或者整数加法只需要一个指令周期，对控制环没有任何实质影响。唯一要留意的是，不同C2000系列的CLA在ADC结果读取行为上不见得完全一致，有的器件修正方式可能是加、可能是减，也可能最终版本已经把两条通路统一处理了。所以你换型号后一定先做一次CPU/CLA对比读数的自测，确认偏差方向和值的大小，再在代码里处理。

下面是CLA任务里的修正代码片段：

#include "F2806x_Cla_Defines.h" // 共享变量：由CPU初始化后写入，CLA只读 extern volatile Uint16 ClaAdcOffsetTrim; __interrupt void Cla1Task1(void) { // 读ADC原始结果（CLA总线通路，未应用ADCOFFTRIM） Uint16 rawAdc0 = AdcResult.ADCRESULT0 & 0x0FFF; // 手动应用偏移校正 Uint32 corrected0 = (Uint32)rawAdc0 + (Uint32)ClaAdcOffsetTrim; // 后续按校正后的值参与闭环运算 // ... }

5. 完整可参考的代码与链接脚本配置

5.1 初始化流程：从时钟到CLA任务触发

完整工程里初始化顺序建议按照“时钟→PWM→ADC→CLA代码搬运→CLA中断映射→全局中断”来做。CLA代码必须先从Flash搬运到CLA可执行的RAM区，否则任务一启动就进非法指令陷阱。

主程序初始化片段：

void main(void) { InitSysCtrl(); // 系统时钟、外设时钟使能 DINT; // 关全局中断 InitEPwm1(); // 主桥PWM + SOCA触发配置 InitEPwm2(); // 副桥PWM，TBPHS相位跟随 InitAdc(); // ADC采样通道和触发源 LoadCla1Code(); // 从Flash拷贝CLA任务代码到RAML0 InitCla1(); // 配置CLA任务向量、触发源 // 把ADCOFFTRIM值读到共享RAM供CLA使用 ClaAdcOffsetTrim = AdcRegs.ADCOFFTRIM; // 其他业务初始化... InitSci(); InitGpio(); EALLOW; PieVectTable.CLA1_INT1 = &cla1Isr; // CPU响应CLA任务完成中断 EDIS; PieCtrlRegs.PIECTRL.bit.ENPIE = 1; IER |= M_INT11; EINT; // 主循环只做通信、显示、故障记录等工作 for (;;) { // 用户界面、CAN报文等非实时任务 } }

5.2 链接器里的CLA程序段配置

CLA代码不能直接放在Flash里跑，必须放到与CLA总线相连的RAM段中。TI的编译环境里通常用__attribute__或者#pragma把CLA任务代码单独圈成一个程序段，然后在链接器cmd文件里指定加载和运行地址。

我工程里的cmd文件相关片段如下：

SECTIONS { Cla1Prog : LOAD = FLASH, RUN = RAML0, LOAD_START(_Cla1funcsLoadStart), RUN_START(_Cla1funcsRunStart), SIZE(_Cla1funcsLoadSize) Cla1Data : > RAML1 /* 共享数据段，CPU和CLA都可以访问 */ Cla1Shared : > RAML2 }

对应的Flash到RAM拷贝函数：

extern Uint16 Cla1funcsLoadStart; extern Uint16 Cla1funcsLoadSize; extern Uint16 Cla1funcsRunStart; void LoadCla1Code(void) { memcpy((Uint16 *)&Cla1funcsRunStart, (Uint16 *)&Cla1funcsLoadStart, (Uint32)&Cla1funcsLoadSize); }

5.3 CLA任务里的控制算法与相位写入

这里给出一个简化但完整的CLA任务示例，实现ADC采样、偏移校正、PI计算、写TBPHS移相角。实际项目的PI参数需要按自己的环路设计来调整，这里只展示结构：

#include "F2806x_Cla_Defines.h" extern volatile Uint16 ClaAdcOffsetTrim; // 控制相关变量，放在共享数据段 #pragma DATA_SECTION(ctrlRef, "Cla1Shared") volatile float ctrlRef; // 移相角参考值 #pragma DATA_SECTION(piOut, "Cla1Shared") volatile float piOut; // PI输出 #pragma DATA_SECTION(pwmPhase, "Cla1Shared") volatile Uint16 pwmPhase; // 移相后的TBPHS值 static float errAcc = 0.0f; static float lastErr = 0.0f; // 极简增量式PI，浮点，CLA单周期浮点单元直接算 __interrupt void Cla1Task1(void) { Uint16 rawAdc0 = AdcResult.ADCRESULT0 & 0x0FFF; float iMeas = (float)(rawAdc0 + ClaAdcOffsetTrim); float fbk = iMeas / 4096.0f; float err = ctrlRef - fbk; errAcc += err; // kp、ki根据实际环路设计给出，这里仅占位 piOut = 0.02f * err + 0.001f * errAcc; // 限幅，防止移相角跑飞 if (piOut > 0.85f) piOut = 0.85f; if (piOut < -0.85f) piOut = -0.85f; // 移相角范围映射到TBPHS的数值范围 // EPWM2的TBPHS值除以900就是移相比，中心对齐模式下按半周期折算 pwmPhase = (Uint16)(900.0f * piOut + 900.0f); // 直接写从桥的相位寄存器，硬件在下一次同步加载点生效 EPwm2Regs.TBPHS.all = pwmPhase; }

5.4 数据交换协议：防撕裂比加锁更重要

CPU和CLA共享变量时，最常见的问题不是“数据冲突”，而是“读到一半的数据”。CLA在一个周期里可能连续写多个16位变量，CPU如果在当中时刻去读取，可能读到前一半新的、后一半旧的组合，这在控制计算里会表现为偶发的突变毛刺。

我的经验是，凡是CPU和CLA之间传递的多字节数据，都尽量拆成16位宽的变量，并且把变量更新顺序安排成“先写数据，再写一个递增的序列号”。读取方先读序列号，再读数据，读完再读一次序列号，两次一致才认为数据是完整快照。控制环路里大多数变量是16位整型或单精度浮点的低16位/高16位，用这种机制稳定性会好很多。我早期偷懒直接读32位浮点，结果在CPU侧把高16位和低16位拼反过好几次，后来统一改成上述协议，再没出过问题。

6. 调试验证与相关硬件细节

6.1 示波器统计：相位抖动从几百纳秒降到几十纳秒以内

改造完以后，我用示波器做了对比验证。把EPWM1的同步信号和副边PWM的驱动信号同时接出来，用示波器的时间间隔测量功能统计两个沿之间的时间差。CPU中断模式下，统计方差对应的峰值抖动大概在200到400纳秒之间，偶尔还能看到更大毛刺；切到CLA直接触发后，绝大多数周期的抖动落在50纳秒以内，而且没有突发毛刺。因为整个链路的每一步都是硬件事件触发，没有软件参与的随机性，波形自然稳定。

不要小看这个差距。电流环的带宽受限于采样延迟和相位裕量，采样抖动本质上是给环路注入了一个随机的相位扰动。抖动一降，我就能把PI带宽往上提，实际动态响应明显变快。

6.2 调试CLA的实用技巧：别上来就开断点

CLA任务的运行不像CPU那样容易单步跟踪。如果你在CLA代码里设断点直接调试，会遇到两种情况：要么断点命中后整个PWM链路被拉住，控制输出飞掉；要么CCS的调试状态切换太慢，根本反映不过来瞬时行为。

我的习惯是：先在CLB或者共享RAM区放几个调试变量，在任务里把关键中间量写进去，CPU侧用定时器或者串口把数据搬出来分析。CCS里也能打开CLA寄存器和内存视图，但辅助作用大于主调试手段。真要停CLA任务做单步调测，我建议先把实际控制输出断开，或者用很低的母线电压跑，避免在调试瞬间烧功率器件。项目上吃过一次亏，断点停下来后TBPHS输出停在某个任意位置，副边桥两个管子直接直通炸了保险丝，从此以后我再也不在闭环状态随便断CLA。

6.3 影响ADC采样精度的三个硬件布局细节

CLA读到的ADC值准不准，不全是代码问题，硬件布局也很关键。结合这次项目以及经验，三个PCB布局要点值得强调：

第一，模拟电源和数字电源要分离，ADC模块的参考电压引脚VREFHI、VREFLO附近必须有足够的去耦电容，且电容要靠近芯片引脚，中间不要穿过多余过孔。采样精度对参考电压噪声极其敏感，参考电压不稳，ADC结果就跟着抖。

第二，采样时钟的抖动来源要堵死。ADC的SOC触发源应该直接来自PWM时基，不要在软件里用定时器或延时函数来产生“伪采样时刻”。同时，PWM模块的时钟树、HSPCLKDIV分频也要固定下来，别让系统在运行中动态切分频。系统时钟一旦有抖动，SOC触发沿就不准，后面所有采样相位都会偏移。

第三，ADC输入通道的RC滤波电路要兼顾源阻抗和采样窗口。C2000的ADC是开关电容采样结构，输入源阻抗太大会导致采样瞬间电容电荷来不及建立。我在项目里把每个ADC输入通道前都加了一级RC低通，R取几十欧、C取几百pF到几nF的量级，同时把ACQ_PS采样窗口放宽到6个ADC时钟以上。这样既滤掉了开关噪声，又不会让采进来的值“瘪”掉。

6.4 这套“CLA离线控制架构”还能迁移到哪些场景

做完DAB移相控制后，这套“PWM触发ADC、CLA直读结果并直写PWM”的架构，我发现基本可以平移到大半个电力电子控制领域：

• 三相永磁同步电机FOC控制：电流环放到CLA，CPU只做速度环和上位机交互；
• 三相维也纳整流器、图腾柱PFC：高频电流内环放CLA，数字化平均电流模式控制；
• 多路并联DC-DC的均流控制：每一路的相位和占空比调节都可以由CLA分担；
• 有源滤波器APF：需要高速并行处理多路采样和补偿量输出，CLA的并行能力刚好匹配。

你在移植时要重点核对三件事：一是目标芯片的CLA是否支持直读ADC结果寄存器，二是目标芯片的ePWM关键寄存器是否映射到CLA可访问的外设帧，三是CLA程序空间和共享RAM的大小是否容纳得下你的算法。F28069这颗芯片属于Piccolo系列里CLA资源相对够用的型号，换成早期F2802x、F2803x时，程序RAM和数据RAM都要精打细算。

实践下来我最大的感受是，CLA不适合跑那种“偶尔算一次”的复杂算法，它就适合跑那种“每个开关周期都跑、规则固定、不容有失”的控制律。把这类任务从CPU里摘出来，CPU这边的中断压力、代码耦合度、实时性焦虑都会大幅下降。尤其是这次ADCOFFTRIM的偏差问题，让我养成了一个习惯：凡是CLA读ADC结果的方案，第一版调通后先做一次CPU/CLA读数比对再继续往下写控制逻辑。这个习惯值得保留。