Of course it isn't impossible. There may be other mechanisms for the C code to deduce time than a built-in timer. An external GPS may produce a 1Hz tick on an interrupt or send in $GMRMC strings with time information.

The system may perform some synchronous transfers that results in a transfer interrupt at a fixed frequency.

It might be possible to read a frequency divider somewhere in an SPI device.

The list of possible sources of timing information can be made almost infinite, so "impossible" is a quite strong word to use.

The only thing that can be said is that C code that does not have access to any timing information and just creates the delay with a number of dummy instructions - possibly in a loop - can work but is so extremely unreliable that it should be avoided if at all possible.


A target may not have anything better to do, so wasting foreground time may not matter. And the delay need not be "just" a delay. It may be a delay waiting for something to happen, in which the 60 seconds represents a timeout. An example: A boot loader may wait a specific time for serial data to inform it that the application should be updated. During this wait, the boot loader does not have anything better to do so it doesn't matter if it busy-loops.

What is unacceptable for one product may be perfectly ok for another product.

Look at battery chargers. Some microprocessor-controlled battery chargers uses busy loops or sleep between checking ADC samples. You may remove a battery and then see the charge lamp continue to light for maybe a second or two until the charger notices the zero charge current or the very high charge voltage and turns off the LED. Nothing wasteful with such a busy-loop.