ich arbeite seit geraumer Zeit mit einem Arduino UNO und einem CAN-BUS Shield. Da mir der UNO mit dem Shield zu gross ist, und die Anschlüsse nicht perfekt passen, entschied ich mich für das Erstellen einer eigenen Platine.
Beim Schema orientierte ich mich am Arduino Pro Mini und dem CAN-Bus Shield selbst. Anbei findet Ihr das Schema.
Da ich keinen Platz für die SPI Schnittstelle für das uploaden des Bootloaders auf dem Board selbst opfern wollte, erstellte ich eine weitere Platine, mit der ich den neuen 328p Chip mit dem Bootloader und einem Blink Programm programmieren kann. Dabei wird der 328p (TQFP) auf die Platine gepresst. Dies funktioniert auch soweit gut. Dabei verwendete ich den Bootloader vom Arduino Pro Mini.
Auf dem CAN-Bus Board habe ich jetzt aber das Problem, dass ich den 328p nicht direkt über USB programmieren kann. Auf dem Board verwende ich einen FTDI Chip. Das Board an sich funktioniert ansonsten wunderbar. Das Blink Programm funktioniert und auch eine Serielle Ausgabe von 328p über den FTDI Chip zum Computer funktioniert ebenfalls. Jedoch kommt folgende Fehlermeldung wenn ich direkt aus der Arduino IDE das Board programmieren will:
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : COM17
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x9c
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xad
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x0f
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xbf
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xed
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x0a
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x9c
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xac
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x0d
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xbf
avrdude done. Thank you.
An error occurred while uploading the sketch
Da diese Fehlermeldung oft mit einem nicht funktionierenden Auto-Reset zusammenhängt, habe ich einen normalen Taster dazu gelötet. Leider ohne Erfolg.
Lötstellen habe ich alle kontrolliert. Zudem habe ich auch alles durchgepiepst. Das Board habe auch zweimal aufgebaut, bei beiden das gleiche Problem.
Wisst ihr noch einen möglichen Grund, warum ich den 328p nicht über USB programmieren kann? Ich möchte dies zuerst erfolgreich testen, bevor ich den 328p fix verlöte.
"Da ich keinen Platz für die SPI Schnittstelle für das uploaden des Bootloaders auf dem Board selbst opfern wollte, ..."
Genau das ist jetzt dein Problem. Den Fehler machst du hoffentlich nur einmal.
Man benötigt zum flashen des Bootloaders die SPI/ISP Pins. Über Serial geht das nicht.
Wo sind die bei dir während des flashens SPI/ISP angeklemmt?
Dein gezeigtes Board ist für mich nur ein USB-Serial Wandler mit Zusatzfunktionen.
Aber nicht zum flashen eines nackten ATmegas geeignet.
"Da ich keinen Platz für die SPI Schnittstelle für das uploaden des Bootloaders auf dem Board selbst opfern wollte, ..."
Genau das ist jetzt dein Problem. Den Fehler machst du hoffentlich nur einmal.
Für das nächste Layout werde ich dies sicherlich nochmals überdenken. Dazu eine zwischen Frage: Der CAN-Controller kommuniziert ebenfalls über SPI mit dem 328p. Kommen sich dieser und die Programmierung dann nicht einander in die Quere?
Anstelle des FTDI-Chips hättest du besser den ISP-Steckplatz und einen UART-Steckplatz vorsehen sollen.
Damit wäre dein Board sehr viel flexibler.
Da bin ich der gleichen Meinung. Aber ich hatte neben dem Grund für ein möglichst kleines Board auch die Bedenken mit dem CAN-Controller.
Zudem verwende ich Arduinos schon seit einigen Jahren. Ich bin mir den "Luxus" gewöhnt, direkt über USB den Arduino zu programmieren ohne dafür noch einen zusätzlichen Programmer zu verwenden.
Weiter ist der Bootloader ja schon auf dem Chip drauf. Dafür habe ich ja extra eine Platine erstellt (Bild im Anhang). Der Bootloader wie auch das darauffolgende geflashte Programm läuft ja auch einwandfrei. Auch auf meinem CAN-Bus Board. Da ein digitaler Ausgang sowie die serielle Ausgabe funktioniert, glaube ich nicht das was mit dem Bootloader selbst falsch ist oder mit dem FTDI Chip.
Jedoch bin ich mir bei folgendem nicht sicher:
-Ist der Arduino Pro Mini der richtige Bootloader für mein Projekt?
Der Pro Mini kann ja ebenfalls über einen FTDI-Adapter programmiert werden. Was kann ich sonst noch untersuchen, um dem Fehler auf die schliche zu kommen? Bin für jeden weiteren Input dankbar.
Ah das geht so einfach? Würde ein 10k Wiederstand passen?
Bezüglich meines Upload-Problems:
Der Reset scheint zu funktionieren. Ich gebe millis() auf der seriellen Schnittstelle aus und dieser setzt sich nach einem Upload-Versuch auch wieder auf Null zurück.
Jedoch habe ich bemerkt, dass die Fehlermeldung nicht immer identisch ist:
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : COM17
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x9c
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xad
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x0d
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xbf
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xed
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x58
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x59
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xad
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x85
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x9c
avrdude done. Thank you.
Dazu ist zu sagen, dass diese 10 Versuche in unter einer Sekunde durchlaufen.
Was bedeutet diese Hex-Zahl am Ende jeder Zeile?
ich dachte du kannst den Bootloader nicht flashen. Okay, dann verhält sich das etwas anders.
Also Bootloader ist drauf aber jetzt kannst du nicht wie gewohnt den "Arduino" über USB programmieren?
Mach mal folgendes:
In der IDE alle Compilerwarnungen einschalten.
Datei > Voreinstellungen >
Ausführliche Ausgabe während > beide Haken rein
Compilerwarnungen > "ALLE"
Zeilennummern und Codefaltung sind auch hilfreich.
Dann zeigste alles was ausgegeben wird und dir wird sicherlich geholfen.
PS: SPI Geräte können "tausende" am Bus hängen. Das /CS Signal entscheidet welches Gerät angesprochen wird. Der /CS Ruhepegel hat immer "High".
Edit:
Was mich beim lesen aber immer wieder durcheinander bringt ist folgender Satz.
"Der Bootloader wie auch das darauffolgende geflashte Programm läuft ja auch einwandfrei."
Das bedeutet du konntest alles korrekt flashen. Nur warum gehts dann plötzlich nicht mehr? Die letzte Aktion war doch einen Sketch erfolgreich zu flashen? Wie hast du das gemacht?
du darfst. Genau das ist auch meine stille Vermutung.
Ansonsten müßte freesmile nochmal in kurzen knackigen Stichpunkten sagen was er wie genau in welcher Reihenfolge gemacht hat. Ohne großes textliches Gedöhns drumherum. Und eben die komplette IDE Ausgabe des Flashversuches.
Per ISP und damit den Bootloader natürlich wieder platt gemacht.
Genau so ist es
Habe nun nur den Bootloader per ISP geflasht und dann den 328p auf das neue Board gepackt und dann von dort über den FTDI Chip das Programm hochgeladen. Jetzt funktioniert der Upload auch über USB auf anhieb
Ich bin irgendwie davon ausgegangen, dass der Bootloader in einem anderen "Bereich" geflasht wird als das eigentliche Programm selbst. Das ich den Bootloader überschreibe, wenn ich ein Sketch per ISP hochlade, war mir nicht bewusst.
Ohne eure Hilfe wäre ich nie darauf gekommen. An alle vielen herzlichen Dank für eure kompetente Unterstützung.
Tolles Forum, in unter 24h die Lösung zu meinem Problem gefunden. Wenn ihr wüsstet, wie lange ich zuvor daran herumstudiert und probiert habe :
wenn es dich tröstet, den gleichen Denkfehler hatte ich zu Beginn auch gehabt. Macht man einmal und merkt sich das für immer. Danke für die Rückmeldung und schön das es nun funktioniert.
Ja, das ist ja auch der Vorteil des Flashen über ISP: dadurch, dass dann der Bootloader weg ist, hast Du mehr Programm-Platz auf dem Chip, und der Start ist auch noch etwas schneller, da nicht erst der Bootloader startet um zu schauen, ob grad was programiert werden soll.
Und flashen über ISP geht in aller regel auch dann, Wenn noch etwas an SPI dranhängt. Das einzige , was probleme bereiten kann, sind Kondensatoren (besonders Elkos) an SCK, MISO und MOSI (wenn mann z.B diese Pins in der eigenen Schaltung für was anderes als SPI nutzt).
Ich hatte dieses Problem mal bei nem ATTINY , da ich da die SPI-Pins nur während der Programmirung als SPI nutzte, und ansonsten als normale Pins nutzte. Einer diese war als PWM in gebrauch und da hatte ich nen Elko drann, um ne Analoge Spannung zu erzeugen. Da hat dann das Programieren per ISP nicht mehr funktioniert, solange der Elko drin war.
Da das ganze aber erst im Experimentieraufbau war, also Platine noch nicht erstellt, war das kein Problem zu ändern.
wenn man über ISP flashen muss mit angeschlossener Beschaltung, dann kann ich dir eine Lösung des Problems mitgeben. Man nehme einen 4053 und baut sich eine ISP Pin Umschaltautomatik. Das Resetsignal steuert alles. Man muss sich um nichts kümmern. Schon mehrfach aufgebaut, keine Probleme. Auszug vom Schaltplan.
Deltaflyer:
Ja, das ist ja auch der Vorteil des Flashen über ISP: dadurch, dass dann der Bootloader weg ist, hast Du mehr Programm-Platz auf dem Chip, und der Start ist auch noch etwas schneller, da nicht erst der Bootloader startet um zu schauen, ob grad was programiert werden soll.
Nur muss man dazu auch die Fuses anpassen,sonst droht der nächste Pferdefuß, dich zu küssen.
Danke Doc_Arduino,
nur wäre dafür auf meinem Endsystem nicht auch noch Platz genug gewesen.
Ich hatte da 3 Attinys, die Spannungsstabilisierung , 7 3A Fets, Steckanschlüsse und noch etwas Hünerfutter auf ner Fläche von 20 x 27 mm (doppelseitig bestückt) drauf. War, da ich wegen der Ströme auch teilweise dickere Leiterbahnen benötigte wirklich hart an der Grenze mit dem Platz. wär nur dann möglich gewesen noch mehr drauf zu packen, wenn ich kliener Widerstände als 603er Baugrösse genommen hätte. Aber da wärs dann mit dem verbauen von Hand für mich unmöglich geworden.
Hier war das Problem, dass der Einbauort vorgegeben und da einfach nicht mehr Platz vorhanden war.
Genau das ist auch meine stille Vermutung.
