Hallo zusammen,
wir (ich und meine Kollegen) haben über einen Freelancer ein eigenes Carrier-Board für das Raspberry Pi Compute Module 4 entwickeln lassen, aber leider zeigt der Pi beim Einschalten keinerlei Aktivität. 5V ist da, alle GNDs auch. wir sind selber leider keine Profis in PCB-Design.
Die Gerber-Dateien, die Scematics und die vollständige Stückliste (BOM) sind vorhanden.
Gibt es hier jemanden, der uns eventuell helfen kann herauszufinden, woran es liegt?
Wir wären für jede Unterstützung oder jeden Hinweis wirklich sehr dankbar!
zum Board: Es soll für die Steuerung eines Drehkreuzes verwendet werden, dafür sind Relais vorhanden, die an GPIO Pins hängen. Zusätzlich sind Steckplätze für LEDs, I2C, USB, HDMI, MIPI verbaut.
Falls uns jemand helfen möchte, gerne melden.
Vielen Dank im Voraus!
Sollte euer Auftragnehmer nicht auch sicherstellen, dass sein Design funktioniert und gegebenenfalls euch Instruktionen geben können wie (falls durch sein Design abweichend von Standardkonfiguration notwendig) das SoM in Betrieb genommen werden muss?
Also da fehlen bestimmt noch die Flyback dioden.
Die LEDs in der 4N35 brauchen auch bestimmt einen Vorwiderstand. Soll das durch den GPIO limitiert werden oder was?
Ob der CTR da ausreicht? 50mA LED Strom würde dann 50mA durch den Schalter jagen. Ob das genug ist? Muss man halt im Relay Datensheet überprüfen.
Sonst frage ich mich ob da genügend Kondis verbaut worden sind?
Ich denke mal, wenn da die Relays so gedesigned sind, ist halt anzunehmen dass irgendwo anders auch probleme gibt.
Vorschlag ist, das Ding in die Tonne zu treten. Von 0 anfangen. Erstmal nur aber 1 Feature implementieren. Dann kannst du dein PCB immer wieder erweitern. Immer nur ein schritt machen. Überprüfen ob es so noch tut, wenn ja dann weiter.
Auf die Schnelle:
Die Signale am RS232 Treiber sind falsch aufgelegt
R1OUT sollte auf auf UART_TX gehen ... Rxxx sind die RS232 Signale Txxx die 3.3V Signale.
Dem entsprechend sind da auch die PI Signale falsch
Sollte euer Auftragnehmer nicht auch sicherstellen, dass sein Design
funktioniert und gegebenenfalls euch Instruktionen geben können wie
(falls durch sein Design abweichend von Standardkonfiguration notwendig)
das SoM in Betrieb genommen werden muss?
Sollte man meinen... Er hat keine Ahnung, warum es nicht läuft.
Sollte euer Auftragnehmer nicht auch sicherstellen, dass sein Design
funktioniert
nicht unbedingt... Es kommt halt darauf an wer den Schaltplan gemacht hat. Ich vermute, dass da nur das Layout eingekauft wurde. Die SUB-D Buchse gibt es auf der LP nicht, also entspricht der Schaltplan nicht dem Layout.
Auf die Schnelle:
Die Signale am RS232 Treiber sind falsch aufgelegt
R1OUT sollte auf auf UART_TX gehen ... Rxxx sind die RS232 Signale Txxx
die 3.3V Signale.
Nein, das ist schon richtig, nur die Bezeichnung UART* für die RS232-Signale irritiert.
Allerdings sollte er den ungenutzten T2IN nicht floaten lassen.
leider zeigt der Pi beim Einschalten keinerlei Aktivität
Was ja auch an der Software liegen kann.
Der Profi schreibt sich eine kurze Testsoftware, die nichts anderes tut, als einen unbenutzten Port-Pin periodisch im 5-Sekunden-Takt abwechselnd auf High und Low zu setzen, und misst an dem Pin. Wenn schon das nicht funktioniert, braucht man sich nicht mit Gerber-Dateien und Stücklisten zu befassen.
Hallo zusammen,
wir (ich und meine Kollegen) haben über einen Freelancer ein eigenes
Carrier-Board für das Raspberry Pi Compute Module 4 entwickeln lassen,
aber leider zeigt der Pi beim Einschalten keinerlei Aktivität.
Dann muss man erstmal ein lauffähiges System sicherstellen. Sprich, das Modul muss auf einem normalen Board laufen. Dann geht's weiter. Siehe Fehlersuche
Wir wären für jede Unterstützung oder jeden Hinweis wirklich sehr
dankbar!
zum Board: Es soll für die Steuerung eines Drehkreuzes verwendet werden,
dafür sind Relais vorhanden, die an GPIO Pins hängen. Zusätzlich sind
Steckplätze für LEDs, I2C, USB, HDMI, MIPI verbaut.
Das könnte man auch mit einem normalen Raspi machen, den man auf ein einfaches Board steckt und nur den Krümelkram an Signalen (IOs, I2C, UART) runter führt. Alles ansprichsvolleren Verbindungen sind schon vorhanden (USB, HDMI etc.)
Wenn man den Stecker angesichts der J11 und J13 überhaupt reinbekommt, dann würde ich sicherheitshalber vorher den Clip des Steckers abbrechen. Und ich würde auch die beiden LEDs für die Buchse einplanen. Es ist blöd, wenn man nicht weiß, ob überhaupt ein Link zustande gekommen ist.
Ich hätte bei dieser Schaltung als Optokoppler auch Angst.
Und zwar sowohl auf der Eingangsseite ohne Vorwiderstand als auch auf der Ausgangsseite ohne Freilaufdiode. Weil der CTR zudem nur 100% ist, müssten durch die LED deutlich mehr als 30mA fließen, damit der Ausgangstransistor ausreichend gut leitet (Stichwort: Übersteuerung für Schaltbetrieb). Denn der CTR ist im Datenblatt bei einer Spannung von Uce=10V spezifiziert, das ist weitab von "Schaltbetrieb".
Der Profi schreibt sich eine kurze Testsoftware, die nichts anderes tut,
als einen unbenutzten Port-Pin periodisch im 5-Sekunden-Takt abwechselnd
auf High und Low zu setzen, und misst an dem Pin.
Und das tut und testet er auf einem Board, das nachweislich funktioniert.
aber leider zeigt der Pi beim Einschalten keinerlei Aktivität.
Ich hätte da den GLOBAL_EN und den RPIBOOT unbedingt auf einen Jumper geführt. Denn die haben sehr exponierte Funktionen, die man auch fürs Troubleshootig oder fürs Image-Update per USB braucht.
Ich vermute, dass da nur das Layout eingekauft wurde.
Sehe ich auch so. Denn das Layout an sich sieht ganz brauchbar aus.
Hmmm, das sehe ich etwas anders. Man beachte z.B. nur die völlig unzureichenden Aussparungen neben den Befestigungsbohrungen. Da kollidiert doch jeder Schraubenkopf mit den benachbarten Bauelementen.
Leiterbahnen werden auch unnötig dicht an anderen Elementen vorbeigeführt. Bei differentiellen Signalen gibt es auch keine sinnvoll vergrößerten Abstände zu dem umgebenden Kupferfüllflächen.
Da kollidiert doch jeder Schraubenkopf mit den benachbarten Bauelementen.
Stimmt.
Und nicht nur das: die Bauteile und die Lötstellen dort werden mit mechanischem Stress durch die (wenn auch minimale) Verbiegung der Leiterplatte beaufschlagt.
Kann aber sein, dass zur Befestigung Plastikclips geplant sind:
Da kollidiert doch jeder Schraubenkopf mit den benachbarten Bauelementen.
Stimmt.
ich denke mal, dass die 4 Mounting Holes ursprünglich dafür gedacht waren das Modul sicher auf der Trägerplatine zu fixieren.
Ich kenne das so, dass man als Layouter nach einer ersten Plazierung der mechanischen Komponenten sich erst mal eine Freigabe holt. Da wäre dann auch die Plazierung der Netzwerkbuchse aufgefallen.
Ich hätte das PI Modul mit den beiden Steckern ev als Bauteil gleich mit den Holes und Umrissen definiert. Der Abstand zu Bauteilen auf dem Träger kommt mir etwas knapp vor.
ich denke mal, dass die 4 Mounting Holes ursprünglich dafür gedacht
waren das Modul sicher auf der Trägerplatine zu fixieren.
Die dienen auch zur Befestigung eines Kühlkörpers - dazu werden Schrauben von unten durch die Platine, durch Distanzringe und das CM4 selbst gesteckt, um dann in den Kühlkörper geschraubt zu werden.
Eine gute Hilfe für Selbstbasteleien mit dem CM4 (oder auch dem CM5) sind wirklich die KiCad-Fertigungsdaten der zugehörigen I/O-Boards.
Gibt es hier jemanden, der uns eventuell helfen kann herauszufinden, woran es liegt?
Antwort: wir sind selber leider keine Profis in PCB-Design.
Man kann nur outsourcen, was man nur aus Zeitgründen nicht selber machen kann. Wenn neben der Zeit auch das Know-How fehlt bekommt man beim Outsourcen keine brauchbaren Ergebnisse.
Das Projekt war bis zur Inbetriebnahme des Boards mit Sicherheit in Time und in Budget.
Und dann noch das aus dem Datenblatt:
USB_OTG_ID Input (3.3V signal) USB OTG Pin. Internally pulled up. When grounded the CM4 becomes a USB host but the correct OS driver also needs to be used.
Der Layouter wird auch der Schaltplaner sein, da der TO vom Altium Projekt den Schaltplan nur als PDF hat und das Projekt besteht paktisch nur aus den exportierten Fertigungsdaten. Der "Entwickler" des Boards will sich da wohl unentbehrlich machen. Mit der Qualität ist er aber entbehrlich geworden.
Mit in Time und in Budget meine ich vor allem das das Projekt schon bei Start kaputtgespart wurde. Wer verspricht zum kleinsten Preis und kürzester Bearbeitungszeit einen ersten Konzeptentwurf aka finale Hardware. Das Layout und den Schaltplan hat niemand reviewed, geschweige denn jemals vorher schon mal ein Raspi Trägerboard erstellt.
TO:Falls uns jemand helfen möchte, gerne melden.
Bin neugierig was die Hilfe kosten darf.
Wie von einigen hier schon korrekt angemerkt ist das ein Projektneustart.
Ich wäre gespannt auf die konkreten Projektanforderungen, die ein Linux System erforderlich machen, besonders bei den Vorkenntnissen.
damit keine Verwechslung auftritt, ich habe da meine Beiträge anscheinend missverständlich formuliert.
Ich habe mit dem Projekt nichts zu tun, ich spekuliuere nur mit wie es zu so einem Ergebnis kommen konnte damit andere diese Fehler vermeiden können.
Ich selbst habe mal ein Trägerboard mit einem RPI CM3 gebaut mit einigen Hardwareerweiterungen und eine passende Applikation dafür geschrieben. Das war ein interessantes Projekt, habe viel über Raspi dabei gelernt. Das Board hat gut funktioniert. Es waren ca. 6 Monate Vollzeit Entwicklung für Bauteilauswahl, Schaltplan, Layout, HW Inbetriebnahme, RPI Linux Anpassung, Einrichten einer Entwicklungsumgebung für den Raspi und der Applikationsentwicklung.
Wurde beim TO ebenfalls mit so einem Aufwand gerechnet ?
Wenn die Entscheidungsträger sich für eine Plattform entscheiden werden oft Zeitvorteile angenommen, die nicht existieren, wenn man Community Hardware wie Raspi, Arduino usw. verwenden will.
Aber für die eigendliche Aufgabe bei meinem Projekt war ein Raspi bzw. Linux nicht die richtige Wahl, war aber so vom Projekt Management gefordert. Ich hätte einen uC mit RTOS gewählt. Das wäre schneller zu entwickeln gewesen und flexibler in der Anwendung. Und man hätte auf bestehende Projekte und Vorwissen aufbauen können.
Die späteren Lieferengpässe bei den Raspis waren da nur noch der letzte Nagel.
@Falk: trotzdem Danke für das Supportangebot.
VG,
Markus.
PS: bevor jemand fragt, mein RPI Design ist unter Verschluss, das bekommt hier niemand zu sehen, Copyright und Firmengeheimnis usw...
