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.

[参考译文] SK-AM62A-LP:SK-AM62A-LP:在 MCU-GPIO 引脚上的 MCU-R5 FW 中使用 ClockP_usleep ()生成13us 导通周期脉冲的正面问题。

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1511275/sk-am62a-lp-sk-am62a-lp-facing-issue-to-generate-13us-on-period-pulse-using-clockp_usleep-in-mcu-r5-fw-on-mcu-gpio-pin

器件型号:SK-AM62A-LP

工具/软件:

尊敬的团队:
使用下面的代码片段、我们尝试使用在 MCU-GPIO 引脚上生成脉冲 13us 导通时间和10ms 周期 。 我们在一个任务中添加了此逻辑、从中可在 GPIO 引脚上在特定条件下生成13us 的保持活动脉冲。
MCU-SDK-版本:-  MCU_PLUS_SDK_am62ax_09_02_00_38
代码:-  
while (1)
{
    if (Condition-1) /*Code-logic in this if condition */
    {
        if (xSemaphoreTake(keepAlivePulseMutex, portMAX_DELAY) == pdTRUE)
        {
            DebugP_log("EIC-Log ClockP_usleep(): KeepAlivePulseTaskHandler() Case-2 onTimeUs: %d && keepAlivePeriodMs: %d\r\n", onTimeUs, keepAlivePeriodMs);
            setGpioValue(MCU_SOC_ILLUM_STRB_PIN, GPIO_PIN_HIGH);
            ClockP_usleep(13); /* ON time in µs */
            setGpioValue(MCU_SOC_ILLUM_STRB_PIN, GPIO_PIN_LOW);
            xSemaphoreGive(keepAlivePulseMutex);
        }
        ClockP_usleep(10000); /* Configurable pulse period */
    }

}
在测试过程中、我们发现、在重新引导后随机观察到、即使我们已在中配置了13us (硬核值)、956us 导通周期也会生成 ClockP_USleep ()函数。
使用 ClockP_USleep ()函数在小微秒值配置下是否稳定/正常工作? 请提供上述问题的解决方案。
 使用前需要进行的任何其他配置  ClockP_usleep() 函数? 还请提供详情。
正常脉冲:- (配置13us 休眠模式 (使用  ClockP_uSleep)  获取脉冲宽度 13.89us)
导通时间脉冲 (随机观察到的问题)   (配置13 μ s 睡眠 (使用  ClockP_uSleep)   并获得随机的脉冲宽度  956.3.  美国)
注意:我们在 MCU-R5内核上运行应用程序、在 A-53内核上运行 Linux。
谢谢、
Nisarg
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好团队:

    对此有任何更新?

    谢谢、

    Nisarg

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

    尊敬的 Nisarg:

    GPIO 是否是应用中运行的唯一任务?  

    是否还有其他任务正在运行? 每个任务的优先级是什么以及任务发生的时间段是什么?

    Unknown 说:
    获取随机的脉冲宽度  956.3.  美国 [/报价]

    这是否意味着 GPIO 信号在956us (而不是13us)内处于高电平? 此问题发生了多少次?

    此致、

    Tushar

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

    尊敬的 Tushar:

    应用中没有正在运行的多个任务。 当特定条件启用时、此保持活动任务将连续运行;特别是条件 false。在这种情况下  、将任务置于睡眠状态毫秒时间、并在该时间之后唤醒、以检查条件 true 或 false。 请检查案例描述中的代码片段。 我们已在任务创建(keep_aliive_pulse_task)中设置了保持活动任务优先级14。

    define Keep_Alive_pulse_task_pri 14u

    用于剩余任务; 我们将任务优先级设为12或更低、然后设为12。  

    [报价 userid="16414" url="~/support/processors-group/processors/f/processors-forum/1511275/sk-am62a-lp-sk-am62a-lp-facing-issue-to-generate-13us-on-period-pulse-using-clockp_usleep-in-mcu-r5-fw-on-mcu-gpio-pin/5810396 #5810396"]

    这是否意味着 GPIO 信号在956us (而不是13us)内处于高电平? 此问题发生了多少次?

    [/报价]

    是的, GPIO 高为大约956us 而不是13us ,即使 硬核值设置13us 在  ClockP_USleep ()保持活动功能。

    在软重新启动中; 检查5次时、大约观察到该问题3次。

    在 HW-Reboot 中; 选中10次时、大约4次观察到该问题。

    请尽快帮助我们解决此问题。

    谢谢、

    Nisarg

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

    尊敬的 Nisarg:

    应用程序中没有正在运行多个任务。 [/报价]

    感谢您的确认。 您能否尝试注释其他任务并直接运行 GPIO、如果发生异常、请检查它?

    #define keep_aliive_pulse_task_pri 14U

    我假设 GPIO 任务是系统中运行的最高优先级任务。 这是正确的吗?

    此致、

    Tushar

    [/quote]
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [报价 userid="16414" url="~/support/processors-group/processors/f/processors-forum/1511275/sk-am62a-lp-sk-am62a-lp-facing-issue-to-generate-13us-on-period-pulse-using-clockp_usleep-in-mcu-r5-fw-on-mcu-gpio-pin/5813059 #5813059"]
    define Keep_Alive_pulse_task_pri 14u

    我假设 GPIO 任务是系统中运行的最高优先级任务。 这是正确的吗?

    [/报价]

    尊敬的 Tushar:

    优先级较高的主任务;其余所有任务的优先级都较低(保持活动任务)。 (值越高意味着优先级越高)

    尽管如此、我使用低于优先级值进行了检查、但仍然面临问题并在中获得了随机行为  ClockP_usleep() 功能和  GPIO 高为大约956us 而不是13us ,即使硬核值设置13us 在  ClockP_USleep ()保持活动功能。  

    define Keep_Alive_pulse_task_pri 25u

    谢谢、

    Nisarg

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

    尊敬的 Nisarg:

    您是否尝试过注释所有任务并仅运行 GPIO 切换? 您仍然面临这个问题吗?

    请通过执行上述申请实验来帮助我们缩小问题范围。

    此致、

    Tushar

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

    尊敬的 Tushar:

    我尝试禁用主要任务、并检查在该案例中很少观察到。  (在此过程中启用的配置和所需任务很少)。   

    启动  ClockP_usleep() 取决于 FreeRTOS 或基于 TI 硬件? 请提供详情。  为什么在小微秒值中观察到这种问题?   Is  ClockP_USleep ()是否稳定在较小的微秒值 (在固件中启用多个任务期间)?

    谢谢、

    Nisarg

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

    尊敬的 Nisarg:

    我尝试禁用主要任务、并在这种情况下检查发现它很少

    感谢上述确认,没有多个任务,它可以正常工作。  

    执行此操作  ClockP_usleep() 取决于 FreeRTOS 或基于 TI 硬件? [/报价]

    这取决于 TI 硬件。  

     是  ClockP_USleep ()稳定在较小的微秒值或不稳定 (在固件中启用多个任务期间)?

    我认为这不是 ClockP_usleep API 的问题。 您能告诉我们您在其他任务中进行的所有处理工作吗?

    还可以通过启用发生问题的任务来进行实验? 分享任务的详细信息。

    此致、

    Tushar

    [/quote]