[参考译文] TM4C1294KCPDT：GPTM 重新加载 INT 优先级串

您好 BP101、

您是否检查了定时器与 PWM 的中断优先级？ 如果 PWM 具有更高的优先级、则计时器将一直等待 PWM 中断解决、您看到的行为将非常有意义。 它毕竟是单核 MCU、因此如果 PWM 具有更高的优先级、由于 PWM 的原因、计时器可能无法在精确的1秒间隔内执行。

您好、Ralph、

[引用 USER="Ralph Jacobi"]、则计时器将一直等待 PWM 中断解决、您看到的行为将会非常有意义[/quot]

同样 ， 当 NVIC 运行 8.3ns 时，GPTM 加载间隔大于100ms 的增益不应产生与 CPU 内核速度相同的结果。 这是另一个问题！ 它不是100ns 增益、而是>100ms 锁定到 PWM0中断速度。 所有 NVIC 终端都必须共享 CPU 时间 任何单个外设都无法实现优先级片、尤其是在 NVIC 尾链中。 当谈到 NVIC 尾链 INT 端时、您必须意识到100毫秒就像大峡谷一样。  PWM0 零计数中断和 ADC 负载计数触发器是边沿脉冲生成的中断。

也许不 考虑 AHB 总线仲裁、或者 GPTM 重新加载间隔只是 增加 、因为 它不应超过>100ms 的中断陷阱。 AHB 仲裁的中断时序是关键 、但我们不知道它如何  或是否影响较低的 NVIC 优先级 或 GPTM 重新加载值。 逻辑 上来说、NVIC 绝不能将实时时钟属性直接强加在任何单 个外设上。 我的观点包括认为100ms GPTM 不必要的间隔负载值 增长。  负载值似乎会随着 NVIC 优先级交互尚未详细说明而增加、从而导致任何此类 GPTM 行为。   

μ■中断(IRQ)。 中断或 IRQ 是一个异常、由外设发出信号、或者由软件请求生成、并通过 NVIC (优先级)提供。 所有中断与指令执行异步。 在系统中、外设使用中断与处理器进行通信。 第116页的列出了 TM4C1294KCPDT 控制器上的中断。

3.1.2.1电平敏感和脉冲中断

处理器支持电平触发中断和脉冲触发中断。 脉冲中断也被描述为边沿触发中断。 电平敏感中断保持有效、直到外设使中断信号无效。 通常情况下会发生这种情况、因为 ISR 会访问外设、导致其清除中断请求。 脉冲中断是在处理器时钟的上升沿同步采样的中断信号。 为了确保 NVIC 检测到中断、外设必须使中断信号有效至少一个时钟周期、在此期间 NVIC 检测到脉冲并锁存中断。 当处理器进入 ISR 时，它会自动清除中断的挂起状态(更多信息，参见第136页的“中断的硬件和软件控制”)。 对于电平式中断、如果在处理器从 ISR 返回之前该信号未失效、则该中断将再次挂起、处理器必须再次执行其 ISR。 因此、外设可以保持中断信号的有效状态、直到它不再需要处理。

不会 、因为有多个其他优先级分组和 其他启用 GPTM OneShot 计时  器的上下文保持恒定、在80us PWM 中断窗口内小于100ns 的杂散时间。

在   CCP-0B 边沿触发中断 时启用 TM3A OneShot   从 NVIC 优先级分组 同步定时器之外的中断处理程序上下文加载 TM3A 负载更新。 TM3负载计数更新看起来既不是立即更新 、也不是在下一个超时事件发生。 从    下面的调用方语法中看、什么情况会更新模式位 Tivaware 为 OneShot GPTM 设置是不明显的。 请注意、PWM 中断在所有 Tivaware GPTM 配置中保持启用、我们不需要添加任何更改。  此外、未知的 Tivaware Tamr TAILD 位8设置可能会增加意外 的混乱。  Tivaware TimerConfiure() 文本不会试图解释 任何人如何 定义 TAILD 位字段控制函数或对其进行控制定义。 如果下一个周期被延迟该怎么办？TAILD 位如何进入 TM3A 中断处理程序内的加载间隔？

