Go Down

Topic: Yun bootloader question (Read 2773 times) previous topic - next topic

5a2v0

Hi, in my project i need to use all Yun's pins and a relay is connected to digital 13 (and one to 12). The normal state for this pin in my sketch is HIGH but when i perform a reset, the led attached on this pin flashes so my relay goes off and then yet goes on...

is it possible to disable the blinking effects on digital13 on the yun, changing the bootloader ?

sonnyyu

Put it at setup loop?

Code: [Select]
void setup() {
  // initialize digital pin 13 as an output.
  pinMode(13, OUTPUT);
  digitalWrite(13, LOW);
  // digitalWrite(13, HIGH);  // setup default status as HIGH
}


Quote
Pins configured as OUTPUT with pinMode() are said to be in a low-impedance state. This means that they can provide a substantial amount of current to other circuits. Atmega pins can source (provide positive current) or sink (provide negative current) up to 40 mA (milliamps) of current to other devices/circuits. This is enough current to brightly light up an LED (don't forget the series resistor), or run many sensors, for example, but not enough current to run most relays, solenoids, or motors.
https://www.arduino.cc/en/Tutorial/DigitalPins





ShapeShifter

The simplest solution is to rearrange your connections so that D13 does not drive a relay or a critical output that would cause problems if it's driven at the wrong time. If you have an indicator LED on one of the other pins, that is an ideal candidate to swap with your relay.

If you are set on using D13 for a relay, and you can't tolerate the bootloader usage of the LED, you have limited options as there is no configuration option to stop the bootloader from using that pin. Your choices are:
  • Find the bootloader source code, edit it to remove that feature, compile the code, and program it onto your board. (And copy it to the Linux processor if you will be loading code over the network.)
  • Remove the bootloader, and use an ICSP programmer to load code, eliminating the IDE's ability to download code. (The Linux processor can also act as an ICSP programmer.)
  • Find a different bootloader that is compatible with the '32U4 processor, which already doesn't use the LED, and program that onto the board. This may require updating the board definition file in the IDE, and will require copying that bootloader onto the Linux side as well if you are going to download code over the network.

All of these options will require some work, some of them more than others. The simplest option is to just not use D13 as a critical output.

sonnyyu

Great catch! Thanks a lot.




5a2v0

Find the bootloader source code, edit it to remove that feature, compile the code, and program it onto your board. (And copy it to the Linux processor if you will be loading code over the network.)
So this is possible ! --> My question got answer...
Where i can get yun's bootloader?

5a2v0

#5
Aug 19, 2015, 09:29 am Last Edit: Aug 19, 2015, 09:38 am by 5a2v0
Another question:

I found this string in the board.txt file
Code: [Select]
yun.bootloader.file=caterina/Caterina-Yun.hex
then I searched for this file into Yun trought Putty and I found it in: /etc/arduino

So if I edit the bootloader's source file, compile it and replace the file on Yun, if I upload sketches on my yun over WiFi with IDE, my Yun get the new one and I solve the problem right ?
Or this files is used only for upload trought the yun's web interface?

But, where can i found the Yun's bootloader source file?

ShapeShifter

I found this string in the board.txt file
Code: [Select]
yun.bootloader.file=caterina/Caterina-Yun.hex
This is where the IDE will reference the bootloader file (relative to the folder that holds boards.txt.) You will want to update that file, with your new image, or give your new image a different name and update boards.txt to point to it (probably the safer option.)

Quote
then I searched for this file into Yun trought Putty and I found it in: /etc/arduino

So if I edit the bootloader's source file, compile it and replace the file on Yun, if I upload sketches on my yun over WiFi with IDE, my Yun get the new one and I solve the problem right ?
To be correct, you need to upload your sketch over the network (WiFi or wired Ethernet) and it will update the bootloader on the board. So much of the Yun documentation only mentions WiFi: in reality the Yun is a fully functional router with both wired and wireless networking, and all of the communications/programming options work equally well over either interface.

Quote
Or this files is used only for upload trought the yun's web interface?
That file is definitely used for loading code through the IDE over the network, and it should also be used by the web interface. You can also manually put your sketch's hex file on the Yun's disk system and run the programming sequence manually:
Code: [Select]
merge-sketch-with-bootloader.lua path_to_sketch.hex
run-avrdude path_to_sketch.hex

 
Note that /usr/bin/merge-sketch-with-bootloader.lua references /etc/arduino/Caterina-Yun.hex internally. If you give your updated bootloader a new name (which I think is a good idea) then you will have to update this reference as well.

When you upload code through the USB port using the IDE, you are going through the Yun's bootloader. If you upload it over the network (either using the IDE, the web interface, or by manual commands using SSH) you are first combining the sketch with the bootloader into a combined image, and then running avrdude on the Linux processor. avrdude then acts like an ICSP programmer, and will completely reprogram the AVR processor using the combined bootloader and sketch image. So yes, programming over the network will indeed update the bootloader image in the Yun's AVR processor.

Quote
But, where can i found the Yun's bootloader source file?
It looks like the source and makefile are in the bootloader\caterina folder that is below the folder that holds boards.txt.

5a2v0

Is Caterina.c the sourcefile?

Because there is only one Caterina-Yun.* file and is the .hex one

In the Caterina.c there is this code that I think is the section that I must edit:
Code: [Select]
/* Breathing animation on L LED indicates bootloader is running */
uint16_t LLEDPulse;
void LEDPulse(void)
{
LLEDPulse++;
uint8_t p = LLEDPulse >> 8;
if (p > 127)
p = 254-p;
p += p;
if (((uint8_t)LLEDPulse) > p)
L_LED_OFF();
else
L_LED_ON();
}


right ?
Can I on windows edit this file and compile it? How?

Before you write your answer, I found on github this file Caterina-Yun-noblink.hex
and I saved it on Yun in the /etc/arduino/ folder (i did a backup of original file and i rename the new as the old)
and I saved it in the bootloader dir in the ide folder on my pc also...

Then i opened IDE and uploaded mysketch again over WiFi... after upload i switched off and again switched on the board.. the relay connected to pin 13 goes excited once yet!

I would (if possible) that when I switch on the board the pin 13 never gets LOW state !

My first line of void setup() :

Code: [Select]
void setup() {
  pinMode(releBagniPin, OUTPUT); //13
  pinMode(releStanzePin, OUTPUT); //12
  digitalWrite(releBagniPin, HIGH);
  digitalWrite(releStanzePin, HIGH);


So:
1) The compiled file that i found, doesn't flash the led but put the led off (LOW STATE) ?
2) Or is there other explanation for my case ?

ShapeShifter

#8
Aug 19, 2015, 06:59 pm Last Edit: Aug 19, 2015, 07:01 pm by ShapeShifter
You're on your own on how to build it, I've never tried it.

I would still look for the simple solution: move the relay to a different pin, and put something there that is an input or is not a critical output. If using it as an input, it's worth putting a current limiting resistor in line since it will likely be driven as an output

Next would be to invert the output so that LOW is the idle state, and goes HIGH to trigger the output. An inverter gate or a simple transistor inverter would do the trick.

Also, while the processor is starting up, before things get initialized, the input is floating. Make sure there is an external pullup or pulldown if your relay driver triggers on a floating input.

What is your circuit? Is there nothing that can be swapped with D13?

Very often one sees a problem, and focuses on one particular solution: in this case, prevent the bootloader from setting that pin. Often times, a simpler solution is presented when one looks at the real problem: the real problem isn't that the bootloader is using that pin, it's that you need the relay to not trigger when restarting or loading code - focus on that issue, and consider other ways of preventing that from happening.

Go Up