www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Toshiba 32-bit CISC Controller


Autor: Michael Leske (nemesisod)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
This manual:

http://www.semicon.toshiba.co.jp/docs/datasheet/en...

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

Autor: Michael Leske (nemesisod)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: galileo14 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)


Autor: Michael Leske (nemesisod)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)


Autor: Klaus M. (klaz80)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.