AVR: Fuse bits fehlprogrammiert

S

Simone Winkler

Guest
Hallo!

Habe da ein mehr oder minder großes Problem:
Auf einer Platine habe ich einen ATmega128L drauf - Oszillator ist dabei ein
externer 4MHz-Quarz.

In meiner "Atmel-neuen" Programmierfreude hab ich natürlich sofort
übersehen, daß die fuse bits genau umgekehrt zu programmieren sind (0 =
programmiert, 1 = unprogrammiert)....und so habe ich den Atmel jetzt auf
eine external clock konfiguriert.

Jetzt geht natürlich das serielle Programmieren nicht mehr...
Ich habe schon einiges versucht, natürlich u.a., eine Frequenz an XTAL1 zu
geben...leider wollte er nicht wieder losfahren. Mein Oszillator war halt
ein gekaufter (SMI 2100CHS 3.579MHz), da ich als "arme Studentin" weder ein
Oszi noch einen Funktionsgenerator besitze ;-) (nur eins über die
Soundkarte, aber das wird wohl doch nicht ganz reichen ;-))).
Na gut - funktioniert hat's nicht - ich kann natürlich ohne Oszi nicht mit
100%iger Sicherheit sagen, daß der Oszillator sich zum Schwingen überreden
hat lassen, aber das Multimeter hat zumindest Spannung angezeigt.

Meine Idee war dann, daß es vielleicht daran liegt, daß der Atmel in einer
Schaltung ist, vielleicht der Oszillator also durch die Schaltung beeinflußt
wird (z.b. durch den Quarz). Hab ihn also rausgetan - war aber leider nix.

Was ich bemerkt hab, war, daß ohne Last die auf dem Multimeter angezeigte
Spannungsamplitude größer war als angehängt auf XTAL1. (sowohl mit als auch
ohne herausgenommenem Quarz).

Ich kann den Atmel auch nicht parallel programmieren (ist ja in einer
Schaltung.....).

Tja...das große Problem dabei ist: das Board ist nicht meines. Ich würd also
gern eine saubere Lösung finden, und wenn es irgendwie geht, keinen neuen
drauflöten müssen... (TQFP-gehäuse... ;-)).
Ich könnt mir notfalls Oszi und Funktionsgenerator ausleihen - aber
irgendwie glaub ich schon nicht mehr, daß das funktioniert...;-) (habe sogar
schon den Takt eines anderen Microcontrollers verwendet, um den Atmel zum
Laufen zu bekommen...)

Vielen Dank für Eure Tips...:)

ah ja...habe (bevor das alles passiert ist) vor einiger zeit bei atmel 2
samples von selbigem muc bestellt. hat jemand erfahrungswerte, wie lange das
dauert? ich warte nämlich nun schon einige wochen...

Simone
 
ah ja...habe (bevor das alles passiert ist) vor einiger zeit bei atmel 2
samples von selbigem muc bestellt. hat jemand erfahrungswerte, wie lange
das
dauert? ich warte nämlich nun schon einige wochen...

Hi
IMHO versendet Atmel nur Muster an Hochschulen und Firmen.

Gruß
Tobi
 
Hallo Simone,

Simone Winkler schrieb:
Hallo!

Habe da ein mehr oder minder großes Problem:
Auf einer Platine habe ich einen ATmega128L drauf - Oszillator ist dabei ein
externer 4MHz-Quarz.

In meiner "Atmel-neuen" Programmierfreude hab ich natürlich sofort
übersehen, daß die fuse bits genau umgekehrt zu programmieren sind (0 > programmiert, 1 = unprogrammiert)....und so habe ich den Atmel jetzt auf
eine external clock konfiguriert.

Jetzt geht natürlich das serielle Programmieren nicht mehr...
Ich habe schon einiges versucht, natürlich u.a., eine Frequenz an XTAL1 zu
geben...leider wollte er nicht wieder losfahren. Mein Oszillator war halt
ein gekaufter (SMI 2100CHS 3.579MHz), da ich als "arme Studentin" weder ein
Oszi noch einen Funktionsgenerator besitze ;-) (nur eins über die
Soundkarte, aber das wird wohl doch nicht ganz reichen ;-))).
Na gut - funktioniert hat's nicht - ich kann natürlich ohne Oszi nicht mit
100%iger Sicherheit sagen, daß der Oszillator sich zum Schwingen überreden
hat lassen, aber das Multimeter hat zumindest Spannung angezeigt.
Welche "Spannung" hast Du denn mit dem Multimeter am
Ausgang des Oszillators gemessen?
Es sollte in der Gegend um 1/2 Ub liegen, bei 5V also
etwa 2,5V. Misst Du aber ca. 5V oder 0V, dann passt was nicht.

