ATMega328PB lässt sich nur noch programmieren. Sonst keine Funktion mehr

[Felix N. (felix_n888)]

Hallo zusammen,

Ich habe ein ATMega328PB auf einer Platine verbaut welcher verschiedene 
Sensoren ausließt wie SCD-40, SGP-40, BME280, TGS5141 und die 
entsprechenden Messwerte via Modbus RTU bereitstellt.

Das Problem ist nun das jetzt schon den zweiten ATMega328PB auf dieser 
Platine verlötet habe der "nichts" mehr macht. Er lässt sich via USBasp 
mittel ICSP noch ganz normal programmieren. Aber der Code wird nicht 
ausgeführt bzw es passiert nichts. Egal ob ich jetzt eine LED ansteuere 
oder ein Loopback im USART mache oder ein Sensor ansteuere so das dann 
die Stromaufnahme steigt nichts.

Ich verwende kein Bootloader. Folgende Fuses hab ich mittels avrdude 
programmiert:

Low : 0xF7

High: 0xD9

Ext : 0xFD


Der Controller läuft auf 3,3V mit einem Quarz von 7,3628MHz für 19,2 und 
115,2k Baudraten. BOD ist auf 2,7V eingestellt. Wenn ich ein Pin auf 
HIGH setzte kann ich maximal 0,4 bis 0,8V an diesem Pin messen. Als ich 
den zweiten Controller neu eingelötet, und das Programm für LED-An und 
USART1 hochgeladen hatte, war PWR-LED am leuchten und über USART1 kamen 
auch korrekte Zeichen an. Erst als ich den Code wieder auf USART0 für 
den RS485 Teil geändert habe kam der Zustand wie er nun ist.

Auf der Platine hab ich schon einiges geprüft. Quarz swingt sauber, RST 
ist auch auf 3,3V im Betrieb. 3,3V sind auch stabil.

Stromaufnahme der gesamten Platine bei 24V ca. 2,5mA -> 60mW ist auch ok 
dafür das die Sensoren alle in Standby sind. Auf der 3,3V Rail sind es 
etwa 15mA sollte auch passen.

Ich hab euch mal mein Schaltplan angehängt insbesondere den 
Mikrocontroller und den RS485 Teil, ich vermute das es damit zusammen 
hängt aber allerdings war diese Schaltung für mich nicht neu.

Hat einer von euch ne Idee was das sein könnte? Ich kann mir das 
irgendwie nicht erklären

Mfg

[Ob S. (Firma: 1984now) (observer)]

Felix N. schrieb:

> Low : 0xF7

Das ist falsch. Ein Mega328PB ist kein Mega328P. Einer der wesentlichen 
Unterschiede zwischen beiden ist der Quarzoszillator und die zugehörigen 
Fuses.

RTFM

> Er lässt sich via USBasp
> mittel ICSP noch ganz normal programmieren.

Nach dem Setzen dieser Fuses? Glaub' ich nicht wirklich.

[H. H. (hhinz)]

Ob S. schrieb:
> RTFM

Inbesondere AT15007.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Felix N. schrieb:
> Hat einer von euch ne Idee was das sein könnte? Ich kann mir das
> irgendwie nicht erklären

Was ist mit Pin 21 des µControllers?

[Felix N. (felix_n888)]

Ob S. schrieb:
> Nach dem Setzen dieser Fuses? Glaub' ich nicht wirklich.

Ansprechen. Programmieren und Flash auslesen geht:

avrdude.exe: Device signature = 0x1e9516 (probably m328pb)

avrdude.exe: safemode: Fuses OK (E:F5, H:D9, L:F7)

avrdude.exe: reading input file "C:\Users\Felix\Documents\Atmel 
Studio\7.0\EnviroBus Sensor\EnviroBus Sensor\Debug\EnviroBus Sensor.hex"
avrdude.exe: writing flash (1814 bytes):

Writing | ################################################## | 100% 
13.05s

avrdude.exe: 1814 bytes of flash written

Der Quarz selbst schwingt ja auch. Wenn ich an XTAL2 mit meinem Oszi 
messe habe ich dort etwa 7,4MHz mit ~2,5V Spitze-Spitze.

Ob S. schrieb:
> RTFM

Gut zugegeben die Fuses stammen auch einem Forum wo es auch um dem 328PB 
ging. Mit den gleichen Einstellungen für 3,3V und 8MHz quarz. Ich habe 
nun nochmal den Fuses Calculator von Atmel Studio direkt genommen und 
wie auf dem Bild eingestellt und gebrannt. Ansprechen & Programmieren 
geht aber die LED leuchtet trotzdem nicht.

Gregor J. schrieb:
> Was ist mit Pin 21 des µControllers?

Ist in diesem Fall nicht einzeln herausgeführt worden sondern in KiCad 
intern mit dem Pin 4 (GND) verbunden. Auf der Platine sind beide GNDs 
angeschlossen.

Falls irgendwie wichtig ist diesen Quarz habe ich verbaut:

https://www.mouser.de/ProductDetail/774-407F39E007M3728

Ich hab auch mal testweise ein 220uF Elko noch zusätzlich an 3,3V 
angeschlossen aber der hat auch kein Unterschied gemacht.

