3.4.for crying out loud...

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey, version 3.4.4 of the toolchain is out! Great! Well, OK, there have been some problems with the download page (there still are), but this should be an improvement, right?

What's this?! A project which builds fine in 3.4.3 now fails in 3.4.4!?

I now get the following error:

In file included from :1:0:
./fuses_and_lockbits.h:9:16: error: expected expression before ')' token
   .extended = EFUSE_DEFAULT,
                ^

Huh? OK, this is because all of my projects include a file called fuses_and_lockbits.h which starts out like this:

#include 

FUSES = {
  .low = LFUSE_DEFAULT ,
  .high = HFUSE_DEFAULT,
  .extended = EFUSE_DEFAULT,
};

LOCKBITS = (LOCKBITS_DEFAULT);

I make adjustments as required, and my makefile then does a bit of fiddling with avr-objcopy and srec to pass the fuses and lock bits to avrdude.

Fine. But why is this failing now?

A quick diff of iom328p.h shows why:

--- avr8-gnu-toolchain-linux_x86.3.4.3/avr/include/avr/iom328p.h	2013-11-19 03:08:01.000000000 -0500
+++ avr8-gnu-toolchain-linux_x86_64.3.4.4/avr/include/avr/iom328p.h	2014-04-25 10:55:33.000000000 -0400
@@ -344,6 +344,7 @@
 #define PGWRT 2
 #define BLBSET 3
 #define RWWSRE 4
+#define SIGRD 5
 #define RWWSB 6
 #define SPMIE 7
 
@@ -893,21 +894,22 @@
 #define LFUSE_DEFAULT (FUSE_CKSEL0 & FUSE_CKSEL2 & FUSE_CKSEL3 & FUSE_SUT0 & FUSE_CKDIV8)
 
 /* High Fuse Byte */
-#define FUSE_BODLEVEL0 (unsigned char)~_BV(0)  /* Brown-out Detector trigger level */
-#define FUSE_BODLEVEL1 (unsigned char)~_BV(1)  /* Brown-out Detector trigger level */
-#define FUSE_BODLEVEL2 (unsigned char)~_BV(2)  /* Brown-out Detector trigger level */
+#define FUSE_BOOTRST (unsigned char)~_BV(0)
+#define FUSE_BOOTSZ0 (unsigned char)~_BV(1)
+#define FUSE_BOOTSZ1 (unsigned char)~_BV(2)
 #define FUSE_EESAVE    (unsigned char)~_BV(3)  /* EEPROM memory is preserved through chip erase */
 #define FUSE_WDTON     (unsigned char)~_BV(4)  /* Watchdog Timer Always On */
 #define FUSE_SPIEN     (unsigned char)~_BV(5)  /* Enable Serial programming and Data Downloading */
 #define FUSE_DWEN      (unsigned char)~_BV(6)  /* debugWIRE Enable */
 #define FUSE_RSTDISBL  (unsigned char)~_BV(7)  /* External reset disable */
-#define HFUSE_DEFAULT (FUSE_SPIEN)
+#define HFUSE_DEFAULT (FUSE_BOOTSZ0 & FUSE_BOOTSZ1 & FUSE_SPIEN)
 
 /* Extended Fuse Byte */
-#define FUSE_BOOTRST (unsigned char)~_BV(0)
-#define FUSE_BOOTSZ0 (unsigned char)~_BV(1)
-#define FUSE_BOOTSZ1 (unsigned char)~_BV(2)
-#define EFUSE_DEFAULT (FUSE_BOOTSZ0 & FUSE_BOOTSZ1)
+#define FUSE_BODLEVEL0 (unsigned char)~_BV(0)  /* Brown-out Detector trigger level */
+#define FUSE_BODLEVEL1 (unsigned char)~_BV(1)  /* Brown-out Detector trigger level */
+#define FUSE_BODLEVEL2 (unsigned char)~_BV(2)  /* Brown-out Detector trigger level */
+
+#define EFUSE_DEFAULT ()

OK, so a few things have been fixed. SIGRD is finally there, HFUSE_DEFAULT isn't wrong anymore, and the comment above groups of fuses now reflects reality. But...What!? EFUSE_DEFAULT has be redefined as () ?! It needed to be fixed, but not like that. It should read:

#define EFUSE_DEFAULT (0xFF)

For a long time the fuses were (incorrectly) just lifted from the other members of the family (48/88/168). Now that they've finally tried to fix it, they broke it in a new and special way.

[sigh]

I quick recursive grep shows that iom328p is the only file that suffers from this gaff. Lucky me.

Guess I'll just fix my local copy until 3.4.5 blows I mean shows up.

What the heck is going on over there? ;)

////////////////////////////////////////////////////////////////////////////////////////////////////

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That commit had my name on it, so red faces all around :|

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've never really explored their bugzilla but might it reveal where/when/why/who/etc ?

EDIT: Oops too slow to post reply.

(but I do like "git/svn blame" - it's always fun being able to poke the person who broke your code!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It was part of fixing the 328p fuses, as they have been wrong for time in memorial. In that process, it seems that I failed to really contemplate on how 'None' is represented, and just moved the former default from EFUSE to HFUSE...

Cause:


--- iom328p.h
+++ iom328p.h
@@ -893,21 +893,22 @@
#define LFUSE_DEFAULT (FUSE_CKSEL0 & FUSE_CKSEL2 & FUSE_CKSEL3 & FUSE_SUT0 & FUSE_CKDIV8)

/* High Fuse Byte */
-#define FUSE_BODLEVEL0 (unsigned char)~_BV(0) /* Brown-out Detector trigger level */
-#define FUSE_BODLEVEL1 (unsigned char)~_BV(1) /* Brown-out Detector trigger level */
-#define FUSE_BODLEVEL2 (unsigned char)~_BV(2) /* Brown-out Detector trigger level */
+#define FUSE_BOOTRST (unsigned char)~_BV(0)
+#define FUSE_BOOTSZ0 (unsigned char)~_BV(1)
+#define FUSE_BOOTSZ1 (unsigned char)~_BV(2)
#define FUSE_EESAVE (unsigned char)~_BV(3) /* EEPROM memory is preserved through chip erase */
#define FUSE_WDTON (unsigned char)~_BV(4) /* Watchdog Timer Always On */
#define FUSE_SPIEN (unsigned char)~_BV(5) /* Enable Serial programming and Data Downloading */
#define FUSE_DWEN (unsigned char)~_BV(6) /* debugWIRE Enable */
#define FUSE_RSTDISBL (unsigned char)~_BV(7) /* External reset disable */
-#define HFUSE_DEFAULT (FUSE_SPIEN)
+#define HFUSE_DEFAULT (FUSE_BOOTSZ0 & FUSE_BOOTSZ1 & FUSE_SPIEN)

/* Extended Fuse Byte */
-#define FUSE_BOOTRST (unsigned char)~_BV(0)
-#define FUSE_BOOTSZ0 (unsigned char)~_BV(1)
-#define FUSE_BOOTSZ1 (unsigned char)~_BV(2)
-#define EFUSE_DEFAULT (FUSE_BOOTSZ0 & FUSE_BOOTSZ1)
+#define FUSE_BODLEVEL0 (unsigned char)~_BV(0) /* Brown-out Detector trigger level */
+#define FUSE_BODLEVEL1 (unsigned char)~_BV(1) /* Brown-out Detector trigger level */
+#define FUSE_BODLEVEL2 (unsigned char)~_BV(2) /* Brown-out Detector trigger level */
+
+#define EFUSE_DEFAULT ()

Fix:


--- iom328p.h
+++ iom328p.h
@@ -908,8 +908,7 @@
#define FUSE_BODLEVEL0 (unsigned char)~_BV(0) /* Brown-out Detector trigger level */
#define FUSE_BODLEVEL1 (unsigned char)~_BV(1) /* Brown-out Detector trigger level */
#define FUSE_BODLEVEL2 (unsigned char)~_BV(2) /* Brown-out Detector trigger level */
-
-#define EFUSE_DEFAULT ()
+#define EFUSE_DEFAULT (0xFF)

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

(but I do like "git/svn blame" - it's always fun being able to poke the person who broke your code!)

Especially when that is yourself :D

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:
It was part of fixing the 328p fuses, as they have been wrong for time in memorial. In that process, it seems that I failed to really contemplate on how 'None' is represented, and just moved the former default from EFUSE to HFUSE...
Morten,

Sorry I lost my cool. I blame my barometric headache :shocked:

Truthfully, thanks for the fix in the first place. It was a minor but longstanding issue. I've adjusted my local copy. Just out of curiousity, will this get fixed 'in-place' for 3.4.4? Or 3.4.5...

Cheers,
JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Just out of curiousity, will this get fixed 'in-place' for 3.4.4? Or 3.4.5...

The next one :) Already committed to our source, and I'll see about making a patch to avr-libc next week.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

and I'll see about making a patch to avr-libc next week.

Well, what do you know... We have actually updated avr-libc and forgot to update our own repo.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Morten

So you're using a "stock" avr-libc ?
And not an atmel patched source.

Meaning can i use the avr-libc from Savannah ?

I suppose i have to check out the SVN version , correct ?

Afaik Jörg hasn't released a new avr-libc "package" in a while.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:
Quote:

Just out of curiousity, will this get fixed 'in-place' for 3.4.4? Or 3.4.5...

The next one :) Already committed to our source, and I'll see about making a patch to avr-libc next week.

@Morten

Couldn't you also update the avr-libc file here "please"
http://distribute.atmel.no/tools...

And maybe correct the readme to reflect the dependancy of the ncurses source package , that gdb uses.

You have mentioned mpfr etc , but misses to mention ncurses.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

You have mentioned mpfr etc , but misses to mention ncurses.

I don't work with the toolchain, but I can pass it along...

Quote:

Couldn't you also update the avr-libc file here "please"
http://distribute.atmel.no/tools... ... ain/3.4.4/

Those files follow a toolchain release, so it will get updated when the next toolchain version is released.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a specific reason to write

(unsigned char)~_BV(2)

and not

((unsigned char)~_BV(2))

And _BV is really antique and we are telling users to avoid it in new code.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, not really...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)