cancel
Showing results for 
Search instead for 
Did you mean: 

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

ChintaN1
Associate III

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

 

1 ACCEPTED SOLUTION

Accepted Solutions

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

View solution in original post

15 REPLIES 15
ChintaN1
Associate III

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 invalid memory region. 

Please check below snap, It looks like issue of Push operation

ChintaN1_0-1692938937805.png

 

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
ST Employee

Hello,

The attached snapshot shows disassembly of single step of the test when testing pattern (0xfff94127UL stored at R3) is just pushed to SRAM (to address 0x300000b0) pointed by active SP.  It should be PSP at case of STL_TM_CPU_TM7PushPopPsp procedure. Unfortunately, the Control register content is not visible on the snapshot. Please double check if the SPSEL bit set (the STL_TM_CPU_TM7PushPopMsp test should clear the SPSEL oppositely).

At principle, the test redirects the current PSP {saved at R5temporary here towards aStlCpuTm7VirtualStack (top of it is kept at R6) and perform verified series of push/pop operations upon the area there. The problem could be at accessibility of either the CONTROL register (changes of the forcing SPSEL bit are not forced) or the virtual stack area during the PSP test.

Anyway, as the test manipulates with both the stack pointers, its execution must not be interrupted while being performed under disabled interrupt (STL_UTIL_Disable_IT and STL_UTIL_Enable_IT are called prior and after both the tests) so STL_ENABLE_IT compilation flag must not be defined.

Best regards,

Petr

ChintaN1
Associate III

Hello Petr,

We are checking your suggested points.

Thanks for your support.

Thanks & Regards,

Chintan Patel

 

ChintaN1
Associate III

Hi Petr,

Thanks for your support.

The attached snapshot shows disassembly of single step of the test when testing pattern (0xfff94127UL stored at R3) is just pushed to SRAM (to address 0x300000b0) pointed by active SP.  It should be PSP at case of STL_TM_CPU_TM7PushPopPsp procedure. Unfortunately, the Control register content is not visible on the snapshot. Please double check if the SPSEL bit set (the STL_TM_CPU_TM7PushPopMsp test should clear the SPSEL oppositely).

Control register value is 6.

ChintaN1_10-1693808158743.png

nPRIV: 0 (Privileged mode)
SPSEL: 1 (PSP is the current Stack pointer)

ChintaN1_11-1693808178505.png

 

At principle, the test redirects the current PSP {saved at R5) temporary here towards aStlCpuTm7VirtualStack (top of it is kept at R6) and perform verified series of push/pop operations upon the area there. The problem could be at accessibility of either the CONTROL register (changes of the forcing SPSEL bit are not forced) or the virtual stack area during the PSP test.

ChintaN1_12-1693808204168.png

Virtual stack start address: 0x30000070

STL lib start address: 0x300000b0

When performing the “push r3” content on “current PSP 0x300000b0” the device generates a hard fault and the reason is Stack overflow.

ChintaN1_13-1693808246294.png

 

Observation:

When we change the PSPLIM_S to 0 it does not get a hard fault while TM7 executes.

ChintaN1_14-1693808288152.png

Queries:

  1. Is there any impact on the Process stack pointer limit register? 
  2. Do we need to increase the Virtual Stack for TM7?

Thanks & Regards,

Chintan Patel

Petr Sladecek
ST Employee

Hi Chintan,

You've written that STL TM7 test works both without ThreadX and if you change PSPLIM_S so I see no reason to manipulate with the STL virtual stack size here. STL doesn't care about PSPLIM_S configuration at all so the problem is that something (your code, ThreadX system or your configuration of it) performs the PSP limit setup because doesn't pretend such a redirection of the PSP value applied during the STL test. At your case PSPLIM_S is set to 0x30000668. No wonder the TM7 test execution fails when it forces PSP value below the limit between 0x30000070 and 0x300000b0 where the STL virtual stack is allocated. Either change your ThreadX configuration or apply temporal modification of the PSPLIM_S value just to allow passing of the TM7 test execution.

Best regards,

Petr

ChintaN1
Associate III

Hi Petr,

Thanks for your support.

We will update you.

Thanks & Regards,

Chintan Patel

Petr Sladecek
ST Employee

Chinta, please check order of the RAM sections allocation at linker file. The integration examples provides fixed allocation order (see block FIXED_ORDER_RAM) where the "rw" section (allocating the TM7 virtual stack) is above the stack area allocation what is not your case evidently. That is why your test fails once apply any HW PSP limit at bottom of the area allocated for your stack. It seems this limitation is not noted at any STL documentation. I've asked a corrective action already.

Best regards,

Petr

ChintaN1
Associate III

Hello Petr,

Thanks for your support.

We will check with your suggested changes.

Thanks & Regards,

Chintan Patel

ChintaN1
Associate III

Hello Petr,

Thanks for your support.

reply_1.png

reply-2.png

Yes, you are right. RAM is allocated in the "FIXED ORDER" and the similar RAM mapping is reflected in the .map file.

We have fixed the hard fault issue due to the "TM7 virtual stack" by changing the PSPLIM register value to zero before the TM7 test, but we are not sure if it is impacting other tasks or not. (under observation)

The integration examples provides fixed allocation order (see block FIXED_ORDER_RAM) where the "rw" section (allocating the TM7 virtual stack) is above the stack area allocation what is not your case evidently.

We have the STL Class-B library file, so how can we allocate the fixed RAM region for the TM7 virtual stack?

Can you please provide the STL Class-B source code for STM32U5?

It would be appreciated if you could provide the limitation details and proposed solution.

Thanks and Regards,

Chintan Patel