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.

Problems in implementation of system tests

Other Parts Discussed in Thread: HALCOGEN

Hi,

I'm actually trying to implement the system tests mentioned in the document "TMS570LS20216S_Safety_Manual.pdf". 

Is there any source for getting informations on how to implement the tests (eg: code snippets)?

Additional to above mentioned document I also use the technical reference manual and the datasheet as information base.
Some tests are well described there, others not.

Actual I try to implent the checking of ccm_r4 on startup.

There are only two control register for ccm_r4:
CCMSR = ccm status register
CCMKEYR = ccm key register

So, for starting self test, I set CCMKEYR to 0x6. Result: nothing happens. My application waits infinite for STC (self test complete, CCMSR) being set.

What are the possible reasons for this behaviour?

I think, in further development of system tests there will be much more questions and problems like this. It would be very helpfull to get further details for implementing the tests.

Marco

 

 

  • Hi Marco,

    We are currently investigating if there is any possibility of the CCM self-test not completing correctly. I will provide a detailed response as soon as we have checked the behavior.

    In the mean while, can you confirm that the CPU is in a privileged operating mode (any mode other than user mode) when it writes to the CCM MKEY?

    Regards,

    Sunil

  • Hi Marco,

    The CCM-R4 registers can only be written to in a privileged CPU operating mode. Any mode other than the user mode is a privileged mode. A write to the CCM registers in user mode is ignored. Please ensure that the CPU is not in the user mode when writing to the CCM registers. 

    The following sequence can be used for the CCM self-test:

    • Configure MKEY = 0x6
      • This makes the CCM enter the error forcing mode, which verifies the path from the CCM module to the compare error output from the CCM
      • Note that the nERROR pin will be driven low during this self-test
    • Wait for Self-Test Complete (STC) status flag in CCM to get set
      • Check the ESMPSR (ESM Pin Status Register) to ensure that nERROR is indeed driven low
      • Clear the Compare Error (CMPE) flag in the CCM status register
      • Clear the ESM status register for group2 (channel 2 is for CCM compare error)
    • Configure MKEY = 0xF
      • This makes the CCM enter the self-test error forcing mode, which verifies the path from the CCM module to the selftest error output from the CCM
      • The nERROR pin is not driven low in this case
    • Wait for the Self-Test Complete (STC) flag in CCM to get set
      • Check that the ESM group1 status register bit 31 is set (CCM self-test error)
      • Clear the ESM group1 status register
    • Configure MKEY = 0
      • This will resume normal lock-step checking mode of the CCM

    Your feedback is certainly appreciated and it will help us improve our documentation. We will include this description as part of the CCM chapter of the TRM in the next update.

    Please let us know if you have any questions on the above sequence.

    Regards,

    Sunil

  • Hallo Sunil,

    excuse my late answer, but I wasn't at office for a few days.

    During the initialization of the CPU I had added following lines for performing self test of CCM (CCM_SELF_TEST_MODE is defined as 0x6):

      CCMKEYR = CCM_SELF_TEST_MODE;

      while((CCMSR & (1 << 8)) == 0)
      {
        ;
      }

    I've set a breakpoint on the first code line, and checked the content of CPSR's mode-bits. Result: 0b10011. In the TRM for Cortex R4F this value stands for "supervisor mode".

    I'm using IAR embedded workbench with j-link ultra.

    Regards

    Marco

     

  • Hello Sunil,

    I've just noticed the following line in the TRM of TMS570:

    23.3.5 Operation During CPU Debug Mode
    Certain JTAG operations place the CPU in a debug mode where the code execution is halted. Once this mode
    is entered, compare errors are not generated, irrespective of the compare mode the CCM-R4F is in. The
    status flags are also not updated. Normal operation is resumed only after a CPU reset is asserted.

     

    I think, thats the solution for my problem as I have the problems in debug mode. I will do some tests on it, and report my results.

    Regards

    Marco

  • Dear TI community,

    I'm lucky to have my CCM-test finished yet. Thanks to Sunil for his help.

    I'd different problems in implementing the test. Following you find a summary of my experiences I made.

    I hope, it's helpfull for anyone who wants to implement the test.
    If anyone recognizes errors in it, I would be pleased if he report it to me.

    Best regards

    Marco

     

     

    Documentation of CCM-test

    Subject

    The task of CCM (core compare module) of TMS570 is to compare the outputs of the two cores integrated in TMS570. This permanent comparison is called "lock step".

    For safety reason it's necessary to prove the correct operation of the CCM and that the paths to ESM (error signaling module) also works properly.
    There are two channels in ESM for signaling errors related to CCM:

    • Group1 channel 31: CCM self test error
    • Group2 channel 2 : CCM core compare error

    Thus, following checks has to be performed:

    1. self test of CCM
      This shows that the compare module is able to detect all differences in outputs of both cores
    2. check of path CCM self test -> ESM self test error
      This shows that a detected error results in setting a flag in ESM
    3. check of path CCM core compare -> ESM core compare error
      This shows that die CCM is able to signalize an error to ESM

    Initializations for CCM test

    Thus the ESM channels related to CCM will be checked for active state within the tests described in the following sections,
    they should be cleared previously. After that I additionaly prove that the states of the ESM flags=0

    Self test of CCM

    • Start self test by setting CCMKEYR = 0x06 (CCM self test mode)
    • Wait until self test completes (CCMSR->STC = 1 shows completion of self test)
    • The ESM group1 channel 31 should remain false (no self test error) this has to be proved
    • I found out that after test CCMSR->CPME=1 (core compare error detected).
      I guess this is the result of the compare mismatch test which is part of self test (-> [1] 23.3.2.2).
      Thus this flag has to be checked to prove functionality of core compare

    Check path for CCM self test error

    • Set CCMKEYR=0xf (self test error forcing mode). This simulates a detected error in CCM (CCM not working properly) and results in signalizing a CCM self test error in ESM
    • Right after setting the key check if an error was signaled to ESM by proving ESM group 1 channel 31=1

    Check path for core compare error

    • Set CCMKEYR=0x9 (error forcing mode). This simulates a compare mismatch of the two cores
    • Right after setting the key check if an error was signaled to ESM by proving ESM group 2 channel 2=1
    • To ensure that the MCU is able to signalize a core compare error with nError-pin prove that after the preceeding test this pin is active (=low, ESMEPSR->EPSF=0)

    Cleaning up after CCM test

    After the preceeding tests the ESM channels related to CCM signalize errors.
    By writing '1' to this channels the flags will be cleared.
    After that the nError-pin is still active. This can be deactivated by ESMEKR->EKEY=0x05.
    As the result, nError will become inactive, when LTC times out

    Remarks

    • CCMSR-STC: This flag only becomes active after completion of self test (CCMKEYR=0x6).
      In all other modes, this flag is cleared. Thus it is not possible to determine the
      completion of error forcing mode and self test error forcing mode with this.
      For these modes, the related ESM channels has to be checked right after setting the key
    • The self test of CCM does not work in debug-mode! This is described in [1] 23.3.5.
    • To ensure correct operation of CCM and correct operation of CCM self test all tests mentioned above has to be run
    • Right after switching to error forcing mode or self test error forcing mode
      the key register (CCMKEYR) is automaticilly resetted to 0 (lock step mode). Its thus not
      not nesscessary to reset it manually.

    Related documents

    [1] Technical reference manual of TMS570

  • Dear Marco,

    Thank you for the excellent test description. In fact, I have a few additional questions to this topic:

    - "Self-test Error Forcing mode" is signalling to ESM group 1 channel 31 only if I set its level to high-priority interrupt handling. Is that correct, why it is not handled in the low-priority interrupt handling settings?

    - "Error Forcing mode" is signalling to ESM group 2 channel 2 and also to ESM group 1 channel 31 if I reuse the configuration from the "Self-test Error Forcing mode" (channel 31 interrupt enabled and channel 31 interrupt level is high). I didn't find any specification about this effect, is it expected test outcome?

    Thank you

    Regards

     Vaclav 

  • Hi,

    I have a couple of questions relating to this thread.

    In the post by Marco there's a section that is labelled "Documentation of CCM-test", where did this information come from, the Technical Reference Manual (spnu499a)?

    It says that the CCM signals to the ESM on Group2 Channel2 for CCM Core Compare Errors. When I look at HALCoGen, under the ESM the Group 2 box is greyed out. How do I enable that?

    Regards

    Andy

  • Hi Andy,

    The information about the different CCM modes used in this test is present in the TRM (SPNU499a). Marco described the correct sequence that needs to be used to carry out a test of the CCM diagnostic before employing / trusting it to work correctly.

    It is better for this sequence to also be included in the TRM, and I will include this in the list of updates that we have accumulated.

    As for the HALCoGen question: the CCM mismatch error is mapped to group2 channel 2 on the ESM. The ESM response to a group2 (or group3) error is not configurable, hence the grayed out box. A group2 error will always generate a high-priority interrupt from the ESM (mapped as non-maskable FIQ on VIM channel 0) and will always drive the device nERROR pin low. The application can choose the duration for how long this nERROR pin is driven low by configuring the Low-Time Counter (LTC), also configurable via the GUI.

    Regards, Sunil

  • Hi Sunil,

    in Marco's message he describes:

    • Group1 channel 31: CCM self test error
    • Group2 channel 2 : CCM core compare error

    You said this is in the Technical Reference Manual. I have looked for this information in spnu499a & spnu499b and I can't find it. What page are you looking at?

    Regards

    Andy

  • Hi Sunil,

    Ignore my last posting, I've found it. It's not in the TRM, but the device datasheet. I can now move forward.

    Thanks

    Andy

  • Hi Andy,

    I also meant that the modes in which you can configure the CCM module are documented in the TRM. The error signal connections are defined in the device datasheet, as you indicated.

    Regards, Sunil