[参考译文] ePWM-TB-Reset CTR=PRD

您好！

我不确定我是否理解您问题中的一些首字母缩略词。 什么是 TDB 计数？ 什么是 CTR_MAX 状态？
为什么期望 CMPA 匹配 会导致 TB CTR_MAX？

您是说、您希望使用与 CTR=CMPA 相同的操作来配置 CTR=PRD？  
TB 重置、我假设您是指 CTR=PRD、当计数器递增到周期值时将发生。 您指的是什么故障条件？
什么是 WA？

您指的是哪种24位计数器？ 时基计数器仅为16位。

您好！

如果计数一直= 0xFFFF MAX 位被置位、则最大 TBCTR 计数寄存器状态标志。 在 EWPM-A/B 生成的波形图中、TBD 用作时基周期的短接。 WA。

X49c 数据表 ePWM 类型4标记为24位 TBCTR 寄存器、(+8)表示 TBPRD 有效寄存器。 当 CMPA 低寄存器为位(31：16)时、32位宽内部总线(uint32_t)从 TBCTR 位23：0 (而非15：0)传输24位计数。  在16位总线中、没有办法获得24位计数、16位计数无法锁存24位匹配比较、除非 CMPA 在 TBCTR 侧为24位宽。 TB 模块的数据不正确、/16应为/24、然后(-8)允许16位低分辨率 TBCTR 计数到24位输入 CMPA、(-8)位(15：0)用于这些匹配、而不是31：16。

TBCTR 通过32位存储器映射值 CCS 调试进行永久溢出查看。 当 CTR=PRD (红色框)达到2500计数(重新加载)时、复位不会清除计数、但周期在计数时是准确的。 我们无法验证是否发生了复位运行计数、但可以通过 CCS 调试看到它通常超过16位。 CMPA 将24位计数器链中的高位16位锁存在32位宽的内部总线上、而不是16位宽的内部总线。 工具链通过16位寄存器存储器映射位置屏蔽 TBCTR 32位宽的总线、该位置与真实的计数值不对齐。   

         /* set comparator load mode, shadow CMP-A */
         EPWM_setCounterCompareShadowLoadMode(obj->pwmHandle[cnt],
											  EPWM_COUNTER_COMPARE_A,
											  EPWM_COMP_LOAD_ON_CNTR_PERIOD);//CTR=PRD

更糟糕的是、CMPA 被映射为高序位(31：16)、TBCTR 总线结构显示为存在位(15：0)。 因此、负载计数 TBCTR 通过32位 CMPA/CMPAHR 寄存器对乘以16位。

看起来、如果 CCSM 复位确实有效(CTR=PRD)、那么寄存器 TBCTR 中的计数绝不能超过 TB 影子加载值。 使用16位存储器映射寄存器似乎会屏蔽前台计数事件、而不是计数器比较子模块(CCSM)内的实际十进制计数器链。

还尝试 通过 EPWM1 Synchi 事件将 ACQSM TBCTL 或 GATE 置为有效、以触发 CCSM 重新加载计数重置、但也会失败。 已启用 PHSEN (EPWM1)、以允许 SW 事件和 EPWM2/3 CMPA 链接。 也许 CMPA 寄存器是作为 WA 的存储器映射位(31：16)、但在几个 PWM 周期之后/之前似乎会导致毫秒的无效。  

当达到2500个负载计数时、发出 RESET 应该重新载入脉宽 PRD 计数？

您好！

TBCTR 递增至 TBPRD 值。 它不会进行乘法、与 CMPA/HR 配置无关。

您是否尝试从 CPU 读取它而不是在调试器中查看它？  PWM 输出是否按预期生成？

您能否在发现问题的地方共享配置代码和 PWM 输出波形？
如果可能、请说明您尝试生成的 PWM 输出是什么、以及您遇到 PWM 生成问题的位置。
如果您从 C2000Ware 中提供的一些示例开始、并首先对这些配置进行实验、情况会更好。