[Hmmm (hmmm)]

Felix N. schrieb:
> Der Quarz selbst schwingt ja auch.

Die beiden Cs sind eigentlich etwas gross für den PB, aber das bereitet 
i.d.R. keine Probleme.

Entspricht die Reset-Beschaltung ganz sicher dem Schaltplan? Die 
Symptome klingen danach, dass der Pin fest auf GND liegen könnte.

[Felix N. (felix_n888)]

Hmmm schrieb:
> Entspricht die Reset-Beschaltung ganz sicher dem Schaltplan?

Ja. Ein 10k von Vcc nach Reset. Den sieht man auf dem Platinenbild auch 
rechts. Wenn kein ICSP Programmer angeschlossen ist und man den Reset 
pin misst hat er 3,3V.

Das komische ist ja das dass erste Programm was ich nachdem ich die 
"alten" Fuses hochgeladen habe hat ja funktioniert. Die PWR-LED 
leuchtete und über USART1 (Am ICSP Header verfügbar) kam "Hallo" im 
Terminal am PC an. Nachdem ich dann die usart.c/h von USART1 auf USART0 
geändert habe und entsprechend PB0 auf HIGH konfiguriert habe sprich das 
der RS485 Transreceiver auf senden ist, fing das ganze erst an. Danach 
kam nichts mehr am PC an und die LED ging auch nicht mehr an. Deswegen 
hatte ich die Vermutung das es damit was zutun hat.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Felix N. schrieb:
> (...)

Für das Prototypen und Debuggen wäre es vernünftiger, sich wirklich mit 
dem µController zu verbinden (Anhang), um die Fuses real auslesen und 
sich sie dann anschauen zu können – mit dem Simulator weiß man nicht, ob 
und wie die Fuses wirklich eingestellt sind. Sie können wie gewünscht 
eingestellt sein, müssen aber nicht – mit dem Auslesen in echt weiß man 
das immer hundertprozentig. Den BOD würde ich auch testweise auf 1,8V 
setzen oder auch mal ganz ausgeschaltet lassen, um zu schauen, was dann 
passiert. Abgesehen davon, hast Du es schon mal mit 47-100nF zu GND am 
Resetpin versucht? Der 10kΩ-Widerstand zu VCC bleibt natürlich auch 
drin. Den Kondensator mit dem Widerstand (+Taster) sieht man auf meinem 
Schaltplanausschnitt, den ich vorhin hochgeladen habe – ich lade es hier 
aber nochmal hoch (der Kondensator befindet sich links-unten).

[S. L. (sldt)]

> Low : 0xF7
> Gut zugegeben die Fuses stammen auch einem Forum wo es
> auch um dem 328PB ging.

Okay, und welche Taktquelle soll mit CKSEL=0111 eingeschaltet werden?

[Ob S. (Firma: 1984now) (observer)]

Felix N. schrieb:
> Nachdem ich dann die usart.c/h von USART1 auf USART0
> geändert habe und entsprechend PB0 auf HIGH konfiguriert habe sprich das
> der RS485 Transreceiver auf senden ist, fing das ganze erst an.

Alternative Funktionen von PB0 sind u.a.: ICP1 und PCINT0. Beides kann 
Interrupts auslösen.

Kann es sein, dass einer der zugehörigen Interrupts aktiviert, die 
entsprechenden ISRs aber nicht implementiert ist? Oder auch: 
falsch/unvollständig implementiert?

[Felix N. (felix_n888)]

Gregor J. schrieb:
> Für das Prototypen und Debuggen wäre es vernünftiger, sich wirklich mit
> dem µController zu verbinden

Ich bin jetzt heute nicht mehr zuhause.

Ich baue morgen nochmal eine Platine auf nur mit dem Atmega und 
Stromversorgung also ohne die Sensoren und RS485 Teil und so. Hab ja 3 
Stück von aisler bekommen.

Ich habe die Platine ja mittels Stencil aufgebaut und Sn/Bi Lötpaste. 
Ich löte die morgen mal von Hand zusammen bis auf die Sensoren geht das 
ja auch. Nicht das da irgendwo noch nen Kurzschluss oder so ist aber 
eigentlich dürfte da nichts sein hab zumindest das meiste vorher optisch 
bzw mit Multimeter geprüft.

Ich habe leider auch kein richtigen Debugger für die Atmega da ich 
mittlerweile nur noch auf den STM32 unterwegs bin. Deswegen nur den 
USBasp

S. L. schrieb:
> Okay

Ich gebe ja zu das es nicht die beste Strategie war die ich da gewählt 
habe.

Ich habe jetzt unterwegs nochmal geschaut. Ich brauche dann ja 
eigentlich den Low Power Crystal Oscillator mit Frequenz im Bereich von 
3 bis 8 MHz. Das macht für CKSEL[3:1] 110 laut Tabelle 11-1.

Und für die Start up Times hab ich jetzt das letzte laut Tabelle 11-5 
genommen mit der höchsten Anlaufzeit das macht für CKSEL0 auch ne 1 und 
für SUT[1:0]=11

Also  müsste dann ja CKSEL=1101 und SUT=11 sein korrekt?

