ADuC706x manuell flashen (ARM7TDMI)

[Wadim P. (wadim)]

Hallo, Leute!

Im Rahmen des Praktikums wird ein Pyrometer gebaut. Es wird ADuC7061 
verwendet. Beim fertigen Gerät soll nur vier Anschlussdrähte vorhanden 
sein: Vcc, Serial_In, Serial_Out, GND. Serial_In und Serial_Out sind die 
TXD/RXD des RS232.

So...jetzt mein Problem! Ich suche eine Möglichkeit das fertige Gerät 
über die UART zu flashen. Das Problem ist, dass das Versetzen des µC in 
den Serial Download Mode nur per Hardware geht...und das ist nicht 
möglich ohne das Gerät zu öffnen. Somit dacht ich mir, dass es vllt. 
über Software möglich sei die Bereiche des Speichers zu ändern und somit 
eine neue Firmware draufzuspielen. Im Datenblatt 
http://www.analog.com/static/imported-files/data_sheets/ADuC7060_7061.pdf 
habe ich in dem Kapitel "Flash/EE Control Interface" die acht Register 
gefunden, die auch JTAG und UART für das Programmieren verwenden. Auf 
der Seite 25 habe ich ein Beispiel für "Mass Erase" gefunden. Das habe 
ich getestet, aber da hat sich nicht getan, die LED am Port P1.6 
leuchtet weiter.

Ich verwendete dafür folgenden Code:

#define BIT24 0x1000000
#define BIT30 0x40000000

#include <Analogdevices\ioaduc7060.h>
#include <intrinsics.h>
# include "stdio.h"
# include "string.h"

int main(void)
{
  POWKEY1 = 0x1;
  POWCON0 = 0x78;       // Set core to max CPU speed of 10.24Mhz
  POWKEY2 = 0xF4;

  GP1DAT=BIT24+BIT30; //LED zum Test am P1.6
                
        //Command Sequence for Executing a Mass Erase
        FEEDAT = 0x3CFF;
        FEEADR = 0x77C3;
        FEEMOD = FEEMOD|0x8; //Erase key enable
        FEECON = 0x06; //Mass erase command
        
  while(1)  {}
}

Ist es überhaupt möglich den Speicher so manipulieren und somit den 
Quellcode verändern?

Ich hoffe, jemand kann mir hier weiterhelfen.

Viele Grüße
Wadim

[(prx) A. K. (prx)]

Vielleicht kann man einen eigenen Bootloader stricken. Der dann ohne 
Steuerleitung auskommt.

Hardwareseitig liesse sich das möglicherweise mit dem vorhandenen 
Bootloader realisieren, in dem der Controller über ein Verzögerungsglied 
(R/C-Glied) den eigenen Steuereingang bedient.

[Wadim P. (wadim)]

Hallo A.K.

Die Idee mit Verzögerungsgliedern hatte ich auch. Musste die aber 
verwerfen, da das unmöglich ist. Außerdem sind alle µC Pins schon 
belegt, somit kann ich da mit dem µC kein RC-Glied oder weiteres 
bedienen.

Es gibt schon einen Bootloader von ADI, aber, wie gesagt der geht nur 
mit Hardware. Hier ist der Link 
http://www.scienceprog.com/programming-microcontrollers-aduc70xx-using-boot-loader-and-armwsd-utility/

Wir dachten uns, dass es irgendeine Möglichkeit geben soll Teile des 
neuen Programms in den SRAM zu Schieben und von dort irgendwie die 
aktuelle Firmware zu überschreiben. Das Problem ist aber, WIE?

[(prx) A. K. (prx)]

Es ist anzunehmen, dass sich das Flash nicht aus sich selbst heraus 
überschreiben kann, d.h. dass der betreffende Code im RAM stehen muss. 
Das sollte sich mit dem Compiler auch machen lassen - wenn AD schon kein 
brauchbares Beispiel für's Flashen hat, dafür gibt es welche.

