Become a leader in the IoT community!
New DevHeads get a 320-point leaderboard boost when joining the DevHeads IoT Integration Community. In addition to learning and advising, active community leaders are rewarded with community recognition and free tech stuff. Start your Legendary Collaboration now!
I think, you could look into this
https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/basic/threads/src/main.c
https://docs.zephyrproject.org/latest/samples/basic/threads/README.html#multi-thread-blinky
If you have any other question, i would love to help
Thank you very much!
I know how to start threads, define gpios, blink them, etc… using supervisor mode threads (the default), but when I try with user mode thread I am facing an hardfault.
which HW are you using?
Stm32f401re
Hey, sorry for the ghost.
Could you tell me the flow of your code if possible?
I think i can prepare something to share, but not today, sorry and thank you again for your interest
I found 1 minute to prepare a minimal try that goes in hardfault
usermode_test_1.zip
is this a supported board?
Don’t know
how were you building it up until now?
Without config_usermode=y and without K_USER option to the thread
sorry i wasnt clear enough
i mean to say
which west cmd for building the project
Oh sorry
something like .
west build -p always -b
Yup
i want the board snippit for that
-b nucleo_f401re
Sorry i need to go now, i can be on again in about 2h
Cool,
lemme try it out
till then
Hi melta, have you made any attempts?
dont have an stm with me right now, thought i had one in office. will try to get one in another 8-10 hr
but from my guess, it feel like the hardfault occurs because it is accessing something with higher privileges
if you have a debugger, could you check what are the value of the FSR?(atleast with that, we can find which area is the prob, whether it is memfault, hardfault etc )
also, have you raised this on the stm chat on zephyrproject?
I can.
In my opinion i need to place the gpio descriptor in a memory section that have user access and/or give the user access to the memory area in which the gpio registers are mapped… But i am new in user space and searching for a guidance…
I wrote in memory protection channel…
Just forwarded in stm32 channel!
https://docs.zephyrproject.org/apidoc/latest/group__usermode__apis.html#ga6a2dae4c6dc6959d8785ff1924b1b424
i think you are correct, we will need to grant it some privileges of any kernel object that it needs to use
maybe that’s why the hardfault happens because the user thread is being denied access to GPIO API
Anyway I read that in usermode threads can use syscalls… And gpio api should be syscalls… 😵💫
Compiling… Then I’ll attach the hardfault status
yep,
it’s a memfault
seems to be the GPIO
i am pretty sure that is the GPIO
unfortunately can`t find a sample for that
k_object_access_all_grant
use this instead
the access grant should come from supervisor thread. and as we havnt declared a supervisor thread
we cant directly declare it to access GPIO
if we want it to have access, we would need to statically give teh access
so instead of k_thread_create we need K_THREAD_DEFINE
and instead of k_object_access_grant, we need K_THREAD_ACCESS_GRANT
the main thread isn`t a supervisor thread?
same behaviour
@32bitwidesaviour could you give your insights here?
Here are my tries:
https://github.com/silvio-vallorani-zephyr-portfolio/usermode_gpio_test/ -> 3 branches, one for each approach
i dont think dbg_pin1 is a kernel object, because the parameter accepts a void, it’s taking anything.
leading to no error during compilation
https://github.com/zephyrproject-rtos/zephyr/blob/main/scripts/build/gen_kobject_list.py
we can use this script to list all possible k_object present in the elf
message.txt
if I remove the k_object_access_grant(&dbg_pin1, usermode_thread); the program goes in
static inline int z_vrfy_gpio_port_toggle_bits(const struct device *port, gpio_port_pins_t pins)
{
K_OOPS(K_SYSCALL_DRIVER_GPIO(port, port_toggle_bits)); <-- and finally in /* LCOV_EXCL_START */ FUNC_NORETURN __weak void arch_system_halt(unsigned int reason) { ARG_UNUSED(reason); /* TODO: What's the best way to totally halt the system if SMP * is enabled? */ (void)arch_irq_lock(); for (;;) { /* Spin endlessly */ } } with reason == 3
from the driver side
i can see that when CONFIG_USERSPACE is present in prj.conf,
it includes gpio_handlers.c
which lets the user use the gpio
hmm
i think i found a hint
yup I follow his suggestion but I noticed that there is a permission error
solved. thank you very much for your time!
Could you share your finding?
https://github.com/silvio-vallorani-zephyr-portfolio/usermode_gpio_test/
This is a functioning sample
I need to add CONFIG_MPU=y to prj.conf and grant access for user thread to the gpio “port” object
I tried to grant gpio.port before, but without CONFIG_MPU=y… resulting in hardfault
Then i add CONFIG_MPU=y but grant access to gpio object… resulting in permission error
Finally I tried with both and boom
Anyway i need to use CONFIG_NO_OPTIMIZATIONS=y to debug step by step inside the syscalls…
great
It was a learning to me too!
Maybe i should also start using userspace style programming
CONTRIBUTE TO THIS THREAD