Odd.. External xtal set in fusebits but code still running.

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

Can someone explain this to me?

I am developing an AVR multi-tool for myself. it allows you todo basicly anything programming related to an AVR standalone or through serial to PC.

I just added an external clock feature for locked out AVRs. So I hooked up a target, its an attiny2313 set to run on a 8+Mhz external crystal. I loaded it with a simple flip portb on/off every second.

So to test the external clock feature I pulled out the crystal and turn on the clock. So it went from 10Mhz xtal to 1Mhz square wave. The LED is blinking, just alot slower, good. I hit the info button and it output the targets fuse settings so I thought 'sweet the external clock works good enough to read the fuse's it is most likly good enough to write them too.

but. Then I disconnected the external clock source (no clock source now, no crystal) but the tiny's LED is still blinking...

Whats happening? when I put the crystal back in it blinks faster but shouldnt it not be blinking at all?

edit: and when no clock source or crystal i can still read the fusebits too.

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

You seem to talk about an external crystal AND an external clock source. That external clock source appears to be a stand-alone oscillator.

You seem to be saying that the Tiny2313 is running with both the crystal and external clock disconnected. I'll bet that it is running at the external clock frequency due to "leaked" signal from that source into the clock input. Bet you that the Tiny will stop working if you stop the external source from running.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Now try disconnecting a power supply and confirm the Tiny is still running :lol:

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

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

Tell us more about how you read the fuses. What software are you using? What are the results? (Quote verbatim or a screen-shot).

If your fuses are reported as 1's and 0's with your programming software then please observe that 1 means cleared and 0 means programmed. (More user-friendly programming software reports the fuse selections in text "E.g. "Internal RC oscillator...".)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Not much to show. The software reading the fuses is on an atmega32 through uart. The fuses are correct.

[AVRs] Received "i", Looking up function...
[AVRs]  
[AVRs] Checking for response from target...
[AVRs]  
[AVRs] Received response from target, gathering data...
[AVRs]  
[AVRs] DeviceID: 	1E 91 0A
[AVRs] TrgtName: 	Attiny2313
[AVRs] ProgStat: 	Target IS currently programmed.
[AVRs] EPrmStat: 	01:EMPTY
[AVRs] LockByte: 	FF
[AVRs]    lFuse: 	EE
[AVRs]    hFuse: 	DF
[AVRs]   exFuse: 	FF
[AVRs] CaliByte: 	58
[AVRs]  
[AVRs] Done.

Anyways. I think Jim was dead on; for whatever reason its not doing that any more; some sort of leakage.