EEPROM - Werte verändern sich! ATMega32 defekt?

[Sagitus]

Hallo zusammen,

ich versuche ich mein DIV - Modul abzugleichen und bin auf ein seltsames Problem gestossen.
Z.Z. funktioniert die Kummunikation zwischen IFP und DIV-Modul nicht. Zu einem DCG-Modul funktionieren Terminal-Programm, vi-Demos etc. einwandfrei.

In diversen Foren habe ich gelesen, die Prommer-Einstellungen zu überpfüfen, und die Fuses richtig zu setzen.

All die Ratschläge habe ich befolgt... und mir ist folgendes aufgefallen:

Flashen des ATMega funktioniert. Fuses setzen auch! Ein anschließender Verify bestätigt, dass die programmierten Daten korrekt sind.
Das Programmieren des EEPROM-Files funktioniert scheinbar auch... "Verify nach Programmierung" wird automatisch durchgeführt und gibt keine Fehler.
Nach der Programmierung initialisiert sich das DIV-Modul.
Versuche ich anschließend ein "manuelles" verify auf den EEPROM-Speicher durchführe, erhalte ich IMMER einen Fehler an immer derselben Speicheradresse....

18:41:03: [ERROR] Verifying EEPROM...Failed! address=0x0082 expected=0x00 actual=0x89
18:42:36: [ERROR] Verifying EEPROM...Failed! address=0x0082 expected=0x00 actual=0x89
18:43:42: [ERROR] Verifying EEPROM...Failed! address=0x0082 expected=0x00 actual=0x7e
18:54:09: [ERROR] Verifying EEPROM...Failed! address=0x0082 expected=0x00 actual=0x16

Ein ebenfalls manuell gestartetes Verify auf Flash-Speicher (HEX-File) und Fuses ist immer erfolgreich. Einzig das EEPROM macht Schwierigkeiten.

Als Firmware verwende ich die Original-FW von CM in der aktuellen Version.
Mein Prommer: AVRISP MKII
Software: AmtelStudio 6 auf Windows XP (mit entsprechenden Rechten)
Terminalsoftware: HyperTeminal unter Windows XP
Das IFP - Modul ist angebunden mit USB und LAN (funktioniert beides)

Hat jemand von euch eine Idee? Kann der ATMEGA32 defekt sein?

Viele Grüße und schon mal vielen Dank
Markus

[psclab38]

Hmmm. Wenn die Kommunikation zwischen DIV und IFP nicht klappt, dann läuft der Controller des DIV vielleicht mit dem falschen Takt. Stimmen die Fuses wirklich?
Und wenn der Takt nicht richtig eingestellt ist, dann kann der AVRISP mk2 Probleme machen. Der Kommunikationstakt des AVRISP darf max. 1/4 des Prozessortaktes betragen.

Grüße Paul

[Sagitus]

Hallo psclab38,

vielen Dank für die schnelle Antwort...
Ich vermute das Kommunikationsproblem in der fehlerhaften Programmierung? des Chips.

Der Kommunikationstakt des AVRISP darf max. 1/4 des Prozessortaktes betragen.

Den Takt habe ich schon überprüft und auch verschiedene Taktungen versucht.
Standardmäßig sind 125Khz eingestellt. Das ist auch der Takt mit dem ich die meisten Versuche unternommen habe.

Die Fuses habe ich schon mehrfach überprüft auch anhand der im Forum angegebenen Werte... auch verschiedene Reihenfolgen der Programmierung der einzelnen Module (HEX-File, dann EEP-File, Fuses) habe ich getestet. Auch mit und ohne vorheriges explizites löschen des Chips.
Ich kann gerne (aber erst morgen) einen Screenshot einstellen.

Direkt nach der Programmierung scheint der Verify auch ok... versuche ich den Verify nach der Initialisierung des Modul aufzurufen, schlägt dieser fehlt. Noch zu erwähnen wäre, dass der angezeite Verify-Fehler ab dann immer derselbe ist, solange bis ich den EEPROM-Speicher neu programmiere. Das kommt im ersten Post nicht so rüber.

Da die Kosten überschaubar sind, habe ich versuchsweise mal einen neuen ATMega32 bestellt.

Noch etwas fällt mir ein...
Die Kommunikation zwischen DIV und IFP funktioniert zumindest in eine Richtung teilweise.
Beim bedienen des Drehgebers auf dem PM8 werden 3 Statusinformationen geschickt, die ich über das Termialprogramm angezeigt bekomme. Die 2. Statusmeldung beinhaltet immer ein [PARERR]. Ich liefere einen Auzug der Meldungen schnellestens nach...

Für noch weitere Ideen wäre ich sehr dankbar...

Viele Grüße
Markus

[psclab38]

Hallo Markus,

Direkt nach der Programmierung scheint der Verify auch ok... versuche ich den Verify nach der Initialisierung des Modul aufzurufen, schlägt dieser fehlt.

wernn ich mich nicht irre, dann schreibt das Modul bei der Pascal-Firmware die Offsetwerte nach der Initialisierung ins EEPROM. Dann wäre wäre Deine Beobachtung völlig in Ordnung.

Grüße
Paul

[Sagitus]

Hallo pcslab38,

wernn ich mich nicht irre, dann schreibt das Modul bei der Pascal-Firmware die Offsetwerte nach der Initialisierung ins EEPROM. Dann wäre wäre Deine Beobachtung völlig in Ordnung.

vielen Dank für den Hinweis...
Bei genauerem durchlesen des Onlineartikels habe ich inzwischen auch einen entsprechenden Hinweis dazu gefunden, dass Werte im EEPROM hinterlegt werden.

Da das DIV-Modul prinzipiell funktioniert muss der Kommunikationsfehler anderswo liegen.
Ich werde daher nochmal den Aufbau intensiv kontrollieren.
Damit ist dieser Threat hinfällig was die EEPROM - Daten angeht... sorry für die unnötigen Posts von mir.

Viele Grüße
Markus

[psclab38]

Hallo Markus,

Damit ist dieser Threat hinfällig was die EEPROM - Daten angeht... sorry für die unnötigen Posts von mir.

keine Ursache.

Da das DIV-Modul prinzipiell funktioniert muss der Kommunikationsfehler anderswo liegen.
Ich werde daher nochmal den Aufbau intensiv kontrollieren.

So wie es aussieht kannst Du ja die Meldungen des Moduls lesen. Damit ist der Rückkanal ok. Kontrollier mal die Bestückung auf der Empfangsseite, also R3, R24, "R25" und U2.

Wenn die Bestückung ok ist, dann hast Du vielleicht einen "preiswerten" Optokoppler erwischt. Manche Fabrikate muß man explizit zur Mitarbeit überreden; siehe hier: viewtopic.php?f=31&t=541

Grüße,
Paul

[Sagitus]

Hallo,

So wie es aussieht kannst Du ja die Meldungen des Moduls lesen. Damit ist der Rückkanal ok. Kontrollier mal die Bestückung auf der Empfangsseite, also R3, R24, "R25" und U2.

Vielen Dank für den Hinweis mit dem Zaun(-pfahl). Wie schon oft lag das Problem beim Bediener des Lötkolbens.
Ich hatte z.T. die für das TRMSC-Modul vorgesehenen geänderten Bauteile auf der DIV-Platine verwendet. Das ist jetzt korrigiert... und (oh Wunder) jetzt klappt auch die Kommuniktation zwischen den Modulen.

Einzig der Bereichswechsel über den Drehgeber am PM8 erzeugt noch drei Meldungen
2:255=196[SRQUSR]
2:255=133[PARERR]
2:255=192[SRQUSR]

2 ist die Moduladresse meines DIV

Nochmal vielen Dank für die tolle Unterstützung!!!
Markus

[psclab38]

Hallo Markus,

Einzig der Bereichswechsel über den Drehgeber am PM8 erzeugt noch drei Meldungen
2:255=196[SRQUSR]
2:255=133[PARERR]
2:255=192[SRQUSR]

das könnte auch normal sein. Ich hab's nicht ausprobiert (ich hab ja die C-Firmware drin ), aber die Codierung des Statusbytes 255 sieht so aus:

Code: Alles auswählen

196 = 11000100
133 = 10000101
192 = 11000000

      10000000 = Busy
      01000000 = UserSRQ

      00001000 = Button Enter
      00000100 = Button up
      00000010 = Button down
      00000001 = Button freigegeben

UserSRQ will heißen, daß sich der User am Panel zu schaffen gemacht hat. Woher der PARERR kommt, ist mir aber schleierhaft. Hat vielleicht damit zu tun, daß die Pascal-FW beim DIV gar keinen Drehgeber erwartet, nur den Enterknopf.

Viele Grüße
Paul