Greetings,
I made myself a universal display board with a Atmega32A, to use in various projects. One of them is a Geiger counter, where I want to use a timer interrupt combined with a external interrupt to measure cps, counts per second. The problem is, it sometimes works with a crystal and it sometimes doesn't.
The fuses are set correctly. I checked multiple times. I used
http://www.engbedded.com/fusecalc/ and
http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega32. I do like the latter more.
Today I thought I start from the beginning, making a led blink. Which to my surprise worked, with the external crystal. Then I flashed the Geiger firmware, and that also worked. Then I put the board into the Geiger counter and it stopped working. The first row of the 1602A display just showes black segments, instead of CPS and CPM. Then I took the Mega32 from inside the counter and put it into an identical display board and it worked just fine.
I have no real idea what the issue could be. Maybe a bad solder joint at the crystal, as I read an a thread I found ? I use a 16Mhz crystal with 22pF caps. I also discovered that when shorting one cap, a cursor appears on the display. Does that mean 22pF is too much ?
The Mega32 come from Aliexpress and Reichelt. There is no difference.
Best regards
rbastler
Interesting.
I often have a problem with fuses but I never had a problem like that one.
Can we look at a photo of your pcb?
What are the actual fuse values have you used?
I tried all the options the calculators gave me for the external crystal with high frequency and startup time 1 CK + xx ms and startup time 258CK + 64ms.
Do you have the datasheet for the crystal, does it advise 22pf load caps?
Just to add:
This may or may not be related, but I have a board (stm32f103V6 from Aliexpress) which steadfastly refuses to work with external crystals.
I have changed the crystal for a known working one, and then tested it and still no oscillation.
I placed the crystal back into another unit, and it oscillated.
I tested the tracks for continuity, but it all appears to be fine.
The firmware was correctly configured (it worked on other boards), but to this day, I still have no clue why this one won't work.
Do you have the datasheet for the crystal, does it advise 22pf load caps?
Yup,22pf is correct
I think it could be a coding error like unwanted loop or missing ';' or bracket.Those,don't show up as error sometimes.
could you reflash fuse and use internal clock for first test?
could you back up your code,make no change to circuit and try driving the lcd with rest of the code removed (just flash the lcd code alone.)?
Can you buy a new batch of crystal?
also,see if the voltage is 5 volts,it cannot run that fast,below that.
Hey wait a second.The lcd you said you are using is parallel interface.It won't malfunction and display garbage blocks if the clock is bad and is ticking slow or fast. If the clock is not ticking at all,it'll display nothing.Something else is bad I'm afraid.
The difference may be the fact you are running faster (probably 2x), not the fact you are using a crystal. I have not used lcd displays in a long time, but they certainly have timing requirements that must be met- 8MHz - ok (simply by being slower, it meets the requirements), 16MHz - now you are out of timing requirements of the lcd and will get unexpected results. Assuming the lcd code does not take into account the clock speed.
Possibly.
The difference may be the fact you are running faster (probably 2x), not the fact you are using a crystal. I have not used lcd displays in a long time, but they certainly have timing requirements that must be met- 8MHz - ok (simply by being slower, it meets the requirements), 16MHz - now you are out of timing requirements of the lcd and will get unexpected results. Assuming the lcd code does not take into account the clock speed.
Possibly.
Now I don't know why it worked with the internal oscillator, but the lcd.c file was missing the #define F_CPU part. I thought it would be enough to have it in the main.c guess it wasn't. Now it works with the crystal inside the Geiger counter.
Thanks all for the help!
Here's a picture of the Geiger:
Now I don't know why it worked with the internal oscillator, but the lcd.c file was missing the #define F_CPU part. I thought it would be enough to have it in the main.c guess it wasn't
Your lcd code most likely calculates things like the enable time, and adds nop's accordingly to meet the timing requirements. If the F_CPU define was required in lcd.c, you would get a compiler error if it was not provided, unless it used a default value if none provided (if not defined, define as a default value). The other possibility is your project has F_CPU set somewhere and is simply being passed to each c file as a compiler -D option, and it may still be using your old value, which you are now overriding with a specific define (correct value). You may want to check if F_CPU is set somewhere in your project (makefile, ide settings, or whatever)- and use that instead (then only need to set in one place).
Also keep in mind, each c file is compiled as a separate 'unit'- each c file needs to have all the info it needs to compile (from headers, etc.), and will not use any info from other c files. So, lcd.c does not know anything about main.c, or any other c file you have- if it needs a define, you have to provide it in the lcd.c file, or include a header which has it (or provided with a compiler -D option), if it needs access to a function in another c file, it needs to know about it (an include header, or just specifying the function prototype/declaration). Whatever it takes for each c file to have all the info it needs to compile.
Now I don't know why it worked with the internal oscillator, but the lcd.c file was missing the #define F_CPU part. I thought it would be enough to have it in the main.c guess it wasn't
Your lcd code most likely calculates things like the enable time, and adds nop's accordingly to meet the timing requirements. If the F_CPU define was required in lcd.c, you would get a compiler error if it was not provided, unless it used a default value if none provided (if not defined, define as a default value). The other possibility is your project has F_CPU set somewhere and is simply being passed to each c file as a compiler -D option, and it may still be using your old value, which you are now overriding with a specific define (correct value). You may want to check if F_CPU is set somewhere in your project (makefile, ide settings, or whatever)- and use that instead (then only need to set in one place).
Also keep in mind, each c file is compiled as a separate 'unit'- each c file needs to have all the info it needs to compile (from headers, etc.), and will not use any info from other c files. So, lcd.c does not know anything about main.c, or any other c file you have- if it needs a define, you have to provide it in the lcd.c file, or include a header which has it (or provided with a compiler -D option), if it needs access to a function in another c file, it needs to know about it (an include header, or just specifying the function prototype/declaration). Whatever it takes for each c file to have all the info it needs to compile.
Thanks! I certaintly will keep that in mind.
A few months ago I decided to do something with µCs again...after nearly two years. So, a lot of catching up to do..
I don't see any local bypass caps, or ground stitching vias.
Tim
In a move hard to understand by a lot of Atmel fanboys and hobbyists I remember that Atmel Removed Full-Swing Crystal Oscillator from a lot of Atmega MCU's (48/88/168/328 etc). Might wort to take a look if this is not also your case.
Also check if is working OK with a 8Mhz external crystal.