Sprich für das Low Fuse Byte dann
1111 1101 sprich 0xFD, ohne div8 und clkout

Ist das korrekt?

Ob S. schrieb:
> Oder auch: falsch/unvollständig implementiert?

Nein interrupts waren noch nicht in Verwendung und waren auch nicht 
aktiv mit sei() bzw. im USART Konfiguriert.

[S. L. (sldt)]

> ... Low Fuse Byte ...0xFD ... Ist das korrekt?

Ja.

Ich kenne den ATmega328PB nicht, aber der Satz aus dem Datenblatt gibt 
mir zu denken: '4. When selecting the external capacitor value, the 
stray capacitance from the PCB and device should be deducted. The total 
load Ce+Ci+Cs) on XTAL pins must not exceed 22 pF.'
  Wohlgemerkt, da steht 'must not' (darf nicht), nicht etwa 'should 
not'. Auch wenn Sie schreiben, dass der Oszillator sauber schwingt.

Ansonsten würde ich (wie immer) raten, mit dem Fünfzeiler 'blinkende 
LED' zu beginnen, und dann nach und nach die einzelnen Module 
hinzufügen. Zugegeben, ist manchmal mühsam&langwierig, aber Sie haben 
jetzt auch schon einen Tag drangegeben ...

[Ob S. (Firma: 1984now) (observer)]

Felix N. schrieb:

> Nein interrupts waren noch nicht in Verwendung

Das hoffst du. Tatsächlich würde das Gegenteil aber das Verhalten 
hervorragend erklären. Dein Teil läuft an, bis die Bedingungen zur 
Abarbeitung der ISR gegeben sind, also
1) Du setzt PB0 auf high
2) Mindestens einer der beiden Interupts ist enabled und natürlich die 
Interupts global

Wenn dann die ISR nicht implementiert ist, erfolgt per default 
unmittelbar ein Restart ab Adresse 0. Auch in vielen Fällen, wenn die 
ISR falsch implementiert ist. Und in den restlichen Fällen hängt das 
Teil in irgendeiner sinnlosen Endlosschleife.

> und waren auch nicht
> aktiv mit sei() bzw. im USART Konfiguriert.

Die beiden Interrupts, um die es hier geht, würden auch nicht im 
UART-Code aktiviert werden, sondern in irgendwelchem Code, der mit 
Timer1 oder mit Pinchanges hantiert.

Du solltest deinen Code posten (aber bitte als Anhang). Du selber 
scheinst mir nicht in der Lage, den Fehler darin zu finden.

[Felix N. (felix_n888)]

S. L. schrieb:
> Ja

Okay dann werde ich das morgen nochmal testen. Danke

Aber das erklärt für mich leider immer noch nicht warum aktuell 
garnichts mehr läuft weil auch wenn ich die falsche Fuse jetzt habe vom 
Takt lief der Mikrocontroller ja. Und die LED hat geleuchtet / geblinkt.

Aktuell geht dies ja nicht mehr.

Ob S. schrieb:
> Du selber scheinst mir nicht in der Lage, den Fehler darin zu finden

S. L. schrieb:
> Ansonsten würde ich (wie immer) raten, mit dem Fünfzeiler 'blinkende
> LED' zu beginnen,

Ich kann den Code gerne morgen posten aber aktuell sind da nur 5 Zeilen 
drin. Pin PD3 als Ausgang. Und dann blinken mittels _delay_ms(500) in 
der Hauptschleife.

Mein Ziel ist es ja gerade überall mal wieder ein Lebenszeichen zu 
bekommen. Auf dem Oszi sieht man auch nichts kein Zucken des Pins 
nichts.

Ob S. schrieb:
> Dein Teil läuft an, bis die Bedingungen zur Abarbeitung der ISR gegeben
> sind,

Also interrupts sind aktuell erstmal kein Thema? Weil es ist ja keine 
andere Peripherie initialisiert bzw in Verwendung.

[Ob S. (Firma: 1984now) (observer)]

Felix N. schrieb:

> Ich kann den Code gerne morgen posten aber aktuell sind da nur 5 Zeilen
> drin. Pin PD3 als Ausgang. Und dann blinken mittels _delay_ms(500) in
> der Hauptschleife.

Huch? Bisher haben wir mindestens noch von UART (mit 
RS485-Richtungsteuerung via PB0) gehört. Und von irgendwelchen Sensoren.

Du willst wohl deinen tatsächlichen Code nicht zeigen. OK, mir egal, 
dann sieh' zu, wie du selber den/die Fehler findest.

[Björn W. (bwieck)]

Probier dieses Programm, Es lässt PD3 im ca. im Sekundentakt blinken.
Sonst nichts.

[Felix N. (felix_n888)]

Ob S. schrieb:
> Huch? Bisher haben wir mindestens noch von UART (mit
> RS485-Richtungsteuerung via PB0) gehört. Und von irgendwelchen Sensoren.

Das ist auch korrekt.

Felix N. schrieb:
> Egal ob ich jetzt eine LED ansteuere oder ein Loopback im USART mache
> oder ein Sensor ansteuere so das dann die Stromaufnahme steigt nichts.

