Lesson for life time

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

This is my project's outline:
Controller: ATmega8L
Clock : 8Mhz Internal with calibration code
Peripherials: ADC, LCD, Keys

Project Description:
Using default values stored in internal EEPROM, monitor input current (ADC value). If this input current crosses the SET limit, then a formula will tell us, in how much TIME, relay should be OFF.

All and all a simple looking project.

But was HORIBLE experience due to MISLEADING datasheet of ATmega8.

I used Timer 2 in ASYNC mode CTC with external 32.768KHz crystal.

Every thing was fine and simple, except the DELAY counting code.

I wrote an ISR, which will increment a global variable and compare it with the value calculated using the formula.

The BIGGEST Problem:
Timer 2 works fine in stand alone application. It is very accurate.
But if LCD Code is mixed with the Timer 2, then timer was BAD. Used to count 670ms instead of 1400, an example of error.

I refered abcminiuser, and other freaks users. But all in vain... no one could POINT out the PROBLEM. abcminiuser has helped me a lot during this problem and guided me to a large extent to get going.

At last, today, I got a reply from "theusch", a freaks user.
As per the reply, I simply connected two 22pf disc cap to crystal and grounded it's other legs. Every thing started working fine.

Quote:
The Lesson

In Timer2 Async CTC mode, Always use 22pf disc with crystal of 32.768 Khz, to avoid "glitches" in crystal's frequency. EVEN THOUGH DATASHEET SAYS NOT TO DO IT

Hope this will be sticky message forever.......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yellowboy_75 wrote:
Hope this will be sticky message forever.......

But hopefully in the right forum - this has nothing specific to do with GCC does it?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's already a known issue in the inofficial errata list there:

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=185178#185178

(I'm moving the thread anyway.)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Was the CKOPT fuse set as per P. 26 of the datasheet? That should enable internal 36pf capacitors.

Ralph Hilton

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
CKOPT was unprogram.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps I understand thing wrong, but CKOPT has nothing to do with asyncrhonous ocillator for RTC. It only affects Main CPU clock oscilator (for external crystal/resonator). Am I wrong?

Guillem.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guillem: That depends on what clock source you're working with.
Clearly, the OP is using one of the internal calibrated RC oscillator as a clock source, since the XTAL1/XTAL2 (aka TOSC1/TOSC2) pins are being used for the 32.768 kHz crystal in asynchronous mode on an ATmega8.

Page 32 of the datasheet quite clearly states that the CKOPT fuse must be programmed in order to remove the need for external capacitors on TOSC1/TOSC2.

Similarly, page 28 states that, if a 32.768 kHz crystal were being used as the main system clock, then CKOPT would need to be programmed to eliminate the need for external capacitors on XTAL1/XTAL2 (ie. the very same pins).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yellowboy_75 wrote:
.
But was HORIBLE experience due to MISLEADING datasheet of ATmega8.

Hope this will be sticky message forever.......

Since this is titled 'Lesson for life time', I hope you won't mind a brief lecture from another perspective. Your experience is a normal part of development. Datasheets, application notes, turorials, books and any other source of information WILL have defects that will throw you off. If you find this fact 'HORRIBLE' then, and don't take this the wrong way, you are in the wrong business. I personally never trust any information I receive and for me the whole debugging process isn't just finding the mistakes I made, but the mistakes in the documents and sometimes in the devices themselves. When I come across a bug that isn't fixed by the obvious, then I just assume I have incorrect information and I attempt a workaround using another technique.

Development is a kind of war against defects in your own work and the work of others. Personally I delight in making my way through the mine fields and various traps that are set in my path. Sorting through all the truth, mistakes, and blatent lies can get frustrating at times, but if you are smart and persistent you will eventually figure out a way to get it done. If you find this process FUN you will thrive, if you find it HORRIBLE you will burn out quickly.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, it can be Horrible if that happens when the system is already in production, and some units sold. Specially if the 'big boss' blames on you and your job is on the spot.
If it is still in the early development stages, the PCB's are not sent to manufacture, and it only delay a little the development, then it should be fun. In fact, that is what I found always: 10% time designing circuits 90% time solving theyr problems, so I suggest longer development times due to this.

Guillem.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been in a couple of failed projects where the 'boss' was too stupid to follow the advice of the programmers on how to properly do software engineering. Yourdin's book 'Death March' describes some similar projects. Basically they don't allocate sufficient time or resources and then start changing specs well after the project is underway.

I guess I've had the attitude that if they want to pay me to do something stupid and I've warned them, then I get my resume out and start saving extra cash because I know I'll get shit canned - even though I told them how to do it right - so the boss can cover his stupid ass until he takes the entire company down the tubes.

But on the personal level, I guess I've been fortunate enough to not let it drive me crazy. It is, after all, their problem and this type of thing occurs commonly in our profession.

Again, if you let the normal routine of development get to you, this career will kill you. You just can't let other people's stupidity get to you (wether it is a bad boss or a bad datasheet) and you have to take your own stupidity as a perfectly normal aspect of being human and your mistakes as a damn good way to learn new stuff. I've learned most of the really important stuff in this career from my own stupid mistakes and from seeing the results of other's stupid mistakes.

I really do think that this career requires a personality type that can just shrug this off and move on to the next thing and not get too worked up over the 'HORRIBLE'ness of it all. But I've worked with other people who let it drive them to distraction and finally become total burn-outs. That is sad and they really should have choosen some other career.

I guess that's why I'm bothering to push a warning here: if it ain't FUN why do it. This career path may seem to pay well, but what good will it do you if you burn out by 40 and hate every day of your working life? Anyway, the Indians and Chinese are taking the money out of the career, so why else would you do it other than for fun?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another point:

Whenever current consumption was not an issue (not battery powered), its easier to use a standard crystal like e.g. 11.0592MHz.

On my experience MHz crystals are more stable and less sensitive against noise, temperature variation and so on in comparison to a 32kHz crystal.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
... Development is a kind of war against defects in your own work and the work of others....

I find it is more of a siege. A good sign that a product is pretty well debugged is when the only bugs you are finding are in the things it is connected to. (Add smilies to taste. Or smileys? :wink:)

- John

Last Edited: Thu. Jul 13, 2006 - 07:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I believe that SYSTEMS are ALWAYS perfect, may it be a microcontroller or operating system. My word "perfect" means, the system designer has already thought of the facilities to be made available to users like us. We as users of these systems, simply read the documents which may have errors, but we always should trust the systems.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In this situation it does seem to me that the problem came not from the datasheet but from lack of study of it. Have you tried programming the CKOPT fuse and does that work correctly?
As far as perfect systems go it seems to me that you are setting yourself up for a rather frustrating career as the simple reality is that they rarely exist. Atmel, from my experience, do a good job with their systems and support. Have you ever used Windows???

Ralph Hilton

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Have you ever used Windows???

Do you mean the bug free version? :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

:-) And a small can of pyrethrum spray just in case.

Ralph Hilton

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
Have you ever used Windows???

Do you mean the bug free version? :lol:

Bug free but oodles of "features".

Don