Electron STARTUP() blinking red mode led

[Erhughes1944]

The document (example) for STARTUP() suggests that any code will run. STARTUP() worked great for me until I added my own wait that called Time.now().
See snippet. If I comment out my waitAwhile, in setPins() everything is great otherwise blinking red. I call waitAwhile in loop() to show that it works fine. I’m using the DEV IDE and whatever the default system version is 4.8?
UPDATE: I removed the Particle.process() (leaving just {} and no more errors. That may be logical; but, the documentation should be clearer.

#pragma SPARK_NO_PREPROCESSOR
#include "Particle.h"
#include <math.h>


void waitAwhile(unsigned long delay);
//----------------------------------------------------------------
void setPins()
{
  pinMode(D4, OUTPUT); // control valve relay HIGH means open
  digitalWrite(D4, HIGH);
  waitAwhile(1); // this the killer; comment out this statement and it works great.
}

STARTUP(setPins()); //get the pins setup ASAP

//
void setup()
{
  Serial.begin(9600);
  waitAwhile(5);
}
void  loop()
{
  int i = 10;
  while (i>0)
  {
    Serial.println(i);
    i --;
    waitAwhile(1);
  }
    System.enterSafeMode(); // exit
}
//----------------------------------------------------------------
//
//---------------------------------------------------------------
 void waitAwhile(unsigned long delay)
 {
   unsigned long t0 =Time.now() + delay;
   while (Time.now() <= t0) {Particle.process();}
 }

[ScruffR]

Any code that does not require objects for which you instructed the compiler to have your code executed before their initialisation (like Time)

@Erhughes1944

The document (example) for STARTUP() suggests that any code will run.

That's an assumption based on two lines of code?
That's like deriving a fourth order function from two arbitrary sample points.

@Erhughes1944

I removed the Particle.process() (leaving just {} and no more errors. That may be logical; but, the documentation should be clearer.

Particle.process() is tightly related to the network/cloud connection and the docs clearly state

the application wants to have code run as early as possible, before the cloud or network connection are initialized
...
The code referenced by STARTUP() is executed very early in the startup sequence, so it's best suited to initializing digital I/O and peripherals. Networking setup code should still be placed in setup()

And if networking setup code should be in setup() anything depending on this being done already could hardly hope to work before that, could it?

BTW: Time also "needs" cloud connection to give you the correct time

#Time
The device synchronizes time with the Particle Cloud during the handshake.

Using millis() or even delay() might be the better way.

[Erhughes1944]

thanks for explanation. My comment was aimed at obtaining clarity and think you have provided an improvement. If processing() prior to setup(), is fatal it should be blocked even if not logical.