MAP_IntPriorityGroupingSet (4)；

MAP_IntPrioritySet (INT_TIMER3A、0x40)；//Fan OneShot Taco Tick
MAP_IntPrioritySet (INT_TIMER0B、0x40)；//Fan Taco Edge Counter
MAP_IntPrioritySet (INT_PWM0_0、0x20)；/PWM Gen Load

/*********
* GPTM-3：32位宽 OneShot 倒计时器配置
*用于生成60Hz 风扇 Taco 节拍间隔。
(三 /
/*设置 GPTM-3A 时钟源120MHz 或16MHz */
MAP_TimerClockSourceSet (TIMER3_base、TIMER_CLOCK _PIOSC)；
//为 OneShot 设置 GPTM－3A 下一次超时。 *
MAP_TimerConfigure (TIMER3_base、TIMER_CFG_ONE_SHOT)；

//计时器在下一次超时后加载 TAILR。 *
HWREG (TIMER3_base + TIMER_O_TAMR)|= TIMER_TAMR_TAILD；

/*加载 GPTM3A PIOSC：60Hz/16.6ms (0xF42400)*/
MAP_TimerLoadSet (TIMER3_base、TIMER_A、0xF42400)；
/*启用定时器超时时中断。 *
MAP_TimerIntEnable (TIMER3_base、TIMER_TINA_TIMEOUT)；
/*为 EDGE INT 周期启用220Hz/30Hz OneShot 时钟计数*/
MAP_TimerEnable (TIMER3_base、TIMER_A)；
/*在控制器中注册全局中断*/
TimerIntRegister (TIMER3_base、TIMER_A、FANSpeedTickHandler)；
MAP_IntEnable (INT_TIMER3A)；

/*同步 CCP1和60赫兹节拍定时器
*阻止两个计数器之间的时钟漂移。
* GPTM-3A：OneShot 无超时操作。 GPTM-0B：
*向下边沿计数 ILR=超时操作的计数值*/
MAP_TimerSynchronize (TIMER0_BASE、TIMER_0B_SYNC | TIMER_3A_SYNC)；


void

FanSpeedTickHandler (void)
｛
uint32_t ui32TBVEdgeCount；
uint32_t ui32TBILREdgeCount；

/*清除周期性60Hz 超时中断。*/
MAP_TimerIntClear (TIMER3_base、TIMER_TINA_TIMEOUT)；
/*禁用滴答中断*/
MAP_IntDisable (INT_TIMER3A)；

/*在递减计数模式下，输入的当前计数
*可以通过减去 GPTMTBR 来获取事件
从 GPTMTBPR (预分频)组成的值中减去*或 GPTMTBV
*和 GPTMTBILR 寄存器组合。 *

/*获取 GPTMTBV 自由运行计数值。 *
ui32TBVEdgeCount = HWREG (TIMER0_BASE + TIMER_O_TBV)；
/*获取 GPTMTBILR 开始计数加载值、超时事件的上限*/
ui32TBILREdgeCount = HWREG (TIMER0_BASE + TIMER_O_TBILR)；
/*确定 INT 和 ISR 入口之间计数的累积边沿。 *
ui32EdgeCount = ui32TBILREdgeCount - ui32TBVEdgeCount；

/*重新加载 GPTM3A PIOSC：60Hz/16.6ms (0xF42400)*/
HWREG (TIMER3_base + TIMER_O_TAILR)= 0xF42400；

/*报告风扇转速*/
ReportSpeed()；

/*启用 tick interrutp */
MAP_IntEnable (INT_TIMER3A)；
/*启用边缘计数 interrutp */
MAP_IntEnable (INT_TIMER0B)；

｝

您好、Ralph、

[引用 USER="Ralph Jacobi"]我仍然强烈怀疑您在 PWM 中断处理程序中花费了~100ms [/引用]

