Unbekannter µC mit BT in LED Controller

[Dodger T. (dodgertherunner)]

vielleicht könnt ihr mir weiterhelfen.
Mir sind zum 3. Mal die LED Controller abgeraucht, welche ich bei meinen 
Kindern in den Zimmern habe.
Es sind Controoler mit IR und Bluetooth, scheinbar einfacher China-Kram
Das Fehlerbild:
Beim Einstecken der Spg.-Versorgung leuchten die LEDs für eine 
Millisekunde auf und gehen dann wieder aus. Sonst ist keine Funktion 
mehr gegeben.
Ich habe euch mal ein Bild von dem Controller angehängt.
Die MosFET sind vom Typ ME12N04 und sind i.O., hab sie mit dem 
Diodentester durchgetestet.
Das 8-pinnige IC ist ein 24C02N, wohl ein EEPROM.
Am Stecker ist ein 3,3V Spannungsregler.
Der funktioniert auch noch.
Der große Käfer hat leider keinerlei Bezeichnung.

Die mit dem Multimeter durchgemessenen Pinbelegungen der ICs:
24C02N:

    1: NC
    2: NC
    3: NC
    4: GND
    5: SDA -> IC ? Pin 11
    6: SCL -> IC ? Pin 10
    7: NC
    8: VCC 3,3V

IC ? (der 16 polige)

    1: FET B Gate
    2: FET R Gate
    3: FET G Gate
    4: ?
    5: Taster 3 (Farbe)
    6: ?
    7: ?
    8: ?
    9: ?
    10: SCL -> 24C02N Pin 6
    11: SDA -> 24C02N Pin 5
    12: Quarz
    13: Quarz
    14: VCC 3,3V
    15: GND
    16: GND

Der Quartz mit 12MHz läuft auch.

Ich würde fast vermuten, der SoC hat den Code verloren. Aber ich weiß 
nicht, was es für einer ist. Keine Typenbezeichnung drauf...
Als BT Device meldet er sich mit "ELK-BLEDOM" (weiß ich vom letzten 
funktionierenden Ding, das noch da ist).
Ich würde gene mit welcher Schnittstelle auch immer, auf den SoC 
zugreifen und mir mal die SEW runterziehen bzw. aus einem 
funktionierenden IC hochladen.
Jemand eine Idee, wie ich auf den Typ kommen könnte?

Gruß
Dodger

[hinz (Gast)]

Die hier stellen sowas her:

http://www.zh-jieli.com/

Aber du wirst keine Daten bekommen.

[Dodger T. (dodgertherunner)]

Meine Hoffnung war, dass man irgendwie herausfinden kann, welche µC das 
ist.
Immerhin weiß ich die Anzahl der Pins, die Lage der Versorgungsspannung, 
der Quartz Anschölüsse und sogar der BT Antenne (15 oder 16).
Und ich kenn die Funktionen: BT, IR, I2C

Aber bei Mouser hab ich nichts passenden gefunden.

[H. (Gast)]

Das Zeugs von Jieli ist sehr oft in solchen Anwendungen drin. Die 
Controller gibt es aber nicht einzeln und es würde ja auch nichts 
nützen, da sie jeweils mit der richtigen Software programmiert werden 
müssen.

[Stefan F. (Gast)]

Dodger T. schrieb:
> Meine Hoffnung war, dass man irgendwie herausfinden kann, welche µC das
> ist.

Was willst du dann damit anstellen? Wenn du ein Datenblatt bekommst 
fehlt dir wohl immer noch das Programm, um damit etwas nützliches 
anzustellen.

[Dodger T. (dodgertherunner)]

Ich hab noch so einen Controller hier rumliegen,der glücklicherweise 
funktioniert.
Wenn ich nun wüsste, von welchem Typ der ist, dann könnte man sich an 
das Auslesen der SW wagen und sie auf den "vergesslichen" Controller 
aufspielen.
Hängt halt alles davon ab, was für ein Typ das ist....

[Stefan F. (Gast)]

Dodger T. schrieb:
> Hängt halt alles davon ab, was für ein Typ das ist....

Verstehe. Wobei da meistens der Ausleseschutz aktiviert ist. Aber klar, 
einen Versuch ist es Wert.

