• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 226 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.

SAFETI-HALCOGEN-CSP: Unit test RTI_UT_21:1 never terminates

Andrew Harrington
Intellectual 445 points
Part Number: SAFETI-HALCOGEN-CSP
Other Parts Discussed in Thread: HALCOGEN

Hi,

The SAFETI-HALCOGEN-CSP provides a number of unit tests for the RTI module (RTI_UT_01:1 to RTI_UT_21:1).
I have found that if I try to run all of these tests then RTI_UT_21:1 never terminates.

The console output is as follows:

********************************************************************************
*
* Executing Existing Test Case 57 in Sequence RTI_UT
* File : D:\MCU_FSIM\OM-8857\code\src\OM_MCU_FSIM_SwSolution\OM_MCU_FSIM_SwSolution\code\src\HAL\source\HL_rti.c
* Procedure : rtiInit
*
********************************************************************************

Call rtiInit
No exception raised


But I have also found that if I do not run RTI_UT_01:1 then RTI_UT_21:1 does terminate successfully.

Question 1: Do you know why running RTI_UT_01:1 prevents RTI_UT_21:1 from terminating.

The start-up code in RTI_UT.xlsx is
/* Run RTI on oscillator to reduce the clock speed */
systemREG1->RCLKSRC = 0;

Question 2: Why is this necessary?

As well as setting the clock source to Oscillator this sets the RTICLK1 divider value to 1.

But the note in section 2.5.1.18 of the Technical Reference Manual (spnu563a) states the following.

Question 3: Aren't these unit tests violating this constraint?

Thank you,

Andrew

  • 0
    TI__Guru**** 196306 points

    Hi Andrew,

    I will check the RTI test cases and come back later today.

  • 0 in reply to QJ Wang
    TI__Guru**** 196306 points

    Question 2: Why is this necessary?

    It is not a MUST. Using OSCIN as the RTI clock source is good way to reduce the RTI clock rate.

    Question 3: Aren't these unit tests violating this constraint?

    The VCLK is HCLK/2, it is 75MHz which is much higher than RTICLK (OSCIN/2=8MHz)

  • 0 in reply to QJ Wang
    Intellectual 445 points

    Hi QJ,

    Thank you for your reply.

    Doesn't your statement "The VCLK is HCLK/2, it is 75MHz which is much higher than RTICLK (OSCIN/2=8MHz)" depend upon certain assumptions?
    For instance assuming that the PLL is enabled.

    In our system the PLL is not enabled and consequently the VCLK and the RTI1CLK are at the same frequency.
    So, I think that in our case the statement "systemREG1->RCLKSRC = 0;" is not appropriate.

    But removing "systemREG1->RCLKSRC = 0;" from the test on its own is not enough to get the test to complete.
    I have found that I also needed to deselect test case RTI_UT_12:1 Unit test for dwdCounterEnable.


    The test case RTI_UT_21:1 calls rti_functest1() which contains a number of tests which repeated compare the value of the FRC against a threshold.
    The fact that test case RTI_UT_21:1 appears to hang implies that the FRC isn't running.

    Is there any reason why dwdCounterEnable could have an effect upon the FRC?


    Regards,

    Andrew

  • 0 in reply to Andrew Harrington
    TI__Guru**** 196306 points
    Andrew Harrington said:
    Doesn't your statement "The VCLK is HCLK/2, it is 75MHz which is much higher than RTICLK (OSCIN/2=8MHz)" depend upon certain assumptions?

    The clock source for RTICLK is selected by RCLKSRC. The default is VCLK and 75MHz is its default frequency in HALCoGen code.The other RTI clock sources are PLL, OSC, etc. I assumed that the PLL is enabled and VCLK=75MHz, and RTICLK source is VCLK

    If PLL is not enabled, and clock source is OSCLK, and GCLK=VCLK=OSCLK, I think you need to configure the RTI1DIV field of the RCLKSRC to 0x2 to reduce the RTI clock frequency (RTICLK=OSCLK/4, <VCLK/3).

    Have you run the test with the PLL enabled (VCLK>3*OSCLK)?

  • 0 in reply to QJ Wang
    TI__Guru**** 196306 points
    Andrew Harrington said:
    Is there any reason why dwdCounterEnable could have an effect upon the FRC?

    After DWD is enabled, the DWD reset or NMI will occur immediately If an incorrect value is written key register. The reset will affect FRC, and NMI might affect the FRC too based on how the NMI ISR is implemented.

    Andrew Harrington said:
    The fact that test case RTI_UT_21:1 appears to hang implies that the FRC isn't running.

    Is an external timebase (NTU) used? But if NTU is used, and if there is no NTU input pulse, the RTI timebase control will automatically switch bake to RTI clock. I am not very sure if this process halts the FRC.