2023-08-24 06:42 AM
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
Solved! Go to Solution.
2023-10-26 01:10 AM
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
2023-08-24 09:50 PM
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
2023-08-31 05:31 AM
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
2023-08-31 09:06 AM
Hello Petr,
We are checking your suggested points.
Thanks for your support.
Thanks & Regards,
Chintan Patel
2023-09-03 11:20 PM
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:
Thanks & Regards,
Chintan Patel
2023-09-04 03:35 AM
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
2023-09-04 05:47 AM
Hi Petr,
Thanks for your support.
We will update you.
Thanks & Regards,
Chintan Patel
2023-09-05 09:38 AM
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
2023-09-11 10:05 PM
Hello Petr,
Thanks for your support.
We will check with your suggested changes.
Thanks & Regards,
Chintan Patel
2023-09-17 06:14 AM - edited 2023-09-17 06:28 AM
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