externes Ram am Atmega162

[Andreas (ah3112)]

Hallo,

ich habe mich nach langen Jahren mal wieder mit meinen AVR-Controllern 
beschäftigt und versuche einen externen Ram beim ATMega162 anzusprechen. 
Ich bekomme es aber nicht hin.

In exakt derselben Hardware funktioniert es aber mit einem AT90S8515 mit 
derselben Software.

Als Ram habe ich einen 62256 und als Latch einen 74HCT573.

Der einzige Unterschied ist in der Software folgendes:

  #if defined(_AVR_ATmega162_)

     MCUCR = (1<<SRE) | (1<<SRW10);
  #elif defined(_AVR_AT90S8515_)

     MCUCR = (1<<SRE) | (1<<SRW);
  #endif

Ansonsten ist die Software vollkommen identisch.

Hat jemand einen Tipp für mich woran es liegen könnte.

Für eine Antwort im Voraus vielen Dank.
Viele Grüße

[Helmut -. (dc3yc)]

Dein Problem liegt in Zeile 42 des Programms oder beim IC J42! Also 
bitte Schaltplan und Programm hier hereinstellen.

[Falk B. (falk)]

Andreas schrieb:
> Ich bekomme es aber nicht hin.

Was geht denn nicht? Wie testest du? Mal alle Verbindungen geprüft? Mal 
den RAM "zu Fuß" per Software angesprochen? Dann weiß man wenigstens, 
daß alle Verbindungen stimmen.

[Peter D. (peda)]

Andreas schrieb:
> Der einzige Unterschied ist in der Software folgendes:

Sollte nicht sein, die Bits heißen lt. Datenblatt in beiden genau 
gleich.
Ein "SRW" konnte ich nicht finden.

Ein Unterschied ist allerdings der Start des XMEM, da der M162 1kB 
intern hat.

[Andreas (ah3112)]

Euch Dreien erstmal Danke für die schnellen Antworten.

Helmut -. schrieb:
> Also bitte Schaltplan und Programm hier hereinstellen.

Das hatte ich vergessen zu erwähnen. Es handelt sich um ein STK200. Das 
habe ich genommen, weil ich dort externen RAM gesteckt habe. Auf meinem 
STK500 ginge es nur über das STK501. Auf demselben Sockel hatte es mit 
dem AT90S8515 funktioniert.

Falk B. schrieb:
> Mal den RAM "zu Fuß" per Software angesprochen? Dann weiß man
> wenigstens, daß alle Verbindungen stimmen.

Das habe ich gemacht. Aber ich will nicht ausschließen, dass mir dabei 
Fehler passiert sind, weil ich nach mehreren Stunden nicht mehr so 
konzentriert war.

Peter D. schrieb:
> Ein "SRW" konnte ich nicht finden.

Ich habe gerade nochmal im Datenblatt nachgeschaut. Bei der Beschreibung 
des MCUCR-Registers steht das "SRW".

Peter D. schrieb:
> Ein Unterschied ist allerdings der Start des XMEM, da der M162 1kB
> intern hat.

Das hatte ich berücksichtigt. Beim AT90S8515 habe ich als Adresse 0x0260 
genommen und beim ATmega162 0x0500. Zumindest habe ich es so in 
Erinnerung. Der PC ist schon aus. Aber ich weiss, dass ich die 
unterschiedlichen Adressen berücksichtigt hatte.

Sobald wie ich dazu komme, werde ich das nochmal so ausprobieren, wie 
Falk vorgeschlagen hat und mich dann wieder melden und den Code des 
Programms hier einstellen.

Danke erstmal.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Andreas schrieb:
> MCUCR = (1<<SRE) | (1<<SRW10);
> Hat jemand einen Tipp für mich woran es liegen könnte.

Kann es zufällig sein, dass Du den SRAM in dem unteren Adressraum hast 
und die Waitstates für die obere Hälfte einstellst? Bei einem 70ns-SRAM 
und einem langsamen LATCH wie hier würde ich es zuerst auch mit zwei 
Waitstates probieren und wenn es läuft, dann damit runter auf 1 gehen – 
natürlich in der richtigen Hälfte des Adressraums. Dem Datenblatt nach 
befinden sich die anderen Bits in dem EMCUCR (Extended MCU Control 
Register).

