From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@ecoscentric.com To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1002169] New: Broken cyg_interrupt_disable/enable for cortex m3 Date: Sun, 10 Jul 2016 09:21:00 -0000 Message-id: X-SW-Source: 2016/msg00070.html List-Id: 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: 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: List-Subscribe: List-Post: List-Help: , 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