Yun Powerup

Hi Guys,

I'm trying to power up my Yun using a 5 volt regulator that connects to the Vin of the Yun. The problem is it takes the Yun about 1 minute before it executes my first command.
Nevertheless, when I power up the Yun via the micro USB, the Yun operates instantaneously.

Is there any reason as to why this happens?

Regards

Please define "before it executes my first command."

There are two processors on the Yun. The ATMega32U4 that runs the sketch should boot immediately. The AR3391 processor that runs Linux and the networking does normally take a minute or so to boot up.

Which processor is giving you trouble?

How are you sending it commands and how is it responding?

I'm using both processors. The first action of my sketch is to set the value of a DAC (Digital to Analog Converter) to zero. The next thing it does is to connect to the wifi network and send readings of an analog pin to a android tablet and that is all it does the rest of the time until I shut it down.

I'm not sure which processor is giving me trouble, but when I have the Yun powered by the USB I can start using the Yun almost instantaneously. But for the same sketch I have to wait 1 minute before I can start using it, when I power it using a 5 volt regulator connected to Vin.

I’m still confused.

Is the DAC an external chip? Or are you just using analogWrite()? I take it that setting this output is what you called “the first command”? If you are setting an output of zero, how do you know it’s actually getting set?

You say on USB you can start using the Yun almost immediately. I don’t see how this is possible since you are sending readings over WiFi, and that won’t be working for at least a minute while the Linux side boots.

By almost immediately, are you saying that the DAC write happens right away, and then the network starts talking a minute later? That is the only thing that would really make sense.

Then, when running on VIN, are you saying that the DAC write doesn’t happen for a minute?

The really confusing thing is you say “start using the Yun almost immediately” but the thing is that there are two different processors on the Yun, and they have very different startup characteristics. You say you’re using both, but which one is having problems starting up?

I just now tried an experiment with my Yun: I loaded a custom “blink-the-LED” sketch that puts out an easily recognized blink pattern. When I plug the Yun into USB, it starts blinking right away. When I power it with 5V into VIN, it also starts blinking right away. That’s the sketch side. The Linux side, as expected, takes a minute or so to start up, regardless of how I have it powered up. So mine, at least, seems to be working as expected.

@ShapeShifter, I'll try and address your concerns chronologically

Yes I'm using an external DAC. I have the Output of the DAC connected to voltmeter from where I can see the the Yun setting the output of the DAC from a -5V to 0V.

When I said "almost instantaneously" I meant both the DAC value change and wifi connection occurred seconds after I had the Yun powered through the micro USB.

Yes I have to wait a minute when I power the yun through Vin before the yun can even set the DAC value to Zero.

Given that the sketch goes to the ATMega, I would say the ATMega is the one having trouble starting up but I'm not sure and that is why I'm here.

I actually tried running the blink example on the Yun and it started right away no matter how I powered the Yun. But I still ran into the same issue as explained earlier once I ran my code.

Catalyst0001:
I'll try and address your concerns chronologically

And I'm going to go a bit out of order. :smiling_imp:

I can see the the Yun setting the output of the DAC from a -5V to 0V.

OK, most DACs power up with a zero volt output (the minimum value) so I was wondering how you could tell it was being updated to zero. Now it makes sense.

I actually tried running the blink example on the Yun and it started right away no matter how I powered the Yun. But I still ran into the same issue as explained earlier once I ran my code.

Good, that's the way it's supposed to be. You do not appear to have a power supply or hardware problem.

When I said "almost instantaneously" I meant both the DAC value change and wifi connection occurred seconds after I had the Yun powered through the micro USB.

This is simply not possible. It takes somewhere around a minute for the Linux side to boot up, and no WiFi connections are possible until that happens. I suspect you are mistake about how quickly it is starting up on USB power.

I suspect your sketch is starting up properly and immediately after power up. I also suspect that your sketch starts out by initializing the Bridge interface, and then updates the DAC. The bridge interface will not finish initializing until the Linux side is booted up, therefore the sketch will freeze there until Linux is ready.

It would make things much easier if you would post your sketch, or at least your startup code. It's likely one of us will see something subtle in there that explains this apparent change in timing, and I'm certain it will have nothing to do with the power source - if it turns out that it does, I will be dumbfounded.

Below is the start up code
"writeValue" is the function that sends values to the DAC.

