RM57L843: How to get into the idle mode of RM57L843

Hello Yue,

One way to gauge if the WFI instruction and LBIST execution are happening is to place a while(1) routing after the call to the STC LBIST. If the code reaches the while(1) then the CPU reset didn't happen and LBIST wasn't executed. Normally, there is a check for the CPU reset at the start of the code and restore the context or set a flag indicating the CPU reset occurred so that the code can jump to the proper post-STC functionality.

When attempting to debug STC, it is very difficult given that the CPU goes offline for a bit and is reset. The debugger usually looses it's debug settings such as breakpoints and such due to the CPU reset. My recommendation for debuging this type of function is to utilize GIO toggling before and after execution that can be monitored on a scope along with running in free run mode within or outside the debugger environment.

Hi Chuck,

          As you said, a while(1) has been added after the _SL_Kickoff_STC_execution() .

When I "Break" , the program stop at the _SL_Kickoff_STC_execution() but the CPU doesn't reset!  When I "Go", the while(1) is executed!

If I don't "Break" and "Go", the while(1) would never been executed.

It seems like the CPU doesn't reset!

Hello Yue,

I don't see an issue with the behavior you describe. If you run without interruption (i.e., no break points) you should see a warning from the IDE that the device was reset. As noted in the code, the code after the call to _SL_Kickoff_STC_execution(), will never be reached which is expected due to the CPU reset.

In your startup code, there should be logic to read the SYS_ESR register and determine if a CPU reset occurred and direct the program counter to the place it should pick up execution. Unless there is also code to save the breakpoint information prior to execution of the STC LBIST and then restore it after the CPU reset, this information will be lost due to the CPU reset as well. For this reason, it is very difficult to debug or track the STC progress through the IDE. This is why I suggested the use of pin toggling to track the events with a scope during a free run scenario. You could also use UART messaging or internal flags and counter variables to verify what is happening in the device during operation.

Hi chuck,
I am using the HAL code generated by HALCoGen! In the startup file, I noted that the SYSESR register is cleared by the "switch case", and I have modified that part. But the problem is still there! Would mind helping me checking the initial code below?? Thanks!

void SL_SelfTest_STC(void)
{

register uint32 tempVal = 0U;

/* Configure the clock divider */
stcREG1->STCCLKDIV = ((uint32)2U << 24U);

/* Clear CPU RST status bit in the System Exception Status Register */
systemREG1->SYSESR &= (uint32)(1U<<5U);


/* 40 test intervals*/
stcREG1->STCGCR0 = ((uint32)stcREG1->STCGCR0 &(uint32)(0U << 16U));
stcREG1->STCGCR0 = ((uint32)stcREG1->STCGCR0 |(uint32)(40U << 16U));

/* restart self test from beginning*/
stcREG1->STCGCR0 = ((uint32)stcREG1->STCGCR0 |(uint32)(1U));

/* Setup the timeout value */
stcREG1->STCTPR = 0xFFFFFFFF;

/* Select only core 1 for self-test */
stcREG1->STCGCR1 |=(uint32)(0x5 << 8U);


for (tempVal = 0u; tempVal < 320u; tempVal++) {
}

/* Enable STC run */
stcREG1->STCGCR1 |= 0x0A ;

/* Kick off the STC execution */
_gotoCPUIdle_();
while(1)
{
vLedSet(0, 0);
vLedSet(1, 0);
vLedSet(2, 0);
vLedSet(3, 0);
vLedSet(4, 0);
vDelay(100000);
vLedSet(0, 1);
vLedSet(1, 1);
vLedSet(2, 1);
vLedSet(3, 1);
vLedSet(4, 1);
vDelay(100000);
}
/* Execution never comes here !!! */
//return (0);
}

Hello Yue,

If you are directly using the Halcogen startup code combined with any special updates from you posted information above, I can look at this over the next couple of days on my bench. Can you remind me again if you are using a specific TI development board (EVM or Launchpad) or if you are using your own custom PCB?

Hello Chuck,

I am testing the STC module on TI TMDXRM57LHDK  and I can share my IAR project with you if you need it!

Hello Yue,

I don't have an IAR setup, but if you can share the source and the halcogen files (.hcg and .dil files for your halcogen project). I can then setup and import the project into CCS. If we can't reproduce the issue, I will look into setting up an IAR workspace and doing the same. I am also going to see if our SW team can have a look since they should have the IAR bench setup.

Hi Chuck,

I have upload my hcg and IAR project. I hope that could be helpful!

BR.

 

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/312/3858.IAR.7z

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/312/4667.STC-test.7z

Hi Chuck,

Have you check the project I shared last week? Does it work in your IDE?

BR!

Yue,

My apologies for the delay. I have discussed this with one of my associates and they have offered to debug this issue since they have both the RM57 HDK hardware and an IAR IDE setup on their bench. They should be able to get back with you within the next day or so.