[gelöst] Pollin Evaluations Board und ATMEGA8L ?!?!

Hmm was für eine Taktquelle nutzt denn der Asuro? Quarz mit Kondesatoren oder Oszillator oder intern?
Bzw. kannst du die Fusebits auslesen? Oder zumindest die von der verwendeten Asuro-Programmierung hier verraten?

probiers halt mal mit einem ganz einfachen Testprogramm für den Atmega8.
der Atmega8L ist ja nichts anderes als ein Atmega8. Auf MC.net geistert sogar rum, dass die L Modelle einfach die Fehlproduktionen der Atmega8 Reihe sind, die bei hohen Takten nicht mehr stabil gelaufen sind. Dann wird einfach der Spannungsbereich heruntergesetzt und der noch gewinnbringend verkauft..

Zitat

Wenn ich den Chip reinmache Blinkt LED1 dann beide dann LED dann nichts ... ist wahrscheinlich das Testprog vom ASURO.... wenn ich versuch auszulesen dann hört der auf genauso wenn ich auf RESET drücke.

Dass der Controller bei Aktivität vom ISP sein Programm unterbricht ist ja normal. Oder hab ich da jetzt grad was falsch verstanden.

Es passiert relativ leicht, daß man sich aus dem Atmega durch setzen der Fuses selber aussperrt. Entweder weil man die Taktquelle falsch einstellt oder sich selbst den ISP aus den Fuses abschaltet. Im ersten Fall hilft es, den Chip von extern mit einem Clocksignal zu beschalten. Dazu kann man einfach ein Dreickssignal auf den XTAL1 geben mit einer Frequenz von ungefähr 8 Mhz. Das Signal bekommt man entweder mit einen Oszillatorbaustein oder man baut sich mit nem NE555 einfach einen Taktgenerator selber. Für den zweiten Fall hilft nur der Reset des Bausteins per High-Voltage Programmierung. Das können aber nur wenige Programmieradapter wie das STK500.

Hi,

sowas ähnliches kenne ich. Wenn beim auslesen der Fuse- oder Lockbits jedesmal was anderes angezeigt wird, dann kenne ich 2 Möglichkeiten dafür:

1.
Es wurden einmal die Fusebits manuell in der falschen Reihenfolge programmiert (low-byte - high-byte und eventuell extended-byte). Bei Dir eher nicht der Fall weil der Chip dann gar nichts mehr tut.

2.
Es ist eine zu hohe ISP Frequenz eingestellt, dann hat man den gleichen Effekt. Stell dazu einfach mal eine niedrigerere ISP Frequenz ein. Die darf nicht höher sein als 1/4 der Frequenz des mega8.

Da Du ja leider keine Infos mehr über das alte Programm hast, würd ich einfach mal eine relativ niedrige Freuquenz einstellen. Dauert dann beim ersten proggen etwas, kannst ja aber als erstes mal wieder die Frequenz des mega8 höher setzen.

Gruß, Benny.

Also das die Reihenfolge der Fusebits zu Fehler führen kann, ist mir noch nie aufgefallen. Na ja, hängt vielleicht von der Software ab. AVRStudio überträgt ja alle Fuses in einem Rutsch.

Es ist aber richtig, daß man die ISP Frequenz auf 1/4 des Taktes stellen muss, sonst gibts Stress. Wenn man auf internen Oszillator läuft sollte man mit der ISP Frequenz unter 250kHz bleiben.

Die ISP Frequenz stellt man bei PonyProg ein. Dazu in das Installationsverzeichnis gehen und die Datei Ponyprog2000.ini aufmachen.
Dort findest du dann die Geschwindigkeitseinstellungen. Für den ISP müsste das SPIbusspeed sein. Dort steht bei mir NORMAL und funktioniert mit dem Atmega8 bei 1mhz ohne Probleme. Versuch mal die Einstellungen zu ändern in z.B.
SLOW
VERYSLOW
für schnellere TAkte gibts auch noch
FAST und
VERYFAST
ist aber für dich jetzt eher nicht interessant. Wollte es nur noch mal der vollständigkeit halber erwähnen.

Zitat von Deadeye5589

Also das die Reihenfolge der Fusebits zu Fehler führen kann, ist mir noch nie aufgefallen. Na ja, hängt vielleicht von der Software ab. AVRStudio überträgt ja alle Fuses in einem Rutsch.

Hi,

das ist so nicht ganz richtig. Im Hintergrund werden die nacheinander geschrieben. Es betrifft hier allerdings nur das high- und das lowbyte der fusebits. Das extended byte wird mit einem extra Befehl übertragen.
Wenn man mal mehrere µC über eine .bat-Datei proggen will dann muss man sich damit rumschlagen. Man kann die µC ja auch mit der STK500.EXE in der CMD mit den richtigen Strings proggen. Und wenn man da die Fusebits setzt dann muss man das high- und lowbyte in hex in der richtigen Reihenfolge reinschreiben, sonst killt man den µC.

Aber wie ich schon sagte, das wird bei Ihm wohl nicht der Fall gewesen sein.

Gruß, Benny.

Das kann gut sein... das machen die meisten Hersteller, die wollen ja nicht, dass jemand ihre SW klaut

brauchst Du denn das noch, was da drauf ist....? - Ansonsten einfach den µC komplett löschen (per PonyProg), anschließend kannst Du auch wieder auf die Fusebits zugreifen...

Sollte das auch nicht gehen, kann es auch sein, dass die die ISP deaktiviert oder den Reset-Pin umgefust haben - dann kommst Du leider nur noch mit Hochvolt-Programmierung rein...

Zitat von gentleL

Hey foo38,

ich habs mal ausprobiert mit SLOW und VERYSLOW leider zu keinem Erfolg gekommen...

Mein Lehrer meinte vllt sind die Security Bits so gesetzt, dass man den nicht auslesen kann. (Vom Hersteller aus halt)

Der Chip ist ja beschrieben anscheinend

Alles anzeigen

Dann lösche den Chip mal. Wenn man den löscht dann werden auch die Lockbits zurückgesetzt.

Gruß, Benny.

Wie willst den denn löschen, wenn du nicht draufkommst.

Der Asuro hat nen Bootloader drauf, und wahrscheinlich ist Reset mitels Fusebits auf IO Pin geschaltet.
Dadurch kommst da nur mit dem Bootloader drauf.

Hilft nur nen neuen Atmega 8 kaufen oder den original ISP verwenden.

Der Vollständigkeit halber:
Ggfs. ginge es, dem Bootloader Fusebits unterzuschieben, die er sich dann selber brennt.
Wie das bei diesem Loader geht, weiß ich aber nicht.