[Bug 1002169] New: Broken cyg_interrupt_disable/enable for cortex m3

[bugzilla-daemon@ecoscentric.com]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1002169

            Bug ID: 1002169
           Summary: Broken cyg_interrupt_disable/enable for cortex m3
           Product: eCos
           Version: unknown
            Target: All
 Architecture/Host_ Other
                OS:
            Status: UNCONFIRMED
          Severity: major
          Priority: low
         Component: HAL
          Assignee: unassigned@bugs.ecos.sourceware.org
          Reporter: bernard.fouche@kuantic.com
        QA Contact: ecos-bugs@ecos.sourceware.org
                CC: ecos-bugs@ecos.sourceware.org

Problem 1:

hal_interrupt_set_level() does not consider the way bits are used in IPR0..8:
the lowest bits are zero, the priority level is to be set in the upper bits.

An example for LPC17XX:

- CYGNUM_HAL_CORTEXM_PRIORITY_MAX is set to 8, because eCos sees 5 bits for
priority levels, so it does CYGNUM_HAL_CORTEXM_PRIORITY_MAX = (1 << (8-5)).

- when entering hal_interrupt_set_level(), the user set level in the .ecc file
is added to CYGNUM_HAL_CORTEXM_PRIORITY_MAX (so the priority level defined in
the .ecc file isn't what will be used by the hardware, it will be silently
changed by an offset of 8). 

- For instance, if I set the priority of an UART to 12, eCos will set 12+8=20.

- but the bit layout of IPR0..8 isn't considered, so eCos writes directly 20
(0x14) into the register corresponding to the interrupt number.

- since for LPC the 3 lower bits of IPR0..8 aren't used, what the MCU keeps in
the register is 0x10 and the priority level described is now 0x10 >> 3 = 0x02.

- When one wants to disable an interrupt, cyg_interrupt_disable() writes
CYGNUM_HAL_CORTEXM_PRIORITY_MAX (8) into BASEPRI. But with a priority level of
2, the UART interrupt can still fire.

Some TI MCU will have 16 levels of priority instead of 32 for LPC17XX and the
same problem arises, the priority level bits are always in the upper parts of
IPR0..8.

Note also that the default priority set for all vectors, 128, will be 128>>3=16
at the hardware level. This 128 value is hardcoded in hal_reset_vsr(), that
doesn't call hal_interrupt_set_level().

Fixes:

- have hal_reset_vsr() to store 0xFF instead of 0x80 (fix default priority
level)
- have hal_interrupt_set_level() to write '(l<<3)'
(level+CYGNUM_HAL_CORTEXM_PRIORITY_MAX) instead of 'l'.

Problem 2:

In hal_misc.c for cortexm/lpc17xx, the system tick has priority 0: SHPR3
(stangely SHPR* registers are named differently in eCos and in the doc: ecos's
SHPR2 is NXP/ARM SHPR3...) is set with a priority of zero for system tick,
while SVC is set with priority 255.

This means that using BASEPRI to enable/disable int's won't filter the system
tick since 0 < 8 : this breaks the specification of cyg_interrupt_disable().

Worse, the system tick processing may trigger a context switch calling SVC,
hence triggering an interrupt with a 255 (more likely 31) level priority,
leading to a hard fault.

Possible solutions:

- use PRIMASK instead of BASEPRI for cyg_interrupt_disable/enable since the
goal is to filter all kind of ints without considering priorities (seems the
best).
- have system tick priority set to CYGNUM_HAL_CORTEXM_PRIORITY_MAX + 1

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
>From ecos-bugs-return-11130-listarch-ecos-bugs=sources.redhat.com@sourceware.org Sun Jul 03 22:55:18 2016
Return-Path: <ecos-bugs-return-11130-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 20292 invoked by alias); 3 Jul 2016 22:55:17 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 20281 invoked by uid 89); 3 Jul 2016 22:55:16 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=NEXT, HTo:U*unassigned, H*Ad:U*unassigned, navigation
X-HELO: mail.ecoscentric.com
Received: from albus.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.200)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 03 Jul 2016 22:55:06 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 512)
	id 5B45CA8A6FE; Sun,  3 Jul 2016 23:55:03 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.ecoscentric.com 5B45CA8A6FE
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
Content-Transfer-Encoding: quoted-printable
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.ecoscentric.com 60F9EA8A6C3
Content-Type: text/plain; charset="UTF-8"
From: bugzilla-daemon@ecoscentric.com
To: unassigned@bugs.ecos.sourceware.org
Subject: Your Bugzilla bug list needs attention.
X-Bugzilla-Type: whine
Date: Sun, 10 Jul 2016 09:21:00 -0000
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
Message-Id: <20160703225502.60F9EA8A6C3@mail.ecoscentric.com>
X-SW-Source: 2016/txt/msg00071.txt.bz2
Content-length: 3567

[This e-mail has been automatically generated.]

You have one or more bugs assigned to you in the Bugzilla bug tracking syst=
em (http://bugs.ecos.sourceware.org/) that require
attention.

All of these bugs are in the CONFIRMED
state, and have not been touched in 7 days or more.
You need to take a look at them, and decide on an initial action.

Generally, this means one of three things:

(1) You decide this bug is really quick to deal with (like, it's INVALID),
    and so you get rid of it immediately.
(2) You decide the bug doesn't belong to you, and you reassign it to
    someone else. (Hint: if you don't know who to reassign it to, make
    sure that the Component field seems reasonable, and then use the
    "Reset Assignee to default" option.)
(3) You decide the bug belongs to you, but you can't solve it this moment.
    Accept the bug by setting the status to IN_PROGRESS.

To get a list of all CONFIRMED bugs, you can use this URL (bookmark
it if you like!):
http://bugs.ecos.sourceware.org/buglist.cgi?bug_status=3DCONFIRMED&assigned=
_to=3Dunassigned@bugs.ecos.sourceware.org

Or, you can use the general query page, at=20
http://bugs.ecos.sourceware.org/query.cgi

Appended below are the individual URLs to get to all of your CONFIRMED bugs
that haven't been touched for 7 days or more.

You will get this message once a day until you've dealt with these bugs!

 STM32 USB driver unplugging/replugging issue
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001084
 Navigation of the documentation using PREV NEXT PARENT arrows broken
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001146
 help documentation tree does not correspond to viewed document
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001148
 documentation tree in navigation panel does not open at viewed document
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001149
 CAN loopback driver requires CYGPKG_DEVS_CAN_LOOP_CAN[01]
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001211
 eCos GNU tools 4.6.3
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001468
 Fix compiler warnings about mismatch between log() format string and argum=
ent values.
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001510
 Array index out of bounds in tftp_server.c
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001522
 Cortex-M: Remote 'g' packet reply is too long
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001524
 BSD nc_test_slave chrashes
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001586
 [RFC] eCos FLASH startup from RedBoot
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001623
 Kinetis variant HAL patch: mostly cosmetic and descriptive improvements
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001783
 Kinetis DSPI, flash and platform HAL tidies
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001784
 Data not relocated to RAM during ROMINT startup
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001864
 Freescale ENET support fot little endian.
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1002114
 KSZ8081 Ethernet PHY driver.
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1002115
 Prepare Kinetis for Gen2 K
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1002116
 Freescale UART - some macros for advanced serial buffers.
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1002117
 outdated expectations in documentation
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1002126