Allerdings imponiert mir die Doku von AD nicht sonderlich. Das Datasheet 
ist extrem minimalistisch. Anderswo (ST,NXP,Atmel) finde ich deutlich 
ausführlichere Reference Manuals und Appnotes dutzendweise, darunter 
nicht selten auch zum Flashen, aber bei AD?

[Wadim P. (wadim)]

A.K., danke für deine Ratschläge.


A. K. schrieb:
> Es ist anzunehmen, dass sich das Flash nicht aus sich selbst heraus
> überschreiben kann, d.h. dass der betreffende Code im RAM stehen muss.
> Das sollte sich mit dem Compiler auch machen lassen - wenn AD schon kein
> brauchbares Beispiel für's Flashen hat, dafür gibt es welche.

Hmmm...Das ist natürlich keine gute Annahme. Ich glaube, ich habe ein 
Beispiel für RAM gesehen. Da konnte man eine Funktion rein tun, aber das 
bringt mich auch nicht weiter. Naja...dann such ich mal weiter.

> Allerdings imponiert mir die Doku von AD nicht sonderlich. Das Datasheet
> ist extrem minimalistisch. Anderswo (ST,NXP,Atmel) finde ich deutlich
> ausführlichere Reference Manuals und Appnotes dutzendweise, darunter
> nicht selten auch zum Flashen, aber bei AD?

Ja, die Datenblätter finde ich auch zum Weinen. Die Hälfte muss ich da 
erraten. Ich habe eine AppNote gefunden, die ist aber leider wieder für 
den Seriellen Download.


Was tun, was tun??? Es muss doch eine Lösung geben.

[Arc N. (arc)]

A. K. schrieb:
> Es ist anzunehmen, dass sich das Flash nicht aus sich selbst heraus
> überschreiben kann, d.h. dass der betreffende Code im RAM stehen muss.
> Das sollte sich mit dem Compiler auch machen lassen - wenn AD schon kein
> brauchbares Beispiel für's Flashen hat, dafür gibt es welche.

Gibt es schon...
http://www.analog.com/en/analog-microcontrollers/analog-microcontrollers/aduc7060/products/code-examples/resources.html?display=popup

Die Lib enthält zwei Funktionen zum Schreiben und Löschen des Flashs, 
die Beispiele auch entsprechendes für RAM-Funktionen.

In den App-Notes findet man noch mehr
http://www.analog.com/en/technical-documentation/application-notes-whitepapers/resources/analog-microcontrollers/analog-microcontrollers/listing.html

> Allerdings imponiert mir die Doku von AD nicht sonderlich. Das Datasheet
> ist extrem minimalistisch. Anderswo (ST,NXP,Atmel) finde ich deutlich
> ausführlichere Reference Manuals und Appnotes dutzendweise, darunter
> nicht selten auch zum Flashen, aber bei AD?

Gibt's zumindest guten Support (meistens...)

[Wadim P. (wadim)]

Vielen Dank, Arc Net!

Ich werde mir die Libs gleich anschauen...ich hoffe das bringt mich 
weiter :)

Bei den Application Notes & Whitepapers habe ich leider nichts passendes 
gefunden.

[Frank K. (fchk)]

Eine anderer Idee:
Auf das Board kommt ein zusätzlicher Controller. Das kann auch ein 
kleiner Attiny mit Software-UART sein. Dieser übernimmt die ersten 5 
Sekunden die serielle Schnittstelle. Wenn er in dieser Zeit einen Befehl 
empfängt, kann er irgendwas machen, um den Download-Modus zu erreichen. 
Kommt die ersten 5 Sekunden nichts, gibt er die serielle Schnittstelle 
frei, und das System startet ganz normal.

fchk

[Wadim P. (wadim)]

Hallo, Frank!

Das ist natürlich eine gute Idee, aber aus Platzgründen leider nicht 
realisierbar. Die LP soll später ca. 10mm mal 25mm sein, und da muss 
eine Menge drauf. Vorallem ist es noch eine Kostenfrage...Einen 
zusätzlichen µC nur für eine Funktion zu nehmen wäre zu 
verschwenderisch.

