Hi guys,
I'm making a FM Radio using (SparkFun FM Tuner Evaluation Board - Si4703 - WRL-12938 - SparkFun Electronics) Si4703 Evaluation Board and controlling it with Arduino UNO, I uploaded the Code and it was running smoothly, But when i disconnect and re-connect the power lines, I cannot tune it to any station. I've to manually press the reset button on UNO to make it work again.
I want to know : Is there any way to reset the Arduino Automatically when it's powered or give meany other alternative to overcome this problem.
Thanks
mudassir9999:
Hi guys,
I'm making a FM Radio using (https://www.sparkfun.com/products/12938) Si4703 Evaluation Board and controlling it with Arduino UNO, I uploaded the Code and it was running smoothly, But when i disconnect and re-connect the power lines, I cannot tune it to any station. I've to manually press the reset button on UNO to make it work again.
I want to know : Is there any way to reset the Arduino Automatically when it's powered or give meany other alternative to overcome this problem.
Thanks
Do you mean when you disconnect/reconnect the power to the evaluation board only, or to the Arduino AND that board?
Showing us your schematic and code might be helpful.
If you have made 66 posts so far, you should know that your question is useless without specifying the Web links to each of the components you are using apart from the Arduino, as well as the complete code - not as an attachment, but in "code" tags, and a circuit diagram or perfectly focussed photo (in full daylight) of you project; preferably both. 
Thank you very much for the reply sir,
I'm powering the Evaluation board by using the 3.3V and GND pins from Arduino and powering the Arduino from USB, Now when i disconnect and reconnect the USB Cable from my computer, I cannot able to tunein any stations, I've to press the Reset button on Arduino UNO to start tuning.
Here is the code.
#include <SparkFunSi4703.h>
#include <Wire.h>
int resetPin = 2;
int SDIO = A4;
int SCLK = A5;
Si4703_Breakout radio(resetPin, SDIO, SCLK);
int channel;
int volume;
char rdsBuffer[10];
void setup()
{
Serial.begin(9600);
Serial.println("\n\nSi4703_Breakout Test Sketch");
Serial.println("===========================");
Serial.println("a b Favourite stations");
Serial.println("+ - Volume (max 15)");
Serial.println("u d Seek up / down");
Serial.println("r Listen for RDS Data (15 sec timeout)");
Serial.println("Send me a command letter.");
radio.powerOn();
radio.setVolume(0);
}
void loop()
{
if (Serial.available())
{
char ch = Serial.read();
if (ch == 'u')
{
channel = radio.seekUp();
displayInfo();
}
else if (ch == 'd')
{
channel = radio.seekDown();
displayInfo();
}
else if (ch == '+')
{
volume ++;
if (volume == 16) volume = 15;
radio.setVolume(volume);
displayInfo();
}
else if (ch == '-')
{
volume --;
if (volume < 0) volume = 0;
radio.setVolume(volume);
displayInfo();
}
else if (ch == 'a')
{
channel = 930; // Rock FM
radio.setChannel(channel);
displayInfo();
}
else if (ch == 'b')
{
channel = 974; // BBC R4
radio.setChannel(channel);
displayInfo();
}
else if (ch == 'r')
{
Serial.println("RDS listening");
radio.readRDS(rdsBuffer, 15000);
Serial.print("RDS heard:");
Serial.println(rdsBuffer);
}
}
}
void displayInfo()
{
Serial.print("Channel:"); Serial.print(channel);
Serial.print(" Volume:"); Serial.println(volume);
}
Perhaps you could try a delay in setup() before calling 'radio.powerOn()'. Maybe the radio board isn't ready to receive commands that soon after powerup.
Same Problem 
I added delay in setup()
void setup()
{
Serial.begin(9600);
Serial.println("\n\nSi4703_Breakout Test Sketch");
Serial.println("===========================");
Serial.println("a b Favourite stations");
Serial.println("+ - Volume (max 15)");
Serial.println("u d Seek up / down");
Serial.println("r Listen for RDS Data (15 sec timeout)");
Serial.println("Send me a command letter.");
delay(500);
radio.powerOn();
radio.setVolume(0);
}
Oh well, it was worth a try.
But did you try even longer delays, or just 500mS?
If I was you, I'd experiment a bit with delay lengths, up to a couple of seconds. Resetting the Arduino will still only execute the code in 'setup()', but at a later time.
Yes I tried different delay lengths, 500mS,1000mS,1500mS.....5000mS, But nothing works. I odserved one thing while experimenting with the delay lengths, If i exceed more than 1000mS a this stage even pressing Reset button doesn't works.
mudassir9999:
Yes I tried different delay lengths, 500mS,1000mS,1500mS.....5000mS, But nothing works. I odserved one thing while experimenting with the delay lengths, If i exceed more than 1000mS a this stage even pressing Reset button doesn't works.
As I said, it was worth a try. Sometimes the easiest option is the best one.
You might be stuck with pressing the [Reset] button, unless someone else has any ideas.
I think it's time you showed us your schematic diagram.
But when i disconnect and re-connect the power lines, I cannot tune it to any station.
Think about what you are doing: UNO powered from PC's 5.0Volt USB and the 3.3Volt tuner powered separately. In general, uC and I/O boards should powered from the same power system. In this manner, power-On provides a Power-On-Reset, POR, to all connecteddevices ... like having a shield plugged into the UNO.
Additionally, you must surely know that Sparkfun has a support forum! You do not have an Arduino issue BUT you are NOT following Sparkfun's suggested hookup: Do It The Suggested Way and use an 8MHz 3.3V mini.
Ray
As mrburnette says, you can't use your present setup. You could use the UNO, but only if you take the necessary precautions.
According to the Sparkfun page, the board is 5V-tolerant in general, but the I2C communication lines are not. So you need to ensure that these lines never exceed 3.3V. A level-shifter is one way, (two-way for the I2C data line).
When communicating with 3.3V I2C boards directly from my UNO, without extra level-shifting, I disable the internal pullups in "twi.c", then use external 3.3V pullups for the clock and data lines. That's one option, and in fact, the radio board might already have it's own 3.3V pullups on those lines. (You need to check before adding external ones.)
If the Sparkfun page is correct, the board should handle 5V on it's "Reset" line, but I'd personally do a level-shift on that pin, possibly using a voltage-divider. (You might need to check the value of it's on-board pullup/pulldown resistor, assuming it has one, and choose your voltage-divider resistor values accordingly.)
All-in-all, a lot of messing around compared with using a 3.3V Arduino directly connected without extra trickery.
OldSteve:
When communicating with 3.3V I2C boards directly from my UNO, without extra level-shifting, I disable the internal pullups in "twi.c", then use external 3.3V pullups for the clock and data lines.
As I only just mused in this post, it seems to me that given that the software is properly written such as to only enable the internal pull-ups and never writes an output HIGH, it would be sufficient to clamp the lines to the 3.3 V rail.
Four-way level shifters are dirt cheap on eBay; SDA, SCL, reset and one spare.
UNO powered from PC's 5.0Volt USB and the 3.3Volt tuner powered separately
mrburnette I'm powering the Evaluation Board with the powerlines coming from Arduino only, Both the Arduino and evaluation board are on same power lines.Using the exactly same hookups in my setup shown in the hookup guide by SPARKFUN.
but the I2C communication lines are not. So you need to ensure that these lines never exceed 3.3V. A level-shifter is one way, (two-way for the I2C data line).
OldSteve, Yes, I'm sure and checked with my multimeter twice, the +powerline to the board is 3.3V only which is provided by the Arduino UNO only.
That's one option, and in fact, the radio board might already have it's own 3.3V pullups on those lines. (You need to check before adding external ones.)
Yes! the board itself has pull-up resistors onto it, the values are 4.7K for clockline and 4.7K dataline.I'm attaching the schematics of that board. Please see
SparkFun_FM_Tuner_Basic_Breakout.pdf (44.1 KB)
Paul__B:
it seems to me that given that the software is properly written such as to only enable the internal pull-ups and never writes an output HIGH, it would be sufficient to clamp the lines to the 3.3 V rail.
You're right Paul. The UNO internal pullups connect to 5V, but they're very weak pullups, and would be overpowered to a fair degree by 3.3 pullups as long as they were reasonably low resistance.
The OP has since shown that the radio board has it's own 3.3V pullups, 4K7, so it wouldn't be absolutely necessary to disable the UNO pullups. I still do it as a matter of course though. Better practice, and takes but a moment to comment out the two lines in "twi.c". I originally did it for an MPU6050 module, but then decided to leave those lines commented out and only enable them when I really need to, since so many add-ons have their own pullups anyway.
These are the relevant lines in "twi.c". (Lines 77 and 78):-
// Activate internal pullups for twi:-
// digitalWrite(SDA, 1); // *** Disabled temporarily ***
// digitalWrite(SCL, 1); // *** Disabled temporarily ***
mudassir9999:
OldSteve, Yes, I'm sure and checked with my multimeter twice, the +powerline to the board is 3.3V only which is provided by the Arduino UNO only.
I realise that, but that's only the power - the I2C lines on the UNO have internal 5V pullups, not 3.3V, though that shouldn't matter too much when the onboard 4K7 pullups are taken into account. The chip recommends up to 3.6V on it's IO lines, absolute max 3.9V. (See my last post and Paul's.) Disabling the UNO internal pullups is just an extra precaution that I take as a matter of course when interfacing with 3.3V logic. It costs nothing, and keeps the I2C voltage closer within spec if an add-on has high-resistance 3.3V pullups. The 4K7 pullups on the radio board aren't too bad in this regard.
The documentation for the radio board says that the other inputs are 5V tolerant, but the radio chip datasheet says that the maximum voltage on the reset pin should be Vio + 0.3V, (3.6V). Take your pick. The radio board only has a 330 ohm series resistor and 10K pulldown resistor on the reset pin, so I'd personally take precautions to make sure that the voltage on that pin can't exceed 3.6V. It's up to you though.
This problem also happened to me. The power-on-reset is not stable. It may have nothing to do with your sketch, I can see my problem from the D13 LED's behave.
When I press the reset button, the Opti bootloader makes the D13 LED blink a few times and it happens all the time, but if I turn on the power, sometime the LED blinks, sometime it doesn't. That indicates a hidden problem.
The problem might be a circuit design oversight. During power-up, usually the reset pin has a capacitor to hold it low until the VCC reaches a stable working voltage. After uploading a sketch Arduino IDE uses the DTR through a 0.1uf cap to automatically reset the 328P which is a great idea, but it omitted the power-on-reset. It should keep the cap on the reset pin. The problem is that if the reset pin has a 0.1uf capacitor, the DTR reset doesn't work, because it's a weak pull down and cannot fully discharge the cap on the reset pin.
The solution is that you need to buffer the DTR reset by adding a HC1G07. The open collector output of the HC1G07 will be able to fully discharge the 0.1uf cap. I guess that you may not have a HC07 type open collector buffer at hand, but any buffer is OK to use, so you can use a HC125 or a HC14 (need 2 buffers in series to make a non-inverting buffer) in series with a Schottky diode, like a BAT-54. See the attached schematic. The forward voltage of the diode will only be about 0.3V, because the forward current is small. May be the 1N4148 will work too. I hope that future UNO type boards will have an HC1G07 on it, so besides the auto mode, the board will also work 100% in standalone mode. Without it, the 328P may start from an unknown location, somehow execute all unknown instructions, illegal op traps and may finally reaches the user's code by luck. In your case, it did not reach your code. It could be dangerous for a commercial product when a temporary power outage may happen.
A simpler way is to add a 3-position header in your circuit, then use a jumper to select auto reset or power-on-reset. you can verify it by inserting a 0.1uf cap between the reset and ground pins on the power header.
You have to press the reset button to run every time after uploading a sketch, but the power-on-reset will work all the time. You will sacrifice the auto reset, may be that's less important to you.
BTW, I made a drop-in replacement for the 328P to upgrade UNO boards, called UU, it stands for Uno Upgrade. See www.firebirduino.com
When your sketch size exceeds the memory limit, this is the easiest solution. Since this is a result of long community efforts and many people's contribution in software, I will give away the ownership and donate it to Arduino or anyone who can fork the Arduino IDE to include it. When so many UNO boards are in use, the potential market is big if Arduino makes it. With Arduino's volume, the cost will be substantialy lower, so more people can afford it and more people can stay with the community longer. If an AVR controller can do what an ARM controller can, the life is a lot easier, why leave?
Wayne
Edit: Sorry forgot to add the 0.1 cap on the reset pin. Attached is the new schematic
power_on_reset_problem.pdf (68.7 KB)
power_on_reset_problem_new.pdf (71.3 KB)
1 Like
firebirduino:
@mudassir9999This problem also happened to me. The power-on-reset is not stable. It may have nothing to do with your sketch, I can see my problem from the D13 LED's behave.
When I press the reset button, the Opti bootloader makes the D13 LED blink a few times and it happens all the time, but if I turn on the power, sometime the LED blinks, sometime it doesn't. That indicates a hidden problem.
The problem might be a circuit design oversight. During power-up, usually the reset pin has a capacitor to hold it low until the VCC reaches a stable working voltage. After uploading a sketch Arduino IDE uses the DTR through a 0.1uf cap to automatically reset the 328P which is a great idea, but it omitted the power-on-reset. It should keep the cap on the reset pin. The problem is that if the reset pin has a 0.1uf capacitor, the DTR reset doesn't work, because it's a weak pull down and cannot fully discharge the cap on the reset pin.
The solution is that you need to buffer the DTR reset by adding a HC1G07. The open collector output of the HC1G07 will be able to fully discharge the 0.1uf cap. I guess that you may not have a HC07 type open collector buffer at hand, but any buffer is OK to use, so you can use a HC125 or a HC14 (need 2 buffers in series to make a non-inverting buffer) in series with a Schottky diode, like a BAT-54. See the attached schematic. The forward voltage of the diode will only be about 0.3V, because the forward current is small. May be the 1N4148 will work too. I hope that future UNO type boards will have an HC1G07 on it, so besides the auto mode, the board will also work 100% in standalone mode. Without it, the 328P may start from an unknown location, somehow execute all unknown instructions, illegal op traps and may finally reaches the user's code by luck. In your case, it did not reach your code. It could be dangerous for a commercial product when a temporary power outage may happen.
A simpler way is to add a 3-position header in your circuit, then use a jumper to select auto reset or power-on-reset. you can verify it by inserting a 0.1uf cap between the reset and ground pins on the power header.
You have to press the reset button to run every time after uploading a sketch, but the power-on-reset will work all the time. You will sacrifice the auto reset, may be that's less important to you.BTW, I made a drop-in replacement for the 328P to upgrade UNO boards, called UU, it stands for Uno Upgrade. See www.firebirduino.com
When your sketch size exceeds the memory limit, this is the easiest solution. Since this is a result of long community efforts and many people's contribution in software, I will give away the ownership and donate it to Arduino or anyone who can fork the Arduino IDE to include it. When so many UNO boards are in use, the potential market is big if Arduino makes it. With Arduino's volume, the cost will be substantialy lower, so more people can afford it and more people can stay with the community longer. If an AVR controller can do what an ARM controller can, the life is a lot easier, why leave?Wayne
Edit: Sorry forgot to add the 0.1 cap on the reset pin. Attached is the new schematic
I think you're on the wrong track, Wayne. (Perhaps mudassir9999 can clarify.)
As I understand it, the problem is with the radio board, not the UNO's reset. I think the UNO itself is resetting OK, but the radio board isn't. (I might be wrong though. Wouldn't be the first time. 
)
mudassir9999, does your UNO usually reset cleanly on power-up, when running other sketches?
UNO boards usually reset cleanly on power-up, without modifications.
firebirduino:
The problem might be a circuit design oversight. During power-up, usually the reset pin has a capacitor to hold it low until the VCC reaches a stable working voltage.
Not on the ATmega series.
A Power-on Reset (POR) pulse is generated by an On-chip detection circuit. The detection level is defined in ”System and Reset Characteristics” on page 305. The POR is activated whenever V CC is below the detection level. The POR circuit can be used to trigger the start-up Reset, as well as to detect a failure in supply voltage.
A Power-on Reset (POR) circuit ensures that the device is reset from Power-on. Reaching the Power-on Reset threshold voltage invokes the delay counter, which determines how long the device is kept in RESET after V CC rise. The RESET signal is activated again, without any delay, when V CC decreases below the detection level.
The MCU is held in reset until Vcc reaches the minimum working voltage so that the chip is stable. In fact, the oscillator may not start until a higher voltage is reached, but since there is no minimum clock speed requirement, this does not matter.
Thus there is no need nor point to providing a capacitor to ground on the Reset line and in fact, such a capacitor does foul up the auto-reset arrangement, thus a common blunder in various "instructables" and such.
Paul__B:
Not on the ATmega series
.......
Thus there is no need nor point to providing a capacitor to ground on the Reset line and in fact, such a capacitor does foul up the auto-reset arrangement, thus a common blunder in various "instructables" and such.
Hi Paul
I was working on a design today and included that capacitor to ground. I found it in Atmel's AVR042 app note (link to Atmel doc) (figure 2-1 on page 6 shows their reference reset circuit with the capacitor). From page 5 :
To protect the RESET line further from noise, it is an advantage to connect a capacitor from the RESET pin to ground. This is not directly required since the AVR internally have a low-pass filter to eliminate spikes and noise that could cause reset. Applying an extra capacitor is thus an additional protection. However, note that this capacitor cannot be present if DebugWIRE or PDI is used.
The most recent update on that is October 2015 but there's no exclusion I can see for Atmega. FWIW looks like that advice is direct from the horse.
Will the inclusion of that additoinal protection prevent ICSP in your view? I was hoping to include the 6-pin ICSP header is all so your comment has shaken me.
Thanks,
Geoff