[H. (Gast)]

Dodger T. schrieb:
> Wenn ich nun wüsste, von welchem Typ der ist, dann könnte man sich an
> das Auslesen der SW wagen

Wird nicht funktionieren, so gut wieder jeder Microcontroller hat heute 
einen Ausleseschutz. Selbst wenn der Ausleseschutz nicht gesetzt ist 
müsstest Du auch zunächst einmal die Ausrüstung zum Auslesen und 
Programmieren besitzen. Jieli habe ich bisher in gängigen 
Programmiersystemen nicht gesehen. Hast Du derlei Ausrüstung? Dann 
würdest Du vermutlich nicht hier fragen.

> und sie auf den "vergesslichen" Controller aufspielen.

Das der Controller sein Programm "vergisst" ist in den ersten 20 Jahren 
sehr unwahrscheinlich. Wenn der defekt ist dann hat das mit sehr hoher 
Wahrscheinlichkeit eine andere Ursache.

[Drago S. (mratix)]

Ich denke nicht dass der uC sein Programm verloren hat. Eher das EEPROM 
die Settings. Oder der uC ist einfach verglüht.

Hast du einen Logic Analyzer um mal auf die Pins zu schauen? Was z.B. 
auf dem I2C Bus passiert.
Sind irgendwelche Bezeichnungen am uC abzulesen?

Könnte vielleicht ein PIC oder Padauk sein. Oder irgend ein OTP, daher 
das nachgeschaltete EEPROM.

Hier Beitrag "RGB LED Strips Controller inside ?" ist etwas ähnliches, 
mit einem Atmel920 und 24C02N, nur ohne BT.

[Dodger T. (dodgertherunner)]

Logik Analyzer nicht, nur ein Oszilloskop.
Und siehe da, auf der Clock und Datenleitung kommt tatsächlich was. Aber 
warum ist der Pegel auf der Datenleitung so unterschiedlich?
Müsste nicht jeder Puls das gleiche Level haben?

[Stefan F. (Gast)]

Dodger T. schrieb:
> warum ist der Pegel auf der Datenleitung so unterschiedlich?
> Müsste nicht jeder Puls das gleiche Level haben?

Die Frage ergibt sich sicher aus dem Schaltplan - wenn wir den den 
hätten. Da steckt vermutlich ein Widerstand hinter.

[Dodger T. (dodgertherunner)]

Hab jetzt nochmal gemessen, es werden etwa  nach PowerOn etwa 20ms lang 
Daten übertragen. Leider reicht die Speichertiefe meines Oszilloskop 
nicht aus, die Daten zu interpretieren.
Bei der Kommunikation müssen ja beide Devices senden können, oder?
Der hohe Puls liegt bei 3,3V, was der VCC entspricht, der niedrige Puls 
bei etwa 0,6V.
Damit wir der niedrige Puls doch garantiert nicht mehr erkannt.

[Dodger T. (dodgertherunner)]

Nochmal eine Teilaufnahme

[Stefan F. (Gast)]

Dodger T. schrieb:
> Damit wir der niedrige Puls doch garantiert nicht mehr erkannt.

Vielleicht soll er absichtlich als LOW interpretiert werden.

[Dodger T. (dodgertherunner)]

Dann bin ich vielleicht doch auf der falschen Fährte? Wenn der Clock da 
ist, dann muss ja auch der µC laufen.
Trotzdem kommt an den FETs nichts an.
Vielleicht sollte ich die Gates nochmal messen. Jetzt wo ich wieder 
weiß, wie mein Oszi funktioniert :-)
Um herauszufinden, ob das EEPROM noch funktioniert, müsste man wirklich 
die Datenpakete analysieren, oder?

[Stefan F. (Gast)]

Dodger T. schrieb:
> Dann bin ich vielleicht doch auf der falschen Fährte? Wenn der Clock da
> ist, dann muss ja auch der µC laufen.

Ja.

> Um herauszufinden, ob das EEPROM noch funktioniert,
> müsste man wirklich die Datenpakete analysieren, oder?

Ja, aber man müsste auch wissen, welche Daten man erwartet.

[Dodger T. (dodgertherunner)]