...Es muss wirklich möglich sein den ADuC7061 entweder per Software in 
den Download Modus zu versetzen, oder durch irgendwelche Kommandos die 
Teile des Quellcodes zu löschen bzw. ersetzen.

mfg Wadim

[(prx) A. K. (prx)]

Dann kannst du versuchen, den Bootloader im Speicher zu finden und zu 
disassemblieren. Vielleicht ist da ganz am Anfang die Abfrage des 
Steuerpins und es reicht, ihn direkt dahinter anzuspringen.

[Wadim P. (wadim)]

A. K. schrieb:
> Dann kannst du versuchen, den Bootloader im Speicher zu finden und zu
> disassemblieren. Vielleicht ist da ganz am Anfang die Abfrage des
> Steuerpins und es reicht, ihn direkt dahinter anzuspringen.

Hmm...wie finde ich den? Gibt es eine Vorgehensweise? Worauf soll ich 
achten?

Ich benutze IAR, da kann ich einen Disassembly Fenster aufmachen...soll 
ich da den ganzen Speicher von 0x0 bis 0xffffffff durchforsten?

[Martin T. (mthomas) (Moderator)]

Wadim Popov schrieb:
> A. K. schrieb:
>> Dann kannst du versuchen, den Bootloader im Speicher zu finden und zu
>> disassemblieren. Vielleicht ist da ganz am Anfang die Abfrage des
>> Steuerpins und es reicht, ihn direkt dahinter anzuspringen.
>
> Hmm...wie finde ich den? Gibt es eine Vorgehensweise? Worauf soll ich
> achten?
>
> Ich benutze IAR, da kann ich einen Disassembly Fenster aufmachen...soll
> ich da den ganzen Speicher von 0x0 bis 0xffffffff durchforsten?

