Go Down

Topic: Power up and running the sketch (Read 12060 times) previous topic - next topic



I have been navigating around other topics to find how i can program my yun and have the sketch run with external power.
I found some things on the FAQ area mentioning that we need an 10k ohms at RX pin to make sure it dont run the bootloader code but the code i want.

This topic looks to be for other arduinos and i would like to confirm if this make sense for Yun.
It it is, I would like to understand better the reasons. What is the RX pin when we power up? Does it make the SW pointer go to my code instead of bootloader? Why the default is bootloader if we can move to the bootloader when load new SW from the arduino sketch interface?

Thanks in advance!


Your sketch will run when it powers up, you shouldn't need to do any modifications that I know of.

Here's my understanding:
Reset or Power up happens
Bootloader looks for something trying to load a program (sketch) for a few seconds, if it sees this it loads the program into flash.
Bootloader exits and runs program in flash (if it didn't load a new one the last one is still in flash)

Various tricks are done to cause a reset on a running Arduino so this can happen by pushing a button in the IDE.

Do remember that the Leonardo part starts up quickly and the Linino part takes about a minute to be up and running after power up.

Be careful with your power supply it needs to be fairly close to 5V, I use a cell phone charger on the micro usb.


Oct 25, 2013, 11:41 pm Last Edit: Oct 25, 2013, 11:44 pm by jpremor Reason: 1
Well, then i have some problems on my side.
Pretty strange but the sketch is not starting with no modifications to the board.

I have been powering up by the Atmel USB connector with external USB charger.

Just saw in another post how to reset the mcu from Linino. I did it and then the sketch runs. Something is happening in the boot, because it confirms that the firmware is there since last programming.

Any thoughts?


Well, I don't understand your desire to bypass the bootloader, it just allows you to upload a sketch when the AVR is reset, if it doesn't receive an upload it runs the sketch that was last uploaded, the practical effect is a delay of a few seconds when powering up.

Try this simple example to see if we are on the same page-
1. Configure your Yun so you can upload a sketch over the WiFi (You have probably already done this)
2. Connect your Yun to a power supply like the cell phone charger
3. Open the Arduino IDE
4. In the Tools menu, select Board->Arduino Yun
5. In the Tools menu, select Port-> (Your Yun's Name) at 192.168.xxx.xxx (Arduino Yun)
6. Load the sketch under Examples->Basics->Blink
7. In the File menu,  select Upload, watch the sketch compile and upload
8. The red LED should start blinking
9. Shutdown the Arduino IDE
10. Remove the power from the Yun, wait until you are satisfied it is shutdown, count to 5, whatever
11. Connect the Yun to power again, the LED should start blinking again

Does your Yun do this? Isn't this what you are asking for?


Hi, it starts properly on led blinking example boot up with external power.
I have a problem with my sketch, then.
I'll try to see what part of the code is causing the problem and post it back.
This sketch that is giving the problem have some code migrated from other plataform (mbed) and can be something related to the structure.


I have run into strange things that make Arduinos bomb, I have gotten in the habit of putting this as the first thing in setup()
Code: [Select]

and in loop()
Code: [Select]
Yes, I have found ways to make a sketch not even get to setup(). These give me some idea of where the problems are...


I was thinking of starting a new thread, but I think my problem is enough related to not be considered a threadjack :)

My problem is similar to OP in that my sketch run perfectly when uploading, but when starting from power up, it would not run, or rather not run correctly.  After a lot of experimentation I discovered that the problem related to running a process executing the shell command "date".  For some reason, when running the process 'too early' it return the date '20131020' instead of todays date.

If I insert a delay before Bridge startup, it still does not work correctly, but if I insert a delay after the Bridge startup I can get it to work.  I have included my test code snippets below.  Here are some results from many test runs:

Delay  tries
0         577-623
20       41-63
25       15-31
30       1          (which means it got the correct date on first try)

I have no idea where the date '20131020' comes from, but it might be the first day I turned it on?  Any suggestions for how to solve this problem in a cleaner way than a brute force delay?

Code: [Select]
void setup() {
   int startupDelay = 30;
   // delay before bridge startup
   //delay(startupDelay * 1000);

   // Bridge startup
   digitalWrite(13, LOW);
   digitalWrite(13, HIGH);

   // delay after bridge startup
   delay(startupDelay * 1000);



   nextMinute = (minute - minute%5) + 5;
   if(nextMinute > 59) nextMinute -= 60;

   String message = "Greenhouse starting at ";
   message += timeString;
   message += "\ngetTime() tries: ";
   message += tries;
   message += "  after delay: ";
   message += startupDelay;
   message += " sec";
   sendEmail("Start message", message);

And the getTime() function:
Code: [Select]
void getTime() {
   Process time;
   String tempString;
   boolean valid = false;
   tries = 0;
   while(!valid) {
      // get the time from the server:
      time.runShellCommand("date +\"%Y%m%d %T\"");
      tempString = "";
      while(time.available()) {
         char c = time.read();
         if(c != '\n')
            tempString += c;
      dateString = tempString.substring(0, 8);
      if(dateString != "20131020") valid = true;
   timeString = tempString.substring(9);
   minuteString = tempString.substring(12,14);

   minuteString.toCharArray(charBuf, 30);
   minute = atoi(charBuf);


You have two systems involved, it can be hard to get your mind wrapped around it. It takes my linino around 60 seconds to get up and connected to the WiFi. The time gets set some time after that when NTP syncs up with a server.

A good way to understand what is going on is to use the yunserialterminal sketch to watch the Boot up in the serial monitor. Upload the sketch, start the monitor, push the reset by the LEDs and watch the chatter.


Thanks for the reply.
Yes, I understand how the two systems interact, and I can see the problem.  I was really asking if there is a way from the Arduino side to tell when the Linino side is 'ready'.  I guess that is is really the NTP piece which is tripping me up, and I did not understand where the dummy date came from.  So, while it feels a little kludgy I guess my approach of not accepting a date until is does NOT match the dummy date, is OK.


The problem is somewhat defining what 'ready' is. There is one thread http://forum.arduino.cc//index.php?topic=194721.msg1437818#msg1437818 that talks about when you can expect sdcards to be available in Linino, which refers to another which talks about when you can start using the bridge without interrupting the boot process of Linino, now we also want to know when the time is valid!

These are all issues that need to be dealt with, it just isn't easy to do outside of waiting for a set period which will inherently be too long if you ensure everything is 'ready'.


Guys... its really strange problem.
I got it working when removed interactions with linino but after some power cycling looks that the atmel code is not there anymore.
Ill need some more testing to identify the behavior.
For now just mentioning what I see so far.


This thread is old! But still relevant.

I'm using a plain old Leonardo to control a mouse when it gets plugged into the computer via USB. Sketch basically goes like this:

Code: [Select]
#include "Mouse.h"

void setup() {
    Mouse.move(100, 10, 0);

I've found that it only works after uploading the sketch. If i unplug the leo, plug it back in, nothing happens!



Great that you used code tags but s "snippet" of code is about as much use as a chocolate fireguard when trying to help anyone.

Please post the WHOLE sketch.
It may not be the answer you were looking for but its the one I am giving based on either experience, educated guess, google (who would have thunk it ! ) or the fact that you gave nothing to go with in the first place so I used my wonky crystal ball.

Go Up