Global Array Size Affects Clock Frequency (avr-gcc on Linux)

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

I am having the most peculiar problem. When the size of a global array changes, it alters the clock frequency of the ATmega164a. This is on Linux. When compiled on Windows, this problem doesn't occur (irrespective of whether the .hex file is actually programmed onto the ATmega164a in Windows or Linux aka I don't suspect avrdude is contributing to this problem). I even ran on Linux the exact commands run by AVR Studio to build the target, and still encountered this problem.

The CLKDIV8 fuse is not set, and the Internal RC fuse is set, so the ATmega164a should be running at 8MHz nominal.

This is the minimum working example of the code that runs correctly:

#include 
uint8_t bytes[6];
int main(void){
    DDRB = (1<<PB5);

    while(1){
        PORTB |= (1<<PB5);
        PORTB &= ~(1<<PB5);
    }
}

An oscilloscope shows the resulting pulse is 250ns wide (2 cycles).

However, increasing the global array size by one results in odd behavioral.

#include 
uint8_t bytes[7];
int main(void){
    DDRB = (1<<PB5);

    while(1){
        PORTB |= (1<<PB5);
        PORTB &= ~(1<<PB5);
    }
}

An oscilloscope shows this pulse width as 444ns, and the time between pulses increases in the same ratio which indicates the clock frequency has decreased.

I have no clue where to go from here. It took me a very long time just to narrow it down to this minimum working example. I have attached my Makefile. Any help would be greatly appreciated.

Attachment(s): 

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

Versions of compilers on the two systems?
Optimization setting on Windows/Atmel Studio?

What happens if you change optimization on the Linux system from

OPT = 1

to

OPT = s

?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

The problems persists with either the -Os or -O1 compiler flags.

The avr-gcc versions are:
Linux: 4.5.3
Windows: (AVR_8_bit_GNU_Toolchain_3.4.1_830) 4.6.2

I have also attached the .lss files for both cases compiled with the -O1 flag.

Also, I have verified with the internal 16bit timer in CTC mode that the clock frequency is indeed decreasing by the factor previously quoted (250ns -> 444ns)

Attachment(s): 

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

How weird. Would have me completely befuddled, but then, it doesn't take much.

Try looking in the generated ASM for the PortB access. Is the generated code the same?

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

The start of the BSS section is incorrectly set to 0x60.

The address of OSCCAL on a ATmega164a is 0x66.

So when the array is 7 bytes long zero is written OSCCAL when the program starts.

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

This is PR50652. You can use a compiler version where this bug is fixed or use a known work around.

avrfreaks does not support Opera. Profile inactive.

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

Thank you TimothyEBaldwin and SprinterSB. Upgraded my avr-gcc to 4.7.2 and all is well. Unfortunately Ubuntu repositories use version 4.5.3

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

Quote:

Unfortunately Ubuntu repositories use version 4.5.3

Never use a repo version. Canonical know as much about building avr-gcc as Atmel do!