AVR mehr Speicher (RAM) als erwartet

[Simon G. (sigro)]

Hallo zusammen,
wenn ich den folgenden Code ausführe steht bei einem ATmega16m1 mit 1k 
Ram der Zeiger Z am Ende der Ausführung auf 0x081F.
Ich würde aber 0x0500 erwarten.

Es sieht für mich so aus, als hätte der AVR einen größeren Speicher als 
im Datenblatt vermerkt.

Kennt jemand dieses "Problem"? Hat jemand ähnliche Erfahrungen gemacht 
oder hat eine Erklärung für dieses Phänomen?

Vielen Dank Simon

ldi  r30,  0x00   ;initialisiere Zeiger Z auf
ldi  r31,  0x01   ; 0x0100 (Beginn RAM)
ldi  r16,  0x00
ldi  r17,  0x00
loop:
st   z,    r16    ; Speichere Register 16 auf Adresse Z
ld   r17,  z+     ; Lade Adresse Z in Register 17 und inkrementiere Z
cpse r16,  r17    ; Wenn R16 und R17 gleich sind überspringe nächsten Befehl
jmp end           ; Springe ans Ende
inc  r16          ; inkrementiere Wert von R16
jmp  loop         ; wiederhole alles
end:
jmp end           ; endlosschleife zur Erkennung von Ungleichheit

[Volker (Gast)]

Vielleicht auch mal mit anderen Werten als 0 testen?

[Volker (Gast)]

Machst du ja - sorry...

[Georg I. (dschi-ai)]

Weil der RAM erst bei 0x0100 beginnt. Siehe Datenblatt S. 21

[Volker (Gast)]

Machst du doch nicht :-)
Du testest pro Speichersteller immer nur einen Wert.
In der Schleife welche wahrscheinlich alle 256 Werte abfragen soll 
darfst du natürlich nicht z inkrementieren.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> st   z,    r16    ; Speichere Register 16 auf Adresse Z
> ld   r17,  z+     ; Lade Adresse Z in Register 17 und inkrementiere Z
Mach da mal noch was anderes zwischen Schreiben und Lesen. Die paar ns 
kann sich sogar eine offene Leitung einen Pegel merken...  :-o

Ich würde z.B. immmer schon die nächste Adresse schreiben und die 
(unterschiedliche) vorherige dann erst zurücklesen...

Am besten wäre es, Zufallswerte auszugeben, und nicht etwas, das sich 1. 
wiederholt und 2 so wiederholt, dass immer die Adressleitungen 0..7 
gleich den Datenleitungen 0..7 sind...

[Uwe (Gast)]

dir ist schon klar das du r16 in r17 speicherst und danach guckst ob die 
gleich sind ? Die sind immer gleich. Deshalb hast du eine Endloschleife 
programmiert. Diese schreibt irgendwann in den Stackbereich falls dieser 
existiert und irgendwann hinter den gültigen RAM Bereich.

[Simon G. (sigro)]

Vielen Dank für die schnellen und vielen Antworten.

Georg Ious schrieb:
> Weil der RAM erst bei 0x0100 beginnt. Siehe Datenblatt S. 21

Deshalb initialisiere ich den Z Pointer auch auf 0x0100
0x0100 + 0x0400(1kByte RAM) = 0x0500

Volker schrieb:
> Machst du doch nicht :-)
> Du testest pro Speichersteller immer nur einen Wert.
> In der Schleife welche wahrscheinlich alle 256 Werte abfragen soll
> darfst du natürlich nicht z inkrementieren.

Dieses "Programm" dient nur zur Verdeutlichung des Problems, eigentlich 
möchte ich den Speicher auf festsitzende Bits testen.

Lothar Miller schrieb:
>> st   z,    r16    ; Speichere Register 16 auf Adresse Z
>> ld   r17,  z+     ; Lade Adresse Z in Register 17 und inkrementiere Z
> Mach da mal noch was anderes zwischen Schreiben und Lesen. Die paar ns
> kann sich sogar eine offene Leitung einen Pegel merken...  :-o

Ich habe einfach mal einige nops eingefügt, das ändert aber leider 
nichts am Ablauf.

> Ich würde z.B. immmer schon die nächste Adresse schreiben und die
> (unterschiedliche) vorherige dann erst zurücklesen...
>
> Am besten wäre es, Zufallswerte auszugeben, und nicht etwas, das sich 1.
> wiederholt und 2 so wiederholt, dass immer die Adressleitungen 0..7
> gleich den Datenleitungen 0..7 sind...

Da mir auf anhieb keine einfache Zufallserzeugung einfällt, habe ich 
einfach r16 auf 4 initialisiert. ändert leider auch nichts.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Simon G. schrieb:
>>> st   z,    r16    ; Speichere Register 16 auf Adresse Z
>>> ld   r17,  z+     ; Lade Adresse Z in Register 17 und inkrementiere Z
>> Mach da mal noch was anderes zwischen Schreiben und Lesen. Die paar ns
>> kann sich sogar eine offene Leitung einen Pegel merken...  :-o
> Ich habe einfach mal einige nops eingefügt
Das ändert nichts daran, dass der Datenbus nicht geändert wird. Schreib 
mal mit einem anderen (Y-)Pointer ganz was anderes (z.B. 
Komplementärwert von R16) auf/über/in den Datenbus...

Ich kann mir zwar schon vorstellen, dass einfach ein größerer uC 
umgelabelt wird, aber 0x081F ist irgendwie ein blöder Wert. Hast du da 
auch mal einen anderen ATmega16m1 ausprobiert?

[spess53 (Gast)]

Hi

Solche Effekte entstehen auch bei unvollständiger Adresscodierung. Dann 
erscheint die gleiche Speicherzelle auf 2 oder mehr Adressen. Allerdings 
hätte ich dann auch einen anderen Endwert erwartet.

MfG Spess

[Simon G. (sigro)]

Lothar Miller schrieb:
> Am besten wäre es, Zufallswerte auszugeben, und nicht etwas, das sich 1.
> wiederholt und 2 so wiederholt, dass immer die Adressleitungen 0..7
> gleich den Datenleitungen 0..7 sind...

Habe jetzt folgendes Programm benutzt, mit dem Ergebnis, daß das 
Programm bei 0x0850 abbricht.

.DEF lfsr0   = r6  ;3 Register bilden ein 23bit-LFSR
.DEF lfsr1   = r7  ; (linear rückgekoppeltes Schieberegister)
.DEF lfsr2   = r8  ; für den Pseudo-Zufallszahlengenerator
.DEF lfsr3   = r9  ; für den Pseudo-Zufallszahlengenerator
.DEF xh = r27

.macro next_down ;(reg, label)
  dec @0
.if pc-@1 < 64
  brne @1
.else
  breq pc+2
  rjmp @1
.endif
.endmacro

ldi  r30,  0x00
ldi  r31,  0x01
ldi  r16,  0x04
ldi  r17,  0x00
loop:
call zufallszahl
mov r16,  r26
st   z,    r16
nop
.
.
.
nop
ld   r17,  z
adiw r30,  1
cpse r16,  r17
jmp end
jmp  loop
end:
jmp end

zufallszahl:
zufallsz1: ; *** Pseudo-Zufallszahl erzeugen (per LFSR mit 23 Bits)
; Input:  R16 = Anzahl n der zu erzeugenden Bits (1 ... 16)
; Output: XH:XL = Zufallszahl (in den unteren n Bits)
  zuf_lp1: ;n Shift-Operationen mit Rückkopplung
    mov xh,lfsr1
    lsl xh ;bit 13 des LFSR steht nun in bit 6 von xh
  eor xh,lfsr2 ;bit 22 und 13 des LFSR sollen verknüpft werden
  lsl xh ;jetzt in bit 7
  lsl xh ;jetzt im Carry-Flag
  rol lfsr0 ;gesamtes LFSR links-shiften und neues Bit einschieben
  rol lfsr1
  rol lfsr2
  next_down r16,zuf_lp1 ;n "neue bits" stehen bereit in LFSR
  movw x,lfsr0
