Announcement: there is an English version of this forum on 
Hallo! Eventuell kann mir jemand helfen. Ich musste eine Platine mit der Herstellersoftware über den USB Anschluss der Leiterplatte flashen, das leider missglückte. Das habe ich schon öfter gemacht, hat auch immer funktioniert. Leider diesmal nicht. Die Firmware Programmierung (mot Datei) wurde nicht abgeschlossen, jetzt geht leider nichts mehr:(. Ich habe über USB keinen Zugriff mehr. Im Forum und Internet habe ich schon gesucht und scheinbar kann man den Controller seriell programmieren!? TTl Konverter hätte ich. Die Leiterplatte hat neben der USB Buchse auch eine 8 polige Schnittstelle. Ich bin zwar Elektrotechniker habe aber mit Controllern eigentlich nichts zu tun. Eventuell kann mir jemand einen Tip geben. Der Schaden ist nicht so klein, daher meine Bitte. Danke im voraus. Egon
Angehängte Dateien:
:
Bearbeitet durch User
Der hat doch einen unlöschbaren Bootlader on chip? Wahrscheinlich macht dein USB-Anschluss nichts weiter als eine serielle Schnittstelle zum Chip zu bilden (FT232 o.ä.). Neben Rx und Tx braucht man noch ein reset-Signal und noch ein Signal um im bootlader-Modus zu starten, also noch 2 Steuersignale (RTS, DTR).
H.Joachim S. schrieb: > Wahrscheinlich macht dein USB-Anschluss nichts weiter als eine serielle > Schnittstelle zum Chip zu bilden (FT232 o.ä.) Den siehst man sogar auf dem Bild, rechts neben den Optokopplern (FTDI chip)
Hallo, danke für die Antwort. Ich denke Bootloader ist drauf. Ja,Ft232 ist verbaut. Das heißt über USB müsste es irgendwie gehen? Haben Sie eventuell eine Link zu einer Beschreibung/ Zeichnung. Danke.
Im Prinzip gibts nur wenige Baustellen: -Software auf dem PC, aber da hast du ja wahrscheinlich nichts geändert -der FTDI-Chip selbst -der MC kaputt Ganz konkret zu helfen ist schwierig, weil es letzten Endes auch auf die Beschaltung der Steuerleitungen ankommt. Da müsstest du dann schon mal die Beschaltung zwischen FTDI und M16C aufnehmen. Mit HTerm z.B. kanns du ganz gezielt RTS und DTR setzen und rücksetzen. Dann noch Rx und Tx überprüfen. Die relevanten Pins sind: -RxD/P66 -TxD/P67 -Reset (geht meist an RTS) -CNVSS (bei mir DTR) P55 und P57=/CNVSS
Ich glaube irgendwie nicht, dass der FTDI mit der RXD1/TXD1 Schnittstelle des M16C verbunden ist. RXD1 (P66) liegt auf Pin 30, TXD1 (P67) liegt auf Pin 29 bei deinem Package des M16C. Prüf doch erstmal ob es hier überhaupt eine Verbindung zu den RX/TX Pins des FTDI gibt oder ob die beiden Pins nicht vielleicht doch auf die 8pol Stiftleiste gehen.
Hallo, ich schau mir das am Wochenende mal genauer an und berichte dann...
> RXD1 (P66) liegt auf Pin 30, TXD1 (P67) liegt auf Pin 29 bei deinem > Package des M16C. Ausserdem sei noch erwaehnt das die allerersten Serien der M16C garnicht die Moeglichkeiten hatten seriell geflash zu werden wenn der Anwender das nicht in seiner eigenen Firmware vorgesehen hatte. Die konnte man damals nur parallel flashen. Olaf
Ich habe zwischen den Jahren 2000 und 2008 den M16C eingesetzt. Der "FGAFP" ist eine frühere Version mit 16MHz, später gab es den "FGPFP" mit PLL und 24MHz. Alle wurden seriell programmiert. Parallel ging auch, habe ich aber nie gemacht. Das große Problem: Die M16C hatten kein Fusebit zum Ausleseschutz, sondern eine Folge von 8 Hex-Zahlen (eine Art von Zugangscode). Und diese haben immer wieder mal gesponnen. Ab und an war es fast unmöglich, auf den Chip zu kommen. Musst man manchmal erst mehrmals löschen (Zugangscode wird dann komplett zu FF). Oft ging es dann plötzlich. Vielleicht war es auch ein Bug in der Software des Programmers (Segger). Ansonsten hatte ich nie Probleme mit den M16C. Habe die Tausendefach verbaut. Auf den Bootloader, der ab Werk im M16C ist, kann man nicht mit dem seriellen Programmer zugreifen, nur mit einem parallelen Programmer. Auch nicht aus Versehen löschen. Gruß Joachim
Joachim M. schrieb: > Das große Problem: Die M16C hatten kein Fusebit zum Ausleseschutz, > sondern eine Folge von 8 Hex-Zahlen (eine Art von Zugangscode). > Und diese haben immer wieder mal gesponnen. Ab und an war es fast > unmöglich, auf den Chip zu kommen. Musst man manchmal erst mehrmals > löschen (Zugangscode wird dann komplett zu FF). Oft ging es dann > plötzlich. Ungefähr zu gleichen Zeit habe ich auch zuviel mit M16C gemacht und kenne daher das Problem zu genüge... selbst wenn man den Code wusste hat es nicht immer funktioniert. Joachim M. schrieb: > Vielleicht war es auch ein Bug in der Software des Programmers (Segger). Nicht das ich wüsste aber könnte vor meiner Zeit hier gewesen sein. Hatte das Problem aber auch schon vor SEGGER als ich mit einem einfachen seriellen Adapter den M16C bespielt habe. Ich kann mal schauen ob ich zuhause noch diesen Programmieradapter finde. Vielleicht hilft der.
Falls die Programmierverbindung über Optokoppler läuft, wären die auch einen Blick wert. Die Dinger altern.
Til S. schrieb: > Nicht das ich wüsste aber könnte vor meiner Zeit hier gewesen sein. > Hatte das Problem aber auch schon vor SEGGER als ich mit einem einfachen > seriellen Adapter den M16C bespielt habe. Ich kenne nur dieses Programmiergerät. Wie gesagt, genau nachvollziehen konnte ich es nicht. Aber da es ja diese Programmiergeräteserie für sehr viele Mikrokontroller gab, könnte es schon sein, dass diese "spezielle Eigenheit" des M16C nicht von der Programmiersoftware abgefangen wurde. Vielleicht ein Timingproblem des M16C. Jedenfalls gab es das Problem niemals, wenn dieser Code unbenutzt gelassen wurde. Nur wenn man ihn einsetzte, konnte es eine Überaschung geben. Das dumme ist eben, dass man ungern ein Produkt mit einem offenen Kontroller verkauft. Irgendwie war diese Codesicherung seitens des M16C sowieso nicht ganz ausgereift. Mein Produkt wurde damals in China gehackt und nachproduziert. Bei Nachfolgeprodukten mit ARM-Kobntrollern ist das nicht passiert. Kann nun Zufall sein, aber naja.. Ich habe das Programmiergerät noch (Windows 98 Rechner) und könnte theoretisch den o.g. Kontroller programmieren. Allerdings scheint es sich dabei nicht um das normale 10polige Interface zu handeln, sondern um 8 Pins. Da müsste man erst wieder die Belegung herausmessen. Gruß Joachim
> Hatte das Problem aber auch schon vor SEGGER als ich mit einem einfachen > seriellen Adapter den M16C bespielt habe. Also ich kann mich an keine keine besonderen Probleme bei Flashen erinnern. Ich hab immer den E8 (der grosse schwarze) und spaeter den E8a (der kleine rot/weisse) verwendet. Ich meine aber mal irgendwo gelesen zu haben das die irgendwann mal die Interpretation der Bits geaendert haben, also 0xff soll dann 0x00 gewesen sein. Allerdings greift der E8 ja normalerweise syncron auf die Bausteine zu. Ich hab teilweise auch nur ueber einen Adapter an der seriellen Schnittstelle geflasht und ich koennte mir vorstellen das nicht jede Baudrate mit jedem Quarz am Controller funktioniert. Olaf
Hallo, ich danke einmal für die Informationen und Hilfestellungen. Ich hab mir gerade die 8 polige Steckerleiste angesehen und die Verbindungen gehen direkt zu folgenden Anschlüssen am Controller. Vcc, 2x Vss, Reset, Txd1, Rxd1, Hold, CNVss. Ich hoffe ich hab das richtig herausgemessen. Meine Frage: Könnte eine serielle Beschaltung wie oben im Link von „Pegel“ beschrieben über TTL Wandler funktionieren? Software von M16C Flasher oder kann ich mir die Arbeit sparen? Ich habe leider kein originales Programmiergerät und eines zu kaufen zahlt sich dann eher nicht aus....Danke.
Egon P. schrieb: > > Meine Frage: Könnte eine serielle Beschaltung wie oben im Link von > „Pegel“ beschrieben über TTL Wandler funktionieren? Software von M16C > Flasher oder kann ich mir die Arbeit sparen? Ich habe leider kein > originales Programmiergerät und eines zu kaufen zahlt sich dann eher > nicht aus....Danke. Ein M16C lässt sich problemlos z.B. mit dem M16C-Flasher (https://m16c.mikrokopter.de/Download.43.0.html) über die serielle Schnittstelle programmieren (man braucht natürlich einen Pegelwandler). Dazu müssen beim Reset ein paar Pins den richtigen Pegel haben (soweit ich mich erinnere CNVss -> "High", Hold -> "Low", zur Sicherheit im Datenblatt des jeweiligen M16C nachschauen). Falls die Code ID gesetzt ist sollte man diese kennen.
Hallo, danke. Kann sein, dass diese Beschaltung der Pins sowieso richtig vorhanden sind und der Controller „immer bereit“ für das überschreiben der Firmware ist. Im Normalfall kann man die Firmware über USB ohne irgendeiner Änderung überschreiben (Leiterplatte ist fix über den USB Anschluss mit dem PC verbunden). Entschuldige meine Unwissenheit im diesem Bereich. Danke.
:
Bearbeitet durch User
> Meine Frage: Könnte eine serielle Beschaltung wie oben im Link von > „Pegel“ beschrieben über TTL Wandler funktionieren? Ja, kann funktionieren. Ich hab das schon gemacht. http://people.redhat.com/~dj/m32c/ http://people.redhat.com/dj/m32c/flash-guide.pdf http://www.delorie.com/electronics/e8a-mini/ https://www.renesas.com/us/en/document/man/e8e8a-emulator-additional-document-users-manual-notes-connecting-h83664f-h83687f-h83694f-h836037f https://webpages.uncc.edu/~jmconrad/ECGR4101Common/SKP16C62P/App_Notes/M16C62_Flash_Asynchronous_Serial_Programming.pdf Olaf
Ich werde das nächste Woche mal testen und berichten. LG
Egon P. schrieb: > Kann sein, dass diese Beschaltung der Pins sowieso > richtig vorhanden sind und der Controller „immer bereit“ für das > überschreiben der Firmware ist. Ziemlich sicher nicht. Die Pegel an den beiden Pins signalisieren dem M16C dass er im ROM Bootloader bleiben soll damit man ihn gegebenenfalls programmieren kann. Wenn diese Pegel nicht stimmen wird das User-Programm ausgeführt.
> Ziemlich sicher nicht. Die Pegel an den beiden Pins signalisieren dem
Man muss da unterscheiden zwischen Bootloader von Renesas wo du recht
hast und einem vom Anwender geschriebenen Bootloader. Letzerer prueft
vermutlich erstmal die Seriennummer der Firmware bevor er sie startet.
Das erkennt der OP aber daran ob er bisher mit einem einem Renesas-Tool
Hexfiles oder Binfiles geflasht hat oder mit einem speziellen
FirmwareUpdatetool vom Anwender gearbeitet hat. Und wenn letzeres der
Falls war dann hat er hoffentlich auch eine Firmware in einem Format mit
dem der Renesas-Flasher etwas anfangen kann. .-)
Olaf
Olaf schrieb: > > Man muss da unterscheiden zwischen Bootloader von Renesas wo du recht > hast und einem vom Anwender geschriebenen Bootloader. Warum denkst Du habe ich "ROM Bootloader" geschrieben? Auf die verschiedenen Aspekte eines "User-Bootloaders" bin ich bewusst nicht eingegangen weil sich aus den bisherigen Information wenig dazu sagen lässt. Wenn man eine Blick auf die Update-Datei werfen könnte, die programmiert werden soll, könnte man eventuell mehr dazu sagen.
Joachim M. schrieb: > > Irgendwie war diese Codesicherung seitens des M16C sowieso nicht ganz > ausgereift. Mein Produkt wurde damals in China gehackt und > nachproduziert. Die ersten Versionen des ROM Bootloader des M16C hatten die Prüfung der Code-ID nicht sauber gemacht, man konnte anhand der Antwortzeit auf das "Unlock" Kommando erkennen ob ein einzelnes Byte passt. Damit braucht man nur noch maximal 7 x 256 Versuche um die 7 Byte der Code-ID herauszubekommen. Dieses Problem wurde aber relativ bald behoben. Natürlich gibt es noch andere Ansätze um die Code-ID zu umgehen, je nach dem wie viel Aufwand man reinsteckt.
Hallo, habe es heute versucht. Angeschlossen über TTL Wandler den Rest beschalten wie Dieter es beschrieb ( über 8 polige Steckerleiste). Siehe da- es funktionierte. Bootloader wurde nach Reset angezeigt. ID Nummern FF.... eingegeben. Mit Mot Datei programmiert und läuft. Danke an alle! LG Egon
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.