Viele Oszillatoren haben nämlich auch einen Enable-
Eingang, der hat Dir vielleich gefehlt.

lG
Wolfgang
 
Welche "Spannung" hast Du denn mit dem Multimeter am
Ausgang des Oszillators gemessen?
Es sollte in der Gegend um 1/2 Ub liegen, bei 5V also
etwa 2,5V. Misst Du aber ca. 5V oder 0V, dann passt was nicht.
....hmm! das könnte mir durchaus etwas bringen... Habe den Oszillator mit
3.3V betrieben - aber lt. Datenblatt (das ich grad lange gesucht hab) mag er
5V haben :). (da hat mir der Verkäufer wieder mal Blödsinn
verkauft....hab's ihm extra gesagt!)

Natürlich wirds dann nicht so gut gehen - wahrscheinlich handelt es sich bei
meiner gemessenen Spannung um irgendeinen Arbeitspunkt oder sowas... sie lag
übrigens bei ca. 1.1V (unbelastet) und 0.9V (belastet). Kommt also hin als
symmetrischer Arbeitspunkt...

Auf
http://www.lssystems.at/infoserver/devel-hard/crystal_osc/Crystal_SMI.pdf
(Seite 2)
ist der Oszillatortyp angeführt (ohne Tristate).

Viele Oszillatoren haben nämlich auch einen Enable-
Eingang, der hat Dir vielleich gefehlt.
Enable-Eingang hat er nicht...

Meine Idee ist jetzt: an 5V hängen -> mit dem 5V-Takt den Atmel füttern....
Eigentlich müßte er das vertragen oder? Könnte höchstens sein, daß er ein
wenig viel Strom zieht (Schutzdioden,...).
Was meint ihr?

Aber ich mach mir ja nicht mehr allzuviele Hoffnungen, daß das
funktioniert...

LG, Simone
 
Hallo Simone!

Hatte vor einiger Zeit das selbe Problem - Fusebits falsch programmiert, von
intern auf extern umgeschaltet - Quarz war nicht dran, IC aber schon
eingelötet. Habe dieses Problem schließlich so gelöst, dass ich eine andere
AVR-Schaltung daneben gelegt habe, GND verbunden habe und mit einem
Stückchen Fädeldraht den Takt des funktionierenden von XTAL1 auf XTAL2 des
toten gelegt - konnte ihn problemlos programmieren danach - obwohl der
Fädeldraht einige 10cm lang war.

Grüße
Andreas
 
: Hatte vor einiger Zeit das selbe Problem - Fusebits falsch programmiert,
von
: intern auf extern umgeschaltet - Quarz war nicht dran, IC aber schon
: eingelötet. Habe dieses Problem schließlich so gelöst, dass ich eine
andere
: AVR-Schaltung daneben gelegt habe, GND verbunden habe und mit einem
: Stückchen Fädeldraht den Takt des funktionierenden von XTAL1 auf XTAL2 des
: toten gelegt

von XTAL1 des funktionierenden AVR ein draht zu XTAL2 des toten AVR??
ich dachte XTAL1 wäre der eingangspin für den externen takt???
habe leider keinen zweiten AVR da - könnte es mit einem PIC versuchen (hab
ich zwar schon mal, aber da war ich nicht sicher, ob der noch ein Programm
oben hat).

muß der quarz draußen sein? (der normalerweise für den takt des AVR
zuständig wäre...)

wäre super, wenn das klappt...

- konnte ihn problemlos programmieren danach - obwohl der
: Fädeldraht einige 10cm lang war.
:
: Grüße
: Andreas
:
:
 
Entschuldige bitte meine Tippfehler, sollte natürlich XTAL1 heißen. Im
Prinzip sollte es egal sein, ob dein "Spender-IC" programmiert ist, oder
nicht, der Oszillator muss auch im unprogrammierten Zustand anspringen.
Externe Beschaltung des XTAL1-Pins des "Empfänger-ICs" würde ich entfernen.
Dieses Problem hatte ich nicht, da mein AVR mit internem Oszillator laufen
sollte. Obwohl AVR-Oszillatoren sehr stabil arbeiten, kann eine zusätzliche
Kapazität sie eventuell in die Knie zwingen - also lieber rauslöten.

Viel Glück!
Andreas
 
Hi Simone,

Simone Winkler schrieb:
Auf
http://www.lssystems.at/infoserver/devel-hard/crystal_osc/Crystal_SMI.pdf
(Seite 2)
ist der Oszillatortyp angeführt (ohne Tristate).
Na gut....ich hatte vergessen die Kristallkugel zu polieren :)

