Hallo @ all Ich verwende einen ATXMEGA 128A3. Ich habe eine Programm geschrieben das Paramater, die über die RS232 Schnittstelle kommen in den EEPROM gespeichert werden. Dies habe ich mehrfach erprobt. Ich schreibe die Daten über die RS232 Schnitstelle rein. Anschließend schalte ich die Versorgungsspannung aus und dann wieder ein. Danach lese ich die gespeicherten Werte aus den EEPROM aus und übertrage diese wieder an den PC. Dies funktioniert auch ohne Fehler. Nun habe ich 2 seperate Platinen. Auf jeder Platine ist der µC drauf. Auf der 1. Platine funktioniert die EEPROM Speicherung und auf der anderen Palatine funktioniert es nicht. Auf beiden µC ist die gleiche Firmware drauf. Jetzt habe ich im ERRATA gelesen das es bei der Revision B beim Atmel XMEGA 128A3 Probleme mit dem EEPROM gibt. Meine Vermutung ist das auf den beiden Platinen eine unterschiedliche µC Revision drauf ist. Jedoch weiß ich nicht wie ich herrausfinden kann welche Revision verbaut ist. Ich verwende ein JTAGICE MKII und das AVR Studio. Dort kann ich die Signatur des µC auslesen. Diese ist bei beiden identisch. Wie weiß ich jetzt welche Revision verbaut ist?
Angehängte Dateien:
-
ATXMEGA_128A3.PNG
84 KB
Es kann natürlich auch sein das der µC defekt ist, jedoch alle anderen Funktionen wie Timer, RS232 und SPI funktionieren sehr gut. Es kann jedoch der EEPROM Controller defekt sein. Jedoch halte ich dies für sehr unwahrscheinlich
Hi
>Wie weiß ich jetzt welche Revision verbaut ist?
Steht bei Atmel im allgemeinen auf der Unterseite des ICs.
MfG Spess
Kannst Du mir nich einen Link senden. Ich habe bereits danach gesucht ab nicht wirklich gefunden. Bitte Link und Seite angeben. Wir stehen kurz vor der Serienfertigung und das ist jetzt natürlich nicht besonders schön wenn es auf einem µC funktioniert und auf dem anderen µC nicht funktioniert.
Ich vermute mal, auch der Xmega hat ne Brownout-Fuse, die man setzen muß, wenn man den EEPROM benötigt. Peter
spess53 schrieb: >Steht bei Atmel im allgemeinen auf der Unterseite des ICs. Johann schrieb: >Kannst Du mir nich einen Link senden. Vielleicht zu schnell gelesen? Wie soll man Dir denn einen Link auf die Unterseite Deines uC schicken? ;-)
Wie soll ich auf die Unterseite des IC schauen wenn dieser draufgelötet ist :-) Was meinst Du mit den Brownout-Fuse? Die Brownout-Fuses geben doch die Spannung an ab dem der Reset des µC durchgeführt wird. Wenn die Spannung unterschritten wird, erzeugt der µC einen Reset. Oder reden wir hier von was anderen?
Das habe ich im Datenblatt gefunden.: Each device has a three-byte device ID which identifies the device. These registers identify Atmel as the manufacturer of the device and the device type. A separate register contains the revision number of the device. Demnach steht es in einem Register des µC. Nur kann man es leider nicht so einfach auslesen. Ich könnte eine Funktion schreiben mit der ich die Revision auslesen kann und dann per RS232 an den PC übertrage. Ich finde es nur schwach das Atmel einem dies nicht einfacher ermöglicht.
Du bist sicherlich nur genervt, gerade. Daher schreibst Du so. Entweder Du gibst die Revision Nummer per Software aus oder Du lötest den uC ab und schaust auf die Unterseite. Weitere Möglichkeiten gibt es nicht. Schrei in Dein Kissen, hau' den Lukas und dann entscheide Dich für das eine oder andere.
Ich kann das IC nicht ablöten. Das ist ein 800MHz AD/C Board für eine EURONEN. Und genau deshalb bin ich leider etwas angespannt. Ablöten heist zerstörren des Boards und das sollte wirklich der letzte Schritt sein. Ich habe noch eine Möglichkeit gefunden. Ich AVR Studio gibt es noch einen weiteren Reiter, da kann man den Takt Kalibrieren und den Offset Fehler vom AD-Wandler einstellen. Dort soll unter "REVID - MCU Revision ID" die Revision des µC stehen :-) Mist jetzt ist alles auf Arbeit und ich bin kurz davor wieder hin zu fahren um es auszuprobieren. Für alle die es Interessert es steht auf Seite 43 Absatz 4.20.4 http://www.atmel.com/dyn/resources/prod_documents/doc8077.pdf
Johann schrieb: > Und was mache ich wenn die Revisionen beide gleich sind :-) das was jeder andere auch macht: hau dir ein Becks in Schädel und geh Schäfchen zählen, Morgen ist auch noch ein Tag MfG
Johann schrieb: > Was meinst Du mit den Brownout-Fuse? Die Brownout-Fuses geben doch die > Spannung an ab dem der Reset des µC durchgeführt wird. Wenn die Spannung > unterschritten wird, erzeugt der µC einen Reset. Ja und das muß man eben enablen: Bit 5:4 - BODACT[1:0]: BOD operation in active mode Bit 2:0 - BODLEVEL[2:0] - Brown out detection voltage level Der Default-Zustand ist undefiniert: Initial Value 1 1 - - - - - - Die Xmega Datenblätter sind wirklich ne Qual, ehe man was findet und dann kann man nichts damit anfangen. Peter
So ich habe mal die Revision ausgelesen. Es steht bei beiden µC die Revision 0x01 im REVID Register. Somit sind beide µC Revision B Ich muss noch mal nachlesen was die BODACT und BODLEVEL Register bedeuten
Kannst Du mir schreiben wie die Zustaände der Register sein müssen
Ich habe mit AVR die Fuses von BODACT[1:0] und BODLEVEL[2:0] ausgelesen. BODACT steht auf "BOD Disabled" BODLEVEL steht auf 1,6V Bei beiden µC steht das gleiche drin eienr geht und der andere geht nicht. Bis auf das EEPROM funktionieren jedoch beide µC sehr gut.
Johann schrieb: > Ich schreibe die > Daten über die RS232 Schnitstelle rein. Anschließend schalte ich die > Versorgungsspannung aus und dann wieder ein. lies doch mal die Daten ein, ohne die Spannung abzuschalten, dann weist du ob er überhaupt daten speichern kann.
Der µC hängt sich bei schreiben auf so das ich nichts mehr machen kann. Beim anderen µC ist es kein Problem die Daten zu schreiben und dann wieder auszulesen.
Johann schrieb: > Der µC hängt sich bei schreiben auf so das ich nichts mehr machen kann. glaube ich nicht - denn der µC arbeitet immmer einen Befehl nach den anderen ab, es gibt keinen Befehl wo der Prozessor blockiert! (ohne Sleep) Wennn überhaupt kann es nur eine Programmierte schleife sein wo die ende bedingung nicht erreicht wird.
Ich habe mal den Code unterscuht den der Codevision Compiler erzeugt. Er packt Daten auf dem Stack und da kann schon mal die Rücksprungadresse verloren gehen und somit hängt der µC. Dann kann man nur noch über den Watchdog einen Reset durchführen.
Johann schrieb: > Er packt Daten auf dem Stack und da kann schon mal die Rücksprungadresse > verloren gehen und somit hängt der µC. das sieht eventuell so aus aber das stimmt nicht. Denn dem µC ist es egal wo er weiter macht er finden schon einen Befehl den er als nächsten abarbeiten kann. Wenn aber der Stack verloren geht und das ist ja nichts anderes als ram dann würde der µC überhaupt nicht sinnvoll arbeiten man könnte keiner Berechnung mehr trauen und nicht nur das schreiben in dem EEPROM. Das kann also nicht die erklärung sein. hängt doch mal ein timer interupt rein der eine LED linken lässt und im init sorgst du dafür das er ohne tastendruck nicht weiter macht. Danach müsste man ja sehen das die LED nicht mehr blinkt - was ich aber nicht glaube. Die meisten Fehler sind doch Softwarfehler.
Ich sende die Daten für den EEPROM über RS232. Wenn ich die Daten in den EEPROM geschrieben habe sende ich ein Bestätigung an den PC zurück. Manchmal bekomme ich jedoch keine Bestätigung. Selbst wenn ich eine Bestätigung bekomme kann ich die Daten auch mit dem AVR Studio auslesen, indem ich den EEPROM auslese und mit einem Texteditor anschaue. Es steht totaler Müll drin. Beim identischen Board ist dieser Fehler noch nie aufgetreten ich habe es bereits schon so oft getestet. Daher gehe ich davon aus das der EEPROM in dem einen µC defekt ist.
Johann schrieb: > Beim identischen Board ist dieser Fehler noch nie aufgetreten ich habe > es bereits schon so oft getestet. Daher gehe ich davon aus das der > EEPROM in dem einen µC defekt ist. was ist wenn du mal mit dem AVR Studio daten in den EEPROM schreibst und dann wieder ausliest?
Du weißt aber schon, daß es eine Würgaround gibt: http://www.atmel.com/dyn/resources/prod_documents/doc8241.pdf http://www.atmel.com/dyn/resources/prod_documents/AVR1008.zip Peter
Dieses Workaround kann man ja nicht gerade als Lösung darstellen. Da man den µC in den Sleep Mode versetzt und dann über einen Interrupt aus der Scheiße wieder herrauskommt. Das merkwürdige ist ja das beide µC die gleiche Revision haben und bei einem geht es immer und beim anderen nie.
Johann schrieb: > Das merkwürdige ist ja das beide µC die gleiche Revision haben und bei > einem geht es immer und beim anderen nie. Errata sind ja keine garantierten Features. Sie können auftreten, aber sie müssen nicht bei jedem Exemplar auftreten. Es kann sogar sein, wenn Du die Schreibroutine an eine andere Stelle im Flash setzt oder eine andere EEPROM-Adresse benutzt, daß dann der defekte funktioniert, aber der vorher funktionierende nicht mehr. Für zuverlässige Funktion hast Du 2 Möglichkeiten: 1. Workaround programmieren 2. Alte ICs wegschmeißen und neue Revision einlöten. Peter
Aber ab welcher Revision geht denn der EEPROM wieder. Bei der Revision D steht doch auch noch etwas vom EEPROM Problem. Jedoch gibt es von der Revision D noch kein Workaround. Ist es nun behoben oder muss man dort den gleichen Workaround benutzen. Ich verwende den Codevision Compiler. Und ich dachte dieser hat bereits das Workaround für den EEPROM implementiert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.