2025-12-10 11:26 AM
The erroneous configuration in the tx_initialize_low_level.S is this:
LDR r1, =0x40FF0000 // SysT, PnSV, Rsrv, DbgM
The tx_initialize_low_level.S file is generated upon selecting ThreadX 'Core' in the STM32CubeMX v6.15.0, and the above line is thereafter never changed. Specifically, upon enabling 'Enable BASEPRI support' and selecting a very common value of 5 for the TX_BASEPRI_VALUE, the above line is not updated accordingly. Not syncing the SYSTICK IRQ priority with the TX_BASE_PRI_VALUE of course leads to a system failure.
This issue can be duplicated by creating a brand new project with STM32CubeMX v6.15.0 and it can be seen in the sample projects included in the Applications/ThreadX in the STM32Cube_FW_U5_V1.8.0
2025-12-10 11:09 PM
Hello @ScottyWinsome ,
Let me thank you for posting.
I am currently checking this behavior, and I will get back to you ASAP.
Thanks.
Mahmoud
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-12-11 7:31 AM
Hello @ScottyWinsome ,
Let me thank you for bringing this issue to our attention.
An internal ticket is submitted to the dedicated team (Internal Ticket Number: 223683)
I will let you know when the issue is fixed.
Thanks.
Mahmoud
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-12-15 6:38 PM
The fix should probably just be to set the SYSTICK priority one higher than the PENDSV priority (i.e. there should be no need to try to coordinate with the exact BASEPRI setting at such a low priority setting):
LDR r1, =0xEFFF0000 // SysT, PnSV, Rsrv, DbgM2025-12-17 8:04 PM
@Mahmoud Ben Romdhane I have found a minor typo in this file generated by the CubeMX for EWARM:
\Middlewares\ST\threadx\ports\cortex_m33\iar\src\tx_thread_schedule.s
The typo is on line 149:
MOV r0, 0 // Disable BASEPRI masking (enable interrupts)
The correct syntax is of course
MOV r0, #0 // Disable BASEPRI masking (enable interrupts)
If I correct the typo, every time I re-generate code from the CubeMX, the tx_thread_schedule.s file get overwritten and the change would be lost but not for source code control diffs. Perhaps you can just add this to the internal ticket that you have already created?
2025-12-23 2:47 AM
Hello @ScottyWinsome ,
For the first issue:
The current implementation is correct and there is no need to modify the “tx_initialize_low_level_s.ftl” file.
The BASEPRI register is managed by the ThreadX ports files (_tx_thread_schedule, ..) When the user enables BASEPRI feature, new defines symbols are passed to the assembler via the IDE Assembler preprocessor for example: TX_PORT_USE_BASEPRI TX_PORT_BASEPRI=80.
Based on these definitions, the ThreadX port code automatically switches to using BASEPRI for interrupt priority masking, instead of globally disabling and enabling interrupts with CPSID i / CPSIE i.
For the second issue:
You can find through this GitHub Link that the code executed is correct.
Thanks.
Mahmoud
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-12-23 7:25 AM
@Mahmoud Ben Romdhane for the second issue, the problem is that the STM32CubeMX v6.16.0 outputs the erroneous .s file every time I need to regenerate code - why don't you just try it for yourself, it is as easy to duplicate the observation as a button press, namely, generate code, and you will see the output tx_thread_schedule.s has the line with the typo - have you even tried this simple step to duplicate the observation?
For the first issue, setting the priority of SYSTICK to 4 when the BASEPRI is 5 or greater is absolutely incorrect, to differ shows an utter lack of understanding of what is happening with interrupts and interrupt masking. And regardless of trying to "match" the SYSTICK to the BASEPRI, I would argue that for 99% of use-cases of ThreadX, the SYSTICK should be the lowest priority, one above the PENDSV.
2025-12-25 2:36 AM
Hello @ScottyWinsome ,
For the second issue:
The erroneous code is protected by compilation flag that is not defined by default.
>#if (defined(TX_ENABLE_EXECUTION_CHANGE_NOTIFY) || defined(TX_EXECUTION_PROFILE_ENABLE))
It is a normal behavior that the code after generation remains by default because it is not placed between
User Code begin and User Code end.
You need to change the code line in the file tx_thread_schedule.S under
Repository\STM32Cube_FW_U5_V1.8.0\Middlewares\ST\threadx\ports\cortex_m33\gnu\src\tx_thread_schedule.S
and regenerate the code.
Thanks.
Mahmoud
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-12-25 9:23 AM
@Mahmoud Ben Romdhane thank you, that is a handy work-around for the second issue.
For the first issue, the same work-around is not possible, since apparently the CubeMX is uniquely generating the tx_initialize_low_level.S. May I suggest solving the issue similar to how I am working around it with added code by moving the logic out of assembly and into C-code, probably in the app_azure_rtos.c or app_threadx.c like this:
/*
* SYSTICK: fix erroneous setting propagated from the CubeMX in tx_initialize_low_level.S
*/
NVIC_SetPriority(SysTick_IRQn, NVIC_EncodePriority(NVIC_GetPriorityGrouping(), IRQ_SYSTICK_PRIORITY, 0));
You probably even want to bring the PENDSV priority setting out of assembly onto a C-code line next to the above.
2025-12-26 2:29 PM - edited 2025-12-26 2:30 PM