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.

TMS570 STC Undefined Instruction Exception

Other Parts Discussed in Thread: TMS570LS3137

Hello,

i'am trying to implement an STC Runtime check into an AUTOSAR Stack using your SafeTI Diagnostic Library.

This is my function which calls the API:

void stlDrv_STC_RuntimeTest(void)
{
    SL_STC_Config 			stcSelfTestConfig;
    SL_STC_FailInfo         failInfoSTC;        /* STC Failure inforamtion */

	__disable_irq();

	/* execute the test */
	stcSelfTestConfig.stcClockDiv		= 1; 											/* STC Clock divider = 1 */
	stcSelfTestConfig.intervalCount 	= 1;
	stcSelfTestConfig.restartInterval0 	= TRUE; 										/* Start from interval 0 */
	stcSelfTestConfig.timeoutCounter 	= 32760; 	/* Timeout counter */

	/* do lock step test and mark it*/
	myFaultInjected = 0x12345678;
	/* save the core register set */
	_CoreRegisterSetSave_(&myCoreRegisterSet[0]);
	/* save the stacks of the banked registers */
	_CoreBankRegisterSetSave_(&myCoreRegisterSet[16]);

	SL_SelfTest_STC(STC_RUN, TRUE, &stcSelfTestConfig);

	/* Reentry after CPU Reset */
	myFaultInjected = 0x00000000;

	/* switch back to System Mode */
	__asm( "	cps	#0x1F" );
	/* restore stack pointers */
	_CoreBankRegisterSetRestore_(&myCoreRegisterSet[16]);


	SL_SelfTest_Status_STC (&failInfoSTC);
	if (ST_FAIL == failInfoSTC.stResult)
	{
		stlDrvErrorCounter++;
	}
	else
		stlDrvPassCounter++;

	/* enable the interrupts again, because they have been disabled by the test */
	__enable_irq();
}

During my startup code at the very beginning I mask the myFaultInjected variable and jump back into that function. But it seems that there is something wrong because when I connect an debugger after executing I am standing at the Undefined Instruction Exception. Here is the part of the startupcode:

    ldr r0, =myFaultInjected
    ldr r1, [r0]
    ldr r2, =0x12345678
    cmp r1, r2
    bne no_stc
    ldr r0, =myCoreRegisterSet
    bl _CoreRegisterSetRestore_       
no_stc:	// Standard init

I attached the executable for you. Maybe it helps. 7612.exe.zip

The API call is @ 0xBE5C

Thanks and Regards,

Christopher

  • Hello Christopher,

    Generally what causes this type of error is when all of the CPU registers are not properly restored after execution of the CPUBIST. i.e., the CPU BIST is a destructive test and all of the CPU registers need to be saved before and restored or reinitialized after the test. It is highly likely that the program counter or stack pointer is getting corrupted and the code is jumping to some unprogrammed or unintended location causing the error.

    If the device is stuck in the invalid instruction service routine, then you should be able to examine the CPSR and other CPU registers to note where code execution was before jumping to the exception. This should give some clues what is happening.

  • Hello Christopher,

    I have modified the sample demo project that comes with the safety library installation package to emulate the scenario similar to yours. I have made a small change to the code in _CoreRegisterSetRestore_ to point the PC to jump to the right location (which is after the call to SL_SelfTest_STC in the function you have provided)

    I have
            add r14, r14, #0x1C

    in place of

            add r14, r14, #0x18

    Other than this I'm running the code in superviser mode. (In your case it is system mode)
    Also my initial startup code is entirely in C instead of assembly.

    The same sequence runs fine with this project. Please check with this project and along with some details given below.

    There seems to be no problem with the SL_SelfTest_STC module in itself, it seems to be running fine.
    As Chuck has indicated, it is important to know at what point the abort is being created? Whether after the STC run (that is after CPU reset) or before and at what point?

    You may also need to keep a check on the execution mode as the program flows. (un-necessary switches to different modes might affect the stack pointer [SP] and in turn lead to sort of problems which you descirbe [such as undef instruction abort])

    This part of your code seems suspicious -

        /* switch back to System Mode */
        __asm( "    cps #0x1F" );
        /* restore stack pointers */
        _CoreBankRegisterSetRestore_(&myCoreRegisterSet[16]);

    After the call to _CoreBankRegisterSetRestore_ it would be in user mode (as the assembly code ends with switch to user mode). This would affect the SP. Is this intentional? (Since in the earlier statement you have made a switch to system mode)

    A point to note: It would be required that you run the STC selftest with the debugger disconnected, since after the reset some debug information might be lost. (With this in mind use of halt instructions as inline assembly __asm(" b #-8 "); might be useful while debugging - in a sequence like disconnect target -> POR -> connect target)

    Please find attached support project files (running on TMS570LS3137) for reference

    6283.TMS570LS3137 project.zip

    Regards,
    Sharath

  • Thanks for your investigation. I look into it and reply after.


    Regards,

    Chrstopher

  • This morning I had some more time to investigate the problem.

    You are right with the mode switches. They were at a false position. I corrected it and now I can run the code a bit further.

    The STC resets the CPU and it gets back into the RuntimeSelftest-function. But after I active the Interrupts at the end again, there is something wrong. So i get stuck into the undefined instruction exception. I can't catch the irq exception with the debugger. Without activating the irqs the OS runs in idle mode without problems.


    I can't check the link register when I am the undefined instruction exception because it seems that I have lost the thumb mode und so my branch to the exception handler is the next undefined instruction.

    Update:

    I forget to reset the TE-Bit in the c1, System control register to enable Thumb exception generation after the CPU reset. Now it works perfectly.

  • Christopher,

    I'm glad you were able to work through the issues. Please mark the post(s) that provided you with the answers as verified so that others can see that this information was the key to your problem. Also, by marking the answers verified, it closes the thread.

  • Hello Sharath,
    We are trying to do the same thing, it will be helpful if you could provide the code for
    "_CoreRegisterSetSave_(&myCoreRegisterSet[0]); and _CoreBankRegisterSetSave_(&myCoreRegisterSet[16]); " and code for restore the same.
    Thanks in advance.