94 lines
5.7 KiB
Markdown
94 lines
5.7 KiB
Markdown
# RTC测试例程说明文档
|
||
|
||
本测试程序用于测试RTC基本功能。
|
||
|
||
## RTC简介
|
||
|
||
RTC timer（real-time clock timer）即实时时钟定时器，通过内部计数器计数到指定值来产生定时中断，指定值可以由软件修改。
|
||
|
||
### RTC特性
|
||
|
||
kl3 RTC具有如下特性：
|
||
|
||
* 支持32bit的计数数值，只支持向上计数。
|
||
* 支持设置计数补偿值。
|
||
* 支持软件暂停计数和清零。
|
||
* 支持单周期和多周期计数模式。
|
||
* 支持两个timer级联成一个64bit counter mode，此时timer1作为计数值高32bit，timer0作为计数值低32bit。
|
||
* 支持3种工作模式。
|
||
1. timer mode，计数值到达阈值之后停止计数。
|
||
2. repeat mode，计数值到达阈值是产生中断，并清除counter重新计数。
|
||
3. freerun mode，在计数达到阈值后，产生中断，但是不停止计数。
|
||
* 支持timer计数产生中断之后，软件直接修改阈值产生下一个中断。
|
||
* 支持auto-reload模式，软件可以直接改写counter当前的计数值。
|
||
|
||
## 测试例程说明
|
||
|
||
rtc测试例程使用到的外设包含rtc、uart、gptimer。
|
||
|
||
* rtc：测试对象，测试其计数、中断、级联等基础功能。
|
||
* uart：使用uart0，实现调试信息打印，接收case配置信息等与PC的交互功能。
|
||
* gptimer：使用gptimer0，用于测试时延时，方便判断rtc是否正常工作。
|
||
|
||
rtc测试例程遵循自动化测试框架，在例程执行之后，初始化串口0，通过串口发送“start”字段到PC，并等待PC发送“config”字段来获取本次需要执行的测试case，如果在规定时间内（9s）没有收到测试case信息，则默认测试所有的case。
|
||
|
||
在获取到case组合之后，初始化rtc以及gptimer，并根据case组合开始执行测试case。
|
||
|
||
*rtc的测试较为简单，测试用的例程大多数使用gptimer延时（阻塞式），并对比延时前后的计数值的方式，来判定rtc是否正常工作。已知rtc时钟为32768，则延时1s的情况下，rtc应该累计32768左右的计数值，但是据rtc ower戴万描述，由于操作rtc存在跨时间域的问题（即rtc时钟主频和core主频不一致），在操作rtc时可能会导致rtc丢失几个周期的计数值*
|
||
|
||
### case0：获取和设置计数值
|
||
|
||
在rtc timer配置为非级联模式下，分别获取timer0和timer1的计数值，并通过gptimer延时（阻塞式）1秒，再次获取timer0和timer1的技术值，通过分别对比timer对应的计数值差值，如果差值小于32768，则认为rtc工作异常（因为代码执行以及打印需要额外的时间）。
|
||
|
||
设置timer0和timer1的计数值为0，延时1秒，读取timer0和timer1的计数值，如果计数值小于32768，则认为rtc设置计数值失败。
|
||
|
||
测试结果正常。
|
||
|
||
### case1：计数暂停和恢复
|
||
|
||
在rtc timer配置为非级联模式下，读取timer0和timer1的计数值，然后暂停rtc计数，延时1秒之后从新读取计数值，如果两次读取的计数值差值大于32768，则认为rtc暂停失败。
|
||
|
||
暂停成功后回复rtc计数，延时1秒之后重新读取rtc计数，判断延时前后的rtc计数值差值，小于32768则认为恢复失败。
|
||
|
||
测试结果正常。
|
||
|
||
### case2：rtc stop和start
|
||
|
||
测试方法和case1一致。测试结果正常。
|
||
|
||
### case3：rtc中断
|
||
|
||
在rtc timer配置为非级联模式下，将scratch0寄存器置0，使能timer中断，配置对应的中断处理函数，通过配置timer计数值使其能够在3秒后达到阈值并触发中断，在中断处理函数中将scratch0寄存器对应的bit置位（timer0置位bit0，timer1置位bit1）并清除中断标志。在程序中等待scratch0寄存器变为0x3，如果7秒内scratch0寄存器值不为0x3，则判定测试失败。
|
||
|
||
这里使timer在3秒内达到阈值用了两种办法：
|
||
|
||
1. timer0阈值配置为0xffffffff，配置补偿值为阈值减去当前计数值再减去3*32768，使其3秒后能达到阈值，顺便测试了补偿值功能*
|
||
|
||
（***补偿值不直接累加到计数值上，而是存在于额外的寄存器中，所以获取到的计数值等于计数器寄存器值加上补偿寄存器值***）
|
||
|
||
2. timer1计数值配置为0，阈值配置为3*32768。
|
||
|
||
测试结果正常。
|
||
|
||
### case4：级联计数器
|
||
|
||
在kunlun大code中，级联为64bit计数器才是rtc真正的用法。根据实际使用场景，这里只需要保证64bit计数值能正常工作即可。
|
||
|
||
在测试时，将rtc重新初始化为级联模式，并配置timer0的计数值为0xffffffff，配置timer1的计数值为0，以确保timer0计数超出阈值之后，timer1作为高32bit能正常累加。延时1秒，读取级联计数值，如果高32bit不等于1或者计数值小于0xffffffff加32768，则判定测试失败。
|
||
|
||
测试结果正常。
|
||
|
||
### case5：计数精准度
|
||
|
||
这个测试较为简单，在级联模式下，直接使用gptimer延时，并在延时前后读取timer计数值并打印，在串口工具端开启日志时间戳功能。通过判断时间戳和打印的计数值差值，来判定rtc计数精准度，这个测试需要人工参与，因此不加入自动化测试流程中。
|
||
|
||
需要注意的是，两次读取计数值之间尽量不要存在多余的流程和打印，仅保留一个简单打印用于触发串口工具的时间戳即可。
|
||
|
||
### case6：看门狗复位时rtc行为测试
|
||
|
||
这个测试主要验证rtc在看门狗复位是，配置寄存器的值是否会改变，以及计数值是否继续累加。
|
||
|
||
测试方法较为简单，在执行完中断测试之后（中断测试汇总修改了较多的寄存器），dump rtc寄存器的值，然后触发看门狗复位，复位后使用gdb dump rtc寄存器的值，然后对比两次寄存器值即可，预期的结果是计数值继续累加，但是配置寄存器的值不变化。
|
||
|
||
测试结果正常，符合预期。
|