一次调试一个步骤会更容易。  首先解决 TBCTR 问题、因为时基是 PWM 生成的基础。
您可以删除所有其他配置、只需运行 TBCTR、并通过 CPU 读取检查它是否不会永久保持在0xFFFF。

否、但它与 CMPA 在被记录的位15：0时被载入位31：16有关。 如果 TB 模块在计数中未复位或复位高电平、则占空比将超过100%、因为 CMPA 值大于 TBPRD。  TI 的某个人已根据记录的 TRM 数据表图直观地更改了工具链计数器。 同样、如果没有某种压缩写入/读取硬件、我们无法将24位放入16位管道中。 CMPA 上的 TBCTR 24位计数和100%占空比似乎表明由于高序位匹配、二进制计数值>16位而导致 TB 复位失败。   

使用向上向下计数模式来生成对称 PWM：
•如果您在零上加载 CMPA/CMPB、则使用大于或等于1的 CMPA/CMPB 值。
•如果在周期上加载 CMPA/CMPB、则使用小于或等于 TBPRD-1的 CMPA/CMPB 值。
这意味着在一个 PWM 周期内将始终有一个至少为一个 TBCLK 周期的脉冲、当非常短时、这个脉冲往往被系统忽略。

这种100%占空比条件 CMPA 是通过电机 SDK 运动无传感器 FOC 应用 V2.01至 V3.01实现的。 384µs ePWM 中断加载(MAIN_ISR)循环加载 CMPA。 生成的电流波形具有混合交流全波的直流1/2波脉冲和100%占空比170ms 周期。

 请注意、100%占空比 CH2应具有由 PI 速度控制器调节的脉冲序列50µs 周期。 它会尝试、但死区发生器输出为100%占空比、这表明 ePWM 忽略 PI 控制器来完全控制 CMPA、因为 TBCTR 值似乎仅在32位视图中超过 TBPRD。

您能解释一下为什么 CMPA 位置被从位(15：0)移动到位(31：16)的 x49c 工具链？ 事实移动 CMPA 已完成、这表明它可能会对 TB 重置失败产生不利影响、正如我多次解释的那样。 移动 CMPA 二进制位置还有其他什么原因、尤其是记录了 x49数据表位(15：0 +8)=位(23：0)？

BTW：

CCS 实时调试存储器映射集(uint_32t)的点是显示 CMPA 寄存器视图的 TBCTR 计数超过(uint16_t)工具链屏蔽。 除非在溢出计数中发生 CCSM 复位，否则我们无法停止计数器递增>TB。

在我看来、这种情况似乎解释了捕获 CH2中170ms 100%的占空比周期。 死区时间对我来说毫无意义、因为它与适当的 SVM 空间矢量调制有关。 我在 SW 中看不到任何可能导致100%占空比的时序问题、但在我看来、硬件会响铃。

您好！

我认为这种混淆可能是因为您将 CMPA：HR 视为一个32位数字、但 TBCNT 是16位数字。
对于计数器比较子模块、只有 CMPA 16位(无 HR)用于与 TBCNT 16位进行比较。
高分辨率部件可被视为分数部分。 它不会进入计数器比较的路径。
关于 SDK 运动无传感器 FOC 应用 V2.01至 V3.01的变更、我将邀请 SDK 专家参加。

然而、CMPA 寄存器不在15：0、它被移动到每个 x49c 工具链变体 CCS 项目构建的位31：16和 CMPAHR 位15：0。 我可以理解存储器映射的32位值是下一个寄存器的一部分、但这似乎是 CMPA 寄存器视图的延伸。

我在下面捕获了 CMPA 负载变化、SDK 匹配计数负载 CMPA 似乎不是问题。 很难想象170ms 的 PWM 空隙是由下一个周期 CMPA 匹配事件的计算(黄色框)引起的。 这些值不会将匹配计数负载偏离1250左右、只会产生很小的占空比变化、假定来自 PI 速度控制器。

