Hallo!
Ich habe bei Reichelt 10 Atmega8 bestellt.
auf diesen läuft mein Programm "teilweise" und nicht immer.
Hat Aussetzer.
Mit anderen Atmega8, die ich früher hatte, war alles ok.
Habe jetzt alle 10 geflasht, fuse bits gesetzt wie immer.
Das Problem wiederholt sich immer.
Habe dann einen alten Atmega8 genommen, mit der SELBEN hex-Datei
geflasht (war in PonyProg noch offen), und es läuft alles wie gewohnt.
Was kann das sein?
Auf den neuen µC steht
Atmel 1045
ATMEGA8-16PU
auf dem alten
Atmel 0716I
ATMEGA8-16PU
Stimmt da was mit der Charge nicht, oder was zum Teufel ist da los?
PS: Ich bin mir 100% sicher, dass die Fuses und HEX Dateien die selben
sind.
Tja, konkrete Antwort muß ich dier hier mal schuldig bleiben, aber über
Reichelt liest, hört und erlebt man in letzter Zeit sehr viel Negatives:
Preistreiberei, minderwertige Qualität, ja, sogar Produktfälschungen.
Das alles mit steigender Intensität seit die Bude wohl verhökert wurde.
Ich hatte vor einigen Wochen auch noch ein paar Atmega8 von dort
bezogen, sie aber noch nicht verwendet. Das kann ja eventuell auch bei
mir noch heiter werden.
Dabei komme ich immer mehr zu dem Entschluß, Reichelt mal längere Zeit
zu meiden. Mal sehen wie sich das noch entwickelt!?
Gruß, unikum.
Also, ich konnte noch weitere 3 Atmega8 aus früheren Basteleien
auftreiben.
Ich klicke in PonyProg auf Fusebits (die Einstellung bleibt immer
gleich, sobald man das nicht selbst ändert), dann write.
Danach den Flash Speicher noch füllen.
Tatsache ist, bei ALLEN 3 alten Atmegas geht alles wunderbar, bei ALLEN
10 neuen der selbe Fehler.
Ich kann mir das nicht erklären.
@unikum
Kannst du, bitte schauen, was bei deinen µC Rechts von "atmel" steht?
Danke
Das ist der Datecode, die neuen sind in KW45 2010 hergestellt, die alten
in KW16 2007.
Möglicherweise gibt es neue Chiprevisionen, darüber sollte das jeweils
aktuelle Datenblatt von Atmel sowie das entsprechende zur Revision
gehörende Erratum aufklären.
Das was rechtes von Atmel steht, wird die Chargenummer, oder
Herstelldatum sein. Also mal die Eratas studieren, ob es da mal an für
dein Programm entscheidender Stelle mal ein Problem gab.
Ansonsten könnten natürlich noch "lächerliche" Fehler deinerseits die
Ursache sein: fehlende Resetbeschaltung, Abblock-C's, offene Eingänge,
die vielleicht auf aktiver Interupts gehen, oder sonstwas. Kann durchaus
sein, daß die neuen etwas empfindlicher auf sowas reagieren.
Danke schön!
das hilft mit leider nicht wirklich weiter.
@holger
fast! es ist nicht UART, sondern ISP Kommunikation läuft jedes 3-4 mal
nicht (total sporadisch).
Habe Datenblatt schon durchgelesen, aber nichts dazu gefunden.
Danke
Vielleicht Interupts lost - s. Errata ...
Ansonsten wäre schonmal Layout, Schaltplan und (für die Programmierer
unter uns) der Code (zumindest teilweise) nützlich.
Hallo Mike,
ich muß mich etwas korrigieren. Mein Kauf stammt schon vom November
letzten Jahres, wie doch die Zeit vergeht! Naja.
Der Aufdruck lautet demnach: 1013G
Aber, wie schon hier berichtet ist das ja das Herstellungsdatum. Ob Dir
das was bringt?
Hast Du jetzt schon den Schweinepreis von 3,90 oder so bezahlt?
Gruß, unikum.
Sorry, ich kann mit meinem English das nicht so ganz begreifen:
Interrupts may be lost when writing the timer registers in the
asynchronous timer
Was heisst das? Übersetzen kann ich das, nur Verstehen klappt nicht
ganz.
Ich benutze schon Interrupts, aber keinen Timer im Programm.
Das Programm reagiert auf Interrupt (ein Pin wird gelowert), aber die
SPI Kommunikation findet nicht immer statt (ob komplett fehlt, oder
fehlerhaft ist, weiss ich noch nicht).
Gruss Mike
>@holger>fast! es ist nicht UART, sondern ISP Kommunikation läuft jedes 3-4 mal>nicht (total sporadisch).
Wenn du SPI meinst, dann setz den SS Pin mal auf Ausgang.
Wenn du ISP meinst (Chip programmieren) dann setz die
ISP Frequenz auf 125kHz.
Hallo Mike,
> Habe ich einen "falschen" gekauft?
Nee, Preis scheint in Ordnung. Den anderen Preis hatte ich aus einem
anderen Thema dieses Forums. Da ging`s wohl mehr um einen Mega88. Wäre
aber trotzdem ganz schön happig.
Gruß, unikum.
@holger
Sorry, schreibe leider in Bascom
Config Spi = Hard , Data Order = Msb , Master = Yes , Polarity = Low ,
Phase = 0 , Noss = 1 , Clockrate = 16
Erklärung:
Syntax for hardware SPI
CONFIG SPI = HARD, INTERRUPT=ON|OFF, DATA ORDER = LSB|MSB , MASTER =
YES|NO , POLARITY = HIGH|LOW , PHASE = 0|1, CLOCKRATE = 4|16|64|128 ,
NOSS=1|0 , SPIIN=value
>Wenn du SPI meinst, dann setz den SS Pin mal auf Ausgang.
Warum funktioniert das dann mit den alten µC?
Danke
Gruss Mike
>>Wenn du SPI meinst, dann setz den SS Pin mal auf Ausgang.>Warum funktioniert das dann mit den alten µC?
Die reagieren evtl. nicht ganz so empfindlich wenn
der SS Pin offen und ein Eingang ist. Meine Erfahrung
mit offenem SS Pin: Einmal mit der Hand zu nah an die Schaltung
und SPI ist tot. Handy daneben reicht auch schon. Reines Glücksspiel;)
Wichtig ist der /SS-Pin, er muß vor dem SPI-Kram als Ausgang gesetzt
werden!
Wenn das SPI scheinbar hängt, wurde es durch nen floatenden /SS-Pin in
den Slavemode gesetzt.
Peter
ja, die unbeschalteten Pins sind ganz am Anfang des Programms (als
erstes nach der µC Konfiguration) als Ausgänge gesetzt.
Ich kann mir schon vorstellen, dass es am Programm liegen könnte, aber
das hat doch schon früher so IMMER funktioniert, und ich habe viele von
diesen Platinen gebaut. Mit der selben Belichtungsvorlage usw.
Danke
Gruss Mike
Laut Speck und laut Bascom-Doku muss man den SS im Hardware-Master-Modus
selber(!) setzen - ggf. aus Ausgang oder wenigstens per Pullup
festhalten. Wenn der SS im Mastermodus Input ist und Low geht, dann geht
der SPI in den Slavemodus [1]:
1
Serial Peripheral Interface – SPI
2
[..]
3
/SS Pin Functionality
4
[..]
5
Master Mode
6
[..]
7
If /SS is configured as an output, the pin is a general output pin which
8
does not affect the SPI system. Typically, the pin will be driving the /SS
9
pin of the SPI Slave.
10
If /SS is configured as an input, it must be held high to ensure Master SPI
11
operation. If the /SS pin is driven low by peripheral circuitry when the SPI
12
is configured as a Master with the /SS pin defined as an input, the SPI
13
system interprets this as another Master selecting the SPI as a Slave and
14
starting to send data to it. To avoid bus contention, the SPI system takes
15
the following actions:
16
1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. As a
17
result of the SPI becoming a Slave, the MOSI and SCK pins become inputs.
18
2. The SPIF Flag in SPSR is set, and if the SPI interrupt is enabled, and
19
the I-bit in SREG is set, the interrupt routine will be executed.
>fast! es ist nicht UART, sondern ISP Kommunikation läuft jedes 3-4 mal>nicht (total sporadisch).
Was passiert denn da? Kompletter Hänger oder Daten falsch?
Meinst du wirklich ISP oder SPI?
Beim Atmega88 vom Reichelt (ähnliches Herstellungsdatum) habe ich in
letzter Zeit ähnliche Fehler gehabt: Haben sich nicht richtig
programmieren lassen bzw. nur immer einmal pro Strom-aus-Strom-an.
Programmer war ein Dragon, also nix bastelei oder so ;-)
@g457
Danke für Deine Mühe, aber ich denke nicht, dass es das Problem ist.
Link:
http://avrhelp.mcselec.com/config_spi.htm?zoom_highlightsub=SPI%2Bconfig
Hier noch mal meine SPI Konfiguration:
Config Portb.2 = Output
........
Config Spi = Hard , Data Order = Msb , Master = Yes , Polarity = Low ,
Phase = 0 , Noss = 1 , Clockrate = 16
"NOSS = 1 or 0. Use 1 when you do not want the SS signal to be generated
in master mode."
@holger
Nein, kein kompletter Hänger des µC/Programms
Der µC sendet gelegentlich die GLEICHEN Daten per SPI an einen anderen
IC.
Der Empfänger reagiert manchmal auf die Daten nicht.
Das heisst wenn es 1 mal pro minute eine 8 Byte-lange Nachricht gesendet
werden soll, kann das sein, dass es einmal (angenommen nach 5 minuten)
nicht ankommt, dann gehts aber weiter, dann fehlen wieder die Daten.
Kann jetzt leider nicht sehen, ob der SPI komplett nicht sendet, oder
"Müll" sendet.
DAnke
Gruss Mike
>Der µC sendet gelegentlich die GLEICHEN Daten per SPI an einen anderen>IC.>Der Empfänger reagiert manchmal auf die Daten nicht.
Programmfehler oder Schaltungsfehler.
Viel Spass beim suchen;)
Habe gerade 3 µC, mit den es funktioniert (seit Monaten in Betrieb, kein
Aussetzer). Und 10 neue m8, mit den es nicht funktioniert.
Wenn ich aus dem alten m8 das programm auslese, dann den neuen m8
einsetze und das Ganze vergleiche, dann sagt Pony "Verify successful".
Das kann doch nicht sein, oder?
Danke
Gruss Mike
Was willst du erwarten es ist ein ATMEL :)
Nein, Spass beiseite. Ich wuerde nochmal gezielt darauf schauen, was
sich in der Zeit am Chip getan hat (Erratas, Silicon Revisions). Es kann
ja durchaus sein, dass du irgendwo in nem Randbereich arbeitest, was bei
dem alten Kontroller funktioniert hat. Der neue ist aus irgendwelchen
Gruenden empfindlicher, Atmel hat aber beispielsweise die ganzen Werte
nicht nochmal extra geprueft (oder geaendert und weist nicht explizita
daruaf hin). Ich kann mir naemlich nicht vorstellen, dass das ein Fehler
von Reichelt ist.
Hallo,
also ich kenne dieses Problem! Bei uns funktionierten ALLE Atmega8 mit
einem "G" so wie von TE beschrieben eben NICHT. Ich kann das Problem
nicht eingrenzen. Ich habe viele ältere Atmega8 getestet (gar kein
Buchstabe hinter dem Datumscode, I oder N ...) Egal welche, alle
funktionieren so wie es erwartet wird. Nur die mit "G" wollten irgendwie
nicht richtig.
Unser Programmierer hat dann das Program grundlegend überarbeit und nun
funktioniert es mit jedem Chip. Leider kann er auch nicht sagen welche
Änderung das nun bewirkt hat.
Also ich konnte zwar nicht helfen aber zumindest die Beobachtung von
Mike bestätigen...
grüße
Andreas schrieb:> Unser Programmierer hat dann das Program grundlegend überarbeit und nun> funktioniert es mit jedem Chip. Leider kann er auch nicht sagen welche> Änderung das nun bewirkt hat.
Also eben Software Fehler....
Jan S. schrieb:> Andreas schrieb:>> Unser Programmierer hat dann das Program grundlegend überarbeit und nun>> funktioniert es mit jedem Chip. Leider kann er auch nicht sagen welche>> Änderung das nun bewirkt hat.>> Also eben Software Fehler....
Nicht unbedingt!
Kann auch bedeuten: Hardwarebug in der neuen µC Revision Umschifft!
Wenn ich das so lese dann weiß ich schon warum ich häufiger PICs
einsetze. Wenn ich da einen Baustein bestelle bekomme ich auch genau
denselben Baustein wie seit Jahren... Die neuen Revisionen werden am
Namen kennlich gemacht -
Das kann ganz schön nervig werden wenn sich die µCs einer Serie
unterschiedlich verhalten und man nur irgendwie anhand des Datecodes
nach erhalt schätzen kann was man genau in den Händen hat! Vorzugsweise
in kritischen Projektphasen tritt soetwas dann auf.
Daher sollte es eigendlich ein No-go sein funktionsverschiedene
Versionen zu haben die man bei der Bestellung nicht auseinanderhalten
kann.
Gruß
Carsten
Ich habe von Atmel nicht den Eindruck, das Hardware Bugs verschwiegen
werden.
Und funktional unterschiedliche Versionen der AVRs wurden bislang auch
mit neuen Bezeichnungen gekennzeichnet.
Ich muss meine Behauptung allerdings auf Software- oder
Hardwaredesignfehler ändern.
Es gibt ne Menge Fehler im Platinenlayout, welche man durch eine
Softwareänderung noch umschiffen kann. Z.B.:
Langsameres Timing bei Leiterbahnen mit zu hoher Kapazität oder
Induktivität.
Nicht mehrere Pins zeitgleich schalten, wenn man Ground-bounce hat.
Da gibts so einiges was man tun kann...
Carsten Sch. schrieb:>> Also eben Software Fehler....>> Nicht unbedingt!
Aber sehr wahrscheinlich.
Gerade das SPI-Interface hat sich seit einem Jahrzehnt praktisch nicht
mehr geändert.
Carsten Sch. schrieb:> denselben Baustein wie seit Jahren... Die neuen Revisionen werden am> Namen kennlich gemacht -
ähm... nein.
> Daher sollte es eigendlich ein No-go sein funktionsverschiedene> Versionen zu haben die man bei der Bestellung nicht auseinanderhalten
vielleicht sollte man aber auch einfach nur den eigenen fehler in der
eigenen software finden?
Ich würd mal an den /SS-Pin (PB2) nen Pullup 1k ranpappen.
Wenns dann geht, stimmt doch was mit der Init-Reihenfolge nicht oder er
wird zwischendurch mal floatend gesetzt.
Dann kannst Du noch nen Gegentest mit den alten M8 machen, d.h. einen 1k
Pulldown an /SS und auch die alten gehen nicht mehr.
Daß sich verschiedene Chargen bei nem floatenden Pin unterschiedlich
verhalten, liegt an den Leckströmen und ist kein Bug.
Peter
Hi, Leute!
Also, ich habe jetzt ein 470 Ohm Pull-up nach SS (PB2) gelegt.
Der Fehler ist fast! weg.
Kommt nur noch selten vor.
Also vielen Dank an Alle, speziel an Peter!
Habe jetzt noch mal den alten m8 eingesetzt, und eine Weile lang
beobachtet. Damit kommt der Fehler definitiv NICHT vor.
Was kann es denn noch sein?
Danke
Gruss Mike
>Also, ich habe jetzt ein 470 Ohm Pull-up nach SS (PB2) gelegt.>Der Fehler ist fast! weg.
Buuuuuaaaaah. Sag mal hast du sie noch alle?
Schalte den Scheiss Pin auf Ausgang. Dann brauchst du
keinen Pullup.
Die Reihenfolge zum initialisieren:
SS Pin auf Ausgang.
Danach das SPI Modul initialisieren und gut iss.
>SS Pin auf Ausgang.>Danach das SPI Modul initialisieren und gut iss.
So habe ich das auch gemacht.
Habe doch oben schon geschrieben.
>Also alten Mega8 und Pulldown?
Habe ich gerade probiert.
Alte und neue m8 senden trotz Pull-down.
Weil der pin eben vorher als Ausgang definiert ist.
Dann verstehe ich aber nicht, warum der Pull-up eine Besserung bringt?
Gruss Mike
>Hmm, zeig' doch mal die Schaltung dazu ...
Hätte ich schon längst gemacht, aber ich habe die nicht. Ich meine die
Schaltung existiert (noch) nicht "auf Papier"
Gruss Mike
Mike schrieb:> Hätte ich schon längst gemacht, aber ich habe die nicht. Ich meine die> Schaltung existiert (noch) nicht "auf Papier"> Gruss Mike
das ist normalerweise das erste was man macht.
Auch bei Lochraster kann man so doch das Layout wenigstens planen, dass
möglichst wenig drähte verlötet werden müssen.
Außerdem reicht da auch nach Jahren ein Blick drauf und man sieht wie
alles zusammenspielt, ohne irgendwelche Gehäuse zu öffnen und ewig
verworrene Drähte durchzumessen.
Es Programmiert sich doch auch einfacher, wenn man auf einen Blick
sieht, wo was dranhängt.
Mike schrieb:>>Hmm, zeig' doch mal die Schaltung dazu ...> Hätte ich schon längst gemacht, aber ich habe die nicht. Ich meine die> Schaltung existiert (noch) nicht "auf Papier"
Dürfte kaum länger als 'ne Viertelstunde dauern, die mit 'nem Stift auf
Karopapier zu malen, wo also ist das Problem?
