Electronic – Due to overcurrent, shouldn’t I be extremely cautious when setting an I/O pin as Output

The STR91x family of microcontrollers has very flexible peripherals. Unfortunately, this flexibility makes them somewhat complicated to set up. My suggestion is to start by downloading the STR91xFA Firmware Library from ST.com. Once you have the library linked into your project, you need to do something similar to the following:

void InitGPIO7( void )
{
   GPIO_InitTypeDef GPIO_InitStructure;

   /* Enable the GPIO7 clock */
   SCU_APBPeriphClockConfig(__GPIO7, ENABLE);

   /* Initialize the GPIO port */
   GPIO_DeInit(GPIO7);

   /* Configure pin GPIO7.3 */
   GPIO_InitStructure.GPIO_Direction = GPIO_PinOutput;
   GPIO_InitStructure.GPIO_Pin = GPIO_Pin_3;
   GPIO_InitStructure.GPIO_Type = GPIO_Type_PushPull;
   GPIO_InitStructure.GPIO_IPConnected = GPIO_IPConnected_Disable;
   GPIO_InitStructure.GPIO_Alternate = GPIO_OutputAlt1;
   GPIO_Init (GPIO7, &GPIO_InitStructure);
}

Note that this is untested but it should be pretty close.

Not a real answer, but too much information to include in a the comments:

I took a look at your disassembled code and this part is strange:

  18:   11 24           eor r1, r1          ; r1 = 0

...

0000005e <main>:
  5e:   8f ef           ldi r24, 0xFF   ; 255
  60:   8a bb           out DDRA, r24   ; DDRA=0xff (output)
  62:   87 bb           out DDRB, r24   ; DDRB=0xff (output)
  64:   1a ba           out DDRA, r1    ; DDRA=0x00 (input)

Definitely something strange is going on. DDRA is set to output and shortly after that it is set to input. This explains the 2V5 glowing of your LED's, you're seeing the LED's glow by the current through the internal pull up resistors. This explains what you see, but I cannot explain why this is happening.

I compiled the code on my own PC and although I cannot test it on an ATtiny26, it looks fine to me. So here are the tool versions that I use:

• avr-gcc --version → avr-gcc (GCC) 4.7.0
• avr-objcopy --version → GNU objcopy (GNU Binutils) 2.20.1.20100303
• avr-objdump --version → GNU objdump (GNU Binutils) 2.20.1.20100303

These are the commands I use to generate the disassambly:

avr-gcc $(cflags) -mmcu=$(avrType) -c -o $(src).o $(src).cpp
avr-gcc $(cflags) -mmcu=$(avrType) -o $(src).elf $(src).o
avr-objdump -C -d $(src).elf

And to flash:

avr-objcopy -j .text -j .data -O ihex $(src).elf $(src).hex
avrdude -p$(avrType) -c$(programmerType) -P$(programmerDev) -b$(baud) -v -U flash:w:$(src).hex

Notice that $(..) are variables, in my test case:

baud=19200
src=main
avrType=attiny26
avrFreq=1000000
programmerDev=/dev/ttyUSB003
programmerType=stk500v1
cflags=-g -DF_CPU=$(avrFreq) -Wall -Os

The resulting code looks as follows (sniplet):

00000044 <main>:
  44:   8f ef           ldi     r24, 0xFF       ; 255
  46:   8a bb           out     DDRA, r24       ; 26
  48:   87 bb           out     DDRB, r24       ; 23
  4a:   c0 e4           ldi     r28, 0x40       ; 64
  4c:   cb bb           out     PORTA, r28      ; 27
  4e:   c8 bb           out     PORTB, r28      ; 24
  50:   84 e6           ldi     r24, 0x64       ; 100
  52:   90 e0           ldi     r25, 0x00       ; 0
  54:   e8 df           rcall   .-48            ; 0x26 <milli_delay(int)>
  56:   1b ba           out     PORTA, r1       ; 27
  58:   18 ba           out     PORTB, r1       ; 24
  5a:   84 e6           ldi     r24, 0x64       ; 100
  5c:   90 e0           ldi     r25, 0x00       ; 0
  5e:   e3 df           rcall   .-58            ; 0x26 <milli_delay(int)>
  60:   f5 cf           rjmp    .-22            ; 0x4c <main+0x8>

And in contrast to your code where DDRA is written twice (once 0x00 and once 0xff), here it is only written once.