[参考译文] MSPM0G3507：检测16位计时器上溢

您好、 Stanley

这些信息无效、 请删除以避免进一步误解...

此致、

Helic

您好、

抱歉、我的错是 MSPM0时间似乎没有溢出中断。

此致、

Helic

您好 Bruce

感谢您的回复、我使用了向上计数模式(TIMG8)并启用了零& ccr0 (compare)& ccr1 (capture)中断。

我的计时器是自由运行的、它会在一个进程中产生几个溢出。

在我理想的情况下:当我捕获几个计数(也许<10),然后检查溢出标志,如果标志=1

我会知道计时器只是有溢出、此数据(捕获值)需要进行特殊处理。

但在 实际情况下、当我同时捕获65519并检测到溢出标志(P1)时、我很困惑、

当前的 CTR 值也很奇怪(P2)。

您好、 Stanley

我方面的一个提示：

请注意 TIMER_ERR_01

https://www.ti.com/lit/pdf/slaz742

此致、

Helic

您好、Helic

谢谢你的答复,我认为我的捕获值是正确的,我只是想知道  

如果计时器在捕获小于10的值时刚刚溢出。

您好、 Stanley

对于实时调试、请尝试使用设置/清除 GPIO 进行调试。

在逻辑分析仪中、更容易确认 GPIO、计时器中断和溢出之间的序列。

我不确定在__BKPT (0)和零/加载中断之间是否有一些延迟。

此致、

Helic

1)计时器的节拍率是多少(即预分频)?  如果它是/1、那么在捕获和中断(MIS)提取之间经过(65536-65519)=17个 CPU CLKS (MCLK)的情况下、我就不会感到意外。 这是非常严格的时序。

2)计时器(正常)在断点期间持续运行、因此您不能真正信任调试器获取的 CTR 值。 另请参阅：

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1490313/mspm0l1306-how-to-stop-timer-counter-while-cpu-execution-is-halted-for-debug-when-a-breakpoint-is-hit-in-mspm0l1306

[编辑：澄清了延迟差距。]

您好 Bruce

感谢您的回复、我的计时器时钟是10MHz、MCLK=MCLK 40MHz、我可以理解计时器是否继续在调试中运行、

但我仍然感到困惑、因为在第718行中设置的断点 、如果程序在断点中停止、则为捕获值

和 overflow_check 不应受计时器运行的影响、结果为 捕获值=65519和 overflow_check=1。

我不知道为什么会得到这个结果、在我看来我应该得到 capture value=65519和 overflow_check=0或者

Capture value=10且 overflow_check=1。

您好 Bruce

感谢您的回复、我最近测试并寻找解决方案、请参阅下面的说明。

1.这个项目是一个双斜率的 ADC、我使用溢出作为(a)一种将计时范围(溢出计数)扩展到放电计数计算的方法、在放电过程中计时器将产生数次时间溢出、p2是我的 ADC_count 公式、监视捕获部分中的数据构建。

2. p1是4次监测数据,你可以在第三次看到我得到了错误的 adc_count,capture_count=65534但得到了新的 overflow_count(5 ),在前一个项目(msp430)我依靠 taiFG 来消除令人沮丧(new overflow_count),但在这个项目中我不能使用 DL_Timer_getEnabledInterruptStatus ()来检测溢出,即使我把这一行输入了第一个溢出(P3)

3.最终我用过滤技术来消除这个0xFFFF。

在 P3中、您使用 DL_TimerG_getPendingInterrupt 函数。

此函数将读取 IIDX 寄存器、通过读取 IIDX、中断将通过读取操作自动清除。

您需要将 overflow_check 放在 switch 的第一行、请在计时器处理程序的第一行阅读它。

您好、Helic

感谢您的重放,我将 DL_Timer_getEnabledInterruptStatus ()从交换机内部移动到交换机外部,我仍然无法获得

溢出指示。

此地址中的参数 overflow_check 更新、并分配给 DL_TIMER_IIDX_CC1_UP (捕获中断)中的监控参数。

您能否输入代码行606 ~ 616？

如果进入此中断、则表示触发了零事件。

您可以直接将 overflow_check 设置为 true。

在 SWITCH 中、它使用了 DL_Timer_getPendingInterrupt、这将读取 IIDX 寄存器。

您好、Helic

感谢您的回复,当然我可以输入606~616 ,我将一些累加器置于零事件中,我知道我可以使用标志来指示溢出,但我不知道何时清除此标志,因此我必须使用 DL_Timer_getEnabledInterruptStatus ()来获取溢出情况,但 DL_Timer_getEnabledInterruptStatus ()仍然不起作用,即使我把它放在 TIMG8_IRQHandler 的第一行。

该 API 已正式提供、我希望 TI 可以教用户如何正确使用该 API。

