This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC2340R5:启用 J-link RTT 时 GPIO 中断延迟大幅增加

Guru**** 2534260 points
Other Parts Discussed in Thread: SEGGER

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1547681/cc2340r5-gpio-interrupt-delay-to-much-when-enable-j-link-rtt

器件型号:CC2340R5
主题中讨论的其他部件:SEGGER

工具/软件:

您好、

我们遇到有关 IO 中断延迟的问题、请帮助进行检查。

Fritly、我们使用 J-link RTT!

  1. 它需要更多  150μs  当我们在 PC 上没有使用 j-link RTT 查看器连接到电路板时、从 IO 下降沿到 IO 中断处理回调函数、该过程太长了。
  2. 当我们在 PC 上使用 j-link RTT 查看器连接到电路板时、只需要 45μs 从 IO 下降沿到 IO 中断处理回调函数、这是正常现象(从待机状态唤醒到工作状态)

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、张:

     CC2340R5:GPIO 中断延迟  

    请参阅 PowerCC23X0.c、其中在 PowerCC23X0_enterStandby 之后调用 PowerCC23X0_startHFXT 。

    static void PowerCC23X0_startHFXT(void)
    {
        /* Only start HFXT if it is not already enabled. Trying to start the HFXT
         * if it is already enabled will cause TRACKREFLOSS when starting the LDO.
         * This situation can arise when:
         * - Waking up from fake standby. Fake standby does not shut down the HFXT,
         *   unlike real standby.
         * - Waking up without actually entering real standby. If a wakeup source is
         *   pending when we reach WFI in the ROM function, the hardware will just
         *   turn that into a NOP instead and not run through the regular state
         *   machine.
         */
        if ((HWREG(CKMD_BASE + CKMD_O_HFXTCTL) & CKMD_HFXTCTL_EN_M) != CKMD_HFXTCTL_EN)
        {
            /* Start LDO */
            HWREG(CKMD_BASE + CKMD_O_LDOCTL) = (CKMD_LDOCTL_SWOVR | CKMD_LDOCTL_STARTCTL | CKMD_LDOCTL_START |
                                                CKMD_LDOCTL_EN);
    
            /* Bypass a lowpass filter that is connected to the reference voltage
             * for 66us to ensure that reference has settled.
             */
            HapiWaitUs(66);
    
            /* Clear START bits */
            HWREG(CKMD_BASE + CKMD_O_LDOCTL) = (CKMD_LDOCTL_SWOVR | CKMD_LDOCTL_HFXTLVLEN | CKMD_LDOCTL_EN);
    
            /* Force bias measurement before enabling HFXT - Set SRCSEL = BIAS.
             * Enable the peak detector in the HFXT amplitude control loop to
             * control RF phase jumps.
             */
            HWREG(CKMD_BASE + CKMD_O_AMPADCCTL) = (CKMD_AMPADCCTL_SWOVR | CKMD_AMPADCCTL_PEAKDETEN_ENABLE |
                                                   CKMD_AMPADCCTL_ADCEN_ENABLE);
    
            /* Delay to settle PEAKDET + ADC */
            HapiWaitUs(6);
    
            /* Clear raw interrupt for ADCBIASUPD */
            HWREG(CKMD_BASE + CKMD_O_ICLR) = CKMD_ICLR_ADCBIASUPD;
    
            /* Start an SAR conversion */
            HWREG(CKMD_BASE + CKMD_O_AMPADCCTL) |= CKMD_AMPADCCTL_SARSTRT;
    
            /* Immediately prevent any SAR new conversions from starting. The one
             * started above will complete though.
             */
            HWREG(CKMD_BASE + CKMD_O_AMPADCCTL) &= ~CKMD_AMPADCCTL_SARSTRT;
    
            /* Wait until HFXT-ADC BIAS measurement is done */
            while (!((HWREG(CKMD_BASE + CKMD_O_RIS) & CKMD_RIS_ADCBIASUPD_M) == CKMD_RIS_ADCBIASUPD)) {}
    
            /* Clear SW override of amplitude ADC */
    
            /* Keep PEAKDET on */
            HWREG(CKMD_BASE + CKMD_O_AMPADCCTL) &= ~(CKMD_AMPADCCTL_SWOVR_M | CKMD_AMPADCCTL_ADCEN_M);
    
            /* Start HFXT */
            HWREG(CKMD_BASE + CKMD_O_HFXTCTL) |= CKMD_HFXTCTL_EN;
        }
    
        /* Disallow standby until AMPSETTLED is true */
        Power_setConstraint(PowerLPF3_DISALLOW_STANDBY);
    
        /* Enable the AMPSETTLED interrupt.
         * Since it is a level status signal, it remains asserted when we are
         * running on HFXT and cannot be cleared.
         * The oscillator interrupt removes it from the interrupt mask to prevent
         * repeated vectoring.
         */
        HWREG(CKMD_BASE + CKMD_O_ICLR)  = CKMD_ICLR_AMPSETTLED;
        HWREG(CKMD_BASE + CKMD_O_IMSET) = CKMD_IMSET_AMPSETTLED;
    }

    当连接 J-link RTT 调试器时、该器件可能会使 HFXT 保持为启用状态、即所谓的“假待机“。  因此 在这种情况下、退出待机模式后不会产生额外的开销、因此总体延迟与数据表中的“唤醒时序“参数非常相似。 对于自由运行的器件、在 Power TI 驱动程序中实现了额外的延迟来安全启动 HFXT、这将导致在执行 ISR 之前花费更长的时间。  

    由于 UART 硬件外设本身在 UART RX 功能期间禁用了待机模式、因此您可以始终保持在工作模式、或使用虚拟第一个字节来唤醒器件、禁用待机、读取以下 UART 字节、然后在超时或完成读取所有字节后重新启用待机模式。

    此致、
    Ryan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Ryan、

    感谢您的答复。

    更多问题:

    1.对于“假待机“、您是指   连接 J-link RTT 调试程序时 PowerCC23X0_startHFXT() 将在 PowerCC23X0_enterStandby() 之后调用吗?  我不认为 是这样、下面是我的测试代码、我基于连接的 J-link RTT 进行了测试。

    /************************************************************************************************************************************** /

    static int pwr_awake_notify_CB (unsigned int event_type、
    uintptr_t event_arg、
    uintptr_t client_arg)

      if (PowerLPF3_Awake_standby == event_type){
         GPIO_WRITE (6、1);
      }
    }

    静态 void PowerCC23X0_startHFXT (void)

      GPIO_WRITE (6、1);
      …
    }

    int app_pwr_manage_enter_sleep (uint32_t sleep_s)

      POWER_REGISTERNotify (&pwr_notify、PowerLPF3_Awake_standby、pwr_Awake_notify_CB、(uintptr_t) NULL);
      GPIO_WRITE (6、0);
      睡眠 (15);
    }

    /************************************************************************************************************************************** /

    从画面中可以看到、只有在睡眠时间 15 秒后 DIO6 才会上拉。 所以我认为  PowerCC23X0_startHFXT() 不会在 PowerCC23X0_enterStandby () 之后调用。 如果我有任何误解、请告诉我。




     ~在数据表的“MCU,待机到工作状态“唤醒时序 33 μ s 50μs 中,我认为它不是在 “假待机“模式下测试的,这 与 J-link RTT 调试器相似。 这毫无意义。 它认为应该使用自由运行进行测试。


    期待您的答复。



    此致

    Zhang

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    1.很抱歉不清楚这一点、但 在 PowerCC23X0_enterStandby 将器件置于待机状态时唤醒 MCU 后会调用 PowerCC23X0_startHFXT、即在 安全地从待机状态唤醒时使用 PowerCC23X0_startHFXT。  因此、它将在 15 秒睡眠后发生、与 pwr_awake_notify_CB 大致相同。

    2.数据表未使用任何假待机模式进行测试,也未考虑电源 TI 驱动程序产生的额外延迟开销。

    此致、
    Ryan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Ryan、

    是的、我同意 在 MCU 从待机模式唤醒后调用 PowerCC23X0_startHFXT。

    但是、当我尝试在代码中删除 RTT 时 、让器件自由运行、ISR 的延迟与 45μs 有关、这与数据表中的“唤醒计时“参数非常相似。 在这种情况下、器件 自由运行、并且包括了 电源 TI 驱动程序产生的额外延迟开销、对吗?
    从 IO 信号的下降沿到 ISR 所用的时间总结如下:


    在我的观点中、如果“enable RTT and connected   to PC“(启用 RTT 并连接到 PC)将使其在假待机模式下工作、则此情况所用的时间应大于 45μs、、它可能是空闲至活动状态的时间、大约为 3 或 14μs。 但实际上、即使我们启用了 RTT、它似乎处于待机状态。 因此,为什么我想知道在“启用 RTT 但不连接到 PC“的情况下,它将是更多的 150μs。

    期待您的答复。



    此致

    Zhang

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、张:

    我对 J-Link RTT 了解不足、无法进行进一步评论。  您是否与 Segger 谈论过这些观察结果?   在“无 RTT“测试期间、PC 是否已连接、您能否验证“无 RTT“(PC 已连接,未连接)的两个实例?  您使用的是哪个版本的 SimpleLink F3 SDK?

    此致、
    Ryan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Ryan、

    1、否、我们 尚未与 Segger 谈论过这个问题。

    2.如果“无 RTT“,则无需连接到 PC(J-Link RTT 查看器)

    3.我们使用 simplelink_lowpower_f3_SDK_8_40_02_01

    此致

    Zhang

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    值得联系 Segger、以便您将他们的工具期望与您的报告保持一致。  如果仅用于调试、则可以考虑禁用用于生产的 RTT。

    此致、
    Ryan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Ryan

    感谢您的答复。
    我将尝试联系 SEGGER。 如果没有任何其他建议、我将关闭此问题。
    再次感谢!

    此致

    Zhang