低功耗定时器正在计数的过程中重新计时

2024-11-20 15:41

如题，低功耗定时器正在计数的过程中，需要重新计时，此时修改：

M0P_LPTIMER0->CR_f.TR = 0;

                for(timeout = 1000; (timeout > 0) && !M0P_LPTIMER0->CR_f.WT_FLAG; timeout--);

                M0P_LPTIMER0->ARR_f.ARR = preload;

                M0P_LPTIMER0->CR_f.TR = 1;

按照HC32L136的资料，preload必须小于0xfffb.  当我计时6个时钟的时候，preload = 0xfffa, 中断正常。但是测量输出波形，发现实际是9个时钟，额外多了3个时钟。  进一步测试：输出一组方波，高脉宽20个脉冲，低脉宽8个时钟。测试输出波形，高脉宽为23个时钟，低脉宽为11个时钟。

  请问，低功耗定时器从写入ARR到装载成功，内部花费了3个时钟周期？

2024-11-20 16:04

资料上说LPTIM用的是非PCLK时钟时，此时LPTIM是异步时钟。也就是说并不能一个PCLK就能把ARR值写入，而是需要一个LPTIM的异步时钟才能确保写入。假如此时PCLK是4M的话，而异步时钟此时是32.768K，按照理论来说需要10多个PCLK时钟周期才能正确写入，而你实测需要3个CLK就写完了，这也算是比较正常了。

建议LPTIM用PCLK看看，需要几个PCLK时钟周期能正常写入。理论上应该一个CLK就能正常写入了。

2024-11-20 16:33

wubangmi 发表于 2024-11-20 16:04
资料上说LPTIM用的是非PCLK时钟时，此时LPTIM是异步时钟。也就是说并不能一个PCLK就能把ARR值写入，而是需 ...

你好，以上指的均是XTL低频时钟（1000000/32768us). 如果是PCLK时钟的话，就没有必要提出来了。大概也很难测试到定时器有延迟。

2024-11-21 09:02

本帖最后由 Sam131208 于 2024-11-21 09:04 编辑

大概可以确定了， LPTIM 在 WT_FLAG == 1 时写入ARR, 还需要等待3个XTL低频时钟，ARR才起作用。 LPTIM 写入的ARR 不大于 0xfffc时（LPTIM 的中断写入），可以可靠的进入中断。考虑到非LPTIM 中断写入时的临界问题，ARR 不应该大于0xfffb。
所以，LPTIM 的定时最小值是（0xffff-0xfffb + 1）+ 3 = 8 (xtl clock).
如果以LPTIM 作为软定时器，最小定时时间还要加上额外的附加时间。实测在24MHZ系统时钟下，在最简单的软定时器任务下，11个XTL时钟就是最小的定时了。小于这个，会出现意外的定时时间。

2024-11-21 11:38

学习一下

2024-11-22 14:13

本帖最后由 Sam131208 于 2024-11-22 14:17 编辑

再次补充一个关于LPTIM 的bug，当启用DeepSleep的时候，完全无法确定，写入ARR后还需要等待多少个XTL低频时钟，ARR才起作用。
测试条件：利用LPTIM 定时输出占空比不是50%的波形，比如正脉宽24个时钟，负脉宽8个时钟。在Sleep睡眠模式下，可以可靠输出正确波形。在DeepSleep睡眠模式下，大多数情况下正脉宽变为5个时钟，负脉宽为8个时钟，偶尔正脉宽为24个时钟。
据此推测，DeepSleep睡眠下，写入的ARR会延迟3个以上XTL时钟。实测3~16个xtl时钟，完全随机的。可能是决定于写入ARR后，是否有被其它事务延迟了进入到DeepSleep状态，越早进入DeepSleep，ARR延迟起作用的时钟需求越多。

专栏首页

低功耗定时器正在计数的过程中重新计时