Seite 1 von 3

[Gelöst] Falsche Fuse gesetzt, Atmega328P nicht mehr ansprechbar

Verfasst: 13.05.2021, 19:49
von stony
Hallo zusammen,

ich habe eine fertig bestückte HMSensor-CR2032 ohne externen Quarz. Jetzt wollte ich nach der Anleitung (https://asksinpp.de/Projekte/psi/HMSensor/#software) die Fuses setzen, habe aber ohne zu überlegen direkt mal die Fuses gesetzt -> Low E0 High D2 extended FF

Dann war nichts mehr. Die LED vom Board hat beim erhalt von +3 V nicht geleuchtet, Reset Knopf reagiert auch nicht. Die richtigen Fuses wären wohl E2 D2 FF gewesen (E2 steht laut https://www.engbedded.com/fusecalc/ für den internen Quarz).

Zuerst dachte ich "mist, jetzt kann ich das Board wegwerfen, da es kaputt ist), aber scheinbar lässt sich das Teil noch retten. Was ich bisher versucht habe: Einen externen Quarz an Y1 gelötet, dann wieder 3 V drauf. Leider reagiert die MCU trotzdem nicht, AVRDude kann sie nicht finden.

Habt ihr Ideen? Könnt ihr mir helfen das Kind aus dem Brunnen zu holen?

Re: Falsche Fuse gesetzt, Atmega328P nicht mehr ansprechbar

Verfasst: 13.05.2021, 20:02
von HMSteve
Hast Du nur den Quarz an Xtal1 und Xtal2 vom ATMega geloetet, oder auch die ueblichen Lastkapazitaeten nach Masse?

Viele Gruesse,
Stephan

Re: Falsche Fuse gesetzt, Atmega328P nicht mehr ansprechbar

Verfasst: 13.05.2021, 21:24
von stony
Habe den Quarz an Y1 gelötet, schau mal hier das Bild https://asksinpp.de/assets/img/CR2032-B ... 444def.svg an. Ist von der verlinkten Seite. Aber jetzt wo du es sagst: Nur den Quarz und nicht die C4 und C5 Kondensatoren. Braucht der Quarz diese um zu schwingen?

Re: Falsche Fuse gesetzt, Atmega328P nicht mehr ansprechbar

Verfasst: 13.05.2021, 21:42
von HMSteve
Du brauchst einen 8MHz Quarz und die beiden Cs mit je ca 12 bis 22 pF. Mit dem 32.768kHz Quarz geht das nicht.

Viele Gruesse,
Stephan

Re: Falsche Fuse gesetzt, Atmega328P nicht mehr ansprechbar

Verfasst: 13.05.2021, 21:48
von stony
Ich habe aktuell einen 8.0000 MHz AEC12E Quarz zur Hand (ja mit 0 Nullen). Soll das 8 oder 80 MHz sein? Wobei 80 ein wenig viel wären, oder? Leider habe ich die Kondensatoren nicht zur Hand. Andere Werte wären auch möglich oder dürfen es speziell nur 12 bis 22 pF sein?

Re: Falsche Fuse gesetzt, Atmega328P nicht mehr ansprechbar

Verfasst: 13.05.2021, 21:53
von jp112sdl
Welchen Programmer nutzt du denn?
Der Diamex Prog-S2 hat einen Taktgeber, mit dem man sich aus versehentlich gesetztem ext. Takt wieder retten kann.

Re: Falsche Fuse gesetzt, Atmega328P nicht mehr ansprechbar

Verfasst: 13.05.2021, 22:03
von HMSteve
stony hat geschrieben:
13.05.2021, 21:48
Ich habe aktuell einen 8.0000 MHz AEC12E Quarz zur Hand (ja mit 0 Nullen). Soll das 8 oder 80 MHz sein? Wobei 80 ein wenig viel wären, oder? Leider habe ich die Kondensatoren nicht zur Hand. Andere Werte wären auch möglich oder dürfen es speziell nur 12 bis 22 pF sein?
Wenn da 8.0 draufsteht, ist hoffentlich auch 8 drin. Die Cs sind nicht extrem kritisch, wenn du aber nichts unter ca 50pF zur Hand hast, wuerde ich es eher erstmal ohne probieren.

Viele Gruesse,
Stephan

Re: Falsche Fuse gesetzt, Atmega328P nicht mehr ansprechbar

Verfasst: 13.05.2021, 22:10
von HMSteve
jp112sdl hat geschrieben:
13.05.2021, 21:53
Welchen Programmer nutzt du denn?
Der Diamex Prog-S2 hat einen Taktgeber, mit dem man sich aus versehentlich gesetztem ext. Takt wieder retten kann.
Oh, kannte ich noch gar nicht, den 10poligen Anschluss hab ich nie beachtet.
Von dem muesste dann Pin 3 an Xtal1.

Viele Gruesse,
Stephan

Re: Falsche Fuse gesetzt, Atmega328P nicht mehr ansprechbar

Verfasst: 13.05.2021, 22:13
von jp112sdl
HMSteve hat geschrieben:
13.05.2021, 22:10
Oh, kannte ich noch gar nicht, den 10poligen Anschluss hab ich nie beachtet.
Nachdem ich mich aus Unbedarftheit und "keinem Plan, was ich da mache", aus 2 eQ-3 Geräten ausgesperrt hatte, war das Vorhandensein des Takt-Pins das wichtigste Kriterium für den Kauf des Diamex. :mrgreen:
Ich glaub, deimos hatte mich darauf damals auf dieses Feature hingewiesen.

Re: Falsche Fuse gesetzt, Atmega328P nicht mehr ansprechbar

Verfasst: 13.05.2021, 22:25
von stony
HMSteve hat geschrieben:
13.05.2021, 22:03
Wenn da 8.0 draufsteht, ist hoffentlich auch 8 drin. Die Cs sind nicht extrem kritisch, wenn du aber nichts unter ca 50pF zur Hand hast, wuerde ich es eher erstmal ohne probieren.

Viele Gruesse,
Stephan
Ich habe gerade ein älteres Board gefunden mit einem 8 MHz Quarz und 2 22 pF (Nr 22) gefunden und diese ans Board gelötet. Sieht zwar nicht schön aus, musste den Quarz mit Beinchen verlängern, aber der Kontakt sollte ja so trotzdem gewesen sein. Leider leuchtet weder die LED, noch lässt sich das Board ansprechen :(
jp112sdl hat geschrieben:
13.05.2021, 21:53
Welchen Programmer nutzt du denn?
Der Diamex Prog-S2 hat einen Taktgeber, mit dem man sich aus versehentlich gesetztem ext. Takt wieder retten kann.
Den "eHajo ISP". Da dieser nur mit 5 läuft, habe ich sämtliche Pins an einen Levelshifter angeschlossen, damit ich mir nichts mit 5 V zerschieße. Das hat auch zum Setzen der Fuses soweit immer funktioniert.

Hier auch nochmal die AVRDude Log. Jetzt wo ich nochmal genauer drauf schaue, ob ich beim Erstellen ja völligen Blödsinn geschrieben. Die low fuse habe ich auf 0xE0 gesetzt. "Ext. Clock; Start-up time PWRDWN/RESET: 6 CK/14 CK + 65 ms; " -> sagt euch das was? Ist mein Projekt noch zu retten? Ich bin ziemlich neu und recht unerfahren in dem Thema.

Code: Alles auswählen

_WRITINGINGFUSES
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
>>>: avrdude -u -c ehajo-isp -p m328p -P usb -U lock:w:0xFF:m -U lfuse:w:0xE0:m -U hfuse:w:0xD2:m -U efuse:w:0xFF:m 

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: reading input file "0xFF"
avrdude.exe: writing lock (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude.exe: 1 bytes of lock written
avrdude.exe: verifying lock memory against 0xFF:
avrdude.exe: load data lock data from input file 0xFF:
avrdude.exe: input file 0xFF contains 1 bytes
avrdude.exe: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lock verified
avrdude.exe: reading input file "0xE0"
avrdude.exe: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0xE0:
avrdude.exe: load data lfuse data from input file 0xE0:
avrdude.exe: input file 0xE0 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:

Reading | ################################################## | 100% -0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0xD2"
avrdude.exe: writing hfuse (1 bytes):

Writing | ################################################## | 100% -0.00s

avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0xD2:
avrdude.exe: load data hfuse data from input file 0xD2:
avrdude.exe: input file 0xD2 contains 1 bytes
avrdude.exe: reading on-chip hfuse data:

Reading | ################################################## | 100% -0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of hfuse verified
avrdude.exe: reading input file "0xFF"
avrdude.exe: writing efuse (1 bytes):

Writing | ################################################## | 100% -0.00s

avrdude.exe: 1 bytes of efuse written
avrdude.exe: verifying efuse memory against 0xFF:
avrdude.exe: load data efuse data from input file 0xFF:
avrdude.exe: input file 0xFF contains 1 bytes
avrdude.exe: reading on-chip efuse data:

Reading | ################################################## | 100% 0.02s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of efuse verified

avrdude.exe done.  Thank you.