• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 32 subscribers
  • Views 2076 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.

TMS570LS1114: SafeTI-Lib VIM Parity Selftest occasionally causes change in VIM-RAM interrupt table

Jan Gregorz
Prodigy 135 points

Part Number: TMS570LS1114

We are using the SafeTi Lib 2.3.1 in our project to do various selftests.

One of the tests we use is SL_SelfTest_VIM(VIM_SRAM_PARITY_TEST).

For this test, we observed the following random error:

- SL_SelfTest_VIM(VIM_SRAM_PARITY_TEST) itself passes successfully.

- After the test, the content of vimRAMLoc   ((volatile uint32 *)0xFFF82008U) has a wrong value.

- The change in vimRAMLoc only seems to affect the LowByte. (which might be coincidence, so far)

We do the selftests once per second.

Most of the time, everything is ok.

Having five devices running, this error occurs once per day.

We did set a write watchpoint in CCS debugger on vimRAMLoc to check our source code.

But there was no writing access from source code to this address.

We also changed the address of vimRAMLoc to 0xFFF82020U (VIM channel 7 RTI overflow 1).

The error then occured on the new address.

We do not have an explanation for this, because SL_SelfTest_VIM(VIM_SRAM_PARITY_TEST)

does not write to vimRAMLoc but only changes the parity bit in vimRAMParLoc.

What could be the reason for this behaviour?

