externes Ram am Atmega162

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

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.

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.

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.

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).

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.

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.

Einfach mal messen ob alle Signale richtig am RAM ankommen.

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.

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.

nach langen Jahren mal wieder ... ATMega162

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

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.

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.

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:

1

#include <avr/io.h>

2

3

#if defined(__AVR_ATmega162__)

4

  #define SRAM_START_ADR   0x0500

5

  #define SRAM_END_ADR   0x7FFF

6

#elif defined(__AVR_AT90S8515__)

7

  #define SRAM_START_ADR   0x260

8

  #define SRAM_END_ADR   0x7FFF

9

#else

10

  #error "Ram Start- und Endadresse nicht definiert"

11

#endif

12

13

#define LED_PORT    PORTB

14

#define LED_DDR     DDRB

15

16

#define TEST_1    0

17

#define TEST_2    1

18

#define TEST_FAIL  2

19

#define TEST_ENDE  7

20

21

22

int  main (void)

23

{

24

  uint8_t *p;

25

26

 // externen Ram aufschalten    

27

#if defined(__AVR_ATmega162__)

28

  // Versuch 1, ohne EMCUCR

29

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

30

31

  // Versuch 2, ohne EMCUCR

32

  // MCUCR = (1<<SRE) | (0<<SRW10);

33

34

  // Versuch 3, mit MCUCR und 2 Wait-States Lesen/Schreiben, 1 Wait-State bei Adressausgabe

35

    // MCUCR = (1<<SRE) | (1<<SRW10);

36

    // EMCUCR = (0<< SRL2) | (0<<SRL1) | (0<<SRL0) | (0<<SRW01) | (0<<SRW00) | (1<<SRW11) | (0<<ISC2);

37

38

  // Versuch 4, mit MCUCR und 2 Wait-States Lesen/Schreiben

39

    // MCUCR = (1<<SRE) | (0<<SRW10);

40

    // EMCUCR = (0<< SRL2) | (0<<SRL1) | (0<<SRL0) | (0<<SRW01) | (0<<SRW00) | (1<<SRW11) | (0<<ISC2);

41

42

  // Versuch 5, mit MCUCR und 1 Wait-States Lesen/Schreiben

43

  // MCUCR = (1<<SRE) | (1<<SRW10);

44

  // EMCUCR = (0<< SRL2) | (0<<SRL1) | (0<<SRL0) | (0<<SRW01) | (0<<SRW00) | (0<<SRW11) | (0<<ISC2);

45

46

  // Versuch 6, mit MCUCR und keine Wait-States Lesen/Schreiben

47

  // MCUCR = (1<<SRE) | (0<<SRW10);

48

  // EMCUCR = (0<< SRL2) | (0<<SRL1) | (0<<SRL0) | (0<<SRW01) | (0<<SRW00) | (0<<SRW11) | (0<<ISC2);

49

50

  // Versuch 7, Prescaler auf 128

51

  //MCUCR = (1<<SRE) | (1<<SRW10);

52

  //CLKPR = (0<<CLKPS3) | (1<<CLKPS2) | (1<<CLKPS2) | (1<<CLKPS0);

53

54

  // Versuch 8, Prescaler auf 256

55

  // MCUCR = (1<<SRE) | (1<<SRW10);

56

  // CLKPR = (1<<CLKPS3) | (0<<CLKPS2) | (0<<CLKPS2) | (0<<CLKPS0);

57

58

  // Versuch 9, Prescaler auf 256

59

  //MCUCR = (1<<SRE) | (1<<SRW10);

60

  //CLKPR = (1<<CLKPS3) | (0<<CLKPS2) | (0<<CLKPS2) | (0<<CLKPS0);

61

62

  // Versuch 10, Prescaler auf 256 und Buskeeper

63

  // MCUCR = (1<<SRE) | (1<<SRW10);

64

  // CLKPR = (1<<CLKPS3) | (0<<CLKPS2) | (0<<CLKPS2) | (0<<CLKPS0);

65

    // SFIOR |= (1<<XMBK);

66

67

#elif defined(__AVR_AT90S8515__)    

68

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

69

#elif defined(__AVR_AT90CAN128__)

70

    XMCRA = (1<<SRE);

71

#else

72

    #error "Wrong MCU defined"

73

#endif

74

75

    LED_DDR     = 0xFF;

76

    LED_PORT    = 0xFF;

77

78

    LED_PORT &= ~(1<<TEST_1);

79

80

    for(p = (uint8_t *) SRAM_START_ADR;p<(uint8_t *)SRAM_END_ADR;p++)

81

    {

82

      *p = 0x55;

83

    }

84

85

    for(p = (uint8_t *) SRAM_START_ADR;p<(uint8_t *)SRAM_END_ADR;p++)

86

    {

87

      if (*p!=0x55) { LED_PORT &= ~(1<<TEST_FAIL); }  

88

    }

89

90

    LED_PORT &= ~(1<<TEST_2);

91

    for(p = (uint8_t *) SRAM_START_ADR;p<(uint8_t *)SRAM_END_ADR;p++)

92

    {

93

      *p = 0xAA;

94

    }

95

    for(p = (uint8_t *) SRAM_START_ADR;p<(uint8_t *)SRAM_END_ADR;p++)

96

    {

97

      if (*p!=0xAA) { LED_PORT &= ~(1<<TEST_FAIL); }  

98

    }

99

    LED_PORT &= ~(1<<TEST_ENDE);

100

    while(1);

101

    return 0;

102

}

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

... AVR_AT90CAN128 ...

Wo kommt jetzt der her?

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

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

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)

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.

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.