Upload- Probleme

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Upload- Probleme

      Hallo zusammen,

      mich narrt mal wieder ein Controller. Es ist mir zwar gelungen, den Atmega 16 erstmalig zu flashen, Weitere Versuche werden allerdings mit Fehlermeldungen abgebrochen. Programmer hatte ich schon getauscht. Einen Attiny13 kann ich problemlos flashen. Gelegentlich erkennt der Programmer den Atmega nicht sofort, ein Aufrufen der Fusebits geht dann aber, der Chip wird korrekt erkannt. Die Einstellungen für den Programmer sind wie schon immer gesetzt, das gab bisher keinerlei Probleme.

      Hat jemand schon mal vergleichsweise Meldungen gehabt? Ich nicht :(




      Wenn das die Lösung ist, möchte ich mein Problem wieder haben.
    • Du hast deinen Programmer nicht genannt.
      Ich habe mehrere, aus diversen Gründen. Der Atmel AVR MKII funktioniert mit Bascom am besten, zuverlässigsten, Null Probleme.
      Der ist nur relativ groß, hat nur einen 6poligen ISP Stecker. Das STK500 ist sinngemäß uraltes erstes Programiermodell. Auch super zuverlässig,
      aber großvolumig etc.
      Also gibt es noch einen Diamex Programmer, der schön klein ist, zwei übliche ISP Stecker besitzt und einen Taktgeber hat, um (Taktfreq) verfuste MCU wieder ansprechbar
      zu machen. Dieser Diamex soll sich wie ein AVR MKII verhalten, ansprechbar sein. Klappt so einfach unter Bascom nicht. Da erhalte ich sehr ähnliche Meldungen von Bascom.

      Deswegen habe ich zwei Möglichkeiten, je nach Programmer. Direkt aus Bascom mit dem AVRMKII, oder über AVRDUDESS mit dem Diamex.
      Übrigens bietet diese Programmsoftware AVRDUDESS eine Menge an unterstützen Programmern an, ist sehr einfach zu bedienen, nix mehr mit Kommandos, sondern klicks.
      Rein schauen lohnt sich nebenbei auch, denn da sind einige Unterschiede z.B. betreffend STK500 V x Protokol Versionen zu erkennen.
    • Pluto25 schrieb:

      Sicher das es kein Hardware Problem ist? Schlechte Stromversorgung , überlast an den Datenleitungen, Reset Pullup zu klein oder einfach schlechter Kontakt?
      Controller sitzt auf eine Platine in Industriequalität. Reset, VCC,GND,SCK, MOSI und MISO hab ich kontrolliert. Wie geschrieben, lässt sich der Attiny13 auf meinem Experimentierboard mit dem Programmer (hab ich auch schon getauscht) normal flashen. Hab das Ganze nicht nur mit dem Atmega 16, sondern auch mit einem Atmega32 probiert und auch noch mal das Pollinboard rausgekramt, wo ja ein entsprechender Sockel vorhanden ist. "Saft" ist auch genug da.

      Es ist ja nicht so, dass da gar nichts geht. Controller wird richtig erkannt und Fusebits lesen und schreiben geht auch a_56_df238249 .Ein wenig merkwürdig ist das schon a_52_eb39d6ae

      Svenulm31 schrieb:

      125kb ist ungewöhnlich, klappt aber bei dem Tiny (1Mhz)
      Versuch mal 512 oder 1Mb
      Hab ich alles durch. Bislang funktionierte das alles mit meinen Standardeinstellungen
      Wenn das die Lösung ist, möchte ich mein Problem wieder haben.
    • Svenulm31 schrieb:

      125kb ist ungewöhnlich, klappt aber bei dem Tiny (1Mhz)
      Versuch mal 512 oder 1Mb
      Hier ist sicher die Programmierfrequenz gemeint. (Hz statt b)

      Was hängt denn an den Pins?
      Gerne wird ja SPI benutzt, dann muss CS der Slaves natürlich mit einem echtem Pullup auf nicht aktiv gesetzt werden.
      Auch LC-Displays an diesen Pins stören gerne mal.
    • An den Pins hängt erst Mal gar nix. Ein Port fragt später Eingänge ab, ein Port bleibt Reserve und die anderen beiden sollen nur Richtungs- und Schrittimpulse für Treiberbausteine abgeben. Aber dran hängt noch nichts, alle Pins sind nur entsprechend konfiguriert. 100n an Vcc und Gnd ist auch direkt am Controller verbaut.
      Wenn das die Lösung ist, möchte ich mein Problem wieder haben.
    • Also, meine Platine ist neu, aber schließlich nicht meine Erste. ISP- Verbindungen sind in Ordnung und geprüft. Es handelt sich um eine reine I/O- Platine ohne weitere relevante Komponenten.

      Atmega 16 und 32 werden erkannt, Fusebits können gelesen und geschrieben werden. Beim Flashen kommen oben genannte Fehlermeldungen. Ich habe diverse Einstellungen bei den Programmerparametern bereits durchprobiert, final erfolgreich war ich da jedoch nicht.

      Um einen Fehler am Programmer auszuschließen habe ich den schon ausgetauscht. Auch habe ich die griffbereite Platine mit dem Attiny13 geflasht - alles normal wie immer.

      Das Flashen von Atmega 16 und 32 habe ich seinerzeit auch schon mit den Diamex- Programmern gemacht, sollte also auch nicht ursächlich sein.

      Auf der Pollinplatine funktioniert das in gleicher Weise nicht. Daraus schließe ich, dass das Problem nicht von der Platine kommt.

      Die 500 ms, die Mitch genannt hatte zeigten eine gewisse Wirkung. Da ich jedoch wieder nur eingeschränkt Zeit habe, kann ich nicht alles sofort testen.

      Was ich nicht habe, da es bislang nicht notwendig war, ist ein 10k Pullup an Reset. Das wäre etwas, was ich auch noch probieren werde.

      Ich bin aber immer noch zuversichtlich, dass ich das noch irgendwie gelöst bekomme. Ich finde das nach wie vor ungewöhnlich, da ich solche Probleme lange nicht mehr hatte.
      Wenn das die Lösung ist, möchte ich mein Problem wieder haben.
    • Es kommen zwei Möglichkeiten in Betracht. Hardware und/oder Software.
      Da immer vom STK>500 V2 Protokol oder Vorversion die Rede ist, schaun wir doch mal da rein. ;)

      diericx.net/downloads/STK500v2.pdf
      Darin erwähnt werden auch diese unterschiedlichen Timeouts etc. Vorrangig heißt es darin, die Übertragung sollte mit 115200 Baud usw ausgeführt werden.

      Bezug nehemd auf die Hardware, somit auf das Bord namens STK500 hier ein Link mit ausführlicher Dokumentation:
      ww1.microchip.com/downloads/en/DeviceDoc/doc1925.pdf

      Hier verweise ich auf Seite 3-20 in der die Beschaltung des Reset-Einganges beschrieben, und somit auf dem Bord ausgeführt ist.
      Da ist kein 10 K Widerstand, sondern ein 4,7 K verbaut, wird so empfohlen.

      Übrigens, ich musste mit meinem originalen Atmel AVR MKII keine Waits einfügen, keine Timeouts verlängern etc. Funktioniert mit entprechender Einstellung
      in Bascom als entsprechnder Programmer einwandfrei.

      Bitte möglichst die Doku vom STK500V2 Protocol komplett durchlesen, überfliegen. Gegen Ende (ab Seite 33) dürfte einiges interessante zu sehen sein.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von bitlogger ()

    • da kann auch irgendeine Windows Sicherheitsfunktion wieder reinföhnen, Prozessor lesen und fuses dauer ja nicht lange, Program flash schon. Gabs ja früher schon wo man dann alle hintergrundtasks und Virenscanner abschalten musste.
      hängt der Brenner an nem Hub? Probier mal nen anderen port am Pc.
      Ärger mich grad auf der Arbeit mit sowas, kleine Dateien auf USB stick schreiben geht, grosse werden immer langsamer bis zum totalen stillstand. Find das mal wenn alles was irgendwie geht und nützlich währe aus sicherheitsgründen für dich deaktiviert ist :(

      Tobias