Regards, Jan

  • 0
    TI__Guru**** 200976 points
    Hello Jan,

    The code doesn't write to vimRAMLoc, so the content in this location should not be changed. The content at 0xFFF82008 is 0x00018C04 (the address for phantomInterrupt in my case). What is the changed value after the error occurred? and what is the value at parity address (0xFFF82408)? The code has been running on my HDK for almost 2 hours, I haven't see the issue so far.
  • 0 in reply to QJ Wang
    Prodigy 160 points

    Hello QJ,

    in the following table there are the changed values after the error occured (yellow). The Phantom Interrupt is marked red and the used Interrupts are marked green (Ch1 is not used as Interrupt channel only for selftest). In Column "A7-12.07.17" and "H1-13.07.17" channel 7 (0xFFF82020) was used for VIMParity test.

    The corresponding parity results are listed below (0xFFF82400 - 0xFFF82420). "Zero" is not marked and "One" is marked green.

    There are two Scenarios if the VIMCRC happens:

    1. Only the VIMCRC appears.

    2. The VIMCRC aapears right after a VIMParitySelftest Error. If this is the case, the VIMCRC can be "reset" by reading out the corresponding table entry (e.g. 0xFFF82008) with the TMS (triggered by SCI).

    Adresse (hex) Beschreibung Interrupt H1-05.07.17 A7-05.07.17 A7-07.07.17 A1-10.07.17 A6-11.07.17 A7-12.07.17 H1-13.07.17 A3-13.07.17 A6-17.07.17 H1-17.07.17
    FFF82000 Phantom 0x00060440 0x00060220 0x00060238 0x0005FFDC 0x0005FFDC 0x0006039C 0x00060130 0x000603D8 0x0006039C 0x0006039C
    FFF82004 Ch0 ESM High 0x0005EDEC 0x0005EA78 0x0005EA90 0x0005E988 0x0005E988 0x0005EBF4 0x0005EADC 0x0005EC30 0x0005ED48 0x0005ED48
    FFF82008 Ch1 Reserved 0x00060400 0x00060200 0x00060200 0x0005FF00 0x0005FF00 0x0006039C 0x00060130 0x00060301 0x00060300 0x00060301
    FFF8200C Ch2 RTI compare 0 0x00055444 0x00055740 0x00055758 0x00054FE0 0x00054FE0 0x000558BC 0x00055134 0x000558F8 0x00055248 0x00055248
    FFF82010 Ch3 RTI compare 1 0x00055464 0x00055760 0x00055778 0x00055000 0x00055000 0x000558DC 0x00055154 0x00055918 0x00055268 0x00055268
    FFF82014 Ch4 RTI compare 2 0x00060440 0x00060220 0x00060238 0x0005FFDC 0x0005FFDC 0x0006039C 0x00060130 0x000603D8 0x0006039C 0x0006039C
    FFF82018 Ch5 RTI compare 3 0x00060440 0x00060220 0x00060238 0x0005FFDC 0x0005FFDC 0x0006039C 0x00060130 0x000603D8 0x0006039C 0x0006039C
    FFF8201C Ch6 RTI overflow 0 0x00060440 0x00060220 0x00060238 0x0005FFDC 0x0005FFDC 0x0006039C 0x00060130 0x000603D8 0x0006039C 0x0006039C
    FFF82020 Ch7 RTI overflow 1 0x00060440 0x00060220 0x00060238 0x0005FFDC 0x0005FFDC 0x00060300 0x00060101 0x000603D8 0x0006039C 0x0006039C
    FFF82400 Phantom Parity 0x00000001 0x00000001 0x00000001 0x00000000 0x00000000 0x00000001 0x00000000 0x00000001   0x00000001
    FFF82404 Ch0 Parity 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000001 0x00000000   0x00000001
    FFF82408 Ch1 Parity 0x00000000 0x00000000 0x00000000 0x00000001 0x00000001 0x00000001 0x00000000 0x00000000   0x00000000
    FFF8240C Ch2 Parity 0x00000000 0x00000001 0x00000001 0x00000001 0x00000001 0x00000001 0x00000001 0x00000001   0x00000000
    FFF82410 Ch3 Parity 0x00000001 0x00000000 0x00000000 0x00000001 0x00000001 0x00000001 0x00000001 0x00000001   0x00000001
    FFF82414 Ch4 Parity 0x00000001 0x00000001 0x00000001 0x00000000 0x00000000 0x00000001 0x00000000 0x00000001   0x00000001
    FFF82418 Ch5 Parity 0x00000001 0x00000001 0x00000001 0x00000000 0x00000000 0x00000001 0x00000000 0x00000001   0x00000001
    FFF8241C Ch6 Parity 0x00000001 0x00000001 0x00000001 0x00000000 0x00000000 0x00000001 0x00000000 0x00000001   0x00000001
    FFF82420 Ch7 Parity 0x00000001 0x00000001 0x00000001 0x00000000 0x00000000 0x00000001 0x00000001 0x00000001   0x00000001

    Best Regards,

    Helge Pape

  • 0 in reply to Helge Pape
    Prodigy 135 points

    Hello QJ,

    my colleague Helge already posted you a table with parts of the VIM interrupt table. (see post above).

    For clarification: We did the tests on several devices and software versions (which are represented by the 10 columns).

    For this reason, the interrupt adresses are not always the same.

    In column 6 and 7, we modified the VIM parity selftest to use adress FFF8201C instead of FFF80008. (VIM channel 7).

    The cells in yellow show the values, which differ from expected phantom interrupt.

    Regards Jan

  • 0 in reply to QJ Wang
    Prodigy 135 points

    Hello QJ,

    I have some update to the failing VIM parity selftests:

    In our project, there are two active interrupts, RTI and CAN1HI.

    For testing purposes, we increased the busload on DCAN1 by a factor of 20.

    As a result, the frequency of VIM parity selftest errors also increased.

    So now the question:

    - what will happen, if the VIM parity selftest is interrupted by - for example - CAN interrupt?

    - can this cause the mentioned behaviour?

    Regards, Jan

  • 0 in reply to Jan Gregorz
    TI__Guru**** 200976 points
    Hi Jan,

    Are the A7, H1, and A6 the computer names and 07.07.17, 05.07.17 the test date? If A7 is the computer name, why the addresses for all the interrupts are different between 2 tests? for example, addresses for the ESM High are 0x0005EA78 (A7, July 5) and 0x0005EA90 (A7, July 7). What are the addresses before the error occurred? Why is there a parity error "0x00000001" in the untested channel?
  • 0 in reply to QJ Wang
    Prodigy 160 points

    Hello QJ,

    A1-A7 and H1 are the names of the devices under test. The addresses are not equal for the same devices because there are different software versions. A7, July 5 is the same device as A7, July 7 but with "other" Software so the addresses for the interrupt channels are changed.

    The address before the errror occured was the address of Phantom Interrupt (red). For example: H1-05.07.17 Ch1 = 0x00060400 (after error); H1-05.07.17 Ch1 = 0x00060440 (before error).

    What do you mean with "parity error 0x00000001"? Aren't the contents of address 0xFFF82400-0xFF827FC parity bit for even and odd parity? For example: A7-05.07.17 Phantom = 0x00060220 has parity even (=0) and Ch1 = 0x0005EA90 has parity odd (=1).

    Best Regards,

    Helge

  • 0 in reply to Helge Pape
    Prodigy 160 points

    Hello QJ,

    are there new findings concerning our topic?

    Our workaround is now to save the VIMParity test cell (0xFFF82008 Ch1 "Reserved") before testing and to overwrite the corrupted cell afterwards. Therefore there is no VIMCRC Error anymore.

    To prevent the VIMParity error (which is triggered by CAN Interrupt) we deactivated the CAN Interrupt before testing and reenabled Interrupt afterwards.

    These two approaches solve our problem but we are still waiting for an explanation on what is the exact Problem here.

    Best Regards,

    Helge