• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 98 subscribers
  • Views 145 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Facing issue to generate 13us ON-Period pulse using ClockP_usleep() in MCU-R5 fw on MCU-GPIO Pin.

Nisarg Prajapati
Intellectual 430 points
Part Number: SK-AM62A-LP

Tool/software:

Hi Team,
Using the code snippet below, we are trying to generate pulse on MCU-GPIO Pin with 13us ON-Time and 10ms period. We added this logic in one task from where it is generate keep-alive pulse of 13us on GPIO-Pin in particular condition.
MCU-SDK-Version:- mcu_plus_sdk_am62ax_09_02_00_38
Code:- 
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 */
    }

}
During testing we found that after Reboot randomly observed that 956us ON-Period generate even though we have configured 13us (hard-core value) in ClockP_usleep() function.
Does ClockP_usleep() function stable/working for small microseconds values configuration or not? Kindly provide solution on above issue.
Any additional configuration require to before use ClockP_usleep() function ? Please provide details on it also.
Normal-Pulse:-  (Configure 13us sleep  (using ClockP_usleep)  and getting pulse width 13.89 us)
Higher ON-Time Pulse (Issue randomly observed)   (Configure 13us sleep  (using ClockP_usleep)  and getting randomly pulse width 956.3 us)
Note: We are running applications on the MCU-R5 core, along with Linux running on the A-53 core.
Thanks,
Nisarg
  • 0
    Intellectual 430 points

    Hello Team,

    Any update on this ?

    Thanks,

    Nisarg

  • 0 in reply to Nisarg Prajapati
    TI__Mastermind 48868 points

    Hi Nisarg,

    Is GPIO the only task running in the application? 

    Are there any other task also running? What is the priority of each task and it's period of occurrence?

    Nisarg Prajapati said:
    getting randomly pulse width 956.3 us

    Does this means that GPIO signal was high for 956 us instead of 13us? How many times this issue occurs?

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Intellectual 430 points

    Hi Tushar,

    No there is multiple task is running in the application. This keep-alive task run continuously when particular condition enable; In particular condition false in that case put the task in sleep for milliseconds time and wake-up after that time for check condition true or false. Please check code snippet in case description. We have set keep-alive task priority 14 in Task Creation (KEEP_ALIVE_PULSE_TASK).

    #define KEEP_ALIVE_PULSE_TASK_PRI 14U

    For remaining task; We have set task priority 12 or less then 12. 

    Tushar Thakur said:

    Does this means that GPIO signal was high for 956 us instead of 13us? How many times this issue occurs?

    Yes,  GPIO high for the around 956us instead of the 13us even though hardcore value set 13us in ClockP_usleep() function for keep-alive.

    In Soft-Reboot;  Observed this issue around 3 times; when check 5 times.

    In HW-Reboot;  Observed this issue around 4 times; when check 10 times.

    Please help us on this issue asap.

    Thanks,

    Nisarg

  • 0 in reply to Nisarg Prajapati
    TI__Mastermind 48868 points

    Hi Nisarg,

    Nisarg Prajapati said:
    No there is multiple task is running in the application.

    Thanks for the confirmation. Can you try commenting other task and just running the GPIO, check for the abnormality if it happens?

    Nisarg Prajapati said:
    #define KEEP_ALIVE_PULSE_TASK_PRI 14U

    I assume the GPIO task is the highest priority task running in the system. Is this correct?

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Intellectual 430 points
    Tushar Thakur said:
    Nisarg Prajapati said:
    #define KEEP_ALIVE_PULSE_TASK_PRI 14U

    I assume the GPIO task is the highest priority task running in the system. Is this correct?

    Hi Tushar,

    Main-Task having default-higher priority; rest all the task having lower priority compare to this task (keep-alive task). (Higher value means Higher priority)

    Even, I checked with below priority value still facing issue and getting random behavior in the ClockP_usleep() function and GPIO high for the around 956us instead of the 13us even though hardcore value set 13us in ClockP_usleep() function for keep-alive. 

    #define KEEP_ALIVE_PULSE_TASK_PRI 25U

    Thanks,

    Nisarg

  • 0 in reply to Nisarg Prajapati
    TI__Mastermind 48868 points

    Hi Nisarg,

    Have you tried commenting all task and just running the GPIO toggle? Are you still facing the issue?

    Please help us narrowing the issue by performing above requesting experiment.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Intellectual 430 points

    Hi Tushar,

    I have tried to disable major tasks and check in that case observed it very rarely.  (Few configurations and required tasks are enable during it).  

    Does this ClockP_usleep() depends on FreeRTOS or TI-HW-based ? Please provide details on it.  Why this kind of issue observed in small microseconds values ?  Is ClockP_usleep() stable for the smaller microseconds values or not  (during multiple task enable in firmware)?

    Thanks,

    Nisarg

  • 0 in reply to Nisarg Prajapati
    TI__Mastermind 48868 points

    Hi Nisarg,

    Nisarg Prajapati said:
    I have tried to disable major tasks and check in that case observed it very rarely

    Thanks for the above confirmation that without multiple task it works fine. 

    Nisarg Prajapati said:
    Does this ClockP_usleep() depends on FreeRTOS or TI-HW-based ?

    This depends on TI HW. 

    Nisarg Prajapati said:
     Is ClockP_usleep() stable for the smaller microseconds values or not  (during multiple task enable in firmware)?

    I don't think this is an issue with the ClockP_usleep API. Can you please tell us what all processing you are doing in other task.

    Also experiment by enabling which task the issue occurs? share the details of the task.

    Regards,

    Tushar