• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 101 subscribers
  • Views 422 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM6442: Abnormal values ​​appear when measuring GPIO interrupt interval using ClockP_getTimeUsec function in gpio interrupt service function

wen f
Prodigy 235 points
Part Number: AM6442

Tool/software:

Hi Ti,

SDK version: mcu_plus_sdk_am64x_08_06_00_45

Test environment description:
I run a program based on the FreeRTOS version on the r5fss1_0 kernel. In the program, I enabled the external GPIO pin (GPIO0_37 -> GPMC0_WAIT0 (W19)) interrupt configuration. I input a square wave with a period of 100us to the pin externally, and then I use the ClockP_getTimeUsec function in the GPIO interrupt service function to measure the interrupt interval. Normally, the measured interrupt interval should be stable at around 100, but I recorded the measured values ​​through some software methods (wave recording), and I found that there would be abnormal values ​​of up to about 1100. For this reason, I did a lot of debugging work. I found that by modifying the priority of the tick interrupt, as long as the tick interrupt priority is higher than the GPIO interrupt priority, the abnormal value will not appear. So I would like to ask TI experts, what level is recommended for the tick interrupt priority? In addition, can my problem be explained as related to the tick interrupt priority? Is my handling correct?

Here are my key parts of the code for your reference:

5807.example.c
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
volatile uint32_t ISR_TimeValues[4];
void getCtrlCycleTime(void)
{
volatile static uint64_t preTime = 0;
volatile uint64_t dTime = ClockP_getTimeUsec();
if (dTime > preTime)
{
ISR_TimeValues[0] = dTime - preTime;
}
preTime = dTime;
}
/* GPIO Pin interrupt function with a period of 100us */
static void GPIO_BankIsrFxn(void *args)
{
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Regards,

wen

  • 0
    Prodigy 235 points

    Reference for recording data of ISR_TimeValues :

  • 0 in reply to wen f
    TI__Mastermind 38923 points

    Hello Wen,

    Thanks for reaching out to Texas Instruments E2E support forum.

    I have taken your inputs and working on it. Please allow some time to revert back.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    TI__Mastermind 38923 points

    Hello Wen,

    Thanks for your patience.

    wen f said:
    I found that there would be abnormal values ​​of up to about 1100.

    Can you please try once running the example after following the below mentioned steps.

    • Comment the WFI instruction from the vApplicationIdleHook() API. The API can be found at ${MCU+SDK}/source/kernel/freertos/portable/TI_ARM_CLANG/ARM_CR5F/port.c file.

    • Rebuild the kernel using below commands. Run the below commands from the ${MCU+SDK} root directory.

    Fullscreen
    1
    2
    3
    cd source/kernel/freertos/
    gmake -s -f makefile.am64x.r5f.ti-arm-clang
    gmake -s -f makefile.am64x.r5f.gcc-armv7
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    • Rebuild the example application and run it.

    Please let us know the results.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 235 points

    Hi Tushar,

    I have completed the test, and this change did not improve the problem. There is still an error period data of about 1ms.

    Regards,

    Wen

  • 0 in reply to wen f
    TI__Mastermind 38923 points

    Hello Wen,

    wen f said:
    There is still an error period data of about 1ms.

    Can you please also confirm have you build the kernel for debug mode also?

    I assume that you are building the example for debug mode, so you will need to rebuild the kernel for debug mode also.

    Please run below command from MCU+SDK root directory to build kernel for debug mode.

    Fullscreen
    1
    2
    3
    4
    5
    6
    cd source/kernel/freertos/
    gmake -s -f makefile.am64x.r5f.ti-arm-clang PROFILE=debug clean
    gmake -s -f makefile.am64x.r5f.gcc-armv7 PROFILE=debug clean
    gmake -s -f makefile.am64x.r5f.ti-arm-clang PROFILE=debug
    gmake -s -f makefile.am64x.r5f.gcc-armv7 PROFILE=debug
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    After rebuilding kernel, please rebuild the example project.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 235 points

    Hi Tushar,

    I have confirmed that the kernel has been built, because I have added the kernel source code to the project for compilation, but the error data still appears.

    Regards,

    Wen

  • 0 in reply to wen f
    TI__Mastermind 40031 points

    Hello Wen,

    I am not sure if the above Tushar proposal is done correctly or not in your workspace .

    To confirm above changes are there in your workspace ,  put the break point in vApplicationIdleHook  API and the se whether wfi instruction is executing or not. If it is not executing, then recompile debug kernel libraries and after that rebuild your application too in debug mode 

    Otherwise with the above proposal , Please confirm with any GPIO pin toggling rather than cycleP_counter API in ISR routines and share the results.

    Reagrds,

    Anil.

  • 0 in reply to Swargam Anil
    Prodigy 235 points

    Hi Anil,

       I confirmed the modification of this part of the code again, and confirmed through break point debugging that this change has no effect on my measured results. I can still get abnormal values ​​of more than 1000us.

    Regards,

    Wen

  • 0 in reply to wen f
    TI__Mastermind 40031 points
    wen f said:
       I confirmed the modification of this part of the code again, and confirmed through break point debugging that this change has no effect on my measured results. I can still get abnormal values ​​of more than 1000us.

    Hello Wen,

    We have not seen these issues on our EVM.

    This is the only problem with the measurement of GPIO timing.

    We suggested that instead of checking with the clock_timerP, please check with GPIO toggling and share the test results.

    As already, we have confirmed that the PMU timer does not give proper results in freeRTOS applications.

    Can you please confirm how you measured the above test results ? Is it with GPIO or ClockP timer ?

    If you measure with a clockP timer, then there is a problem with the GPIO measurement .

    Regards,

    Anil. 

  • 0 in reply to Swargam Anil
    Prodigy 235 points

    Hi Anil,

    Test code reference:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    volatile uint32_t ISR_TimeValues[4];
    void getCtrlCycleTime(void)
    {
    volatile static uint64_t preTime = 0;
    volatile uint64_t dTime = ClockP_getTimeUsec();
    if (dTime > preTime)
    {
    ISR_TimeValues[0] = dTime - preTime;
    }
    preTime = dTime;
    }
    /* GPIO Pin interrupt function with a period of 100us */
    static void GPIO_BankIsrFxn(void *args)
    {
    volatile uint32_t pinNum = (uint32_t)args;
    volatile uint32_t intrStatus;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    1) I did not use PMU timer to measure and calculate the gpio interrupt interval.
    2) I used ClockP_getTimeUsec function to calculate the gpio interrupt interval by taking the difference between two interrupts, and the system's tick interrupt is clock_timerP enabled, and the priority of the tick interrupt is very low by default, and is lower than the gpio interrupt.
    3) I have confirmed that the gpio interrupt is not lost, and I simulated the gpio interrupt through another 100us period timer interrupt for testing, and also called ClockP_getTimeUsec function to calculate the interrupt interval by taking the difference. Surprisingly, there is no abnormal value exceeding 1000us, but a very stable normal value of 100us.
    4) In addition, I also found that when executing a small amount of load code in the 100us period gpio interrupt, the gpio interrupt interval is obtained by directly obtaining the count value of a timer and then multiplying it by the corresponding coefficient. At this time, there is no abnormal value exceeding 1000us.

    Regards,

    Wen

  • 0 in reply to wen f
    TI__Mastermind 40031 points

    Hello Wen,

    Please check with GTC timer or GPIO toggling and share the test results.

    Here, why I am suggesting many times rather than with the above PMU or ClockP_getTimeUsec since these belong to the PMU timer and FreeRTOS timer.

    So, the PMU timer does not give proper results when an application is running in freetops.

    ClockP_getTimeUsec Timer is not a continuous timer, which means that every time it is loaded with the freeRTOs schedule expired time as start of the counter, and it will never start from 0x00.

    In this case, we may get issues while measuring these latencies .

    Please confirm this testing with toggling GPIO or GTC timer and share test results.

    This testing will be confirmed either this issue with the measurement method or GPIO interrupt.

    Regards,

    Anil.