threadx icon indicating copy to clipboard operation
threadx copied to clipboard

Why is the file tx_initialize_low_level.S part of the port in case of cortex_m33 and doesn't have the possibility to change the SYSTEM_CLOCK?

Open Vinzenz82 opened this issue 1 year ago • 3 comments

Describe the bug I use ThreadX on a system with cortex_m33 core with proposed CMAKE construct to compile ThreadX into a lib. But confusingly the file tx_initialize_low_level.S with some fixed values like SYSTEM_CLOCK is a part of the port. If I have different clock settings I don't see any possibility to use the lib straight forward without touching it. On another system with cortex_m0 the file tx_initialize_low_level.S is NOT a part of the port and it can easily compiled with the project related code files. After some research I'm confused because at some ports the file is included (e.g. cortex_m33, cortex_m23, cortex_m55) and at some ports not (cortex_m0, cortex_m4, cortex_m7). Maybe I don't get it but why is this difference? Would it be possible to use a CMAKE var to allow a user customized version of the file?

Please also mention any information which could help others to understand the problem you're facing:

  • STM32H5xx / Raspberry Pi Pico
  • Master-Branch of ThreadX
  • CMAKE + arm-none-eabi-gcc

Vinzenz82 avatar Jun 04 '24 07:06 Vinzenz82

I've got the same problem. It must be moved to the example folder like the other targets, because it's just an exmaple. there is no other way. btw, "{CMAKE_CURRENT_LIST_DIR}/src/tx_thread_secure_stack_initialize.S" is not in the list of target sources and compilation failes.

HosseinSagha avatar Jul 15 '24 02:07 HosseinSagha

I've got the same problem. It must be moved to the example folder like the other targets, because it's just an example. there is no other way. btw, "{CMAKE_CURRENT_LIST_DIR}/src/tx_thread_secure_stack_initialize.S" is not in the list of target sources and compilation failes.

Thanks for comment. Just a small correction; the problem is that for some ports the file is included in the CMAKE file (like: ports/cortex_m33/gnu/CMakeLists.txt) and then you are fixed to the settings inside the file and your fix/workaround is not usable unfortunately.

Vinzenz82 avatar Jul 15 '24 06:07 Vinzenz82

You can fork it and modify the cmake file. that's the only solution for now. That's what I did.

HosseinSagha avatar Jul 16 '24 04:07 HosseinSagha

@HosseinSagha is correct. We try to have sensible defaults but cannot anticipate the specific configurations you may need. Tweaking the CMake files is a perfectly suitable solution.

fdesbiens avatar Feb 27 '25 15:02 fdesbiens

Actually I had missed to add this to resolve the build issue. This define needs to be added to tx_user.h for armv8. #define TX_SINGLE_MODE_NON_SECURE

https://github.com/eclipse-threadx/rtos-docs/blob/main/rtos-docs/threadx/user-guide-armv8m/chapter2.md

Anyway, the tx_initialize_low_level.S must be copied to the project, modified and compiled. That's how it's supposed to be used. That is also how the MXcube code generator does it. The one in the library is supposed to be an example file only.

However, unlike m4 or silmiliar, the m33 compiles the example tx_initialize_low_level.S in, which is wrong. So, fork and modify cmake is the only solution for now, untill this is fixed.

HosseinSagha avatar Feb 28 '25 00:02 HosseinSagha