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.

AM2634: RTI timer behaviour with Debug UART

Part Number: AM2634

Tool/software:

Dear Team,

I just found strange behavior of RTI timer with debug uart,

Timer interrupt is configured for 1us and its working fine if UART debug log not used,

but whenever UART debug log are on  in infinite loop timer interrupt is not occur on time some times its coming 1ms, 5ms  or less than 1ms (mean timer is not curtain)

kindly let me know why such kind of behavior  

  • Hello,

    Apologies for the delay in looking into this. I will be running some tests on this on Monday. 
    For now, can you try and adjust the interrupt priority of the RTI to be higher than the UART debug log My initial thoughts is that since their interrupt priorities are the same, the UART debug interrupt triggers first, causing a delay in the RTI interrupt.

    Thank you,

    Susan

  • Hello,

    Were you able to test if setting the interrupt priorities fixed your issue with the RTI timer?

    Thank you,

    Susan

  • I test upto 1 RTI interrupt priority but results are same

    you just try on your end,

    while(1){

    USE  DebugP_log("HELLO")

    with 1us RTI interrupt and test on any gpio  

  • Hello,

    So I spoke with some of our software experts on this. The statement was that you should NOT use the debug logs in benchmarking or production code. The DebugP_log API uses a portion of the CPU cycles, which will mess up time profiling.

    In fact, according to the API guide, DebugP_log should NOT be called within ISR context.

    Instead, please use the following steps:

    1. Increment a variable instead of printing logs over console
    2. Set breakpoint where the variable gets incremented
    3. use benchmark tool/ ccs profiling to get the clock cycle delta between 2 breakpoint halts

    Thank you,

    Susan Moore