16MHz internal oscillator????

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

A customer of mine is having a problem I can't reproduce: after messing about with the eeprom a watchdog timer is intentionally triggered by a while(1); loop. This is all fine except that the mega8 appears to be running at 16MHz on its internal oscillator when the processor restarts. Communication only works at 4800baud where it should be 2400, leds blink at twice the speed, etc...
After a power down it works fine again.

I am dumbfounded as to the cause of this problem. Clock calibration byte is in eeprom, but hasn't been corrupted.
Has anyone seen something like this before? (and can we exploit it later :-)

TIA
Igor

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

"...can we exploit it later ..."

Probably.

Search your Mega8 datasheet for OSCCAL. The value will vary from trimmed-unit to trimmed-unit, but OSCCAL of 0xff should give ~200% of the nominal internal oscillator value.

So, my conclusion is that something in your code is tromping on OSCCAL to the tune of 0xff--which just >>happens>used<< to be. :)

Lee

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

I had a similar problem with my 2313 which was supposed to communicate with another 2313 but exhibited an unusual behavior including refusing to be programmed. I thought that at least one of the chips was fried. (Nothing wrong with the program). It turned out that the reset pin of the receiving chip should not have been connected to it's own VCC (via a resistor of course, common ground) but only to to the reset of the sending chip via a simple wire ( I wanted to reset both at the same time). I hope this thread will help.

admin's test signature
 

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

Lee,
This had occurred to us too, but the code is solid. The interesting part is also that is occurs often after a watchdog reset, and only sometimes afer a power down. This hints to something wrong with the internal eeprom workings. The cal byte in eeprom is not overwritten as a powerdown almost always fixes the problem.

We were able to patch it today by reading the calibration byte for a second time and continually comparing OSCCAL to that second value in the main loop. This was a bit of a buck shot approach so we haven't pinpointed the exact problem yet. It does appear to be a silicon error though.

Thanks for both replies,
Igor

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

I let my programmer read the calbyte and write it into the FLASH (not EEPROM). Works perfect. I also own some AVRs which can be tuned up to almost 16MHz internal RC. However, you must not do that, if you are using ADC or EEPROM (see datasheet). Preferably I tune them down to some baud rate friendly value, which seems to be ok according to datasheet (it does not mention downtuning).

/Berndt

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

I've also "downtuned" as Berndt mentioned, to get close to 3.6864MHz and 7.3728MHz. It works pretty slick at modest baud rates.

Keep one thing in mind, though, if planning to do this on a production application: the internal oscillator will move with changes in temperature and supply voltage. Another stable time base of some sort may be needed for periodic re-calibration for reliable communications over the full range of temperatures that the device is exposed to.

Lee