Fragen zu Problemen mit nanoVNA ....

  • Daher der Gedanke (ohne es sicher zu wissen) den Akku abklemmen, dass alles wirklich Spannungsfrei ist, dann wieder anstecken in geladenem Zustand und probieren, ob alles funktioniert.

    Keine Garantie, dass es funktioniert, aber eine kleine Chance bleibt, dass es vielleicht hilft.

    Marco, das wäre vor dem Weg in die Tonne noch einen Versuch wert.

    73, Michael, DF2OK.
    ~ AFU seit 1975 ~ DARC ~ G-QRP-Club ~ DL-QRP-AG GM ~ AGCW ~ FISTS ~ QRPARCI ~ SKCC ~ QRZ.COM ~ YouTube ~
    - Morsecode ~ The ART of communication. (DF2OK) - No computer required, just human skill. And: Real pilots don't need engines.

  • Wenn das flashen über DFUse nicht funktioniert, weil die Load Firmware eine Macke hat, bleibt auch noch die Progrmmierung über einen In-Circuit ST-Link Programmer, das ist der native Weg um einen STM32 zu programmieren. Wäre schade, wenn er nicht mehr zum Leben erweckt werden könnte. Vielleicht ist hier ja jemand, der mit STM32 arbeitet und einen Programmer hat.

    https://www.st.com/en/development-tools/st-link-v2.html


    Clones von dem originalen STM Programmer gibt es für kleines Geld

    ST-Link V2 Debugger und Programmer
    ST-Link V2 mit Anschlusskabel Der ST-Link V2 ist ein schaltungsinterner Debugger und Programmer für STM8 und STM32 Microcontroller. Die SWIM…
    www.roboter-bausatz.de

    73 Günter

    "For every complex problem there is an answer that is clear, simple, and wrong" (H.L. Mencken)

  • Das ist richtig. Ich habe auf diese Art vor einiger Zeit schon mal einen alten NanoVNA repariert. Noch bevor der Markt von den ganzen chinesischen Klonen überschwemmt wurde. Das Problem ist eigentlich nicht der STM32 Programmer, die kosten nicht die Welt. Das Problem ist, die richtigen Programmierpins des STM32 auf der Leiterplatte zu finden. Die sind nämlich oft nicht extra herausgeführt. Nicht wie bei den bekannten STM32 Microcontroller Boards like „Blue Pill“, „Black Pill“ und wie sie alle heißen, da sind die Pins extra auf der Leiterplatte herausgeführt.

    Leider hat Marcos NanoVNA ein großes Manko: Dieser ist von Sysjoint und die setzen als CPU keinen echten STM32 von STMicroelectronics ein, sondern einen Artery AT32F403AVGT7. Ich habe mich mit dem Teil nicht weiter beschäftigt, ist wohl ein chinesischer Nachbau. Mir ist die Zeit dafür zu Schade. Und da liegt der Hase im Pfeffer: Der braucht wohl einen eigenen Programmer.

    Siehe auch diese beiden Threads aus groups.io:

    https://groups.io/g/nanovna-f-v2/topic/105082331#msg540

    https://groups.io/g/nanovna-f-v2/topic/nanovna_f_v2_gone_totaly_dead/104094481

    Wenn es ein echter STM32 auf der Leiterplatte gewesen wäre, hätte ich es sogar für Marco versucht. Schade. Ich kann nämlich kaputte Geräte auch nicht ausstehen.

  • Progrmmierung über einen In-Circuit ST-Link Programmer

    Günter,

    ich bin kein Experte auf diesem Gebiet, aber es scheint mir sinnvoll noch zu prüfen, ob der Programmer funktioniert. Denn in den meisten NanoVNA stecken architekturgleiche ARM Chips, meistens aber von GigaDevice, daher beginnen diese auch mit der Bezeichnung GD32 anstatt STM32. Letztendlich könnte man, wenn man sonstige Fehler ausschließen kann, noch den ARM auslöten und einen neuen einsetzen. Die kosten knappe 10 Euro.

    Edit: Hallo Dirk, da haben wir parallel geschrieben. Aber wie man sieht, scheint es einen Blick wert zu sein bzgl. Programmer. Es gibt Fundstellen die berichten, dass aus Programmiersicht nahezu alle verwendeten ARMs "baugleich" sind, teilweise sollen sie sogar von der Ausführungsgeschwindigkeit und vom Flash-Speicher her besser sein als die von STM.

    vy 73 de Dirk, DH4YM

    Edited once, last by DH4YM (February 27, 2026 at 6:27 PM).

  • Dann ist er reif für die Tonne. Beim Kalibrieren und anschließenden Speichern der Kalibrierung für einen bestimmten Frequenzbereich hängt er sich auf. Die letzte FW Version 0.6.0 ging Problemlos zu Flashen.

    Den Fehler kenn ich von den SV4401, etc

    Sobald man die Kalibrierung durchgeführt hat, gefriert die Anzeige. Wenn man diese wieder löscht, läuft der VNA wieder.

    Nur ist das bei dem Schweinepreis mit der Mülltonne nicht so schmerzfrei. Aber offenbar ist das noch nicht das Ende der preislichen Fahnenstange, denn es gibt ja noch genügend die bereit sind für den Chinamist fast 500€ auf den Tisch zu legen....

  • Danke Dirk und Dirk für den Hinweis. Da schaffen die Chinesen es, beim clonen immer noch eine Schikane einzubauen.

    73, de Günter

    "For every complex problem there is an answer that is clear, simple, and wrong" (H.L. Mencken)

  • Wenn das flashen über DFUse nicht funktioniert, weil die Load Firmware eine Macke hat, bleibt auch noch die Progrmmierung über einen In-Circuit ST-Link Programmer, das ist der native Weg um einen STM32 zu programmieren.

    Den STM32 braucht man beim tinySA, ebenfalls DFUse. Beim NanoVNA wird die Firmware lediglich in den Speicher des VNA kopiert und dann einmal aus und wieder einschalten. Das wars ... man braucht da keinen Programmer. Siehe auch auf meiner Webseite zu tinySA und NanoVNA. Gerade noch erkannt: "In-Circuit ST-Link Programmer," aber ob das möglich ist?

    Das Problem ist eigentlich nicht der STM32 Programmer, die kosten nicht die Welt.

    Den gibt es zum freien Download, der kostet nichts.

    73 de Volker https://dl3lk.darc.de/

    DOK M19 / Feld Hell Club #6008 (Zum Avatar: Hatte ich beruflich mit zu tun)

  • Volker, ein In-Circuit-Programmer ist ein Hardware Modul, das kann man nicht Downloaden. Man braucht so etwas, um einen jungfräulichen µ-Controller, mit grundsätzlichen Kommunikations-Fähigkeiten, wie z. B. einem Bootloader über eine Hardwareschnittstelle zu programmieren.

    Was du da beschreibst ist die Vorgehensweise bei einem NanoVNA bei dem der Bootloader im Prozessor schon aufgespielt ist und die Kommunikation mit der Außenwelt noch funktioniert. Das ist bei dem beschriebenen NanoVNA hier, aus welchem Grund auch immer, offenbar nicht mehr der Fall.

    73, de Günter

    "For every complex problem there is an answer that is clear, simple, and wrong" (H.L. Mencken)