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.

RM57L843: SL_SelfTest_STC does not generate CPU reset

Part Number: RM57L843
Other Parts Discussed in Thread: HALCOGEN

Hi,

My customer is developing software and their startup code is based on below file.
\ti\Hercules\SafeTI Diagnostic Library\2.4.0\demo_app\HALCoGen\RM57L843_NoOS\source\HL_sys_startup.c

At the end of _c_int00(), SL_SelfTest_STC(STC1_COMPARE_SELFCHECK, TRUE, &stcSelfTestConfig) is called.
Then, at the end of SL_SelfTest_STC(),  _SL_Kickoff_STC_execution() is called and CPU is reset.
This is an expected behavior.

But in customer's system, CPU reset does not happen most of the time (9 times in 10 trials).
Customer did some investigation and found the code reaches properly to _SL_Kickoff_STC_execution(), but no CPU reset is generated.
It seems _SL_Kickoff_STC_execution() does not do anything special according to sl_asm_api.asm.

;/* Kick off the STC execution */
	.def _SL_Kickoff_STC_execution
    .asmFunc
_SL_Kickoff_STC_execution

		 WFI
		 MOV R0, R0
		 MOV R0, R0
		 MOV R0, R0
		 MOV R0, R0
		 MOV R0, R0
		 B _SL_Kickoff_STC_execution ; This would ensure that the CPU retries WFI
		 							 ; until LBIST is indeed entered because only the CPU reset from LBIST would exit from this loop.
         BX     LR ;Though not required, to be safe adding branch here

	.endasmfunc


This behavior is observed only when no JTAG is connected.
If JTAG is connected and the code starts from CCS "SYSTEM Reset", the issue does not occur. CPU reset is always generated after _SL_Kickoff_STC_execution().

What is potential cause of such behavior?

Thanks and regards,
Koichiro Tashiro

  • Hi Koichiro-san,

    When WFI instruction is executed, it sends a signal (STANDBYWFI) to the STC controller to start the self check. After the self check, a CPU reset will be asserted. This will force the CPU to start from the reset vector at 0x0 again.

    But in customer's system, CPU reset does not happen most of the time (9 times in 10 trials).

    I think the WFI is not executed. Does your customer see any exception for example Undef or Abort? Can you please check if you have any pending interrupts to the CPU? If you have an asynchronous abort but the CPU has masked the asynchronous abort with the A-bit in the CPSR, then the CPU will not enter standby even after executing WFI. So please check to see if you have any pending interrupts. It may be hard to know if you have any imprecise abort as by default the A-bit is set. You can try to clear the A-bit in the beginning of your program and see if WFI is taken or not.

    3.7.8 The A bit  -- from ARM Cortex-R5 TRM (DDI0460D)
    The A bit is set automatically by certain exceptions and is written by privileged software. It disables asynchronous Data Aborts. For more information on how to use the A bit,

  • Hi QJ,

    You can try to clear the A-bit in the beginning of your program and see if WFI is taken or not.

    Could you tell me how to clear the A-bit?
    It seems we have a macro to get CPSR value. Does below work?

    	_getCPSRValue_();
    	asm(" BIC r0, r0, #0x10");
    	asm(" MSR CPSR, r0");


    As the issue does not happen if JTAG is enabled.
    Does this make sense A-bit is related?

    Thanks and regards,
    Koichiro Tashiro

  • Hi Koichiro-san,

    Arm architecture manual says that:

    When a processor issues a WFI instruction it can suspend execution and enter a low-power state. It can remain in that state until the processor detects a reset or one of the following WFI wake-up events:
    • an IRQ interrupt, regardless of the value of the CPSR.I bit
    • an FIQ interrupt, regardless of the value of the CPSR.F bit

    So you may need to disable interrupts in VIM in the '_SL_Kickoff_STC_execution' funciton to avoid perpetually skipping the WFI.