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