由于 PWM 中断 发生 的间隔@80us、并且在    1ms 的间隔内只通过 SW 中断启动1个分支、因此不可能实现这种情况。 每80us 可为较低优先级的 TM3A 中断提供一次服务 、同时为在类似中断上下文中运行的另外6个 GPTM 提供服务。  如 GPTM0-A PWM 占空比更新 了风扇速度控制。 GPTM0-B 是边沿 计数(0xd2) 匹配 中断、 在1秒的间隔内启用 OneShot TM3A。  

如果一秒时间不足以让 NVIC 为 TM3A 中断处理程序提供服务 、则表明确实  发生了错误。  有时、TM3A 会有更多的关闭 周期 、但 导通 周期延迟(负载计数)对于保持 RPM 数字读数至关重要。   由于 TM3A 中断似乎是 一个边沿触发事件 、应该与 TIAR 超时重合、但 看起来 不会重合。  

它 是单次触发定时器在   特定时间间隔内触发中断的整个点。 示波器 GPIO 测试 显示导通时间 (负载计数)长于65.5ns*16M。 如果 PIOSC 时钟源漂移 、 这也会导致 TM3A 连续 一秒发生故障。 良好的示例 可能会证明 SYSCLK 作为  TM3A 的时钟源 在中断周期之间甚至会产生大于1秒的电压、但仅当 PMW0正在运行时才会产生。

也许 Tivaware 误配置4x4优先 级分组、NVIC 也可能 无法正确配置？       7 个优先级分组中配置了23个中断、例如0x0、0x20、0x40、0x60、 3 位优先级组(bxxx)中的0x80、0x0A、0xE0、1个子优先级组、0x4二进制拆分。 虽然存在中断并且为其它被启用的外设模式配置了优先级、但是并不是所有中断都是有效的。

Map_IntPriorityGroupingSet (4)； 

您好、Ralph、

[引用 USER="Ralph Jacobi"]除了您陷入更高优先级 ISR 的时间过长外，我们没有人能给出解释

这正是发生的情况，因为优先级分组甚至未 能优先于 其他 较低优先 级组的优先级。   我通过在清除后禁用 TM0B 中断以及  在 TM3A OneShot 清除后禁用链中断来证明失败。 (以上代码)。   无论   设置何种一次性加载值、只有在退出 TM3A 处理程序之前才重新启用两个定时器 INT。 注意：如果  在进入中断处理程序后中断未被禁用、则置1的 TM3A TALID 位(在下一次超时后加载新计数)似乎不起作用。 另外一个线索 OneShot 加载值(TIALR)正在下一个时钟周期重新加载、无论中断是否被挂起 。 但 仅当 PWM0高优先级中断挂起80us 周期 TM3A 中断的作用非常不受限制。

接下来发生的情况 当调用 PWM0更高优先级组时、较低优先级组(TM0B/TM3A)在  较高80us PWM 停止挂起前不能再抢占较高优先级组。 这不是 NVIC 优先级链接的工作方式、请自行阅读。 另请注意、禁用 TM3A 中断 看门狗后 、MCU 将随机对任何尝试重新启用 TM0B 边沿计数的尝试进行上电复位、这些尝试存在于 同一个较低优先级组中。   

也就是说、表3-9 (第171页)显示了 REG58优先级组字段位(10：8)和 Tivaware 调用集0x300 (高于 POST)、每个 defies 表(第一行/列) 0x0-0x4。  似乎可以  认为0x0-0x4意味 着可以  存在5个主要组 (0-4)。 根据位字段的拆分 [7：5] 高三 位、  在每个优先级组下可能有8个子优先级(INT)？ 无论如何  、对于[7：5]来说、0xE00似乎更合适、而不是0x300。 该表在与由 REG-58 (10：8)定义的位字段的关系上非常混乱。  表3-9未能解释(bxxx。) 以及(b)如何表示二进制拆分(10：8)并最终 更像(xxxb)。  或 [7：5] 在 REG58二进制字段位(10：8)中定义。  在数据表中、REG58位字段10：8十六进制代码在哪里解释或列出以定义[7：5]拆分？

 表3-9似乎 表示3位拆分仅支持 来自 ARM Cortex M4v7基准的8个优先级表 B1-6。 问题是 鼠标悬停(宏) 始终 指示[4]无论值被设定为什么值、IntPriorityGroupingSet (n)也是 Tivaware 调用定义 了二进制拆分8位字段 (REG58) 、对于   表 B1-6中显示的每个特定分组、似乎都没有被设定为最高优先级。

