ich habe einen HM800 Wechselrichter von Hoymiles hier liegen, der defekt ist.
Der Wechselrichter "wechselt" nicht mehr in Wechselspannung. Er ist aber über eine AhoyDTU erreichbar und man erkennt, dass die Solarpanele Strom liefern. Dieser wird aber ausschließlich für den Betrieb des Wechselrichters verwendet, sodass auch Daten an die AhoyDTU gesendet werden.
Auch erkennt man, dass Wechselspannung anliegt.
Die LED leuchtet dauerhaft rot und bedeutet "Bitte Hersteller kontaktieren".
Letzteres wurde gemacht und es wurde auf Garantie ein neuer Wechselrichter geschickt. Problem gelöst.
Den alten WR durfte ich behalten und es wäre irgendwie schade den WR einfach wegzuwerfen, wenn es z.B. nur eine Kleinigkeit ist.
Hinderlich wird wohl sein, dass das gesamte Gehäuse mit Vergussmasse aufgefüllt wurde.
Also falls jemand eine Idee hat, wär ich sehr dankbar für einen Tipp.
Fehlercode habe ich nicht ausgelesen.
Aber über Nacht die Sicherung draußen gehabt, der WR ist bei Bekannten verbaut gewesen, die technisch nicht so versiert sind.
Anbei ein Bild, wie es bei der DTU immer aussah. Also Solar nur für den Betrieb des WR, AC-Seite wird erkannt; aber halt nichts verwechselt.
Aber ggf kann ich den WR hier mal mit nem Netzteil an Solar und provisorisch AC mal auf den Schreibtisch klemmen und gucken was der hier bei mir zuhause macht.
Wo kann ich denn Fehlercodes in der AhoyDTU auslesen.
Aber ggf kann ich den WR hier mal mit nem Netzteil an Solar und
provisorisch AC mal auf den Schreibtisch klemmen und gucken was der hier
bei mir zuhause macht.
Du meinst, dass dein Netzteil eine mit einem Solarpanel vergleichbare Kennlinie besitzt?
Da wird der MPPT möglicherweise etwas orientierungslos aus der Wäsche gucken, aber vielleicht hast du ja Glück.
Du meinst, dass dein Netzteil eine mit einem Solarpanel vergleichbare
Kennlinie besitzt?
Da wird der MPPT möglicherweise etwas orientierungslos aus der Wäsche
gucken, aber vielleicht hast du ja Glück.
da braucht es keine Kennline
Hatte lange einen Hoymiles HM-300 direkt an einem 55V Akku, nachts für die Grundversorgung
Der wurde nur AC-seitig bei Sonnenuntergang zugeschaltet
Problem ist eher - wer hat ein NT das 800W liefern kann
Aber wen Du mit Ahoy zugreifen kannst - da kannst die Leistung ja reduzieren
stell aber das Netzteil beim anschließen auf 0V ein, fahr die Spannung dann hoch
Es ist nicht mein Video, das hatte ich nur gefunden.
Entweder ist der Hoymiles nicht vergossen oder derjenige hat bereits alles entfernt, weil ja sowieso verpolt gewesen war.
Bevor ich den WR öffne Probier ich es aber nochmal zuhause was der so sagt.
Aufschrauben kann ich den immer noch.
Auf dem Video sind die Abrisskanten der Vergussmassenreste doch noch gut zu sehen. Das Dingen war scheinbar auch vollvergossen.
So ein Verguß ist für wirklich ausfallkritische Elektronik, die stark Wasser, Temperaturschwankungs und und Kondensationsbelastet ist - ein probater Weg. Aber eigentlich kosten die Vergussmassen relativ teuer.
So ein Verguß ist für wirklich ausfallkritische Elektronik, die stark
Wasser, Temperaturschwankungs und und Kondensationsbelastet ist - ein
probater Weg
ja, aber wenn es dann so vergossen ist das es diese Funktionen erfüllt kann man es nicht mal kurz abreissen
man schafft es kaum es so wegzubekommen das man die einzelnen Bauteile wieder sieht
Alternativ gibt es auch PUR Vergussmassen, die durchsichtig und flexibel wie ein Riesengummibärchen bleiben. Electrolube stellt sowas her. Da kann man dann mit Sicht aufprokeln oder gar Messpitzen reindrücken. Wobei ich bei Polyurethan Lacken und Vergussmassen mittlerweile gesundheitlich vorsichtig wäre, vor allem der Härter ist sehr ungesund. Aber natürlich ist mir im Normalfall unvergossene oder nur lackierte Elektronik lieber.
Also mit dem Schreibtisch-Setup läuft der WR an und verbindet sich auch mit der DTU.
Zeigt aber das selbe Verhalten, wie vorher. Er wechselt nicht und die rote LED leuchtet dauerhaft.
Ist also intern was defekt würde ich vermuten.
Wahrscheinlich ein Kondensator oder ähnliches Bauteil.
So sieht der übrigens von innen aus, Mega klebrig das Zeug. Bei öffnen kamen mir auch ein paar Tropfen Wasser entgegen, kann natürlich auch sein, dass die ihren Weg weiter ins Innere gefunden haben.
So sieht der dann ohne die Klebemasse innen aus. Sorry für die vielen gleichen Bilder
Ich habe ein Bauteil eingekreist, dass du dir mal genauer ansehen solltest. Ist das ein Widerstand oder eine Induktivität? Der dunkle Punkt läßt einen defekt vermuten.
Ich bin beeindruckt was du da alles erkennst und du dir die Mühe machst genauer hinzuschauen!
Leider war der schwarze Punkt ein Rest Vergussmasse. Ließ sich abwischen.
Habe aber selbst gerade kritisch draufgesehen.
Die vier Widerstände sehen alle nicht mehr frisch aus:
Auf dem großen Foto sind die neben dem WLAN Modul zu sehen. (Oben rechts)
Das sind Shunts für irgendeine Strommessung. Falls da mal "R010" stand, waren das welche mit 10 Milliohm. Kannst du da mal ein Multimeter dranhalten? Es muss ja dann auf jeden Fall ~0 Ohm zeigen.
Kannst du da mal ein Multimeter
dranhalten? Es muss ja dann auf jeden Fall ~0 Ohm zeigen.
Sorry bin erst heute dazu gekommen, die alle mal zu messen. Ausgelötet habe ich sie nicht, ob da R010 drauf stand (könnte sein), kann man nicht mehr so recht erkennen.
R307 und R306 haben 5,96kOhm
R308 und R309 zählen hoch bis in den MOhm-Bereich und irgendwann kein Durchgang mehr. Wahrscheinlich wird da irgendein Kondensator aufgeladen und dann ist Ende. Die Komponenten selbst sind aber offensichtlich defekt.
Dann werden die wohl hinüber sein. Das scheint der Ausgang zu sein, oder? Also netzspannungsseitig? Das Problem ist, dass da normalerweise ja nur einige Millivolt abfallen. Wenn die durchgebrannt sind, liegt an dem dazu gehörigen Chip in der Nähe wohl eine relativ hohe Spannung an. Dann wird der vermutlich auch kaputt gegangen sein. Kannst ja mal die Leiterbahnen verfolgen, ein Datenblatt suchen, etc.
Ich glaube aber nicht, dass das das einzige Problem ist. Es muss ja einen Grund gegeben haben, warum da ein so hoher Strom geflossen ist. Der Wechselrichter wird versucht haben, nicht netzsynchron einzuspeisen.
So sieht der übrigens von innen aus, Mega klebrig das Zeug.
Wie hast Du die Platine aus dem schwarzen Gehäusedeckel herausbekommen?
Ich habe als erstes das AC Kabel abgenommen, das ist mit 6,3mm Flachsteckern auf der Platine fest, dann habe ich mit nem flachen Gegenstand die Platine gleichmäßig hochgehebelt bzw. Die vergussmasse gelöst. Irgendwann war so wenig Widerstand dass man die Platine recht einfach entnehmen konnte.
Wie hast Du die Klebemassse unter der Platine gelöst?
Die Klebemasse klebte am Alu-Gehäuse, die Platine kam sauber raus.
Ich denke ich werf den weg. Es sieht zwar recht übersichtlich aus, aber es sind wahrscheinlich deutlich mehr Komponenten betroffen und ich kann auch nicht SMD Löten. Ich habe den Ersatz auf Garantie kostenfrei erhalten deshalb stecke ich keine weitere Energie da rein.
Wäre es einfach gewesen hätte ich mir den vielleicht als Reserve weggelegt oder vielleicht für irgendwas experimentelles und auf die Vergussmasse verzichtet. Aber ich denke das lohnt so jetzt nicht mehr.
Hallo,
ich habe den WR bzw. nur die Platine an Uwe weitergegeben. Eventuell verfügt er auch bereits über die technische Ausstattung weitergehende Untersuchungen an dem WR durchzuführen.
Danke für den schnellen Versand und die nette Kommunikation, ich hab das Teil nächste Woche auf dem Tisch und schau was geht. Falls schon jemand Controllertyp, Pinout, Anzahl der Controller kennt, gerne rauslassen, danke.
Wenn da auch HM2401-51802-V1.0.0 seitlich auf dem RF-Modul steht, sollte da ein nRF51802 unter dem RF-Käfig drin sein mit dem Pinout aus dem Anhang. Also SWD sollte dann auf einem unbestückten 1.27RM (oder 2mm?) Pinheader rausgeführt sein (und natürlich auch seitlich an den castellated holes vom Modul anliegen).
Falls du dir den DSP ebenfalls anschauen willst, wird das garantiert auch ein TMS320 sein mit einem unbestückten JTAG-Header neben dran mit dem TMS320-Standard-Pinout. (Im HM-400 ist ein TMS320F28034 drin - im HM-800 vermutlich etwas "dickeres".)
S301, das ist einer der vier AC-seitigen Schalter des "Halbwellenumklappers", hat Kurzschluss, und dann waren die Shunts der Halbwellenzweige das nächste was sich aufgelöst hat. Reparatur der Widerstände hätte also nichts gebracht .
Auf den Fotos oben vom 4.7. sieht man das gut, die Sense-Leitungen von den DC-Shunts (ganz weit an den Rändern der Platine) laufen in die Mitte, wo die drei 8-Beiner nebeneinander sind. Ich meine im pv-Forum hab ich dazu schon ein Detailbild gesehen und vom pv23 die Aussage, dass das ganz ähnlich zu der Schaltung von dem anderen Modell ist.
in die Mitte, wo die drei 8-Beiner nebeneinander sind
Dann müsste man das Gehäuse in der Mitte öffnen, wenn man da ranwollte. Hast Du Maße, wo man die Flex ansetzen muss?
Zwei der drei 8-Beiner werden die Ströme der beiden Eingangskanäle Messen. Was macht der dritte? Summiert er die Ausgangsspannungen der beiden Mess-OPVs auf? Hast Du einen Schaltplan?
die Fehler passen aber nicht zusammen:
abgebrannte Shunts im DC-Eingang,
defekter S301 im AC-Ausgang.
Außerdem bekommt man die DC-Shunts mit Solarmodulen nicht kaputt.
Der mittlere 8-Beiner ist ein Doppel-OPV für die beiden Shuntströme. Der
liegt ungefähr bei (87mm; 22mm) von der Mitte der Status-LED.
Die beiden Kanäle gehen getrennt zum Controller.
Hallo Uwe,
kannst Du noch mal genau die Koordinaten per Bild zeigen,
sind es 22mm nach links und 87mm nach oben?
Vielleicht kannst Du von einer Draufsicht die Angaben einzeichnen ?
Eine andere Frage: konntest Du die Firmware per Jtag aus dem TMS320 lesen ?
Wir stiften Verwirrung, weil mehrere Themen laufen: Der Defekt (Transistor im Unfolder und AC-Shunts), und das Thema Stromsteuerung aus dem anderen Thread.
Die DC-Shunts sind nicht defekt, und mein Bild zeigt die Lage derer und des zugehörigen zweikanaligen DC-Strom-Messverstärkers.
Ein weiteres Thema ist das Auslesen der Firmware von Funkmodul und TMS, kommt noch.
Auslesen vom Funkmodul (nRF51802) hat funktioniert, hab Flash, UICR, RAM und Register.
Die Vor-Analyse ganz unten ist von Claude, ich kenn mich zu wenig aus, die zu bewerten. Seine Tips zum Auslesen haben einwandfrei funktioniert.
1
# Reading the content of a nRF51802 in a Hoymiles HM-800 microinverter
2
3
Cross references:
4
5
- Ref1: discussion on mikrocontroller.net https://www.mikrocontroller.net/topic/586015#8074969
Grab the xPack OpenOCD Windows build from its GitHub releases and unzip to something like C:\openocd. Avoid the ancient 0.10.0 binaries floating around — you want 0.12 or newer for nRF51 HWID fallback.
4
5
## Driver swap with Zadig
6
7
Run Zadig as admin, Options → List All Devices, select FT232H (or Single RS232-HS), pick WinUSB, click Replace Driver.
8
9
This removes the COM port. To get it back later, uninstall the device in Device Manager and check "delete driver software."
10
11
## First run openOCD
C:\LegacyApp\openocd\OpenOCD-20250710-0.12.0_for_nRF\bin>openocd -f interface/ftdi/ft232h-module-swd.cfg -c "adapter speed 200" -f target/nordic/nrf51.cfg
Open On-Chip Debugger 0.12.0 (2025-07-10) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 d52e355daa09f17ce64819122cb067b8a2ee0d4b
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
adapter speed: 200 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bb11477
Info : [nrf51.cpu] Cortex-M0 r0p0 processor detected
Info : [nrf51.cpu] target has 4 breakpoints, 2 watchpoints
Info : [nrf51.cpu] Examination succeed
Info : [nrf51.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
1
## Open PuTTY and open a Telnet connection on localhost:4444
RBPCONF reading 0xffffffff means readback protection is off and you're clear. Anything else and reads will come back as zeros or the connection will drop — that's the protection, and it's not bypassable.
This confirms the SWD link isn't dropping bits at 200 kHz. Note that RAM only matches because the target stayed halted — it is a readout-stability check, not an independent confirmation of the RAM contents.
2
3
## Analysis of the dumps
4
5
### Flash memory map (256 KB)
6
7
| Range | Size | Contents |
8
|---|---|---|
9
| `0x00000`-`0x007FF` | 2 KB | Nordic MBR |
10
| `0x00800`-`0x00FFF` | 2 KB | blank |
11
| `0x01000`-`0x1AFFF` | 104 KB | SoftDevice |
12
| `0x1B000`-`0x2071B` | 22,300 B | Application |
13
| `0x20800`-`0x357FF` | 84 KB | blank |
14
| `0x35800` | 20 B used | config/calibration record |
15
| `0x35C00`-`0x3AC9B` | 20,636 B | second code image |
16
| `0x3B000`-`0x3FBFF` | 19 KB | blank |
17
| `0x3FC00` | 16 B used | serial number page |
18
19
151 of 256 pages hold data. Entropy is 6.3-6.9 bits/byte across the code regions — plain Thumb, not encrypted or compressed, so it disassembles directly.
Because the struct is only 16 bytes there is no SD-ID or version field — anything read past `0x3010` is code, not metadata. `SD_SIZE` includes the MBR, so the application base is `0x1B000`, and there is a valid vector table exactly there (SP `0x20003cb0`, Reset `0x1b0f5`). The halted `pc=0x1c1a6` / `lr=0x1d495` both fall inside that application.
2
3
`0x1B000` = 108 KB is the S130 v2.0.x footprint for nRF51. Confirm the exact version by looking up FWID `0x0087` in Nordic's table.
4
5
### UICR is completely erased
6
7
Every word reads `0xFFFFFFFF`. No readback protection, no `CLENR0` (so the SoftDevice isn't write-protected either), no `BOOTLOADERADDR`, no customer data. Device identity is stored in the last flash page instead.
`11 41 91 22 42 30` as BCD is **114191224230**, and `1141` is the Hoymiles HM-400 serial prefix — matches the sticker. The whole page is mirrored into RAM at `0x200030DC`, so the app reads it at boot. At `0x20003148` there is also a bare `91 22 42 30`, the last 8 digits on their own, which is the form used as the radio pipe address.
2
3
### Second code image at 0x35C00
4
5
Has its own valid vector table (SP `0x20003498`, Reset `0x35d29`) with handler addresses self-referential to the `0x35C00` region, so it is linked to execute there — not a staged copy of the app waiting to be relocated.
6
7
It shares substantial code with the application: 1,987 matching 16-byte windows. But the offsets do not line up on one constant delta; they cluster across roughly `0x1A56C`-`0x1AC34`. A verbatim copy would show a single dominant delta, so this is the same source tree recompiled and relinked, with functions shifted relative to each other — a sibling build.
8
9
Probably a DFU/updater bootloader: 20 KB is a typical Nordic bootloader size and high flash is where they live. Against that, `UICR.BOOTLOADERADDR` is erased, so the MBR will never jump there at reset — leaving either dead factory-programmed code or something the app enters explicitly. **Open question — disassemble `0x35d29` to settle it.**
10
11
### Config record at 0x35800
12
13
Twenty bytes, rest of the page blank. Not yet identified; probably calibration.
| `0x200033E0`-`0x2000348F` | `0xDE` fill — paint pattern, untouched |
8
| `0x20003B00`-`0x20003CB0` | live stack |
9
| `0x20003CB0`-`0x20003FFF` | above stack top, never written: raw power-on SRAM noise |
10
11
`sp=0x20003ca0` is 16 bytes below the app's stack top of `0x20003cb0`, so the halt caught a shallow frame, but the dirty region below puts the stack high-water mark at 400+ bytes.
12
13
### Next steps
14
15
- Disassemble `0x35d29` to identify the second image.
16
- Load the app at `0x1B000` in Ghidra as Cortex-M0 with the vector table applied. The SVC calls into the SoftDevice map onto the S130 API and should reveal what the radio protocol is doing.
Sorry, dass die Formatierung so schräg ist. Ich hatte das als Markdown, und dann "einfach" in code-Tags eingeschlossen, aber die Code-Tags vom Markdown heben offenbar die vom Forum auf, so dass genau die Stellen, die wirklich Code-Formatierung vertragen würden, jetzt unformatiert dastehen.
Update zum DSP-Ausleseversuch:
Der TMS320F28034 ist per FT232H/OpenOCD über JTAG stabil erreichbar (IDCODE 0x1b80702f), doch nur IDCODE und Boundary-Scan sind nutzbar – letzteres erlaubt nur Pin-Beobachtung, keinen Speicherzugriff. Das OpenOCD unterstützt offenbar nicht die zum Speicherzugriff notwendigen Treiber. Daher auf diesem Weg keine Aussage, ob der Speicher geschützt ist oder nicht. Alternativer Weg zum Auslesen des Speicherschutz-Status und Dump ist das SCI-Boot-ROM über UART, sofern das Teil nicht gesichert ist.
Ja, das ist leider ein ziemlicher PITA. Ich hab mir da von aliexpress einen XDS100-v2 JTAG-Interface Nachbau kommen lassen. Dann kann man mit diesem gräßlichen TI CCS drauf zugreifen. (Ging dann aber alles. Memory dumps, register, breakpoints, ...)