Aber ich habe ja auch oben geschrieben das aktuell garnichts mehr geht 
weder I/O pin noch loopback oder I2C. Daher sollte es wahrscheinlich 
einfacher sein erstmal eine LED ans blinken zu kriegen bevor ich mich 
wieder mit usart und i2c beschäftige. Und es scheitert ja gerade von an 
der LED warum auch immer.

Ob S. schrieb:
> Du willst wohl deinen tatsächlichen Code nicht zeigen

Zeig ich dir aber kann ich erst morgen hochladen da ich von Unterwegs 
schreibe und kein Zugriff auf den Quellcode habe. Er ist zuhause auf 
meinem Computer.

Ich melde mich morgen mittag nochmal.

Trotzdem danke schon mal.
Schönen abend euch noch

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Felix N. schrieb:
> Aber das erklärt für mich leider immer noch nicht warum aktuell
> garnichts mehr läuft (...)

In so einem Fall würde ich zurückrudern und mich dann systematisch auf 
die Suche begeben:

– alle µC-Verbindungen (in erster Linie VCC, GND, Reset etc.) im 
ausgeschalteten Zustand auf richtige Verbindung mit einem Multimeter 
durchmessen (auch die Pinzuordnung des µC auf dem Schaltplan und der 
Leiterplatte nochmal mit dem Datenblatt abgleichen)
– im zweiten Schritt dann vorsichtig die Spannungen an diesen Pins 
messen
– auch mal VCC-Start und danach im Betrieb VCC mit einem Oszilloskop 
anschauen (auch am Resetpin)
– neues, leeres Projekt im Atmel Studio anlegen und dann nur PD2/PD3 als 
Ausgänge einstellen, um Tests mit den LEDs zu machen (Ein/Aus) => wenn 
schon das nicht funktioniert, ist etwas grundsätzliches extrem faul oder 
verbockt an der Geschichte; sollte das Umschalten der IOs für die LEDs 
gehen, kann man mit einem Multimeter/Oszilloskop den Spannungspegel bei 
Low und High nachmessen, ob das plausibel ist und wie die Flanken sind, 
auch die Zeit mit Delay usw. auf Plausibilität prüfen; danach kann man 
mit der Software einen Schritt weitergehen, also ein Stückchen von dem 
eigentlichen Programm und Peripherie aktivieren (das macht man 
normalerweise auch so Schritt für Schritt, wenn etwas Neues entwickelt 
wird und der selbstentwickelte Code noch nicht sicher getestet worden 
ist oder man die Inbetriebnahme des ersten Prototypen/Platine macht)
– neue Platine nehmen und diese nach und nach inbetriebnehmen (wie Du 
selbst geschrieben hast) ist auch eine gute Option, um effektiv aus der 
Sackgasse herauszukommen

Für die Programmierung am besten einen vernünftigen Programmer benutzen 
(MK2, Snap etc.), damit man den Zustand der Fuses eindeutig überprüfen 
kann, ansonsten ist es wie träumen im Traum davon, dass man etwas 
leckeres isst, beim Erwachen aber weder im Mund noch im Magen etwas von 
dem geträumten Essen vorhanden ist. Mit irgendwelchen günstigen 
Programmerlösungen, mit denen man den µC nur über zwei Ecken flashen 
kann und z.B. nichts verifizieren/auslesen kann, macht man sich selbst 
das Leben nur unnötig schwer. Sparen ist hier nicht angesagt und wie 
manch einer schon erfahren durfte – fürs Prototypen und „Debuggen” 
extrem kontraproduktiv. Das gleiche gilt beim STM32 natürlich auch – 
mindestens einen ST-Link-2V1 aus einem Board wie beispielsweise Nucleo 
benutzen, mit dem man in der IDE direkt mit dem µC arbeiten kann und 
nicht die Daten/Flashinhalt erst über zwei Kamele extern, von hinten 
durchs Auge schicken muss. Beim STM32 kann man dann natürlich auch von 
dem richtigen Debugger der IDE Gebrauch machen, der auch über die 
SWD-Schnittstelle läuft.

PS: 2-3 Fotos von Deinem Aufbau zu machen und hier zu posten, wäre 
bestimmt auch nicht verkehrt

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Felix N. schrieb:
> Ja. Ein 10k von Vcc nach Reset.

Das ist normalerweise nicht die übliche Standardbeschaltung, sondern 
eine minimalistische Notlösung für höchstens irgendwelche Tests, denn 
nur mit dem Widerstand kann der µC sporadisch einen Reset erfahren, wenn 
man z.B. Taster betätigt, kleine Lasten im System schaltet oder generell 
kleine Störungen auf das System von außen oder von innen einwirken. Mit 
dem Kondensator nach GND wird ein Tiefpass konstruiert, der solche 
Spikes am Reseteingang erfolgreich verhindert. Wer Angst hat, weil er 
mit einem Taster die 100nF kurzschließt, kann hier zusätzlich einen 
Widerstand in Reihe einbauen (100-220Ω). Wer wiederum Angst vor einem 
möglichen ESD-Problem am Resetpin hat, da dieser bis 12V arbeiten kann 
und hier deswegen intern keine Schutzdiode nach VCC verbaut ist, der 
kann hier noch zusätzlich diese Diode (z.B. LL4148) nach VCC konzipieren 
oder auch mal eine 5,6V Zenerdiode direkt am Pin anschließen – die 
HV-Programmierung ist dann aber in beiden Fällen nicht mehr möglich und 
kann sogar zum Schrotten des Boards führen, wenn die 12V durch die Diode 
dann nach VCC umgeleitet werden; bei der Zenerdiode macht man wiederum 
einen Kurzschluss der 12V, was wiederum den HV-Programmer kaputtmachen 
kann.

