Hallo zusammen, Ich bin der Dirk und sammle grad Erfahrungen in der Programmierung eines Microcontrollers. Mein Vorhaben war, mir Sensoren fürs Smarthome selber zu bauen. Dazu musste ich auf dem atmega328 die fuses setzen, was ich mittels avrdude und diesem Befehl getan habe: avrdude -p m328p -P usb -c usbasp -B 10 -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0xFF:m -U lock:w:0xFF:m Die frage von avrdude, ob ich die fuses ändern wolle bestätigte ich 3x mit yes und ich bekam einer Erfolgsmeldung. Nun wollte ich die Firmware mit Bootloader flashen, die ich mittels Webbrowser aus diesem Github erstellt habe. https://github.com/pa-pa/HB-Sec-RHS-3/tree/master/firmware Ich wurde ebenfalls gefragt, ob die fuses gesetzt werden sollen, was ich wieder bestätigt habe. Erneut wurde Erfolg von avrdude gemeldet. Leider startet die Platine aber nicht, kein Lebenszeichen. Wenn ich versuche erneut zu flashen, bekomme ich diese Ausgabe: C:\Users\Asus>avrdude -p m328p -P usb -c usbasp -B 10 -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0xFF:m -U lock:w:0xFF:m -F avrdude: set SCK frequency to 93750 Hz avrdude: error: program enable: target doesn't answer. 1 avrdude: initialization failed, rc=-1 avrdude: AVR device initialized and ready to accept instructions avrdude: Device signature = 0x743430 avrdude: Expected signature for ATmega328P is 1E 95 0F avrdude done. Thank you. Ist da noch was zu retten? Laut meinen Recherchen habe ich die fuses wohl falsch gesetzt, was ich aber ehrlich gesagt nicht nachvollziehen kann. Bin wie gesagt blutiger Anfänger was das programmieren angeht, deshalb sind Begriffe wie „mit externem Quarz wiederbeleben“ auch böhmische Dörfer für mich :-) Ich kann nicht abschätzen, ob da noch was zu retten ist und wieviel Aufwand das ist. Wäre evtl hier jemand an Bord der mir helfen, bzw gegen Bezahlung den Atmega zu retten? Gruß Dirk
Dirk G. schrieb: > C:\Users\Asus>avrdude -p m328p -P usb -c usbasp -B 10 -U lfuse:w:0xE2:m > -U hfuse:w:0xD0:m -U efuse:w:0xFF:m -U lock:w:0xFF:m -F Damit setzt du doch nur die Fuses. Hast du das Hex-File aufgespielt, wie es im Git steht: avrdude -p m328p -P usb -c usbasp -V -U flash:w:SAVEDFILE.hex Was sagt avrdude dabei?
Dir würde ich raten: Mit dem Datenblatt und dem https://www.engbedded.com/fusecalc/ herausfinden welchen Mist du da gebaut hast. Und dann eben mit externem Takt versuchen oder die letzte Rettung HVPP wählen. Wenn du eine kleine Schachtel voll hast, könntest du sie mir schicken und ich nudele sie durch den FuseBitDoctor Dirk G. schrieb: > auch böhmische Dörfer für mich :-) Ist natürlich doof, wenn man nicht weiß was man da tut. Aber da das keine Geheimwissenschaft ist, kann man sich da einarbeiten. Tu du das.
Arduino Fanboy D. schrieb: > Mit dem Datenblatt und dem https://www.engbedded.com/fusecalc/ > herausfinden welchen Mist du da gebaut hast. Ich hatte das auch schon geprüft, scheint OK zu sein. Interner RC mit 8MHz, da nützt der externer Quarz ja auch nix... falls er gar kein Zugriff mehr auf die Fuses hat. Aber die Ausgabe mit der Signature find ich komisch.
:
Bearbeitet durch User
Die Fehlermeldung beim flashen der hex Datei hänge ich an, wenn ich nachher am Rechner bin. Ich habe die Befehle aus dem Github übernommen, so wie es in der Anleitung steht.(Dateinamen natürlich angepasst). Die Befehle funktionieren ja bei anderen Usern. Allerdings habe ich das ja von Windows aus gemacht, avrdude und Windows scheinen ja nicht die besten Freunde zu sein. Wollte heute Abend nochmals mittels Raspi das ganze probieren. Kann es auch ein Windows Treiberproblem sein?
Sieht für mich eher nach schlechter Verbindung, vulgo Wackelkontakt,
zwischen Programmiergerät und Zielplatine bzw. auf dieser selbst aus:
> avrdude: Device signature = 0x743430
Dirk G. schrieb: > avrdude und Windows > scheinen ja nicht die besten Freunde zu sein. Oha... Gut, dass das meinem avrdude und Windows noch keiner gesagt hat! Denn die gehen schon seit Jahren zusammen auf eine Platte. Quasi Byte an Byte.
Ich hatte mal ein falsches Programm auf einen AVR geladen. Dadurch stürzte er so gründlich ab, dass danach sogar die ISP Schnittstelle tot war. Ich konnte das Problem beheben, indem ich den /Reset-Pin fest mit GND verband und dann erst die Stromversorgung anlegte. Dadurch startet das Programm nicht. Der ISP Programmer konnte danach problemlos auf den Chip zugreifen. Eigentlich sollte ein ganz normaler Reset (durch den ISP Programmer ausgelöst) genügen.
Beitrag #6340291 wurde von einem Moderator gelöscht.
Dirk G. schrieb: > C:\Users\Asus>avrdude -p m328p -P usb -c usbasp -B 10 -U lfuse:w:0xE2:m > -U hfuse:w:0xD0:m -U efuse:w:0xFF:m -U lock:w:0xFF:m -F Beitrag "Re: Timing-Problem" Immer wieder lustig. Und SCNR.
Weder "lustig" noch "kryptisch" - wer uCs programmieren will, muss ein Datenblatt lesen und mit Hex-Zahlen sowie Bitpositionen umgehen können.
S. Landolt schrieb: > Weder "lustig" noch "kryptisch" - wer uCs programmieren will, muss ein > Datenblatt lesen und mit Hex-Zahlen sowie Bitpositionen umgehen können. Nein, er muß richtig ERRATEN können, was der Unterschied zwischen: -external Clock -external low Frequency Oscillator - low Frequency Crystal - high Frequency Crystal sein soll!
S. Landolt schrieb: > Weder "lustig" noch "kryptisch" - wer uCs programmieren will, muss ein > Datenblatt lesen und mit Hex-Zahlen sowie Bitpositionen umgehen können. Wie gut das es Menschen gibt die das schon gleich nach der Geburt konnten. Wo wären wir bloß Heute?
Dirk G. schrieb: > Die Fehlermeldung beim flashen der hex Datei hänge ich an, wenn ich > nachher am Rechner bin. Also ich hab bei meinem Nano jetz ein neuen 328P draufgemacht (um es mal selbst zu testen). Könntest du mir dann später auch mal deine erstellte Hex-Datei hochladen? Weiß ja nicht was du da genau erstellt hast...dann könnte ich es mal selbst versuchen um da ein Fehler auszuschliessen. S. Landolt schrieb: > Sieht für mich eher nach schlechter Verbindung, vulgo Wackelkontakt, > zwischen Programmiergerät und Zielplatine bzw. auf dieser selbst aus: >> avrdude: Device signature = 0x743430 Das könnte natürlich auch sein, einmal tuts und dann wieder nicht.
Dirk G. schrieb: > Die frage von avrdude, ob ich die fuses ändern wolle Das ist schon mal ein sehr schlechtes Zeichen: diese Frage kommt nur dann, wenn AVRDUDE (bzw. der Programmer) andere Werte für die Fuses vorfinden als die, die eigentlich gesetzt werden soll(t)en. Wenn sich aber dort "on the fly" etwas ändert, dann ist an dieser Stelle hochgradig was foul – und vermutlich eigentlich schon zu spät. Historischer Hintergrund: Diese ganze Geschichte mit der Rückfrage stammt aus einer Zeit, als der übliche Billigprogrammierer noch am Parallelport eines PCs hing und einfach mit ein paar Drähten an den AVR-Pins herum gewackelt hat. Diese Konstruktionen waren teilweise etwas fehleranfällig, weshalb es gelegentlich zu Bitfehlern kam. Wenn ein solcher Bitfehler nun beim Schreiben der Fuses auftrat, hatte das u.U. katastrophale Folgen ("gebrickter" Chip). Daher stammte die Idee, dass man noch innerhalb der gleichen ISP-Sitzung (die ja in dem Moment erstmal noch funktioniert) ggf. die Fuses nochmal erneut schreibt. Moderne Programmer haben dieses Problem aber nicht mehr, weshalb dieser ganze "safemode"-Kram dort an sich überflüssig ist. Im vorliegenden Fall zeigt er aber wohl an, dass der gesamte Aufbau ein Problem dergestalt hat, dass das Ergebnis der Programmierung nicht stabil ist. Vermutlich hat dir das AVRDUDE anfänglich schon dadurch angezeigt, dass es die Signatur gar nicht richtig lesen kann. An der Stelle würde es eigentlich aufhören, aber du hast ihm gesagt: "Ich bin hier Experte, mach, was ich sage!", indem du diesen Test mit der Option -F überschrieben hast. Nicht ganz unwahrscheinlich, dass du jetzt Fuses irgendwie gesetzt hast. Du kannst versuchen, eine Takt an XTAL1 einzuspeisen (üblich ist da 1 MHz) in der Hoffnung, dass er damit wieder einen für das ISP erforderlichen Takt erhält. Auf jeden Fall solltest du deinen Aufbau überprüfen. Meine Vermutung: dir fehlen die notwendigen Stütz-/Abblock-Kondensatoren an der Betriebsspannungsleitung. Übrigens setzen deine Fuses den Reset-Vektor auf den Bootloader-Bereich, obwohl du offensichtlich gar keinen Bootloader installieren willst …
:
Bearbeitet durch Moderator
Angehängte Dateien:
Das ist die Fusekonfiguration bei einem echten Pro Mini Clone (3.3V). Falls jemand braucht.
Jörg W. schrieb: > obwohl du offensichtlich gar keinen Bootloader installieren willst … Doch, den OTA Loader. Selbst ein Link dahin findet sich Startbeitrag.
> Historischer Hintergrund: Diese ganze Geschichte mit der Rückfrage > stammt aus einer Zeit, als der übliche Billigprogrammierer noch am > Parallelport eines PCs hing und einfach mit ein paar Drähten an den > AVR-Pins herum gewackelt hat. Diese Konstruktionen waren teilweise etwas > fehleranfällig, weshalb es gelegentlich zu Bitfehlern kam. Wenn ein > solcher Bitfehler nun beim Schreiben der Fuses auftrat, hatte das u.U. > katastrophale Folgen ("gebrickter" Chip). Daher stammte die Idee, dass > man noch innerhalb der gleichen ISP-Sitzung (die ja in dem Moment > erstmal noch funktioniert) ggf. die Fuses nochmal erneut schreibt. > > Übrigens setzen deine Fuses den Reset-Vektor auf den Bootloader-Bereich, > obwohl du offensichtlich gar keinen Bootloader installieren willst … Hallo Jörg, Ich vermute genau den "Wackelkontakt" bei meinem ersten flash Versuch. Dort wollt ich keine Kabel an die Platine löten, was nicht so richtig geklappt hat, denke dabei hats was zerlegt. Zum Thema bootloadewr, der sollte in dem hex file integriert sein. Aber, ist ja hinfällig :-) oder ist da mit Hausmitteln noch was zu retten?
> mit Hausmitteln
Kommt auf das "Haus" an - als erster Versuch, wie Jörg Wunsch schon
schrieb, einen Hilfstakt an XTAL1 anschließen oder, falls zufällig auf
'Low Frequency Crystal Oscillator' verstellt wurde, einen Takt mit max.
200 kHz an XTAL2.
Dirk G. schrieb: > oder ist da mit Hausmitteln noch was zu retten? Ja, wie ich schon schrieb: Takt an XTAL1 einspeisen und schauen, ob man danach mit ISP wieder rankommt.
Ok, Danke für die Info, aber das übersteigt wohl meine Fähigkeiten...
Hast du noch einen weiteren AVR rumliegen? Je nach AVR-Typ genügt es u. U., einfach nur eine Fuse zu setzen, damit er seinen internen Takt an einem Pin heraus wackeln lässt. OK, diesmal die Fuse richtig setzen. :)
Angehängte Dateien:
-
atmega328.jpg
350 KB
Das gute Stück ist ja auf einer Platine aufgelötet, das bekomme ich nicht ab. Mit dem Hilfstakt an XTAL1 wäre wohl machbar, allerdings fehlen mir hierzu die Quarze.
Dirk G. schrieb: > Das gute Stück ist ja auf einer Platine aufgelötet, das bekomme ich > nicht ab. Baumarkt-"Fön" hilft. Vorzugsweise einer mit einstellbarer Temperatur, zur Not geht auch ein ganz einfacher. Aber ich würde es an deiner Stelle erstmal mit irgendwas probieren, mit dem man einen Takt generieren kann, bevor man den ganzen Chip da ablötet. Weiß nicht, wieviel Pegel so ein Smartphone am Kopfhörer-Ausgang produzieren kann … dafür gibt es ja einfache Apps, die einen Funktionsgenerator imitieren. Das geht zwar nur bis reichlich 10 kHz, weiß nicht, ob man ein USBasp dann langsam genug herunter takten kann (-i 1khz bzw. -i 1000).
Andere Frage, wo werden so kleine Quarze denn verbaut? Vielleicht hab ich in meiner Fundus Kiste was, wo man den auslöten könnte.
Beitrag #6340444 wurde von einem Moderator gelöscht.
Quarze gibt's überall, wo es Elektronik gibt. Die meisten haben aber Taktfrequenzen, die hier nicht zu gebrauchen sind (einige bis viele MHz). Da der Zustand der Fuses aber ungewiss ist, wäre ein externer Takt (nicht Quarz) eigentlich universeller. Was bietet dein Fundus denn sonst noch an Elektronik? ;-)
Angehängte Dateien:
-
IMG_1681__002_.jpg
140 KB
Also :-) einen FTDI Programmer,Sämtliche Sorten Widerstände, LED´s, ein paar Dioden, Kondensatoren und die beiden Dinger vom Bild :-)
Dirk G. schrieb: > einen FTDI Programmer, Wäre eine interessante Herausforderung, den zum Taktgenerator umzufunktionieren. :-) Müsste eigentlich gehen … Das im Bild ist ein Seriel->Parallel-Schieberegister (kann man mit SPI von einem Controller aus ansteuern) und ein Optokoppler. Das hilft nicht so viel.
Dirk G. schrieb: > Das gute Stück ist ja auf einer Platine aufgelötet, Dann ist der Fehler doch sonnenklar.... (vielleicht) Das aufgelötete Funkmodul quatscht dir dazwischen, weil dessen /CS nicht per Pullup auf High gezogen wird. Dirk G. schrieb: > das bekomme ich nicht ab. Noch nicht mal den Schaltplan dürfen wir sehen
> Wäre eine interessante Herausforderung, den zum Taktgenerator > umzufunktionieren. :-) Müsste eigentlich gehen … Na dann mal los, ich bin ganz Ohr :-) Gibt es was, was einfacher geht? Hab auch noch einen Uno hier und einen Nano
Dirk G. schrieb: > Gibt es was, was einfacher geht? Hab auch noch einen Uno hier und einen > Nano Nimm die doch...!
Dirk G. schrieb: > Hab auch noch einen Uno hier Ja, das geht auf jeden Fall einfacher. Timer auf CTC-Mode setzen und einen Ausgang als "toggle on compare match" festlegen. Aber mit Arduinos kennt sich der Fanboy bestimmt besser aus als ich.
Dirk G. schrieb: > Na der Schaltplan ist nicht das Problem Aber warum hast du die Fuses für internen RC eingestellt obwohl da doch ein Quarz drauf ist ? mh... Dann hast du doch einen!
Arduino Fanboy D. schrieb: > Dirk G. schrieb: >> Gibt es was, was einfacher geht? Hab auch noch einen Uno hier und einen >> Nano > > Nimm die doch...! Wie schon gesagt, das zu löten übersteigt mein Equipment.
Dirk G. schrieb: > Na der Schaltplan ist nicht das Problem Um das von ufuf genannte Problem auszuschließen, fehlt ein Widerstand (10 kΩ oder so) von Pin 14 des Controllers nach Vcc. Der würde dafür sorgen, dass während der Programmierung der CC1101 inaktiv bleibt, da sein CSN auf inaktiv gehalten wird.
Adam P. schrieb: > Dirk G. schrieb: >> Na der Schaltplan ist nicht das Problem > > Aber warum hast du die Fuses für internen RC eingestellt obwohl da doch > ein Quarz drauf ist ? mh... Dann hast du doch einen! Der Quarz ist nicht verbaut, das Platinenlayout wurde weiterentwickelt und somit wurde der externe Quarz zur Option.
> Um das von ufuf genannte Problem auszuschließen, fehlt ein Widerstand > (10 kΩ oder so) von Pin 14 des Controllers nach Vcc. Der würde dafür > sorgen, dass während der Programmierung der CC1101 inaktiv bleibt, da > sein CSN auf inaktiv gehalten wird. Also ablöten und nochmal testen?
Dirk G. schrieb: > Na der Schaltplan ist nicht das Problem Geht doch! ARef mit AVcc verbunden, das kann ins Auge gehen. Quarz im Schaltplan, aber Fuses auf 8MHz intern, ist unlogisch. Und Pullup am /CS vergessen, sach ich ja ....
Angehängte Dateien:
-
atmega328.jpg
400 KB
Dirk G. schrieb: > Wie schon gesagt, das zu löten übersteigt mein Equipment. Da müsste ein Draht dran.
Dirk G. schrieb: > Also ablöten und nochmal testen? Nein, einen Pullup anlöten an Pin 14 des Controllers.
Dirk G. schrieb: > Also ablöten und nochmal testen? Drei oder vier mal wurde gesagt: Einen Widerstand anlöten. Von Funkmodul ablöten hat keiner geredet.
Jörg W. schrieb: > Dirk G. schrieb: >> Wie schon gesagt, das zu löten übersteigt mein Equipment. > > Da müsste ein Draht dran. Achso, ist auf dem matschigen Bild nicht richtig zu sehen: geht vermutlich, indem du dann die Pads des nicht bestückten Quarzes weiter links benutzt. Dort den Takt einspeisen, den du aus einem Arduino Uno bekommen kannst.
Dirk G. schrieb: > Arduino Fanboy D. schrieb: >> Dirk G. schrieb: >>> Gibt es was, was einfacher geht? Hab auch noch einen Uno hier und einen >>> Nano >> >> Nimm die doch...! > > Wie schon gesagt, das zu löten übersteigt mein Equipment. Du sollst einen Arduino als Taktgenerator verwenden. Dafür muss man nix löten. Und wenn löten ein Problem für dich ist, solltest du das lernen.
Jörg W. schrieb: > Dirk G. schrieb: >> Also ablöten und nochmal testen? > > Nein, einen Pullup anlöten an Pin 14 des Controllers. Sorry, aber bitte einmal für Anfänger. Den Draht bekomme ich angelötet. Da muss dann ein Widerstand dran der mit Spannung beaufschlagt wird?
Jörg W. schrieb: > Aber mit Arduinos kennt sich der Fanboy bestimmt > besser aus als ich. Möglich... Je nach Taktwunsch würde ich vermutlich den Vorteiler von Timer 1 oder 2 ändern und auf dessen Pin 50% PWM ausgeben. Dürfte das schnellste und einfachste sein. Ansonsten ist Pinwackeln nun wirklich keine Kunst. Gibt bald ein 1/2 Dutzend Hardware Module auf dem ATMega328P welche einen Takt ausgeben können. Und in Software wackeln geht natürlich auch Im einfachsten Fall:
1 | const byte wackelpin = 12; |
2 | |
3 | void setup() |
4 | {
|
5 | pinMode(wackelpin,OUTPUT); |
6 | }
|
7 | |
8 | void loop() |
9 | {
|
10 | digitalWrite(wackelpin,not digitalRead(wackelpin)); // ca 57kHz |
11 | }
|
Wenns schneller gehen soll, auch mit delayMicroseconds() und Register Zugriffen. Hat ja sonst nix zu tun.
Arduino Fanboy D. schrieb: > Je nach Taktwunsch würde ich vermutlich den Vorteiler von Timer 1 oder > 2 ändern und auf dessen Pin 50% PWM ausgeben. > Dürfte das schnellste und einfachste sein. Ja, das hätte ich jetzt auch gemacht. Mir ist nur gerade nicht klar, ob das Arduino-Framework für solche Sachen vielleicht schon selbst was bietet. > Wenns schneller gehen soll, auch mit delayMicroseconds() und Register > Zugriffen. Geht auch ohne delayMicroseconds(). Einfach immer wieder den jeweils anderen Wert ausgeben, mit Arduino-Mitteln:
1 | void loop() |
2 | {
|
3 | digitalWrite(wackelpin, 0); |
4 | digitalWrite(wackelpin, 1); |
5 | }
|
oder eben direkt auf die Portregister. Aber dann muss man sich die passenden Register und Bits selbst raussuchen:
1 | void loop() |
2 | {
|
3 | PORTB |= (1 << wackelpin); |
4 | PORTB &= ~(1 << wackelpin); |
5 | }
|
Dirk G. schrieb: >> Nein, einen Pullup anlöten an Pin 14 des Controllers. > > Sorry, aber bitte einmal für Anfänger. Den Draht bekomme ich angelötet. Der Pfeil da oben bezog sich auf die Takteinspeisung, das ist Pin 7. An Pin 14 (wäre in deinem Bild in der unteren Reihe der dritte Pin von rechts) sollst du einen 10-kΩ-Widerstand nach Vcc anlöten, damit der CC1101 sich nicht während der Programmierung versehentlich angesprochen fühlt und dann auf den SPI-Leitungen herum hampelt.
:
Bearbeitet durch Moderator
So, vielen Dank für die Tipps, aber leider hat es nichts gebracht. Ausgabe von avrdude
1 | pi@raspberrypi:~ $ sudo avrdude -p m328p -P usb -c usbasp -B 10 -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0xFF:m -U lock:w:0xFF:m -F |
2 | |
3 | avrdude: set SCK frequency to 93750 Hz |
4 | avrdude: AVR device initialized and ready to accept instructions |
5 | |
6 | Reading | ################################################## | 100% 0.01s |
7 | |
8 | avrdude: Device signature = 0xdb2d0d |
9 | avrdude: Expected signature for ATmega328P is 1E 95 0F |
10 | avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable. |
11 | avrdude: safemode: To protect your AVR the programming will be aborted |
12 | |
13 | avrdude done. Thank you. |
Dirk G. schrieb: > So, vielen Dank für die Tipps, aber leider hat es nichts gebracht. Was hast du getan?
Dirk G. schrieb: > avrdude: Device signature = 0xdb2d0d Solange du das siehst, brauchst du nicht weiterzumachen. Und lass bitte dieses blöde -F da weg! Das ist die Option "Ich möchte mir gern in den Fuß schießen, hindere mich nicht dran!". Falls das irgendwo auf einer Webseite so erwähnt ist, schreib ihnen das ebenfalls, dass sie das da wegmachen sollen. Wer an den Fuses rumfummelt und dann auch noch gleich mal standardmäßig -F setzt, hat das Rezept zum (Controller-)Selbstmord. Hintergrund der -F Option: bei den ersten AVRs konnte man es mit besagten Pinwackel-Programmier-Adaptern schon mal schaffen, die Signatur des Controllers entweder versehentlich zu löschen (liest dann als 0xFFFFFF aus), in einem Falle habe ich sie sogar mal (bei einem AT90S1200) mit Nullen überschreiben können. Um mit diesen (ansonsten funktionierenden) Controllern überhaupt noch etwas anfangen zu können, wurde die Option -F eingeführt. Später beim STK500 bekam sie noch einen zweiten (ebenfalls dokumentierten) Anwendungsfall: wenn man (im Terminal-Modus) an den im STK gespeicherten Einstellungen (Taktfrequenz, Target- oder ADC-Referenz-Spannung) etwas ändern möchte, ohne dass man überhaupt bereits einen Controller im STK hat, der bedient werden könnte. Abseits dieser beiden Fälle hat die Option -F nirgends etwas auf einer AVRDUDE-Kommandozeile zu suchen. Erst recht ist sie absolut nicht dafür gedacht, dass man sie "auf Verdacht" einfach mal "standardmäßig" mit angibt ohne zu wissen, was man tut.
Jörg W. schrieb: > Erst recht ist sie absolut nicht dafür > gedacht, dass man sie "auf Verdacht" einfach mal "standardmäßig" mit > angibt ohne zu wissen, was man tut. Also das ›sudo‹-Äquivalent von avrdude … [tut mir leid, das musste sein]
Dirk G. schrieb: > avrdude: AVR device initialized and ready to accept instructions > Reading | ################################################## | 100% > avrdude: Device signature = 0xdb2d0d > avrdude: Expected signature for ATmega328P is 1E 95 0F Du hast jetzt also eine erfolgreiche Kommunikation, aber aus irgendeinem Grund kann er die Device Signatur nicht lesen. Entweder hast du zu lange Leitungen, oder dein Programmieradapter hat zu große Schutzwiderstände an seinen Leitungen oder ein anderes IC stört die Kommunikation auf diesen Pins. > Wie sieht die Stromversorgung der Zielplatine aus? Gute Frage, denn Chips ohne Stromversorgung an diesen Pins können auch stören.
Stefan ⛄ F. schrieb: > Du hast jetzt also eine erfolgreiche Kommunikation Ich würde sie eher als erfolglos bezeichnen. :-/ Er liest irgendwas da ein. Das könnte eine Störung vom CC1101 sein (er hat uns ja noch nicht geschrieben, was er mittlerweile geändert hat), es kann auch Verdrahtung sein. Die Abblockung an sich scheint OK zu sein (was man dem Platinenfoto und Schaltplan entnehmen kann), der ISP-Takt ist eigentlich auch niedrig genug, sofern nicht gerade durch das Verfusen jetzt mit dem Watchdog-Oszillator getaktet wird. Dann bräuchte man einen sehr viel niedrigeren ISP-Takt … (-i 1000 oder sowas).
Vielleicht wurde schlicht die Masse-Verbindung vergessen (und ja, ist mir auch schon passiert).
Folgendes habe ich gemacht. Den Sketch von ufuf auf den Uno CC1101 von der Platine entfernt(um 100% sicher zu gehen) Kabel zwischen USBasp und Zielplatine verlötet Pin 12 vom Uno auf das Pad Y1 (lt Schaltplan für den externen Quarz) Stromversorgung 3,3V vom Uno auf die Zielplatine. Am Anschluss für die Batterie kommen 3,29 V an.
Hallo, für stabile 2MHz kann man in der Arduino IDE (getestet mit Mega2560) Port/Bit auf Arduino UNO Pin 'D13'
1 | #include <avr/io.h> |
2 | |
3 | #ifndef sbi
|
4 | #define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
|
5 | #endif
|
6 | #ifndef cbi
|
7 | #define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
|
8 | #endif
|
9 | |
10 | #define D13_OUT sbi (DDRB,5)
|
11 | #define D13_TOGGLE sbi (PINB,5)
|
12 | |
13 | int main(void) |
14 | {
|
15 | D13_OUT; |
16 | |
17 | while(1) |
18 | {
|
19 | D13_TOGGLE; |
20 | }
|
21 | }
|
:
Bearbeitet durch User
Dirk G. schrieb: > Den Sketch von ufuf auf den Uno Dann musst du im USBasp viel langsamer werden. Er schreibt was von 57 kHz, die da rauskommen. ISP-Takt muss weniger als ein Viertel davon sein. Probier mal "-i 10khz". (Ich hoffe, das USBasp geht auch so weit herunter zu takten.)
Jörg W. schrieb: > Dirk G. schrieb: >> Den Sketch von ufuf auf den Uno > > Dann musst du im USBasp viel langsamer werden. Er schreibt was von 57 > kHz, die da rauskommen. ISP-Takt muss weniger als ein Viertel davon > sein. Probier mal "-i 10khz". (Ich hoffe, das USBasp geht auch so weit > herunter zu takten.) Leider das gleiche Ergebnis
1 | pi@raspberrypi:~ $ sudo avrdude -p m328p -P usb -c usbasp -B 10 -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0xFF:m -U lock:w:0xFF:m -i 10000 |
2 | |
3 | avrdude: set SCK frequency to 93750 Hz |
4 | avrdude: AVR device initialized and ready to accept instructions |
5 | |
6 | Reading | ################################################## | 100% 0.01s |
7 | |
8 | avrdude: Device signature = 0xdb2d0d |
9 | avrdude: Expected signature for ATmega328P is 1E 95 0F |
10 | Double check chip, or use -F to override this check. |
11 | |
12 | avrdude done. Thank you. |
> Den Sketch von ufuf auf den Uno Ich hatte extra ca 57kHz dabei geschrieben! Und du: > set SCK frequency to 93750 Hz Das kann nichts werden! Das Verhältnis muss umgekehrt sein. Ich weiß nicht mehr genau wie, aber die Taktfrequenz muss doppelt oder vierfach so hoch sein wie die Programmierfrequenz. Steht im Datenblatt. Glaube dem Datenblatt. Tipp: Entweder -i oder -B Entscheide dich.
Arduino Fanboy D. schrieb: > set SCK frequency to 93750 Hz Ja, allerdings scheint das unabhängig von der -i Option zu sein. :/ Damit scheint das USBasp dafür ungeeignet. Bliebe nur noch der Weg, den Sketch so abzuändern, dass er direkt auf den Ports rumfummelt. Veit hat ja einen Ansatz geliefert.
Arduino Fanboy D. schrieb: > Entweder -i oder -B Ah sorry, da war ich wohl dran Schuld. Hätte vorher mal die Manpage wieder lesen sollen. ;-) Bei einer von beiden sollte man die Frequenz auch in kHz direkt angeben können, müsste -B sein.
Hallo, falls verschiedene Taktfrequenzen versucht werden sollen ...
1 | /*
|
2 | IDE 1.8.13
|
3 | avr-gcc 9.3.0
|
4 | Arduino UNO/Mega2560
|
5 | Frequenzgenerator
|
6 | */
|
7 | |
8 | #include <util/atomic.h> |
9 | |
10 | const byte pinFreq = 10; // Pin OCR1B (am Mega Pin 12) |
11 | const unsigned int PRESCALER = 8; |
12 | /*
|
13 | // gültig mit Prescaler 1
|
14 | 100kHz -> TOP 80
|
15 | 250kHz -> TOP 32
|
16 | 500kHz -> TOP 16
|
17 | 1MHz -> TOP 8
|
18 | 4MHz -> TOP 2
|
19 | 8MHz -> TOP 1
|
20 |
|
21 | // gültig mit Prescaler 8
|
22 | 500Hz -> TOP 2000
|
23 | 1kHz -> TOP 1000
|
24 | 2kHz -> TOP 500
|
25 | 4kHz -> TOP 250
|
26 | 6kHz -> TOP 167
|
27 | 8kHz -> TOP 125
|
28 | 10kHz -> TOP 100
|
29 | 50kHz -> TOP 20
|
30 | 100kHz -> TOP 10
|
31 | */
|
32 | const unsigned int TOP = 100; // MAX <= 65535 |
33 | |
34 | void setup (void) |
35 | {
|
36 | pinMode(pinFreq, OUTPUT); |
37 | preSetTimer1(); |
38 | runTimer1(PRESCALER); |
39 | }
|
40 | |
41 | |
42 | void loop (void) |
43 | {
|
44 | |
45 | }
|
46 | |
47 | void preSetTimer1 (void) // Voreinstellungen, läuft noch nicht los |
48 | { // Mode 11, Phase Correct |
49 | ATOMIC_BLOCK (ATOMIC_RESTORESTATE) |
50 | {
|
51 | TCCR1B = 0; // Resets |
52 | TCCR1A = 0; // |
53 | TIMSK1 = 0; // |
54 | TCNT1 = 0; // |
55 | OCR1A = TOP; |
56 | OCR1B = TOP / 2; |
57 | TCCR1A = _BV(COM1B1) | _BV(WGM11) | _BV(WGM10); // OC1B Pin nicht invertiert |
58 | TCCR1B = _BV(WGM13); |
59 | }
|
60 | }
|
61 | |
62 | |
63 | void runTimer1 (const unsigned int prescaler) |
64 | {
|
65 | ATOMIC_BLOCK (ATOMIC_RESTORESTATE) |
66 | {
|
67 | switch (prescaler) { // set Prescaler Clock Select Bits |
68 | case 1 : TCCR1B |= _BV(CS10); break; |
69 | case 8 : TCCR1B |= _BV(CS11); break; |
70 | case 64 : TCCR1B |= _BV(CS11) | _BV(CS10); break; |
71 | case 256 : TCCR1B |= _BV(CS12); break; |
72 | case 1024 : TCCR1B |= _BV(CS12) | _BV(CS10); break; |
73 | default : TCCR1B |= _BV(CS11); |
74 | }
|
75 | }
|
76 | }
|
77 | |
78 | |
79 | void stopTimer1 (void) |
80 | {
|
81 | ATOMIC_BLOCK (ATOMIC_RESTORESTATE) |
82 | {
|
83 | TCCR1B &= ~( _BV(CS12) | _BV(CS11) | _BV(CS10) ); |
84 | }
|
85 | }
|
Mein USBasp sagt bei -B 500
> avrdude: set SCK frequency to 2000 Hz
Ließt die Fuses und Signatur korrekt
Schnarchend langsam, aber korrekt
Auch -B 500Hz funktioniert noch.
nur zur Vollständigkeit, obige 8MHz Einstellung funktioniert so nicht, da war ich zu schnell
Dirk G. schrieb: > Stromversorgung 3,3V vom Uno auf die Zielplatine. Beim Arduino UNO liefert der 3,3V Ausgang nur wenige Milliampere. Das ist nur ein kleiner Seiteneffekt vom USB-UART Adapter.
Es hilft nichts, auch -B 500 ändert zwar die Frequenz auf 2000hz, aber die Fuses lassen sich nicht schreiben. Hab das Teil jetzt in die Tonne befördert, 5 neue in China in Auftrag gegeben und wenn die hier sind, löte ich die Kabel direkt an vorm flashen und lasse auch das -F weg. Hab da wohl Lehrgeld bezahlt. Danke allen für ihre Mühe und Geduld!
Veit D. schrieb: > ATOMIC_BLOCK (ATOMIC_RESTORESTATE) Wofür brauchst du denn einen Atomic Block, wenn du gar keine Interrupts aktiviert hast? Dirk G. schrieb: > Hab das Teil jetzt in die Tonne befördert Trotzdem schade, zumal man ja aus der Rettung solcher Missgeschicke auf jeden Fall was lernen kann.
> Trotzdem schade, zumal man ja aus der Rettung solcher Missgeschicke auf > jeden Fall was lernen kann. Was gelernt hab ich ja, zumindest wie man es nicht macht :-) Wie gesagt, beim neuen löte ich direkt und lass das -F weg, dann sollte es ja gelingen.
Hallo, in der "Arduino IDE" sind die Interrupts immer aktiviert, sieht man aber nicht. Ähnlich dem das die Timer für analogWrite schon vorbelegt sind und man ihre Register erst löschen muss, wenn man die Timer für eigene Zwecke verwenden möchte. Das mit dem Interrupt hatte mich außerhalb der Arduino IDE in Atmel Studio schon zur Verzweiflung gebracht. Da hatte ich schlichtweg den System-Interrupt nicht aktiviert. Das dauerte bis ich darauf kam. :-)
Veit D. schrieb: > in der "Arduino IDE" sind die Interrupts immer aktiviert, sieht man aber > nicht. OK, stimmt auch wieder. Andererseits ist es für das bisschen TCCR1B sicher auch egal, ob da zwischen dem Lesen und dem Schreiben ein Interrupt reinrutscht.
Guten Abend Finde ich auch schade, als lesender Gast. Warum "nur" die Erwähnung mit HVPP (HVSP)? Vor Tagen fand ich: http://www.peterfleury.epizy.com/avr-hvsp-fuse-restore.html?i=2 u.a., das liesse sich auch auf einen ATMEGA 328p übertragen, s.w.u. , allerdings ist die vorgekommene Änderung der device signatur mit Fragezeichen, finde ich. PS.: Der Arduino UNO geht auch als ISP zusammen mit avrdude zum auslesen und flashen. Wünsche noch einen schönen Abend. dirk, lesender Gast
dirk schrieb: > Vor Tagen fand ich: > http://www.peterfleury.epizy.com/avr-hvsp-fuse-restore.html?i=2 > u.a., das liesse sich auch auf > einen ATMEGA 328p übertragen, Eher nicht. HVSP hilft hier nicht weiter. HVPP allerdings schon. dirk schrieb: > PS.: Der Arduino UNO geht auch als ISP zusammen mit avrdude zum auslesen > und flashen. Ja, aber nicht von Hause aus HVPP Siehe besser hier: https://github.com/microtherion/ScratchMonkey
Arduino Fanboy D. schrieb: > HVPP allerdings schon. Ist aber ziemlicher Aufwand, und typischerweise eben nicht "in-circuit" machbar (wegen der restlichen Peripherie in der Schaltung).
Eine Frage hätte ich noch, Wenn ich einen jungfräulichen atmega328p kaufe und auflöte, kann ich dann wieder bei „0“ anfangen?
Dirk G. schrieb: > Wenn ich einen jungfräulichen atmega328p kaufe und auflöte, > kann ich dann wieder bei „0“ anfangen? Wenn du nicht aus Vesehen sonst was kaputt gemacht hast: ja. Du hattest irgendwas geschrieben, dass du den CC1101 entfernt hast. Den wieder aufzulöten, dürfte mit einer einfachen Baumarkt-Heißluftpistole schwierig werden.
Jörg W. schrieb: > Arduino Fanboy D. schrieb: >> HVPP allerdings schon. > > Ist aber ziemlicher Aufwand, und typischerweise eben nicht "in-circuit" > machbar (wegen der restlichen Peripherie in der Schaltung). Ja! Und dennoch wohl der letzte Anker, um den konkreten µC noch zu retten.
> Du hattest irgendwas geschrieben, dass du den CC1101 entfernt hast. Den > wieder aufzulöten, dürfte mit einer einfachen Baumarkt-Heißluftpistole > schwierig werden. Ja, aber das ist ja ein komplettes Modul, das ging ganz gut abzulöten, also mit kleiner Spitze und Entlötlitze.
Dirk G. schrieb: > Ja, aber das ist ja ein komplettes Modul OK, dafür war dein Bild zu unscharf (der Fokus ist auf der Unterlage, nicht auf der Platine ;-). Jetzt erkenne ich es auch.
Guten Abend, Neues Spiel, neues Glück. Ratschläge beherzigt, neuen Atmega aufgelötet, Fuses kann ich setzen.
1 | sudo avrdude -p m328p -P usb -c usbasp -B 10 -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0xFF:m -U lock:w:0xFF:m |
2 | |
3 | avrdude: set SCK frequency to 93750 Hz |
4 | avrdude: AVR device initialized and ready to accept instructions |
5 | |
6 | Reading | ################################################## | 100% 0.01s |
7 | |
8 | avrdude: Device signature = 0x1e950f (probably m328p) |
9 | avrdude: reading input file "0xE2" |
10 | avrdude: writing lfuse (1 bytes): |
11 | |
12 | Writing | ################################################## | 100% 0.00s |
13 | |
14 | avrdude: 1 bytes of lfuse written |
15 | avrdude: verifying lfuse memory against 0xE2: |
16 | avrdude: load data lfuse data from input file 0xE2: |
17 | avrdude: input file 0xE2 contains 1 bytes |
18 | avrdude: reading on-chip lfuse data: |
19 | |
20 | Reading | ################################################## | 100% 0.00s |
21 | |
22 | avrdude: verifying ... |
23 | avrdude: 1 bytes of lfuse verified |
24 | avrdude: reading input file "0xD0" |
25 | avrdude: writing hfuse (1 bytes): |
26 | |
27 | Writing | ################################################## | 100% 0.00s |
28 | |
29 | avrdude: 1 bytes of hfuse written |
30 | avrdude: verifying hfuse memory against 0xD0: |
31 | avrdude: load data hfuse data from input file 0xD0: |
32 | avrdude: input file 0xD0 contains 1 bytes |
33 | avrdude: reading on-chip hfuse data: |
34 | |
35 | Reading | ################################################## | 100% 0.00s |
36 | |
37 | avrdude: verifying ... |
38 | avrdude: 1 bytes of hfuse verified |
39 | avrdude: reading input file "0xFF" |
40 | avrdude: writing efuse (1 bytes): |
41 | |
42 | Writing | ################################################## | 100% 0.00s |
43 | |
44 | avrdude: 1 bytes of efuse written |
45 | avrdude: verifying efuse memory against 0xFF: |
46 | avrdude: load data efuse data from input file 0xFF: |
47 | avrdude: input file 0xFF contains 1 bytes |
48 | avrdude: reading on-chip efuse data: |
49 | |
50 | Reading | ################################################## | 100% 0.00s |
51 | |
52 | avrdude: verifying ... |
53 | avrdude: 1 bytes of efuse verified |
54 | avrdude: reading input file "0xFF" |
55 | avrdude: writing lock (1 bytes): |
56 | |
57 | Writing | ################################################## | 100% 0.00s |
58 | |
59 | avrdude: 1 bytes of lock written |
60 | avrdude: verifying lock memory against 0xFF: |
61 | avrdude: load data lock data from input file 0xFF: |
62 | avrdude: input file 0xFF contains 1 bytes |
63 | avrdude: reading on-chip lock data: |
64 | |
65 | Reading | ################################################## | 100% 0.00s |
66 | |
67 | avrdude: verifying ... |
68 | avrdude: 1 bytes of lock verified |
69 | |
70 | avrdude: safemode: Fuses OK (E:FF, H:D0, L:E2) |
71 | |
72 | avrdude done. Thank you. |
Wenn ich aber jetzt einfach nur diesen bootloader flashen möchte
1 | https://raw.githubusercontent.com/pa-pa/AskSinPP/master/bootloader/avr/ATmegaBOOT_168_atmega328_pro_8MHz.hex |
bekomme ich dieses angezeigt
1 | sudo avrdude -p m328p -P usb -c usbasp -V -U flash:w:ATmegaBOOT_168_atmega328_pro_8MHz.hex |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.01s |
6 | |
7 | avrdude: Device signature = 0x1e950f (probably m328p) |
8 | avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed |
9 | To disable this feature, specify the -D option. |
10 | avrdude: erasing chip |
11 | avrdude: reading input file "ATmegaBOOT_168_atmega328_pro_8MHz.hex" |
12 | avrdude: input file ATmegaBOOT_168_atmega328_pro_8MHz.hex auto detected as Intel Hex |
13 | avrdude: writing flash (32652 bytes): |
14 | |
15 | Writing | ################################################## | 100% 0.01s |
16 | |
17 | avrdude: 32652 bytes of flash written |
18 | |
19 | avrdude: safemode: lfuse changed! Was e2, and is now fe |
20 | Would you like this fuse to be changed back? [y/n] |
Wenn ich die jetzt überschreibe, ist bestimmt der atmega wieder nicht ansprechbar, oder?
Dirk G. schrieb: > avrdude: safemode: lfuse changed! Was e2, and is now fe Das ist aber wirklich sehr seltsam. Nichts an dieser Kommandozeile sollte da irgendeine Fuse ändern. :/ Falls du es nicht schon beendet hast, du kannst die Frage mit "y" beantworten und die safemode-Prozedur versuchen lassen, ob sie die Fuse nochmal korrigiert bekommt, aber verwundersam ist das irgendwie. ps: Warum gibst du die Option -V an, und verhinderst damit die flash verification? Wenn irgendwas an dem Setup "klapprig" ist, dann würde vermutlich auch diese flash verification fehlschlagen.
:
Bearbeitet durch Moderator
Ich bin was das programmieren von Microchips angeht blutiger Anfänger. Was ich nicht verstehe ist, wenn ich nach einer Anleitung vorgehe die vor mir diverse andere Personen befolgt haben, nicht zum gleichen Ergebnis komme.
Vielleicht ist deine Spannungsversorgung instabil oder passt nicht zum Programmieradapter. Oder die Kabel sind zu lang. Die allermeisten USBASP funktionieren nur mit 5V Signalen (auch die mit 3,3V Jumper). Ich möchte Dir raten, mit kleineren Schaltungen zu üben. Wenn du nur 3-5 Bauteile hast, wird es Dir leichter fallen, die Ursache von Problemen zu finden. Mit etwas Erfahrung kommst du dann mit größeren Schaltungen besser zurecht. Dass dein Programm bereits 99% des Speichers ausfüllt, macht die Sache nicht gerade einfacher. Fange mit kleineren Programmen an! Der Konditor lernst zuerst, Kekse zu backen. Hochzeitstorten kommen später.
Stefan, was soll ich sagen. Programmer auf 5V gejumpert und es läuft :-)
1 | sudo avrdude -p m328p -P usb -c usbasp -U flash:w:ATmegaBOOT_168_atmega328_pro_8MHz.hex |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.01s |
6 | |
7 | avrdude: Device signature = 0x1e950f (probably m328p) |
8 | avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed |
9 | To disable this feature, specify the -D option. |
10 | avrdude: erasing chip |
11 | avrdude: reading input file "ATmegaBOOT_168_atmega328_pro_8MHz.hex" |
12 | avrdude: input file ATmegaBOOT_168_atmega328_pro_8MHz.hex auto detected as Intel Hex |
13 | avrdude: writing flash (32652 bytes): |
14 | |
15 | Writing | ################################################## | 100% 0.00s |
16 | |
17 | avrdude: 32652 bytes of flash written |
18 | avrdude: verifying flash memory against ATmegaBOOT_168_atmega328_pro_8MHz.hex: |
19 | avrdude: load data flash data from input file ATmegaBOOT_168_atmega328_pro_8MHz.hex: |
20 | avrdude: input file ATmegaBOOT_168_atmega328_pro_8MHz.hex auto detected as Intel Hex |
21 | avrdude: input file ATmegaBOOT_168_atmega328_pro_8MHz.hex contains 32652 bytes |
22 | avrdude: reading on-chip flash data: |
23 | |
24 | Reading | ################################################## | 100% 0.01s |
25 | |
26 | avrdude: verifying ... |
27 | avrdude: 32652 bytes of flash verified |
28 | |
29 | avrdude: safemode: Fuses OK (E:FF, H:D0, L:E2) |
30 | |
31 | avrdude done. Thank you. |
> avrdude: 32652 bytes of flash verified
?
Dirk G. schrieb: > Stefan, was soll ich sagen. > Programmer auf 5V gejumpert und es läuft :-) Guck Dir den Schaltplan an und siehe dass der Jumper ein Fake ist: https://hacksterio.s3.amazonaws.com/uploads/attachments/745250/screenshot_2019-02-02_at_4_25_05_pm_mOfBiXA31s.jpg Damit stellst du nur ein, wie viel Volt der Programmieradapter an deine Zielspannung liefert. Mal abgesehen davon, dass es eigentlich umgekehrt herum sein sollte (die Zielschaltung versorgt den Programmieradapter, damit er sich an deren Spannung anpassen kann), hat dieser Jumper überhaupt keine Wirkung auf den Mikrocontroller des Programmieradapters. Der läuft immer auf 5V.
Vielleicht stabilisiert das ja aber seine Spannungsversorgung?
Jörg W. schrieb: > Vielleicht stabilisiert das ja aber seine Spannungsversorgung? Kann durchaus sein. Oder über diesen Weg kommt die fehlende Masse-Verbindung zustande.
Ich frag nochmal :-) Flashen klappt jetzt, wenn ich auf 5V jumper. (Hab ein paar Platinen zu flashen) Da ich aber den Dingern nicht immer volle Breitseite geben möchte, hab ich mir aus einem Step down und nem 12V Netzteil eine Spannungsversorgung gebaut. Ich stelle fest, das sich jeder Atmega mit ner anderen Spannung flashen lässt. Mal sind’s 3.3V, mal 3.5V, mal 3.7V. Was ich immer festgestellt habe, das nur ein flashen ohne montiertes CC1101 Funkmodul möglich ist. Das ist relativ doof, weil ich die Firmware ggf. noch anpassen muss, zum testen aber das Modul verlötet sein muss. Kann es sein, das die Spannung mit aufgesetztem Modul soweit einbricht, das das flashen nicht möglich ist? Wieviel Spannung verträgt so ein CC1101? 3.9 - 4 Volt Max?
Beitrag #6347872 wurde von einem Moderator gelöscht.
Beitrag #6347876 wurde von einem Moderator gelöscht.
Beitrag #6347890 wurde von einem Moderator gelöscht.
Beitrag #6347893 wurde von einem Moderator gelöscht.
Dirk G. schrieb: > Kann es sein, das die Spannung mit aufgesetztem Modul soweit einbricht, > das das flashen nicht möglich ist? Vermuten und raten kann man viel. Ich würde dir empfehlen, das zu überprüfen.
Beitrag #6347907 wurde von einem Moderator gelöscht.
Angehängte Dateien:
Ist bei diesem Modul nicht der Pullup integriert?
Dirk G. schrieb: > Wieviel Spannung verträgt so ein CC1101? 3.9 - 4 Volt Max? Davon würde ich ausgehen. Hast du denn mal probiert, die Vcc-Leitung nicht zum USBasp durchzuschleifen?
Dirk G. schrieb: > Ist bei diesem Modul nicht der Pullup integriert? Zeige mal lieber den Schaltplan davon, als ein Foto. Bzw. gucke da selber rein, wenn du ihn gefunden hast.
Jörg W. schrieb: > Hast du denn mal probiert, die Vcc-Leitung nicht zum USBasp > durchzuschleifen? Oder JP1 einfach abziehen.
Beitrag #6347917 wurde von einem Moderator gelöscht.
Angehängte Dateien:
Es soll so eins sein. Und ja, ich weiß das es unterschiedliche Versionen gibt. VCC schleife ich nicht durch, nur Masse ist aufgelegt.
:
Bearbeitet durch User
Für all diejenigen, die es interessiert. Kann jetzt auch die Platinen mit aufgesetzten CC1101 flashen. Problem war die Spannungsversorgung, so wie ich das herausgefunden habe, scheinen die Chinesen Atmega clones einzusetzen, denen die 3.2 V aus dem USBasp nicht reichen. Versorge die Platine während des flashens jetzt mit 3.75 V, das kann das CC1101 ab und avrdude meckert auch nicht. Dank all denjenigen, die mit ihren konstruktiven Beiträgen mir als Noob auf die Sprünge geholfen haben!
Dirk G. schrieb: > scheinen die Chinesen Atmega clones einzusetzen, denen die 3.2 V aus dem > USBasp nicht reichen. Naja, die ATmegas laufen eigentlich ab 2,7 V. Clones gibt es meines Wissens bislang nicht von AVRs, aber massenhaft ausgelötete und recycelte Teile, die können also auch schon älter sein.
Jörg W. schrieb: > Clones gibt es meines > Wissens bislang nicht von AVRs, Richtige Klone kenne ich auch nicht. Aber deutlich leistungsfähigere Nachbauten. z.B. MD-328D oder lgt8f328p https://github.com/RalphBacon/LGT8F328P-Arduino-Clone-Chip-ATMega328P Naja, in wie weit die legal sind, kann/will ich nicht beurteilen
War da nicht bein Flashen mehr Spannung nötig, als für den Betrieb? Einige AVR laufen offiziell sogar noch mit 1,8V aber zum flashen war mehr nötig, glaube ich. 3,3V reichen aber mit Sicherheit. Blöd ist aber, wenn der USBASP den AVR mit 3,3V versorgt und dann trotzdem 5V auf die Signal-Leitungen legt. Genau das tun alle, die ich kenne.
Stefan ⛄ F. schrieb: > Blöd ist aber, wenn der USBASP den AVR mit 3,3V versorgt und dann > trotzdem 5V auf die Signal-Leitungen legt. Genau das tun alle, die ich > kenne. Wie ich ja gelernt habe, ist das mit dem Diamex Programmer ja nicht der Fall. Den werde ich mir auch zulegen, für evtl Firmwareupdates oder neue Projekte :-) Falls "Diamex" ein Synonym ist, bitte ich im Vorfeld um Entschuldigung!
Stefan ⛄ F. schrieb: > War da nicht bein Flashen mehr Spannung nötig, als für den Betrieb? Nö, das ist nur bei den ganz kleinen Tinys (ATtiny10 etc.), die man zum Flashen mit 5 V betreiben muss. > Blöd ist aber, wenn der USBASP den AVR mit 3,3V versorgt und dann > trotzdem 5V auf die Signal-Leitungen legt. Genau das tun alle, die ich > kenne. Diamex kenne ich jetzt nicht, aber die originalen Atmel-Teile (AVRISPmkII etc.) machen das auch nicht, die haben Levelshifter drin. Aber die versorgen die Schaltung auch überhaupt nicht; Pin 2 ist dort eine Referenzspannung aus der Schaltung in die Levelshifter.
:
Bearbeitet durch Moderator
Dieser hier würde für meine Zwecke ausreichen.
1 | https://www.diamex.de/dxshop/USB-ISP-Programmer-fuer-Atmel-AVR |
Jörg W. schrieb: > Diamex kenne ich jetzt nicht, aber die originalen Atmel-Teile > (AVRISPmkII etc.) machen das auch nicht, die haben Levelshifter drin. > Aber die versorgen die Schaltung auch überhaupt nicht; Pin 2 ist dort > eine Referenzspannung aus der Schaltung in die Levelshifter. Die tun das auch so, mit Levelshifter usw. Wie auch der Atmel ICE das tut. Zusätzlich kann der Diamex mkII auch die Schaltung mit 3,3 oder 5V versorgen. Betrachtet man die Gesamtpalette, der ehemals Atmel Chips, dürfte der Atmel Ice das Mittel der Wahl sein. Einzig HVPP und HVSP, daran fehlt es ihm.
Arduino Fanboy D. schrieb: > dürfte der Atmel Ice das Mittel der Wahl sein Leider ist er seit der Übernahme durch Microchip stetig teurer geworden. Das "bare PCB" davon war mal billiger als der seinerzeit sehr beliebte AVR Dragon (der ja auch nur ein "bare PCB" war). Kostet inzwischen schon doppelt so viel wie damals. :-(( (War meiner Erinnerung nach anfangs unter EUR 40, wenngleich ich nicht mehr ganz genau weiß, ob der erinnerte Preis mit oder ohne MWSt war.) https://www.reichelt.de/debug-programmer-fuer-arm-cortex-m-avr-atmel-ice-pcba-p190409.html Mit Kabelsatz dann 1,5mal so viel: https://www.reichelt.de/debug-programmer-fuer-arm-cortex-m-avr-atmel-ice-basic-p176552.html Und das ist noch "Basic", d.h. das Universal-"Tintenfisch"-Kabel ist noch nicht mit dabei. Vorteilhaft daran ist natürlich, dass man damit auch für Cortex-M gewappnet ist. Wenn man OpenOCD nimmt, funktioniert es auch für Cortex-M beliebiger Hersteller, nicht nur Microchip/Atmel. (Dass man für einen STM kein Atmel Studio nehmen kann, ist irgendwie logisch. ;-)
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Mit Kabelsatz dann 1,5mal so viel: Tja, wer das Angebot, direkt nach der Übernahme, verpasst hat, muss wohl leider bluten. Ich meine, das waren um 60 Euronen incl. Gehäuse und Kabelsatz.
Die ISP Programmer von Diamex sind OK. Können halt nur ISP, das aber gut.
Stefan ⛄ F. schrieb: > Die ISP Programmer von Diamex sind OK. Können halt nur ISP, das aber > gut. Das ist für meine Zwecke voll ausreichend!
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.