PIC18F4520: SRAM- und FLASH-Memory Map

Sven Scholz Gast #1132531
Lesenswert?
• ▲
▼ 
Hallo,

ich habe zwei kurze und knappe Fragen bezüglich der Memory Map des 
PIC18F4520:

a. Wie lautet die Start- und End-Adresse des SRAM Speichers?

Ich denke mal 0x000 - 0x7ff. Sicher bin ich mir da nicht. Ist das denn 
gleichzeitig auch der besagte Boot Block von Seite 263 in dem Datasheet?

b. Die Adressen des 32kB Flash-Speichers bräuchte ich zudem...

Fängt der bei 0x800 an und bei 0x7FFF auf? (Block 0 - Block 3)


Ist das SRAM überhaupt direkt adressierbar?
Wie habe ich mir den Boot Prozess vorzustellen? Stichwort: Reset Vector

Danke.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Zwirbeljupp Gast #1132554
Lesenswert?
• ▲
▼ 
Stichwort: Harvard-Architektur. Der Befehlsspeicher ist physisch vom 
Datenspeicher getrennt und beide werden über getrennte Busse 
angesteuert.

a)
Direkte Adressierung macht beim SRAM nur bedingt Sinn, da der Speicher 
bei den PIC16 und PIC18 in Bänke unterteilt ist. Grundsätzlich geht der 
SRAM von 0x000 bis 0xEFF, danach kommen die SFRs.

b)
Der Bootblock liegt im Programmspeicher (FLASH) und geht von 0x000 bis 
0x7FF. Der Programmspeicher vom PIC18F4520 geht von 0x0000 bis 0x7FFF.

Bootprozess? Naja, das es keinen wirklichen "Reset Vector" bei diesem 
PIC gibt, wird der Programmcounter auf 0x000 gesetzt und die SFRs 
initialisiert. Jau und dann gehts ab!

Was hast Du eigentlich vor???

gruß
jupp
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Severino R. #1132570
Lesenswert?
• ▲
▼ 
Sven Scholz wrote:
> Hallo,
>
> ich habe zwei kurze und knappe Fragen bezüglich der Memory Map des
> PIC18F4520:
>
> a. Wie lautet die Start- und End-Adresse des SRAM Speichers?
>
> Ich denke mal 0x000 - 0x7ff. Sicher bin ich mir da nicht.

Falsch, das SRAM (=Data Memory) liegt von 000h - 5ffh (der PIC18F4520 
hat 1536 Bytes RAM).

> Ist das denn gleichzeitig auch der besagte Boot Block von Seite 263 in
> dem Datasheet?

Nein, Der Boot Block liegt im Programm-Memory (=Flash).


> b. Die Adressen des 32kB Flash-Speichers bräuchte ich zudem...

Bitte sehr:
DS39631E-page 53: 0000h - 7fffh, wobei bei 0000h der Reset-Vektor, bei 
0008h der High-Priority Interrupt-Vektor und bei 0018h der Low-Priority 
Interrupt-Vektor sind.

> Fängt der bei 0x800 an und bei 0x7FFF auf? (Block 0 - Block 3)
Nein, siehe oben.

> Ist das SRAM überhaupt direkt adressierbar?
Ja, aber Programmcode kann nicht aus dem RAM ausgeführt werden.
http://de.wikipedia.org/wiki/Harvard-Architektur

> Wie habe ich mir den Boot Prozess vorzustellen? Stichwort: Reset Vector
Der PIC führt die Instruktion aus, die auf dem Reset-Vektor steht, also 
an Adresse 0000h.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Sven Scholz Gast #1133202
Lesenswert?
• ▲
▼ 
Ich möchte im laufenden Betrieb, also bei Abarbeitung des Programms, den 
Boot Block überschreiben lassen. Ist das generell möglich?

1. Bei der Ausführung meiner Boot Block Überschreibroutine steht der PC 
bei 0x7900. Damit dürfte ich doch dann locker die ersten Adressen 0x000 
- 0x7FF löschen und neu schreiben dürfen oder?

2. Wegen den Interrupt Vektoren: Zum Zeitpunkt des Überschreibens ist 
der globale Interrupt ausgeschaltet. Wird dann trotzdem noch irgendwie 
in 0x008 bzw. 0x0018 nachgesehen bzw. verzweigt?

Im Moment sieht es nämlich stark danach aus. Beim Versuch die ersten 
Speicherzellen des Flashes zu manipulieren kommt es anscheinend zu einem 
Reset. Der PC steht völlig falsch. (PC=0024h)

Und das passiert nur wenn ich die Adressen 0x000 - ca. 0x0040 anrühre. 
Höhere Adressbereich lassen sich neu schreiben.

Hat jemand vielleicht eine Idee, was da schief gehen könnte???

Danke sehr.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Colt F. (Firma: TUC) #1133687
Lesenswert?
• ▲
▼ 
> Ich möchte im laufenden Betrieb, also bei Abarbeitung des Programms, den
> Boot Block überschreiben lassen. Ist das generell möglich?

Grundsätzlich schon.

> 1. Bei der Ausführung meiner Boot Block Überschreibroutine steht der PC
> bei 0x7900. Damit dürfte ich doch dann locker die ersten Adressen 0x000
> - 0x7FF löschen und neu schreiben dürfen oder?

Naja, bist Du denn sicher, dass der PC nicht vielleicht doch mal zu 
einer Unterfunktion springt, die meinetwegen an der Adresse 0x200 
liegt??? Du musst Dein Programm schon so kompilieren, dass keine 
Programmteile im Bootblock abgelegt werden, andernfalls ist das 
Überschreiben des Blocks Russisches Roulette. Wird der Bootblock nicht 
explizit reserviert, beginnt der Programmcode natürlich direkt hinter 
den Interrupt-Vektoren.

> 2. Wegen den Interrupt Vektoren: Zum Zeitpunkt des Überschreibens ist
> der globale Interrupt ausgeschaltet. Wird dann trotzdem noch irgendwie
> in 0x008 bzw. 0x0018 nachgesehen bzw. verzweigt?

Sind die globalen Interrupts deaktiviert erfolgt kein Sprung zu den 
Interrupt Vektoren.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren