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

YunTu Forum

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

关于Gpt测不准问题

已定时 已固定 已锁定 已移动 YTM32B1H系列
20 帖子 4 发布者 492 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • 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
                                        XgqX
                                        Xgq
                                        gaoShengG
                                        gaoSheng
                                        mcM
                                        mc
                                        nuseavaN
                                        nuseava
                                        BillYinB
                                        BillYin
                                        • 登录

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