B3.4.1 NVIC 操作

•通过更新32位寄存器(每个寄存器支持四个中断)中的一个8位字段、NVIC 中断被优先化。 优先级根据 ARMv7-M 优先级方案进行维护。

支持的最大优先级值

支持的优先级值的数量是在8到256范围内由实现定义的2的幂、并且支持的最小优先级值始终为0。 所有优先级值字段都是8位的、如果一个执行支持少于256个优先级、那么这些字段的低序位是 RAZ。  

表 B1-6优先级位数与最大优先级值之间的关系

优先级位数         优先级数     最大优先级值 A

3                                             8                             0b11100000 = 224 (0xE0)

4                                             16                          0b11110000 = 240 (0xF0)

5                                             32                           0b11111000 = 248 (0xf8)

6                                             64                           0b11111100 = 252 (0xFC)

7                                             128                        0b111110 = 254 (0xFE)

8                                             256                         0b11111111 = 255 (0xFF)

a：该值始终对应于可能的最低异常优先级。

BTW：为了使表3-9在(下面的数组)中具有任何意义、可以使用第一行(0x0-0x4)信息编码器(7_1、6_2、5_3、4_4、3_5)来设置5个优先级分组、而不仅仅是一个(4_4)。 否则、表3-9的第一列(0x5、0x6、0x7)分别与数组(2_6、1_6、0_8)相关。   数据表文本中未介绍 NVIC 占先优先级行为的二进制拆分中的多个分组。 较低的组似乎具有最高优先级的组。

也许我们不应简单 地将所有 INT 源组合到优先级组 (4_4)中、因为 INT 抢占 可能会被取消处理？  相反、将 INT 挂起层次结构从最重要的外设分配 到 多 个(总共5个优先级组)分组中的最小值、而不是如表3-9中所示的8。 这样做 可能会受益于外设中断处理程序之间的高速尾链。  

这是优先级分组编码和 抢占优先级位数之间的映射。

静态常量 uint32_t g_pui32Priority []=

｛

  NVIC_APINT_PRIGROUP_0_8、NVIC_APINT_PRIGROUP_1_7、NVIC_APINT_PRIGROUP_2_6、

  NVIC_APINT_PRIGROUP_3_5、NVIC_APINT_PRIGROUP_4_4、NVIC_APINT_PRIGROUP_5_3、

  NVIC_APINT_PRIGROUP_6_2、NVIC_APINT_PRIGROUP_7_1

}；

在上述 ARM 系统指南中修改了 POST、以指示二进制拆分 REG58是任何单个分组中的最高十六进制值。

此外、数据表(REG58)中未显示上述文章的注释(INTA、INTB、INTC、INTD)似乎推断了应参考下面的 NVIC 表、为特定分组分配任何中断。

调用 IntPrioEntryGroupingSet()时，优先级分组二进制拆分(REG58)似乎不完整。   当  SS2 通过 优先级组(0x40)的 GPIO 触发 采样信号产生 的组(0x20)时、低优先级组的中断处理程序必须被延迟 、这样应用程序将 延迟窗口作为低优先级组中的 NVIC 错误地取代活动挂起、这似乎与高 NVIC 延迟(>μ 400µs)相关。 接地端不存在任何方法 TM4C1294 NVIC 应该被预先成形、这样  奇怪的情况下、多个外设等待有源边沿 或者来自 Tivaware 优先级中断分组的脉冲中断。   