ret

[Simon G. (sigro)]

spess53 schrieb:
> Hi
>
> Solche Effekte entstehen auch bei unvollständiger Adresscodierung. Dann
> erscheint die gleiche Speicherzelle auf 2 oder mehr Adressen. Allerdings
> hätte ich dann auch einen anderen Endwert erwartet.
>
> MfG Spess

Hi,
in die Richtung gingen meine ersten Vermutungen auch, nur schwankt der 
Endwert um einiges, und ich sehe bei höheren Adressen keine Änderungen 
im regulären Adressraum mehr.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Simon G. schrieb:
> st   z,    r16
> nop
> .
> .
> .
> nop
> ld   r17,  z
Immer noch: der Datenbus leibt zwischen Schreiben und Lesen unberührt. 
Und das, was Simon G. schrieb:
> nur schwankt der Endwert um einiges
Deutet irgendwie auf floatende Datenleitungen hin...

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

Wie Lothar schon schrieb: Zumindest bei externen Bussystemen ist 
bekannt, dass ein offener Bus geschriebene Daten aufgrund der Kapazität 
noch eine Weile tragen und folglich geschriebene Daten bei alsbaldigem 
Lesen wieder zurück liefern kann.

Ob es etwas damit zu tun hat lässt sich feststellen, indem man in 
aufeinander folgende Bytes verschiedene Werte schreibt und stets den 
Wert des vorletzten kontrolliert.

[Simon G. (sigro)]

Lothar Miller schrieb:
> Simon G. schrieb:
>> st   z,    r16
>> nop
>> .
>> .
>> .
>> nop
>> ld   r17,  z
> Immer noch: der Datenbus leibt zwischen Schreiben und Lesen unberührt.
> Und das, was Simon G. schrieb:
>> nur schwankt der Endwert um einiges
> Deutet irgendwie auf floatende Datenleitungen hin...

neues Programm, altes Ergebnis.

ldi  r30,  0x01
ldi  r31,  0x01
ldi  r18,  0x55
loop:
call zufallszahl
mov r16,  r26
st   z,    r16
sts 0x100, r18
ld   r17,  z
adiw r30,  1
cpse r16,  r17
jmp end
jmp  loop
end:
jmp end

am Ende steht aber bei 0x100 kein 0x55 mehr. scheint doch irgendwie mit 
unvollständiger Adresscodierung zu tun zu haben.

[MWS (Gast)]

Simon G. schrieb:
> Habe jetzt folgendes Programm benutzt,

Jetzt dachte ich immer, man müsste den SP initialisieren, wenn man Calls 
benutzt... Per Default steht der beim ATM16M1 auf $0000, wenn der Call 
ausgeführt wurde auf $FFFE. Sollte der Call dann ordnungsgemäß an die 
Ausgangsposition zurückkehren, hast Du ja noch viel mehr Speicher. 
Glückwunsch :D

Sobald der Adresszähler überdreht und in Prozessorregister reinschreibt, 
kann das Ganze chaotisch werden.

Da wär's doch mal Zeit den Gegenbeweis zu suchen. SRam mit Nullen 
vollschreiben, dann auf verschiedene Zellen ab $0500 bis $084F ein $FF 
und im SRam auf die Suche danach gehen.

[Simon G. (sigro)]

ldi  r30,  0x00
ldi  r31,  0x01
ldi  r18,  0x00
ldi  r16,  0x05
loop1:
st   z+,    r18
cpse r31,   r16
jmp loop1

; Initialisierung des Speichers auf 0

ldi  r30,  0x01
ldi  r31,  0x05    ; Start bei 0x500
ldi  r18,  0x55
loop:
call zufallszahl
mov r16,  r26
st   z,    r16
sts 0x100, r18
ld   r17,  z
adiw r30,  1
cpse r16,  r17
jmp end
jmp  loop
end:
jmp end

Also bei diesem Programm ist am Ende in der Speicherzelle 0x100 der Wert 
0x54 und bei 0x4FF steht 0x0D.
Der Z Pointer steht bei 0x081C

[Purzel H. (hacky)]

Interessant waere nun, ob der der Speicher, der zuviel ist allenfalls 
sogar am Wachsen ist...
Dann koennte man einen Kompressor schreiben, der exponentiell mehr Daten 
reinkriegt.

[Osche R. (Gast)]

Simon G. schrieb:

> Es sieht für mich so aus, als hätte der AVR einen größeren Speicher als
> im Datenblatt vermerkt.

Oft ist auf dem Die der Speicher des größten Typen aus der Familie 
vorhanden (das ist vermutlich der ATmega32) und es wird nur der Teil 
getestet, den Du auch bezahlt hast.

Ans RAM kommt man immer dran (auch wenn die Funktion nicht garantiert 
ist), das Flash ist manchmal im Bootloader gesperrt.

[Simon G. (sigro)]

om pf schrieb:
> Simon G. schrieb:
>
>> Es sieht für mich so aus, als hätte der AVR einen größeren Speicher als
>> im Datenblatt vermerkt.
>
> Oft ist auf dem Die der Speicher des größten Typen aus der Familie
> vorhanden (das ist vermutlich der ATmega32) und es wird nur der Teil
> getestet, den Du auch bezahlt hast.
>
> Ans RAM kommt man immer dran (auch wenn die Funktion nicht garantiert
> ist), das Flash ist manchmal im Bootloader gesperrt.

Das "Problem" taucht auch bei einem Tiny13 auf. Meiner Meinung nach gibt 
es da keinen Typ mit mehr Speicher.

[Jörg W. (dl8dtl) (Moderator)]

om pf schrieb:
> Oft ist auf dem Die der Speicher des größten Typen aus der Familie
> vorhanden (das ist vermutlich der ATmega32) und es wird nur der Teil
> getestet, den Du auch bezahlt hast.

Das würde ich bei den Stückzahlen, in denen der ATmega16 verkauft
wird, nicht erwarten, dass es sich nur um runterskalierte Dies
handelt.

> Ans RAM kommt man immer dran

Eine sehr gewagte Aussage.  Warum sollten die Entwickler nicht auch
die paar Gatter spendieren, um den datenblattmäßigen Adressraum
des angedachten Bauelementes dann tatsächlich zu emulieren?

Nein, des Rätsels Lösung wurde ja schon genannt: die oberen
Adressbits werden einfach ignoriert.

Simon G. schrieb:
> Habe jetzt folgendes Programm benutzt, mit dem Ergebnis, daß das
> Programm bei 0x0850 abbricht.

Wenn das Programm korrekt ist, sollte es nach 0x085F abbrechen,
denn der SRAM eines ATmega16 beginnt bei 0x60.  Die Adresse 0x0860
greift dann also wieder die gleiche Speicherstelle zu wie 0x60.

[spess53 (Gast)]

Hi

>Das würde ich bei den Stückzahlen, in denen der ATmega16 verkauft
>wird, nicht erwarten, dass es sich nur um runterskalierte Dies
>handelt.

Es ist ein ATMega16M1.

MfG Spess

[Jörg W. (dl8dtl) (Moderator)]

spess53 schrieb:
> Es ist ein ATMega16M1.

OK, missgelesen.  Dann stimmt natürlich auch das mit dem RAM ab 0x60
nicht.

Memory wraparound ist trotzdem normal.  Sollte man sich übrigens
problemlos beim Debuggen über JTAG ansehen können (natürlich nur,
sofern einen die GUI nicht daran hindert, weil sie ja "weiß", dass
der RAM an dieser Stelle zu Ende ist).

