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

[v2.7.x] Application defined Shell Command not registered #45579

Closed
th-fischer2020 opened this issue May 12, 2022 · 6 comments
Closed

[v2.7.x] Application defined Shell Command not registered #45579

th-fischer2020 opened this issue May 12, 2022 · 6 comments
Assignees
Labels
area: Shell Shell subsystem bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@th-fischer2020
Copy link

th-fischer2020 commented May 12, 2022

Describe the bug
I implemented some submodules in my Zephyr-Project with some shell command impelmentations. When i was still working on zephyr version 2.6.0 everything worked fine.

Now i did an Update to Zephyr 2.7.1 and later to 2.7.2. Since the Update i faced the problem, that my shell commands are gone. When i went back to 2.6.0 everything is fine again.

If the source files with my shell commands are moved to /src-directory (in project root), the shell commands are available again. Any other directorys are not working.
Another way to get back the commands is to create an shell_cmd.c file /src-directory (in project root) and include my shell-command-implementation-files like:

#include "my_cmd_1.c"
#include "my_cmd_2.c"

I think it has something to do with build-system settings (cmake)? Registration of the commands may not work, because in map-File i cannot find any symbols concerning my commands.
Additionally i did some tries with different gcc optimization settings but no success.

My project is based on a STM32F4 platform.

I am working with PlatformIO, but i think that is not a possible reason, because Zephyr 2.6.0 still works.

Expected behavior
My commands should appear in shell.

Impact
Key features are not available in my application. showstopper

Logs and console output
No logs. Shell commands not appear.

Environment (please complete the following information):

  • OS: Ubuntu 20.04.4 LTS x86_64
  • Toolchain: Platformio Core 5.2.5·Home 3.4.1
  • Zephyr 2.7.2
@th-fischer2020 th-fischer2020 added the bug The issue is a bug, or the PR is fixing a bug label May 12, 2022
@henrikbrixandersen henrikbrixandersen added the area: Shell Shell subsystem label May 17, 2022
@carlescufi carlescufi added the priority: low Low impact/importance bug label May 17, 2022
@carlescufi carlescufi changed the title Application defined Shell Command not registered [v2.7.x] Application defined Shell Command not registered May 17, 2022
@carlescufi
Copy link
Member

@tfir1981 could you please try to see if this issue is present in the main branch as well?

@ThomasFike
Copy link

Have you verified that those files are being compiled when not in your src directory? You could check this quick by adding #error to one of the files. Then make sure you run a pristine build and see if it errors at the error you added. It sounds like the files are not being compiled from what your saying.

@th-fischer2020
Copy link
Author

th-fischer2020 commented May 19, 2022

@ThomasFike

Have you verified that those files are being compiled when not in your src directory? You could check this quick by adding #error to one of the files. Then make sure you run a pristine build and see if it errors at the error you added. It sounds like the files are not being compiled from what your saying.

Yes, when my Code is not in src-directory it is compiled. On one hand i got an error if adding #error on other hand i can see compiler log. .o-File and .a-File were created.
Another test i did is adding an error inside of makro SHELL_CMD_REGISTER by changing symbolnames. It results in compiling error, too.

@th-fischer2020
Copy link
Author

th-fischer2020 commented May 20, 2022

@carlescufi

@tfir1981 could you please try to see if this issue is present in the main branch as well?

Thanks for your reply. I did some tests:

I am using PlatformIO for development where it is not so easy to check out any Zephyr-Version. Finally i cloned the Zephyr-Example Repo Zephyr-Example and do compilation and flashing by using west.

I added a test command (myTestCmd.c)

#include <shell/shell.h>

static int testCmdFunc(const struct shell *pShell, size_t argc, char **argv)
{
  shell_print(pShell, "This is my very special testCmd");

  return 0;
}

SHELL_STATIC_SUBCMD_SET_CREATE(testCommands,
                               SHELL_CMD_ARG(status, NULL, "", testCmdFunc, 1, 0),

                               SHELL_SUBCMD_SET_END);

SHELL_CMD_REGISTER(testcommand, &testCommands, "My: Test shell commands", NULL);

I placed the file in app/src/myTestCmd.c. At this point my file is not compiled and my command is not visible on shell. I have to do some addition in app/CMakeLists.txt:

target_sources(app PRIVATE src/main.c src/myTestCmd.c)

In a second test i moved my command implementation to drivers directory. My command was not built until i added the following line to drivers/sensor/examplesensor/CMakeLists.txt :

zephyr_library_sources(myTestCmd.c)

I understand the necessary additions concerning cmake. Using west my command is visible on shell. Zephyr version does not matter.

I will do an another test by implementing a submodule. I will post the results later.

@th-fischer2020
Copy link
Author

@carlescufi

I did another Test. To the example-application mentioned above i added a static lib in style of sample. I added another shell command implementation to this lib and i got it built and flashed. This Command appears in shell, too.

I think the Problem muss be on platformio side.

@th-fischer2020
Copy link
Author

In my PlatoformIO i addes -Wl,--whole-archive to my build_flags. This is the solution.
Thanks for your help.
So this issue is solved for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Shell Shell subsystem bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

5 participants