[引用 USER="BP101]PWM0高优先级组 被调用后、低优先级组(TM0B/TM3A)在  80us 的 高 PWM 停止挂起之前不再优先于高优先级组。 这不是 NVIC 优先级链接的工作方式、请自行阅读。[/引述]

我真的不明白这一点、您能否提供说明优先级较低的组应该能够取代优先级较高的组的文档和页码？ 或者、您可能对其措辞有误？

您不必花时间研究 NVIC 优先级来证明您的系统行为、而是不花一些时间测试代码从 PWM ISR 进入到 ISR 退出所需的时间(只有在 ISR 中的所有被调用函数都被解析时才会发生)。 因为在退出 PWM ISR 之前、不会为较低优先级的中断提供服务。 此问题可能比您尝试使其看起来简单得多。

您好、Ralph、

[引用用户="Ralph Jacobi"])。 因为在退出 PWM ISR 之前、不会为较低优先级的中断提供服务。 此问题可能比您尝试使其看起来简单得多。

PWM 生成代码完全由中断优先级驱动、它 仅在 A 部分被调用函数中 用于开始。 然后 NVIC 通过优先处理所有其他中断源来接管。 整个应用程序由 NVIC 优先级中断驱动。 二进制拆分 Tivaware 使 REG58不像 ARM Cortex M4v7手册所示。  校验禁用 TM3A/TM0B 中断 表示 NVIC 不会交错 或优先处理其他 相对于 较高优先级的低优先级中断源。  配置的较慢的 TM3A (1.1ms - 16.8ms) 边沿中断应是相对于 80us PWM GEN0脉冲中断的无缝周期。   

