avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] [bugs #8391] Fuse mask in boot.h wrong?


From: Theodore A. Roth
Subject: [avr-libc-dev] [bugs #8391] Fuse mask in boot.h wrong?
Date: Tue, 20 Apr 2004 14:48:18 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3

This mail is an automated notification from the bugs tracker
 of the project: AVR C Runtime Library.

/**************************************************************************/
[bugs #8391] Latest Modifications:

Changes by: 
                Theodore A. Roth <address@hidden>
'Date: 
                Tue 04/20/04 at 18:48 (US/Pacific)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Fixed
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
I decided to change the macro to take the complement of lock_bits as I 
previously suggested.

The fix has been committed to HEAD and 1.0 branches.






/**************************************************************************/
[bugs #8391] Full Item Snapshot:

URL: <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=8391>
Project: AVR C Runtime Library
Submitted by: 0
On: Wed 03/31/04 at 18:20

Category:  Header
Severity:  5 - Average
Item Group:  None
Resolution:  Fixed
Assigned to:  troth
Originator Email:  address@hidden
Status:  Closed


Summary:  Fuse mask in boot.h wrong?

Original Submission:  Fuse-Mask in boot.h may be wrong. In current (31 Mar 04):

/* Define the bit positions of the Boot Lock Bits. */
#define BLB12           5
#define BLB11           4
#define BLB02           3
#define BLB01           2
#define __BOOT_LOCK_BITS_MASK  (_BV(BLB01) | _BV(BLB02) 
                               | _BV(BLB11) | BV(BLB12))

didn't work for me in an AVRStuido STK500-plugin-compatible bootloader on an 
ATmega16. To fix this issue here it has been changed like this:

/* Define the bit positions of the Boot Lock Bits. */
#define BLB12           5
#define BLB11           4
#define BLB02           3
#define BLB01           2
// mt:
#define LB2             1
#define LB1             0
#define LOCK6           6
#define LOCK7           7
#define __BOOT_LOCK_BITS_MASK (_BV(LB1) | _BV(LB2) |  
                               _BV(LOCK6) | _BV(LOCK7))

BTW. The bug I've submited regarding sleep.h and ATmega169 haven't been fixed 
so far. At least a remark in the documentation (like the one in/for eeprom.h) 
would avoid time-consuming debugging on the users-side until someone has time 
to fix this bug.

Follow-up Comments
------------------


-------------------------------------------------------
Date: Tue 04/20/04 at 18:48         By: troth
I decided to change the macro to take the complement of lock_bits as I 
previously suggested.

The fix has been committed to HEAD and 1.0 branches.

-------------------------------------------------------
Date: Tue 04/06/04 at 20:19         By: troth
Looks like we have the mask bits inverted in boot.h.

It also looks like there's some confusion in the __boot_lock_bits_set() macro. 
When using this macro, the lock_bits argument is really the BLB bits that will 
be cleared (i.e. written to 1). It seems to me that the proper fix for this 
would be changing this line in the __boot_lock_bits_set() macro:

uint8_t value = (uint8_t)(lock_bits|__BOOT_LOCK_BITS_MASK);

to this:

uint8_t value = (uint8_t)(~(lock_bits));

which would make __BOOT_LOCK_BITS_MASK unnecessary.

I would like to think this over some more and will post a patch to the dev list 
soon.

BTW: Instead of noting the sleep bug here, it would have been better to just 
post a follow-up comment for that bug.












For detailed info, follow this link:
<http://savannah.nongnu.org/bugs/?func=detailitem&item_id=8391>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/







reply via email to

[Prev in Thread] Current Thread [Next in Thread]