Problem mit openKNX UP1_Connector2040

[mobil750]

Bei meinem Umstieg auf PlatformIO habe ich das empfohlene OAM-Logikmodul geklont und dann soweit abgestrippt, das nur noch die Kernfunktionen vorhanden sind und funktionieren. Ich kann damit einen PiPico BCU Connector bespielen und per ETS eine phy. Adresse programmieren. Mehr Funktionen habe ich noch nicht drin.

Dann habe ich die PiPico BCU Connector HW Definitionen kopiert und Prog_LED, Prog_Button und SAVE an die Pinbelegung laut Schaltplan an den UP1 Controller2040 angepasst. Ich habe alles neu kompiliert und auf den UP1 kopiert. Er startet nun auch wie der PiPico Connector, wenn ich dann aber den Prog-Button betätige bewirkt das ein Reset des UP1. Was könnte da falsch sein? Das Verhalten kann ich auch reproduzieren, wenn keine BCU dran ist. Beim PiPico BCU Connector bewirkt es das ein/ausschalten des ProgMode, so wie es sein soll.

Noch ein Thema:
Ich bin in der PlatformIO komplett neu und verstehe da noch nicht alles. Ich kann die unterschiedlichen Boards kompilieren, das Upload funktioniert aber nicht. Ich verwende für den PiPico Connector unverändert die in der INI vorhandenen Einstellungen. Stimmt da was nicht oder sind da noch weitere HW Voraussetzungen gegeben? Ich möchte erstmal per USB (PiPico BCU Connector oder den UP1-Progger) die FW einspielen.
Es kommt dann zum "Error 1" wenn ich " upload_port = COM8" in [env: upload_USB_RP2040] angegeben habe.
Fehlt dieser Eintrag, dann kommt: "Error: Please specify 'upload_port' for environment or use global '--upload_port' option"

Mir ist auch nicht klar welche der verschiedenen Varianten in der PIO INI (develop, release, ...) zum Einsatz kommen. Durch was wird das gesteuert?

Für Hilfe wäre ich dankbar.

Gruß
Helmut

[Bjoern3003]

Es kommt dann zum "Error 1" wenn ich " upload_port = COM8" in [env: upload_USB_RP2040] angegeben habe.

Das kam bei mir immer, als ich den falschen Treiber installiert hatte.

Ich habe dann mit https://zadig.akeo.ie/ den richtigen Bootsel Treiber für den RP2040 installiert. Den upload_port angeben, was der richtige Weg :-)

[Ing-Dom]

wird das UP1 denn als Massenspeicher erkannt?
Wenn ja könnte es helfen (erstmal) manuell den BL über den Bootsel Button am Progger zu aktivieren.

[Ing-Dom]

habe ich das empfohlene OAM-Logikmodul geklont

welches Repo genau und welcher branch?
Ggf. würde ich support für UP1 direkt mit einbauen und einen PR machen.
An sich müsste aber nur ein paar Pinkonfigs geändert werden.

Bekommst du denn ein "blinky" auf die Hardware?

[mobil750]

Bjoern3003: Danke für den Tipp, das hat geholfen. Es war für den Pico kein Treiber installiert.


Ing-Dom: ja der UP1 wird als Massenspeicher erkannt, wenn ich beim Verbinden (USB) den BootSel Button gedrückt halte. So habe ich die FW bislang aufgespielt.
Mit deinem 2. Satz kann ich leider nichts anfangen. Sowohl der Prog_Button am UP1 als auch der Reset_Button am Progger bewirken das selbe. Der UP1 wird "ausgeworfen" und bootet dann neu.

[mobil750]

Noch ein Nachtrag zum Upload. Der Upload funktioniert nur, wenn der UP1 mit gedrücktem BootSel Button Resetted wird und als Massenlaufwerk eingebunden ist.

[Ing-Dom]

Sowohl der Prog_Button am UP1 als auch der Reset_Button am Progger bewirken das selbe. Der UP1 wird "ausgeworfen" und bootet dann neu.

der Prog-Button am UP1 führt nur auf einen GPIO. ggf. überschneiden sich hier die Pinkonfigurationen und deine FW interpretiert das drücken des Prog-Button als SAVE event?

Da du kaum Infos gibst ist es schwierig dir zu helfen.

- welches repo genau hast du geklont?
- auf welchem branch steht deine Umgebung?
- welche lokalen Änderungen hast du durchgeführt?
- welches environment baust du und lädst du hoch?

[mobil750]

Die Umgebung des verwendeten OAM-Logikmoduls ist m.M. nach irrelevant, da ich es extrem abgestrippt habe. Da kann etwas schief gehen aber ich arbeite mit 2 HW Varianten

- deinem PiPico BCU Connector
- und deinem UP1 Connector2040

Die reduzierte FW funktioniert auf dem BCU Connector wie erwartet.
Auf dem UP1 ist der Anlauf identisch (inkl. Melungen im seriellen Monitor der PIO), nur wenn ich den Prog_Button betätige geht der UP1 über Reset.
Der BCU geht dagegen in den ProgMode und meldet das auch entsprechend. Genauso kann ich den ProgMode auch wieder verlassen. Er ist auch über die ETS programmierbar.

Daraus folgere ich die FW ist OK, es könnte/müsste an der HW liegen. Entweder es gibt da einen Kurzschluss auf dem Board oder die Pinbelegung laut Schematic stimmt nicht ganz.

