Skriptänderung killt Shelly

[johann.pascher]

[johann.pascher]

10 minutes ago, thgoebel said:

Ja, Johann, die Lötpads für den GPIO-Port sind bei allen Minis gleich angeordnet. Hier ist das Teardown der Minis:

https://www.smarthome-forum.eu/thread/22066-teardown-shelly-mini/

Danke! Print sieht etwas anders aus bei der 3 Gen auch die Chipbeschriftung weicht ab.

[johann.pascher]

Weist du ist der ESP auf den 3gen der leiche oder zumindet gleich zu behndeln?

[tvbshelly]

Quote

 

All Gen3 devices are based on Shelly-C3F8 MCU. The Shelly-C38F are fully compatible with ESP32-C3, but with build-in more Flash and RAM 

 

[johann.pascher]

32 minutes ago, tvbshelly said:

irritweirend ist dass die Beschriftung wohl bewußt für shelly geändert wurde: ESP C38F/4523

 

[tvbshelly]

Ich vermute bei dem Posting eher einen Tippfehler:

Quote

 Shelly-C3F8 MCU. The Shelly-C38F 

Da steht C3F8 und direkt im Anschluss C38F wie es auf dem Chip auch aufgedruckt ist. Ist mir aber auch erst durch deine Bemerkung aufgefallen 😇

Edited August 28 by tvbshelly

[thgoebel]

Die Gen3-CPUs sehen so aus:

Beschriftung: ESP-Shelly C38F/4723

Hergestellt in Kalenderwoche 47 2023.

[johann.pascher]

10 hours ago, thgoebel said:

Die Gen3-CPUs sehen so aus:

Beschriftung: ESP-Shelly C38F/4723

Hergestellt in Kalenderwoche 47 2023.

Danke! Ich werde dann doch versuchen zu flashen. 

[tvbshelly]

1 hour ago, johann.pascher said:

Ich werde dann doch versuchen zu flashen. 

🤞

[thgoebel]

Bitte berichte hier, wie Du vorgegangen bist und ob es erfolgreich war! Merci vielmals!

[johann.pascher]

9 hours ago, thgoebel said:

Bitte berichte hier, wie Du vorgegangen bist.

---