Anderer Vorschlag: den gesamten Bereich von 0x100 bis 0xffff mit
0 füllen.  Anschließend ab 0x100 "Hello, world!" reinschreiben und
danach suchen, an welcher Stelle im RAM man überall das "Hello,
world!" wiederfinden kann.

[MWS (Gast)]

Jörg Wunsch schrieb:
> Anderer Vorschlag: den gesamten Bereich von 0x100 bis 0xffff mit
> 0 füllen.  Anschließend ab 0x100 "Hello, world!" reinschreiben und
> danach suchen, an welcher Stelle im RAM man überall das "Hello,
> world!" wiederfinden kann.

So etwas hatte ich bereits vorgeschlagen, wurde aber ignoriert, genauso 
wie die Frage wo er denn den Stack Pointer initialisiert, wenn er Calls 
verwendet.

[Simon G. (sigro)]

Jörg Wunsch schrieb:
> Nein, des Rätsels Lösung wurde ja schon genannt: die oberen
> Adressbits werden einfach ignoriert.
Aber mehr als Erwartet

ldi  r30,  0x00
ldi  r31,  0x01
ldi  r18,  0x00
ldi  r16,  0x05
loop1:
st   z+,    r18
cpse r31,   r16
jmp loop1
; initialisierung auf 0

ldi  r30,  0x00
ldi  r31,  0x05
ldi  r18,  0x55
ldi  r16,  0x08 ; Normaler Speicher am Ende mit 0x00 gefüllt
; ldi  r16,  0x09 ; Normaler Speicher am Ende mit 0x55 gefüllt
loop2:
st   z+,    r18
cpse r31,   r16
jmp loop2
; initialisierung auf 0x55

Jörg Wunsch schrieb:
> Memory wraparound ist trotzdem normal.  Sollte man sich übrigens
> problemlos beim Debuggen über JTAG ansehen können (natürlich nur,
> sofern einen die GUI nicht daran hindert, weil sie ja "weiß", dass
> der RAM an dieser Stelle zu Ende ist).
Ja, leider kann ich mir nicht mehr Speicher anzeigen lassen als der Typ 
haben sollte.
Bei Auswahl des ATmega32M1 läßt das AVR Studio das Debuggen nicht zu.

[Jörg W. (dl8dtl) (Moderator)]

MWS schrieb:
> ..., genauso
> wie die Frage wo er denn den Stack Pointer initialisiert, wenn er Calls
> verwendet.

Muss man bei modernen AVRs nicht, der SP steht initial auf dem Ende
des internen SRAMs.  Allerdings sollte man natürlich in einem
Testprogramm tunlichst CALLs vermeiden, denn es hat ja keinen Sinn,
sich den Stack zu überschreiben mit einem Testmuster.

Simon G. schrieb:
> Ja, leider kann ich mir nicht mehr Speicher anzeigen lassen als der Typ
> haben sollte.

Nicht-Klicki-Debugger benutzen.  Oder eben anderes Testprogramm, s. o.

Ich habe deinen Controller leider nicht zur Hand, sonst hätte ich
ihn mal schnell in einen STK<irgendwas> gesteckt und mit dem Debugger
draufgeguckt.

[Simon G. (sigro)]

> Muss man bei modernen AVRs nicht, der SP steht initial auf dem Ende
> des internen SRAMs.  Allerdings sollte man natürlich in einem
> Testprogramm tunlichst CALLs vermeiden, denn es hat ja keinen Sinn,
> sich den Stack zu überschreiben mit einem Testmuster.

Der Stackpointer wurde erst mit der Einführung der Zufallszahl benutzt, 
davor kab es keine Calls.

Habe Jetzt auch den Call bei der Version mit der Zufallszahl entfernt, 
immer noch das gleiche Ergebnis.

> Ich habe deinen Controller leider nicht zur Hand, sonst hätte ich
> ihn mal schnell in einen STK<irgendwas> gesteckt und mit dem Debugger
> draufgeguckt.
Danke, die Frage ist ja auch, ob sich dieses Phänomen bei anderen Typen 
zeigt.

[MWS (Gast)]

Jörg Wunsch schrieb:
> Muss man bei modernen AVRs nicht, der SP steht initial auf dem Ende
> des internen SRAMs.

Nun, dann lade Dir doch mal das Datenblatt von Atmel und schau Dir auf 
Seite 15 die Werte von Initial Value an, die stehen auf $0000.

http://www.atmel.com/Images/doc8209.pdf

Kann natürlich sein, dass das DB 'nen Fehler hat und die Initialisierung 
tatsächlich auf RAMEND stattfindet. Dann werd' ich in Zukunft nicht mehr 
in's DB schauen, sondern Dich fragen ;D

[Simon G. (sigro)]

MWS schrieb:
> Jörg Wunsch schrieb:
>> Muss man bei modernen AVRs nicht, der SP steht initial auf dem Ende
>> des internen SRAMs.
>
> Nun, dann lade Dir doch mal das Datenblatt von Atmel und schau Dir auf
> Seite 15 die Werte von Initial Value an, die stehen auf $0000.
>
> http://www.atmel.com/Images/doc8209.pdf
>
> Kann natürlich sein, dass das DB 'nen Fehler hat und die Initialisierung
> tatsächlich auf RAMEND stattfindet. Dann werd' ich in Zukunft nicht mehr
> in's DB schauen, sondern Dich fragen ;D

Das AVR Studio zeigt nach einem Reset an, daß der Stack Pointer auf 
0x04FF(RAM Ende) zeigt, ohne das ich ihn initialisiert habe.

[Alex W. (Gast)]

Das kann aber auch ein Bug in AVRStudio sein!

[MWS (Gast)]

Simon G. schrieb:
> Das AVR Studio zeigt nach einem Reset an, daß der Stack Pointer auf
> 0x04FF(RAM Ende) zeigt, ohne das ich ihn initialisiert habe.

AVR-Studio zeigt mir manchmal beim Debuggen einen *JMP $0000* an, obwohl 
da keiner ist. Das ist hier sicher nicht das Maß der Dinge.

Normalerweise ist schon das DB das Entscheidende, von etwas anderem 
auszugehen kannst Du Dir u.U. leisten, wenn Du es in der aktuellen HW 
selbst überprüft hast. Und das würd' ich bezweifeln.

[Simon G. (sigro)]

Alex W. schrieb:
> Das kann aber auch ein Bug in AVRStudio sein!

Ich debugge direkt auf dem Controller. Angebunden ist dieser über das 
debugWIRE On-chip Debug System. Trotzdem kann ich natürlich einen Bug 
nicht 100%ig ausschließen.

[Peter D. (peda)]

MWS schrieb:
> Kann natürlich sein, dass das DB 'nen Fehler hat und die Initialisierung
> tatsächlich auf RAMEND stattfindet.

Wird ein Copy&Paste-Fehler sein.
Alle AVR ab ATtiny13/ATmega48 setzen den Stack selber richtig. Warum 
sollte ein neuer Typ wieder einen Rückschritt machen?


Peter

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

Peter Dannegger schrieb:

>> Kann natürlich sein, dass das DB 'nen Fehler hat und die Initialisierung
>> tatsächlich auf RAMEND stattfindet.
>
> Wird ein Copy&Paste-Fehler sein.

Steht in DB völlig richtig drin. In der aktuellen Version.
http://www.atmel.com/Images/doc7647.pdf

[Simon G. (sigro)]

Anbei nochmal das Programm.
Ich würde mich sehr freuen wenn ihr noch Verbesserungen einbaut, das 
Programm auf anderen Typen testet und wir eine abschließende Antwort 
finden.

[Peter D. (peda)]

A. K. schrieb:
> Steht in DB völlig richtig drin. In der aktuellen Version.
> http://www.atmel.com/Images/doc7647.pdf

Das ist aber das Automotive Datenblatt.


Peter

[MWS (Gast)]

A. K. schrieb:
> Steht in DB völlig richtig drin. In der aktuellen Version.
> http://www.atmel.com/Images/doc7647.pdf

