johann.pascher

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: 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). 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. 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. 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. 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.

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.

--- 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. ---

Danke! Ich werde dann doch versuchen zu flashen.

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

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

Danke für dein Entgegenkommen! Es ist schön zu hören, dass du nach wie vor Freude daran hast, etwas mit Elektronik zu machen.

Es ist zumindest gut zu wissen, dass es auch andere Enthusiasten gibt, die sich mit solchen Dingen beschäftigen. Lass mich mal wissen, an was du gerade arbeitest. Wir entwickeln Hardware und Software für diverse Anwendungen.

Hier ist die überarbeitete Version des Textes: --- Das ist im Grunde kein Problem. Mit einer Lupe findet man auch beim Mini die Anschlüsse, und ein Tool zum Lesen und Schreiben ist ebenfalls verfügbar, insbesondere wenn man bereits mit ESPs gearbeitet hat. Das ist alles ohne großen Aufwand machbar, wenn ich Lust dazu bekommen würde. Schwieriger ist allerdings die Kontaktierung bei den Minis. Interessanter ist für mich jedoch, dass ich – wie schon bei anderen Produkten mit ESP – ohnehin auf die Shelly-Software verzichte und meine eigene Software aufspiele. Dann weiß ich zumindest, wo ich ansetzen muss, wenn etwas nicht rund läuft. Aber das war ein anderer Ansatz. Die Umgebung, die die Shellys derzeit bieten, ist nicht schlecht, und wenn alles noch etwas verbessert wird, könnte das durchaus eine Alternative zu eigenen Programmen sein, die alles von Grund auf selbst erledigen müssen.

Nur aus Interesse: Wird das Flashen des Shelly hier im Forum irgendwo beschrieben? Ich strebe das derzeit nicht an, aber es könnte für mich interessant sein, dies selbst zu tun. Wenn man genügend freie Zeit hat und es selbst machen möchte, ist das durchaus eine Überlegung wert. Die Kosten für ein neues Shelly sind oft geringer als die Versandkosten für Rücksendungen, insbesondere wenn man das von jemand anderem erledigen lässt. Es müssten schon eine größere Anzahl von Shelly mit demselben Problem versendet werden, um dies rentabel zu machen. Ich habe früher regelmäßig ähnliche Chips geflasht und bin daher kein Neuling. Die Mikroelektronik beschäftigt mich beruflich seit Jahrzehnten.

Nachtrag: Das Skript führt unter bestimmten Bedingungen einen Reset aus. Beim ersten Shelly, das abgestürzt ist, war das Skript auf Autostart nach dem Neustart eingestellt. Beim zweiten Shelly, das ebenfalls abgestürzt ist, war diese Einstellung in der Weboberfläche noch nicht auf Autostart gesetzt. Es handelt sich daher nicht um das von einigen vermutete Problem einer Endlosschleife durch Programmieranweisungen, sondern definitiv um eine Absturzsituation, die das Betriebssystem irgendwie zum Absturz bringt.

Das setzt voraus, dass das Shelly entweder noch als Access Point mit der IP 192.168.33.1 im Netzwerk erscheint oder in der Verbindungsliste des Routers aufgeführt wird. In diesem Fall ist das leider nicht gegeben. Auch das Drücken der Werksreset-Taste auf der Rückseite bewirkt nichts: Die LED wechselt nicht in den schnellen Blinkmodus, und das Gerät wird nicht zurückgesetzt.