-
Atmel Studio compiler errors
Posted by
Simon
on 29 Aug, 2014 09:03
-
What does this warning mean ?
Warning 2 control reaches end of non-void function [-Wreturn-type]
It relates to this code:
TIMER0_COMPA_vect()
{
count++;
}
The count variable has been declared as a volatile variable.
I am also getting other complaints around the watchdog timer reset code but I can't work out why as I'm just using the wdt_reset ( ); that is specified in the manual but errors have been asking me for "(" in front of parts of code in the library file that is none of my business. This was after commenting some of the code out and then trying to put it back. Basically the compiler is unstable at best.
-
#1 Reply
Posted by
andersm
on 29 Aug, 2014 09:46
-
The warning means that there is a function that is declared to return a value (eg. int foo(...)), but there is an execution path that reaches the end of the function without returning a value. I doubt it is related to the code you showed.
I don't mean this as an insult, but you have a history of making lots of beginner's errors. Before blaming the compiler, make sure you have all your i's dotted and t's crossed.
-
#2 Reply
Posted by
Simon
on 29 Aug, 2014 10:03
-
According to responses i got on avr freaks i should have used ISR(TIMER0_COMPA_vect) So that one is sorted.
The code previously worked, I commented some of it out and then removed the comments and now I get errors relating to code in the watchdog header file which is out of my control, I think that's unusual is it not ? I also experience instances where first the code refuses to compile and on a second attempt it does, I think that constitutes unstable.
-
#3 Reply
Posted by
Simon
on 29 Aug, 2014 10:39
-
Using my original code works again, but still it took two attempts to compile and things that compiled correctly on one computer don't compile on another despite having the same versions. it also seems to make a difference as to where my cursor is when i hit build which i don't understand.
-
#4 Reply
Posted by
T3sl4co1l
on 29 Aug, 2014 13:58
-
To guarantee consistent builds, you should probably wipe output data every once in a while. C compilers are not inconsistent (they're deterministic programs), but they are stateful, in that if you have compiled modules that weren't changed (or so it seems), it will include them without recompiling. Which can lead to inconsistent results, perhaps if some header files changed or something.
Tim
-
#5 Reply
Posted by
Simon
on 29 Aug, 2014 14:23
-
ah that is interesting, and how do i clear "output data" ?
-
#6 Reply
Posted by
T3sl4co1l
on 29 Aug, 2014 14:45
-
Project / Clean Project, or something like that. I forget where Atmel/AVR Studio has that at. Or you go into the output directory and delete it yourself.
-
#7 Reply
Posted by
Simon
on 29 Aug, 2014 17:16
-
hm, pretty roundabout when your making minor code changes and want to keep verifying them.
-
#8 Reply
Posted by
sporadic
on 29 Aug, 2014 17:55
-
In regards to error references within a system header file, that's usually caused by a macro expansion gone bad or malformed code block in the users code. The cleaning referred to above will cleanup all the intermediate compiled objects and what not required to create your final binary. Very much like a "make clean". An object won't re-compile unless it needs to (source changed or compiled object removed), so if you see a warning the first time around in say "mystuff.c", make a change in "main.c", and recompile, you won't see the warning from mystuff.c again until you do a "make clean", or in Atmel Studio's case, "Build->Clean Solution". Have a link for the thread you have going on avrfreaks?
-
#9 Reply
Posted by
Simon
on 29 Aug, 2014 18:31
-
So basically i need to do a clean build each time to make sure ?
-
#10 Reply
Posted by
sporadic
on 29 Aug, 2014 19:24
-
So basically i need to do a clean build each time to make sure ?
If you're wanting to re-compile all files each time and see the warnings for them again, yes. Atmel Studio's default build configuration turns on many of GCC's warning flags so it can be pretty verbose at times. Many warnings are just that and won't cause runtime issues, but its best to deal with them if you can. So generally, you don't need to do a clean build unless you want to go back and check your warnings for all modules or you've been prodding around doing something that messed up the make system / causing the linker to fail. I rarely have to do a clean, but its good for a sanity check every now and then.
-
#11 Reply
Posted by
Simon
on 30 Aug, 2014 07:52
-
Yea apparently now I have variables that are not being modified when they clearly are..........
-
#12 Reply
Posted by
andersm
on 30 Aug, 2014 09:00
-
Yea apparently now I have variables that are not being modified when they clearly are..........
Please post an example.
-
#13 Reply
Posted by
David_AVD
on 30 Aug, 2014 09:01
-
Without seeing the whole project it's hard to tell, but maybe the variables are not correctly defined? I've had no issues with variables marked as volatile.
Maybe check for other silly mistakes such as calling a function without the parenthesis. Things like this can really screw things up without generating errors.
So far, each time I've seen something weird going on it's been a typo or me not completely understanding C.
-
#14 Reply
Posted by
Simon
on 30 Aug, 2014 09:56
-
Well I'll continue probing monday and be able to post some code
-
#15 Reply
Posted by
mikerj
on 31 Aug, 2014 17:49
-
Just bear in mind that weird compilation errors are 99.999% caused by user code. Missing brackets etc. can cause errors to be shown in apparently unrelated code, but with experience you get a feeling for where the real problem is likely to be.
-
#16 Reply
Posted by
Simon
on 31 Aug, 2014 17:53
-
It's just weird that first it fails and then it succeeds with no code change, I need to look at the second computer i am using as most problems occur moving to that.
As pointed out previously a clean built is the best option to clear any old bits of code the compiler is hanging onto that I may have changed anyway.
I have
watchgod reset code
while(1)
watchdog reset code
and I'm getting error in the watchdog header file........
Reverting to a previous copy of the program fixes it all.
-
#17 Reply
Posted by
c4757p
on 31 Aug, 2014 18:02
-
watchgod reset code
while(1)
watchdog reset code
It'd be seriously helpful if your pseudocode was, well, pseudo-
code. With structures and all that. Is the third line inside the while(1), or have you tried to make the processor halt at the while(1)? That could make a difference.
and I'm getting error in the watchdog header file........
Remember that the compiler lumps all the headers together at the beginning of your file. Errors in a header that ought to be okay are often actually latent errors from things before the header's #include line. What did you do
before #include <avr/wdt.h> ?
Reverting to a previous copy of the program fixes it all.
Usually a sign that you changed something and broke it, not a sign that the compiler's "unstable".
Would you be so kind as to share a minimal diff?
-
#18 Reply
Posted by
Simon
on 31 Aug, 2014 18:05
-
Sorry to be cleare it was and i forgot a parenthesis:
main()
{
watchgod reset code
while(1)
{
watchdog reset code
rest of code in loop
}
}
[code/]
The 3 errors I got pointed to before and after the while in my code but stated that there needed to be "(" in some code, the code it referred to is in the watchdog header file.
-
#19 Reply
Posted by
miguelvp
on 31 Aug, 2014 18:16
-
It actually will be helpful to put the actual code snippets if you are getting compiler errors.
-
#20 Reply
Posted by
Simon
on 31 Aug, 2014 18:20
-
I'll post some tomorrow
-
#21 Reply
Posted by
Simon
on 31 Aug, 2014 18:22
-
I'll do that tomorrow although I've gone back to my original and in any case identical copy and got no errors, hence my comments about instability, these may be down to not doing a clean build.
-
#22 Reply
Posted by
true
on 31 Aug, 2014 19:16
-
No, it very likely isn't.
I'll wait for code.
-
#23 Reply
Posted by
Simon
on 31 Aug, 2014 19:18
-
Well then as far as i can tell i have 2 pieces of code that say the same thing but only one works.
-
#24 Reply
Posted by
David_AVD
on 31 Aug, 2014 21:55
-
My money is on them not being the same. About the only other thing I can think of is the file has gotten mangled with bad CR/LF ?