Interrupts strange behavior on RISC-V

[Joel Sherrill]

Yeah!!

Does this mean you have a ticker variant working now? With polled console
IO?

I ask because that is a nice capability merge point. When merged, you move
from a large submission to review to smaller more incremental ones. Easier
to review, etc.

On Jul 8, 2017 7:30 PM, "Denis Obrezkov" <denisobrezkov at gmail.com> wrote:

> I found the problem, I made a mistake in my code, instead of:
> if ((cause & MCAUSE_MTIME) == MCAUSE_MTIME) {
> I have written:
> if (cause & MCAUSE_MTIME) {
>
> now local interrupts work.
>
> 2017-07-08 19:18 GMT+02:00 Denis Obrezkov <denisobrezkov at gmail.com>:
>
>>
>>
>> 2017-07-08 18:05 GMT+02:00 Joel Sherrill <joel at rtems.org>:
>>
>>>
>>>
>>> On Jul 8, 2017 10:09 AM, "Denis Obrezkov" <denisobrezkov at gmail.com>
>>> wrote:
>>>
>>> Hello all,
>>> I worked with local interrupts last few days and found some strange
>>> behavior:
>>>
>>>
>>> I am trying to handle local interrupts.
>>> That's what I do, in my handler for timer interrupts:
>>> * disable timer interrupts in mie
>>> * read a current value from mtime
>>> * copy it to mtimecmp (both are 64bit width types)
>>> * add some big value to mtimecmp
>>> * enable timer interrupts in mie.
>>>
>>> And I have two boards and the problem is that on one of them interrupts
>>> are permanently generated because mip register is always 1 in mtip
>>> position, though mtimecmp is greater than mtime, and are not generated at
>>> all on the other.
>>>
>>> Is there a procedure for clearing the interrupt?
>>>
>> Yes, it is written that external interrupts are cleared by PLIC (external
>> interrupt controller),
>> software interrupts are cleared I think by the main thread (I didn't find
>> it in docs), and timer
>> interrupts are cleared by writing the value in mtimecmp memory-mapped
>> register greater
>> than in mtime  (memory mapped register too.) [2, p.28]
>>
>>> In this piece of code, I turn on interrupts:
>>> la t0, RISCV_Exception_default
>>> csrs mtvec, t0
>>> li t0, 0x88
>>> csrs mie, t0
>>> csrsi mstatus, 0x8
>>>
>>>
>>> Can you point us to the documentation and section where this timer
>>> behavior is defined? Sometimes having someone else read it can provide a
>>> different interpretation.
>>>
>>> And is there other code like Linux which deals with this timer? There
>>> may be a magic sequence you are missing
>>>
>>
>> I wasn't able to find a magic sequence and didn't look at Linux code, but
>> I initialized it like in hifive1 example provided with FreedomStudio (IDE
>> for HiFive1).:
>> https://github.com/sifive/freedom-e-sdk/tree/master/bsp
>>
>> But these are the docs:
>> Description of mstatus register, which contains mie field for global
>> interrupt enabling (Ch 3.1.6):
>> [1] https://riscv.org/specifications/privileged-isa/
>> Description of the core, on which SoC is based (Ch 6 is about interrupts):
>> [2] https://www.sifive.com/documentation/coreplex/e31-coreplex-manual/
>>
>> There are also description of the SoC:
>> https://www.sifive.com/documentation/freedom-soc/freedom-
>> e300-platform-reference-manual/
>> and description of the chip:
>> https://www.sifive.com/documentation/chips/freedom-e310-g000-manual/
>>
>> --
>> Regards, Denis Obrezkov
>>
>
>
>
> --
> Regards, Denis Obrezkov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170708/4203b7f2/attachment-0002.html>