Hallo zusammen, auf die µC-Hauptplatine wird eine weitere Platine aufgesteckt, deren Version durch die Pegel an den drei Pins des Steckers kodiert wird. Diese Pins werden vom µC der Hauptplatine an drei IO-Pins (weiter unten als Versions-Pins genannt) eingelesen. Die Platine wird in sehr kleinen Stückzahlen hergestellt. Für sie soll ein Testgerät (eine Art Testplatine) gemacht werden, die per Stecker und Kabel mit der Hauptplatine verbunden wird und mit dessen Hilfe die Funktion der Hauptplatine getestet wird. Und jetzt meine vielleicht etwas primitive Frage: Wie kann die Funktion der µC-IOs sinnvoll getestet werden, an denen die Version der aufsteckbaren Platine eingelesen wird. Am einfachsten könnte man an alle Versionspins bestimmte Kombination (z.B. 101) anlegen und im Controller per Testsoftware prüfen, ob er diese Kombination auch einliest. Wenn ja, Funktionstest der Versionspins erfolgreich, wenn nein - Fehlermeldung! Es kann aber ja ein Fehler/Defekt auf der Platine oder im Controller (IO-Treiber) auftreten, durch den rein zufällig die gleiche Kombination eingelesen wird. Aus diesem Grund ist ein solcher Test nicht besonders zuverlässig. Eine andere Möglichkeit wäre, z.B. mit DIP-Schaltern die Kombination zu verändern und die eingelesene mit der eingestellten zu vergleichen. Das ist zwar aufwendiger aber zuverlässiger. Und jetzt möchte ich euch um ein paar Anregungen bitten. Wie würdet ihr so etwas machen? Bin für jeden Vorschlag dankbar!!!
Natürlich werden von aussen durch eine Elektronik im Teststecker zeitlich nacheinander alle 8 möglichen (oder zumindest 3) Kombinationen angelegt und diese von der uC-Testsoftware ausgewertet ob alle stimmen
Und noch was anderes: Eine SPI-Schnittstelle des uC wird als SPI-Slave verwendet. Wenn ich diese Schnittstelle zum Test als Master konfiguriere und MOSI mit MISO kurzschließe (eine Art loop-back) und Daten von MOSI wegschicke und an MISO einlese und vergleiche. Wäre das eine gute Möglichkeit zum Testen? Es geht mir darum, auf der Testplatine nicht auch eine SPI-Schnittstelle einrichten zu müssen!
> loop-back
Na ja, eins ist ein Ausgang, der andere ein Eingang, wenn dein
Testadapter beide verbindet, reicht es ja, den Ausgang mal 1 und 0 zu
schalten und zu gucken ob das auch am Eingang ankommt, ganz ohne SPI.
Du brüfst damit zumindest die Verbindungskontakte des Testadapters :-)
>reicht es ja, den Ausgang mal 1 und 0 zu schalten und zu gucken ob das >auch am Eingang ankommt, ganz ohne SPI. Aber SPI-Modul des uC ist doch mehr als nur dig. Eingang und Ausgang. Es hat ja die Schieberegister, evtl. Pufferregister, Taktsignalauswertung und SS-Logik (im Slave-Mode) wobei natürlich die letzten zwei mit meiner Methode oben sich nicht testen lassen. Und der Fehler kann irgend wo liegen, auch wenn der zugehörige Ausgang/Eingang in Ordnung ist.
Ich hol den Thread mal nach oben, vielleicht hat jemand ja was dazu zu sagen!
Sicher. Die Chance, daß der Fehler auf dem Board liegt ist aber sicherlich deutlich höher, als wenn er im Chip liegt. Oder andersherum: Wenn Du der internen Peripherie nicht mehr traust -Puffer, Treiber, Schieberegister - welchen Grund gibt es dann noch, dem Kern zu trauen? Viele Grüße Nicolas
Hallo In unserer Abteilung werden Prüfmittel erstellt, Incircuit und Funktiontest. Beim ICT sehen wir zu, das jeder Ausgangspin mindestens einmal toggelt. Jeder Eingangspin sollte ebenfalls mindestens einmal toggeln, und dieses Toggeln sollte an einem Ausgang bemerkbar sein. Wir wollen damit testen, das auch jeder Pin angelötet ist. Du solltest also deine Versionspins von außen toggeln lassen und das ganze auf anderen Pins wieder ausgeben. Dann kannst due sicher sein, das deine Versionspins funktionieren. Gruß Joachim
Bitte 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.