[参考译文] CC1352P：边沿计数模式下的 GPT -更新 TAPMR/TAMATCHR/TALR 时、TAV/TAR 寄存器计数发生变化

admin

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1224485/cc1352p-gpt-in-edge-count-mode---tav-tar-register-count-changes-when-updating-tapmr-tamatchr-tapr-tailr

器件型号：CC1352P

问题：

* 在边沿计数模式(向上)并启用计数器的情况下、设置 TAPMR/TAMATCHR/TAPR/TAILR 时、我们将获得额外的计数。意外计数的数量取决于所写入的寄存器。

预期行为：

*在更新匹配/最大值寄存器时、TAV/TAR 值应保持稳定-无论计数器是否被启用。

以下代码片段展示了我们正在执行的操作：

1. 配置

PRCMPowerDomainOn(PRCM_PERIPH_TIMER0);
PRCMPeripheralRunEnable(PRCM_PERIPH_TIMER0);
PRCMLoadSet();
while (!PRCMLoadGet()) {
  continue;
}

IOCPortConfigureSet(15, IOC_PORT_MCU_PORT_EVENT0, IOC_IOPULL_UP | IOC_INPUT_ENABLE | IOC_IOCFG0_EDGE_DET_NEG);

/* next we enable IRQ15 / GPT0 in a platform specific way */

TimerDisable(GPT0_BASE_ADDR, TIMER_A);

HWREG(GPT0_BASE_ADDR + GPT_O_CFG) = GPT_CFG_CFG_16BIT_TIMER;
HWREG(GPT0_BASE_ADDR + GPT_O_CTL) |= GPT_CTL_TASTALL;
HWREG(GPT0_BASE_ADDR + GPT_O_TAMR) =
GPT_TAMR_TAMR_CAPTURE | GPT_TAMR_TACM_EDGCNT | GPT_TAMR_TAMIE | GPT_TAMR_TAMRSU_CYCLEUPDATE | GPT_TAMR_TACDIR_UP;

/* next we set initial top/match values see code snippet below */

TimerIntEnable(DT_TIMER_BASE_ADDR(0), TIMER_CAPA_MATCH);

2. 我们的代码更新最高/匹配值

uint32_t value = 14;
uint8_t prescaleValue = 0xff & (value >> 16);
HWREG(GPT0_BASE_ADDR + GPT_O_TAPR) = prescaleValue; // or GPT_O_TAPMR when updating the match value
HWREG(GPT0_BASE_ADDR + GPT_O_TAILR) = value & 0xffff; // or GPT_O_TAMATCHR

3.重现问题的步骤

-如1所示设置定时器。

-当我们更新顶部/匹配值时启用定时器(请参阅2。) 然后、TAP/TAV 值立即计数1个或者更多额外计数、这取决于被写入的寄存器。

-当我们在更新顶部/匹配值时禁用定时器时,没有记录对 TAP/TAV 值的变化。

临时禁用计时器以更新匹配值的变通办法不能令人满意。我们更希望在计时器保持运行时更新匹配值、以确保在计时器禁用时不会出现边沿松动。

除此之外、边沿计数器运行良好、因此基本设置似乎没有问题。

2 年多前

0 admin 2 年多前

TI__Guru**** 2482225 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Florian：

GPTimer 驱动程序中提供了用于更新匹配或间隔加载值的 API。该文档建议在定时器运行时可以使用 API。

我建议您遵循驱动程序功能、并检查您的方法中是否存在差异。

https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_7_10_00_98/docs/drivers/doxygen/html/_g_p_timer_c_c26_x_x_8h.html#a3f83bdcc8482297952f6e08ccadd0e11

还想知道计数的变化是什么。

此致、

SID

0 admin 2 年多前

TI__Guru**** 2482225 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Sid：

感谢您花时间研究此问题。

Unknown 说：
我建议您遵循驱动程序函数并检查方法中的差异。

没有区别、因为我们从那里获取了我们的代码。 :-)确认 GPTimer 驱动程序代码为自己,并与我张贴的代码比较:

/* The method you reference to sets up regPre/regLoadMatch as GPT_O_TAPMR and GPT_O_TAMATCHR respectively */
...

    /* Upper byte is used by prescaler */
    uint8_t prescaleValue = 0xFF & (loadMatchVal >> 16);
    /* Discard upper byte (24 bits max) */
    loadMatchVal &= 0xFFFF;

    /* Set prescale value */
    HWREG(hwAttrs->baseAddr + offset + regPre) = prescaleValue;

    /* Set load / match value */
    HWREG(hwAttrs->baseAddr + offset + regLoadMatch) = loadMatchVal;
    
...

除了变量名称的更改和通过额外的函数调用进行的额外间接访问之外、该方法应该完全相同、包括寄存器的访问顺序。

Unknown 说：
]还想知道计数更改是什么。 [/报价]
计数在2到4之间的值、具体取决于所访问的寄存器的类型和数量。计数的增加是确定性的 AFICS。这意味着相同的寄存器组合将始终导致相同的计数器偏移。

另请注意、我无法验证在时钟计数模式下是否也会发生这种情况、因为时钟运行得太快、我无法找到。因此、这仅针对上面指出的边沿计数确认、但也可能发生在时钟计数。

因此，令人遗憾的是，该问题仍未得到解决。我建议您使用 TI 的原始 GPTimer 驱动程序在原始 TI 硬件上重现此情况、以查看是否可以确认问题。我们能够始终如一地重现问题

此致、

弗洛里安

0 admin 2 年多前

TI__Guru**** 2482225 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Florian：

我给您发送了一条个人 e2e 消息。我需要知道您是如何验证这一点的？

此致、
SID

0 admin 2 年多前

TI__Guru**** 2482225 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

是的、看到了- 通过 PM 向您发送了我的回复、因此我们现在应该直接联系。

低于 1GHz（参考译文帖）

低于 1GHz（参考译文帖）(Read Only)

[参考译文] CC1352P：边沿计数模式下的 GPT -更新 TAPMR/TAMATCHR/TALR 时、TAV/TAR 寄存器计数发生变化