Drawing the line between Module and ModuleManager in ThreadX priviliges - rtos

Question

Using Module and ModuleManager with ThreadX in a MPU-enabled platform
is "default_module_start" considered part of ModuleManager and can call Tx APIs even though, it is in the app_module.c?
E.G tx_thread_create works in default_module_start but doesn't work in the modules threads and throughs an exception;
Another question why is the ModuleManager is not just using the Tx APIs to handle threats for example, instead it uses custom functions that doesn't call Tx APIs at all

Answer 1

Function demo_module_start is part of a module (this function is in sample_threadx_module.c). It runs in the module context. This function gets called by txm_module_thread_shell_entry.c when a module is started.
Modules run in unprivileged mode, but they call ThreadX APIs (a.k.a. kernel functions). In order to execute ThreadX APIs, the module uses the SVC instruction (for ARM processors) to get into supervisor (privileged) mode. Thus, in the module library, all of the kernel calls are just simple calls that pass the function parameters to the kernel, and the actual ThreadX function is executed in kernel (privileged) mode.
Let me know if this answers your questions or if you have more questions.
Edit:
You can call TX APIs from module threads. By default, they trap into the kernel via the SVC instruction. If you want to call TX APIs directly from a module (i.e. without trapping), the module needs to be in privileged mode execution, which you can configure by modifying the module properties in the preamble of the module (e.g. see https://github.com/azure-rtos/threadx/blob/master/ports_module/cortex_m7/gnu/example_build/txm_module_preamble.S - change the properties from 0x00000007 to 0x00000000).
Creating a module thread is a bit different than creating a normal thread. The manager puts the TXM_MODULE_THREAD_ENTRY_INFO into the module thread stack, allocates a kernel stack for the thread, builds the module thread stack (which has a different return mode than a normal thread).
The manager can have whatever priority you want to assign it. Most if not all of our module manager examples assign a priority of 1 (https://github.com/azure-rtos/threadx/blob/master/ports_module/cortex_m7/gnu/example_build/sample_threadx_module_manager.c).