是 CMPA 是31-16位。

您已经多次这样说、因此重复了图18-129中所示的相同胡说。 CCSM 的分析图显示了寄存器总线位 15：0 +8。 这是 CMPA 应该位于工具链 x49型号中的位置、或者更改 CCSM 数据表和 TRM 图以显示31：16 CMPA、(+8) CMPAHR。

如果我们不相信什么是技术和事实披露、那么所有逻辑扣减都将因疑难解答和奇怪的时序问题而丢失。

也许这个数字需要更新：

图中显示的 CMPA[15：0]是指：

CMPA (32位)：

-- CMPA (16位[31-16])

-- CMPAHR (8位[15-8])

寄存器 CMPA[31-16]=图表 CMPA[15：0]

正确方法如果没有总线仲裁器或多路复用、物理数据总线或地址总线不会移位16位、根据 TRM 和数据表、这两个位都不存在。 对于通过 JTAG 进行的 CCS 调试寄存器视图、我从未见过任何 TI MCU 系列中的16位数据总线移位。  

然而、当通过 SW 更新匹配计数时、实时调试 CMPA 影子值不会改变？ 我们只会看到 CMPA 影子全状态位经常切换。

我们的其他 TI PWM 模块 CCS 调试 XDS100v2调试、我们看到 CMPAA/B 寄存器更新为10Hz 匹配值。 在 CCS 实时寄存器视图中、我们只能看到 x49c 是 CMPA 位31：0 TBCTR 计数变化。 这不是在正确的 TBCTR 计数值发生匹配计数的实时芯片确认。 如果无法在10Hz 时看到 x49c 寄存器的 CCS 调试实时芯片视图的值变化、该怎么办？

我们没有在 TRM 中显示这些内部连接...

当寄存器存在数据总线31：16且没有任何支持证据时、谁会认为 CMPA 与 TBCTR 15：0匹配？ TI 不应期望任何具有微处理器总线结构知识的人员接受技术参考中未描述的不完整要点。

同样、影子值不会改变 CMPA 向下钻取通常是空白的、这使得存储器地址偏移到 TBCTR 的时间更合理、更高的整数计数31：0以某种方式延迟 TBCTR 复位。 在 EPWM1主器件零328µs 事件中、这种情况似乎更多、并且占空比 CMPA 要宽得多10µs μ s、同时在每个 μ s 加载的 Synco/Synci 从器件中 CMPA 的锁定影子值也非常不同。 328µs、x49c ePWM 模块锁定 CMPA 影子寄存器的中断服务例程是否要快速？

对于每个10Hz 器件读取、所有3个 CMPA 的值几乎是相同的并循环的。 要与 TBCTR 31：0进行比较的主/从影子值 CMPA 不会移动！ 当 CMPA 寄存器位(31：0)实际上是 TBCTR 计数值时、也许您认为它是匹配值。

TBCTR 也是16位宽。

有什么想法、为什么影子值 CMPA 不会在寄存器向下钻取 EPWM1、2、4时递增？ 似乎只有第一个 CMPA 匹配计数保持持久、并且没有加载更新。  

您是否在 CCS 中具有持续刷新？

是的、首次加载后仍然不会进行影子更新。 然而、占空比 EPWM-1大于 ePWM-2 10µs μ s、ePWM-4被载入相同的 CMPA 影子值。

再次注意捕获显示 CMPA 向下钻取(15：0)、但存储器映射区域(31：16)、仅显示更新的单元格。 有时、在空白点击存储器映射单元锁定 GUI 时展开下拉菜单、必须关闭 CCS。 寄存器和表达式视图之间的切换截断/空白之前的 CMPA 寄存器深入了解任何 EPMW、更新了 CCS 9.3。 在早期 CCS 版本中发生了寄存器单元消隐、但未启用实时芯片。

您在寄存器视图中看到的是影子寄存器。

活动寄存器是内部的、您无法查看它。

NIMA

