X-CUBE-CLASSB-U5(STL) issue(Hardfault) of TM7 test executing in ThreadX

[ChintaN1]

Hello Support team,

We are working on the Class-B on STM32U585 microcontroller-based product.

We have added the ThreadX support in the X-CUBE-CLASSB-U5(STL) library example code. 

SW Configuration :

- STL library runs the Secure region

- STL APIs calling from Non-secure regions through a Non-secure callback function or Gateway 

Issue :

When we run the TM7 STL test in the thread, the device enters into a hard fault due to assessing the secure region.

Counter Measurement check : 

- STL must be executed with privileged mode. The control register value is showing TM7  in the privileged  mode (nPRIV bit)

- STL is running in the processor mode. The control register value showing PSP mode (SPSEL bit)

- As per debugging, the TM7 test executes the External memories areas (0x6000 0000
0xDFFF FFFF) and shows errors like not accessible due to secure region.

Queries :

- Why getting issues while executing the TM7 test run in Threadx? and not getting issues without ThreadX?

If you need more information please let me know. 

I don't know exactly the root cause of the issue. Waiting for your valuable support.

Thanks & Regards,

Chintan Patel

[Petr Sladecek]

Hello,

To prevent the issue there are two options:

First Option:

• Positioned the data rw after the CSTACK via linker file

Second Option:

• Get value of PSP_LIM , and save it
• Set PSP_LIM to 0 temporary (or rather bellow the address of aStlCpuTm7VirtualStack array)
• Launch Test (TM7)
• Set PSP_LIM to saved value

[ChintaN1]

Hello Petr,

Thanks for your kind support.

Option 1: We need to check.

Option 2: We already applied it to our firmware, and it is working fine.

Thanks and regards,

Chintan Patel

[Petr Sladecek]

Hello,

we are considering implementation of the option 2 into the library at some next version if released but note each change of the library files means to pass new quite demanding and expensive recertification process for us. This is far from simple generation of a new object file unfortunately. So far the issue will be implemented at form of added note describing this limitation at the STL documentation. Anyway, the memory allocation is fully in user hands.

Best regards,

Petr

[ChintaN1]

Hello Petr

I appreciate your invaluable assistance.

We're waiting on the STL FW update that has a resolved solution.

Can the ST team provide us with a solution with an intermediate STL FW release so we can on schedule apply for our product certification?

Thanks and regards,
Chintan Patel

[Petr Sladecek · Accepted solution]

Hello,

please note that no recertification of U5 FW is planned now. Planning that is long way run taking few months (agreement between UL & ST about quotation, planning men bandwidth for retesting and generating heaps of necessary reports, finding common certification time slot, approve & reserve financial resources...). I see only follow up action to be performed ASAP - upgrading the associated User manual by proper warning note.

I believe you have complete knowledge about the problem and possible workarounds applicable easily now. I suggest just to decrease the PSP & MSP limits before calling STL_SCH_RunCpuTM7 procedure at your program and renew them back just after return from it. Occasional patch will do the same at level of the TM7 scheduler. If I understand, it is just what is done already at your side. 

Best regards,

Petr

[ChintaN1]

Hello Petr,

Thanks for your valuable time and efforts.

Thanks & Regards,

Chintan Patel

[Akanksha]

Hi Petr Sladecek

We are working on the Class-B on STM32U5 series microcontroller-based product.

Issue:
When we run the TM7 STL test single time, so code is working fine and all STL test are passes but when we run CPU test (Tm1L, Tm7, TmCB)  multiple time in every 25ms, the device enters into a hard fault.

Register "-

[ChintaN1]

Hello @Akanksha 

As per my understanding related to the PSP and MSP tests,

1. PSP (Process Stack Pointer):

   • Used for the stack of user-level tasks in an RTOS.
   • Each task typically has its own stack, and the RTOS switches the PSP to point to the stack of the currently running task.

2. MSP (Main Stack Pointer):

   • Used for system-level operations, such as interrupt handling and exceptions.
   • The MSP is typically used during the startup phase and for privileged code execution.

In an RTOS environment, the stack pointers are dynamically switched during context switching. If your testing involves verifying the integrity of PSP and MSP, failures may occur due to incorrect assumptions about their values during task execution.

There may be a couple of failure reasons,

1. Context Switching in RTOS:

   • During multitasking, the RTOS saves and restores the stack pointers (PSP and MSP) for each task. If your testing routine does not account for this, it may fail.
   • For example, if the testing routine is called during a context switch or interrupt, the stack pointers may not point to the expected locations.

2. Interrupts and Exceptions:

   • When an interrupt or exception occurs, the processor switches to the MSP. If your testing routine is called during an interrupt, the PSP may not be valid.

3. Stack Corruption:

   • If a task overflows its stack, it can corrupt the memory used by other tasks or the RTOS itself. This can lead to failures in PSP/MSP testing.

4. Testing Routine Timing:

   • If the testing routine is called at inappropriate times (e.g., during a context switch or interrupt), it may fail due to inconsistent stack pointer values.

5. RTOS Configuration:

   • Incorrect RTOS configuration (e.g., stack sizes, priorities) can lead to stack-related issues and testing failures.

STL TM7 Pre-requisite:

1. If the privileged level is not set to privilege, the CPU TM7 returns STL_ERROR.

2. By default, the STM32 interrupts and Cortex® exceptions with configurable priority are masked during the CPU
TM7 except if the user application activates STL_ENABLE_IT.

If the STL_ENABLE_IT flag is activated, the correct STL CPU TM7 behavior is not guaranteed, as the pipeline
sequence is modified. This could lead the STL to generate false test error reporting or not to detect hardware
failures.

3. The STL must be executed in thread mode in order to set the active stack pointer to the process stack pointer.
If the STL is not executed in thread mode, the CPU TM7 returns STL_ERROR. 

4. The STM32 interrupts, and Cortex® exceptions with configurable priority, are masked multiple times by the STL
during CPU TM7. Test duration Max : 422 Cycles and Maked Twice for 422 and 372 clock cycles

I hope this helps in debugging the TM7 issue.

@Petr Sladecek 

Could you share the latest updates regarding the new STL library, specifically the TM7 patch and its documentation?

Thanks,

Chintan

[Pankajkjain]

Hi @Petr Sladecek,

When I was disable the interrupt before TM7 test and enable after test, then it will work properly.
Is it correct way for this testing ?

Thanks, 

Pankaj

[Pankajkjain]

Thank You Chintan