Meine Idee ist jetzt: an 5V hängen -> mit dem 5V-Takt den Atmel füttern....
Eigentlich müßte er das vertragen oder? Könnte höchstens sein, daß er ein
wenig viel Strom zieht (Schutzdioden,...).
Das wird der Atmel nicht mögen. Da musst Du in den Taktausgang einen
Serienwiderstand schalten. Grob geschätzt würde ich zwischen 680R und 1k
nehmen. Hängt davon ab, was Atmel maximal zuläßt und der Oszillator liefert.

Aber ich mach mir ja nicht mehr allzuviele Hoffnungen, daß das
funktioniert...
Nicht verzagen, das wird schon noch.

Viele Grüße,
Wolfgang
 
Simone Winkler wrote:

Ich könnt mir notfalls Oszi und Funktionsgenerator ausleihen - aber
irgendwie glaub ich schon nicht mehr, daß das funktioniert...;-) (habe
sogar schon den Takt eines anderen Microcontrollers verwendet, um den
Atmel zum Laufen zu bekommen...)
Ich hatte das Problem auch schon ein paar Mal. An Deiner Stelle würde ich
mir ein Oszi leihen und erstmal gucken, was tatsächlich wo anliegt; die
einzig giftige Fuse (Deaktivierung der ser. Programmierung) ist bei
serieller Programmierung nämlich nicht zugänglich. Oder hast Du an den
Lock-Bits rumgespielt? Dann könnte es tatsächlich eng werden. Melden sollte
sich der AVR beim Programmer IMHO trotzdem (mit Takt, selbstredend).

Welche Software und welchen Programmer benutzt Du?

Sebastian
 
Aguja wrote:

Hallo !

In meiner "Atmel-neuen" Programmierfreude hab ich natürlich sofort
übersehen, daß die fuse bits genau umgekehrt zu programmieren sind (0 =
programmiert, 1 = unprogrammiert)....und so habe ich den Atmel jetzt auf
eine external clock konfiguriert.

Jetzt geht natürlich das serielle Programmieren nicht mehr...

Tja,

tut mir leid das sagen zu müssen, aber die neuen AVRs haben eine sehr
böse Falle: Man kann seriell (fast) *alle* Fusebits ändern, auch das
SPIEN-Bit welches das serielle Programmieren ganz ausschaltet.
Genau dieses Fuse-Bit ist bei serieller Programmierung nicht änderbar - und
das hat ganz offensichtlich auch einen Sinn. Wirklich giftig sind IMHO nur
die Lock-Bits.

Ich würde evtl. einen anderen Programmer versuchen. PonyProg ist zwar nett
gemacht, teilweise konnte ich damit aber Devices nicht mehr ansprechen, die
uisp z.B. problemlos lesen und beschreiben konnte.

Sebastian
 
Aguja <aguja@despammed.com> wrote:

... Dennoch habe ich das bei einem AtMega8
problemlos geschafft und nur durch paralleles Programmieren beheben können.
Das ist doch der, bei dem man das /RESET-Pin wegdefinieren kann, oder?

Das ist dann natürlich ein typischer Fall von ,,denkste''. Bevor man
das tut, sollte man wohl besser schnell noch einen Bootloader
programmieren. ;-)
--
J"org Wunsch Unix support engineer
joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/
 
Joerg Wunsch wrote:

Aguja <aguja@despammed.com> wrote:

... Dennoch habe ich das bei einem AtMega8
problemlos geschafft und nur durch paralleles Programmieren beheben
können.

Das ist doch der, bei dem man das /RESET-Pin wegdefinieren kann, oder?

Das ist dann natürlich ein typischer Fall von ,,denkste''. Bevor man
das tut, sollte man wohl besser schnell noch einen Bootloader
programmieren. ;-)
Jau; außerdem kann das Ding noch so "genial" abstürzen, daß sämtliche Fuses
völlig kuriose Werte annehmen. Alles schon gehabt... Bisher konnte ich
meinen immer mit der seriellen Methode wiederbeleben, aber irgendwann muß
ich mir wohl doch auch einen parallelen Programmer bauen.

Sebastian
 

Welcome to EDABoard.com

Sponsor

Back
Top