根据打印的值和过载的值、CMPA 影子加载值似乎会锁定或干扰 EPWM1、EPWM2、EPWM4上的 CMPA。 显然、CMPA 影子卡滞、最后一个较低的值用于控制占空比。 首次钻取 CMPA 寄存器时、会显示一些低值阴影匹配、然后它们将停止更新。 不确定下面显示的值是否正是卡纸 CMPA 影子值。   

还添加了每个 CMPA 负载后的 ASM 延迟(10U)以降低回路速度。 奇怪的是、EPWM1循环10µs 比 EPWM2和 EPWM4的占空比大、但 SDK FOC 软件加载了3个 CMPA、其值完全相同。 CCS 调试寄存器视图显示3个不同的锁定影子值。  

CMPA 的影子到活动加载触发器是什么？

 通过 CMPD 计数5触发 ADC。  

    // setup the Event Trigger Selection Register (ETSEL)
    // COMPD-DN=5 or SOC_TBCTR=0
    EPWM_disableInterrupt(obj->pwmHandle[0]);
    EPWM_setADCTriggerSource(obj->pwmHandle[0],
                             EPWM_SOC_A,
							 EPWM_SOC_TBCTR_D_CMPD); //PWM_SOC_TBCTR_ZERO

    EPWM_enableADCTrigger(obj->pwmHandle[0], EPWM_SOC_A);

    // setup the Event Trigger Prescale Register (ETPS)
    if(numPWMTicksPerISRTick > 15)
    {
        EPWM_setInterruptEventCount(obj->pwmHandle[0], 15);
        EPWM_setADCTriggerEventPrescale(obj->pwmHandle[0], EPWM_SOC_A, 15);
    }
    else if(numPWMTicksPerISRTick < 1)
    {
        EPWM_setInterruptEventCount(obj->pwmHandle[0], 1);
        EPWM_setADCTriggerEventPrescale(obj->pwmHandle[0], EPWM_SOC_A, 1);
    }
    else
    {
        EPWM_setInterruptEventCount(obj->pwmHandle[0], numPWMTicksPerISRTick);
        EPWM_setADCTriggerEventPrescale(obj->pwmHandle[0],
                                        EPWM_SOC_A,
                                        numPWMTicksPerISRTick);
    }

    // setup the Event Trigger Clear Register (ETCLR)
    EPWM_clearEventTriggerInterruptFlag(obj->pwmHandle[0]);
    EPWM_clearADCTriggerFlag(obj->pwmHandle[0], EPWM_SOC_A);
    
    // setup the Event Trigger Clear Register (ETCLR)
    EPWM_clearEventTriggerInterruptFlag(obj->pwmHandle[0]);
    EPWM_clearADCTriggerFlag(obj->pwmHandle[0], EPWM_SOC_A);

    // since the PWM is configured as an up/down counter, the period register is
    // set to one-half of the desired PWM period
    // Note: Shadow of TB period register is configured above.
    EPWM_setTimeBasePeriod(obj->pwmHandle[0], halfPeriod_cycles); //1250
    EPWM_setTimeBasePeriod(obj->pwmHandle[1], halfPeriod_cycles); //1250
    EPWM_setTimeBasePeriod(obj->pwmHandle[2], halfPeriod_cycles); //1250

    /* Set the shadow period load mode to occur on counter zero flag */
    EPWM_selectPeriodLoadEvent(obj->pwmHandle[0], EPWM_SHADOW_LOAD_MODE_COUNTER_ZERO);
    EPWM_selectPeriodLoadEvent(obj->pwmHandle[1], EPWM_SHADOW_LOAD_MODE_COUNTER_ZERO);
    EPWM_selectPeriodLoadEvent(obj->pwmHandle[2], EPWM_SHADOW_LOAD_MODE_COUNTER_ZERO);

    // write the PWM data value for ADC trigger 10ns SYSCLK 50ns
    EPWM_setCounterCompareValue(obj->pwmHandle[0],
								EPWM_COUNTER_COMPARE_D, //EPWM_COUNTER_COMPARE_C
                                5);