[Falk B. (falk)]

Mit welchem Takt läuft der AVR? Es gab mal die Info, daß bei vollen 16 
MHz ein HCT zu langsam ist und man ein ACT Latch braucht.

[Andreas (ah3112)]

Gregor J. schrieb:
> Kann es zufällig sein, dass Du den SRAM in dem unteren Adressraum hast
> und die Waitstates für die obere Hälfte einstellst?

Ich werde mir das nochmal genau ansehen und auch Deine Anmerkung 
berücksichtigen. Ich komme heute nur nicht dazu. Aber Danke erstmal.

Falk B. schrieb:
> Mit welchem Takt läuft der AVR?

Auf dem STK200 ist ein 4MHz Quarz fest eingebaut. Da habe ich auch keine 
Möglichkeit einen anderen zu nehmen.

Falk B. schrieb:
> Es gab mal die Info, daß bei vollen 16 MHz ein HCT zu langsam ist und
> man ein ACT Latch braucht.

Die exakte Bezeichnung ist: MM74HCT573N

Was mich irritiert ist, dass es mit einem AT90S8515 funktioniert. Aber 
nicht mit dem ATmega162. Auf dem AT90S8515 läuft auch eine Software mit 
fast 7K Flash und die erheblich mehr RAM benötigt als beide Controller 
intern haben.

Ich werde das in den nächsten Tagen, wie von Dir vorgeschlagen, mit 
einem kurzen Testprogramm, was nur den RAM anspricht, überprüfen und 
mich dass wieder melden.

Bisher erstmal Euch allen Danke.

[Obelix X. (obelix)]

Einfach mal messen ob alle Signale richtig am RAM ankommen.

[Peter D. (peda)]

Andreas schrieb:
> Auf dem STK200 ist ein 4MHz Quarz fest eingebaut. Da habe ich auch keine
> Möglichkeit einen anderen zu nehmen.

Es gibt HC-49 Fassungen:
https://www.fischerelektronik.de/web_fischer/en_GB/connectors/F04/Sockets%20for%20crystal%20oscillators/$catalogue/fischerData/PG/PQ_18/search.xhtml

Auch kann man über das CLKPR den Takt reduzieren.

[Falk B. (falk)]

Andreas schrieb:
>> Mit welchem Takt läuft der AVR?
>
> Auf dem STK200 ist ein 4MHz Quarz fest eingebaut. Da habe ich auch keine
> Möglichkeit einen anderen zu nehmen.

Bei 4 MHz tut es auch ein HCT. Das ACT braucht man nur bei 16MHz.

[S. L. (sldt)]

> nach langen Jahren mal wieder ... ATMega162

Funktioniert denn überhaupt etwas auf dem ATmega162? Oder ist vielleicht 
Fuse M161C eingeschaltet?

[Andreas (ah3112)]

S. L. schrieb:
> Funktioniert denn überhaupt etwas auf dem ATmega162?

Ja, generell läuft der. Die LEDs an den Ausgängen funktionieren.

S. L. schrieb:
> Oder ist vielleicht Fuse M161C eingeschaltet?

Hatte ich schon vor Erstellen des Threads kontrolliert. Ist nicht 
gesetzt.

Peter D. schrieb:
> Es gibt HC-49 Fassungen:

Eigentlich hatte ich nicht vor auf dem STK200 zu löten. Ich wollte mit 
der Angabe, dass es 4MHz fest verbaut sind, auch nur sagen, dass es 
nicht an einer zu hohen Quarzfrequenz liegt.

Peter D. schrieb:
> Auch kann man über das CLKPR den Takt reduzieren.
Danke, das werde ich, neben dem Hinweis von Gregor mit den Wait-States 
am Wochenende ausprobieren.