DL_Timer_getPendingInterrupt  

M0读取 IIDX 寄存器、有关 M0如何在读取该寄存器时处理中断的信息、请参阅 TRM。

This register provides the highest priority enabled interrupt index. Value 0x00 means no event pending. Interrupt
1 is the highest priority, IIDX next highest, 4, 8, … IIDX^31 is the least priority. That is, the least bit position that is
set to 1 denotes the highest priority pending interrupt. The priority order is fixed. However, users can implement
their own prioritization schemes using other registers that expose the full set of interrupts that have occurred.
On each read, only one interrupt is indicated. On a read, the current interrupt (highest priority) is automatically
cleared by the hardware and the corresponding interrupt flag in [RIS] and [MIS] are cleared as well. After a read
from the CPU (not from the debug interface), the register is updated with the next highest priority interrupt, if
none are pending, then it should display 0x0.
F

27.3.11 G 系列 TRM https://www.ti.com/lit/ug/slau846b/slau846b.pdf 中的 IIDX (偏移= 1020h)[复位= 00000000h]

如果您在每个中断上获取 MIS：Z、但只在 CCU1案例中进行检查、那么它(几乎)将始终读为0、因为在 IIDX 寄存器中、Z 优先于 CCU1。 假设 Z 和 CCU1都处于挂起状态、则序列为：

1)输入 Z 的 ISR、获取 MIS：Z -> overflow_check

2)读取 IIDX=Z、清除 MIS：Z

3)为 CCU1输入 ISR、获取 MIS:Z ->在(2)中刚刚清除的 overflow_check

4)读取 IIDX=CCU1 (清除 MIS：CCU1)、查看溢出检查、该检查现在为0

原始代码忽略了在接近计数范围上限的情况下发生的 TAIFG ("if (ICR<10000&&TAIFG_SET)")。 您可以继续操作吗？

[编辑:我想我正在赶上这里。 我怀疑您的原始代码使用了(MSP430) IV 寄存器、其中 CCR1的优先级高于 TAIFG (与 IIDX 相反)。 可能有一种方法可以颠倒上面的"if"测试。 或者、您只需省去 IIDX 寄存器并自行解码位。 我使用的一个常见习语是：

  uint32_t mis = TIMER->CPU_INT.MIS;        // Snapshot all
  TIMER->CPU_INT.ICLR = mis;                // Clear all
  if (mis & GPTIMER_CPU_INT_MIS_CCU1_MASK ) // Check CCU1 first
  { and so on }

未经请求：溢出计数的可能替代方法：

1)增加预分频器,实际上交易分辨率范围[在 MSP430的限制内]。  

2)使用32位计时器(TIMG12)[在 MSP430]上不可用。 (这会使您成为唯一的32位计时器、但这很容易实现。)

3)使用事件系统采用第二个(16位)计时器作为溢出计数器[ MSP430上不提供]。 这将需要2个事件(提供程序/订阅者)从 TIMG8连接到另一个计时器：(1)将 Z 事件馈送到另一个计时器的 CCCTL_01[0].ACOND、使其 CTR 节拍；(2)将 CCU1 ( 捕获)事件馈送到另一个计时器的 CCCTL_01[1].CCOND (捕获)、因此它同时捕获溢出 CTR ->CC_01[1]。 [免责声明:我实际上还没有尝试过这个。]

[编辑：轻微澄清]

您好 Bruce

感谢您的答复

原始代码忽略了在接近计数范围上限的情况下发生的 TAIFG ("if (ICR<10000&&TAIFG_SET)")。 您可以继续操作吗？

是的、请检查 P1、这是我们之前的方法(MSP430)、我已经考虑了 高端附近的捕捉情况、

在这个工程(MSP430)中、在用以检查 TAIFG (overflow)的捕获中断中、这是 可行的、但我在 M0G 中无法获得相同的结果。

正如您在 M0G 和 MSP430F5中提到的中断优先级相反、这就是我无法检测到溢出标志(零

事件)在捕获中断(CCU1)中、我是对吗？

e2e.ti.com/.../priority.pdf

是的。 您的代码片段没有显示它、但如果您使用的是(MSP430) TA2IV 寄存器(在这个特定的种族中)、则会首先显示 CCR1中断、并且 TAIFG 仍将被设置。 这对于(MSPM0) IIDX 是不正确的。

[我提到要尝试逆转测试、但我无法想出一种(可靠)方法来实现这一点。]

我怀疑最简单的解决方案是直接读取 MIS 寄存器(如上所述)、并按照适合您的顺序处理中断条件。 (当固定的 IV 优先级划分不当时、我经常会在 MSP430上完成这项工作。)

您好 Bruce 和 Helic

感谢帮助我澄清这个问题。