Moin Leute, ich habe hier eine Schaltung mit einem Atmega 32U4. Letzterer kommuniziert mit einem PC. Die Schaltung und auch die Software habe ich hier tausendfach getestet und es gab keinerlei Schwierigkeiten. Nun bleibt der uC bei einem Kunden immer wieder hängen. Die Leiterplatte habe ich schon ausgetauscht, sodass ich etwa eine schlechte Lötstelle als Fehler ausschließen möchte. Leider scheint der Fehler wie zufällig aufzutreten. Ich kann keine Ursache ausmachen - auf keine zeitliche - einmal trat der Fehler hier nun auch auf aber ohne, dass ich eine Ursache erkennen konnte... Darum meine Frage: Weiß jemand eine Quelle für eine Art Checkliste was bei einem hängenden uC zu prüfen ist?
Gast
#6386431
In Zeile 42 schreibst du über Arraygrenzen hinweg.
Gast
#6386433
Ja ich seh's auch ganz deutlich.
Gast
#6386435
Tim B. schrieb: > Darum meine Frage: Weiß jemand eine Quelle für eine Art Checkliste was > bei einem hängenden uC zu prüfen ist? - Resetbeschaltung - Abblockung - Versorgung gepuffert - Programmfehler (Atomic, Arraygrenzen z.B.) - Taktausfall (wegen "bleibt stehen") - Endlos-While-Schleifen die etwas pollen, Stichwort Timeout einbauen Kannst du "bleibt hängen" näher spezifierenz?
Gast
#6386438
Hier mal ein Beispiel, wie man ein Timeout einbaut:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Arduino Fanboy D. schrieb: > In Zeile 42 schreibst du über Arraygrenzen hinweg. YMMD ;-) Old-Papa
Gast
#6386442
Meine Glaskugel ist mir gestern explodiert und ist bei der Reparatur. deswegen veröffentliche hier bitte den Code der auf dem Controller läuft.
Gast
#6386446
Manchmal ist es wirklich eine Strafe einen Eröffnungs-Beitrag hier lesen zu müssen. Leider merkt man das erst wenn man ihn gelesen hat sonst könnte man die Situation ja sogar vermeiden.
Vielen Dank. Also es ist so, dass ich nur sehr begrenzt progrtammieren kann, weshalb ich sowohl beim Arduino-Sketch sehr viel Hilfe hatte und an der PC-Software gar nicht beteiligt war. Den Arduino-Sketch werde ich mir wegen der Arraygrenzen gleich mal zur Brust nehmen aber soweit ich mich erinnere hat die PC-Software alle "Rechen- und Merkaufgaben" übernommen. Außerdem müsste die Software dann ja zeitlich immer nach einer bestimmten Anzahl von Schreibvorgängen - also auch nach einer bestimmten Zeit abstürzen. Die läuft aber mal über Nacht problemlos und stürzt dann wieder nach ein paar Minuten ab. Bemerkbar macht sich der Absturz dadurch, dass der uC nichts mehr schaltet und die PC-Software einfriert. Sobald der uC neu gestartet wird läufts wieder. Bevor ich jetzt lange suche: Ist vielleicht das Aktivieren des Watchdogs über die Fuses eine Lösung (Watchdog timer always on; [WDTON=0])? Wird der uC dann automatisch neu gestartet wenn er abstürtzt? Eigentlich würde ich erst mal checken, ob der uC auch dann abstützt, wenn er nicht mit dem PC verbunden ist um herauszufinden ob vielleicht etwas mit der Kommunikation nicht stimmt. Das ist aber natürlich schwierig, wenn sich der Fehler nicht reproduzieren lässt...
Gast
#6386449
Dunkelseher schrieb: > Manchmal ist es wirklich eine Strafe einen Eröffnungs-Beitrag > hier lesen zu müssen. Wieso? Der TO hat doch nur nach einer allgemeinen Vorgehensweise gefragt. Also allgemein: - Den Fehler eingrenzen!
Beitrag #6386452 wurde von einem Moderator gelöscht.
Gast
#6386461
Tim B. schrieb: > Ist vielleicht das Aktivieren des Watchdogs > über die Fuses eine Lösung (Watchdog timer always on; [WDTON=0])? Wird > der uC dann automatisch neu gestartet wenn er abstürtzt? Nein, der Watchdog ist das allerletzte Mittel, den µC wieder zu holen, wenn man selber keinen Einfluss mehr nehmen kann. Ein Programm, dass auf einen WDT angewiesen ist, damit es läuft ist ein schlechtes Programm.
Das ist der Arduino-Sketch:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
128 | |
129 | |
130 | |
131 | |
132 | |
133 | |
134 | |
135 | |
136 | |
137 | |
138 | |
139 | |
140 | |
141 | |
142 | |
143 | |
144 | |
145 | |
146 | |
147 | |
148 | |
149 | |
150 | |
151 | |
152 | |
153 | |
154 | |
155 | |
156 | |
157 | |
158 | |
159 | |
160 | |
161 | |
162 | |
163 | |
164 | |
165 | |
166 | |
167 | |
168 | |
169 | |
170 | |
171 | |
172 | |
173 | |
174 | |
175 | |
176 | |
177 | |
178 | |
179 | |
180 | |
181 | |
182 | |
183 | |
184 | |
185 | |
186 | |
187 | |
188 | |
189 | |
190 | |
191 | |
192 | |
193 | |
194 | |
195 | |
196 | |
197 | |
198 | |
199 | |
200 | |
201 | |
202 | |
203 | |
204 | |
205 | |
206 | |
207 | |
208 | |
209 | |
210 | |
211 | |
212 | |
213 | |
214 | |
215 | |
216 | |
217 | |
218 | |
219 | |
220 | |
221 | |
222 | |
223 | |
224 | |
225 | |
226 | |
227 | |
228 | |
229 | |
230 | |
231 | |
232 | |
233 | |
234 | |
235 | |
236 | |
237 | |
238 | |
239 | |
240 | |
241 | |
242 | |
243 | |
244 | |
245 | |
246 | |
247 | |
248 | |
249 | |
250 | |
251 | |
252 | |
253 | |
254 | |
255 | |
256 | |
257 | |
258 | |
259 | |
260 | |
261 | |
262 | |
263 | |
264 | |
265 | |
266 | |
267 | |
268 | |
269 | |
270 | |
271 | |
272 | |
273 | |
274 | |
275 | |
276 | |
277 | |
278 | |
279 | |
280 | |
281 | |
282 | |
283 | |
284 | |
285 | |
286 | |
287 | |
288 | |
289 | |
290 | |
291 | |
292 | |
293 | |
294 | |
295 | |
296 | |
297 | |
298 | |
299 | |
300 | |
301 | |
302 | |
303 | |
304 | |
305 | |
306 | |
307 | |
308 | |
309 | |
310 | |
311 | |
312 | |
313 | |
314 | |
315 | |
316 | |
317 | |
318 | |
319 | |
320 | |
321 | |
322 | |
323 | |
324 | |
325 | |
326 | |
327 | |
328 | |
329 | |
330 | |
331 | |
332 | |
333 | |
334 | |
335 | |
336 | |
337 | |
338 | |
339 | |
340 | |
341 | |
342 | |
343 | |
344 | |
345 | |
346 | |
347 | |
348 | |
349 | |
350 | |
351 | |
352 | |
353 | |
354 | |
355 | |
356 | |
357 | |
358 | |
359 | |
360 | |
361 | |
362 | |
363 | |
364 | |
365 | |
366 | |
367 | |
368 | |
369 | |
370 | |
371 | |
372 | |
373 | |
374 | |
375 | |
376 | |
377 | |
378 | |
379 | |
380 | |
381 | |
382 | |
383 | |
384 | |
385 | |
386 | |
387 | |
388 | |
389 | |
390 | |
391 | |
392 | |
393 | |
394 | |
395 | |
396 | |
397 | |
398 | |
399 | |
400 | |
401 | |
402 | |
403 | |
404 | |
405 | |
406 | |
407 | |
408 | |
409 | |
410 | |
411 | |
412 | |
413 | |
414 | |
415 | |
416 | |
417 | |
418 | |
419 | |
420 | |
421 | |
422 | |
423 | |
424 | |
425 | |
426 | |
427 | |
428 | |
429 | |
430 | |
431 | |
432 | |
433 | |
434 | |
435 | |
436 | |
437 | |
438 | |
439 | |
440 | |
441 | |
442 | |
443 | |
444 | |
445 | |
446 | |
447 | |
448 | |
449 | |
450 | |
451 | |
452 | |
453 | |
454 | |
455 | |
456 | |
457 | |
458 | |
459 | |
460 | |
461 | |
462 | |
463 | |
464 | |
465 | |
466 | |
467 | |
468 | |
469 | |
470 | |
471 | |
472 | |
473 | |
474 | |
475 | |
476 | |
477 | |
478 | |
479 | |
480 | |
481 | |
482 | |
483 | |
484 | |
485 | |
486 | |
487 | |
488 | |
489 | |
490 | |
491 | |
492 | |
493 | |
494 | |
495 | |
496 | |
497 | |
498 | |
499 | |
500 | |
501 | |
502 | |
503 | |
504 | |
505 | |
506 | |
507 | |
508 | |
509 | |
510 | |
511 | |
512 | |
513 | |
514 | |
515 | |
516 | |
517 | |
518 | |
519 | |
520 | |
521 | |
522 | |
523 | |
524 | |
525 | |
526 | |
527 | |
528 | |
529 | |
530 | |
531 | |
532 | |
533 | |
534 | |
535 | |
536 | |
537 | |
538 | |
539 | |
540 | |
541 | |
542 | |
543 | |
544 | |
545 | |
546 | |
547 | |
548 | |
549 | |
550 | |
551 | |
552 | |
553 | |
554 | |
555 | |
556 | |
557 | |
558 | |
559 | |
Beitrag #6386472 wurde von einem Moderator gelöscht.
Gast
#6386475
Macht das Programm zufällig nach ~50 Tagen Probleme?
Gast
#6386478
Funkdeppjäger schrieb im Beitrag #6386472: > Sag mal glaubst du wirklich, dass sich einer deinen Schrott ansieht und > deine Hausaufgaben macht? Ausserdem gehört der Text in einen Anhang und nicht in den Beitrags-Textkörper! Siehe: Wichtige Regeln - erst lesen, dann posten! .... Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Tim B. schrieb: > Nun bleibt der uC bei einem Kunden immer wieder hängen. Softwarefehler. Oder andersrum: die Software kommt nicht damit klar, dass da ein kleiner, fies kurzer Störimpuls kommt, wenn jemand das Licht ausschaltet. Tim B. schrieb: > Das ist der Arduino-Sketch: Sowas bitte als Anhang (wie in der Anleitung über jeder Texteditbox geschrieben]! Oder pack den C-Code wenigstens in [C] Tags. Dann gibts Syntax-Highlighting gratis. > short adc = 0; /// temporär für Berechnungen usw. Wenn du in einer Funktion eine temporäre Variable brauchst, warum deklarierst du die dann nicht dort, wo sie hingehört? > /// Das ist die Lizenz Netter Ansatz... ;-)
Gast
#6386482
Tim B. schrieb: > Also es ist so, dass ich nur sehr begrenzt progrtammieren kann Tim B. schrieb: > bei einem Kunden Aha.
Ingo Less schrieb: > Macht das Programm zufällig nach ~50 Tagen Probleme? Leider schon wesentlich früher. Beim Kunden tritt das Problem anscheinen schon nach ein bis zwei Stunden auf.
Tim B. schrieb: > Außerdem müsste die Software dann ja zeitlich immer nach einer > bestimmten Anzahl von Schreibvorgängen - also auch nach einer bestimmten > Zeit abstürzen. Eben nicht unbedingt nach einer bestimmten Zeit: Es könnte z.B. sein, dass ein Interrupt, wenn er an einer bestimmten Stelle des Hauptprogramms auftritt, den Fehler produziert. Dann ist das ein Zufallsgenerator: Zeitpunkt des Interrupts und Laufzeit der Hauptschleife. Solche Fehler sind nur schwer zu finden. Da hilft oft nur Durcharbeiten aller kritischen Stellen im Programm. Und um zu wissen, welche Stellen kritisch sind, braucht dann schon Erfahrung.
Tim B. schrieb: > Die Schaltung Lass doch mal sehen. Und das Layout. Und den Aufbau. Nicht, dass da doch auch noch ein Problem drin ist... ;-)
Gast
#6386490
Kommt evtl. so viel Noise über die serielle Schnittstelle, dass diese sich gestört fühlt und hier
1 | |
2 | |
3 | |
4 | |
hängen bleibt?
Lothar M. schrieb: > Tim B. schrieb: >> Die Schaltung > Lass doch mal sehen. Und das Layout. Und den Aufbau. Nicht, dass da doch > auch noch ein Problem drin ist... ;-) Das ist das Layout. Das ist aber vermutlich so erst mal schwer zu verstehen...
Ingo Less schrieb: > Kommt evtl. so viel Noise über die serielle Schnittstelle, dass diese > sich gestört fühlt und hier
1 | |
2 | |
3 | |
4 | |
5 | |
> hängen bleibt?
Das würde erklären warum das Ding beim Kunden abstürzt und bei mir
nicht. Aber we kann man dem begegnen? Kabel besser schirmen?
Ingo Less schrieb: > Tim B. schrieb: >> Ist vielleicht das Aktivieren des Watchdogs >> über die Fuses eine Lösung (Watchdog timer always on; [WDTON=0])? Wird >> der uC dann automatisch neu gestartet wenn er abstürtzt? > Nein, der Watchdog ist das allerletzte Mittel, den µC wieder zu holen, > wenn man selber keinen Einfluss mehr nehmen kann. Ein Programm, dass auf > einen WDT angewiesen ist, damit es läuft ist ein schlechtes Programm. Irgendwie habe ich die Tendenz das trotzdem so zu lösen. Zumindest dann, wenn der Fehler durch Störimpuse hervorgerufen wird. Dazu müsste ich aber die Ursache kennen...
Gast
#6386509
Serial ist virtuell. Da reicht dann auch ein virtueller Schirm. ;-) Im Ernst: Ich kann das Programm kaum lesen und noch viel weniger verstehen. Das ist C++. Damit lässt sich viel schöner modularisieren, als es hier zu sehen ist. Auch behagen mit die Defines nicht so, die meisten lassen sich sicherlich ersetzen.
Gast
#6386512
Ich vermute einfach mal dass ein EMV-Problem vorliegt. Die Schaltung in ein Gehäuse welches auch geerdet ist (Schukostecker) und eine gründlich entstörte Spannungsversorgung helfen dort fast immer. bzw. hast du die USB-Versorgung so wie in den Application Notes geschrieben, entstört? Den Plan haben wir ja nicht. Der Watchdog hilft den Gerät wieder auf die Beine, aber das ist eine sehr "dirty" Lösung, die man nur macht wenn wirklich nichts mehr geht. o/ Anselm
Sieht so aus als ob über die fetten Tracks richtig Strom fließt und die winzigen Leitungen quer dazu gehen dann vom/zum µC. Hm, ob das nicht Probleme macht ? Was sind das für dicke 10-polige Teile ? Shunts ? Gehört das zum oekotrainer.de ?
Thomas W. schrieb: > Sieht so aus als ob über die fetten Tracks richtig Strom fließt > und die > winzigen Leitungen quer dazu gehen dann vom/zum µC. Hm, ob das nicht > Probleme macht ? > Was sind das für dicke 10-polige Teile ? Shunts ? An die Leisterplatte ist ein 40 Ah Akku und ein 1000 W Wechselrichter angeschlossen. Es fließt also tatsächlich ein sehr großer Strom. Der Akku wird über 10 Eingänge geladen. Die 4 MosFETs können die Eingänge im Fehlerfall trennen. Der Strom der 10 Eingänge wird jeweils über einen Hallsensor gemessen - ebenso der Strom zwischen Akku und Wechselrichter. Die Spannung für den uC wird mit einem LM317 erzeugt. Ich bin davon ausgegangen - dass der Akku mit dem niedrigen Innenwiederstand hier für stabilie Verhältnisse sorgt. Außerdem gibt es ja auch diverse Kondensatoren parallel zur Spannungsversorgung direkt am uC. Wenn es hier Schwierigkeiten gäbe würde der uC ja auch im Testlauf ständig abstützen. Das Problem tritt aber nur beim Kunden auf...
Ich würde die Reset Leitung des Micros (ISP Verbinder) ja nicht unbedingt durch die Hälfte der Strompfade mitten durchrouten. Für mich sieht das so aus. als ob da schön viele Antennen sind die Dir alle möglichen Signale einfangen...: - Ich würde die Filter für die HAL Sensoren direkt am Mikrocontroller plazieren - Die Eingänge groundseitig abzutrennen ist auch sehr mutig. Was passiert im Fehlerfall? Ist die Eingangsspannung irgendwie begrenzt? Denn nach dem Abtrennen fehlt ja die Last durch den Akku. - Bei solchen Strömen sollte man Leistungsteil und Steuerteil separieren. - In die HAL Sensoren koppeln die Magnetfelder der Nachbarleitungen und auch der eigenen Leitungen zusätzlich ein. Im Datenblatt steht wie man es richtig macht
Tim B. schrieb: > Das ist das Layout. Das ist aber vermutlich so erst mal schwer zu > verstehen... Es ist schon mal schwer zu erkennen. Poste das mal als PNG und möglichst großformatig. Da gibts auch eine Checkbox, dass das Bild nicht verkleinert werden soll. Zum Verständnis trägt dann der Schaltplan bei... ;-) Tim B. schrieb: > Aber we kann man dem begegnen? Kabel besser schirmen? Die Software fehlertolerant machen. Und die Hardware mal im Labor ein wenig mit EMV belasten. Du schreibst da auch was von USB. Das ist beim EMV-Test bei mir immer der erste Bus, der abkotzt. Ich habe für die Schaltungsinbetriebnahme für begleitende "EMV-Vortests" einfach einen Viehtreiber ähnlich dem "Kerbl Handyshock" gekauft. Dazu brauche ich dann noch eine Metallplatte und eine Kunststoffplatte. Jetzt kommt das Metallblech auf den Labortisch, die Kunstoffplatte als Isolator drauf und auf diese Kunststoffplatte gut von der Metallplatte isoliert meine neue Schaltung. Die lasse ich laufen und zünde mit dem Viehtreiber auf die Metallplatte (einfach rein und gleich wieder raus, nicht in die Schaltung, die wäre sofort kaputt). Wenn meine Schaltung und die Software das überstehen, dann kann ich mich ins Feld trauen. Dieser Aufbau ist der "Burst-Test des kleinen Mannes"... ;-)
Gast
#6386584
Tim B. schrieb: > Das ist das Layout. Das ist aber vermutlich so erst mal schwer zu > verstehen... So auf den ersten Blick wird das nie funzen. Du hast einfach zu hohe Schaltströme zu dicht an empfindlicher Elektronik. Besser auf zwei Leiterplatten verteilen. Softwarefehler kann man mit einem Zähler eingrenzen den man entweder nach dem Reset ausgibt oder bei Aufruf oder zwischen der Routinen.
Gast
#6386591
Na wenn schon die schwindelige PC Software einfriert, weil sie durcheinanderkommt, dann wird der Arduino Profi sich wohl eher gar nicht um Fehlersituationen, deren Erkennung und Behandlung Gedanken gemacht haben. Das ist alles mit der heißen Nadel gestrickt, ausnahmslos....
Tim B. schrieb: > Das würde erklären warum das Ding beim Kunden abstürzt und bei mir > nicht. Aber we kann man dem begegnen? Kabel besser schirmen? besser wäre doch die empfangenen Daten auf Plausibilität zu prüfen kommen da Zeichen die man erwartet? isprint isnum isalpha wären mögliche Tests wenn unplausible Zeichen kommen, wird der Buffer geleert? werden unplausible Zeichen weiter eingelesen? Droht Bufferüberlauf?
Gast
#6386642
Tim B. schrieb: > Also es ist so, dass ich nur sehr begrenzt progrtammieren kann, weshalb > ich sowohl beim Arduino-Sketch sehr viel Hilfe hatte und an der > PC-Software gar nicht beteiligt war. Tim B. schrieb: > Das Problem tritt aber nur beim Kunden auf... Klingt nach Volkswagen ;). Tu dir selbst einen gefallen und nimm das Produkt schnell vom Markt, bevor sich jemand die Bude damit abfackelt. Ich vermute mal deine Bastelei hat keine EMV Tests gesehen. Genausowenig Vertrauen erweckt dein Layout. Sprint Layout ist einfach mal nicht das Programm der Wahl wenn man kundenfähige Produkte entwicklen möchte. Wie hälst du Schaltplan und Layout syncron? Oder gibt es gar keinen Schaltplan und es wurde direkt drauf loslayoutet? Wenn ich lese, dass du 4 Mosfets schaltest im Fehlerfall... Wie wurde der Fehlerfall in der FMEA bewertet? Welches Performance Level soll deine Sicherheitsschaltung erfüllen? Wie hast du den Fall simuliert? Wie hast du den Fall getestet? Solche Sachen wie du habe ich vor 10 Jahren auch gebaut, ich hatte die gleichen Probleme und wäre nicht im Traum darauf gekommen das zu verkaufen, da ich wusste das es zwar halbwegs funktioniert, aber nicht die Zuverlässigkeit an den Tag legt, die ich von so einem Produkt erwarten würde. Aber zurück zum Problem. Schaltet dein Kunde während des Betriebs Leuchtstoffröhren? Wie sicher bist du dir, dass es der µC ist? Hängt sich evenutell die Schnittstelle am PC auf? (Hatte ich bei mir privat, da war das PC Netzteil billiger Kernschrott und die Spannungen waren sehr instabil) Es soll kein Bashing deines Produkts werden, bitte bleib unbedingt dran an der Elektronik. Aber das was du hier präsentiert hast ist weder tauglich noch sicher. Im Interesse deiner Kunden und deiner Freiheit: Nimm das Produkt vom Markt, entwickel es neu, teste und validiere es und dann vermarkte es. Nutze KICAD für das Layout (Open Source), lasse Prototypen fertigen und dann teste sie systematisch oder gib sie zu einem Softwaretester (ISTQB). Falls das finaziell nicht drin ist, dann teste du die Funktionen. Was passiert wenn deine serielle Schnittstelle Werte von 0 bis 10 erwartet, du aber ein "ü" sendest? Was passiert mit Funktionen die ein uint8_t erwarten, wenn stattdessen ein "-3" übergeben wird. Stichwort: Error Handling. VG Paul
Ich hatte auch mal ne Schaltung, ein Step-Down, bei dem bei zu viel Power die serielle Schnittstelle am PC abgestürzt ist... Also zu viel EM können die nicht vertragen. Bei meinem ST-Link verliere ich regelmäßig die Verbindung zum uC wenn ich ne Schaltung habe, die zu sehr sendet bzw. größere Ströme im Spiel sind!
Gast
#6386864
Joachim B. schrieb: > besser wäre doch die empfangenen Daten auf Plausibilität zu prüfen > kommen da Zeichen die man erwartet? > > isprint > isnum > isalpha > > wären mögliche Tests > > wenn unplausible Zeichen kommen, wird der Buffer geleert? Falls die Zeichen nicht palausibel sind, kommt noch "ISNICHWAHR!" in Frage.
Ingo Less schrieb: > Nein, der Watchdog ist das allerletzte Mittel, den µC wieder zu holen, > wenn man selber keinen Einfluss mehr nehmen kann. Ein Programm, dass auf > einen WDT angewiesen ist, damit es läuft ist ein schlechtes Programm. Die große Frage ist das Betriebssystem. preemtiv oder kooperativ? Der Watchdog sollte nicht nur einen Wiederanlauf ermöglichen, sondern auch Debuginforationen sichern. Zu diesen Informationen zählt ein Schnappschuß der Register insbesondere des SP und PC. Der PC läßt auf die Stelle des Hängers schließen. Auch andere "Exceptions", z.B. Division durch Null, sollten so behandelt werden. Für die Implementierung macht preemtiv oder kooperativ einen großen Unterschied aus. Bei kooperativen BS löst jede Dauerschleife eine WD-Restart aus. Bei preemtiven BS, wie Linux, können einzelne Prozesse oder Threads hängen. Hier ist es sinnvoll Überwachungsprozesse zu implementieren, die die zu überwachenden Prozesse auf Plausibiltät bzw. korrekten Ablauf prüfen.
Gast
#6386892
ich persönlioch bin ja schon kein Fan davon eine schon grün leuchtende LED im nächsten "Arbeitsschritt" auf Grün zu schalten, ich finde "schalter" egal welche, ob LEDS der sonstige outputs sollte NUR geschaltet werden wenn sich der Zustand ändert. und sowas:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
finde ich auch fürchterlich nutzlos wenn eine funktion ausschliesslich einmalig im setup() aufgerufen wird, ist sie mMn zu entfernen und ihr code ins setup zu schreiben; insbesondere wenn es nur ein stumpfer Einzeler ist. Egal ich behaupte der Fehler taucht in der ds auf, die konvertierung via ds.write(0x44) kann ne Sekunde dauern, millis laufen weiter, schlimmer noch das Konversionsergebniss wird von Dir vollständig verworfen
1 | |
2 | |
3 | |
4 | |
5 | |
ist also mindestens 'übereilt'
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
wäre der sicherere weg. heisst aber dass alle "timer" die Du has immer auslösen MÜSSEN (alle kleiner einer Sekunde) deswegen solltest Du sie entsprechend anpassen. Apropos...
1 | |
ist natürlich auch eher unsinnig Im Grunde kannst Du UPDATE_TIME_A fast genausogut komplett weglassen und den Code bei jedem Schleifendurchlauf ausführen, der braucht selbst in etwa 2.5-3ms würd ich schätzen. spielt aber keine Rolle, denn ab dem ersten triggern von temperaturschutz() ist jede folgende loop() eh komplett auf "max" und alle vergleiche triggern darunterliegenden Code Mach mal den Test wie folgt:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
(sollte in den ersten zehn sekunden die Zweit zwischen zwei Loop durchläufen veranschaulichen) und achte mal darauf wie gross der Abstand zwischen den letzten paar durchläufen ist, ich möchte wetten, dass Du überhaupt nur 10 zeitangaben über den serial monitor bekommst, (alles andere würde mich bei dem oneWire protokoll echt wundern) 'sid
Leute, vielen lieben Dank für die vielen Beiträge und Tipps. Ich werde am Montag weiter machen. Jetzt raucht der Kopf. Eines konnte ich allerdings noch feststellen: Ich habe den Watchdog aktiviert und der uC ist trotzdem hängen geblieben. Ich habe darum nun die Kommunikation mit dem PC im Verdacht. Eure Tipps werde ich mir natürlich trotzdem anschauen - vieles davon betrifft ja auch diesen Punkt. Das doofe an dieser ganzen Sache ist, dass ich den Fehler nicht auslösen kann und darum immer Stunden lang warten muss bis der Fehler auftritt. EMV-Quälen habe ich mangels Weidezaungerät jetzt mal versucht wie hier beschrieben. Dabei habe ich mit dem Relais, der Leuchtstofflampe und einer alten Bohrmaschine direkt über dem uC rumhantiert. Das hat ihm alles nix ausgemacht :-)
Gast
#6386919
Sowohl die Schaltung als auch das Programm sind komplex. Ich würde drei Dinge versuchen: a) Kläre, ob das Ding ohne große Lastströme zuverlässig funktioniert. b) Gebe jede Menge Logmeldungen auf einem zweiten seriellen Port aus und zeichne diese in eine Datei auf. Diese Meldungen sollten einen Hinweis darauf geben, an welcher Stelle das Programm hängen bleibt und was kurz vorher passierte. c) Reduziere das Programm auf weniger, um den Fehler einzukreisen. Man könnte sich da mal ganz dumm stellen und einfach mal jede Sekunde "Hallo" ausgeben. Dann mal schauen, ob das wenigstens stabil läuft. Danach könnte man Schaltvorgänge im Lastkreis manuell auslösen, um zu sehen, ob diese sich negativ auswirken. Was manchmal auch Wunder wirkt: Zur Stromversorgung eine Batterie verwenden. Muss ja nicht für immer so bleiben, sondern nur, um Probleme mit dem Netzteil oder Masseschleifen auszuschließen.
Gast
#6386958
Hier wird die Variable "dauer" gar nicht benutzt:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Ich wollte das gerne zum Test compilieren, aber dazu fehlt die WS2812.h.
Stefan ⛄ F. schrieb: > Ich wollte das gerne zum Test compilieren, aber dazu fehlt die WS2812.h. Vielleicht sollte später WR_DELAY durch dauer ersetzt werden.
Stefan ⛄ F. schrieb: > while( ( millis() - jetzt ) < WR_DELAY ){} Ich nehme an, mills() liefert den Wert des Systemtickers zurück und dieser ist auch vom Typ unsigned long. Was passiert nach einem Überlauf von 0xffffffff auf 0 ? Dann gibt es sehr lange Wartezeiten, oder?
Gast
#6386988
Gerald K. schrieb: > Was passiert nach einem Überlauf von 0xffffffff auf 0 ? > Dann gibt es sehr lange Wartezeiten, oder? Nein, die zeit stimmt nach einem Überlauf immer noch. Voraussetzung ist, dass man wie hier subtrahiert.
Gast
#6386995
Gerald K. schrieb: > Was passiert nach einem Überlauf von 0xffffffff auf 0 ? > > Dann gibt es sehr lange Wartezeiten, oder? Da passiert gar nix (überraschendes). Das Prinzip heißt in der Arduinowelt "Blink without Delay". Zumindest wird in dem Beispiel das Prinzip implementiert. Und ja: Keine Problem beim Überlauf, wenn das Intervall kleiner als 49,x Tage ist
Vielleicht gibt es in der Nähe von oekotrainer.de einen Dienstleister, der sich das ganze mal anschauen möchte? Lothar M. schrieb: ... > Ich habe für die Schaltungsinbetriebnahme > für begleitende "EMV-Vortests" einfach einen Viehtreiber wie > https://www.ebay.de/itm/Viehtreiber-HandyShock-Rind-Tier-Treiber-11215/381541741059 > gekauft. Dazu brauche ich dann noch eine Metallplatte und eine > Kunststoffplatte. Jetzt kommt das Metallblech auf den Labortisch, die > Kunstoffplatte als Isolator drauf und auf diese Kunststoffplatte gut von > der Metallplatte isoliert meine neue Schaltung. Die lasse ich laufen und > zünde mit dem Viehtreiber auf die Metallplatte (einfach rein und gleich > wieder raus, nicht in die Schaltung, die wäre sofort kaputt). Wenn meine > Schaltung und die Software das überstehen, dann kann ich mich ins Feld > trauen. > Dieser Aufbau ist der "Burst-Test des kleinen Mannes"... ;-) Lothar, Du begeisterst mich. Damit wird die 61000-4-2 (ESD) ein Kinderspiel. Und auch die für die anderen Störempfindlichkeiten bekommt man ein besseres Gefühl. Ich halte gerne mal ein klingelndes Handy an Baugruppen. Gerade bei Analogschaltungen sieht man da schnell die Störempfindlichkeit. Und wenn die MCU abstürzt, bietet das Design noch viel Verbesserungspotential. Frage: weißt Du, was der Viehtreiber rausreicht? Ladespannung (1..15kV), Ladekapazität (150pF) und Ausgangsimpedanz (330R)? (Zum Vergleich, Werte aus der EN61000-4-2).
Beitrag #6387042 wurde von einem Moderator gelöscht.
Gast
#6387058
Bananensoftware : Reift beim Kunden😂😂😂👍👍
Ich habe inzwischen versucht die Schaltung nochmal mit allen möglichen EMV-Störungen zu malträtieren (auch mit der Viehschockermethode mit echtem Viehschocker :-)) aber was ich auch mache, es hat keinen Einfluss auf die Schaltung. Außerdem habe ich den Code für den uC so geändert, dass er nur kuriose Zeichenketten an den PC sendet. Das hat nur dazu geführt, dass die PC-Software kurioses anzeigt (was hier nicht weiter schlimm ist) aber kein Absturz und kein Hänger. Ich habe das while (serial.available()aus dem Code entfernt und einen einfachen Watchdog eingebaut. Vielleicht hat ersteres das Problem ja auch tatsächlich schon behoben. Sicher weiß ich das nicht, weil ich den Fehler ja doofer weise ja durch nichts auslösen konnte. Als nächstes werde ich versuchen vom PC zum uC kuriose Zeichenketten zu senden. Anschließend werde ich mich nochmal mit der ds.write(0x44)-Sache beschäftigen. Ein delay einzubauen ist hier aber keine Lösung, weil das Programm weiterlaufen muss. Da würde ich dem Temp-Sensor eher komplett deaktivieren.
Wahrscheinlich liest ja keiner mehr aber vielleicht ja auch doch:
Inzwischen hat sich herrausgestellt, dass ein defekter Wechselrichter
die Störquelle war, der zwischen Eingang GND und PE eine Spannung von
mehreren hundert Volt produziert hat.
Eine Messelektronik wird über den Akku, an den auch der Wechselrichter
angeschlossen ist, gespeist. Ein PC nimmt die Signale der Messelektronik
über eine USB-Verbindung ab. Dadurch ist der PC über die USB-Verbindung
mit dem Minus-Pol eines Akkus verbunden. Der Wechselrichter ist defekt
und liefert darum (unter Last) gemessen zwischen Minus-Pol des Eingangs
und Schutzleiter des Ausgangs, impulsweise eine sehr hohe Spannung von
>500V. An den Wechselrichter ist ein Beamer angeschlossen und verbindet,
sobald er eingeschaltet wird den Schutzleiter mit dem Gehäuse des
HDMI-Steckers. Wenn nun der HDMI-Stecker am PC eingesteckt wird, liegt
die hohe Spannung zwischen Minus USB und Gehäuse HDMI Stecker an und
sorgt offensichtlich dafür, dass die Schutzschaltung des PCs den
USB-Port lahmgelegt. Mir ist das aufgefallen, weil der USB-Port, schon
nicht mehr funktioniert hat bevor ich den HDMI-Stecker ganz eingesteckt
habe. Als ich das dann näher beobachtet habe, habe ich bemerkt, dass
beim Kontakt des HDMI-Steckers mit der Buchse Funken zu sehen sind.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.