Obelix X. schrieb:
> Einfach mal messen ob alle Signale richtig am RAM ankommen.

Daran habe ich auch gedacht. Aber da es mit einem AT90S8515 auf 
demselben Steckplatz funktioniert, bin ich erstmal davon ausgegangen, 
dass da alles ok ist.

Ich werde das am Wochenende sowohl von der Softwareseite testen als auch 
elektrisch durch messen und mich dann wieder melden.

Euch allen erstmal vielen Dank.

[S. L. (sldt)]

Ohne Ihnen zu nahe treten zu wollen - es ist das alte Lied: Programm auf 
das nötige Minimum reduzieren und hier vorstellen (mitsamt 
Fuse-Einstellungen). Sollte ein eventueller Programmfehler dann nicht 
auf Anhieb erkennbar sein, so findet sich sicher der Eine oder Andere, 
der bereit wäre, seine alte Hardware hervorzuholen und mal kurz wieder 
in Betrieb zu nehmen.

[Andreas (ah3112)]

Ich habe mir jetzt ein kurzes Testprogramm geschrieben. Darin habe ich 
für den ATMega162 die von Gregor und Peter genannten Hinweise 
berücksichtigt.

Mit dem AT90S8515 funktioniert es einwandfrei. Da sehe ich die LED an 
PB2 (TEST_FAIL) nicht. Um sicher zu gehen, habe ich den Befehl zur 
Aufschaltung des externen Rams (MCUCR = (1<<SRE) | (1<<SRW); für den 
AT90S8515 auskommentiert, dann sehe ich auch TEST_FAIL. Also liegt es 
nicht an der Hardware.

Mit dem ATMega162 läuft der Ramtest auf Fehler. Die einzelnen Versuche 
habe ich im untenstehenden Code auskommentiert.

Gregor J. schrieb:
> Kann es zufällig sein, dass Du den SRAM in dem unteren Adressraum hast
> und die Waitstates für die obere Hälfte einstellst?
Das habe ich noch nicht so richtig verstanden, wie Du das meinst. Laut 
Datenblatt wird der externe Ram hinter den internen gehangen. Ich hatte 
alle Flags des EMCUCR unverändert gelassen. Wenn ich das Datenblatt 
richtig verstanden habe, waren weder für die oberen noch unteren 
Adressen Wait-States vorhanden.

Hier die Software meiner heutigen Tests:

#include <avr/io.h>

#if defined(__AVR_ATmega162__)
  #define SRAM_START_ADR   0x0500
  #define SRAM_END_ADR   0x7FFF
#elif defined(__AVR_AT90S8515__)
  #define SRAM_START_ADR   0x260
  #define SRAM_END_ADR   0x7FFF
#else
  #error "Ram Start- und Endadresse nicht definiert"
#endif

#define LED_PORT    PORTB
#define LED_DDR     DDRB

#define TEST_1    0
#define TEST_2    1
#define TEST_FAIL  2
#define TEST_ENDE  7


int  main (void)
{
  uint8_t *p;

 // externen Ram aufschalten    
#if defined(__AVR_ATmega162__)
  // Versuch 1, ohne EMCUCR
  MCUCR = (1<<SRE) | (1<<SRW10);

  // Versuch 2, ohne EMCUCR
  // MCUCR = (1<<SRE) | (0<<SRW10);

  // Versuch 3, mit MCUCR und 2 Wait-States Lesen/Schreiben, 1 Wait-State bei Adressausgabe
    // MCUCR = (1<<SRE) | (1<<SRW10);
    // EMCUCR = (0<< SRL2) | (0<<SRL1) | (0<<SRL0) | (0<<SRW01) | (0<<SRW00) | (1<<SRW11) | (0<<ISC2);

  // Versuch 4, mit MCUCR und 2 Wait-States Lesen/Schreiben
    // MCUCR = (1<<SRE) | (0<<SRW10);
    // EMCUCR = (0<< SRL2) | (0<<SRL1) | (0<<SRL0) | (0<<SRW01) | (0<<SRW00) | (1<<SRW11) | (0<<ISC2);

  // Versuch 5, mit MCUCR und 1 Wait-States Lesen/Schreiben
  // MCUCR = (1<<SRE) | (1<<SRW10);
  // EMCUCR = (0<< SRL2) | (0<<SRL1) | (0<<SRL0) | (0<<SRW01) | (0<<SRW00) | (0<<SRW11) | (0<<ISC2);

  // Versuch 6, mit MCUCR und keine Wait-States Lesen/Schreiben
  // MCUCR = (1<<SRE) | (0<<SRW10);
  // EMCUCR = (0<< SRL2) | (0<<SRL1) | (0<<SRL0) | (0<<SRW01) | (0<<SRW00) | (0<<SRW11) | (0<<ISC2);

  // Versuch 7, Prescaler auf 128
  //MCUCR = (1<<SRE) | (1<<SRW10);
  //CLKPR = (0<<CLKPS3) | (1<<CLKPS2) | (1<<CLKPS2) | (1<<CLKPS0);

  // Versuch 8, Prescaler auf 256
  // MCUCR = (1<<SRE) | (1<<SRW10);
  // CLKPR = (1<<CLKPS3) | (0<<CLKPS2) | (0<<CLKPS2) | (0<<CLKPS0);

  // Versuch 9, Prescaler auf 256
  //MCUCR = (1<<SRE) | (1<<SRW10);
  //CLKPR = (1<<CLKPS3) | (0<<CLKPS2) | (0<<CLKPS2) | (0<<CLKPS0);

  // Versuch 10, Prescaler auf 256 und Buskeeper
  // MCUCR = (1<<SRE) | (1<<SRW10);
  // CLKPR = (1<<CLKPS3) | (0<<CLKPS2) | (0<<CLKPS2) | (0<<CLKPS0);
    // SFIOR |= (1<<XMBK);

#elif defined(__AVR_AT90S8515__)    
    MCUCR = (1<<SRE) | (1<<SRW);
#elif defined(__AVR_AT90CAN128__)
    XMCRA = (1<<SRE);
#else
    #error "Wrong MCU defined"
#endif
    
    LED_DDR     = 0xFF;
    LED_PORT    = 0xFF;

    LED_PORT &= ~(1<<TEST_1);

    for(p = (uint8_t *) SRAM_START_ADR;p<(uint8_t *)SRAM_END_ADR;p++)
    {
      *p = 0x55;
    }

    for(p = (uint8_t *) SRAM_START_ADR;p<(uint8_t *)SRAM_END_ADR;p++)
    {
      if (*p!=0x55) { LED_PORT &= ~(1<<TEST_FAIL); }  
    }

    LED_PORT &= ~(1<<TEST_2);
    for(p = (uint8_t *) SRAM_START_ADR;p<(uint8_t *)SRAM_END_ADR;p++)
    {
      *p = 0xAA;
    }
    for(p = (uint8_t *) SRAM_START_ADR;p<(uint8_t *)SRAM_END_ADR;p++)
    {
      if (*p!=0xAA) { LED_PORT &= ~(1<<TEST_FAIL); }  
    }
    LED_PORT &= ~(1<<TEST_ENDE);
    while(1);
    return 0;
}

Wenn jemand noch eine Idee hat, dann schon mal Danke.

[S. L. (sldt)]

> ... AVR_AT90CAN128 ...

Wo kommt jetzt der her?

[Axel R. (axlr)]

https://ww1.microchip.com/downloads/en/Appnotes/doc2536.pdf

Vielleicht findet sich was interessantes?
Jtag noch aktiv, oderso?

[S. L. (sldt)]

an Andreas:

Also bei mir leuchten zum Schluss die LEDs 7, 1 und 0 - ist doch 
korrekt, oder habe ich das falsch verstanden?

Meinen vorigen Kommentar bitte ignorieren, da hat mich die Flut der 
Kommentarzeilen irregeführt.

PS:
meine Fuses: EF D1 FF

(und Klammerzusatz entfernt)

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Andreas schrieb:
> Das habe ich noch nicht so richtig verstanden, wie Du das meinst. Laut
> Datenblatt wird der externe Ram hinter den internen gehangen. Ich hatte
> alle Flags des EMCUCR unverändert gelassen. Wenn ich das Datenblatt
> richtig verstanden habe, waren weder für die oberen noch unteren
> Adressen Wait-States vorhanden.

Ich habe jetzt im Datenblatt gesehen (im Anhang), dass, wenn alle 
SRL-Bits auf Null gesetzt sind, dann die Waitsates des gesamten 
Adressraums einfach nur über die Bits des Uppersectors eingestellt 
werden, insofern dürfte Deine Annahme am Anfang mit „MCUCR = (1<<SRE) | 
(1<<SRW10);” ausgereicht haben, um den gesamten Adressraum mit einem 
Waitstate zu betreiben, und meine demnach falsch war, da ich die 
gelöschten SRLs nicht berücksichtigt habe. Es schadet aber nicht und 
kostet auch nichts, das auch einmal so wie unten zu probieren, denn in 
irgendwelche Erratas, wo Designfehler aufgeführt werden, habe ich jetzt 
nicht nachgeschaut:

MCUCR = (1<<SRE) | (1<<SRW10);
EMCUCR = (1<<SRW00);

Viel interessanter wäre auch zu wissen, wo der Compiler/Linker den 
Stapel hier platziert, denn der könnte Dir hier bei dem Test, wo Du alle 
Bytes durchgehst, oder später im Betrieb einen Strich durch die Rechnung 
machen. Normalerweise müsste der Stapel am Ende des internen SRAMs 
platziert worden sein und dann abwärts in die Tiefe gehen und seine 
Betrachtung somit egal sein, aber überprüfen sollte man es trotzdem (am 
besten auch den generierten Assemblercode anschauen) und den RAM-Test 
würde ich auch erstmal nur mit einem einzigen Byte an z.B. Adresse 
0x4001 oder 0x5000 ohne irgendwelche komplexen Schleifenausdrücke und 
Inkrementationen probieren, also irgendwo in der Mitte des externen 
Speichers. Einfach nur ein Byte (mit dem Muster) dort reinschreiben, wo 
der Pointer zeigt, anschließend an der Stelle auslesen und vergleichen.

[Andreas (ah3112)]

S. L. schrieb:
> Wo kommt jetzt der her?
Ich hatte das Testprogramm ursprünglich vor millionen von Jahren mal für 
den AT90CAN128 geschrieben. Wollte das aber jetzt nicht rausschmeissen.

Axel R. schrieb:
> Jtag noch aktiv, oderso?

Bingo, das war es. Da wäre ich nie drauf gekommen. Jetzt läuft das 
Testprogramm.

S. L. schrieb:
> Also bei mir leuchten zum Schluss die LEDs 7, 1 und 0 - ist doch
> korrekt, oder habe ich das falsch verstanden?
Nein, genau so muss es sein.

S. L. schrieb:
> meine Fuses: EF D1 FF
Meine sind jetzt CE D9 FF. Aber erst nach dem Hinweis von Axel. Vorher 
waren sie CE 99 FF.

Gregor J. schrieb:
> aber ich würde den RAM-Test trotzdem
> erstmal nur mit einem einzigen Byte an z.B. Adresse 0x4001 oder 0x5000
> ohne irgendwelche komplexen Schleifenausdrücke und Inkrementationen
> probieren, also irgendwo in der Mitte des externen Speichers.
Hätte ich morgen gemacht. Aber nach dem Hinweis von Axel dämmerte mir 
was, dass ich das Bit für JTag beim Auslesen der Fuses in AVR-Studio 
gesehen hatte. Eigentlich wollte ich morgen erst wieder dran gehen. Aber 
das hatte mir keine Ruhe gelassen und musste das noch ausprobieren.

Die Application Note AVR087 wird sofort gespeichert. Die kannte ich gar 
nicht.

Ganz lieben Dank an alle, die sich die Mühe gemacht haben, damit zu 
beschäftigen.