AVR C Runtime Library - Bugs: bug #35003, wdt_enable() has a wrong code...
You are not allowed to post comments on this tracker with your current authentication level.
bug #35003: wdt_enable() has a wrong code sequence for many parts
Submitter: | Luca Matteini <loucypher> | ||
Submitted: | Wed 07 Dec 2011 02:29:44 PM UTC | ||
Category: | Library | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | Header files |
Status: | Invalid | Assigned to: | None |
Percent Complete: | 0% | Open/Closed: | Closed |
Release: | 1.7.* | Fixed Release: | None |
Wed 07 Dec 2011 04:01:36 PM UTC, comment #5: |
Luca Matteini <loucypher> |
Wed 07 Dec 2011 03:20:51 PM UTC, comment #4: You'd be surprised to learn that the compiler has been
|
Joerg Wunsch <joerg_wunsch> |
Wed 07 Dec 2011 03:03:11 PM UTC, comment #3: Well, I wasn't aware of that!
|
Luca Matteini <loucypher> |
Wed 07 Dec 2011 02:39:52 PM UTC, comment #2: I-bit, of course |
Georg-Johann Lay <gjlayde> |
Wed 07 Dec 2011 02:39:16 PM UTC, comment #1: AFAIK, setting the I-big for non-Xmega devices has a latency of 1 instruction, so the code looks fine. |
Georg-Johann Lay <gjlayde> |
Wed 07 Dec 2011 02:29:44 PM UTC, original submission:
While debugging my code I found a bug/race condition in avr/wdt.h that left me astonished (since that code is in effect for a long time now).
the OUT to SREG happens right before the last STS to WDTCSR, making the code non-atomic: the last STS to WDTCSR could be delayed (by an interrupt handler) for many cycles, voiding its effect (has to happen within 4 cycles from the precedent STS to WDTCSR).
|
Luca Matteini <loucypher> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2011-12-07 | joerg_wunsch | Status | None | Invalid | |
Open/Closed | Open | Closed |
Powered by Savane 3.13-02a9.
Corresponding source code
I admit I trusted quality of the compiler for a long time, then!
I don't change my mind anyway on finding questionable the fact how coding style changes every few lines, of the same source file, based on a feature only partially documented by silicon manufacturer.
s/bug/critical review/