Hallo ich habe folgendes Problem: meine Platine mit Atmega 328P scheint sich nicht mehr programmieren zu lassen per ISP (USBasp) Zuvor konnte ich problemlos programmieren. GPIO setzen, Softserial zum debuggen und dann die I2C aktiviert. Plötzlich wurde auf der Softserial nichts mehr ausgegeben. und erneutes flashen schlug fehl. Der Atmega wird nichtmal mehr erkannt. Da der USBasp an einem anderen Atmega 328P funktioniert, gehe ich davon aus das dieser in Ordnung ist. Zum flashen nutze ich AVRDUDESS. Meine Vermutung: ich habe irgendwas geflasht/programmiert was meinen Atmega gekillt hat. Bevor ich weitermache wüsste ich natürlich gerne was? Code wurde mit Arduino IDE geschrieben.
:
Bearbeitet durch User
Durch Quelltext lässt sich ein AVR eigentlich nicht so weit verstellen, dass man mit einem ISP nicht mehr draufkommt. Wie sieht deine Schaltung aus und wie hast du die Fuses eingestellt? Der wohl beliebteste Fehler ist das Konfigurieren der Fuses auf einen externen Clock, ohne dass eine solche vorhanden ist. Dann läuft der Controller ohne ext. Clock nicht mehr und lässt sich auch mitm ISP nicht mehr ansprechen.
Angehängte Dateien:
-
ISP.png
19 KB -
schematic.png
8,4 KB -
ISP2.png
17 KB
Schaltung siehe Anhang
Fuses:
Low Fuse = 0xFF
High Fuse = 0xDA
Extended Fuse = 0xFD
So wie es beim Arduino Pro Mini (Atmega328P) sein soll
Außerdem ließ er sich ja bereits programmieren und das mehrmals.
Als Anhng noch die Signale Miso (rot) Mosi (blau) SCK (gelb) bei klick
auf "detect".
Miso sieht doch sehr ungewöhnlich aus. Als wenn der Ausgang nicht
schaltet.
Edit:
Probeweise einen 10k Pullup an Miso gelötet. Signal ist jetzt bei 3,3V
aber wird nicht vollständig auf gnd gezogen.
Miso Pin defekt?
:
Bearbeitet durch User
Es passiert mal, dass man einen Controller himmelt. Aber eigentlich nicht durch Firmware oder den Flashvorgang. Aber ESD z.B. kann schon mal zu Problemen führen. SPI braucht eigentlich keinen Pullup, also könnte wirklich der SPI-Treiber im Controller hinüber sein.
Dann werde ich mal den Atmega ersetzen und neu flashen. Hoffentlich überlebt er dieses mal.
Sebastian R. schrieb: > Durch Quelltext lässt sich ein AVR eigentlich nicht so weit verstellen, > dass man mit einem ISP nicht mehr draufkommt. Doch, bei etlichen Typen geht das durchaus. Teilweise sogar über mehrere Wege. Am gefährlichsten dürfte CLKPR sein, da genügt ein einziger falscher Wert, um das Teil von unfähigen SPI-Programmern/deren unfähigen Benutzern sozusagen abzukoppeln...
c-hater schrieb: > Doch, bei etlichen Typen geht das durchaus. Teilweise sogar über mehrere > Wege. Es geht, aber das ist eigentlich nichts, was man aus Versehen oder unbewusst macht.
Ich habe den Atmeg328P getauscht. Alles wieder in Ordnung. Ich habe erstmal den sketch ohne I2C geflasht. Beide MCU's funktionieren und senden Daten über die Softserial. Sobald ich aber die I2C wieder einkommentiere, bekomme ich nichts mehr auf der Softserial...so hats beim letzten mal auch angefangen. Bevor wieder der MCU kaputt geht lasse ich es erstmal mit der I2C. Zum Verständnis: Auf der PCB sind 2 Atmega 328P verbaut. Die Softserielle wird durchgeschleift. Also USB TX -> MCU1 -> MCU2 -> USB RX I2C wollte ich nutzen und bidirektional zwischen den MCU's daten auszutauschen.
John P. schrieb: > Auf der PCB sind 2 Atmega 328P verbaut. > Die Softserielle wird durchgeschleift. Also USB TX -> MCU1 -> MCU2 -> > USB RX Also das weckt jetzt grad mein Interesse, wie hast du das genau verbunden und was wolltest du damit erreichen.
John P. schrieb: > Sobald ich aber die I2C wieder einkommentiere, bekomme ich nichts mehr > auf der Softserial...so hats beim letzten mal auch angefangen. Sind vllt. aus einem blöden Zufall die Pin-defines die gleichen? Würde aber laut deinem Schaltplan-Ausschnitts kein Sinn ergeben... Oder vllt. bleibt dein µC ja in irgendeinem I2C Interrupt oder Sofwareteil hängen, wodurch der Code für die Softserial nicht mehr zur Ausführung kommt? Hast du mal versucht das Verhalten im Debug-Mode nachzuvollziehen?
:
Bearbeitet durch User
Adam P. schrieb: > Oder vllt. bleibt dein µC ja in irgendeinem I2C Interrupt oder > Sofwareteil hängen, wodurch der Code für die Softserial nicht mehr zur > Ausführung kommt? was ist mit Clockstretching? das soll der I2C nicht beherrschen, es wird ein weiterer Port benötigt um einen hängenden Clock zu erkennen und abzubrechen!
Adam P. schrieb: >> Auf der PCB sind 2 Atmega 328P verbaut. >> Die Softserielle wird durchgeschleift. Also USB TX -> MCU1 -> MCU2 -> >> USB RX > > Also das weckt jetzt grad mein Interesse, wie hast du das genau > verbunden und was wolltest du damit erreichen. Auf der Platine ist ein USB-UART Konverter. USB/UART TX geht an MCU1 RX (PB0) MCU1 TX (PB1) geht an MCU 2 RX (PB0) MCU2 TX (PB1) geht an USB/UART RX in jedem MCU wird alles was auf der Softserial ankommt gleich wieder versendet. Wie ein Echo, nur das es erstmal zum nächsten Empfänger geht. Ich brauche beide Hardserials für andere Sensoren. Daher sind diese belegt. Und der USB/UART Konverter hat bereits 2 UART's Ich wollte mir einen USB zu 4x UART Konverter sparen Die Softserial soll nur zum Debuggen dienen Ein MCU mit 2 Hardserials wurde ausgeschlossen und hier im forum bereits diskutiert.
John P. schrieb: > in jedem MCU wird alles was auf der Softserial ankommt gleich wieder > versendet. das klappt aber nur wenn er nicht im I2C modus hängt!
Joachim B. schrieb: > was ist mit Clockstretching? das soll der I2C nicht beherrschen, es wird > ein weiterer Port benötigt um einen hängenden Clock zu erkennen und > abzubrechen! Bevor ich die Platine fertig gemacht hatte, habe ich die sketches auf 2 Arduino Pro Mini's getestet. Dort liefen sie ohne Probleme. Außerdem erklärt dies nicht warum die Hardware SPI dabei schaden nehmen sollte. Adam P. schrieb: > Sind vllt. aus einem blöden Zufall die Pin-defines die gleichen? > Würde aber laut deinem Schaltplan-Ausschnitts kein Sinn ergeben... Laut define's liegen SDA und SCL auf PC4 und PC5 Die Softserial auf PB0 und PB1 > Oder vllt. bleibt dein µC ja in irgendeinem I2C Interrupt oder > Sofwareteil hängen, wodurch der Code für die Softserial nicht mehr zur > Ausführung kommt? Das wäre ja ok. Erklärt aber nicht die Beschädigung der Hardware SPI > Hast du mal versucht das Verhalten im Debug-Mode nachzuvollziehen? Nein. Geht das mit der Arduino IDE überhaupt?
John P. schrieb: > Nein. Geht das mit der Arduino IDE überhaupt? Hast recht, ne geht nicht.
1 | Wire.beginTransmission(8); // transmit to device #8 |
2 | Wire.write("Master\n\r"); // sends five bytes |
3 | Wire.endTransmission(); // stop transmitting |
4 | delay(500); |
5 | Wire.requestFrom(8, 7); // request 6 bytes from slave device #8 |
6 | |
7 | while (Wire.available()) { // slave may send less than requested |
8 | char c = Wire.read(); // receive a byte as character |
9 | altSerial.print(c); // print the character |
10 | }
|
11 | Wire.endTransmission(); // stop transmitting |
Was ist mit Zeile 5 "Wire.requestFrom(8, 7);" wenn du doch 6 Byte empfangen willst, warum steht da 7? Und vllt versuch das mit der Serial zu trennen. Also nicht in der while(), schieb die Daten lieber in ein Buffer und versenden diese nach dem Empfangen. Falls an der Aussage von Joachim B. etwas dran sein sollte.
:
Bearbeitet durch User
Adam P. schrieb: > Was ist mit Zeile 5 "Wire.requestFrom(8, 7);" wenn du doch 6 Byte > empfangen willst, warum steht da 7? Hatte das mal mit 2 Arduino Pro Mini's aufgebaut. mit "Wire.requestFrom(8, 6);" fehlte immer das letzte Byte. Daher habe ich es einfach auf 7 gesetzt. Habe allerdings auch nicht weiter darüber nachgedacht, da es ja nur ein funktionstest sein sollte. An meinem Code sind sicher noch fehler. Und es kann durchaus sein das sich der Code irgendwo aufhängt und daher keine Daten auf der Softserial ankommen. Aber...als ich das letzte mal versucht habe das Problem zu identifizieren ist die Hardware SPI abgeschmiert und ich konnte nicht mehr flashen. Also MCU runterlöten und neuen drauf. Bevor sich das ganze wiederholt (aus welchen Gründen auch immer) möchte ich erstmal die eigentliche Application schreiben und testen. Halt ohne I2C. Wenn ich dann unbedingt I2C brauche, kann ich ja die Softserial auskommentieren.
:
Bearbeitet durch User
John P. schrieb: > Auf der Platine ist ein USB-UART Konverter. USB auf RS232 oder USB auf TTL Pegel? USB auf RS232 himmelt den Prozessor recht zuverlässig.
Also ich hab das jetzt mal hier nachgebastelt mit einem Nano (atmega328p). Es ist nun so, JA du hast recht, sobalb I2C aktiviert wird, kommt über deine Softserial nix mehr - ABER, der Code läuft, hab ein toggle auf ne LED gemacht. Hab dann mal die Softserial auf D2 und D3 gelegt und siehe da, läuft. Da beißt sich intern etwas.
:
Bearbeitet durch User
Georg G. schrieb: > USB auf RS232 oder USB auf TTL Pegel? > USB auf RS232 himmelt den Prozessor recht zuverlässig. TTL Pegel Verbaut ist ein CP2105 Adam P. schrieb: > Also ich hab das jetzt mal hier nachgebastelt mit einem Nano > (atmega328p). > > Es ist nun so, JA du hast recht, sobalb I2C aktiviert wird, kommt über > deine Softserial nix mehr - ABER, der Code läuft, hab ein toggle auf ne > LED gemacht. Das werde ich auch mal mit dem Arduino Pro Mini machen. Da brauche ich die SPI ja auch nicht zum flashen. Warscheinlich ist das ganze I2C-Softserial-SPI Problem völliger quatsch Das die SPI gehimmelt wurde ist ein Problem Und das die I2C sich nicht mit der Softserial versteht das andere.
Adam P. schrieb: > Hab dann mal die Softserial auf D2 und D3 gelegt und siehe da, läuft. > > Da beißt sich intern etwas. Hm...teilen sich I2C und Softserial vielleicht einen gemeinsamen Interrupt?
John P. schrieb: > Hm...teilen sich I2C und Softserial vielleicht einen gemeinsamen > Interrupt? Nein, jedoch hat die Softserial Klasse ein Debug-Mode in dem Pin 11 (PD7) und 13 (PB1) verwendet werden, aber ich denke kaum das du das aktiviert hast im Code. Sehr merkwürdig. Also auf anhieb finde ich auch nix in dem Code der Klassen was auf eine Überschneidung hindeutet (habs mal kurz überflogen). Vllt. wissen die Arduino-Nutzer mehr.
:
Bearbeitet durch User
Adam P. schrieb: > jedoch hat die Softserial Klasse ein Debug-Mode in dem Pin 11 (PD7) und > 13 (PB1) verwendet werden, aber ich denke kaum das du das aktiviert hast > im Code. Ist bei mir nicht aktiviert. Eventuell mal direkt auskommentieren. Oder mal die AltSoftSerial verwenden. Diese will ja explizit PB0 und PB1 für RX und TX nutzen.
Kleines bisheriges Fazit: Beide Controller funktionieren weiterhin, keine weiteren Probleme mit der SPI oder beim flashen. Zur Softserial: Die habe ich aus beiden controllern auskommentiert. Die zuverlässigkeit ist wirklich mies. Selbst bei 9600 Baud kommt sehr oft nur noch müll an. Vermutlich werden die Timings durch das 2 fache lesen/schreiben total verzerrt. Schade.... Die I2C läuft jetzt auch problemlos. Zum Debuggen sende ich alles über I2C und schreibe es dann auf die SD Karte. Nicht gerade effizient, aber es reicht. Wenn später die Application(en) fertig sind probiere ich nochmal die Softserial zu verbessern.
Hast du auch ein Schaltplan vom ganzen Board mit beiden µC? Denn so richtig verstehe ich deinen Aufbau nicht, bzgl. der UART und USB usw. Mir kommt da eher der Gedanke, dass es evtl. ein falscher Design-Ansatz ist...was die Controller-Kommunikation betrifft. Du sagtest: John P. schrieb: > Also USB TX -> MCU1 -> MCU2 -> USB RX Somit sieht das doch so aus:
1 | USB MCU_1 MCU_2 |
2 | ---- ---- ---- |
3 | | TX | --> | RX | /--> | RX | |
4 | | | | | / | | |
5 | | | | TX | --/ | TX | --\ |
6 | | | ---- ---- | |
7 | | | | |
8 | | RX | <----------------------------/ |
9 | ----
|
Wird von USB auch etwas versendet, oder ist das nur ein Durchschleifen von Debug-Ausgaben an den USB-Serial Adapter. Und für was hast du die Hardware-UART verwendet?
:
Bearbeitet durch User
Adam P. schrieb: > Somit sieht das doch so aus: > USB MCU_1 MCU_2 > ---- ---- ---- > | TX | --> | RX | /--> | RX | > | | | | / | | > | | | TX | --/ | TX | --\ > | | ---- ---- | > | | | > | RX | <----------------------------/ > ---- > > Wird von USB auch etwas versendet, oder ist das nur ein Durchschleifen > von Debug-Ausgaben an den USB-Serial Adapter. Richtig. Genau so sieht es aus. Von USB kann was gesendet werden. Beide MCU's geben die empfangenen Daten auf RX wieder auf TX raus. Wenn ich per USB immer "Hello World" sende... bekomme ich mal "Hello World" ein anderes mal "Hello Wor(komische Zeichen)" und manchmal nur komische Zeichen. Es würde ja funktionieren, aber schön ist anders. Adam P. schrieb: > Und für was hast du die Hardware-UART verwendet? An MCU1 ist ein "Sensor" der mir Daten mit 115200 Baud sendet (zu schnell für SoftSerial) An MCU2 ist die Telemetrie zum Nutzer die mit 100000 Baud arbeitet. (Zeitkritisch)
:
Bearbeitet durch User
Entweder du nimmst eine andere Softserial. Du schreibst alles selbst mit AtmelStudio und hast alles in der Hand. Du hättest lieber ein µC mit 2 UART nehmen können (ATmega1284P). Und das mit deinem ISP Problem, ich hab es gestern auch irgendwie hinbekommen, aber nur weil ich zwischen DebugWire und ISP gewechselt hatte. ATmega1284P hat JTAG :-)
:
Bearbeitet durch User
Ja die sind doch bis auf den PE Port, Pin gleich. Leider fehlen dir dann die Bahnen auf deiner PCB.
Adam P. schrieb: > Entweder du nimmst eine andere Softserial. Will ich noch machen, vorher sind aber andere Dinge dran. > Du schreibst alles selbst mit AtmelStudio und hast alles in der Hand. Ich weiß, aber dafür fehlt mir auch deutlich die Erfahrung mit dem Atmels. > Du hättest lieber ein µC mit 2 UART nehmen können (ATmega1284P). Ich verweise mal auf Stefanus F's Beitrag Stefanus F. schrieb: > Der ATmega328PB hat auch zwei UART Schnittstellen. Richtig, der war auch schon fast im Schaltplan/Layout drin. Für ein Redesign würde ich den auf jedenfall bevorzugen. Mich hat aber folgendes abgehalten: Für den Nutzer gibt es mehrere Telemetrieprotokolle (5 die ich kenne, 2 die ich selber nutze) Für alle Telemetrieprotokolle gibt es Arduino code für den 328P. Leider habe ich es bisher nicht geschafft mal den 328PB (mit entsprechender Hardware Library) auszuprobieren. Das will ich aber noch nachholen.
Adam P. schrieb: > Entweder du nimmst eine andere Softserial. würde ich auch sagen, ich bin ja gerade dabei den genannten Code mit meiner Softserial aus den Beispielen der ArduinoIDE zu vergleichen, die sind verschieden! > Du schreibst alles selbst mit AtmelStudio und hast alles in der Hand. auch eine Lösung
John P. schrieb: > Leider habe ich es bisher nicht geschafft mal den 328PB (mit > entsprechender Hardware Library) auszuprobieren. > Das will ich aber noch nachholen. Sollte aber eigentlich laufen. Dann noch viel spaß :) und vllt. hab ich ja mal langweile, dann schau ich mal was sich da beißt (Softserial & I2C).
Joachim B. schrieb: > ich bin ja gerade dabei den genannten Code mit meiner Softserial aus den > Beispielen der ArduinoIDE zu vergleichen, die sind verschieden! Aber ich konnte nichts erkennen, was auf ein Ausfall deuten würde, sobald I2C aktiviert wird und die main() lief ja auch.
Adam P. schrieb: > ...und vllt. hab ich ja mal langweile, dann schau > ich mal was sich da beißt (Softserial & I2C). zumindest ist sein Soft Tempo 4x höher als das Beispiel in der IDE ohne in den Quellcode geschaut zu haben, mir war so als wenn man das nicht überreizen darf, eigentlich muss das Startbit mehrfach abgetastet werden, aber das war bei Autobauderkennung, trotzdem sollte man in der Mitte vom Bit abtasten und wenn das Bit zu schmal wird? Also Beispiel sagt 4800 Bd und nicht 19200 Bd wer schneller will muss wohl selber Hand anlegen.
Ja das Problem liegt aber auch schon dabei, dass sobald I2C aktiviert wird, versendet der µC erst gar nichts. Im Ablauf ist ja I2C irgendwann fertig auch mit den ISR und erst dann kommt software-technische der Serial Versand. Da beleibt die Software aber auch nicht hängen, so als ob es wirklich gemacht wird, aber irgendwas den Pin daran hindert es auch auszugeben - habe es jetzt noch nicht mit einem LA getestet. Ich werde mal alle Arduino Libs in ein AtmelStudio Projekt laden und es dort mal debugen. Kann auch sein, dass irgendwas die Pin-Config überschreibt. Alles was man im Arduino IDE nicht sieht.
:
Bearbeitet durch User
Joachim B. schrieb: > Also Beispiel sagt 4800 Bd und nicht 19200 Bd > > wer schneller will muss wohl selber Hand anlegen. deswegen habe ich es schon auf 9600 Baud reduziert. Hat geholfen aber eben nicht so das man zufrieden sein kann. Ich hatte hier auch schonmal die Softserial getestet (da gingen 57600 Baud Problemlos) Allerdings nicht mit verketteten MCU's sondern direkt TX/RX mit einem FTDI verbunden. Bei der verkettung der MCU's wird natürlich jedesmal das Timing verzerrt RX MCU1 -> Bytes könnten fehlerhaft eingelesen werden TX MCU1 -> Timing der Bytes eventuell fehlerhaft, und eventuell bereits falshe Bytes im Buffer RX MCU2 -> Fehlerhafte Bytes werden fehlerhaft eingelesen TX MCU2 -> Fehlerhafte Bytes werden noch fehlerhafter gesendet RX USB -> nur noch Fehler ;)
John P. schrieb: > deswegen habe ich es schon auf 9600 Baud reduziert. Hat geholfen aber > eben nicht so das man zufrieden sein kann. ist ja immer noch doppelt so schnell, vielleicht wärst du ja mit 4800 zufrieden?
John P. schrieb: > Zum Debuggen sende ich alles über I2C und schreibe es dann auf die SD Karte. Wie kommst Du von I2C auf eine SD-Karte? Ich kenne die nur mit SPI-Inteface.
Manfred schrieb: > Wie kommst Du von I2C auf eine SD-Karte? Ich kenne die nur mit > SPI-Inteface. Er meint wohl damit: MCU_1 sendet Daten per I2C zu MCU_2, MCU_2 schreibt die Daten dann auf die SD.
Adam P. schrieb: > MCU_1 sendet Daten per I2C zu MCU_2, MCU_2 schreibt die Daten dann auf > die SD. Korrekt ;)
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.