Reading {s,u}status and {s,u}epc should work IF they exist. If they don’t exist then you should get an illegal instruction exception. This could look like a hang if you haven’t set up an appropriate interrupt handler.
uepc doesn’t exist unless the N extension for delegating selected exceptions to U mode handlers is implemented. Currently, none of our cores implement this, including those on the FU540.
sstatus and sepc exist if S mode is implemented. This is the case on the U54 cores (harts 1…4) on the FU540, but not on the E51 core (hart 0) on the FU540.
I suspect you are running your test code on hart 0.
RISC-V deliberately doesn’t make it easy for code to discover what mode it is running it because this is a virtualisation hole. As a general principle, code should be designed for and implicitly know what mode it will run in. Applications code should assume it is in U mode. The operating system should assume it is in S mode (it might in fact be virtualised and running in U mode, with things U mode can’t do trapped and emulated by the hypervisor).
It would be possible to create an operating system call or SBI call that extracted the previous mode from MPP or SPP in mstatus and returned that as the result. But it’s not recommended to do this.
Hi @bruce, I am using FU540 (HiFive-Unleashed) with SiFive Studio. Now the S mode CSR like sstatus are editable in M-mode, but the debugger (OpenOCD with Freedom studio) doesn’t show them. Is there a way to see those S & U mode CSRs in register view.
I can however access S-mode CSRs from debugger view via gdb commands, but the U-mode CSRs don’t get printed even via, gdb console.