# Syscall Help

**URL:** <https://forums.sifive.com/t/syscall-help/4146>\
**Category:** HiFive1 Rev B\
**Created:** [October 29, 2020, 5:32pm UTC](https://forums.sifive.com/t/syscall-help/4146 "2020-10-29T17:32:41Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![dkhayes117](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.sifive.com/dkhayes117/32/773_2.png) [@dkhayes117](https://forums.sifive.com/u/dkhayes117)\
**Post date:** [October 29, 2020, 5:32pm UTC](https://forums.sifive.com/t/syscall-help/4146/1 "2020-10-29T17:32:41Z")

</div>

I’ve got a user application running in u-mode with it’s stack frame protected by PMP.

```auto
PMP permissions:
pmp0cfg: 0x2004_0000 TOR RWX //These values are before the bit shift 
pmp1cfg: 0x8000_2EE0 TOR RW
pmp2cfg: 0x8000_36E0 TOR RW

```

In user mode I call a syscall function (Rust)

```auto
let p1: usize = 22;
let p2: usize = 44;
unsafe{syscall(1,p1, p2)}

```

The only thing in the body of syscall() is inline assembly `ecall`  
I figure the function call would put 1 into a0, p1 into a1, and p2 into a2 register where I could retrieve them from the trap\_frame (where registers are saved on trap) to determine the syscall type and have a couple of parameters to use inside my trap handler.

However when I call my syscall function in u mode I get `IllegalInstruction` and the values of a0,a1,and a2 are all 0.

```auto
MTVAL = 0x30200073

```

mtval does not make sense to me, any ideas?

---

<div class="post-metadata">

**Author:** ![dkhayes117](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.sifive.com/dkhayes117/32/773_2.png) [@dkhayes117](https://forums.sifive.com/u/dkhayes117)\
**Post date:** [October 29, 2020, 8:07pm UTC](https://forums.sifive.com/t/syscall-help/4146/2 "2020-10-29T20:07:08Z")

</div>

Oh, the mtval is the instruction itself for `IllegalInstruction` exception and is the address for address exceptions. The `0x30200073` makes more sense now

```auto
Machine Code
imm[11:0] rs1 fn3 rd opcode   
00110000001_00000_000_00000_1110011

```

I think that is right, but I don’t see 1110011 opcode in the base instruction set table? Plus  
The source and destination registers don’t make sense either…hmm

---

<div class="post-metadata">

**Author:** ![RalphF](https://avatars.discourse-cdn.com/v4/letter/r/d26b3c/32.png) [@RalphF](https://forums.sifive.com/u/RalphF)\
**Post date:** [October 29, 2020, 8:55pm UTC](https://forums.sifive.com/t/syscall-help/4146/3 "2020-10-29T20:55:08Z")

</div>

Hi DK,

That opcode (0x30200073) is for MRET which can only be executed in machine mode. Could you be executing it from user mode?

We have a small syscall example here that might help:

- [https://github.com/sifive/example-user-syscall](https://github.com/sifive/example-user-syscall)

---

<div class="post-metadata">

**Author:** ![dkhayes117](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.sifive.com/dkhayes117/32/773_2.png) [@dkhayes117](https://forums.sifive.com/u/dkhayes117)\
**Post date:** [October 29, 2020, 9:03pm UTC](https://forums.sifive.com/t/syscall-help/4146/4 "2020-10-29T21:03:20Z")

</div>

Hey Ralph, thanks for the clarification. I don’t call `mret` until the end of my trap handler (if user ecall) which it is in m-mode at that point. I will check out the example code and see if I can spot my error. Thanks  
Daniel

From that example, it looks like all it is doing is an `ecall`. I can simply ecall without issue, I’m trying to pass parameters along with the ecall in the a0…a[n] registers, that is what causes the problem.

---

<div class="post-metadata">

**Author:** ![dkhayes117](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.sifive.com/dkhayes117/32/773_2.png) [@dkhayes117](https://forums.sifive.com/u/dkhayes117)\
**Post date:** [November 1, 2020, 11:05pm UTC](https://forums.sifive.com/t/syscall-help/4146/5 "2020-11-01T23:05:05Z")

</div>

Just wanted to come back and update this thread. This has been solved and was not a risc-v issue. I had a double dependency on a rust crate where the dependencies were of different versions. Once this was fixed, everything works as expected.