Drawing the line between Module and ModuleManager in ThreadX priviliges

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? EG 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 (aka 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.