Anfänglich war ich davon ausgegangen, dass BCU und UP1 identische Boards mit unterschiedlichem Design sind, da es ja keine spezielle HW Definition im OAM Modul gab/gibt. Da funktionierte auf dem UP1 garnichts. Nach Studium der Schematics habe ich dann den Unterschied gesehen und die Pinbelegung für UP1 in einem eigenen HW Definitionsblock angepasst. Seit dem habe ich ein identisches Anlaufverhalten auf beiden Boards - bis auf den Prog_Button.

Ich habe folgendes bei mir eingestellt/geändert
BCU ProgLED -> GPIO21; UP1 -> GPIO6
BCU ProgButton -> GPIO22; UP1 -> GPIO7
BCU Save -> GPIO20; UP1 -> GPIO5

Das selektiere ich durch aus-/kommentieren aller entsprechenden build_flags (-D BOARD_SIRSYDOM_PIPCO_...) in der PIO INI. Mir ist nicht schlüssig welche [region] da zieht. Bei Tests habe ich gesehen, dass die [develop_RP2040] den entsprechenden Block im HW Definitionsfile umschaltet (highlighting). Wie und wodurch das gesteuert wird ist mir nicht ersichtlich.

Ich gehe davon aus, dass das so richtig ist. Wenn so, dann müsste es ein HW Problem auf dem Board sein.
Schöner wäre es allerdings, wenn da die Pins von SAVE und PROG vertauscht wären ....

[Ing-Dom]

Ich habe folgendes bei mir eingestellt/geändert
BCU ProgLED -> GPIO21; UP1 -> GPIO6
BCU ProgButton -> GPIO22; UP1 -> GPIO7
BCU Save -> GPIO20; UP1 -> GPIO5

sieht soweit richtig aus.

Ich würde jetzt mal ein ganz einfaches programm machen das
- die prog led blinken lässt
- je nach zustand des prog-btn die frequenz ändert

und ggf. auch noch den save gpio5 mit auslesen und per serial ausgeben.


Und schau mal nach ob es vielleicht Lötbrücken an den Pins 5-6-7 gibt.

2023_04_12_10_14_26_Window.png

[mobil750]

So, das Problem ist gelöst!

Der Chip ist ja alles andere als schön oder professionell aufgelötet. Da war tatsächlich ein Zinn-Kurzschluss zwischen Pin 9 (Prog_Button) und Pin 10 (GND). Natürlich unter dem Chip zwischen den Pins. Das war sehr nervenaufreibend, den rauszubekommen, aber ich habe es geschafft.

Nachdem alle Pins mal mehr oder sehr viel weniger Zinn hatten, habe ich alle Pins kontrolliert und da war doch tatsächlich noch ein Zinn-Kurzer zwischen +3,3V und SWCLK! Das hat noch weniger Spaß gemacht den rauszubekommen. Aber nun verhält sich der UP1 wie erwartet.

Also wenn jemand ein komisches Verhalten feststellt, gleich mal die Chip Kontakte verifizieren, am besten mit einem Stereomikroskop mit starker Vergrößerung. Die Zinnbrücken erkennt man nur sehr schwach, da alles voller Kolophonium ist.

Soweit, so gut. Nun gehts weiter mit der FW.

[thilog]

Was für einen UP1-Controller hast du denn, dass da Flussmittelreste drauf sind? Meine drei V00.02 sind einwandfrei und die einzigen Flussmittelreste hab ich selbst verursacht...

[mobil750]

Ich hab genau den gleichen. Die Lötstellen am Chip sind zum Teil unterschiedlich groß, teils übergroß, dass sie sich auch sehr nahe kommen.
Bei ein paar anderen ist so wenig Lötzinn drauf, dass man fast unter den Chip schauen muss um es zu sehen. Dafür gab es dann auch noch die beiden Zinnbrücken unter dem Chip. Rund um den Chip war dann gleichmäßig dick eine Kolophoniumschicht.
Ich gehe mal davon aus, dass das ein Ausrutscher ist. Ist halt ärgerlich und kostete sehr viel Zeit von erkennen bis repariert. Bin froh, dass ich es überhaupt hinbekommen habe.

[Ing-Dom]

Ich gehe mal davon aus, dass das ein Ausrutscher ist. Ist halt ärgerlich und kostete sehr viel Zeit von erkennen bis repariert.

Klar ist das ärgerlich. Lässt sich aber auch leider nicht vermeiden. In der Regel findet sich auch eine Lösung, wenn das Teil nicht (selbst) reparabel ist.

Ich hoffe aber auch, dass jedem klar ist, dass sowas immer mal passieren kann.
Hinter der OpenKNX Hardware steht keine große Firma, es gibt keine Qualitätskontrolle und keinen Test.
Nicht ohne Grund wird die Hardware nicht verkauft sondern spendenfinanziert verschenkt und darauf hingewiesen, dass es keine Funktionsgarantie gibt.

[mobil750]

Hallo Dominik,

das war keine Kritik an Dir oder openKNX. Ich lasse auch hin und wieder Platinen fertigen und war deshalb ziemlich überrascht, dass sowas überhaupt passieren kann.

Danke für Arbeit und die Möglichkeit deine Früchte nutzen zu können!

Gruß
Helmut

[Ing-Dom]

und war deshalb ziemlich überrascht, dass sowas überhaupt passieren kann.

ja ich auch. War von der Qualität von JLCPCB sehr überzeugt, und bei den BCUs gabs es nie Probleme.
Ich wüsste nicht eine die da einen Fehler gehabt hätte.

Die letzte Charge REG1 war aber in der Tat etwas unschön gelötet - hab das darauf geschoben dass es während Chinese New Year war. Das mache ich nicht mehr...
Bei den UP1 ist es mir aber nicht aufgefallen, die waren auch schon älter.
Ich beaobachte das auf jeden Fall..