Valid interrupt vectors and the interrupt server

Joel Sherrill joel at rtems.org
Sat Jun 17 18:16:00 UTC 2017


On Jun 17, 2017 11:17 AM, "Christian Mauderer" <
christian.mauderer at embedded-brains.de> wrote:

Hello,

I had a problem recently, that the interrupt server (for example used in
libbsd) caused some odd behaviour on an ARM Cortex BSP. That was solved by
the following patch:

https://git.rtems.org/rtems/commit/?id=ce3ac00c

Just today Sichen Zhao had a similar problem on the BBB:

https://lists.rtems.org/pipermail/devel/2017-June/018158.html

I took a look and it seems that there are a lot of BSPs which don't check
for the valid interrupt vector range in their
bsp_interrupt_vector_disable/enable
functions. Every one of them will most likely have a problems if someone
tries to use libbsd or the interrupt server.

It also seems that there is no test for the interrupt server. As far as I
know, not all targets are able to support the interrupt server depending on
the interrupt controller (I'm not exactly sure which ones have support and
which doesn't). So if a test for the server would be added, that test will
most likely fail on a lot of targets.

Has someone an idea how a test for the interrupt server could look like? We
would need an interrupt that can be used on every target.

Should we mass-change all BSPs to add the check for a valid interrupt? A
mass-change could be problematic because it is nearly impossible to test on
all targets and it's in a quite critical location.


Is there anyway a timer method could be used to fake out the interrupt
occurrence?

There is no single interrupt source or interface to get to one.


Kind regards

Christian Mauderer
--
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel at rtems.org
http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170617/d2c6b319/attachment-0002.html>


More information about the devel mailing list