Leider bin ich nicht weitergekommen. Ich habe einen USB-Adapter verwendet, um das Device zunächst mit PuTTY zu verbinden. Der Adapter funktioniert einwandfrei, wie der Test durch das Verbinden von RXD und TXD zeigt. Zum Vergleich habe ich einen älteren ESP8266 angeschlossen und erhielt dort eine Konsolenmeldung. Beim neuen ESP82C3 hingegen gab es leider keine Reaktion. Das [esptool-js](https://espressif.github.io/esptool-js/) sollte eigentlich eine vernünftige Meldung ausgeben. Wenn ich etwas falsch mache, lass es mich bitte wissen.

---

Edited August 29 by johann.pascher

[thgoebel]

12 minutes ago, johann.pascher said:

Hier ist eine verbesserte Version deines Textes:

Mein Text?

Zum Thema: In dem ganz oben verlinkten Artikel behaupte ich ja, daß Shellies der Generation 2 und 3 nicht mit „normalen“ Mitteln (ESP-Tool) zu flashen sind. Es ist ein Tool der Shelly-Entwickler erforderlich, über das ich wegen eines NDA nicht sprechen/schreiben darf. Damit ist es mir gelungen, eine neue Firmware auf einen defekten Shelly Mini 1 aufzuspielen.

[johann.pascher]

8 minutes ago, thgoebel said:

Mein Text?

Zum Thema: In dem ganz oben verlinkten Artikel behaupte ich ja, daß Shellies der Generation 2 und 3 nicht mit „normalen“ Mitteln (ESP-Tool) zu flashen sind. Es ist ein Tool der Shelly-Entwickler erforderlich, über das ich wegen eines NDA nicht sprechen/schreiben darf. Damit ist es mir gelungen, eine neue Firmware auf einen defekten Shelly Mini 1 aufzuspielen.

Entschuldiguing die erste Zeile war nicht vorgesehen. OK, dann ist es für mich nicht machbar, wenn ich das Tool der Entwickler nicht besitze. Grundsätzlich wundert es mich, dass über die serielle Verbindung absolut keine Zeichen kommen.

[tvbshelly]

Vermutlich muss man erst die "Sesam öffne dich" Code-Sequenz hinschicken, bevor man eine Antwort bekommt 😎

[tvbshelly]

Aber vermutlich ist das auch genau der Grund, warum Shelly eine eigene ESP32 Variante nutzt.

Als Hersteller will man sich ja gern schützen.

[thgoebel]

Nicht wirklich: Shellies der Generation 2 arbeiten mit einem handelsüblichen ESP32 und können dennoch nicht geflasht werden (jedenfalls nach meiner Erfahrung). 

[tvbshelly]

9 minutes ago, thgoebel said:

Nicht wirklich: Shellies der Generation 2 arbeiten mit einem handelsüblichen ESP32 und können dennoch nicht geflasht werden (jedenfalls nach meiner Erfahrung). 

Ah, ok. Gut zu wissen.

[johann.pascher]

15 hours ago, tvbshelly said:

Ah, ok. Gut zu wissen.

Es ist durchaus denkbar, dass ein einleitendes Handshake-Protokoll erforderlich ist, das den Baustein erst zu einer Antwort veranlasst. Voraussetzung dafür ist, dass man das Protokoll und auch die Übertragungsrate kennt. Andernfalls müssten viele Versuche vom Tool durchgeführt werden, um den Baustein zu einer Antwort zu bewegen. Trotzdem ist das nicht unmöglich, da auch dieser Baustein per JTAG ausgelesen werden kann, was letztlich immer funktioniert. Allerdings ist dafür ein speziell angepasstes Tool erforderlich, das diesen Baustein bereits in seiner Liste hat. Ich habe mich damit früher länger beschäftigt. Iheir kurz wie JTAG funktionet: 

JTAG (Joint Test Action Group) ist ein Standard für das Testen und Debuggen von digitalen Schaltungen, insbesondere von Mikrocontrollern und Prozessoren. Es ermöglicht direkten Zugriff auf die internen Register und Speicher eines Chips über eine spezielle Schnittstelle.

Hier ist, wie JTAG grundsätzlich funktioniert:

1. Hardware-Schnittstelle: JTAG verwendet eine serielle Schnittstelle mit mindestens vier Signalleitungen: TDI (Test Data In), TDO (Test Data Out), TCK (Test Clock), und TMS (Test Mode Select). Manche Implementierungen verwenden auch eine fünfte Leitung, TRST (Test Reset).

2. Scan-Kette: Der JTAG-Controller auf dem Chip enthält eine Reihe von Registern, die in einer Kette miteinander verbunden sind, sogenannte Scan-Ketten. Über diese Ketten können Daten in die Register geschrieben oder daraus gelesen werden.

3. Betriebsmodi: JTAG operiert in verschiedenen Modi, die über TMS gesteuert werden. Zu den wichtigsten Modi gehören der Shift-Modus zum Verschieben von Daten durch die Kette und der Update-Modus zum Übertragen der Daten in die Zielregister.

4. Test und Debugging: Durch die JTAG-Schnittstelle kann man Befehle an den Chip senden, um z.B. den Prozessor anzuhalten, Speicher auszulesen oder zu schreiben, und Peripheriegeräte zu steuern. Dies ermöglicht das Testen und Debugging auf einer sehr niedrigen Ebene, oft während der Entwicklung oder zur Fehlersuche im Feld.

5. Boundary-Scan: JTAG bietet auch die Möglichkeit, die Verbindungen zwischen den Chips auf einer Leiterplatte zu testen (Boundary-Scan), indem es Signale an die I/O-Pins eines Chips sendet und die resultierenden Signale an den anderen Enden der Verbindungen überprüft.

Ja, der ESP32-C3 verfügt über eine JTAG-Schnittstelle, die für Debugging- und Programmierzwecke verwendet werden kann. Der ESP32-C3 unterstützt JTAG über seine GPIO-Pins, die entsprechend konfiguriert werden können.

### JTAG-Schnittstelle beim ESP32-C3:
- Der ESP32-C3 kann die JTAG-Funktionalität über vier GPIO-Pins realisieren, die mit den JTAG-Signalen verbunden werden müssen: TDI, TDO, TCK und TMS.
- Diese Pins sind standardmäßig nicht zugewiesen und müssen konfiguriert werden. Die Standard-Pinbelegung sieht normalerweise so aus:
  - TDI: GPIO12
  - TDO: GPIO13
  - TCK: GPIO9
  - TMS: GPIO10

### Tools für JTAG mit dem ESP32-C3:
- **OpenOCD** (Open On-Chip Debugger): OpenOCD ist ein weit verbreitetes Open-Source-Tool, das JTAG-Debugging unterstützt. Es kann mit dem ESP32-C3 verwendet werden, um Code zu debuggen, Speicherinhalte zu überprüfen und vieles mehr.
- **Espressif-IDE (Eclipse mit Espressif-Plugin)**: Diese IDE unterstützt JTAG-Debugging und kann zusammen mit OpenOCD verwendet werden. Espressif bietet auch spezifische Konfigurationen und Dokumentationen für die Verwendung von OpenOCD mit ESP32-Chips, einschließlich des ESP32-C3.
- **JTAG-Hardware-Debugger**: Um JTAG-Debugging zu verwenden, benötigt man auch einen kompatiblen JTAG-Debugger wie den Segger J-Link, Olimex ARM-USB-OCD-H oder FTDI-basierte Debugger.

### Beispielkonfiguration:
Um OpenOCD mit dem ESP32-C3 zu verwenden, muss eine passende Konfigurationsdatei ausgewählt oder erstellt werden, die die JTAG-Pinbelegung und die Zielarchitektur (RISC-V bei ESP32-C3) definiert. Espressif stellt entsprechende Konfigurationsdateien und Anleitungen bereit, um den Einstieg zu erleichtern.

### Zusammenfassung:
Der ESP32-C3 verfügt über eine JTAG-Schnittstelle, und es gibt Tools wie OpenOCD und die Espressif-IDE, die JTAG-Debugging für diesen Chip unterstützen. Diese Tools ermöglichen es, den Chip auf einer sehr niedrigen Ebene zu debuggen und zu programmieren, was besonders in der Entwicklungsphase nützlich ist.

Alles in allem gibt es durchaus Möglichkeiten, auch einen Chip auszulesen und neu zu beschreiben, der kundenspezifisch von Shell geändert wurde. Allerdings ist der Aufwand dafür sehr hoch. Daher sollte man die Versuche zunächst mit einem Baustein durchführen, der eindeutig in Ordnung ist.

Wer Lust und Zeit hat, kann sich gerne einlesen und ausprobieren, was möglich ist. Meine Motivation dafür ist jedoch gering, da ich meine Zeit lieber mit anderen Dingen verbringen.

Edited August 30 by johann.pascher