Hi!
Problemstellung:
Steuerungs-µC macht so alle paar Tage, manchmal nach 1-2 Wochen einen
Reset.
Vorher geht alles OK, danach auch wieder. Aber genau wegen dem Reset
bleibt Anlage stehen.
Da denkt man sich als vollblut Embedded Entwickler, da muß man mit einem
Debugger dran. Scheiße, daß man nur einen hat, den auch nur leihweise,
und die Steuerungen zufälligerweise ausfallen.
Kunde kocht. Manager machen Druck, Lieferant der Teile kuscht, kommt nur
schwer voran, und lässt sich nicht in seinen Code reinblicken. (Da es
damals vertraglich so geregelt wurde)
Erfahrungsgemäß wird daraus eine unendliche Geschichte, und der Fehler
ist unlösbar.
Was tut man in so einem Fall, um Ursache des Fehlers zu finden?
Welche Methoden habt ihr?
LG,
Martin
asteri_x schrieb:> Was tut man in so einem Fall, um Ursache des Fehlers zu finden?
Dafür gibt es eventgetriggerte Datenlogger. Und Watchdogs. Außerdem
würde ich jede CPU regelmässig selbst resetten oder durch ihr Setup
rennen lassen, um zufällige Bitfehler (Funken, Weltraumstrahlung (Soft
Errors)) zu vermeiden.
>>die Steuerungen zufälligerweise ausfallen.
Tun sie nicht. Jeder Softwarefehler ist ein systematischer Fehler und in
diesem Fall auch wohl jeder Designfehler.
Spontan würden mir da Störungen durch Großverbraucher einfallen. Bei uns
in der Firma ist nämlich eine Steuerung regelmäßig montags morgens
ausgefallen. Hat sich dann herausgestellt, das ein 50kW Aggregat den
Fehler produziert hat, weil dummer weise die Versorgungsleitung des
Aggregats und eine Busleitung der Steuerung über ca. 30m parallel
verlegt waren und das die Störung durch das Anlaufen des Aggregats zu
viel war für die Steuerung. Von daher würde ich mal schauen, ob es
irgendwelche größeren Aggregate im Umkreis der Steuerung stehen und
ungefähr im Takt der Ausfälle anlaufen.
Gruß Kai
Moin,
ich habe den Eindruck, dass Du dem Code des Lieferanten nicht ganz
vertraust.
Aber egal, auch wenn: Letztendlich müsst ihr irgendetwas tun, damit ihr
den Code als Fehlerursache ausschließen könnt. "Mit drauf gucken" wäre
eine Möglichkeit.
Ich würde dafür dem Lieferanten mal den Juristen auf den Hals hetzen.
Mit dem Lieferanten wurde vereinbart, dass er niemanden auf den Code
schauen lassen muss. Dieser Vereinbarung liegt natürlich eine als
"fehlerfrei funktionierende und gelieferte Software" zugrunde (wenn
nicht: feuert euren Juristen).
Die Steuerung macht Probleme, deshalb sagt man jetzt dem Lieferanten:
"Wir postulieren, dass Du den Vertrag nicht erfüllt hast wegen Lieferung
von fehlerhafter Software. Du hast zwei Möglichkeiten. Entweder, Du
weist uns die Fehlerfreiheit nach, indem Du unseren Spezialisten mit
draufsehen lässt, oder wir reichen Schadenersatz-Klage ein. Dann wird
ein Gutachter auf die Software gucken und in seinem Gutachten Stellung
über die Qualität und Fehlerfreiheit beziehen. Für den Fall der
außergerichtlichen Einigung (also wenn unser Spezialist mit drauf guckt)
bieten wir kulanterweise an, die Rechte an Code-Verbesserungen, die von
unserem Spezialisten kommen, bei Ihnen zu belassen und auf Schadenersatz
zu verzichten, sofern die Entstehung des Schadens nicht ursächlich in
grob fahrlässigen Verhalten auf Ihrer Seite begründet ist."
(Beispiel: Software ist erkennbar nochmal geändert worden, aber es kann
kein Beleg über Test vorgelegt werden.)
So, nun hat der Lieferant die Wahl.
Gehen wir mal davon aus, dass es zum einen kaum eine Software ohne
Fehler gibt (hierzu verweise ich auch auf dem Hinweis von "hobel") und
zum anderen ein Gutachter immer was findet.
Und das weiß der Lieferant natürlich auch...
Also, wenn ihr den Code sehen wollt, würde ich das so einfädeln und den
Lieferanten etwas "härter" anpacken. Weil: sollte es mal richtig
unangenehm werden mit dem Kunden, ist es gut nachweisen zu können,
seiner Sorgfaltspflicht und Schadenminderungspflicht nachgekommen zu
sein.
Dies könnte nämlich bezweifelt werden über die Aussage: "Sie haben Ihr
gutes Verhältnis zum Lieferanten über mein berechtigtes Interesse an der
Vertragserfüllung gestellt."
Christian J. schrieb:> Jeder Softwarefehler ist ein systematischer Fehler
Das würde ich so nicht sagen, es sei denn nicht-deterministische Fehler
sind für dich auch systematisch.
Hallo,
Volker S. schrieb:> Ich würde dafür dem Lieferanten mal den Juristen auf den Hals hetzen.
die angeführte Rechtsauffassung ist offensichtlich völlig abwegig.
@TO
Berücksichtige, dass eine Eskalation kaum umkehrbar ist. Faktenfreie
Eskalation ist selten eine ideale Strategie, zumal du vermutlich kaum
Erkenntnisse darüber hast, wie der Lieferant auf solche Spielchen
reagiert.
Nicht jeder ist ein ahnungsloser Schisser und zieht gleich den Schwanz
ein nur weil irgend ein Affe meint auf seiner behaarten Brust trommeln
zu müssen. Die Kooperationsbereitschaft des Lieferanten könnte, ggf.
nach juristischen Konsultationen, extrem schnell gegen 0 tendieren.
Das fängt schon bei der Frage an, ob den Umständen nach das Ausfallen
der Steuerung überhaupt einen gravierenden Mangel darstellt.
Offensichtlich ist hier eine Firma im Spiel, die zwar eine Steuerung
entwickeln lässt und verkauft, die Tauglichkeit für den vorgesehenen
Zweck allerdings nicht überprüft, sondern die Steuerung ungeprüft
weiterverkauft und dieses, obwohl sie Vollblut-Embedded-Entwickler
beschäftigt.
Aber nicht nur das! Offensichtlich erweckt diese Firma zwar beim Kunden
den Eindruck maßgeblich für das Produkt verantwortlich zu sein, weswegen
der Kunde angepisst ist, verfügt aber in Wirklichkeit nicht nur nicht
über die Fähigkeiten das Produkt zu entwickeln, sondern auch nicht über
die Fähigkeiten das Produkt überhaupt zu testen.
Ob da dem Lieferanten überhaupt ein wirksamer Vorwurf zu machen ist? Ob
überhaupt fest steht, dass die Ursache in der Software liegt und nicht
in umspezifiziertem Verhalten von Spannungsversorgung oder Eingängen?
Ich persönlich würde eher kooperative Strategien versuchen.
vlg
Timm
Das Problem ist, dass ein EMV Impuls durchaus einen Softwarefehler
aufdecken kann: der Programmierer hat z.B. nur einen Impuls pro Sekunde
erwartet und der Interrupt oder die Funktion wird nun wegen eines
Störimpulses zehnmal in einer ms aufgerufen. Resultat: Stacküberlauf und
"Absturz".
Die Abhilfe? 100% EMV feste Hardware? Gibts nicht. Oder viel eher eine
störungstolerante Software? Das ist oft recht einfach: Tastet
entprellen, externe Signale filtern, usw...
Lothar Miller schrieb:> Das Problem ist, dass ein EMV Impuls durchaus einen Softwarefehler> aufdecken kann: der Programmierer hat z.B. nur einen Impuls pro Sekunde> erwartet und der Interrupt oder die Funktion wird nun wegen eines> Störimpulses zehnmal in einer ms aufgerufen. Resultat: Stacküberlauf und> "Absturz".>> Die Abhilfe? 100% EMV feste Hardware? Gibts nicht. Oder viel eher eine> störungstolerante Software? Das ist oft recht einfach: Tastet> entprellen, externe Signale filtern, usw...
Und Watchdog
> Was tut man in so einem Fall?
Eine neue Stelle suchen.
Eine in der die Geschäftsführung die Kunden beruhigt, bei der man mit
den Lieferanten über alles reden kann, die das erforderliche Werkzeug
kauft, und die genug Entwickler für den Test einstellt.
Und vor allen Dingen... mal drauf achten ob sich um dich herum Leute
ansammeln, die keinen anderen Job finden.
Versorgungsspannung beim Reset aufzeichnen.
Die Versorgungsspannung ist wohl der einfachste trigger.
Leider aber auch ein häufiger Fehler wie bereits oben beschrieben.
Wenn Versorgungsspannung ok, müsste man herausfinden ob nicht irgendein
Event den Reset auslöst.
Wie man das herausfindet musst du uns sagen.
Kommt auf Anlage, Steuerung etc. an.
Vielleicht kann die Steuerung per klar Text ausgeben, was direkt vor dem
Reset passiert oder welche Funktion aufgerufen wird.
Danach von dort aus Fehler weiter eingrenzen.
Noch einer schrieb:>> Was tut man in so einem Fall?> Eine neue Stelle suchen.
Ja, das ist am einfachsten. Nur muss man das laufend tun, wenn man beim
ersten richtigen Problem gleich abtaucht und verschwindet. Das sind dann
immer die Lebensläufe mit ausdauernd 4-5 Berufsjahren pro Arbeitgeber.
So lange kann man die eigene Unfähigkeit idR. noch halbwegs
vertuschen...
asteri_x schrieb:> Welche Methoden habt ihr?
Versuchen, den Fehler zu forcieren. Ab ins EMV-Labor und dort mal
langsam die Störpegel hochfahren. Die Steuerung in den Klimaschrank und
dor anständig plagen. Das Layout erneut auf Tauglichkeit bewerten. Auf
jeden Fall: einen Weg finden, den Fehler mindestens 2x pro Tag zu
bekommen.
> und lässt sich nicht in seinen Code reinblicken.
Das ist ein unerträglicher Zustand.
> (Da es damals vertraglich so geregelt wurde)> Was tut man in so einem Fall, um Ursache des Fehlers zu finden?
Dem Betriebswirt kündigen, der aus Spargründen so einen Vertrag
aufgesetzt hat und einen neuen Vertrag ausarbeiten.
Dem Manager klar machen, dass erst die Software die Steuerung zu dem
macht, was sie ist und tun soll. Ohne die Software geht nichts und mit
der falschen Software kann es sein, dass die Steuerung nur zur
Heizungsregelung eines Pools oder zur Bewässerung eines Gewächshauses zu
gebrauchen ist. Also muss man Zugriff auf die SW haben, und wenn es
"nur" über einen dedizierten Betreuer beim Lieferanten ist, der bei
Fehlern mithelfen muss. Das gehört dann eben auch in den Vertrag...
> Aber genau wegen dem Reset bleibt Anlage stehen.
Dann auf jeden Fall mal den Reset-Grund feststellen. Dazu sollte man
natürlich irgendwie die Software anpacken können. Da beißt sich die
Katze in den Schwanz...
Lothar Miller schrieb:> und wenn es> "nur" über einen dedizierten Betreuer beim Lieferanten ist,
Solche Ein-Mann-Aktionen funktionieren nur bis zum nächsten Urlaub. Da
ist er nicht mehr erreichbar. Lasst Euch REGELMÄßIG Logfiles schicken um
schon einfache Dinge rechtzeitig zu erkennen oder später zu vergleichen.
Bei EMV könnte man zumindes die Logzeiten mit den Ereignissen in der
Maschinenhalle vergleichen. Irgendwelche Schweißarbeiten oder
Einschaltimpulse reichen schon um Ärger zu haben. Da hilft eine Prüfung
im Labor nicht immer.
asteri_x schrieb:> Da denkt man sich als vollblut Embedded Entwickler, da muß man mit einem> Debugger dran. Scheiße, daß man nur einen hat, den auch nur leihweise,> und die Steuerungen zufälligerweise ausfallen.> Kunde kocht. Manager machen Druck, Lieferant der Teile kuscht, kommt nur> schwer voran, und lässt sich nicht in seinen Code reinblicken.
Hatte auch erst einen sehr ähnlichen Fall. Das hat sehr lange gedauert,
bis ich allen Beteiligten klar machen konnte, dass das nicht mein Bier
ist.
Also: Kunden sagen, er möge doch bitte den Managern auf die Eggs gehen.
Management sagen, dass ohne Debugger und Code sowieso nichts geht und
sie beim Lieferanten Druck machen sollen.
Ansonsten findest du vielleicht einen Workaround (automatisch neu
starten, prophylaktisch täglich neu starten,...).
Es ist nicht immer einfach einen Lieferanten zur Kooperation zu bewegen.
Der Jurist maximal kontraproduktiv. Dessen Beitrag zur Loesung ist exakt
Null.
Ein Lieferant ist an einem guten Produkt interessiert, und kommt sicher
vorbei um einen bei ihm nicht aufgetretenen Fehler anzuschauen, und zu
untersuchen. Dabei kann er etwas lernen und das Produkt verbessern.
.. Vorausgesetzt .. das Manual wurde gelesen und befolgt.
.. der Lieferant fuehlt sich auch preislich nicht uebermaessig unter
Druck gesetzt
.. der Kunde nicht dauernd, uebermaessig, unqualifizierten Stunk macht.
> Problemstellung:> Steuerungs-µC macht so alle paar Tage, manchmal nach 1-2 Wochen einen> Reset.> Vorher geht alles OK, danach auch wieder. Aber genau wegen dem Reset> bleibt Anlage stehen.
Dann bringt die Steuerung die Anlage nicht in einen definierten Zustand
und kommt mit dem aktuellen Zustand nicht klar.
> Da denkt man sich als vollblut Embedded Entwickler, da muß man mit einem> Debugger dran. Scheiße, daß man nur einen hat, den auch nur leihweise,> und die Steuerungen zufälligerweise ausfallen.
Häufig kann man sich per Debugger auf das Laufende Programm aufschalten
ohne es zurückzusetzen.
> Kunde kocht. Manager machen Druck, Lieferant der Teile kuscht, kommt nur> schwer voran, und lässt sich nicht in seinen Code reinblicken. (Da es> damals vertraglich so geregelt wurde)
Dann bist du auf deren Kooperation angewiesen, heißt deren Unterstützung
einkaufen.
> Was tut man in so einem Fall, um Ursache des Fehlers zu finden?> Welche Methoden habt ihr?
Statt den Fehler zu beseitigen sollte man versuchen diesen häufiger
auszulösen. Dann klapps besser mit der Suche und man kann überhaupt erst
prüfen, ob die Korrektur das Problem beseitigt hat.
Der CPU einfach mal mitten im Betrieb einen Reset zu verpassen hilft
nicht bei der Lösung des (nebensächlichen) zweiten Problem - dass sich
die Anlage nach Auftreten des Problems wieder fängt?
asteri_x schrieb:> lässt sich nicht in seinen Code reinblicken. (Da es> damals vertraglich so geregelt wurde)
Das ist blöd gelaufen.
Ob es ein Schaltungsfehler, ein Layoutfehler oder ein Softwarefehler
ist, kann man nur feststellen, wenn man sämtliche Unterlagen zugänglich
hat.
Und am besten ist es, wenn alles im Haus entwickelt wird.
Wichtige Sachen sollte man immer selber entwickeln und nicht outsourcen.
>Die Ursache des Fehlers kann ich Dir nennen, aber es wird Dir nicht>gefallen.
Ja bitte bitte bitte!
Steffen Rose schrieb:> Statt den Fehler zu beseitigen sollte man versuchen diesen häufiger> auszulösen. Dann klapps besser mit der Suche und man kann überhaupt erst> prüfen, ob die Korrektur das Problem beseitigt hat.
Ja, genau diesen Ansatz verfolgen wir grade.
Fehler öfter provozieren und dann eingrenzen.
Ist sau schwer, denn das Teil haben wir auch mit bei einem EMV Labor
gestresst, und der meint, man braucht eine Atombombe daneben, um es zu
stören, so gut ist das Gehäuse. Ohne Gehäuse machts Probleme, aber
andere, nicht dieses Reset Phänomen.
Natürlich ist der Vertrag sau schlecht. Aber damals (vor meiner Zeit)
hat man gedacht, wenn die uns das Teil liefern, sollen sie uns gleich
eine richtige FW dazugeben. Alles im allen, dumm gelaufen.
Juristisches Problem jetzt ist, wer für den entstandenen Schaden
aufkommt. Sie meinen EMV, kann ja mal vorkommen. Wir sagen Unmöglich das
ding zu stören, erwiesenerweise. Ich sage, die wissen genau wo der
Fehler ist, sagens uns aber nicht, da sie sonst voll zahlen müssten.
Also Jungs, ich bin auch der Meinung, alles muß in der eigenen Hand
gehalten werden, und höchstens die HW kann vom Lieferanten kommen. Das
sind dann mal gleich wieder 5 Mannjahre, die man da reinsteckt in die
Entwicklung der eignenen FW.
Wo bekomme ich 10 getriggerte Datenlogger her? (5 analogsignale + Can
Bus) ?
Und was das Problem angeht, wir sind mit dem Lieferanten dabei richtig
ins tiefe zu graben. Sind grade beim DMA angekommen. Anscheinend
überschreibt eine DMA Funktion plötzlich alles, deshalb der Reset. Habt
ihr schonmal gesehen, daß der DMA seine Einstellungen verliert oder
ändert? ;)
asteri_x schrieb:> Habt> ihr schonmal gesehen, daß der DMA seine Einstellungen verliert oder> ändert? ;)
Heyho,
die Vorredner haben es bereits versuchtzu erklären: Beim Programmieren
gibt es keinen Zufall nur Fehler zwischen den Ohren des Programmierers
;)
Die Einstellungen des DMA können nicht einfach verloren gehen, es sei
denn eine Routine wird dazu aufgerufen.
Aber spannend ist die Geschichte auf jeden Fall, besten Dank fürs posten
:D lernt man doch glatt auch etwas
beste grüße
public
Moin,
dass Kooperation immer der bessere Weg ist, ist klar. Allein schon weil
es zufriedenstellender ist, GEMEINSAM ein Problem zu lösen.
Dumm nur: Kooperation setzt Wollen auf beiden Seiten voraus.
In vorliegenden Fall scheint der Appell an Kooperation ja wohl nichts
gefruchtet zu haben!
Sicher, man kann sagen "Entschuldige bitte, lieber Lieferant, dass wir
Dich angesprochen haben - wir geben jetzt woanders einfach nochmal
dasselbe Geld aus und lassen uns eine neue Steuerung entwickeln, die
funktioniert."
Aber bevor man DAS macht, macht man doch mal etwas Druck, oder?!
Eine Alternative könnte sein: JETZT erst recht Eigenentwicklung. Dann
kann man zeigen: Eigenentwicklung dran - alles läuft, geliefertes Teil
dran - läuft nicht. Damit kann man den Lieferanten konfrontieren.
Aber Achtung: die Eigenentwicklung muss dann unter denselben
Anforderungen erfolgen wie die beauftragte.
Vorteil: Dem Kunden ist geholfen.
Die Chefs sehen nochmal die Vorteile der Eigenentwicklung.
Das Hühnchen mit dem Lieferanten kann man dann in aller Ruhe später
rupfen... oder es bleiben lassen.
Wenn ich asteri_x richtig verstanden habe, beteiligt sich der Lieferant
jetzt doch...? Dann ist wohl irgendjemand dort vernünftiger geworden.
Ich drücke die Daumen, dass der Fehler schnell gefunden und behoben
wird.
Das geschilderte Problem ist ja nichts neues. Gerade wenn man als
Entwickler in der Industrie unterwegs ist, kennt man das übliche hin und
her geschwappe. Zuerst hat der Einkauf alles extern gekauft, und man
muss sehen, wie man die so tollen günstigen Bruchstücke aus hard- und
Software zusammen dengelt. Da das nicht funktioniert, wird plötzlich
alles im eigenen Haus gemacht... Das geht wegen fehlender Manpower und
bereits vom Vertrieb zugesagter Liefertermine von Produkten ohne
Spezifikation auch nicht.
Da hat es sich als günstig erwiesen, Leistung einzukaufen aber alle
Lieferanten entwickeln auf dem Hauseigenen git. Und man kauft keine
Platine, sondern man spezifiziert sie zusammen mit dem Zulieferer und
hat so von Anfang an die nötigen Daten, die man im Team und an die
Software geben muss, damit alles zusammen passt. Optimalerweise hat man
auf zusammen geklebten Entwicklerkits die Machbarkeit schon mal
bewiesen, während Hard- und Softwarezulieferer schon malen und zeichnen.
Den Mittelweg bei jedem Projekt neu zu definieren ist die eigentliche
Heruasforderung.
Aber da das Produkt ja schon vor der Zeit des TO existierte, ist seine
Aufgabe die denkbar undankbarste...
Leider kann man Dir aber auch wenig helfen, denn man müsste mehr
Information haben. Welcher Aufbau, welche Fertigkomponenten, welche CPU,
welche andere interessante Chips? Die Fehlerbeschreibung "geht manchmal
nicht" hilft nicht, Dir einen Fachkundigen Rat zu geben.
Aber wenn man wüsste, welche CPU, dann macht es vielleicht bei dem einen
oder anderen hier klick, und der postet dann was wie "Das Ding? Na klar,
schau mal in die E123345.pdf vom Hersteller, da ist ein bekannter Bug im
DMA Controller, wenn man das und das macht." Vielleicht ist auch was zu
Aktoren oder Netzteilen, Displays oder so hier bekannt? Ohne Fakten,
keine Möglichkeit...
Damit könnten wir Dir hier im Forum aber wohl eher helfen als mit
Rechts-Beratung und etwas moralischer Unterstützung.
Gruß
Ulrich
Danke für alle eure Beiträge!
Es ist wirlich eine undankbare Aufgabe.
Ich wollte die Methodik erkunden wie andere das machen bei ähnlichen
Problemen.
Der Lieferant weint schon, so lange ärgern wir ihn schon. Aber er
versucht uns zu helfen wo er kann.(und darf ähem ähem)
Die DMA Geschichte geht weiter.
Es geht um einen MPC5634M von Freescale.
Wir vermuten, daß das RTOS, das eigentlich nur ein Interrupt getriebener
Scheduler ist, bei gewissen Zeitpunkten zu viele Tasks gleichzeitig
starten will, von denen manche mit dem DMA arbeiten und sich anscheinend
in die Quere kommen. Auswirkung: in die TCD nbytes kommt statt einer 2
was komplett schräges und den führt er dann auch aus. Nur woher kommt
die idiotische Zahl???
Hat da mit dem µC jemand schon sowas erlebt? Der ist eher in der
Automotive branche aufzufinden.
Also ich habe noch nie mit dieser Architektur gearbeitet und nur gerade
mal die ersten Seiten von Crossbar und eDMA im Datasheet diagonal
gelesen.
Auffällig ist ja, dass der eDMA über ein Size- und ein Loop-Register
verfügt, also einen Block der Größe "Size" dann "Loop"-Mal übertragen
kann. Ein denkbarer Fehler ist dann sicher, dass ein Task mit der Größe
der Blöcke arbeitet, ein anderer mit der Anzahl. Wenn dann der eine Task
das Size-Register setzt und der andere das andere ungewollte das
Loop-Register überschreibt, dann kommen große Blöcke zustande...
Aber das wäre jetzt geraten. Vielleicht kennt jemand anderes den Chip
schon und weiß um Eigen- oder Gemeinheiten dieser Architektur.
Vielleicht sollte man erstmal eine statische Codeanalyse machen? Lint &
Co? Dann gerade bei einem RTOS kann es nette Race Conditions und
nichtatomare Fehler geben!
oszi40 schrieb:> public schrieb:>> Einstellungen des DMA können nicht einfach verloren gehen>> ... aber ein Eingriff zur falschen Zeit?
Nö glaube ich nicht, digital ist digital, 1 oder 0 und leider nichts
dazwischen... (Einhörner vielleicht)...
Sry wenn ich trolle.
beste grüße
public
Angenommen die echten Firmwarefehler (Programmierfehler, Resourcenarmut,
Speicherlöcher, nicht vorhandene Fehlerkorrektur, Timing -> Falk hat
hier schon die statische Codeanalyse vorgeschlagen) und Siliziumbugs
(MCU Errata lesen) hat man im Griff, dann bleibt wieder das Thema
Umgebungseinflüsse.
Für zuverlässige Eigenentwicklungen gibt es von verschiedenen
Herstellern Listen zur Abhärtung der Firmware gegen externe Probleme
(EMI).
Diese Listen enthalten verschiedene Punkte, mit deren Hilfe die Firmware
Fehler erkennen und ggf. korrigieren kann. Z.B. ein Einstieg von ST:
AN1709 EMC DESIGN GUIDE FOR ST MICROCONTROLLERS
http://www.st.com/web/en/resource/technical/document/application_note/CD00004479.pdf
AN3307 Guidelines for obtaining IEC 60335 Class B certification for any
STM32 application:
http://www.st.com/web/en/resource/technical/document/application_note/CD00290100.pdf
AN1015 Software techniques for improving microcontrollers EMC
Performance
asteri_x schrieb:> Hi!>> Problemstellung:> Steuerungs-µC macht so alle paar Tage, manchmal nach 1-2 Wochen einen> Reset.> Vorher geht alles OK, danach auch wieder. Aber genau wegen dem Reset> bleibt Anlage stehen.
Hm ist das nicht eher ein Problem der systemspec als der Hard-/Firmware?
Was ist für den Reset-Fall spezifiziert? Soll die Anlage automatisch
anlaufen
oder manuell gestartet werden?
Das sollte man klären bevor man versucht das Auftreten des Resets zu
verhindern/resp. unnötig zu machen. Sonst die Spec nicht vollständig.
"Shit happens" - auch dieser Fall muss spezifiziert sein.
Und was ist für die Ereignisse spezifiziert die einen reset auslösen
können?
-Spannungsabfall? (brown out detektor)
-(controller interner) Watchdocgtimer?
-Chiptemperatur? (Monitorchip)
-zu hoher Strom (Monitorchip)?
Wurde Hard- oder Softreset ausgelöst?
Was ist da spezifiziert?
MfG,
asteri_x schrieb:> Ich sage, die wissen genau wo der> Fehler ist, sagens uns aber nicht, da sie sonst voll zahlen müssten.
Wenn sie genau wüssten wo der Fehler ist würden sie euch sofort eine
neue Firmware für die Geräte geben, allein schon um den chronischen
Ärger endlich abzustellen, sie würden es natürlich nicht als Bugfix
deklarieren sondern als Zusatzfeature das die Robustheit [gegenüber
irgendwelchen vollkommen hypothetischen Einflüssen die von eurem Teil
der Anlage ausgelöst werden könnten wenn zufällig unerwartet
Weihnachten und Ostern auf einen Tag fallen] noch weiter erhöht [noch
weiter als es das ohnehin schon tut], natürlich ist das Update
kostenlos.
Was? Der Fehler tritt jetzt nicht mehr auf? Na so ein Zufall, dann wars
also doch eure Schuld. Aber Schwamm drüber, sie werden es euch nicht in
Rechnung stellen. Lässt sich ja eh kaum noch beweisen was da wirklich
passiert ist und jetzt gehts ja schließlich endlich. Alle sind
glücklich.
Hi,
>> Die DMA Geschichte geht weiter.> Es geht um einen MPC5634M von Freescale.> Wir vermuten, daß das RTOS, das eigentlich nur ein Interrupt getriebener> Scheduler ist, bei gewissen Zeitpunkten zu viele Tasks gleichzeitig> starten will, von denen manche mit dem DMA arbeiten und sich anscheinend> in die Quere kommen. Auswirkung: in die TCD nbytes kommt statt einer 2> was komplett schräges und den führt er dann auch aus. Nur woher kommt> die idiotische Zahl???>
Das klingt nach einem Klassiker - und ziemlich plausibel. Ferndiagnosen
sind natürlich völlig illusorisch, aber als einer, der seit 10 Jahren
eigentlich immer solche Feuerlöscher-Jobs an der Backe hatte, würde ich
nach sowas als nächstes suchen, wenn man a) Chip-Fehler, b)
Out-of-Specs-Szenarien (EMV, kritisches PCB-Design usw.) ausschliessen
kann.
Und zu den Methoden:
1) Code scharf anschauen
2) Code u.U. simulieren / auf Atomizität überprüfen, und zwar auf
Assembler-Ebene
3) Möglichst non-intrusive Testbenches entwickeln, um den eventuellen
Fehlerfix auch zu verifizieren
Es gibt da auch ein paar strenge Richtlinien, um solchen
Multi-Thread-Code zu entwickeln, aber die helfen in diesem Fall (ohne
Zugriff auf Sourcen) vermutlich kaum.
Das einzige, was man in diesem Fall machen kann: Spezialisten anheuern,
die den Code reverse-engineeren und dem Lieferanten beweisen, dass er
Mist gecoded hat. Aber, um mal wieder ein faules Zitat rauszukramen: Dat
wird teuer.
> Hat da mit dem µC jemand schon sowas erlebt? Der ist eher in der> Automotive branche aufzufinden.
Mit dem uC nicht, aber eben, wie gesagt, ein Klassiker, der
chip-invariant sein dürfte, wenn er in diesem Fall zutrifft.
Was die Chip-Bugs angeht: Da sucht man sich am besten einer der wenigen
Hersteller, die intern kurze Wege zu den "Silicon guys" haben, die einem
einen Bug unter gewissen Umständen auch bestätigen können.
Nicht zuletzt setzen deshalb inzwischen einige Steuerungsspezis auf
simple FPGA-Statemachines, die sich simulieren lassen oder teils sogar
redundant laufen. Da lassen sich viele komplexe Multithread-Probleme von
vornherein ausschliessen.
Strubi schrieb:> Nicht zuletzt setzen deshalb inzwischen einige Steuerungsspezis auf> simple FPGA-Statemachines, die sich simulieren lassen oder teils sogar> redundant laufen. Da lassen sich viele komplexe Multithread-Probleme von> vornherein ausschliessen.
Das klingt sehr interessant insbesonders für SoC - Chips wie ARM in FPGA
(Xilinx - Zynq).
Kannst Du da mehr berichten oder verlinken?
Vielleicht besser im FPGA-Forum?
-> https://www.mikrocontroller.net/forum/fpga-vhdl-cpld
MfG,
Brown out / spike ?
ja so Lieferanten kenne ich auch: "Unsere Schaltung ist ok. die geht
überall anders auch. Das machen wir immer so."
Und dann den Schaltplan studiert und gemeinsame Sicherung in Nulleiter
eines Stern-Sterntrafos bei zwei sehr dynamischne Lasten auf zwei Phasen
verteilt.
Ohne Worte
und auch der rest ist normal.
Hi, asteri_x,
FPGA Kuechle schrieb:
> Hm ist das nicht eher ein Problem der systemspec als der Hard-/Firmware?FPGA Kuechle hat das magische Wort genannt: Spezifikation.
Wenn man dem Lieferanten zugesteht, das Innenleben seiner "Black Box"
für sich behalten zu dürfen, dann muss gnadenlos spezifiziert und
getestet werden. Ich betone: "Und".
Im Fehlerfall geh' streng nach dem Demingkreis vor. Besser nach seiner
diagnostischen Variante. Die kennen wir alle schon von unserem
Kinderarzt.
Denn es gibt keine unlösbaren Fehler. Wohl aber schlampige Verträge und
Fehler, wo gearbeitet wird.
Ciao
Wolfgang Horn
Hi FPGAkuechle,
>>> Nicht zuletzt setzen deshalb inzwischen einige Steuerungsspezis auf>> simple FPGA-Statemachines, die sich simulieren lassen oder teils sogar>> redundant laufen. Da lassen sich viele komplexe Multithread-Probleme von>> vornherein ausschliessen.>> Das klingt sehr interessant insbesonders für SoC - Chips wie ARM in FPGA> (Xilinx - Zynq).> Kannst Du da mehr berichten oder verlinken?>
Zum Verlinken habe ich gerade konkret nix, aber ich denke ein Beispiel -
wenn auch etwas andere Liga - sind die Applikationen aus der
Gaisler-Domäne.
Schlussendlich misst sich die Robustheit einer Anwendung ja an der Güte
der Testbench (und dem Simulator). Um zu "beweisen" (Mathematiker: hört
bloss weg :-) ), dass ein Programm sauber läuft, muss man schon sehr
viel Aufwand betreiben.
Den Zynq EPP finde ich jetzt schon wieder etwas "drüber" in der
Komplexität, insbesondere den Bus-Anbindungen und dem Framework, das man
für die ARM-Cores benötigt.
Ich dachte eher an ein ganz simples Szenario: Soft-CPU erledigt genau
einen simplen Task. Anstatt RTOS für multi-tasking, welches
undeterministisches Verhalten entwickeln könnte, instanziert man ev.
besser eine weitere CPU pro Task bzw. implementiert die FSM als
Coprozessor-Units, die regelmässig in der Hauptkontrollschleife
angetippt werden. Konkurrenzierende Zugriffe gibt es nicht, und
Datenaustausch findet per DMA/FIFO statt oder man nutzt echte
"atomische" Hardware-Locks, die nicht blockieren. Interrupts gibts nur
fürs Front-End (CPU für User-Interaktion). Das kriegt man auch noch mit
Mittelklasse-Tools hin. Wenn man auf der Komplexität des Zynq
co-simulieren will, geht es wohl in Richtung Jahreslöhnen an Toolkosten
(Stand 2012).
Sobald man komplexe OS wie Linux mit optimal fehlertoleranten Systemen
spicken will, hat der Zynq sicher seine Berechtigung - sofern man den
ARM-Cores vertraut. Weiss nicht ob das alle Teufelsadvokaten im
sicherheitsrelevanten Sektor tun...
In der Praxis habe ich bisher immer FPGA und Front-End-CPU getrennt
gesehen und würde es auch pragmatisch weiterhin so angehen, um per
Watchdog wenigstens das Front-End komplett reseten zu können, während
die systemrelevanten Sachen weiterlaufen. Schlussendlich halt eine Frage
der Robustheit und der Kostenabwägung.
Die Steuerung braucht eine Menge Parameter die von der Zentraleinheit
gesendet werden. Ohne die kann sie nicht arbeiten. FMEA mässig wurde das
damals so geregelt, daß die Anlage im laufenden Betrieb nicht wieder
hochfahren darf.
Teile der Steuerung sind ja eh schon mit FPGA gelöst, wo es um absolutes
Echtzeitverhalten geht. Das ganze Ding mit FPGA zu lösen wäre aber
anscheinend zu teuer. Wir hätten aber dann die Flexibilität jetzt
Änderungen zu machen.
Reverse Engineering auf Assembler Ebene kann ja richtig Spaß machen. Wir
sind eh schon dabei. Ich sehe es auch nicht anders.
Wir haben es geschafft den Fehler im Labor nachzustellen, und öfter
auftreten zu lassen. Das hilft uns jetzt enorm. Im Labor sind alle
Bedingungen perfekt. Keine Spannungseinbrüche etc. Wir haben es echt mit
einem SW Bug zu tun der beim Kontext Switching auftritt... Faszinierend.
asteri_x schrieb:> Wir haben es geschafft den Fehler im Labor nachzustellen, und öfter> auftreten zu lassen.
Ein großer Schritt in die richtige Richtung.
Aber eins noch: die hässlichsten Fehler sind die, wenn zwei Fehler mit
unterschiedlichen Ursachen, bei denen die selben Symptome zu sehen sind,
gleichzeitig auftreten. Denn dann findet man einen Fehler und behebt die
Ursache, aber das Fehlerbild und die Symptome sind immer noch da. Sowas
passiert zum Glück nur alle 5-10 Jahre, aber es passiert...
Strubi schrieb:> Es gibt da auch ein paar strenge Richtlinien, um solchen> Multi-Thread-Code zu entwickeln,
Welche meinst du? Hast du evtl. einen Link?
Strubi schrieb:> Zum Verlinken habe ich gerade konkret nix, aber ich denke ein Beispiel -> wenn auch etwas andere Liga - sind die Applikationen aus der> Gaisler-Domäne.
Meinst du Gaisler aus Schweden? Machst du was mit deren Produkten und
wenn ja was? Reine Neugier ;)
asteri_x schrieb:> Wir haben es geschafft den Fehler im Labor nachzustellen,
Klasse, freu mich für dich. So etwas zu finden ist wahrlich kein Zucker
schlecken. Berichte bitte weiter, was ihr gemacht habt und was es denn
schließlich war. Viel Glück :)
Strubi schrieb:> Hi FPGAkuechle,>>>>>> Nicht zuletzt setzen deshalb inzwischen einige Steuerungsspezis auf>>> simple FPGA-Statemachines, die sich simulieren lassen oder teils sogar>>> redundant laufen. Da lassen sich viele komplexe Multithread-Probleme von>>> vornherein ausschliessen.>>>> Das klingt sehr interessant insbesonders für SoC - Chips wie ARM in FPGA>> (Xilinx - Zynq).>> Kannst Du da mehr berichten oder verlinken?>>>> Zum Verlinken habe ich gerade konkret nix, aber ich denke ein Beispiel -> wenn auch etwas andere Liga - sind die Applikationen aus der> Gaisler-Domäne.> Schlussendlich misst sich die Robustheit einer Anwendung ja an der Güte> der Testbench (und dem Simulator). Um zu "beweisen" (Mathematiker: hört> bloss weg :-) ), dass ein Programm sauber läuft, muss man schon sehr> viel Aufwand betreiben.
OK , also das Problem Steuerungsaufgaben entweder mit µC (Software) oder
PLD (Hardware) zu lösen hat mehrere Aspekte. Da hat jeder seine eigene
Meinung dazu und das ist auch gut so.
Also für das PLD spricht wohl jetzt:
-weniger komplexe Abläufe (kein Multithreading)
-harte Echtzeitbedingung (und damit wieder weniger komplex ->
Zustandswechsel dauert eben immer 1 Takt und nicht x bis y Takte wie bei
IRQ)
Klingt jetzt etwas überraschend, FPGA-Programmierung mit VHDL gilt ja
als schwieriger als C auf µC. Aber bei OS auf µC lauert immer der
Kontextwechsel, Systemverklemmung, Heap-CleanUp.
Ein anderes eher kurios anmutendes Argument hat man noch vor einigen
Jahren (vor Einführung DO-254) gehört. Für sicherheitsrelevante Software
gibt es (nur teuer) umzusetzende Richtlinien (Avionics DO-178) die man
bei einer PLD-Realisierung nicht umsetzen muß.
Das PLD-FSM jetzt robuster sind da besser simulierbar und die Güte der
Testbench höher hat mich nicht so überzeugt. Eher das da die Komplexität
geringer mit weniger Testfällen eine höhere Testabdeckung erreicht wird.
Mein Fazit: FSM ist im PLD robuster umgesetzt als im µC mit OS, da dort
hart gekapselt von den anderen Prozessen/Programmen.
MfG,
Hey Jungs!
Die Geschichte geht weiter, und wird immer spannender. Jetzt haben wir
so tief gegraben, daß wir beim XBAR des Kontrollers angekommen sind.
Irgendwie scheint mit den Prioritäten der Master das Problem verbunden
zu sein. Den XBAR benutzen als Master die CPU, die eDMA, und als slave
der RAM und die Periferie, wozu auch der ADC gehört. Irgendwie passieren
komische Sachen, wenn die Prio des eDMA kleiner ist als die des CPU.
Aber jetzt mit gleicher Prio ist das Problem noch immer da, tritt aber
nur seltener auf. Die eDMA schaufelt die Daten aus den QADC-s und zu
unserem RAM Bereich. Wir haben schon Freescale kontaktiert, damit wir
mehr Know How bekommen.
Habt ihr mal mit den XBAR zu kämpfen gehabt?
@asteri_x (Gast)
>Die Geschichte geht weiter, und wird immer spannender. Jetzt haben wir>so tief gegraben, daß wir beim XBAR des Kontrollers angekommen sind.
Hmm.
>Irgendwie scheint mit den Prioritäten der Master das Problem verbunden>zu sein. Den XBAR benutzen als Master die CPU, die eDMA, und als slave>der RAM und die Periferie, wozu auch der ADC gehört. Irgendwie passieren>komische Sachen, wenn die Prio des eDMA kleiner ist als die des CPU.>Aber jetzt mit gleicher Prio ist das Problem noch immer da, tritt aber>nur seltener auf.
Was die Fehlersuche aber eher schwieriger macht.
> Die eDMA schaufelt die Daten aus den QADC-s und zu>unserem RAM Bereich. Wir haben schon Freescale kontaktiert, damit wir>mehr Know How bekommen.>Habt ihr mal mit den XBAR zu kämpfen gehabt?
Nö. Aber wenn der Verdacht besteht, würde ich umgehend ein Testprogramm
ohne den Rest erstellen, dass den XBAR maximal stresst, in
verschiedensten Konfigurationen. Damit könnte man dem Problem auf die
Spur kommen. Auf jeden Fall muss man daran arbeiten, den Fehler häufiger
und sicherer auzulösen.
oszi40 schrieb:> ... aber ein Eingriff zur falschen Zeit?
Dann provoziert den Fehler, wenn Ihr schon mehr wisst und baut
Testpunkte ein. Evtl. reicht bei großer Last die Zeitscheibe nicht, um
alle Wünsche rechtzeitig zu erfüllen?
Moin,
zuviele Meinungen trüben vielleicht die Sicht, aber die Schilderung mit
den XBAR-Prioritäten erinnern mich an ein Problem auf einer anderen
Plattform. Da gab es eine Art Race-Condition im IRQ-Handler für den DMA.
Würde jetzt nix bringen, das auszuführen, und ich kenne auch die
DMA-Arch des genannten Freescale Null, aber ich hätte jetzt mal genau
dort gesucht und mir (oder dem Lieferanten des Code) die Fragen
gestellt:
- Wird nach Erledigung des DMA-Transfer per Routine ein neuer
DMA-Transfer angeworfen? (und das nicht zu früh?) Passiert das in einer
Main-Loop oder im IRQ handler?
- Hat die State-Machine immer einen wohldefinierten Zustand zur
Ausführungszeit des kritischen Befehls X, oder kann ein IRQ zum falschen
Zeitpunkt den Zustand versauen oder gar einen Registerzugriff
unterbrechen?
(z.B.: 32-Bit-Load-Immediate mit zwei Asm-Befehlen)
Den ersten Punkt kann man abhaken, wenn die DMA-Engine Autobuffering
kann, also sich selbst einen neuen Transfer-Deskriptor holt. Das erlaubt
die Konfiguration einer "harten" Buffer-Queue -- die schlechthin
robusteste Variante. Zum zweiten Punkt muss man die Architektur
(Pipeline und Interface-FIFO-Verhalten) plus den IRQ-Handler-Code scharf
anschauen und an der richtigen Stelle Synchronisationen (pipeline
flush-Befehl, o.ä.) erzwingen.
Wenn in einem DMA-Register wie beschrieben ein völliger Bananenwert
steht, müsste man auch noch sicherstellen, dass nicht zwei verschiedene
Kontexte versuchen, ohne Mutex-Bewachung auf die Register zu schreiben.
Sowas ist eigentlich auch mit Mutexen "verboten", nur ein Task darf
typischerweise an das "Device" und sollte alle Daten an andere Tasks per
Queue (Pipe) weiterreichen.
Das aber nur so laut gedacht...
Grüsse,
- Strubi
Aus eigener Erfahrung kann ich da Strubi nur Recht geben.
Ein "Ding" darf nur von einem Stück Code betrieben werden. Oft haben
Controller wenige DMA-Kanäle, die sie aber mit vielen Devices verbinden
können. Teilen sich also in einem System mehr Devices einen DMA-Kanal,
dann muss man einen Treiber dazwischen schreiben, der das managed.
Mich wundert aber, dass bei einem Automotive Prozessor ein echter Fehler
in der XBAR nicht bereits aufgefallen wäre und damit als Errata
beschrieben wurde.
Der Weg zu Freescale ist auf jeden Fall richtig, auch wenn er (ohne FAE
dazwischen) etwas mühsam ist.
