跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
折叠
品牌标识

YunTu Forum

YTMicro.com
  1. 主页
  2. Discussion & Question
  3. YTM32B1H系列
  4. 关于Gpt测不准问题

关于Gpt测不准问题

已定时 已固定 已锁定 已移动 YTM32B1H系列
20 帖子 4 发布者 487 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • yxydoctorY 离线
    yxydoctorY 离线
    yxydoctor
    写于 最后由 编辑
    #1

    Gpt有两个通道:
    TRM0-CH0: 无限循环,自由计数
    TRM0-Ch1; 设置为50ms一次中断。

    测试方案:
    用通道0检测通道1中断的准确性。

    软件平台:
    threadx做os,官方例程修改

    // 点灯线程
    void App_Led2(ULONG thread_input)
    {
        while (1){		
    
            Dio_FlipChannel(DioConf_DioChannel_D18_PTA20); /* toggle D18 */
    
    	tx_thread_sleep(100);
        }
    }
    // 通道1中断通知
    void Gpt_Tmr1Ch1Notification(void)
    {  
        debug_time[2] = Gpt_GetTimeElapsed(0)/50;       // 读计数值转为us
        Gpt_StopTimer(0);  Gpt_StartTimer(0, 0xffffffff);  // 重启定时器
    }
    
    // 定时器初始化
        // 通道0:通用计数,不产生中断
        Gpt_StartTimer(0, 0xffffffff); 
        // 通道1:50ms定时
        Gpt_StartTimer(1, 50*50000U);  // 定时周期=50ms(定时器时钟=50M)  
        Gpt_EnableNotification(1);  // 使能定时器中断  
    
    

    问题描述:
    如果线程中的tx_thread_sleep(100)改为10即10ms时,测时很准就是50ms周期与设计相符;
    但如果设为100ms,则显示的测量值会在35ms-65ms之间波动,但平均值应该还是50ms。这种现象肉眼可见,不知道咋回事。卡了一下午无果。

    1 条回复 最后回复
    0
    • yxydoctorY 离线
      yxydoctorY 离线
      yxydoctor
      写于 最后由 编辑
      #2

      补充一点:通道0测线程周期是很稳定的没有异常。
      感觉就好像不能在Gpt的一个通道中断函数中访问另一个通道一样。
      通道1的实际中断周期似乎是准的,因为拿线程粗略评估过;但用通道0测不准

      1 条回复 最后回复
      0
      • yxydoctorY 离线
        yxydoctorY 离线
        yxydoctor
        写于 最后由 编辑
        #3

        基本实锤,就是通道1定时器中断不准造成的。
        同样计数方法:
        线程1测试调度周期500ms很稳;
        线程2堵塞,接收中断通知进行计数保证计数的实时性,结果还是周期忽上忽下。
        所以现在怀疑是官方Gpt驱动有问题。

        1 条回复 最后回复
        0
        • zyqZ 离线
          zyqZ 离线
          zyq YunTu
          写于 最后由 编辑
          #4

          我测试没有发现问题。你的意思是同样的500ms,两个通道进中断次数不一样吗?

          1 条回复 最后回复
          0
          • yxydoctorY 离线
            yxydoctorY 离线
            yxydoctor
            写于 最后由 编辑
            #5

            不是您说的这样。
            1-线程1只是参考计时,500ms调度周期,测下来也是500ms,说明gpt通道0自由计数方法是对的,不存在理解上的偏差。
            2-线程2消息堵塞,目的只是保证计数的实时性,不至于受限于线程调度周期(1ms)。这个消息是gpt通道2的中断触发的。

            1 条回复 最后回复
            0
            • yxydoctorY 离线
              yxydoctorY 离线
              yxydoctor
              写于 最后由 编辑
              #6

              实测下来,50ms的中断周期,表现为35-65ms不等。所以让人很困惑。
              而反测竞品的gpt驱动(基于EB的),没有这种现象。所以让人比较忧虑

              1 条回复 最后回复
              0
              • zyqZ 离线
                zyqZ 离线
                zyq YunTu
                写于 最后由 编辑
                #7

                我用freertos没有复现你的现象,方便把代码发出来我们测一下吗?

                1 条回复 最后回复
                0
                • yxydoctorY 离线
                  yxydoctorY 离线
                  yxydoctor
                  写于 最后由 编辑
                  #8

                  问题终于锁定了!可喜可贺,复盘一下:
                  1 - 关闭OS,裸机跑(Mcal初始化后死循环),定时器中断周期是准的;但也发现复位后居然没有自动开狗。
                  2 - 开启OS,定时器中断周期不准,标准50ms,实测会在35ms-65ms浮动。
                  3 - 开OS后,某些情况下中断周期也是准的,比如改改app调度周期。

                  原因分析:
                  1 - platform模块修改定时器中断优先级,从0开始测试,一路测试到14,问题都不存在了,也就是优先级不能为15;
                  2 - 把例程中已开启的其它外设的中断都关闭,Gpt模块中未使用的外设也关闭,只保留这一路定时器中断;同样满足步骤1现象,不能为15.
                  3 - 据此分析,想不通原因,希望官方还是核时一下吧。

                  1 条回复 最后回复
                  0
                  • EnweiE 离线
                    EnweiE 离线
                    Enwei YunTu
                    写于 最后由 Enwei 编辑
                    #9

                    你的操作系统Thread的内核SysTick Timer, PendSV和SVCall三个中断的优先级是怎样配置的?
                    image.png
                    内核私有外设模块SCB->SHPR2/3寄存器:
                    image.png

                    yxydoctorY 1 条回复 最后回复
                    0
                    • yxydoctorY 离线
                      yxydoctorY 离线
                      yxydoctor
                      在 回复了 Enwei 最后由 编辑
                      #10

                      Enwei
                      无标题.jpg

                      1 条回复 最后回复
                      0
                      • yxydoctorY 离线
                        yxydoctorY 离线
                        yxydoctor
                        写于 最后由 编辑
                        #11

                        之前用的nxp的rt1021配的,也是个M7

                        1 条回复 最后回复
                        0
                        • EnweiE 离线
                          EnweiE 离线
                          Enwei YunTu
                          写于 最后由 编辑
                          #12

                          yxydoctor 我们这边使用FreeRTOS无法复现你说的问题,初步怀疑是Thread和FreeRTOS两个OS对外设中断的管理不同导致的。要找到root cause,需要你提供一下你的测试工程,谢谢~!

                          yxydoctorY 1 条回复 最后回复
                          0
                          • yxydoctorY 离线
                            yxydoctorY 离线
                            yxydoctor
                            在 回复了 Enwei 最后由 编辑
                            #13

                            Enwei
                            我怎么发呢?

                            EnweiE 1 条回复 最后回复
                            0
                            • yt0069Y 离线
                              yt0069Y 离线
                              yt0069
                              写于 最后由 编辑
                              #14

                              Gpt模块采用的tmr,ptmr,lptmr,rtc实现的,从外设的工作机制上来讲建议优先选择ptrm和lptmr来作为Gpt的硬件模块。OS的tick值可采用core带的system tick来实现,只是需要手写代码

                              1 条回复 最后回复
                              0
                              • EnweiE 离线
                                EnweiE 离线
                                Enwei YunTu
                                在 回复了 yxydoctor 最后由 编辑
                                #15

                                yxydoctor 将工程压缩后,直接论坛里面回帖附件上传或者发到我邮箱enwei.hu@ytmicro.com

                                yxydoctorY 1 条回复 最后回复
                                0
                                • yxydoctorY 离线
                                  yxydoctorY 离线
                                  yxydoctor
                                  在 回复了 Enwei 最后由 编辑
                                  #16

                                  Enwei 工程代码已发您邮箱了,烦请看看根本原因具体在哪里?也是第一次遇到这种情况,但如果不知根本原因,可能会是个隐患。

                                  EnweiE 1 条回复 最后回复
                                  0
                                  • EnweiE 离线
                                    EnweiE 离线
                                    Enwei YunTu
                                    在 回复了 yxydoctor 最后由 编辑
                                    #17

                                    yxydoctor 邮件已收到,我们会尽快处理~!

                                    1 条回复 最后回复
                                    0
                                    • EnweiE 离线
                                      EnweiE 离线
                                      Enwei YunTu
                                      写于 最后由 Enwei 编辑
                                      #18

                                      yxydoctor 收到你的工程后,我这边复现debug这个问题,root cause如下:

                                      你工程中使用的ThreadX OS这个操作系统初始化时没有创建任何空闲任务(idle task),导致用户任务通过调用tx_thread_sleep()睡眠后,内核的PendSV_Handler中不清除自己的中断标志(因为没有ready的task需要执行),从而CPU长期执行任务切换检查的代码而不主动退出(仅在SysTick 1ms中断和APP1和APP2两个用户任务睡眠时间tineout后才退出)。如果这时候外设中断,比如本例中的pTMR_CH0的50ms定时中断的优先级与PendSV设置相同(都是15),那么跟PendSV相同优先级的外设中断ISR将很难被执行(仅退出PendSV_Handler时才可能)。

                                      用户任务睡眠时间越长,这种现象越严重,这也与你反馈的,10ms睡眠时正常(我这边测试5ms,1ms, 50ms,甚至APP2 task中不睡眠都是OK的,因为pTMR_CH0的定时周期为50ms),而100ms不正常(测试500ms睡眠的话,测量的时间周期偏差更大)。

                                      因此,解决方案有如下两种:

                                      1. 将工程中所有用到的外设中断优先级配置为高于PendSV的优先级(Cortex-M系列CPU内核的中断优先级数字越小优先级越高)
                                      2. 给ThreadX OS创建一个Idle task,并将其优先级设置为最低0(ThreadX OS的stask/thread优先级数据越大优先级越高)
                                        9307b272-bff7-4e74-a8f2-012bfd80e3b6-image.png
                                      1 条回复 最后回复
                                      0
                                      • yxydoctorY 离线
                                        yxydoctorY 离线
                                        yxydoctor
                                        写于 最后由 编辑
                                        #19

                                        非常非常感谢,这是真正的专家。您看这样是否可行:
                                        threadx本身并没有空闲任务这个不烦了。我这边保证所有需要中断的mcal外设中断优先级<15,即PendSV,这样可以么?

                                        EnweiE 1 条回复 最后回复
                                        0
                                        • EnweiE 离线
                                          EnweiE 离线
                                          Enwei YunTu
                                          在 回复了 yxydoctor 最后由 编辑
                                          #20

                                          yxydoctor 可以的。

                                          1 条回复 最后回复
                                          0

                                        • 云途论坛规则/Yuntu Forum Rules

                                          发帖前请查看

                                        • YCT离线License申请流程

                                          帮助没办法联网的电脑使用YCT

                                        • YT CONFIG TOOL调查问卷

                                          帮助改进和优化YT CONFIG TOOL,有机会抽取YTM32B1ME0 EVB哦...

                                        • demo
                                          12
                                          can
                                          8
                                          lin stack
                                          6
                                          yt-link
                                          5
                                          vscode
                                          3
                                          adc模块
                                          2
                                          i2c
                                          2
                                          uuid
                                          2
                                          Online Users
                                          • 登录

                                          • 登录或注册以进行搜索。
                                          • 第一个帖子
                                            最后一个帖子
                                          0
                                          • 版块
                                          • 最新
                                          • 标签
                                          • 热门