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

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

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

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,

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 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.

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]

Hello Petr,

We are checking your suggested points.

Thanks for your support.

Thanks & Regards,

Chintan Patel

[ChintaN1]

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.

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

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.

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.

Observation:

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

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]

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]

Hi Petr,

Thanks for your support.

We will update you.

Thanks & Regards,

Chintan Patel

[Petr Sladecek]

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]

Hello Petr,

Thanks for your support.

We will check with your suggested changes.

Thanks & Regards,

Chintan Patel

[ChintaN1]

Hello Petr,

Thanks for your support.

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