/**Main loop

**/
void loop() {
  writeValue(0X1800); //Sets the bipolar output voltage to zero
  
  while(!client.connected()){
    Serial.println("attempting to connect");
    client = server.accept();
  }
  while(client.connected()){
    Serial.println("CLIENT CONNECTED!");
    String string = "";
    char received;
    int index;

      Serial.println("Client still connected");
      if(client.available()){

Sorry, but that's the main loop. I mean the startup code where you initialize the bridge, initialize your client object, server object, etc. Basically everything that's before the loop that you posted. Nothing in that loop will run until all of the startup work is done, and that's where any delay is likely to be occurring.

Below is the setup code

void setup() {
  Serial.begin(9600);
  Bridge.begin();
  
  ///DAC Setup
  pinMode(SDIN, OUTPUT); //Pin for Pin for data input to the DAC9
  pinMode(SCLK, OUTPUT); //Pin for Clock
  pinMode(SYNC, OUTPUT); //Pin for Data entry control
  pinMode(LDAC, OUTPUT); //Pin for DAC automatic Data update control 
  
  SPI.setDataMode(SPI_MODE1);
  //SPI.setClockDivider(2);
  
  digitalWrite(SDIN, LOW);
  digitalWrite(SCLK, HIGH);
  digitalWrite(SYNC, HIGH);
  digitalWrite(LDAC, HIGH);
  ///DAC Setup end
  
  ///Timer1 setup
  Timer1.initialize(100000);  //Iniitializes the timer
  Timer1.attachInterrupt(Timer1ISR);  //Attach interrupt to Timer1 Interrupt Service routine
  Timer1.stop();  //stop the counter
  ////Timer1 setup end
  ///Incremental Setup
  pinMode(2, INPUT); //ChannelA
  pinMode(3, INPUT); //ChannelB
  
  attachInterrupt(0, Achange, CHANGE);
  attachInterrupt(1, Bchange, CHANGE);
  
  //Read the initial value of A and B
  A = digitalRead(2);
  B = digitalRead(3);
  
  //Set inital State value
  if(A==HIGH && B==HIGH) statep = 0;
  if(A==HIGH && B==LOW) statep = 1;
  if(A==LOW && B==LOW) statep = 2;
  if(A==LOW && B==HIGH) statep = 3;
  ///////Incremental Setup end
  
  server.noListenOnLocalhost();
  server.begin();
}

To evaluate the voltage regulator section, we need some details. Have you measured the voltage at the regulator output? Which regulatorare you using, and what are you using to provide the input voltage to the regulator? Is the regulator getting warm/hot? It would be great if you could attach an image of your schematic.

Catalyst0001:

void setup() {

Serial.begin(9600);
  Bridge.begin();

There is no way that you will get past this code "almost immediately" under any power supply conditions. The Bridge.begin() call will not return until bridge communications with the Linux side has been initialized. That won't happen until Linux has booted up sufficiently. It take Linux a minute or so to boot up sufficiently. Ergo, the code will not get past this point "almost immediately."

I cannot understand how it is possible for what you are reporting to happen.

ShapeShifter:
There is no way that you will get past this code "almost immediately" under any power supply conditions. The Bridge.begin() call will not return until bridge communications with the Linux side has been initialized. That won't happen until Linux has booted up sufficiently. It take Linux a minute or so to boot up sufficiently. Ergo, the code will not get past this point "almost immediately."

I cannot understand how it is possible for what you are reporting to happen.

I agree with ShapeShifter.

@Catalyst: try to add a Serial.println("Started") after the Bridge.begin( ) so you can see when the code effectively starts.

Angelo9999:
@Catalyst: try to add a Serial.println("Started") after the Bridge.begin( ) so you can see when the code effectively starts.

Or better yet:

pinmode(13, OUTPUT);
digitalwrite(13, HIGH);

so that the D13 LED turns on once the code effectively starts. No serial connection needed that way.


Another thing I notice, which probably isn't a cause of the immediate issue, but may be worth noting. The setup() function sets up the server, and the loop function immediately checks client.connected(). Where is this client object coming from the first time through loop? I assume that later in loop() there is a connection attempt if the client is not connected. I've run into problems if the client object doesn't exist the first time around.

I've successfully used this model in the past (lots of details left out and not intended to compile.) Note how server.accept() is called before the end of setup():

void setup()
{
  Bridge.begin();
  // Other startup
  server.begin();
  client = server.accept(); // Just to get a valid client object, even if not connected.
}

void loop()
{
  if (client.connected())
  {
     // Connected, so handle the connection
  }
  else
  {
    // Not connected, so try to accept a new connection.
    // If connected, it will be processed during the next loop.
    client = server.accept();
  }
}