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 Problem wiederholt sich immer.
Welches Problem? Datenübertragung per UART klappt nicht?
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.
vielleicht ist ja auch einfach die schaltung so grottenschlecht, dass sie den armen avr eh schon über die spec-grenzen hinaus betreibt...
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
@unikum ich habe 2,27 bezahlt. Artikel-Nr. ATMEGA 8-16 DIP Habe ich einen "falschen" gekauft? Kaufdatum: 02.02.11 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;)
achso, das meinst du! ALLE unbeschaltete Pins sind von Anfang an als Ausgänge definiert. Daran liegt das dann nicht. hm.... Gruss Mike
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. |
20 | [..] |
Einfach mal testen, koscht ja nüscht. HTH [1] aus: Datenplatt vom m8 http://www.atmel.com/dyn/resources/prod_documents/doc2486.pdf Seite 129
>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
Mike schrieb: > Das kann doch nicht sein, oder? richtig... darum: holger schrieb: > Programmfehler oder Schaltungsfehler.
Ok, danke ... Falls noch Jemand eine Idee hat, bitte schreiben. 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.
@ Mike Das würde mich jetzt auch mal interessieren: Hast Du schon die Gegenprobe lt. Peters Empfehlung gemacht? Also alten Mega8 und Pulldown?
>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
Mike schrieb: > Dann verstehe ich aber nicht, warum der Pull-up eine Besserung bringt? Hmm, zeig' doch mal die Schaltung dazu ...
>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?
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.