TMS570LC4357: WFI-Instruction not starting LBIST or interconnect self-test

Hi Max,

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.

Refer below thread for more details:

(+) RM57L843: SL_SelfTest_STC does not generate CPU reset - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--
Thanks & regards,
Jagadish.

Hi Jagadish,

We tried the following:

1. Disable interrupts in VIM and CPU
2. Clear all pending interrupts in VIM

Is there a way we can check for pending interrupts/aborts outside of VIM?

Thank you and best regards,
Max

Hi Max,

Apologies for the delay, i was also stuck with other issues.

Max Wittekind said:

Is there a way we can check for pending interrupts/aborts outside of VIM?

I am not aware of that.

--
Thanks & Regards,
Jagdish.

Hi Jagadish,

We checked the VIM registers before calling the WFI instruction, and I can't find anything in the VIM that would cause the test not to start.
The following shows the state of the VIM registers:

Addr: 0xFFFFFE00 value: 0x00000000
Addr: 0xFFFFFE04 value: 0x00000000
Addr: 0xFFFFFE08 value: 0x00000000
Addr: 0xFFFFFE0C value: 0x00000000
Addr: 0xFFFFFE10 value: 0x00000003
Addr: 0xFFFFFE14 value: 0x00000000
Addr: 0xFFFFFE18 value: 0x00000000
Addr: 0xFFFFFE1C value: 0x00000000
Addr: 0xFFFFFE20 value: 0x00000000
Addr: 0xFFFFFE24 value: 0x00000000
Addr: 0xFFFFFE28 value: 0x00000000
Addr: 0xFFFFFE2C value: 0x00000000
Addr: 0xFFFFFE30 value: 0x00000003
Addr: 0xFFFFFE34 value: 0x00000000
Addr: 0xFFFFFE38 value: 0x00000000
Addr: 0xFFFFFE3C value: 0x00000000
Addr: 0xFFFFFE40 value: 0x00000003
Addr: 0xFFFFFE44 value: 0x00000000
Addr: 0xFFFFFE48 value: 0x00000000
Addr: 0xFFFFFE4C value: 0x00000000
Addr: 0xFFFFFE50 value: 0x00000000
Addr: 0xFFFFFE54 value: 0x00000000
Addr: 0xFFFFFE58 value: 0x00000000
Addr: 0xFFFFFE5C value: 0x00000000
Addr: 0xFFFFFE60 value: 0x00000000
Addr: 0xFFFFFE64 value: 0x00000000
Addr: 0xFFFFFE68 value: 0x00000000
Addr: 0xFFFFFE6C value: 0x00000000
Addr: 0xFFFFFE70 value: 0x00000000
Addr: 0xFFFFFE74 value: 0x00000000
Addr: 0xFFFFFE78 value: 0x00000000
Addr: 0xFFFFFE7C value: 0x00000000
Addr: 0xFFFFFE80 value: 0x00010203
Addr: 0xFFFFFE84 value: 0x04050607
Addr: 0xFFFFFE88 value: 0x08090A0B
Addr: 0xFFFFFE8C value: 0x0C0D0E0F
Addr: 0xFFFFFE90 value: 0x10111213
Addr: 0xFFFFFE94 value: 0x14151617
Addr: 0xFFFFFE98 value: 0x18191A1B
Addr: 0xFFFFFE9C value: 0x1C1D1E1F
Addr: 0xFFFFFEA0 value: 0x20212223
Addr: 0xFFFFFEA4 value: 0x24252627
Addr: 0xFFFFFEA8 value: 0x28292A2B
Addr: 0xFFFFFEAC value: 0x2C2D2E2F
Addr: 0xFFFFFEB0 value: 0x30313233
Addr: 0xFFFFFEB4 value: 0x34353637
Addr: 0xFFFFFEB8 value: 0x38393A3B
Addr: 0xFFFFFEBC value: 0x3C3D3E3F
Addr: 0xFFFFFEC0 value: 0x40414243
Addr: 0xFFFFFEC4 value: 0x44454647
Addr: 0xFFFFFEC8 value: 0x48494A4B
Addr: 0xFFFFFECC value: 0x4C4D4E4F
Addr: 0xFFFFFED0 value: 0x50515253
Addr: 0xFFFFFED4 value: 0x54555657
Addr: 0xFFFFFED8 value: 0x58595A5B
Addr: 0xFFFFFEDC value: 0x5C5D5E5F
Addr: 0xFFFFFEE0 value: 0x60616263
Addr: 0xFFFFFEE4 value: 0x64656667
Addr: 0xFFFFFEE8 value: 0x68696A6B
Addr: 0xFFFFFEEC value: 0x6C6D6E6F
Addr: 0xFFFFFEF0 value: 0x70717273
Addr: 0xFFFFFEF4 value: 0x74757677
Addr: 0xFFFFFEF8 value: 0x78797A7B
Addr: 0xFFFFFEFC value: 0x7C7D7E7F

Is there anything else that coul prevent an execution of WFI or selftest?

Thank you and best regards,
Max

Hi Max,

Can you please share a sample project with this issue so that i can debug it at my end.

--
Thanks & regards,
Jagadish.

Hello Jagadish,
unfortunately we cannot share our project.

The process is as follows.
- The system is booted normally
- All interrupts in the VIM are deactivated
- RTI is switched off
- Interconnect Selftest is started (set bit 24 (MASK_SOFT_RESET) in the SDC Control Register to 0x0, set bits 8-11 (DTC_SOFT_RESET) in the SCM Control Register to 0xA).
- Then execute WFI
- The test remains in an infinite loop.

Do you have any tips or other ideas for debugging?

Thank you and best regards,
Max

Hi Max,

Thanks for giving these steps, let me try to do the same and recreate the issue at my end.

--
Thanks & regards,
Jagadish.

Hi Jagadish,

Were you able to recreate the issue?

Thank you and best regards,
Max

Hi Max,

I could see the issue you are talking about on my end as well.

I am just trying to rectify it, i will provide my update ASAP.

--
Thanks & regards,
Jagadish.

Hi Max,

I created one example project for STC selftest run:

I felt debugging the project is not an ideal way to monitor the STC status, so here i used SCI peripheral to send the status to the serial port:

Like an as shown above, i am verifying the STC run status immediately after main loop starting and printing the status. And if the test is not done then i am doing the test by printing the "TESTING" and at the start of the while(1) i am printing "LOOP"

And here is my test result:

After power ON button pressed, i go the test status as FALSE, so the code went into the TESTING and there after testing the controller automatically got RESET and again the status got print again and this time the status as TRUE with the no failures. And now the code got hit the LOOP that is while(1).

I am attaching my code for your reference, please go through it:

STC_SelfTest_LC4357.zip

--
Thanks & regards,
Jagadish.

Hi Jagadish,

We are doing the same thing as you and the test is still not working.

We compared our old SW version where the tests worked with our new SW version where the same test does not work.

One thing we noticed is that the cpu is running in a different mode. The working version had the cpu in supervisor mode (CPSR register M field) and the non-working version had the cpu in system mode.

So my question is:

Is it possible that the WFI instruction is not executed or the WFI instruction is executed but the test is not started because the processor is in system mode?

Thank you and best regards,
Max

Hi Max,

My sincere apologies for the delay in my response, actually we have holiday on last Friday in TI India. And also, i was stuck with so many pending issues in this mean time.

Max Wittekind said:

One thing we noticed is that the cpu is running in a different mode. The working version had the cpu in supervisor mode (CPSR register M field) and the non-working version had the cpu in system mode.

I don't think this would be the issue because on my working code the mode is system only.

--
Thanks & Regards,
Jagadish.