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
Interrupts on Cortex-M do not work with CONFIG_MULTITHREADING=n #26796
Comments
Note that #26372 was probably failing because of that, too (apart from kernel API usage). |
@nordic-krch what is the root cause of the usage fault? won't EDIT: See for example this use of an interrupt-driven UART: https://github.com/JuulLabs-OSS/mcuboot/blob/master/boot/zephyr/serial_adapter.c#L229 which is perfectly functional. So while it's true that interrupts are disabled by default with multithreading disabled, I am not quite sure that they are broken when enabled. |
I was seeing the same issue yesterday when trying to use I2C functions from main() without a separate thread whilst creating/integrating a driver, trace is as follows:
|
@carlescufi with |
No, it does not. I just checked: disabled logging and built with |
@de-nordic and @nvlsianpu can you confirm that serial recovery is fully functional in mcuboot and that it keeps |
@carlescufi I will look at this today and let you know. |
@carlescufi the Tested on nrf52840dk_nrf52840. |
@de-nordic thanks.
In this case, I think we need to find out whether it's GPIO or UART that are making use of multithreading, or if it's something else entirely. |
@carlescufi do you want me to check it? |
Sure, yes please @de-nordic since we are at it. |
@nordic-krch this commit introduced the regression. |
Waiting for @nordic-krch input on the 2881df3, but I am afraid that the change might have uncovered the issue rather than introduce it. |
@carlescufi @de-nordic @nordic-krch This issue caught my attention and I took a quick deeper look. I think the problem lies in incorrect configuration of stack pointer registers when zephyr/arch/arm/core/aarch32/cortex_m/reset.S Lines 95 to 98 in 3bc6c55
Because further initialization is done this way: Lines 475 to 479 in 7d90812
PSP is not reconfigured to the top of the main stack by this code that is called from switch_to_main_thread() :zephyr/arch/arm/core/aarch32/thread.c Lines 430 to 438 in 4c67339
and after initialization is finished, PSP points to the same stack as MSP, just a little below MSP. Then, if an interrupt routine uses the stack (pointed by MSP) more intensively, it can overwrite the values stacked there on the exception entry (using PSP) and the return from exception may fail in various ways (most likely with UsageFault). But if all interrupt routines don't use too much stack, everything can work correctly for quite a long time. As @de-nordic already signaled:
And it seems this issue may occur on all Cortex-M SoCs. I'm not sure who would be the best person to look at this problem. |
@anangl thanks! |
@anangl thanks for the study you did - it's half of the work already :) |
This was meant for #27343 but is still relevant here. I've updated the issue title. Using #27136 on current master I've confirmed broken
Clearly |
@tcpipchip You are probably trashing memory |
yes, looks stack memory! |
Describe the bug
When
CONFIG_MULTITHREADING=n
then interrupts are initially disabled (see bug #8393) when they are enabled then usage fault happens immediately (seems that it happens during returning from interrupt).To Reproduce
Steps to reproduce the behavior:
prj.conf:
Expected behavior
No error should appear.
Impact
Interrupts cannot be used when multithreading is off. User cannot use any driver (even out of tree which does not use kernel synchronization apis).
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: