Skip to content

Instantly share code, notes, and snippets.

@btashton

btashton/uartblink.S

Last active July 31, 2020 19:28
Show Gist options
  • Save btashton/4aa7ed42bc81ff4716821636997d9df9 to your computer and use it in GitHub Desktop.
Save btashton/4aa7ed42bc81ff4716821636997d9df9 to your computer and use it in GitHub Desktop.
Download ZIP
ecall debugging for SERV core
@btashton
Copy link
Author

@olofk Here is the test that I did that shows how interrupts are not being restored by the MPIE bit in mstatus. How this manifests itself in the RTOS is that an ecall might be issued in a critical section such as when a new task is created. The MPIE bit is set to restore interrupts for things like the system tick.

@DaveBerkeley
Copy link

DaveBerkeley commented Jul 31, 2020 •
edited
Loading

I have not been able to set the mie.mtie bit. Is this a related problem? I'm using asm from C to read / write the csr regs, eg

inline uint32_t read_mie()
{
    uint32_t value;
    __asm__ volatile ("csrr %0, mie" : "=r"(value));
    return value;
}

inline void write_mie(uint32_t value)
{
    __asm__ volatile ("csrw mie, %0" : : "r"(value));
}

inline uint32_t read_mtvec()
{
    uint32_t value;
    __asm__ volatile ("csrr %0, mtvec" : "=r"(value));
    return value;
}

inline void write_mtvec(uint32_t value)
{
    __asm__ volatile ("csrw mtvec, %0" : : "r"(value));
}

...

I can set the interrupt enable bit in mstatus, but not in mie, eg :

    write_mie(0xffffffff); // this apparently does nothing!
    write_mstatus(0x8);
    write_mtvec((uint32_t) irq_handler);

This compiles to :

  100340:       fff00793                li      a5,-1
  100344:       30479073                csrw    mie,a5
  100348:       00800793                li      a5,8
  10034c:       30079073                csrw    mstatus,a5
  100350:       001007b7                lui     a5,0x100
  100354:       0cc78793                addi    a5,a5,204 # 1000cc <irq_handler>
  100358:       30579073                csrw    mtvec,a5

If I set the mie.mtie bit permanently in rtl/serv_csr.v the timer interrupts are enabled :

diff --git a/rtl/serv_csr.v b/rtl/serv_csr.v
index 897e272..f638ed8 100644
--- a/rtl/serv_csr.v
+++ b/rtl/serv_csr.v
@@ -77,7 +77,7 @@ module serv_csr
        mstatus_mie <= csr_in;
 
       if (i_mie_en & i_cnt7)
-       mie_mtie <= csr_in;
+       mie_mtie <= 1; // csr_in;
 
       mstatus <= i_cnt2 & mstatus_mie;

The system then runs as expected.

@btashton
Copy link
Author

@DaveBerkeley have you tried running the assembly in this gist? It was broken in the way mentioned in description, but was resolved by my PR olofk/serv#31. @olofk implemented a different approach that should also fix this issue, as well as another one I found and mentioned in the PR. I have not validating the change that he made in master, but you might try my PR and we can get to the bottom of all of this.

@DaveBerkeley
Copy link

Just tried your mpie branch. Still not working for my case.

I'm new to risc-v, so I may be missing something. I've been wrapping SERV with a SoC to allow XIP (execute in place) directly from Flash on the icebreaker.

https://github.com/DaveBerkeley/fpga/tree/master/serv

This is all working fine, except I can't enable the timer interrupt.

@btashton
Copy link
Author

Oh excellent work! I can take a look later today. Do you have a full code listing where you use these functions I could look at?

@DaveBerkeley
Copy link

DaveBerkeley commented Jul 31, 2020 •
edited
Loading

https://github.com/DaveBerkeley/fpga/blob/master/serv/firmware.c

But I'm using my own timer hardware

https://github.com/DaveBerkeley/fpga/blob/master/serv/timer.v

I was embarrassed to find that it adds 500 LUTs to the usage (including the irq code in SERV). My timer has 2 x 64-registers and a 32-bit temp register.

If you compile with -O1 optimisation gcc does a great job of producing minimal code.

I'm also using a hardware uart for tx which you might like. It delays ack until the next byte can be sent, which removes the need for bit-banging or polling the uart for busy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment