ATXMEGA Revision herausfinden

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.

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

Und was mache ich wenn die Revisionen beide gleich sind :-)

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

Da trinke ich doch lieber ein Soda :-)

Im AVR Studio gibt es keine Möglichkeit

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?

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.

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.