Ferner sollte man auch die Pins der Programmierschnittstelle schützen, 
wenn man irgendwelche billigen Programmer ohne I/O-Strombegrenzung 
benutzt oder es generell Pinkonflikte durch die Peripherie geben kann – 
bei MK2 ist dieser Schutz intern gewährleistet. Es gibt auch noch 
Injektionsströme, die bei ausgeschalteter Stromversorgung (auf einer 
Seite) über die IOs fließen und zu Zerstörung führen können, wenn sie 
nicht begrenzt werden. In meinen Artikelbeschreibungen empfehle ich in 
so einem Fall jeweils 220Ω als Schutzwiderstand an SCK, MISO, MOSI und 
RESET, die zum Programmer führen. Die alten ATMEGAs 328P und 1284P 
können einen kurzzeitigen Pin-Kurzschluss durchaus problemlos überstehen 
– in meinen Tests habe ich in der Vergangenheit gezeigt, dass bei einem 
Pin-Kurzschluss eines 1284P maximal ca. 80mA fließen werden und dieser 
das durchaus unbeschadet überstehen kann. Das war aber nur ein Exemplar 
aus einer zufälligen Charge – bei einem 1284P aus einer anderen Fabrik 
kann das ganz anders ausgehen und wenn man bei dem 328PB, der angeblich 
eine komplette Neuentwicklung sein soll, mit den Nanometern 
runtergegangen ist, könnte die Siliziumstruktur deutlich empfindlicher 
auf solche Kurzschlüsse reagieren. Mit dem 328PB oder den neueren AVRs 
habe ich solche riskanten Tests noch nicht durchgeführt – irgendwann mal 
werde ich es wohl auch machen müssen, um auch hier eine gewisse 
Sicherheit diesbezüglich zu erkunden.

[Ralf-Peter G. (ralfpeter)]

Die ICSP Beschaltung ist nicht Standard.
1 2 bewusst vertauscht?!

[H. H. (hhinz)]

Ralf-Peter G. schrieb:
> Die ICSP Beschaltung ist nicht Standard.
> 1 2 bewusst vertauscht?!

Und statt der Versorgungsspannung des µC einfach +5V angeschlossen.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Zum Vergleich oder Orientierung der ISP-Buchse hier noch zwei 
Screenshots: einmal aus meinem Schaltplan und aus ATMEL-Doku – der MK2 
passt dann 1:1 da rein (quasi bei allen meinen Leiterplatten, wo eine 
2x3-Stiftleiste zum Programmieren angeboten wird, da ich mich strikt 
daran halte)

[Felix N. (felix_n888)]

Björn W. schrieb:
> Probier dieses Programm

Hab ich, die LED blinkt aber leider nicht.

Ralf-Peter G. schrieb:
> Die ICSP Beschaltung ist nicht Standard.
> 1 2 bewusst vertauscht?!

Ja ist bewusst vertauscht. Ich habe mir vor langer Zeit mal ein eigenes 
Programmierkabel für den USBasp angefertigt nach diesem Muster. Deshalb 
sind die vertauscht und da ich normalerweise wenn ich noch mit den AVRs 
arbeite meistens eh den Bootloader verwende und die Programme via USART 
hochlade brauche ich diesen ICSP Anschluss sowieso nicht und ist in der 
Regel auf meinen anderen Platinen auch nicht unbedingt herausgeführt 
sofern es kein PDIP-Package ist. Daher hab ich mir das Leben einfacher 
gemacht und einfach dieses Layout wieder genommen so das ich mein 
bereits vorhandenes Kabel wieder nutzen kann.

H. H. schrieb:
> Und statt der Versorgungsspannung des µC einfach +5V angeschlossen.

Mein USBbasp kann nur +5V ausgeben daher die Einspeisung auf +5V der LDO 
macht dann wieder 3,3V

Das gleiche ist mit der angesprochen eigentlich RESET-Beschaltung. Da 
ich ja kein richtigen Programmer besitzt, mir aber vielleicht mal ein 
anschaffen sollte, hab ich mir die Diode gegen Vcc bisher immer gespart.

Gregor J. schrieb:
> 2x3-Stiftleiste zum Programmieren angeboten wird, da ich mich strikt
> daran halte

Das wäre natürlich auch sinnvoll für meine Platine gewesen. Aber da es 
sich ja nur um ein "privat projekt" handelt ohne irgendwelchen 
Firmenbezug. Also nur ich die Platine programmiere etc.. Geht dort ehr 
eine sehr geringe Gefahr von aus das jemand ein Programmer wie den Atmel 
ICE mit normalen ICSP Kabel anschließt und sich versehentlich was 
abschießt. Aber natürlich zugegeben nicht die besten Vorrausetzungen.

