[avr-gcc-list] just 2 bytes allocated for uint32_t?

[Radoslav Kolev]

Hello!

I wanted to rebuild the Arduino Atmega8 bootloader using avr-gcc
4.2.2, installed from the Ubuntu 8.04.1 packages.

At first I run against the problem of 4.x gcc versions producing
bigger code, compared to 3.x versions that doesn't fit in the 1k boot
loader space. The bug report is here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908

The problem is the compiler inlining functions more than once,
resulting in bigger code, even when the -0s option is specified. I was
able to work around this issue by passing the -finline-limit=1
parameter. The code compiles and fits in the bootloader space. But
after testing on one Atmega8 it didn't work right. The MCU gets stuck
in the bootloader forever, and never gets to executing the main
program.

I tracked it down to the following part:

char getch(void)
{
  /* m8 */
        uint32_t count = 0;
  while(!(inb(UCSRA) & _BV(RXC))) {
                /* HACKME:: here is a good place to count times*/
                count++;
                if (count > MAX_TIME_COUNT)
                        app_start();
  }
  return (inb(UDR));
}

The complete code is available here:
http://code.google.com/p/arduino/source/browse/#svn/trunk/hardware/bootloaders/atmega8

So if there is no data coming in through the USART a counter is
incremented. After it reaches some value the main program is started.
The MAX_TIME_COUNT constant is frequency dependent and is in the range
of 1000000-16000000. In my case the count variable was rolling over
back to zero at 65535, so never reaching the MAX_TIME_COUNT value and
the MCU is forever stuck in the bootloader.

I suspect this, because setting MAX_TIME_COUNT to 65534 gives the
expected very short delay, but setting it to 65535 gives an infinite
loop.

When I changed the type of the count variable from uint32_t to
unsigned long things started working correctly.

But aren't uint32_t and unsigned long supposed to be the same and both
4 bytes long in this case?

Can someone give me a hint or explanation of the above behaviour?

Best regards,
Radoslav Kolev