[引用 user="Ralph Jacobi">我真的不明白这句话、您能否提供文档和第#页、这意味着优先级较低的组应该能够取代优先级较高的组？ 或者、您可能对其措辞有误？[/引述]

NVIC 支持以下特性：

•NVIC 中断可通过写相应的中断设置使能或中断清除使能寄存器位域来使能和禁用。 这些寄存器使用写1到启用和写1到清除策略、这两个寄存器读回相应(32)中断的当前启用状态。 当中断被禁用时、中断有效会导致中断挂起、但中断不能激活。 如果中断在禁用时处于活动状态、它将保持活动状态、直到通过复位或异常返回将其清除。 清零 ENABLE 位可防止相关中断的任何新激活。

在   INT 处理程序期间禁用 GPTM 中断并重新启用它们 证明 了当    PWM0 GEN0中断向量发生时、NVIC 优先级处理不会保持一致。 较慢的计时器30Hz-890Hz 应在 几微秒内保持无缝间隔、而不是几百毫秒、或在禁用时完全不保持无缝间隔。 在  这个测试场景中、定时器中断看起来保持有效、但是永远不会再次挤占 PWM0 GEN0的更高优先级。  中断处理的行为 使其看起来好像 REG58中的二进制拆分0x300、0x400和任何其他位并没有 真正得到 NVIC 的确认。

同样、较慢的计时器间隔中断 应在 PWM0 GEN0的脉冲中断源中保持无缝、但不应如此。 在这种情况下、NVIC 无法控制无缝原始中断周期、这是不对的！  在  这个非常小的中断驱动应用中、在所有 MCU 时钟之后、150 DMIPS 和120MHz M4 Cortex 时钟速率环绕 NVIC。 ADC 采样延迟 CADC (>400us)是 另一个示例 、说明主动优先级脉冲中断的抢占不应该是什么样子。   唯一一个原因是 PWM0 触发的 ADC0中断 不能保持同步 、同样也有优先级分组 NVIC 问题的气味。   

您好 BP101、

我想我知道你在哪里有误解。 您说：

[引用 user="BP101"] PWM 生成代码完全是由中断优先级驱动的，它 只是在 A 部分中调用函数 ，只是为了开始。

您可能不会意识到、如果调用该函数、您将保持在 ISR 中、直到该函数解析。 因此、在函数完成之前、您不会离开 PWM 中断、然后当您最终退出 ISR 时、您可以为计时器提供服务。

请从一开始就运行我指示的测试。 在您进行测试并提供结果之前、我不会花更多的时间向您解释这个主题、因为我很清楚发生了什么、所以您需要自己观察这个问题才能理解这一点、 我无法用比我更好的方式来解释它。

您好、Ralph、

[引用 USER="Ralph Jacobi">您可能不会意识到的是、如果您调用该函数、您将在该函数解析之前保留在 ISR 中。 因此、在函数完成之前、您不会退出 PWM 中断、然后当您最终退出 ISR 时、您可以为计时器提供服务[/报价]

过去 已通过 GPIO 端口 探针确认80us NVIC 间隔退出；   在80us PWM0中断处理程序内也会触发1ms 节拍 SW 中断。  如果 PWM0没有退出并且在示波器探针上不产生1ms 的间隔、GPIO 引脚将保持高电平。

您可能会误解 PWM0中断处理程序 每隔80us 就会退出一次 (在进入时被清除两次)。 因此  、从 NVIC 处理的角度来看、零计数中断不会保持永久挂起/活动状态。 我说 TM3A 超时仅在 PWM0处于活动状态时生效是错误的。 PWM0中断始终处于激活状态(空闲/运行)、 仅门 PWMENABLE (运行状态) 加载 GPTM4A OneShot (400us)触发 ADC0 SS2样本转换 、并立即存在这种非常快速的调用。

因此 SS2 (Int32)会将 INT 优先级挂起 到较 慢的边沿计数(TM0B)以上、OneShot (TM3A)定时器、它们都存在于     TM3A (INT51)和 TM0B (INT36)的同一优先级分组(0x40)中。    (3：5、4：4) splits 的子优先级1  应通过中断向量 编号来确定挂起/活动的顺序。   当 SS2或 TM4A 在 PWMENABLE (REG3)的 PMW0运行状态活动内处于活动状态时、子优先级排序不起作用。 我没有提到 SS2、因为它在 0x40分组顺序内具有最高的子优先级。

数据表显示 优先级分组内的优先级顺序向下流到子优先级中断级别。 同样、优先级组内的子优先级中断处理不起作用 、正如数据表中所述。  我是否误解 了挂起/活动状态的副优先级 NVIC 处理依赖于具有相同优先级分组的中断矢量编号？

您好、Ralph、

然而 、当接地 PL5 CCP1输入 时、外部引脚的噪声不会解释、当  PWMENABLE 周期的 GPTM1A OneShot 中断时、这种情况仍然会显著切换。  GPIOPinConfigure()中使用的多路复用器解码来自(PIN_mux.h)，用于  通过(GPIO_c)和 TM4C1294中本应不存在的寄存器(GPIO_O_CTRL)为端口选择 AHB 与 APB 槽，这是令人震惊的。  请注意、GPTM1A 有两 个 CCP 管脚 、就应用而言、这些管脚并未分配给 GPIO 端口控制。 但是 、如果配置 SW 执行的操作在  CCS 调试过程中模糊不清、  则在发生混乱之前不会发现任何实体。  

Amit 回复后 (以下链接)似乎确认 GPIO_O_CTRL 仍然存在、但 已从 数据表中删除。

https://e2e.ti.com/support/microcontrollers/other/f/908/p/374119/1316366 

https://e2e.ti.com/support/microcontrollers/other/f/908/p/374119/1316370#1316370

对于   低端口 APB 孔径解码(gpio.c)、较低的 GPIO 端口 A-H 保持不变、APB 仍然存在(图1-1)架构方框图。  因此 、用于边沿计数  的 GPTM0B CCP1端口(AHB_PL5)可能与 GPTM1A OneShot CCP0 (未配置)重叠。  在 较慢的 GPTM1A 重新加载 事件中、边沿计数频率 GPTM0B 的速度变化并不明显。  PL5同样接地、因此 CCP1上的边沿计数 发生 在 GPIO 数字多路复用器内部。    在这 一可能的交叉链接解码问题中测试的5个 TM4C1294KCPDT 中的 CCP 之间似乎存在内部链路。

 GPIO 端口控制寄存 器中似乎出现交叉链接解码、在低频 GPTM 节拍率下不会如此明显。  通过 计算器运行数学 GPIOPinConfigure()口径算法一次 ，发现  某些 AHB 高端口(J-S ) pin_mux.h 解码重叠的情况可能存在。  此外 、端口多路信号分离器算法的下半部分 在  非操作中产生 Qword 溢出、这是不好的。