Skip to content
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

examples/blinky_clint.rs does not work properly #5

Open
irandms opened this issue Feb 12, 2019 · 1 comment
Open

examples/blinky_clint.rs does not work properly #5

irandms opened this issue Feb 12, 2019 · 1 comment
Assignees

Comments

@irandms
Copy link

irandms commented Feb 12, 2019

Hello,

I'm working on a project using the FE310 as a controller for a simple phone and I've been using this repo as a resource for learning Rust/embedded Rust specifically, and I've noticed that this example doesn't work as-is on my HiFive1 board; I've found that the way that the MTIMECMP register is set is incompatible with how the MachineTimer interrupt works, as the current code under examples/blinky_clint.rs tries to set the MTIMECMP register outside of the trap handler; this causes a problem because as soon as trap_handler finishes execution, control would be returned to main, but I've found that an interrupt storm occurs instead, as the value within MTIMECMP is greater than MTIME, causing the interrupt pending bit to stay set.

I have a potential fix, but I'm not extremely familiar with Rust, so it is kind of hacky - using a global variable to the MTIMECMP register to call set_mtimecmp from within trap_handler. The fix can be found here, and I'm welcome to any advice on how to make it more Rust-y: https://github.com/irandms/riscv-phone-sw/blob/master/examples/blinky_clint.rs#L68

I'm not 100% sure if this bug is unique to my hardware or not, as I only have the one board right now. If anyone else has a HiFive1 and can try and confirm the behavior of this example, I'd be glad to hear it.

@Disasm
Copy link
Member

Disasm commented Feb 28, 2019

Thanks! I will try to reproduce this. According to the RISC-V priv spec v1.9 this behavior is expected:

Platforms provide a 64-bit memory-mapped machine-mode timer compare register (mtimecmp), which causes a timer interrupt to be posted when the mtime register contains a value greater than or equal to the value in the mtimecmp register. The interrupt remains posted until it is cleared by writing the mtimecmp register.

@Disasm Disasm self-assigned this Feb 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants