Problem with interrupts and SweRVolf about cores-veer-eh1 HOT 9 CLOSED

Hi Albertodbg,
Please note that there are two sets of CSRs related to interrupts. One set is internal CSR space that uses csrr* instructions and are XLEN (32) bits wide, and another memory-mapped set for the gateway that uses load/store instructions. I believe you may be conflating the two in your programming?
The internal CSRs that are programmed via the csrr* instructions (at CSR address 0xBC*) are not memory mapped, and are 32 bits wide.

Please change your code such that the macros use csrr* for the internal CSR space registers, and the gateway memory mapped CSRs uses RV_PIC_BASE_ADDR+offset addresses

from cores-veer-eh1.

Regarding your second issue - if the gateway is configured as level-sensitive (default) and the interrupt input pin stays asserted on MRET, SweRV will take the interrupt again. Your interrupt handler must execute code to disable/clear/negate the interrupt pin (possibly by writing to the SOC agent that is generating the interrupt), prior to the MRET, and must validate this by confirming via a read of the interrupt pending registers of the gateway (MEIPx), prior to the MRET. The MRET will re-enable interrupts in MSTATUS, and level sensitive interrupts pins that continue to stay asserted following MRET will trigger interrupts processing again.

from cores-veer-eh1.

Thanks for your comments. I think that the first part is right now. The program runs, but the interrupt due to the switches is never pending, I am always in the "next" loop. Apparently the MEIE bit is active in the MIE register and things seems to be set up. I have tried to clear the interrupt in the handler, but as it is never run, I do not know whether is working (the same for mret).
I have two questions now:

1. Is it possible to see what gateway is active? Maybe using id=1 was not right.
2. I am mapping the vector table to DCCM (I have also tried ICCM). Could this be causing problems? As the base address is shifted 10 positions when mapped to MEIVT, it is only possible to employ region 0x0 for mapping the vector table, right?
   LedsSwitches.S.txt

from cores-veer-eh1.

Alberto, can you confirm that MSTATUS.mie is set (==1) ?
Yes, MEIVT should be in data memory (anywhere in external data memory or DCCM). The MEIHAP register will contain a fully formed address that is made up of the MEIVT base, and the interrupt claim id. This address should contain the interrupt handler pointer (which should be in instruction memory or ICCM). If you are using external memory, you are not limited to any internally mapped region to hold the vector tables and the corresponding handlers.

You can read the meip registers to see which interrupts are pending.

from cores-veer-eh1.

Hi @albertodbg . It would help a lot if you could show us the modifications to the SweRVolf RTL that you have made. I'm flying blind here, but suspect there are several errors involved.

1. I find it unlikely that gateway ID should be 1, since that is normally used for the UART Interrupts and you seem to get your interrupts from switches, which is not available in the upstream SweRVolf SoC.
2. I don't see that the interrupt source is cleared anywhere. Since you say that this is a level-triggered interrupt, there must be some way of resetting the source. Not sure if this is what you have done, but connecting the switches directly to the interrupt line will not work since it will continuously trigger a new interrupt as soon as the previous one is handled.
3. ICCM and DCCM are not connected in SweRVolf (yet), so you can't put the interrupt vectors there

from cores-veer-eh1.

Alberto, can you confirm that MSTATUS.mie is set (==1) ?

Yes it is. The content of MSTATUS is 0x1808, but I had to force the mei bit after enabling the external interrupts. The MIE content is 0x800 (which I guess is right), but the MIP content is 0x80, so the meip bit is 0, so the interrupt is not being triggered, right?

Yes, MEIVT should be in data memory (anywhere in external data memory or DCCM). The MEIHAP register will contain a fully formed address that is made up of the MEIVT base, and the interrupt claim id. This address should contain the interrupt handler pointer (which should be in instruction memory or ICCM). If you are using external memory, you are not limited to any internally mapped region to hold the vector tables and the corresponding handlers.

I think that the "base" term misguided me. So the MEIHAP register just contains the address by concatenating the base address with the claimid and "00".

You can read the meip registers to see which interrupts are pending.

I have tried looking at address 0x10001000 but all 256 bytes are always 0.

from cores-veer-eh1.

Hi @albertodbg . It would help a lot if you could show us the modifications to the SweRVolf RTL that you have made. I'm flying blind here, but suspect there are several errors involved.

I did not modify the SoC. I am using EH1_1.5 on a Nexys A7 board. Using polling, I was able to read the least significant 8 switches and update the corresponding leds.

1. I find it unlikely that gateway ID should be 1, since that is normally used for the UART Interrupts and you seem to get your interrupts from switches, which is not available in the upstream SweRVolf SoC.

I have parameterized the id in the new version of the code, I have tested several id's but still not working. In this regard, when grepping the Verilog I found that the maximum number of interrupts is 8. Aslo, I found this line
../src/swervolf_0.6/rtl/swervolf_core.v: .extintsrc_req ({6'd0, spi0_irq, uart_irq}),
Every bit of this signal is asserted when an interrupt is triggered with the proper priority, but apparently just spi and uart are mapped?? How could I handle gpio if this is true?
LedsSwitches.S.txt

2. I don't see that the interrupt source is cleared anywhere. Since you say that this is a level-triggered interrupt, there must be some way of resetting the source. Not sure if this is what you have done, but connecting the switches directly to the interrupt line will not work since it will continuously trigger a new interrupt as soon as the previous one is handled.

In the handler I introduced these lines at the end
//Clear interrupt pending register
li t0, (RV_PIC_BASE_ADDR + RV_PIC_MEIGWCLR_OFFSET)
sw x0, 0(t0)
but the handler is never executed.

3. ICCM and DCCM are not connected in SweRVolf (yet), so you can't put the interrupt vectors there

Ok. I tried 0xC0000000 for instance.

from cores-veer-eh1.

1. I find it unlikely that gateway ID should be 1, since that is normally used for the UART Interrupts and you seem to get your interrupts from switches, which is not available in the upstream SweRVolf SoC.

I have parameterized the id in the new version of the code, I have tested several id's but still not working. In this regard, when grepping the Verilog I found that the maximum number of interrupts is 8. Aslo, I found this line

../src/swervolf_0.6/rtl/swervolf_core.v: .extintsrc_req ({6'd0, spi0_irq, uart_irq}),

Every bit of this signal is asserted when an interrupt is triggered with the proper priority, but apparently just spi and uart are mapped?? How could I handle gpio if this is true?

You can't. There is no interrupt connected to the GPIO. The only interrupts in SweRVolf 0.6 are from the UART, connected to gateway 1 and the SPI controller, connected to gateway 2. There is also the timer interrupt, but that goes directly to the core, not through the PIC.

One solution, if you want to set LEDs based on input switches could be to trigger a timer interrupt, say every 10 ms, and check the status of switches there

3. ICCM and DCCM are not connected in SweRVolf (yet), so you can't put the interrupt vectors there

Ok. I tried 0xC0000000 for instance.

There is nothing at 0xC0000000, so you won't be able to write or read anything there. You can find the full memory map here. In addition to that, the PIC is mapped to 0xf00c0000

from cores-veer-eh1.

Thanks!

from cores-veer-eh1.