巧合 的是、81、936、384 =(0x04E2.4000) CMPA 影子匹配值在不应该出现时添加了15：0字(0x4000)。 通过 HWREG (15：0 +1U)将 CMPA 数据移动到位(31：16)会以某种方式添加(0x4000)。 我看到它不时出现在存储器地址空间15：0中、但从未想过它是持久的。 这揭示了32位整数读取存储器地址空间、其中16位读取屏蔽了较低的字15：0、我们从未看到0x4000部分。 它似乎不是下一个串行字 ASCII 打印的一部分  

此外、某些 TI 芯片系列的某些寄存器在 C++ B2B 写入方面存在问题。 数据表 TM4C1294警告某些 WR1C 寄存器可能需要 B2B 写入之间的延迟或写入后执行读取操作、以避免出现问题。

调用 CMPA 影子加载事件的中断处理程序的抽取时间测量为328µs μ s、进入退出。 看似不是很快的思维指令解码和 R/W 累加器操作发生得快得多、对于100MHz SYSCLK、通常为几微秒。     

说明资源路径位置
当前优化/调试设置：-opt_level=2 -opt_for_speed=2 -g is07_speed_control 属性

我还在 CMPA 写入之前添加了影子满标志的代码检查、并获得了一些要滚动的缓冲写入、然后它再次锁定。 最奇怪的部分是 EPWM1、它被配置为计数中断、然后使用 ADC 中断源作为处理程序。 Instaspin 的这种中断方法被记录为使用 PWM 中断时序、而不是 ADC。

EPWM1中断因未知原因而禁用、但部分配置为对中断进行计数、就像 EPWM1具有 ADC 中断输入一样。  

我尝试使用通过 CCS 编译的 ARM 代码推送2级选项、全局选项确实会导致中断和 PWM 控制等问题。

COF 库包含在 Flashlib 调试文件项目中。 如果降低 COF 选项级别1对调试寄存器下拉列表没有影响、我稍后可以尝试 eabi SDK 项目。

您是否将全局变量标记为"volatile"？

否 MOST 是程序间中断静态变量。 根据 IDE 的寄存器( MSVS) 、在中断期间保留变量值必须分配静态。 为什么 CCS 组认为非易失性变量是静态变量、这超出了中断矢量类型变量的 RFC C++定义。  

无论如何、这个 CMPA 匹配计数似乎是针对完美风暴而组合的几个问题、而 CCS 实时器件寄存器更新拒绝轮询2WD。 也许四轮驱动 JTAG 探头会显示更多详细信息？

尝试4WD JTAG。

遗憾的是、LaunchPad 仅通过板载 XDS110 USB 提供两轮驱动。

SOC 中断事件的 EPWM1 ADC 触发器似乎可以过运行 CMPD 门控制逻辑？ EPWM1具有更多的随机死区锁 CMPA、比 EPWM2、EPMW3具有10µs μ s 更宽的占空比、也不具有通过 Synci/Synco 时序实现的同步占空比。  

SDK 为 EPWM1配置了 ADC 触发计数 CMPD (5)或100MHz PWMCLK 的50ns SOC 计数事件。 328µs GPIO 测试、SOC INT 处理程序的宽度、为什么 CMPD 需要50ns 触发计数？

50µs 以为 CMPD 配置了 μ s 计数？  当某些 ePWM 模块比较器针对 高电平有效输出配置了更大的匹配计数时、它们通过极低的匹配计数被锁存。 也许由于 CMPD 上的中断风暴、整个 PWM 模块难以同步主/从？

您有 CMPD 在每个周期生成的 ePWM 中断吗？

再看一下 EPWM_SOC_TBCTRD_CMPD、甚至 TBCTR_PERIOD、会产生125µs μ s 的 ADC 触发 EOC 中断。 理想情况下、TBCTR 始终是一个固定的25µs μ s 周期。 如果 CTR=TBCTR 未被复位、CMPD 匹配计数将如何反应、抓住吸管。