Das von mir verlinkte DB kam von der Atmel Produktseite:
http://www.atmel.com/devices/atmega16m1.aspx?tab=documents
Also von dort, wo man danach suchen würde.

[Jörg W. (dl8dtl) (Moderator)]

Peter Dannegger schrieb:
> Das ist aber das Automotive Datenblatt.

Allerdings gibt es keinen vernünftigen Grund, warum die non-
automotive-Typen ihre Register anders belegen sollten. ;-)  Die
automotive-Teile haben halt nur eine bessere (aufwändigere)
Qualifizierung hinter sich.

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

Jörg Wunsch schrieb:

> automotive-Teile haben halt nur eine bessere (aufwändigere)
> Qualifizierung hinter sich.

Offenbar nicht nur die Chips, sondern auch deren Datenblätter. ;-)

[MWS (Gast)]

Simon G. schrieb:
> Angebunden ist dieser über das
> debugWIRE On-chip Debug System.

Du müsstest sicherstellen können, dass das Messmittel nicht die Messung 
verfälscht. Aufgrund des per Debugwire aufgesetzten Protokolls kannst Du 
das m.E. nicht.

Dein Programm muss ohne Debugwire funktionieren. Dazu sollte es in der 
Lage sein einen Adressüberlauf zu erkennen und selbst kein SRam zu 
verwenden, Stichwort Stack. Gleichzeitig müsstest Du darauf achten, dass 
die Prozessorregister beim Überlauf selbst nicht überschrieben werden 
und letzten Endes Dein Ergebnis Ad Absurdum führen.
Denn genau das kann im Moment passieren, kann verhindert werden indem Du 
z.B. R0 auf 'nen definierten Wert setzt und laufend prüfst. Genauso 
wenig braucht's Zufallszahlen, es reicht einmal auf $00 und auf $FF 
zusetzen und jeweils das Ergebnis zu testen. Am Ende des Tests kannst Du 
dann im einfachsten Fall die ermittelte Adresse auf 2 Ports ausgeben.

[MWS (Gast)]

Jörg Wunsch schrieb:
> Allerdings gibt es keinen vernünftigen Grund, warum die non-
> automotive-Typen ihre Register anders belegen sollten. ;-)

Ist lustig, wie sich da rumgewunden wird.

Normalerweise bekommt jeder unschuldige Frager den Rat, er möge doch 
in's Datenblatt sehen. Und wenn's dann jemand vorher tatsächlich macht 
und sich das nicht mit der eigenen Ansicht deckt, dann werden Annahmen 
getroffen. Diese Sorte Kreativität ist natürlich nur den Profis erlaubt 
:D

Unabhängig davon, was andere, ältere oder neuere µC's da jetzt machen 
werden, wäre der Zweifel der sich aus dem DB ergibt, mehr als 
ausreichend dafür den SP explizit zu initialisieren.

Schau' halt mal in AVR GCC nach, ob der glaubt sich den SP-Init sparen 
zu können. Und da Du Jörg, mit allem Respekt, im AVR GCC eine Koryphäe 
bist, solltest Du das am Besten wissen.

[unl34shed (Gast)]

Die Frage, die sich mir stellt ist, ob der "erweiterte" RAM auch die 
Daten hällt. RAM muss ja refreshed werden, vllt. wurde da ja was raus 
genommen.
Und ob Adresse 0x500 nicht doch auf 0x100 schreibt.

Warum baust du dein Code nicht so um, dass er über UART funktioniert?

Kannst dann auch mehrere Modi einbauen, Alles mit 0 füllen, alles mit FF 
füllen, Zahlenfolge 0 - X, ...
Wäre nur ne kleine Abfrage am Anfang des Programms nötig. (natürlich 
über polling, keine Interrupts!)

Dann schreibst du den RAM voll und liest ihn wieder aus.

Das Ausgelesene dann über den UART wieder zurück an den PC und zB.  in 
Excel gepackt.


Vor allem mit der Zahlenfolge könntest du dann feststellen, ob Adresse 
0x500 nicht doch auf 0x100 schreibt (natürlich nur, wenn du es nicht so 
füllst, dass es sich bei 0x500 wiederholt).

Um die Datenhaltung zu testen, einfach mal 5min Warten und wieder 
auslesen.
Entsprechen am Ende des Programms dann UART pollen für weitere Befehle

[Jörg W. (dl8dtl) (Moderator)]

MWS schrieb:
> Normalerweise bekommt jeder unschuldige Frager den Rat, er möge doch
> in's Datenblatt sehen.

Ist ja auch völlig korrekt, aber es ist eben (leider) auch nicht
der erste Bug in einem Datenblatt, der einem so über den Weg
läuft.

Sicher, in produktivem Code würde ich mich auf nichts verlassen, was
nicht im Datenblatt steht, aber hier geht's um ein simples
Testprogramm, und der Anwender hat sich empirisch mit dem Debugger
versichert, dass der initiale Inhalt des Stackpointers seinen
Erwartungen entspricht.  Die Chance, dass man per debugWIRE nur durch
puren Zufall aus dem SP ein 0x4FF statt einer tatsächlich vorhandenen
0 ausliest ist drastisch geringer als die, dass das Datenblatt
einfach mal nur (infolge von copy, paste & die) falsch liegt.

Aber das ist nun komplett abschweifend und bringt uns in der
eigentlichen Frage nicht weiter.  Entweder müsste Simon also das
Programm mal ändern und nachschauen, an welchen Stellen der wrap
around passiert, oder er müsste jemandem, der mit was anderem als
AVR Studio debuggen kann, einen IC leihen.

[spess53 (Gast)]

Hi

>RAM muss ja refreshed werden, vllt. wurde da ja was raus
>genommen.

AVRs haben SRAM (Static Ram). DRAM (Dynamic Ram) brauchen einen Refresh.

MfG Spess

[Jörg W. (dl8dtl) (Moderator)]

unl34shed schrieb:
> RAM muss ja refreshed werden

Nein.  Das ist doch kein dRAM.  Solange das Zeug Spannung anliegen
hat, hält er die Daten.  [Edit: spess war schneller]

[Peter D. (peda)]

Probier mal folgendes:

Fülle den SRAM mit 0x55.
Fülle die Register mit 0xAA.
Machen einen kompletten Dump über 64kB und sende ihn als Hex über die 
UART zum PC.
Dann sollte man sehen, ob Adreßbits ignoriert werden.


Peter

[Jörg W. (dl8dtl) (Moderator)]

Simon G. schrieb:
> Ich würde mich sehr freuen wenn ihr noch Verbesserungen einbaut, das
> Programm auf anderen Typen testet und wir eine abschließende Antwort
> finden.

Programm auf einem ATmega16:

start:  ldi     r30, 0x60
        clr     r31
        clr     r1
1:      st      Z+, r1
        mov     r24, r30
        or      r25, r31
        brne    1b
        ldi     r24, 'H'
        sts     0x0060, r24
        ldi     r24, 'i'
        sts     0x0061, r24
2:      rjmp    2b

Hier das Ergebnis im GDB:

(gdb) x/256bx 0x800000
0x800000:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800008:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800010:       0x00    0x00    0x00    0x00    0x00    0x00    0x19    0x00
0x800018:       0x69    0x00    0x00    0x00    0x00    0x00    0x61    0x00
0x800020:       0x00    0xf8    0xfe    0xff    0x00    0x00    0x00    0x00
0x800028:       0x00    0x00    0x00    0x20    0x00    0x00    0x00    0x00
0x800030:       0xff    0x00    0x00    0xc3    0x00    0x00    0xff    0x00
0x800038:       0x00    0xff    0x00    0x00    0x00    0x00    0x00    0x00
0x800040:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800048:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800050:       0x00    0x00    0x00    0x00    0x12    0x00    0x00    0x00
0x800058:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x02
0x800060:       0x48    0x69    0x00    0x00    0x00    0x00    0x00    0x00
0x800068:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800070:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800078:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800080:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800088:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800090:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800098:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000a0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000a8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000b0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000b8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000c0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000c8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000d0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000d8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000e0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000e8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000f0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8000f8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb) x/256bx
0x800100:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800108:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800110:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800118:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800120:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800128:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800130:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800138:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800140:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800148:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800150:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800158:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800160:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800168:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800170:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800178:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800180:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800188:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800190:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800198:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001a0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001a8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001b0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001b8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001c0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001c8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001d0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001d8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001e0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001e8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001f0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8001f8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb) x/256bx
0x800200:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800208:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800210:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800218:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800220:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800228:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800230:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800238:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800240:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800248:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800250:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800258:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800260:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800268:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800270:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800278:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800280:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800288:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800290:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800298:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002a0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002a8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002b0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002b8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002c0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002c8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002d0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002d8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002e0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002e8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002f0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8002f8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb) x/256bx
0x800300:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800308:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800310:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800318:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800320:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800328:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800330:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800338:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800340:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800348:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800350:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800358:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800360:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800368:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800370:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800378:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800380:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800388:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800390:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800398:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003a0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003a8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003b0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003b8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003c0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003c8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003d0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003d8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003e0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003e8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003f0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8003f8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb) x/256bx
0x800400:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800408:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800410:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800418:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800420:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800428:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800430:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800438:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800440:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800448:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800450:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800458:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800460:       0x48    0x69    0x00    0x00    0x00    0x00    0x00    0x00
0x800468:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800470:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800478:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800480:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800488:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800490:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800498:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004a0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004a8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004b0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004b8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004c0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004c8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004d0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004d8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004e0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004e8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004f0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8004f8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb) x/256bx
0x800500:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800508:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800510:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800518:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800520:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800528:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800530:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800538:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800540:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800548:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800550:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800558:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800560:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800568:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800570:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800578:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800580:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800588:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800590:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800598:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005a0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005a8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005b0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005b8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005c0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005c8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005d0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005d8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005e0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005e8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005f0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8005f8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb) x/256bx
0x800600:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800608:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800610:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800618:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800620:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800628:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800630:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800638:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800640:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800648:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800650:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800658:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800660:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800668:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800670:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800678:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800680:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800688:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800690:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800698:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006a0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006a8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006b0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006b8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006c0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006c8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006d0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006d8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006e0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006e8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006f0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8006f8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb) x/256bx
0x800700:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800708:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800710:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800718:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800720:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800728:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800730:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800738:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800740:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800748:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800750:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800758:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800760:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800768:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800770:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800778:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800780:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800788:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800790:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800798:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007a0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007a8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007b0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007b8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007c0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007c8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007d0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007d8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007e0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007e8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007f0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8007f8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb) x/256bx
0x800800:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800808:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800810:       0x00    0x00    0x00    0x00    0x00    0x00    0x19    0x00
0x800818:       0x69    0x00    0x00    0x00    0x00    0x00    0x1e    0x08
0x800820:       0x00    0xf8    0xfe    0xff    0x00    0x00    0x00    0x00
0x800828:       0x00    0x00    0x00    0x20    0x00    0x00    0x00    0x66
0x800830:       0xff    0x00    0x00    0xc3    0x00    0x00    0xff    0x00
0x800838:       0x00    0xff    0x00    0x00    0x00    0x00    0x00    0x00
0x800840:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800848:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800850:       0x00    0x00    0x00    0x00    0x12    0x00    0x00    0x00
0x800858:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x02
0x800860:       0x48    0x69    0x00    0x00    0x00    0x00    0x00    0x00
0x800868:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800870:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800878:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800880:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800888:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800890:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x800898:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008a0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008a8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008b0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008b8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008c0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008c8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008d0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008d8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008e0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008e8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008f0:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x8008f8:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00

Ich denke, den Rest kann ich mir sparen:

. der RAM wird hinter RAMEND im Adressraum repliziert, das "Hi" von
  Adresse 0x60 sieht man auf 0x460 erneut
. die oberen Adressbits werden gar nicht dekodiert, auf 0x800 findet
  man den Mirror der CPU-Register von Adresse 0 wieder, auf 0x20 sieht
  man wieder die IO-Register von 0x20

(Der Offset 0x800000 zeigt innerhalb des GDB an, dass man den SRAM-
Bereich zugreift und nicht den Flash.  Da es sich um einen ATmega16
handelt, sind SPL und SPH natürlich initial gleich 0 und nicht gleich
RAMEND.)

[MWS (Gast)]

Jörg Wunsch schrieb:
> Die Chance, dass man per debugWIRE nur durch
> puren Zufall aus dem SP ein 0x4FF statt einer tatsächlich vorhandenen
> 0 ausliest ist drastisch geringer als die, dass das Datenblatt
> einfach mal nur (infolge von copy, paste & die) falsch liegt.

Wegen 4 Zeilen Code den er spart, irgendwelchen Annahmen?
Macht man doch nicht, das kannst Du auch nicht für Testcode 
rechtfertigen.

So hätt' ich mir besagten Test vorgestellt:

.include "m16M1def.inc"
LDI    R16,  low(RAMEND)
LDI    R17,  high(RAMEND)
OUT    SPH,  R17
OUT    SPL,  R16
MOVW   R30,  R16
ADIW   R30,  1
LDI    R16,  $AA
MOV    R0,   R16
LDI    R16,  $00
LDI    R17,  $FF
Nextcell:
ST     Z,    R16
NOP
NOP
NOP
TST    R0
BREQ   Ovrtrn
LD     R18,  Z
TST    R18
BRNE   Outofsram
ST     Z,    R17
NOP
NOP
NOP
LD     R18,  Z+
CPI    R18,  $FF
BRNE   Outofsram
RJMP   Nextcell
Outofsram:
Ovrtrn:
LDI    R18,  $FF
OUT    DDRB, R18
LDI    R18,  $FF
OUT    DDRC, R18
OUT    PORTB,R30
OUT    PORTC,R31
Testend:
RJMP   Testend

[Simon G. (sigro)]

Vielen Dank euch allen!

[Simon G. (sigro)]

Tut mir Leid, aber ich muß das Thema noch einmal öffnen.
Ich habe jetzt folgendes Testprogramm:

.include "m16M1def.inc"

; Fülle den Speicher
ldi r30, 0x00
ldi r31, 0x01
ldi r24, 0x00
ldi r25, 0x00

loop2:
st  z+, r24
st  z+, r25
ADIW r24:r25, 1
ldi r18, 0x08
cpse r31, r18
jmp loop2



;LINBRR = (((F_CPU * 10 / PRESCALE / BAUD) + 5) / 10) - 1;
LDI    r24,    0x33
LDI    r25,    0x00
STS    LINBRRH,  r25
STS    LINBRRL,  r24

;LINBTR = BV(LDISR) | PRESCALE;
LDI    r24,    0x90
STS    LINBTR,    r24

;LINCR = BV(LENA) | BV(LCMD2) | BV(LCMD1) | BV(LCMD0);
LDI    r24,    0x0F
STS    LINCR,    r24


ldi    r30,    0x00
ldi    r31,    0x01

;übertrage Low Byte Z Pointer
loopZL:
LDS R18, LINSIR
SBRC R18, 4
RJMP loopZL
;LDI r24, 0x55
STS LINDAT, r30

;übertrage High Byte Z Pointer
loopZH:
LDS R18, LINSIR
SBRC R18, 4
RJMP loopZH
;LDI r24, 0x55
STS LINDAT, r31

;übertrage  L Wert
loopL:
LDS R18, LINSIR
SBRC R18, 4
RJMP loopL
LD r24, z+
STS LINDAT, r24

;übertrage L
loopL:
LDS R18, LINSIR
SBRC R18, 4
RJMP loopL
LD r24, z+
STS LINDAT, r24
ldi r18, 0x08
cpse r31, r18
RJMP loopZL
end:
RJMP end

Der Output ist in der angehängten Datei.
Hat aber im Prinzip nur folgenden Inhalt:
z    | *(z)
00 01 00 00
02 01 01 00
04 01 02 00
06 01 03 00
.
.
.
F6 07 7B 03
F8 07 7C 03
FA 07 7D 03
FC 07 7E 03
FE 07 7F 03

Wenn Ich das Programm über 0x800 hinaus laufen lasse (füllen und 
auslesen) scheint er bei 0x800 das Register 0 zu beschreiben.

[Simon G. (sigro)]

Hier noch einmal der Output als ASCII

[MWS (Gast)]

Der Code kann aufgrund doppelter Label nicht funktionieren. Wie schafft 
man das beim Copy/Paste ?

;übertrage  L Wert
loopL:
LDS R18, LINSIR
SBRC R18, 4
RJMP loopL
LD r24, z+
STS LINDAT, r24

;übertrage L
loopL:
LDS R18, LINSIR
SBRC R18, 4
RJMP loopL
LD r24, z+
STS LINDAT, r24
ldi r18, 0x08
cpse r31, r18
RJMP loopZL

[Simon G. (sigro)]

Ups, habe noch im Post die Label umbenannt, dabei muß sich der Fehler 
eingeschlichen haben.

;übertrage  L Wert
loopL:
LDS R18, LINSIR
SBRC R18, 4
RJMP loopL
LD r24, z+
STS LINDAT, r24

;übertrage H
loopH:
LDS R18, LINSIR
SBRC R18, 4
RJMP loopH
LD r24, z+
STS LINDAT, r24

[Ernst Haft (Gast)]

So ein lächerlicher Blödsinn.
Ist mehr Speicher vorhanden, als der Hersteller angibt, dann ist das 
Murks.
Atmega ist Profi.

Eigentlich ist dieses Thema so Traurig und nicht mehr lachhaft.

Gruß
Ernst

[MWS (Gast)]

Von der Formatierung verwirrend. Unter der Voraussetzung dass dieses Log 
original vom hier besprochenen ATM16M1 kommt, so fällt mir für Zellen 
mit Zählerinhalt >= 00 02 keine andere Erklärung ein, als dass 
tatsächlich über den normalen Bereich hinausgehende Zellen existieren.

Der erste Bruch erscheint bei Zelle absolut $0812, aufs SRam bezogen 
$712, dez 1810.

> 0E 08 87 03
> 10 08 88 03
> 12 08 02 03 <---
> 14 08 8A 03

Ganz von der Hand zu weisen wäre die Vermutung nicht, dass bei der 
Produktion eine gewisse Menge Ausschuss entsteht und Bausteine mit 
Defekten im oberen Adressbereich ähnlich dem Speedgrade bei 
PC-Prozessoren zu einem bestimmten Typ der jeweils niedrigeren Serie 
gelabelt und damit recycelt werden. Da wäre ein Test noch interessant, 
wie viel der Flash fasst.

Außer dem akademischen Wissen darum, wirst Du allerdings keinen 
praktisch sinnvollen Nutzen daraus ziehen können, denn Du kannst außer 
den zugesicherten 1024 Byte SRam nichts weiter als garantiert annehmen.
Und Du solltest es unabhängig bestätigen lassen, wenn Dir weiter etwas 
daran liegt.

[Simon G. (sigro)]

MWS schrieb:
>
> Der erste Bruch erscheint bei Zelle absolut $0812, aufs SRam bezogen
> $712, dez 1810.
Deutet auf eine defekte Speicherzelle hin.
>
> Ganz von der Hand zu weisen wäre die Vermutung nicht, dass bei der
> Produktion eine gewisse Menge Ausschuss entsteht und Bausteine mit
> Defekten im oberen Adressbereich ähnlich dem Speedgrade bei
> PC-Prozessoren zu einem bestimmten Typ der jeweils niedrigeren Serie
> gelabelt und damit recycelt werden. Da wäre ein Test noch interessant,
> wie viel der Flash fasst.

klingt logisch.

> Außer dem akademischen Wissen darum, wirst Du allerdings keinen
> praktisch sinnvollen Nutzen daraus ziehen können, denn Du kannst außer
> den zugesicherten 1024 Byte SRam nichts weiter als garantiert annehmen.
> Und Du solltest es unabhängig bestätigen lassen, wenn Dir weiter etwas
> daran liegt.
Mir ging es nur darum eine Erklärung zu finden.
Atmel wollte dazu keine klare Ausage machen.
Wenn Du Interesse hast, kann ich Dir gerne einen ATMega16M1 zusenden, 
ist aber im QFN Gehäuse.

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

MWS schrieb:

> Ganz von der Hand zu weisen wäre die Vermutung nicht, dass bei der
> Produktion eine gewisse Menge Ausschuss entsteht und Bausteine mit
> Defekten im oberen Adressbereich ähnlich dem Speedgrade bei
> PC-Prozessoren zu einem bestimmten Typ der jeweils niedrigeren Serie
> gelabelt und damit recycelt werden.

Dagegen spricht die Replikation des Adressraums ab 0x800, d.h. die 
unvollständige Dekodierung der Adressbits. Ein Chip, der für mindestens 
doppelt so viel RAM gebaut ist, als er offiziell liefert, würde die 
Adressen entsprechend weiter ausdekodieren.  Bei der nächsten üblichen 
Stufe von 2K RAM landet man jenseits von 0x800. Es ergibt keinen Sinn, 
diese Ausdekodierung zusammen mit dem Rebinning umzuschalten.

In der Vergangenheit wurde solches Recycling bei Atmel m.W. nicht 
durchgeführt, auch die 5V/<5V Versionen ergaben sich nicht durch 
Ausfälle, sondern durch unterschiedliche Testprofile. Der Aufwand kann 
bei derart niedrigen reinen Fabrikationskosten höher sein als der 
Gewinn. Die Herstellung von PC-Prozessoren ist da kein Modell, die sind 
immens viel teurer in der Herstellung.

[MWS (Gast)]

A. K. schrieb:
> Dagegen spricht die Replikation des Adressraums ab 0x800, d.h. die
> unvollständige Dekodierung der Adressbits.

Das war mir schon klar, genauso wie die unterschiedliche Device-ID der 
Bausteine.

> Ein Chip, der für mindestens
> doppelt so viel RAM gebaut ist, als er offiziell liefert, würde die
> Adressen entsprechend weiter ausdekodieren.

Es ist für Atmel kein Problem, den Chip mit einer Device-ID des als 
schließlich gut geprüften Typs auszustatten, genauso wäre es möglich die 
Adressdekoder passend zu konfigurieren.

Dagegen wäre es ein zusätzlicher Aufwand, exakt bei $04FF den Hahn 
zuzudrehen, da dies eben nicht so einfach durch Abschalten des 12. 
Adressbits geschehen kann.

> Der Aufwand kann bei derart niedrigen reinen Fabrikationskosten höher
> sein als der Gewinn.

Kann, wissen wir aber nicht. Sollten die Chips zum Schluss grundsätzlich 
einer Funktionsprüfung unterzogen werden, dürfte sich der Aufwand ein 
paar Fuses zu schreiben aber in Grenzen halten.

> Die Herstellung von PC-Prozessoren ist da kein Modell, die sind
> immens viel teurer in der Herstellung.

Das war nur dazu gedacht das grundlegende Geschäftsmodell zu 
beschreiben, das aber im Prinzip das Gleiche ist:

Erhöhe den Ertrag durch nachträgliches Aussortieren und Einordnung in 
verschiedene Leistungs- oder Qualitätsklassen.

