If I put ANY Serial.print statements in the Setup() part of the sketch and the Loop() part of the sketch calls AnalogRead() the sketch only seems to execute the print part of the Setup() and never gets to the Loop() part. This is in version 0023 of the IDE. I haven't tried this with the latest version. I can't understand how adding an AnalogRead() to the Loop() function causes the Setup() portion to malfunction, however the sketch DOES reset right after the Serial.print() statement in the Setup(). Remove the AnalogRead() from Loop() and the Setup() functions correctly.
Read this before posting a programming question
Post your code please.
I'm working on a project designed around an Arduino, which is to say it's using an atmega328 processor, Arduino bootloader, and software written using the Arduino IDE (version 0023). When prototyped on an Arduion UNO, or Duemilanove the code worked. When I moved it to a board based on the Dumilanove (same processor, same USB serial chip) but running at 3.3 volts and 8 mhz I started having problems with the ADC. I did define a new 'board' based on an Arduio PRO at 3.3v / 8mhz so all timing should work (indeed the baud rate is correct). See a portion of my code that shows the issue:
const int VERTICAL = A0; // Analog input pin that the potentiometer is attached to
const int HORIZONTAL = A1; //ditto
int vertical = 0;
int horizontal = 0;
void setup() {
// initialize serial communications at 9600 bps:
Serial.begin(9600);
Serial.println("");
Serial.println("setup");
delay(400);
analogReference(DEFAULT); //NOTHING connected to aref except a cap to ground!
}
void loop() {
Serial.println("");
Serial.println("loop");
///read the analog in value:
vertical = analogRead(VERTICAL);
horizontal = analogRead(HORIZONTAL);
Serial.print("Vertical "); Serial.print(vertical);
Serial.print(" Horizontal "); Serial.println(horizontal);
delay(400);
}
On the 5v/16mhz Arduino this works as expected "setup" prints once, "loop and the vertical and horizontal values print once every 400ms (reading a joystick). However on the board running at 3.3v/8mhz it ONLY prints "setup" over and over again. IF I comment out the two analogRead() lines, all print lines happen as on the 5v board (but the readings stay at zero). If I comment out the print lines in the Setup portion and the print "loop" lines at the top of the loop() portion BUT leave the analogRead() lines and the following print lines the sketch seems to run correctly, IE: it reads the joystick and reports the values, .... which seem to look correct. I'm at a total loss as to what is going on here. There is an interaction between the print statements and the ADC read statements for sure. It LOOKS like the processor is resetting, but not in external HW (at least I don't see the reset line moving on a scope). The SAME code (but compiled for different F_CPU values) runs fine on a 5v/16mhz atmega328, but not on a 3.3v/8mhz one.
Starting with the code you posted above comment-out the analogReference and test.
scharkalvin:
The SAME code (but compiled for different F_CPU values) runs fine on a 5v/16mhz atmega328, but not on a 3.3v/8mhz one.
In that case it sounds electrical to me. This is a custom design you say? Do you have decoupling capacitors? Is VCC what you expect it to be? How about AVCC?
It does indeed seem to be a H/W problem. AVCC is powered from the same 3.3v supply as the processor VCC via a decoupling choke and bypass capacitor (as per Atmel documents). (BTW the Arduino schematics omit the choke.) We rewired the board to operate the processor at 5v and wired the joystick to 5v so the circuit would operate as before. We kept the 8mhz crystal. Now the same code works correctly as it did on the Arduino UNO and Duemilanove (compiled for the correct F_CPU of course). This seems to imply that the Atmel atmega328 processor has a big problem with the ADC running at 3.3v. Anybody with an Arduino PRO running at 3.3v seeing this????? Note that the two Arduino boards had the processor in the 28pin dip package, our boards us the 32 pin QTFP package, if that makes a difference. (The PRO mini also uses the 32 pin QTFP).
scharkalvin:
It does indeed seem to be a H/W problem. AVCC is powered from the same 3.3v supply as the processor VCC via a decoupling choke and bypass capacitor (as per Atmel documents). (BTW the Arduino schematics omit the choke.)
What document says a choke is needed?
scharkalvin:
This seems to imply that the Atmel atmega328 processor has a big problem with the ADC running at 3.3v.
If that were the case, I'm sure there would have been somebody else that noticed an issue as well.
What's the schematic look like for your setup? You are looking in the wrong place for the problem.
(BTW the Arduino schematics omit the choke.)
That's cus they're lazy (and chokes are often rather bulky).
IIRC I did see a choke on a schematic from Atmel. It may have been on one of their 'explained' boards.
As for my board, the only possibility I can think of is in the power supply. During testing the unit was powered by a heavy 6v lantern battery and there is a low drop out 3.3v regulator on the board. The regulator has an 'enable' input which is controlled by an RS flip-flop and a push button switch to provide an on/off function. If the processor draws more power when BOTH the Usart AND the ADC are running and if that is enough to trip the regulator output below 2.7 volts (assuming the battery was weak, which I need to test, initially it appeared not to be), then maybe I was seeing a brown out condition. (USB/Serial FT232 chip is powered from PC USB connection). If the Arduino PRO bootstrap or the Arduino main() code does not clear the cpu status register I can add code to my sketch to test for a brownout condition to verify this theory. I also intend to try powering the 3.3v regulator from a mains 9v supply and see if the problem goes away. I do agree that this processor should work correctly at 3.3 volts.
Problem solved. It was a hardware problem with our board. Let me give the findings as advice to anybody building their own device using an atmega processor with the ADC in use. My problem turned out to be caused by a Brownout reset. We finally found a 400mv spike on the AVCC pin (but NOT on the VCC line anywhere else). The AVCC pin was fed from the VCC line via a 400uh choke and bypassed by a .1 uf capacitor. The VCC line was bypassed by a 22uf electrolytic capacitor. We added a 22uf low ESR capacitor across the .1 uf on AVCC and replaced the 22uf capacitor on the VCC line with one having a lower ESR. This removed the 400mv spike on the AVCC pin. It seems one must be careful how the AVCC line is bypassed! I'm glad this problem turned out to have a simple solution, it took awhile to realize that it was a brownout reset (I was able to catch that in SW by adding code to read the MCUSR register). Seeing the glitch required a digital scope with the trigger set correctly, and on the AVCC pin as it wasn't seen on the VCC pins. It seems the processor will detect such a glitch on ANY of the VCC inputs to cause a brownout.
Thank you for the follow-up.