我错误地认为 PWMCLK 或 SYSCLK 各为(10ns)、50ns 中断不正确或是错误的。 t

当 CMPA 匹配值增加100倍时、CMPD 匹配计数(5)仍然非常低。 还发生了 CMPD 影子加载事件、注意到 CMPA 加载事件没有变化。 同样有问题的部分是、占空比不会在 EPWM1、2、4 (用于)回路负载 CMPA 之间均匀分布。

注意 TBPRD 寄存器的 B2B 快速读取是 for 循环的一部分。

    for(pwmCnt=0;pwmCnt<3;pwmCnt++)
    {
    
        // compute the value
        period = (float32_t)(EPWM_getTimeBasePeriod(obj->pwmHandle[pwmCnt]));
        
        // do period calcualtions
    
        int16_t pwmValue  = (int16_t)(V_sat_dc_pu * period);
        
        /* EPMWx CTRL shadow load CMPA empty status */
        if (EPWM_getCounterCompareShadowStatus(obj->pwmHandle[pwmCnt],
											   EPWM_COUNTER_COMPARE_A) == false)
        {

        	        // write the PWM data value
        			EPWM_setCounterCompareValue(obj->pwmHandle[pwmCnt],
                                     EPWM_COUNTER_COMPARE_A,
                                     pwmValue);

        }

您是否考虑过每次使用 DMA 将数据移出 ADC 而不是中断？

这远远超出了针对 FOC 电机控制方案的 Instaspin 抽取解释。 快速估算器要求的范围内。

但是、确实尝试将 EPWM2、EPWM4链接到 EPWM1主器件以进行 CMPA 影子加载、并针对循环代码加载事件删除、仅主器件 CMPA 加载。  它以未知原因拒绝跑步。 尽管18.4.5解释了以这种方式同时链接可变频率阴影负载(CTR=0、PRD=0)。 CMPA 在读取 PRD 寄存器后似乎不会加载、它会在原始模式下锁定死区。

从技术上讲、电流斜坡(赫兹/秒)、根据图18-11？、链接对于主/从的 Synci/Synco 事件应该非常有效   

链接不起作用  会确认向每个 CMPA 写入3个唯一值。  这3个值被数组缓冲、以便每次进行一个循环计数。 然而、将 CMPA 影子加载事件从主器件链接到一起似乎是个好主意、但实际匹配数据不是这样。 从器件 Synci/Synco 似乎是 MPer 零计数 、但从器件应将影子加载事件保持在 ePWM 之间？

没有 FCL 代码可以帮助将 ADC 触发器和中断分离 为专用处理程序。  

您如何确认链接不起作用？

有非常小的感应相电流是通过连接产生的。 文本仅提及影子值、导致假设它们变为全局更新、下面的代码也失败。 也许全局配置应该包括3个 ePWM 影子全局更新？  

       /* Enable global register loads via shadow registers */
        EPWM_enableGlobalLoad(obj->pwmHandle[0]);
        /* Set global shadow register loads trigger on Synci or count zero */
        EPWM_setGlobalLoadTrigger(obj->pwmHandle[0], EPWM_GL_LOAD_PULSE_SYNC_OR_CNTR_ZERO);
        /* enable global loads for these specified register */
        EPWM_enableGlobalLoadRegisters(obj->pwmHandle[0], EPWM_GL_REGISTER_CMPA_CMPAHR);

只将 CMPA 值右键、而不是影子加载事件触发器。 再次测试了 CMPA 的全局更新触发器、但它不能用于上述代码 EPWM1、2、4。  

链接和全局更新*似乎不起作用。 也许无法使用具有全局和链接的主/从(Cnt0/Synci/Synco)？

否则，它们都可以*正常工作，但 CMPA 更新值在驱动相电流时效率会降低。 该条件(如果为 true)表示周围 Instaspin 代码出现某种旋转角度计算错误？