Gregor J. schrieb:
> In meinen Artikelbeschreibungen empfehle ich in
> so einem Fall jeweils 220Ω als Schutzwiderstand an SCK, MISO, MOSI und
> RESET, die zum Programmer führen

Aber das gilt nur, wenn ich das angehängte Bild auch richtige verstehe, 
für weitere Peripherie am SPI Bus, right?

Ich habe mal zwei Bilder der Platine angehängt von der ober und 
unterseite. Das mit der neuen Low-Fuse von 0xFD hatte leider auch kein 
Erfolg gebracht. Ich werde jetzt erstmal eine zweite minimal version der 
Platine aufbauen ohne die ganzen anderen Teile wie RS485 und Sensoren. 
Ich habe nach wie vor immer noch die Vermutung das es sich evtl. um ein 
Hardwarefehler irgendwie handelt.

[Ob S. (Firma: 1984now) (observer)]

Felix N. schrieb:

> Ich habe nach wie vor immer noch die Vermutung das es sich evtl. um ein
> Hardwarefehler irgendwie handelt.

Wie soll das sein können? Du hast hier:

Beitrag "Re: ATMega328PB lässt sich nur noch programmieren. Sonst keine Funktion mehr"

behauptet:

> Das komische ist ja das dass erste Programm was ich nachdem ich die
> "alten" Fuses hochgeladen habe hat ja funktioniert. Die PWR-LED
> leuchtete und über USART1 (Am ICSP Header verfügbar) kam "Hallo" im
> Terminal am PC an. Nachdem ich dann die usart.c/h von USART1 auf USART0
> geändert habe und entsprechend PB0 auf HIGH konfiguriert habe sprich das
> der RS485 Transreceiver auf senden ist, fing das ganze erst an.

[Roland F. (rhf)]

Hallo,
Gregor J. schrieb:
> In meinen Artikelbeschreibungen empfehle ich in
> so einem Fall jeweils 220Ω als Schutzwiderstand an SCK, MISO, MOSI und
> RESET, die zum Programmer führen.

Verstehe ich das richtig, du hast zusätzlich zu den empfohlenen 
Sicherungswiderständen, die zu den SPI-Bausteinen führen, Widerstände in 
die "Strecke" zum Programmer verbaut?

rhf

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Felix N. schrieb:
> Aber das gilt nur, wenn ich das angehängte Bild auch richtige verstehe,
> für weitere Peripherie am SPI Bus, right?

Es kommt immer darauf an, wie viele Parteien miteinander agieren und aus 
welcher Spannungsquelle sie versorgt werden, dann gibt es ja noch Fälle, 
wo die Peripherie nur MOSI oder nur MISO für die Kommunikation über SPI 
benötigt (z.B. bei A/D- und D/A-Wandlern) – das muss man sich dann im 
Einzelfall also immer anschuen. Ich habe auch schon mal eine 
SPI-Peripherie (MISO+MOSI) mit 220Ω bei STM32 abgepuffert, wo das 
absolut nichts mit der Programmierschnittstelle zu tun hatte, denn die 
läuft dort standardmäßig über die zwei SWD-Leitungen. Auch 
UART-Leitungen bekommen solche Schutzmaßnahmen bei mir, wenn zwei VCCs 
im Spiel sind oder man mit der Außenwelt kommunizieren möchte, also mit 
irgendeiner externen Peripherie außerhalb der Leiterplatte, die auch mal 
ihre Spannungsversorgung verlieren kann oder umgekehrt – dort ist eine 
Spannung bereits vorhanden, mein System aber noch nicht eingeschaltet 
ist.

___________
Roland F. schrieb:
> Verstehe ich das richtig, du hast zusätzlich zu den empfohlenen
> Sicherungswiderständen, die zu den SPI-Bausteinen führen, Widerstände in
> die "Strecke" zum Programmer verbaut?

Nein, die Widerstände gibt es in einem simplen Fall nur einmal, zum 
Programmer, aber wie oben ausführlich beschrieben, muss man das immer 
auch im jeweiligen Kontext unterscheiden und ggfs. entsprechend 
anpassen, falls mehrere SPI-Partner auf dem Interface agieren.

[Rainer W. (rawi)]

Roland F. schrieb:
> ... Sicherungswiderständen ...

Sicherungswiderstände? Was sollen das für spezielle Dinger sein?
Die Widerstände in AVR042 Fig. 4-2 sind ganz normale Widerstände.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Felix N. schrieb:
> Das wäre natürlich auch sinnvoll für meine Platine gewesen. Aber da es
> sich ja nur um ein "privat projekt" handelt ohne irgendwelchen
> Firmenbezug. Also nur ich die Platine programmiere etc.. Geht dort ehr
> eine sehr geringe Gefahr von aus das jemand ein Programmer wie den Atmel
> ICE mit normalen ICSP Kabel anschließt und sich versehentlich was
> abschießt. Aber natürlich zugegeben nicht die besten Vorrausetzungen.