Allerdings gibt's auch noch 'ne andere Erklärung: der Produktionsprozess 
ist einfach komplett identisch für die 16/32/64er und zum Schluss wird 
einfach der Typ draus gemacht den man braucht, indem man bestimmte 
Adressbits abschaltet und die Device-ID passend schreibt.

[MWS (Gast)]

Simon G. schrieb:
> Mir ging es nur darum eine Erklärung zu finden.
> Atmel wollte dazu keine klare Ausage machen.

Das verstehe ich, denn einer der zwei von mir angeführten Gründe wird es 
sein. Egal welcher es dann tatsächlich ist, würde eine offizielle 
Erklärung für Atmel nur einen Nachteil bedeuten.

Simon G. schrieb:
> Wenn Du Interesse hast, kann ich Dir gerne einen ATMega16M1 zusenden,
> ist aber im QFN Gehäuse.

Danke für das Angebot, aber ein Test sollte besser von jemand gemacht 
werden, der Deine Entdeckung bezweifelt. Dazu gehöre ich mittlerweile 
nicht mehr, lies Dir meinen vorherigen Beitrag durch.

[Osche R. (Gast)]

Üblicherweise besteht eine Chipfamilie aus wenigen unterschiedlichen 
"umbrella devices". Aus denen werden die verschiedenen Derivate 
abgeleitet. Nicht benötigte Funktionen werden nicht getestet bzw nicht 
angeschlossen. Die device ID und der passcode stehen in einem vom User 
nicht löschbaren Bereich des Programm-Flash und werden nach bestandenem 
Wafertest eingeschrieben. So kann man z.B. beim V850 16 Derivate mit 3 
Dies abbilden.

Testausfälle als kleineres Derivat weiterzuverwenden ist unüblich. 
Trotzdem kann es natürlich sein, dass bei kleineren Derivaten die 
undokumentierten Bereiche nicht funktionieren, sie wurden schliesslich 
nicht getestet.


Atmel kenne ich nicht näher, aber vom Prinzip her wird es da ähnlich 
laufen.

[Jörg W. (dl8dtl) (Moderator)]

Simon G. schrieb:
> Wenn Du Interesse hast, kann ich Dir gerne einen ATMega16M1 zusenden,
> ist aber im QFN Gehäuse.

Das Angebot würde ich gern annehmen, ich würde da gern mal mit dem
Debugger draufgucken.  Im Prinzip müsste man das ja sogar noch mit
einem "dead bug"-Design schaffen (nur GND und VCC mitsamt Kerkos
verlöten sowie /RESET für das debugWIRE).  Eine Platine mit einem
Footprint für QFN32, auf die ich ihn mal schnell auflöten könnte,
hab' ich glaub' ich nicht hier.  Oder ich ätze mir eine.

[Simon G. (sigro)]

Jörg Wunsch schrieb:
> Das Angebot würde ich gern annehmen, ich würde da gern mal mit dem
> Debugger draufgucken.  Im Prinzip müsste man das ja sogar noch mit
> einem "dead bug"-Design schaffen (nur GND und VCC mitsamt Kerkos
> verlöten sowie /RESET für das debugWIRE).  Eine Platine mit einem
> Footprint für QFN32, auf die ich ihn mal schnell auflöten könnte,
> hab' ich glaub' ich nicht hier.  Oder ich ätze mir eine.
Habe Dir eine E-mail geschrieben.

[spess53 (Gast)]

Hi

Habt ihr schon mal überlegt, das nicht nur der RAM sonder auch die 
IO-Register und auch r0...r31 mit Z angesprochen werden können? Also 
auch davon Spiegelregister möglich sind.

MfG Spess

[Jacobi (Gast)]

Ernst Haft schrieb:
> Autor:
>
>         Ernst Haft (Gast)
>
>
>
>
>
>
>
>
>       Datum: 02.04.2012 16:34
>
>
>
>
>
>
>
>
>
>
>       So ein lächerlicher Blödsinn.
> Ist mehr Speicher vorhanden, als der Hersteller angibt, dann ist das
> Murks.
> Atmega ist Profi.
>
> Eigentlich ist dieses Thema so Traurig und nicht mehr lachhaft.
>
> Gruß
> Ernst

Hallo Ernst,
ich denke auch, du hast recht.
Es ist Hobbycram.
Das sollte wirklich keiner für ERNST nehmen.
So etwas ist mir bei Atmel noch nie vorgekommen.
Außerdem sollten die erst mal richtig programmieren lernen.
Wenn ich schon Fehler mit Sprungmarken sehe....   (Kinderkram)
Was soll man dann noch erwarten können?
Haben die keinen Testdurchlauf gemacht?
Finden die bestimmt nicht für nötig.
Welche Qualifikation haben diese Menschen dann?

Übrigens, Atmel zahlt jedem eine hohe Prämie für unendeckten Fehler!!!

Warum?  Produktsicherung! Qualitätssicherung!

Aber die Dummheit der User werden nicht berücksichtigt.

Profis erstellen einen fundierten Bericht mit entsprechenden 
Assemblercode an den Hersteller, und der Hersteller gibt seine Stellung 
zu dem Bericht.

Hat mir schon Erfolg für meinen Geldbeutel gebracht. Waren leider nur 
unwesendliche Sachen in der Rechtschreibung der Unterlagen. Aber 
immerhin sind dort freundliche Menschen, die mit mir reden wollen, wenn 
ich das möchte. Do it.

Gruß
Jacobi

[karl (Gast)]

spess53 schrieb:
> Hi
>
> Habt ihr schon mal überlegt, das nicht nur der RAM sonder auch die
> IO-Register und auch r0...r31 mit Z angesprochen werden können? Also
> auch davon Spiegelregister möglich sind.
>
> MfG Spess



Hi Spess,

genau, damit kommen die doch nicht zurecht.
Programmieren sollte man auch noch können, ist aber nebensächlich.

Mit freundlichen Güßen
Karl

PS: Das mit Ernst und dem Zitat ist Herb. Vielleicht nicht verkehrt.

[MWS (Gast)]

spess53 schrieb:
> Habt ihr schon mal überlegt, das nicht nur der RAM sonder auch die
> IO-Register und auch r0...r31 mit Z angesprochen werden können? Also
> auch davon Spiegelregister möglich sind.

Ja, klar, daraus ergibt sich m.E. diese erste Abweichung:

MWS schrieb:
> Der erste Bruch erscheint bei Zelle absolut $0812, aufs SRam bezogen
> $712, dez 1810.
>
>> 0E 08 87 03
>> 10 08 88 03
>> 12 08 02 03 <---
>> 14 08 8A 03

$0812 ist, wenn man eine eine Adressdekodierung von 11 Bit annimmt, also 
eine Spiegelung ab 2048 = $0800, das Prozessorregister R18. Dies ist das 
niedrigste Prozessorregister, das Simon in seine Code benutzt und damit 
verändert.

[MWS (Gast)]

Jacobi schrieb:
> unwesendliche Sachen in der Rechtschreibung der Unterlagen.

LOL, Du wärst Dein bester Kunde.

[MWS (Gast)]

Simon G. schrieb:
> Hier noch einmal der Output als ASCII

Simon,

kannst Du den Code posten, mit dem dieses Log erzeugt wurde ?

[Simon G. (sigro)]

MWS schrieb:
> kannst Du den Code posten, mit dem dieses Log erzeugt wurde ?

klar, die Datei ist angehängt.

[MWS (Gast)]

Simon G. schrieb:
> klar, die Datei ist angehängt.

Mich wunderte ursprünglich, wie Du in der Log über $0800 hinaus kamst, 
denn da war beim vorherigen Code Schluss, Du hast aber nun auf $0900 
erweitert.

Das hat aber zur Folge, dass Du unvermeidlich, falls wir von einer 
Spiegelung bei $0800 ausgehen, die vom Code selbst verwendeten Register 
beschädigst:

ldi    r30,    0x00
ldi    r31,    0x01
ldi    r24,    0x00
ldi    r25,    0x00
loop2:
st    z+,      r24
st    z+,      r25
ADIW  r24:r25,  1
ldi    r18,    0x09
cpse  r31,    r18
jmp    loop2

Besonders kritisch, weil Du dann in das Z-Register schreibst, worauf 
dann woanders im Speicher weiter geschrieben wird. Hab's mal simuliert.

In der Simulation hat der Code ZL beschädigt, wodurch im nächsten 
Schritt ZL auf $8F stand. Schreibzugriffe gingen damit zwar oberhalb der 
Prozessorregister weiter, wo kein Schaden entstand, aber Du willst ja 
hier einer Ursache auf den Grund gehen und kannst es nicht brauchen, 
wenn der Code sich selbst ein Bein stellt.

Kannst Du aber leicht beheben, bau' bei der Routine für die 
Speichervorbelegung einen Schutz für die unteren Prozessorregister ein, 
sobald die beschrieben werden, brich' ab und gib ZL/ZH aus.

Das kann im Übrigen einen weiteren Beleg für die Spiegelung erst ab 
$0800 liefern. Und wenn's nicht so ist, wirst Du es auch merken. ;-)

[Simon G. (sigro)]

MWS schrieb:
> Mich wunderte ursprünglich, wie Du in der Log über $0800 hinaus kamst,
> denn da war beim vorherigen Code Schluss, Du hast aber nun auf $0900
> erweitert.
Ich habe erst nur bis 0x7FF den Speicher genutzt da ich gemerkt habe, 
daß es ab 0x800 Probleme gibt.
> Besonders kritisch, weil Du dann in das Z-Register schreibst, worauf
> dann woanders im Speicher weiter geschrieben wird. Hab's mal simuliert.
Ich bin mir ziemlich sicher, daß bei 0x800 der Wraparound statt findet 
und die Register beschrieben werden. Wobei ich den Eindruck habe, daß 
das Überschreiben des Z-Pointers keine Auswirkung auf den Ablauf hat.
Ich vermute, daß das daran liegt, daß ich den Autoinkrement-Befehl 
benutze.

[Michael U. (amiga)]

Hallo,

warum erinnert mich das hier so an:

illegale OP-Codes des 6502
illegale OP-Codes des Z80

:-))

Gruß aus Berlin
Michael

[MWS (Gast)]

Simon G. schrieb:
> Ich habe erst nur bis 0x7FF den Speicher genutzt da ich gemerkt habe,
> daß es ab 0x800 Probleme gibt.

Deswegen wollte ich den Code sehen. Dadurch schreibst Du bis $0900:

ldi    r18,    0x09
cpse  r31,    r18
jmp    loop2

> Ich bin mir ziemlich sicher, daß bei 0x800 der Wraparound statt findet
> und die Register beschrieben werden.

Ich halt's auch für wahrscheinlich, denn wenn das früher passiert, würde 
man das im Log an früherer Stelle recht schnell sehen.

> Wobei ich den Eindruck habe, daß
> das Überschreiben des Z-Pointers keine Auswirkung auf den Ablauf hat.

Dein Eindruck trügt Dich. Er hat, soweit ich simulieren konnte, 
zumindest keinen negative Auswirkung auf die Integrität des Ergebnisses, 
aber er hat definitiv Wirkung auf den Ablauf.

Simon G. schrieb:
> Ich vermute, daß das daran liegt, daß ich den Autoinkrement-Befehl
> benutze.

Das fällt Dir nur nicht auf, weil der Inhalt des Logs ab $0812 
durcheinander ist.

Meine Simulation sagt mir, er schreibt zuerst ein $8F in ZL und dann in 
Folge weiter an $xx8F ein $03, auf $xx90 ein ein $90, auf $xx91 ein $03, 
usw.

Schau' Dir mal das Log bei $0890 an, da wirst Du wieder 'ne gewisse 
Regelmäßigkeit für ein paar Bytes feststellen. Da hast Du nämlich in die 
DAC-Register reingeschrieben, $8F ist "reserved", deswegen kannst Du von 
dort nix zurücklesen.

[Osche R. (Gast)]

Michael U. schrieb:

> warum erinnert mich das hier so an:
>
> illegale OP-Codes des 6502
> illegale OP-Codes des Z80

Damit hat das eigentlich relativ wenig zu tun. Wobei die Frage schon 
interessant wäre. Ist bei den ATmegas und PICs jedem Hexwert ein Befehl 
zugeordnet oder gibt es Befehle, die es eigentlich nicht gibt?

Größere Prozessoren haben für sowas eine Trap, d.h. bei illegalen 
Opcodes wird ein Interrupt ausgelöst. So kann man sich eigene Befehle 
basteln.

[Jörg W. (dl8dtl) (Moderator)]

Jörg Wunsch schrieb:
> Das Angebot würde ich gern annehmen, ich würde da gern mal mit dem
> Debugger draufgucken.

OK, ich habe den Chip mittlerweile auf einem kleinen Adapter und
da mit dem Debugger draufgucken können.  Dem Debugger habe ich
"vorsichtshalber" einen ATmega64M1 vorgegaukelt, nicht dass er von
sich aus bereits anfängt, da irgendwelche Speicherzugriffe
einzuschränken.

Ich stimme Simons Erkenntnissen zu, dass das Teil 1792 Bytes nutzbaren
SRAM hat (von 0x100 bis 0x7ff).  Es sieht auf den ersten Blick aus,
als würden ab 0x800 die CPU-Register gespiegelt.  Auf den zweiten
Blick sind sie es aber nicht komplett.  Hier der (beispielhafte)
Zustand nach den Power-On (mit gelöschtem Flash):

0x800000:  0xa1  0x8b  0x3f  0x37  0xf2  0x9e  0xf5  0xcd
0x800008:  0xed  0xff  0x4e  0x2a  0x77  0xfd  0x27  0xfb
0x800010:  0x9f  0xa4  0xef  0xdf  0x2e  0x6c  0xbe  0x57
0x800018:  0x86  0x6c  0x3c  0xe1  0xae  0x16  0xcc  0xd4
…
0x800800:  0xa1  0x8b  0x3f  0x37  0xf2  0x9e  0xf5  0xcd
0x800808:  0xed  0xff  0x4e  0x2a  0x77  0xfd  0x27  0xfb
0x800810:  0x9f  0xa4  0xef  0xdf  0x2e  0x6c  0xbe  0x57
0x800818:  0x86  0x6c  0x3c  0xe1  0xae  0xae  0x1f  0x08

Man kann erkennen, dass die Spiegelung nur bis r29 funktioniert,
danach wird auf Adresse 0x81d nochmal r29 gezeigt, während Adresse
0x81e und 0x81f jetzt auf 0x81f zeigen.  Möglicherweise handelt es
sich hier um Schattenregister, die debugWIRE selbst benutzt (welches
ja wiederum eine Art ROM-Monitor-Firmware ist).

Ab Adresse 0x820 beginnen dann merkwürdige Effekte, selbst, wenn man
(mit dem Debugger) nur lesend darauf zugreift.  Versucht man, nach dem
ersten Zugriff jenseits der 0x820 eine (gültige) RAM-Zelle zu
beschreiben, so liest man fortan nur noch 0x00 aus dem RAM.  Will man
danach die (nicht vorhandene, also nur aus 0xffff-NOPs bestehende)
Firmware weiterlaufen lassen, verabschiedet sich das debugWIRE auf
Nimmerwiedersehen, und man muss einen power cycle machen, bevor man
wieder irgendwas mit dem Teil anfangen kann.

Falls jemand das kleine Platinchen mit Simons Chip haben will (es ist
nur ein ISP-Stecker noch drauf, sonst nichts), dann versende ich es
auch gern weiter.  Ich häng' mal ein Foto mit an.