@nina_kali_nina (For the future) In my limited-yet-diverse experience with ghidra, that behavior is usually because there's a function somewhere much deeper in the call chain that was incorrectly tagged as noreturn by the initial analysis pass and it's "helpfully" re-propagating that flag by re-establishing the flow overrides in the disassembled function. I've learned to not run the "non-returning functions" analyzer on older/embedded code due to that... (There's frequently a lot of "helpers" that don't match the standard ABI, which can confuse that analyzer pretty badly)
It could also help to identify the point where the problematic function does return and set a flow override there to "properly" tell the decompiler "yes, this function really does return to the caller here" even if it really wants to ignore the unset noreturn flag on the function.