Diese falsche Belegung wird Dich lebenlang verfolgen – egal, ob privat 
oder gewerblich, spätestens dann, wenn man sich einen ordentlichen 
Programmer mit solchen fertigen Steckern besorgt, was ich Dir übrigens 
nur sehr empfehlen kann, weil man damit direkt in der IDE arbeiten kann, 
wird man sich ärgern, dass es nicht sofort passt und man immer zu 
irgendeinem selbstgebastelten Adapter greifen muss und sich damit 
zusätzliche Fehlerquellen wie Übergangswiderstände und Wackelkontakte 
einlädt. Und so wird das Murmeltier jedes mal beim nächsten 
Leiterplattenentwurf, der irgendwann mal schon kommen wird, einen schön 
grüßen. Man kann Fehler vermeiden, wenn man alles dreimal prüft, sich 
sehr viele Dokus durchliest und sehr viel Erfahrung angesammelt hat, man 
kann Fehler aber auch korrigieren, wenn sie schon passiert sind oder man 
im Nachhinein leider feststellen muss, dass eine gewisse Idee in der 
Vergangenheit nicht optimal war. Am Ende des Tages ist es aber nicht 
meine Steckkombination, die ich da benutzen muss, insofern geht mich das 
nichts an.

[Felix N. (felix_n888)]

So ich habe erstmal gute Nachrichten!

Die Platine funktioniert komplett :) Es handelt sich nicht um ein 
Hardware oder Softwarefehler auf der Mikrocontroller Seite sondern 
scheinbar wohl ehr um ein Fehler an meinem Computer selbst.

Ich hatte eine zweite minimale Version der Platine aufgebaut nur mit der 
Stromversorgung und dem Mikrocontroller ohne I2C Sensoren, RS485 Treiber 
und so weiter. Hab ein neues Projekt in AS7 erstellt wo ich nur die PWR 
LED blinken gelassen habe. Zuvor nach mittels avrdude, in der Windows 
Powershell, die Fuses gebrannt. Alles gut. Das erste Programm 
hochgeladen ging auch noch alles.

Dann hab ich nur das delay beim blinken geändert und auf einmal ging 
wieder nichts die LED blinkte nicht mehr und ich bekam von avrdude ein 
Verifizierungsfehler aufm FLASH. Kam sonst nicht war irgendwie komisch. 
Hab dann irgendwann mal den Arduino UNO as ISP Programmer verwendet und 
auf einmal ging es wieder mit dem USBasp wieder nicht. Nach einer Pause 
und einem kompletten Neustart meines Computers funktionierte es auch 
wieder mit dem USBasp und es kam kein Verifizierungsfehler mehr. Ich 
musst ja erstmal den libusb-k Treiber mittels Zadig installieren das 
avrdude den USBasp überhaupt erstmal erkannt hat.

Scheinbar wohl ein Windows Treiberproblem oder so keine Ahnung. Mit dem 
Arduino als ISP konnte ich auch den Code mit dem RS485 Teil hochladen 
und die LED blinkte sofort wieder. Nun ja es gab auch noch ein Fehler im 
Schaltplan ich habe zwar die USART0_RX und TX korrekt am ATMega328PB 
beschriftet jedoch bei der Übergabe an das "RS485-Bus Schaltbild" 
versehentlich gekreuzt so das TX vom AVR auf dem Empfangs Pin des 
THVD1330 lagen deshalb funktioniert das auch nicht. Hab nun die 
Leitungen nochmal gekreuzt und nun bekomme ich auch Daten über RS485.

Die I2C Sensoren funktionieren ebenfalls alle und liefern aktuell 
plausible Werte über RS485 an den Computer, der Code läuft aktuell seit 
knapp 1,5 Stunden stabil. Hier mal ein Ausschnitt:

Co2: 426ppm
SGP-Ticks: 34170 - VOC Index: 285
BME Temp: 28.1*C - Hum: 30 %RH

Gregor J. schrieb:
> was ich Dir übrigens
> nur sehr empfehlen kann

Ja da hast du natürlich recht. Ich denke ich werde da mal in den sauren 
Apfel beißen und mir ein Atmel ICE zulegen ist natürlich nicht ganz so 
Attraktiv mit knapp 100€ aber damit gehts wahrscheinlich am besten.

Mein Ursprünglicher Plan war es ja tatsächlich auch ein STM32 wieder 
zunehmen aber ich hatte damals kein preislich guten gefunden(<2€) da ich 
vor habe 7-10 Stk dieser Sensoren zubauen und dann waren die STM32 mit 
4-5€ Stückpreis nicht mehr so attraktiv. Dafür der ATMega328PB mit 
1,5€/Stk oder so. Mittlerweile hab ich sogar noch ein STM32G0 war es 
glaubig für 1,6€/Stk gefunden. Naja egal.

Ob S. schrieb:
> Wie soll das sein können? Du hast hier

Es war nur ne Vermutung

Gregor J. schrieb:
> Diese falsche Belegung wird Dich lebenlang verfolgen

Gut da ich ja eh vor habe mehrere dieser Sensor Platinen am Ende 
einzusetzen und das sowieso erstmal nur der "Prototype" ist werde ich 
dann nochmal eine Rev 2.0 erstellen mit folgenden Änderungen:

- Richtige ICSP Pin Belegung
- 100nF und Schutzdiode am RESET pin (Wobei die Schutzdiode ja 
HV-Programming nicht mehr möglich macht korrekt?)
- USART0 RX/TX Leitungen richtig anschließen
- ggf. noch Schutzwiderstände in der SPI-Leitung die man ja sonst bei 
0805 auch mit Zinn brücken kann wenn nicht benötigt

Trotzdem vielen Dank an euch alle :)

Mfg

[Hmmm (hmmm)]

Felix N. schrieb:
> Atmel ICE zulegen

Felix N. schrieb:
> 100nF und Schutzdiode am RESET pin

Schlechte Idee, der Kondensator versaut Dir die DebugWIRE-Kommunikation. 
Der 10k-Widerstand reicht normalerweise völlig aus und ist auch keine 
"minimalistische Notlösung", siehe AVR042.

Felix N. schrieb:
> Wobei die Schutzdiode ja HV-Programming nicht mehr möglich macht
> korrekt?

Solange man vor dem Setzen der Fuses nachdenkt, braucht man 
HV-Programming ohnehin nie.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Felix N. schrieb:
> - 100nF und Schutzdiode am RESET pin (Wobei die Schutzdiode ja
> HV-Programming nicht mehr möglich macht korrekt?)

Das habe ich bereits alles sehr genau erläutert und falls Du HV oder 
debugWire tatsächlich doch haben möchtest (wird in dem PDF-Auszug, den 
ich bereits hochgeladen habe, auch erwähnt), kann man die störenden 
Bauteile auch optional über kleine Lötjumper trennbar machen – auf 
einigen meiner neuen Entwürfe, wo reichlich Platz vorhanden ist, werde 
ich das wahrscheinlich auch so optional anbieten. Ich werde demnächst 
aber auch testen und mir mit einem Oszilloskop anschauen, mit welcher 
Kapazität am Resetpin debugWire überhaupt noch funktioniert, um die 
Grenze zu erkunden und wieviel von dem Geschriebenen dann Mythos ist 
oder der Wahrheit entspricht, damit eine gewisse Kapazität am 
Reseteingang trotzdem bleiben darf – bei Störungen können selbst 470pF 
oder gar 100pF sehr hilfreich sein. Die HV-Programmierung braucht man so 
gut wie nie in einem Leben, wenn man das Bit 'HIGH.SPIEN' in den Fuses 
grundsätzlich nicht anfasst – über die SPI-Verbindung lässt sich das 
aber nicht abschalten, wie in der Fußnote erwähnt wird, was ich eben mal 
bei meinem 328PB riskiert und ausprobiert habe: wenn man die Fuses nach 
dem Vorgang wieder einliest, ist es wie am Anfang, der ISP-Zugang ist 
also nicht gesperrt (Screenshots angehängt). DebugWire ist etwas 
gewöhnungsbedürftig, vor allem das Umschalten, und man sollte auch 
wissen, dass es mit Einschränkungen verbunden ist, um es mal etwas 
euphemistisch ausdrücken zu wollen, kann in manchen, seltenen Fällen 
aber auch sehr hilfreich sein.

Da nun soweit alles funktioniert, wünsche ich noch viel Erfolg bei der 
restlichen Arbeit und dem eventuellen Kauf von Zubehör, um sich das 
Leben künftig deutlich leichter zu machen.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Noch eine Ergänzung:

Am Bit 7 'RSTDISBL' im High-Byte der Fuses sollte man nicht 
herumspielen, denn dieses Bit kann man über ISP wirklich ändern und 
würde sich dann wohl aussperren, da der Resetpin grundsätzlich nötig 
ist, um sich mittels ISP mit dem µC zu verbinden. Das kann schnell 
passieren, wenn man die Fuses als Bytezahlen mit irgendeinem Programm 
blind schickt und nicht aufgeschlüsselt über die IDE die Fuses 
programmiert. Hier werde ich zu gegebenener Zeit auch mal ein paar Tests 
machen, um zu schauen, ob man sich mit einem Trick im Falle eines 
Aussperrens vielleicht doch noch einklinken kann – beschrieben ist das 
aber nirgendwo in den Datenblättern. Für solche Versuche muss ich aber 
explizit ein neues 328PB-Board und eine zweite Adapterplatine für den 
Snap bestücken und präparieren.

Mit der Wahl einer falschen Taktquelle kann man sich natürlich auch 
aussperren, aber das ist dann doch etwas anderes und auch deutlich 
einfacher zu lösen.

[900ss (900ss)]

Gregor J. schrieb:
> ob man sich mit einem Trick im Falle eines Aussperrens vielleicht doch
> noch einklinken kan

Bei einem ATMega8 funktioniert das nicht. Habe hier eine Schaltung wo 
der Reset-Pin als IO genutzt wird und da bin ich auf "einfachem" Weg 
nicht wieder rangekommen um eine andere SW aufzuspielen. Ich hab die 
Schaltung geändert und den Pin mit Resetfunktion so gelassen bei einem 
neuen Controller.