Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CFE_PSP_Module_FindByName does not find base modules #393

Closed
jphickey opened this issue May 1, 2023 · 1 comment · Fixed by #402
Closed

CFE_PSP_Module_FindByName does not find base modules #393

jphickey opened this issue May 1, 2023 · 1 comment · Fixed by #402
Assignees
Labels
bug Something isn't working

Comments

@jphickey
Copy link
Contributor

jphickey commented May 1, 2023

Describe the bug
PSP modules can be enabled in two ways, either by adding to the ${cpuname}_PSP_MODULELIST in targets.cmake (for optional/platform-specific hardware access routines) or a set of "standard" modules listed in psp_module_list.cmake file under the PSP.

Problem is that CFE_PSP_Module_FindByName() only looks at the user-specified list (from targets.cmake) and not the list of standard modules.

This is needed for HS because the linux_sysmon monitor (for cpu utilization) is now listed as a standard module for pc-linux PSP, but this inadvertently made it un-findable.

To Reproduce
Run the current build of framework + HS app (which relies on being able to locate the linux_sysmon module). HS does not find a module and disables CPU usage reporting.

Expected behavior
HS should find the module and enable usage reporting

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

@jphickey jphickey self-assigned this May 1, 2023
@jphickey jphickey added the bug Something isn't working label May 1, 2023
@avan989
Copy link
Contributor

avan989 commented Aug 9, 2023

@jphickey @dmknutsen It looks like it was intentional from the comments that only the global_config. PspModuleList was supposed to use CFE_PSP_Module_FindByName() and not the base_module. Do we still want to change it so it can look up both lists?

Note:
CFE_PSP_Module_GetAPIEntry also needs to be updated to work.

* Internal/base modules typically should not be the subject
* of a call to CFE_PSP_Module_FindByName or GetAPI,
* so they are assigned IDs at the END of the space,
* this makes them unique but they are otherwise not used
*
* Reserve the last 256 entries for base modules
*/
#define CFE_PSP_INTERNAL_MODULE_BASE ((CFE_PSP_MODULE_BASE | CFE_PSP_MODULE_INDEX_MASK) & ~0xFF)

/* First initialize the fixed set of modules for this PSP */
CFE_PSP_ModuleInitList(CFE_PSP_INTERNAL_MODULE_BASE, CFE_PSP_BASE_MODULE_LIST);
/* Then initialize any user-selected extension modules */
/* Only these modules can be used with CFE_PSP_Module_GetAPIEntry or CFE_PSP_Module_FindByName */
CFE_PSP_ConfigPspModuleListLength = CFE_PSP_ModuleInitList(CFE_PSP_MODULE_BASE, GLOBAL_CONFIGDATA.PspModuleList);

avan989 pushed a commit to avan989/PSP that referenced this issue Aug 9, 2023
update to search through standard module list
avan989 pushed a commit to avan989/PSP that referenced this issue Aug 9, 2023
Update to find psp module from standard list as well as global list
avan989 pushed a commit to avan989/PSP that referenced this issue Aug 9, 2023
Update to find psp module from standard list as well as global list
avan989 pushed a commit to avan989/PSP that referenced this issue Aug 11, 2023
Fix nasa#393, update cfe_psp_module_findbyname and ...getAPIEntry to search
internal module list.
avan989 pushed a commit to avan989/PSP that referenced this issue Aug 11, 2023
Fix nasa#393, update cfe_psp_module_findbyname and ...getAPIEntry to search
internal module list.
dzbaker added a commit that referenced this issue Aug 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants