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.
public schrieb: > Einstellungen des DMA können nicht einfach verloren gehen ... aber ein Eingriff zur falschen Zeit?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.