Hallo zusammen, ich bin im Besitz eines Entwicklungboards mit einem TMP94FD53 (900H2-Familie) von Toshiba. Doch leider weiß ich nicht wirklich wie ich diesen Programmieren soll. Ich kann mein Programm nur in den Bootloader packen, welcher sich bei einem Neustart nicht von selbst ausführt, ich muss mit einer Software über Com1 das Programm starten. Ich habe im Datenblatt nicht wirklich viel Information gefunden wie sowas wie ISP oder JTAG (wie bei den AVRs) gehen soll, und auch nicht wie ich einstellen kann das der Bootloader automatisch das Programm startet. Mir würde es reichen wenn das Programm aus dem Bootloader automatisch startet. Hat von euch jemand erfahrung mit diesen Toshiba Controllern? Gruß NemesisoD
Ill answer in English, because people here says that "my bad German is difficult to understand". Is an expanded z80 core ! (but you new that) really cool, btw. seems much much better than own's Zilog eZ80 attempt !, very interested inded, where did you buy it ? Seems that, that part is now obsolete (is a first gen 900/H2 core), and as usual, they removed all references to it, as it has never existed, I still dot get why. Get custom to it. (May be you should try with a "current" uC, like TMP92FD54). In App Note AN029, says that the Boot loader allows you to save a program to the Flash, have you been able to do so ?. The idea is that you develop your app and you save it to Flash, when it is bigger than the internal RAM. I know this does not help that much, but I could not find much more :-(. I'll try to find a demo board manual or starter kit manual, they should explain a bit more, unless is one of those products (closed) that forces you to buy their tools and boards at exorbitant prices (but then all works (ejem)). Gruß Ale
This manual: http://www.semicon.toshiba.co.jp/docs/datasheet/en/MicroController/TMP92FD54AIF_en_datasheet_060127.pdf Explains the different boot mode options for program start and Flash programming. (It is for the newer 92FD54, but can not be much different for a 94FD53, hopefully). I hope this helps :-) Gruß Ale
I has bye it on: www.glyn.de Thank you for Your awnser. I would read the manual, but not yet. (I think my english is net so good) :-D NemesisoD
You can write in German, I can read it without (too much) trouble. As you got the Entwiklungsboard, that comes with software and dev tools, you should have the Flash utility, to save your program to flash, once flashed, and then change the boot mode to avoid the bootloader. Can you do that ? (btw, how much does it cost ?, it is a very interesting uC)
Hallo, Michael, lese gerade im Urlaub Dein Posting zum Toshiba-Controller. Ich arbeite auch mit diesen Teilen, sie sind sehr leistungsfähig, in mancher Hinsicht wesentlich besser als die AVR, mit denen ich auch arbeite für kleinere Projekte. 94FD53 und 92FD54 unterscheiden sich darin, wie sie programmiert werden können; der 94FD53 (und sein Vorgänger, der TMP95FY64 - super Teil mit 3 UARTs und 2 DACs, leider ausverkauft) konnte sein Flash noch vollständig selbst programmieren, mit entsprechenden Befehlen, die man seinem Bootloader senden konnte. Der 92FD54 benötigt dazu externen Code, d.h. einen zweiten, "aufgesetzten" Bootloader, den man erstmal in sein RAM bringen und dann starten muss. Für beide gibts Programmer-Software, über Glyn zu beziehen; diese schreiben den Bootloader und programmieren dann, sodass man von den Unterschieden kaum etwas bemerkt. JTAG hat das Teil nicht, hier sind die AVRs absolut überlegen, denn sie können damit In-Circuit-Debugging, was es bei den TLCS900s nicht gibt. Dort benötigt man immer einen ICE (In Circuit Emulator), ein viele tausend Euro teures Gerät; früher gab es bei Glyn ein Eva-Board, genannt TOPAS-900, das war ein TMP95FY64-Chip mit externem RAM und Flash-ROM und einem einprogrammierten Monitor, mit dem man, zusammen mit dem Emulator/Debugger-Programm, fast so arbeiten konnte, wie wenn man einen echten ICE hatte, und das fast zum Nulltarif. Das Teil war auf einer kleinen Platine angesiedelt mit vier 26-poligen Stiftleisten (sozusagen ein Carrier-Board), das man auf eine eigene Platine setzen konnte; alle relevanten uC-Anschlüsse waren verfügbar; damit habe ich eine grössere Zahl von Projekten realisiert und konnte sie super gut debuggen. Allerdings: der C-Compiler (sehr gut!) kostete damals auch ca. 1000 DM, mit Freeware läuft da nichts (es gibt aber die limited-Edition, die ja bei der CD Deines Kits dabei ist - wenn nicht: Herrn Ewald von Glyn ansprechen, er ist sehr hilfsbereit). Vielleicht kannst Du bei Glyn noch ein TOPAS-900 ergattern, das würde ich Dir sehr empfehlen; der 94FD53 hat zwar auch die Möglichkeit, Programme in seinem RAM unter Monitor-Kontrolle debuggend auszuführen, aber nur ca. 19k gross; der TOPAS-900 jedoch kann 256k grosse Programme ausführen, das ist etwas anderes. Ich hoffe, ich konnte Dir einige Anregungen geben. Günter (galileo14)
Hallo Günter (galileo14), ich habe mich sehr über deine Antwort gefreut, da mir bisher niemand sowirklich helfen konnte, ich bin von den AVRs bis jetzt gewohnt gewesen, das mein Programm in den Flash und nicht in den SRAM geschrieben wird. Also wenn ich das jetzt richtig Verstanden habe muss ich mir einen eigenen Bootloader schreiben, welcher die Aufgabe hat den Quellcode den ich ihn via USART schicke in den Flash zu schreiben. Und wenn ich dann Resete läuft mein Programm aus dem Flash? Wenn das so ist, muss ich das Programm in die erste Adresse des Flashs schreiben, oder kommen wie bei den AVRs vorher noch Interrupt einsprünge, im Memory Map sieht es so aus als würden die Interrupts am ende stehen. Oder gibt es bereits einen solchen Bootloader zum download? Ich danke dir schonmal für deine Mühe und schönen Urlaub. Gruß Micha
Hallo, Michael, das Thema ISP wird bei Toshiba offensichtlich nicht so sehr hochgehängt; es kommt darauf an, ob Du unbedingt ISP machen willst, oder ob Du Dich begnügst, unter Zuhilfenahme eines Flasherprogramms (z.B. ToshLoad) Deine Platine zu flashen, was viel einfacher ist. Bei meinen Projekten habe ich immer einen extra Steckverbinder für diesen Zweck, dort stecke ich den PC an und benutze das Flasher-Programm; dieses muß den Prozessor in den Boot-Modus bringen, in dem er dann bereit ist, ein Programm zu empfangen und es zu flashen; je nach Prozessor muß das Flasher-Programm einen Sekundär-Bootloader in das Prozessor-RAM bringen (ab dem "54", die Prozessoren davor - wie bereits geschrieben - benötigen den sekundären Bootloader nicht). Willst Du ISP machen, so muß Dein Code einen Bootloader enthalten, den das Programm (das ja aus dem Flash heraus ausgeführt wird) zunächst ins RAM kopiert (vorher schon auf die richtigen Adressen achten) und dann dorthin springt. Dieser Bootloader sollte am besten keine Interrupts verwenden, aber das gelingt ja. Er löscht dann zunächst das Flash und programmiert es dann. Wenn dabei allerdings etwas schiefgeht - z.B. Stromausfall - sieht es schlecht aus, dann gibt's kein ISP mehr, sondern die Platine muß dann mit einem Flasherprogramm ur-programmiert werden (was ja auch keine Katastrophe ist). Die Toshibas haben ja die andere Architektur, bei der auch Programme aus dem RAM heraus ausgeführt werden können (Von-Neumann-Architektur). Hier sind sie AVR's besser; z.B. beim ATmega128, den ich auch verwende, kann der Bootloader ja aus dem Flash heraus arbeiten, und erst wenn er feststellt, daß eine Applikation korrekt programmiert wurde (per Perüfsumme, im Applikationsbereich des Flashs - solch eine Unterteilung des Flashs gibt es ja bei Toshiba nicht), wird das Applikationsprogramm gestartet, andernfalls wird eine Programmierung wiederholt angefordert. Ich empfehle Dir daher, zunächst auf ISP zu verzichten. Bleibt aber immer noch das Problem, das Programm zu debuggen; JTAG gibt es ja nicht; hier gilt das im früheren Posting gesagte. Dort sprach ich davon, daß im Flash ein Monitor einprogrammiert ist, unter dessen Kontrolle (und in Verbindung mit dem PC-Debugger-Programm) ein "kleines" Programm in das RAM des Prozessors geladen wird und dort ausgeführt und debugged werden kann. Dies aber nur zum Testen, nicht als endgültige Applikation. Ich hoffe, diese Hinweise helfen Dir weiter. Viele Grüße Günter (bin wieder zuhause)
Hallo Günter, ich bin, wie Du, auch Ex-Anwender des 95FY64. Seit kurzem bin ich dabei, eine laufende Anwendung von diesem auf den 92FD54 zu portieren. Ich bin begeistert von diesen Controllern und kann Deine obigen Ausführungen voll bestätigen. Es gibt allerdings bei Glyn auch ein TOPAS-Board für den 92FD54. Mit diesem Board lassen sich Programme bis ca. 31 KB im internen RAM debuggen (wie Du oben schon beschrieben hast). Auf der Platine kann man selbst noch ein 128kx8 RAM auflöten, sodass sich Programme bis ca. 160KB debuggen lassen. Ich habe diese Konfiguration im Einsatz und es läuft einwandfrei (allerdings wird die Prorammspeed durch die notwendigen Wait-states und den 8-Bit externen Datenbuszugriff gebremmst). Zurück zum 95FY64: Ich setze diesen Prozessor seit ettlichen Jahren ein und hatte keine Probleme damit. Im letzten halben Jahr sind jedoch einige ausgefallen. Sie waren bis zu 2 Jahre bereits im Einsatz und haben dann Ihren Flash-Inhalt verloren. Nach neu flashen des Programms liefen die Geräte dann wieder einwandfrei. Hast Du auch diese Erfahrung gemacht? Viele Grüsse Klaus
Hallo, Klaus, ich habe das Glyn-Eva-Board mit dem 92FD54 auch; es ist ganz ähnlich wie das mit dem 53er; habe aber mit beiden noch nicht viel gemacht. Aber Danke für Deinen Hinweis bezgl. der Speichererweiterung - das werde ich irgendwann wohl auch so machen, vielleicht komme ich auf Dich zurück. Ich habe für den 95FY64 mehrere Kundenprojekte realisiert (dort werden die Platinen in Serie produziert) und von niemandem irgendwelche Probleme dieser Art gehört. Allerdings hat einer meiner Auftraggeber anfangs Probleme gehabt, diese Chips im Reflow-Ofen zu löten; da gingen viele Chips kaputt durch die Wärme. Sie haben dann Alufolien-Stückchen auf die Chips geklebt, sozusagen als Abschirmung, und seitdem funktioniert es wohl. Könnte es sein, daß Du beim Programmieren damals eine zu geringe Vcc angelegt hattest, sodaß evt. die Flash-Roms nicht voll durchprogrammiert wurden und ihre Ladung mit der Zeit verloren haben? Weiß allerdings nicht, ob soetwas technisch überhaupt sein kann. Wenn Du diesbezüglich neue Erkenntnisse hast, würde ich gerne davon hören. Kannst mich auch gerne direkt anmailen. Viele Grüße Günter
Hallo, obwohl der Thread schon sehr alt ist, hoffe ich dass ihr mir helfen könnt. Ich bin dabei einen Bootloader für den TMP92FD54AIF zu schreiben, der den Flash ONBOARD programmieren kann und den KOMPLETTEN Flash vorher löscht. Per Debugging funktioniert alles wunderbar. (Bis daraufhin, dass da Programm ja da schon im RAM läuft und nicht erst dahin kopiert werden muss, sowie die Interrupt_Tabelle nicht überschrieben wird, siehe unten). Das Problem beim Release ist jedoch, dass ich die gesamten Funktionen zuerst in das RAM kopieren muss und von dort aus ausführen muss. Per "near/far"-Funktionen funktioniert es jedoch nicht. (Ich muss alle Funktionen, quasi das gesamte Projekt in den RAM laden!? Inkl. Main(), etc.) Desweiteren lösche ich mir, wenn es denn einmal aus dem RAM laufen sollte, selbst die Interrupt-Tabelle. Da ich jedoch über RS232 die neue Firmware annehme bin ich darauf angewiesen Interrupts zu verwenden. Eine theoretische Abhilfe wäre Polling, jedoch wird die neue Firmware kontinuierlich an den Bootloader geschickt, womit es schwer werden dürfte keinen Code zu "verpassen". Ich hoffe ich konnte ihnen mein Problem ausreichend darlegen. Vielen Dank im schon im Voraus.
Hallo, Michael, ich sehe es als ein großes Problem an, aus einer Anwendung den Bootloader ins RAM zu kopieren; Du mußt ja das Flash vor der Programmierung löschen; was passiert, wenn es danach beim Programmieren zu einem Absturz kommt? Dann hast Du keine Anwendung mehr, die einen Bootloader ins RAM kopieren könnte, Du bist quasi "ausgesperrt". Auch die Verwendung von Interrupts in einem Bootloader finde ich recht unglücklich, weil unsicher (im gelöschten Flash kannst Du ja keine Vektoren haben); Polling ist daher angesagt, aber bei der geringen CPU-Auslastung kann das kein Problem sein. Ich kann Dir nur empfehlen, auf die prozessor-eigene Boot-Logik zurückzugreifen, d.h. den Prozessor in den Single-Boot-Modus zu bringen (Datenblatt) und dann zunächst den Flash-Lösch-Befehl zu geben (Löschen dauert einige Sekunden); das erspart Dir auch Probleme mit dem Passwort (das Passwort eines gelöschten Flashs besteht aus lauter FF's). Der Flash wird bei dieser Betrachtung also vom uC-eigenen Bootloader gelöscht und nicht von Deinem Bootloader; danach Deinen Bootloader mit "RAM-Load" ins RAM bringen (serieller Download); er startet dann dort und nimmt Kontakt mit Deinem (PC-)Programm auf, das Dein zu programmierendes Anwendungsprogramm in einem von Dir selbst gewählten Protokoll zum uC sendet (z.B. Intel-Hex oder Motorola-S); dort werden die Daten programmiert; evt. danach eine Checksum berechnen, ggf. nach der Methode, die Toshiba auch verwendet (Datenblatt), und den Erfolg überprüfen. Near/Far ist dabei kein beachtenswertes Problem, denn Du solltest den Bootloader, nachdem er debugged ist, auf die RAM-Adresse linken; es muß insofern nicht einmal verschiebbarer Code sein. Aber da Du ja (denke ich mal) eh in C programmierst, mußt Du Dir darüber ja keine Gedanken machen. Günter
HI, danke für die schnelle Antwort. Single Boot Mode ist definitiv ausgeschlossen, da der µC später verbaut wird und nicht mehr erreichbar ist, jedenfalls nicht auf die schnelle. Das mit auf den Ram linken versteh ich nicht ganz. Ich kompiliere den Bootloader ja fürs Flash. und Toshload (mit dem ich den Bootloader dann einmalig auf den Flash schreibe) tolleriert nur Code innerhalb des Flash, somit kann ich den Bootloadercode schlecht aufs RAM linken, da dadurch ja wieder Speicher außerhalb des Flash angesprochen werden würde.
Wenn Du die Schaltung für das Board selbst entwickelst, kannst Du ja Einfluß darauf nehmen, ob der Single-Boot-Modus erreichbar ist; hier ist, falls man nicht einen extra Steckverbinder dafür spendiert (bei meinen Geräten mache ich das!), denkbar, z.B. mittels Monoflop aus einer Break-Condition der Seriellen den Single-Boot-Modus zu starten; dann braucht man keinen extra Signalweg (aber etwas Hardware-Aufwand). Wenn der Bootloader Teil des Flash ist und bei Neuprogrammierung der gesamte Flash komplett gelöscht werden muß, wie Du im ersten Post schriebst, hast Du immer das Problem: was passiert, wenn das Flashen abstürzt oder nicht erfolgreich ist? Bei den AVR's ist das besser gelöst: hier kann ein Bootloader aus einem Teil des Flashs heraus arbeiten, und der größere Flash-Teil wird gelöscht und neu-programmiert (ich arbeite auch mit AVR's, da geht das alles wesentlich besser). Beim TLCS800 geht das m.W. so nicht. Auch ToshLoad schreibt ja seinen Bootloader im Single-Boot-Modus ins RAM. Etwas anderes ist es, wenn Du den Flash NICHT KOMPLETT löschst; dann kannst Du Dir eine Partition ausdenken, in dem Dein Bootloader, der dann im Flash stehen kann (und stehen BLEIBEN kann), angesiedelt ist; er darf nicht überschrieben werden; wenn geflasht werden soll, schreibt der Bootloader das Flash-Programm ins RAM (d.h. er kopiert es dorthin) und startet es dort; dieses RAM-Programm löscht dann selektiv die Nicht-Bootloader-Bereiche und flasht sie dann neu. So kann es auch gehen. Dann: Passwort-Problematik beachten (am besten das Passwort im Bootloader-Bereich ansiedeln)! Mit "auf den RAM linken" meine ich: das Programm, das später im RAM laufen soll, mußt Du auf diese Adresse im RAM compilieren/linken; dazu mußt Du eine entsprechende Section etablieren, das RAM-Programm dorthin ausgeben und im Linker-Control-File (LCF) dieser Section die Startadresse des RAMs geben. Da wird man ein bißchen probieren müssen, bis es klappt. Oder Du splittest diesen Prozess und compilierst/linkst das RAM-Programm separat, formatierst es als Include-File für den Flash-Bootloader (Konstanten-Tabelle), sodaß diese Tabelle (das ist dann das RAM-Programm) ins RAM kopiert und dort gestartet werden kann.
"dazu mußt Du eine entsprechende Section etablieren, das RAM-Programm dorthin ausgeben und im Linker-Control-File (LCF) dieser Section die Startadresse des RAMs geben." Genau so will ich es machen. Du hast geschrieben "das RAM-PRogramm dorthin ausgeben". Sprich ich muss den Flash-Code seperat in den RAM schreiben, sehe ich das so richtig? Nochmal zum Ablauf: Mein FirmwareCode liegt im S24-Format vor. SObald ich das Gerät einschalte habe ich 10sec. zeit den bootloader zu starten. Falls nicht läuft die normale Routine. Wenn der Bootloader gestartet wird, ruft die Main() eine weitere Funktion auf, die aus dem S24-Format die Adresse und den Code ermittelt. Diese 2 Infos werden dann an eine weitere Funktion übergeben, die dann den Flash beschreibt. Dabei geschieht dies zeilenweise und daher auch viele male. Aktuell habe ich in etwa 10 seperate Funktionen. Und diese muss ich dann so wie sie kommen in den Ram kopieren!? Danke.
Ich weiß jetzt nicht, ob bzw. wie es möglich ist, ein Programm gleichzeitig aus dem Flash heraus auszuführen und den Flash zu beschreiben bzw. zu löschen; am sichersten ist es, wenn die gesamte Funktionalität im RAM steht, d.h. alles an Programm und Funktionen, das den Flash löscht, die Kommunikation nach außen etabliert (UART?), die S32-Daten empfängt, umformatiert und ins Flash schreibt. Dazu würde ich eine Funktion schreiben, die quasi eine "main" darstellt (aber natürlich nicht so heißt) und obiges enthält; sie müßte wohl auch nicht viel initialisieren, höchstens ihre eigenen RAM-Variablen, weil das die Startup-Initialisierung nicht macht; diese Funktion und alle weiteren Subroutinen, die benötigt werden (u.U. muß man sie doppelt im Code haben, weil sie auf verschiedenen Adressen landen müssen, aber natürlich unterschiedliche Namen), sollte man in eine eigene Section ausgeben; deren Ausführungsadresse sollte die RAM-Adresse sein (also 0x400), aber die Adresse, wohin man den Code ausgibt, ist der gleiche Adreßbereich, in dem auch der Flash-Bootloader steht, also ab 0xF80000; siehe hier den Unterschied zw. "org= ..." und "area= ..." im Linker-File (im Handbuch nachschauen). Du hättest dann wohl zwei "code"-Sections, eine für die Flash-Ausführung des Bootloaders und eine für die RAM-Ausführung des RAM-Programms. Dann würde der Flash-Bootloader die RAM-Funktion ins RAM kopieren (ab 0x400) und dort als Funktion aufrufen (Stackpointer könnte wohl bestehen bleiben); nach dem Flashen wäre der Bootloader ja noch da, somit könnte die RAM-Funktion einfach mit "return" dorthin zurückkehren; ggf. müßtest Du ein paar Versuche anstellen, ob das im Prinzip so klappt, evt. mit LED's blinken lassen statt gleich zu flashen. Man muß aber außpassen, wie man das RAM aufteilt, sodaß die Variablen des Flash-Bootloaders und das später kopierte RAM-Programm sich nicht ins Gehege kommen. Das Linker-Control-File wird recht anspruchsvoll.
Hi, danke für eure Hilfe. Soweit funktioniert nun alles ganz gut. Nur bleibt ein Problem bestehen: Sobald der Codeabschnitt mit der IRQ-Tabelle kommt (0xFFFF00 - 0xFFFFFF) bricht das Flashen ab. er schreibt die erste Zeile und bleibt dann hängen. Beschrieben werden 0xFFFF00 bis 0xFFFF10, was einer Zeile im s24-Format entspricht. Lösche ich diesen Code aus der S24-Datei und flashe ohne diese Zeile funktioniert alles. Kapiert das jemand? Interrupts sind global disabled, allerdings steht an der Stelle 0xFFFF00 der Reset-Vektor, der ja aber benötigt wird, oder? Ick kann mir da keinen Reim drauf machen.
Ich habe nun nochmals weiter herumprobiert. Problem besteht weiterhin, ABER: Wenn ich die herausgenommene Zeile zum Schluss hinzufüge, quasi manuell nachflashe per Terminalprogramm (ich sende somit nur die Zeile und nicht eine Datei), funktionierts. Das hängt doch am Reset-Vektor oder? MfG Michael
Was mich hier am meisten interessiert: wie kommst Du in Deinen Bootloader, nachdem der Flash im Vektorbereich gelöscht wurde und die Programmierung abstürzt (der Fall ist Dir vielleicht noch nicht passiert, er kann aber - nach Worst-Case-Betrachtung - passieren, etwa wegen Stromausfall)? Die erste Adresse im Vektorbereich ist ja, wie Du richtig schreibst, der Reset-Vektor. >Sobald der Codeabschnitt mit der IRQ-Tabelle kommt (0xFFFF00 - 0xFFFFFF) >bricht das Flashen ab. er schreibt die erste Zeile und bleibt dann >hängen. Wie kommst Du dann wieder in den Bootloader?
Der Fall wäre akzeptabel da recht unwahrscheinlich. Die Folge wäre halt, dass der Bootloader erneut per ToshLoad aufgespielt werden müsste. Tut aber nichts zur Sache. Aber danke für den Hinweis.
Ich hab den Fehler wohl eingekreist. So wie es aussieht, löscht er den Resetvektor nicht, wenn ich einen Block-Erase des Flashes durchführe. Jmd. eine Ahnung woran das liegen könnte?
Interessant; das solltest Du weiter aufarbeiten; ich glaube das nicht;
Block-Erase löscht mit Sicherheit den gesamten Flash, inkl.
Vektor-Bereich; denn der Reset-Vektor kann ja nach einer
Neu-Programmerung woanders hin zeigen und muß dazu ja gelöscht sein,
sonst wäre er ja nicht reprogrammierbar.
Aber das kannst Du ja leicht testen; lasse den Flash mit Deiner Routine
löschen und brich' dann ab; gehe mit ToshLoad dran und lese den Flash
aus ("Read Back ...") und prüfe, ob überall FF steht (auch im gesamten
Vektorbereich).
Also, der FLash ist kurz nach dem Block löschen wirklich leer (0xFF). Kurz danach, nachdem meine Routine dann aber von vorne anfängt, weil ein falsches s24-Format übergeben wurde, steht in dem gelöschten Block 0x00. Kann sich da jmd. nen Reim drauf machen? Ich hab garantiert (!) keinen Schreibzugriff auf das Flash in dieser Zwischenzeit.
Erkennst Du die 0x00 auch wieder mit ToshLoad? Und warum fängt Deine Routine von vorne an, weil ein falsches s24-Format übergeben wird? Dann sollte doch ein Abbruch erfolgen, weil die zu programmierenden Daten nicht okay sind?
Ja, mit Toshload. Neubeginn war vermutlich falsch ausgedrückt. Er versucht nicht die korrupte Zeile erneut zu schreiben sondern erwartet eine neue s24-Datei. Fängt also wieder ganz vorne an. Ich weiß, dass ein Abbruch iwie logischer wäre, allerdings hab ich ja meinen FLash gelöscht, somit auch den Bootloader ;) der momentan ja im RAM läuft. Ist au genauso gewollt alles, da der Bootloader im neuen s24-Code wieder enthalten ist. Mir gehts im Prinzip nur um die ominöse "0x00"-Geschichte.
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.