AVR Freaks

The only thing I can think of is to start your function off with return 0x06 (basically the function does nothing) & see if you are print 6 as expected...

Sure enough, if I explicitly enter an integer literal for the function return, that is what gets printed to both the UART and the LCD.  I've used the same UART library for several other small projects and have had no issues with it before, so I'm pretty comfortable trusting the return values streamed over the serial port.

We freaks often ask for a complete minimal test program that demonstrates the problem. This is one of those cases.

Good idea.  My program isn't that big but it's split into a 6 different files on account of the UART and LCD libraries.  I'll try to consolidate everything into the shortest program that still has the issue.  

Thanks again.

Thanks to everyone for the helpful responses!  I determined that it's definitely an issue with the optimization settings in the version of avr-gcc 4.8.1 that I'm using.  If I select optimization level 2 or higher, and the function with the switch is in a separate .c file, the switch/case does not work properly if I add a third case statement.  Going down to optimization level 1 or 0 makes everything work fine again.

The funny thing is that if I compile the exact same files with avr-gcc 4.3, I can use all of the optimization levels and don't have any problems.

I'm new to looking at the asm output and need to spend more time figuring out how to save and interpret the asm output.  Whenever I use objdump on my program object file the result is almost 2k lines long and it's not clear to me yet which parts are relevant.  I'll study up on this and follow up once I have a better grasp on the asm dump.

Please let me know if there's a better way to post my program other than copy-and-paste.  Here are the files which I'm compiling in avr-gcc 4.8.1.  I've stripped them all of the UART and other LCD code from my program, and whittled it town to a single function in lcd.c which is called by the main program.  There are big differences in the asm dump depending on if all three cases are included, or if the third case is commented out.  Here's the code for lcd.c, including the switch statement:

// lcd.c

#include "lcd.h"

char lcd_get_offset(char row) {
  char row_offset = 0x00; // initialize to zero
  switch(row) {
  case 1 :
    row_offset = 0x01;
    break;
  case 2 :
    row_offset = 0x02;
    break;
  case 3 :
    row_offset = 0x03;
    break;
  default :
    row_offset = 0x06;
    break;
  }
  return row_offset;
}

The header is just:

//lcd.h
char lcd_get_offset(char row);

The program that calls the function is:

// trigger_counter.c
#define F_CPU 14745600  // Clock speed in Hz

#include "./lcd.h"

int main() {

  char switch_result0 = 0;
  char switch_result1 = 0;
  char switch_result2 = 0;

  switch_result0 = lcd_get_offset(0);
  switch_result1 = lcd_get_offset(1);
  switch_result2 = lcd_get_offset(2);

  while(1) {
    // do nothing
  }

  return 0;
}

The makefile I'm using to compile this is

GCCFLAGS=-g -O2 -Wall -mmcu=atmega168

all:	trigger_counter.c lcd.c
	avr-gcc ${GCCFLAGS} -o lcd.o -c lcd.c
	avr-gcc ${GCCFLAGS} -o trigger_counter.o trigger_counter.c lcd.o
	avr-objcopy -j .text -O ihex trigger_counter.o trigger_counter.hex

Using avr-objdump to look at the asm generated by the compiler, the output is very different depending on if I include the third case in the switch statement.  With the third case included, the dump of lcd.o is as follows. 

// output with all 3 cases included in switch statement
lcd.o:     file format elf32-avr

Disassembly of section .text:

00000000 <lcd_get_offset>:
// lcd.c

#include "lcd.h"

char lcd_get_offset(char row) {
   0:	81 50       	subi	r24, 0x01	; 1
   2:	83 30       	cpi	r24, 0x03	; 3
   4:	00 f4       	brcc	.+0      	; 0x6 <lcd_get_offset+0x6>
   6:	e8 2f       	mov	r30, r24
   8:	f0 e0       	ldi	r31, 0x00	; 0
   a:	e0 50       	subi	r30, 0x00	; 0
   c:	f0 40       	sbci	r31, 0x00	; 0
   e:	80 81       	ld	r24, Z
  10:	08 95       	ret
  char row_offset = 0x00; // initialize to zero
  switch(row) {
  12:	86 e0       	ldi	r24, 0x06	; 6
  default :
    row_offset = 0x06;
    break;
  }
  return row_offset;
}
  14:	08 95       	ret

And now here's the object dump with case 3 commented out in the switch statement, still using -O2.  The program works as expected in this case.  It's interesting that commenting out the third switch case results in a significantly larger asm dump:

// output with only 2 cases included in switch statement
lcd.o:     file format elf32-avr

Disassembly of section .text:

00000000 <lcd_get_offset>:

#include "lcd.h"

char lcd_get_offset(char row) {
  char row_offset = 0x00; // initialize to zero
  switch(row) {
   0:	81 30       	cpi	r24, 0x01	; 1
   2:	01 f0       	breq	.+0      	; 0x4 <lcd_get_offset+0x4>
   4:	82 30       	cpi	r24, 0x02	; 2
   6:	01 f4       	brne	.+0      	; 0x8 <lcd_get_offset+0x8>
  case 1 :
    row_offset = 0x01;
    break;
  case 2 :
    row_offset = 0x02;
   8:	82 e0       	ldi	r24, 0x02	; 2
  default :
    row_offset = 0x06;
    break;
  }
  return row_offset;
}
   a:	08 95       	ret
    break;
    //case 3 :
    //row_offset = 0x03;
    //break;
  default :
    row_offset = 0x06;
   c:	86 e0       	ldi	r24, 0x06	; 6
    break;
   e:	08 95       	ret

char lcd_get_offset(char row) {
  char row_offset = 0x00; // initialize to zero
  switch(row) {
  case 1 :
    row_offset = 0x01;
  10:	81 e0       	ldi	r24, 0x01	; 1
  12:	08 95       	ret

I'm still figuring out what all of the asm instructions mean, but this second asm dump with just 2 cases in the switch has much more going on than the first dump, which had all three cases in the switch. 

I can also post assembly dumps of the whole program which is much, much longer, and the asm dumps with optimization off, but I think these two capture the issue. As I mentioned before, with the optimization totally off, the switch/case statement works whether I have two cases, or three.

Any thoughts?  Otherwise I'm going to keep learning the asm to try and make sense of this.  Thanks again.