Atmega328p fuses falsch gesetzt

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?

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.

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?

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 …

Das ist die Fusekonfiguration bei einem echten Pro Mini Clone (3.3V).

Falls jemand braucht.

> 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?

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. :)

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.

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? ;-)

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.

> 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

Na der Schaltplan ist nicht das Problem

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:
> 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.

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.

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?

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.

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:
> 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]

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).

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

}

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.

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.

Wäre ein FTDI zum flashen eine Option?

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

}

Dirk G. schrieb:
> Wäre ein FTDI zum flashen eine Option?

Woher der Takt stammt spielt keine Rolle.

nur zur Vollständigkeit, obige 8MHz Einstellung funktioniert so nicht, 
da war ich zu schnell

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.

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.

> 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.

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.

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

?

Vielleicht stabilisiert das ja aber seine Spannungsversorgung?

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?

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?

Es soll so eins sein.

Und ja, ich weiß das es unterschiedliche Versionen gibt.


VCC schleife ich nicht durch, nur Masse ist aufgelegt.

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.

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.

Dieser hier würde für meine Zwecke ausreichen.

1

https://www.diamex.de/dxshop/USB-ISP-Programmer-fuer-Atmel-AVR

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. ;-)

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!