Das Datenblatt nennt die "upper 2kB" des "Flash/EE Memory" als Bereich, 
in dem unter anderem der vorinstallierte Bootloader untergebracht ist 
("...contain permanently embedded firmware, allowing in-circuit serial 
download..."). Aber es sind dort auch noch andere Funktionen 
untergebracht ("...a power-on configuration routine..."). Falls das 
Datenblatt keine konkrete Einstsprungaddresse für den ISP-Code nennt 
(habe keine gefunden) und auch der Analog-Support keine zusichern 
kann/will, scheint es mir keine gute Idee, auf eine durch 
disassemblieren gefundene Einsprungadresse zu setzen. Mglw. ändert sich 
diese in der nächsten Chiprevision und man darf von Neuem suchen.

Zuverlässiger erscheint der bereits von A.K. genannte Ansatz, einen 
eigenen Bootloader (einige Hersteller nennen das secondary bootloader) 
zu schreiben. Für die benötigten Basisfunktionen für erase und write 
bieten die bereits oben von Arc Net verlinkten Libraries auf analog.com 
etwas Fertiges auch für EWARM (LibFee706x).

[Wadim P. (wadim)]

Danke Martin!

Ich bin auch der Meinung, dass ich um den eigenen bootloader nicht
herumkomme. Ich habe mir die LibFee706x angeschaut und getestet und bin
der Meinung, dass ich damit auch weiter arbeiten kann...

Wenn ich mich nicht irre, dann kan ich für Neuflashen die vorhandenen
Hex-Dateien verwenden. Ich glaube, es ist sinnvoll per Software die
einzelnen Bereiche wie Startadresse, Data usw. auszulesen und in den
Flash zu schieben. Das Einzige, was mich stutzig macht, ist, was ich mit
den letzten zwei Zeilen der HEX-Datei anfangen soll. Vorallem macht mir
die vorletzte Zeile Sorgen.

In der Zeile steht die Adresse des EIP-Registers. Und da ich mich noch
nie mit dieser Materie beschäftigt habe, verstehe ich nicht so ganz, was
ein EIP ist und, wie ich diesen ändern kann. Was passiert den, wenn ich
diese Zeile garnicht betrachte? Funzt dann mein Programm nicht?

Eigentlich suche ich gerade die Info darüber im Inet, aber vllt. kann
mir jemand von euch das auch erklären.

P.S.: Die HEX-Datei, die ich zum Testen verwenden will ist im Anhang.

[Wadim P. (wadim)]

Hmmm....hat den keiner Ahnung? Schade :(

Ich bin auf ein neues Problem gestossen. Ich muss vor dem Löschen mein 
bootloader aus dem Flash in den SRAM kopieren. Wie mach ich das bzw. wie 
kann ich eine Funktion auf eine bestimmte Startadresse legen?

Im Internet habe ich nichts gescheites dazu gefunden...


mfg Wadim

[(prx) A. K. (prx)]

Wadim Popov schrieb:

> Ich muss vor dem Löschen mein bootloader aus dem Flash in den
> SRAM kopieren.

Das hatte ich dir vorgestern schon geschrieben...

> Im Internet habe ich nichts gescheites dazu gefunden...

...und auch dazu hatte ich oben erwähnt, dass in ADs Beispielcode was 
darüber zu finden ist.

Mit etwas Glück verwendest du einen (bisher ungenannten) Compiler, für 
den es tatsächlich ausführliche Doku für die ARM Umgebung gibt. Da steht 
das dann ziemlich sicher drin.

Bei der Startadresse läuft es andersrum. Überlass die Platzierung im RAM 
dem Compiler (Linker). Ist nicht wichtig, wo genau sie liegt, nur dass 
sie für diese Stelle übersetzt wurde und du sie per Name aufrufen 
kannst. Mit etwas Glück wird sie bereits vom Startup-Code automatisch 
dorthin kopiert.

[Wadim P. (wadim)]

A. K. schrieb:

> Mit etwas Glück verwendest du einen (bisher ungenannten) Compiler, für
> den es tatsächlich ausführliche Doku für die ARM Umgebung gibt. Da steht
> das dann ziemlich sicher drin.

Ich verwende ein IAR Embedded Workbench IDE (5.4 Kickstart)


> ...und auch dazu hatte ich oben erwähnt, dass in ADs Beispielcode was
> darüber zu finden ist.

Ja, ein Beispiel mit der RamFunktion gibt es zwar, ABER obwohl dort 
steht, dass der für IAR ist, stimmt das nicht...der ist für Keil 
µVision.

Egal...ich hab dann µVision installiert und die Einstellungen für RAM.C 
so geändert, wie es in der Datei beschrieben ist. Ich starte dort den 
DebugModus, aber da komme ich irgend wie nicht klar. Ich hab auch die 
erzeugte Intel Hex-Datei angeschaut und keine Einträge für den Bereich 
des SRAM (0x40000-0x47fff) gefunden. Deswegen möchte ich das gleiche 
Beispiel auch für IAR erzeugen und dort im DebugModus gucken, ob was in 
den SRAM gelandet ist.

Übrigens, wie kann ich noch erfahren, an welsher Adresse sich eine 
Funktion befindet?

mfg Wadim

[(prx) A. K. (prx)]

Erwartest du ernsthaft, dass nun sich alle Leute auf IAR oder Keil 
stürzen, um dir deren Doku zu diesem Thema vorzulesen? Sogar Tante Gugel 
wird dabei fündig.

[Wadim P. (wadim)]

A. K. schrieb im Beitrag #1791466:
> http://tinyurl.com/2uuh7tv

Cool, danke!...sogar mit Animation :D Sowas habe ich noch nie gesehen

Jetzt aber im Ernst...ich habe viele Stunden verbracht mit der Suche 
nach "ADuC RAM" und "ADuC RAM function" und ähnlichem. Und ich Blödman, 
hab nicht mal Gedanken gemacht, dass das vllt. an dem Compiler liegt.

Danke nochmal...