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

YunTu Forum

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

关于Gpt测不准问题

已定时 已固定 已锁定 已移动 已解决 YTM32B1H系列
20 帖子 4 发布者 5.8k 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • 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
      写于 最后由 编辑
      #19

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

      EnweiE 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 YunTu
                                写于 最后由 编辑
                                #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
                                            • ,FrankieF Frankie 将这个主题转为问答主题
                                            • ,FrankieF Frankie 将这个主题标记为已解决

                                          • 云途开发生态介绍

                                            快速上手云途开发生态

                                          • 云途论坛规则/Yuntu Forum Rules

                                            发帖前请查看

                                          • YT CONFIG TOOL调查问卷

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

                                          • can
                                            25
                                            demo
                                            22
                                            lin stack
                                            13
                                            uds
                                            13
                                            md14
                                            6
                                            yt-link
                                            6
                                            fbl
                                            5
                                            adc模块
                                            4
                                            Online Users
                                            • 登录

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