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

IEC60730SWPACKAGES: Occasionally the CPU reg self-test fails

Jim Chen (SEM)
Intellectual 2330 points
Part Number: IEC60730SWPACKAGES

Hi experts,

My customer is using IEC60730 safety lib to do UL certification based on F28035, and they use STL_CPU_TEST_testCpuRegisters to test CPU regs but will fail after about one week of running.

There are some changes in the code: they don't disable the interrupts and place the CPU reg detection code in the highest priority interrupt with highest priority. And they add ST1, RPC detection into it. Is there a risk that this may cause the self-test to fail?

They found that the registers that failed the test were among SP,ST0,DP,IER,IFR,DBGIER and They don't want to disable interrupts due to system control requirements. Is it caused by the addition of ST1 and RPC self-test? I think that a sudden interrupt while testing IFR causes the IFR to be changed, which may cause the self-test to fail. Not sure if my thinking is correct?

By the way, another department of that customer disabled the interrupt when testing the CPU reg self-test code, but it will reset when testing IER IFR. Does reading and writing to IER and IFR cause a reset?

BR

Jim

  • 0
    TI__Guru 53045 points

    Hi Jim,

    It does sound like they might be getting an interrupt. Are they making sure to clear IER before testing ST1 or avoiding clearing INTM? If any bits are set in IER while INTM is 0, there is a chance they could get an unwanted interrupt.

    Whitney

  • 0 in reply to Whitney Dewey
    TI__Intellectual 2330 points

    Hi Whitney,

    Thanks for reply. You mean that when they test ST1 and some bits of IER are set, there may be an unwanted interrupt? But they do this in the interrupt with highest priority (ADCINT1). Does it affect the IER or IFR self-test?

    Today they find that the reason why the self-test fails is that the data read from IFR is different from the data written into IFR.

    Another question is that they say if disabled interrupt and then do IER, IFR self-test, CPU will reset sometimes. They want to know why it will result in CPU reset, is there a risk that do IER or IFR self-test will cause CPU reset?

    BR

    Jim

  • 0 in reply to Jim Chen (SEM)
    TI__Guru 53045 points

    The priority is used to determine who gets to run first if multiple interrupts are pending, then once you're in an ISR, the IER is cleared and INTM is set by the hardware, so nothing can interrupt it. You can see the behavior described in this doc. If you reenable interrupts from within the ISR though, you're essentially enabling interrupt nesting.

    Also, there's not really anything preventing interrupts from propagating to the IFR registers during the test (unless they disable them in the PIE or at the peripheral level), so although this function saves and restores IFR, an interrupt arriving in IFR during this test will be cleared by the restore or could cause a failure of this test. 

    I've never seen the CPU test reset the device before. Is it going through an ITRAP or NMI ISR before the reset? Can they tell if it was the watchdog?

    Whitney

  • 0 in reply to Whitney Dewey
    TI__Intellectual 2330 points

    Hi Whitney,

    Thanks a lot for your reply.

    My customer now try to disable INTM to test CPU registers and they want to know if there are other cpu registers like IFR maybe changed in the ISR which may lead to self-test failure such as PC, RPC, ACC. And they want to ask which registers in ACC, P, XAR0 – XAR7, XT, SP, IFR,
    ; ST0, DP, IER and DBGIER need to save and restore during the self-test? They can find XAR1 , XAR2, XAR3, SP, ST0, DP, IER, IFR and DBGIER need to save and restore. What about ACC, P, XAR0,XAR4~XAR7, XT?

    Whitney Dewey said:
    Can they tell if it was the watchdog?

    They think the watchdog cause the reset but they don't know why testing IER and IFR will lead to watchdog reset.

    BR

    Jim

  • 0 in reply to Jim Chen (SEM)
    TI__Guru 53045 points

    Jim,

    They should check the Compiler User's Guide chapter "Register Conventions" for an explanation about whey some registers are saved/restored by the function and others are not. Basically if it's "Save on Entry" or not listed (registers the compiler wouldn't use on its own like IER) you need to save/restore it when writing your own assembly code if you use it.

    Whitney