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.

Sign up for GitHub

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

Jump to bottom

OS_API_Init failure #24

Closed
SweeWarman opened this issue Nov 13, 2019 · 3 comments
Closed

OS_API_Init failure #24

SweeWarman opened this issue Nov 13, 2019 · 3 comments

Comments

@SweeWarman
Copy link

I cloned this cFS repository with all its submodules, followed the instructions in the README for compilation. I get the following error when running the executable (core-cpu1).

CFE_PSP: Default Reset Type = PO
CFE_PSP: Default Reset SubType = 1
CFE_PSP: Default CPU ID = 1
CFE_PSP: Default Spacecraft ID = 42
CFE_PSP: Default CPU Name: cpu1
CFE_PSP: Starting the cFE with a POWER ON reset.
CFE_PSP: OS_API_Init() failure

I am working on a linux workstation running ubuntu 18.04. Any insight would be helpful.
@skliper
Copy link
Contributor

skliper commented Nov 13, 2019

Did you configure for permissive mode, as specified in the readme? If not you need to run the code with elevated privileges.

Version information (did you pull master or a tag/release?), and your exact steps to recreate the issue would likely get you a more applicable response (information from the bug issue template is useful).

@skliper
Copy link
Contributor

skliper commented Nov 13, 2019

Also may help to enable debug messages by defining OS_DEBUG_PRINTF in your default_osconfig.h.

@SweeWarman
Copy link
Author

Including the define for the permissive mode seems to have fixed this issue. Many thanks for the swift response.

JandlynBentley-at-NASA pushed a commit to JandlynBentley-at-NASA/cFS that referenced this issue Jun 15, 2020
@jphickey
Fix nasa#24: Add strict warning flags
ebd356b 
Add extra compile options for mission scope and arch scope.

These are separated to support cross compile environments that
do not/cannot use the same flags on both builds.

For "mission" build the targets are never cross compiled, only
built for the native host machine.  It should be safe to assume
a compiler in the GCC family and the strict warnings should
_always_ be applicable here.

For "arch" build the options are compiler vendor dependent.  The
file as-supplied can only be used if all the target cross compilers
are in the same family and support the same warning options.
However, this file can be modified without affecting the options
used for the host side tools.
JandlynBentley-at-NASA pushed a commit to JandlynBentley-at-NASA/cFS that referenced this issue Jun 15, 2020
@jphickey
Issue nasa#24: Add _custom suffix to extension files
7a2f49b 
Add a _custom suffix to differentiate the customization
file from the base file in the cmake directory.
JandlynBentley-at-NASA pushed a commit to JandlynBentley-at-NASA/cFS that referenced this issue Jun 15, 2020
@jphickey
Update nasa#24: Also enable cast-align warning
c5625fc 
Include in the basic warning set.  Note that at this time the CFE
does not build cleanly on all architectures with this warning enabled,
pending resolution of issue nasa#313.
JandlynBentley-at-NASA pushed a commit to JandlynBentley-at-NASA/cFS that referenced this issue Jun 15, 2020
@skliper
Merge pull request nasa#462 from jphickey/jph-fix-24-basic-warnings
451a94f 
Fix nasa#24, Add compiler option examples
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@SweeWarman @skliper