Nächster Analyse-Schritt:
anders als mir mein Sohnemann gesagt hat, meldet sich der Adapter 
weiterhin per Bluetooth. Ergo: der Controller läuft.
Wenn man auf die Tasten drückt, dan ändern sich die Daten auf der SDA.
Jetzt muss ich nur nochmal die Spec vom EEPROM lesen um herauszufinden, 
was gesendete und was empfangene Daten sind.
Die FET hab ich mal am Gate mit 3,3V aus dem Spg.Regler kurzgeschlossen 
und die LEDs gehen an -> FET auf jeden Fall i.O.

Bleibt die Frage: warum aktiviert die SW die Ausgänge des Controllers 
nicht.
Kennt sich jemand mit dem EEPROM Typ aus? Wie programmiert bzw. liest 
man den aus?

[Stefan F. (Gast)]

Dodger T. schrieb:
> Kennt sich jemand mit dem EEPROM Typ aus?

Das spielt erst einmal eine sehr untergeordnete Rolle. Viel wichtiger 
ist, zu wissen, was dir Firmware des µC tut. Ich denke, an diese Info 
wirst du nicht heran kommen. Ende im Gelände.

[Dodger T. (dodgertherunner)]

Hab mir jetzt mal die Mühe gemacht, das I2C Protokoll von Hand zu 
dekodieren. Sieht eigentlich gut aus. Das EEPROM sendet zumindest mal 
Daten, die nicht nur 0 und nicht nur 1 sind.
Was mich allerdings stört, ist das Übersprechen des SCL auf die SDA 
Leitung (sihe bereits gepostetes Oszi-Bild).
Ich hab mal versucht, den Pull-up der SDA Leitung durch 
Multimeter-Messung zu finden. Sind ja nur eine handvoll Widerstände auf 
der PCB. Aber cih war nicht erfolgreich, ergo würde ich sagen, es gibt 
keinen Pull-up. Also hab ich mal 8k nach VCC angelötet (10k sollten nach 
Datenblatt ausreichen) aber am Signal hat sich nichts verändert.

Noch kurioser: während ich so mit der Messspitze des Oszi "rum-geprobt" 
habe, sind die LEDs auf einmal angegangen... Nach einem power-Reset hat 
dann aber wieder nix funktioniert.

Sehr strange...

[Stefan F. (Gast)]

Dodger T. schrieb:
> Noch kurioser: während ich so mit der Messspitze des Oszi "rum-geprobt"
> habe, sind die LEDs auf einmal angegangen

Ich würde mal alle Lötstellen nachlöten.

[Dodger T. (dodgertherunner)]

Analyse-Update:
Folgende Idee: der LED Cotnroller merkt sich ja den letzten 
Betriebszustand und stellt ihm nach erneutem Einschalten wieder her.
Dafür verwendet er das EEPROM. Wenn nun auf Grund des EE Designs ein 
Fehler beim Schreiben der Daten auftritt, dann kann der Controller diese 
beim nächsten Start zwar physikalisch lesen, weiß aber nicht, was er 
damit tun soll.
Also habe ich versucht ihn dazu zu bringen, die EEPROM Daten neu zu 
schreiben, indem ich die Lichtfarbe, Helligkeit etc. per App und per 
Taster verändert habe. Alles, während die LEDs aus waren.
Meiner Interpretation nach wurden die Daten tatsächlich irgendwann neu 
geschrieben und beim nächsten Start waren die LEDs auch wieder an.
Somit wäre mein Fazit:
schlecht programmierte SW (wahrscheinlich kein verify nach dem Schreiben 
der EEPROM Daten und keine Absicherung der Daten selbst durch eine CRC 
oder eine andere Checksumme) gepaart mit einer störungsanfälligen HW 
ergeben ein äußerst günstiges China-Produkt, mit dem man viel Spaß haben 
kann....

[Dodger T. (dodgertherunner)]

Stefan ⛄ F. schrieb:
> Dodger T. schrieb:
>> Noch kurioser: während ich so mit der Messspitze des Oszi "rum-geprobt"
>> habe, sind die LEDs auf einmal angegangen
>
> Ich würde mal alle Lötstellen nachlöten.

Hab ich vorgestern schon erledigt :-)