ATTiny 25V - 1MHz - Huge delay not working

I have a project using an ATTiny board that, in certain cases, has to stand idle for very long amounts of time (~45 minutes, that is 2,700,000ms).
I’m used to the _delay_ms function, but that number is too huge and, basically, the chip stands idle forever.

I then tried to put a for loop like

for(int i=0; i<1000; i++) _delay_ms(2700);

which still does not work as expected (i.e. the chip still keeps going).

Since these are some huge delays, do you know any tricks I can use to make the thing work?
Thanks a lot in advance

Are you compiling it for 8mhz instead of 1mhz? If you did, it would run at 1/8th the expected speed, so the delays would be so long you might conclude they're going on for ever.

delay takes an unsigned long so it should work up to 4.2 billion milliseconds.

I actually don't know how to check for this, sorry… :-[
I used some makefiles from a book, and the avr-gcc -DFCPU option is set to 1000000UL.
Also I defined F_CPU in my code as

#define F_CPU 1000000UL

That should be it, right?

Okay, yup.

So you’re also not using the Arduino IDE.

delay_ms takes a double…

See the comment in util/delay.h

   \ingroup util_delay

   Perform a delay of \c __ms milliseconds, using _delay_loop_2().

   The macro F_CPU is supposed to be defined to a
   constant defining the CPU clock frequency (in Hertz).

   The maximal possible delay is 262.14 ms / F_CPU in MHz.

   When the user request delay which exceed the maximum possible one,
   _delay_ms() provides a decreased resolution functionality. In this
   mode _delay_ms() will work with a resolution of 1/10 ms, providing
   delays up to 6.5535 seconds (independent from CPU frequency).  The
   user will not be informed about decreased resolution.

   If the avr-gcc toolchain has __builtin_avr_delay_cycles(unsigned long)
   support, maximal possible delay is 4294967.295 ms/ F_CPU in MHz. For
   values greater than the maximal possible delay, overflows results in
   no delay i.e., 0ms.

   Conversion of __us into clock cycles may not always result in integer.
   By default, the clock cycles rounded up to next integer. This ensures that
   the user gets atleast __us microseconds of delay.

   Alternatively, user can define __DELAY_ROUND_DOWN__ and __DELAY_ROUND_CLOSEST__
   to round down and round to closest integer.

   Note: The new implementation of _delay_ms(double __ms) with 
    __builtin_avr_delay_cycles(unsigned long) support is not backward compatible. 
   User can define __DELAY_BACKWARD_COMPATIBLE__ to get a backward compatible delay.
   Also, the backward compatible
   algorithm will be chosen if the code is compiled in a <em>freestanding
   environment</em> (GCC option \c -ffreestanding), as the math functions
   required for rounding are not available to the compiler then.


Ok… I already read that but I did not quite understand it.
Anyhow, thanks to your suggestion, I tried to use a slower time (i.e. 60 seconds) and what I found is that the "wait" is doubled. I think this can be due to a lot of reasons… I'd better check out the whole code.
Thanks anyway