AT89C51ED2 + EEPROM

Hast Du den Fehler schon gefunden? Wäre mal von Intresse, woran es lag. 
Mir sind außer den zusätzlichen Ports, keine Unterschiede zwischen 
PLCC68 und PLCC44 Version bekannt. Möglicherweise sind in beiden sogar 
die gleichen Chips verbaut(?)

Hi,

poste doch bitte mal deinen Code. Arbeitest du über die interne API oder 
über selbstgebastelte Routinen? Bei Verwendung der API zum Schreiben 
steht etwas im Errata-Sheet, dass es den Controller durcheinanderbringen 
kann. Es steht nicht beschrieben, ob es eine bestimmte Gehäusevariante 
betrifft, aber ich kann mir vorstellen, dass evtl. die längeren 
Bonding-Drähte im größeren Gehäuse schon ausreichen, um den Fehler zu 
verursachen.

Ralf

1

//-------------------------------------------------------------------------

2

void xram_eeprom (uint adr, uint len)

3

{

4

   uint n,val,ie_save;

5

6

   ie_save = IE;                             // Interuptstatus sichern     

7

   IE    = 0x00;                             // alle Interrupts sperren    

8

   for (n=adr; n<len; n++)

9

   {

10

      EECON &= ~0x02;                        // XRAM Daten Mapping         

11

      val= *(uchar xdata*)n;                 // Akku mit XRAM laden        

12

      EECON |=0x02;                          // EEPROM Daten Mapping       

13

      *(uchar xdata*)n= val;                 // Akku in EEPROM schreiben    

14

      while (EECON & 0x01);                  // warten auf Busy 0          

15

   }

16

   EECON = 0x00;                             // XRAM Daten Mapping         

17

   IE    = ie_save;                          // Interruptstatus herstellen 

18

}           

19

//------------------------------------------------------------------------- 

20

void eeprom_xram (uint adr, uint len)           

21

{

22

   uint n,val,ie_save;

23

24

   ie_save = IE;                             // Interuptstatus sichern     

25

   IE    = 0x00;                             // alle Interrupts sperren    

26

   for (n=adr; n<len; n++)

27

   {

28

      EECON |=0x02;                          // EEPROM Daten Mapping       

29

      val= *(uchar xdata*)n;                 // Akku mit EEPROM laden       

30

      while (EECON & 0x01);                  // warten auf Busy 0          

31

      EECON &= ~0x02;                        // XRAM Daten Mapping         

32

      *(uchar xdata*)n= val;                 // Akku in XRAM schreiben       

33

   }

34

   EECON = 0x00;                             // XRAM Daten Mapping         

35

   IE    = ie_save;                          // Interruptstatus herstellen 

36

}       

37

//-------------------------------------------------------------------------

Hallo
das sind die beiden Routinen mit denen ich die Daten vom XRAM ins EEPROM 
und umgekehrt schreibe. Zur Verwendung der beiden CPU-Ausführungen noch 
folgender Hinweis:
Ich verwende einen BRENDES Emulator und will in der Singlechipausführung 
die sogenannten Softhooks zur Emulation von P0 und P2 umgehen.
Dazu habe ich mir ein eigenes POD gebaut bei dem ich die 68polige CPU 
verwende. P0 und P2 spendiere ich dem Emulator. Ich habe dann in den 
entspechenden Headerdateien die Adressen von P4 und P5 auf P0 und P2 
umgebogen.Natürlich ist es auch Hardwaremäßig so das Pund P% an den 
physikalischen Pins von P0 und P2 liegen. Wenn die Sofware fertig ist 
wird für die eigendliche Anwendung in der 44pol. CPU diese Manipulation 
rückgängig gemacht. Ich verwende dieses POD schon seit 2 Jahren ohne das 
bisher Probleme auftauchten.
Da hier keine Externen Leitungen verwendet werden habe ich bisher noch 
keine Erklärung. Wie gesagt am Emulator läuft alles einwandfrei.

Gruß Jürgen

Hallo Peter,
XRAM und EEPROM liegen im gleichen Adressraum und werden im 
EECON-Register durch das Bit EEE selektiert bzw. umgeschaltet. Daher 
kann der Datenpointer auf die gleiche Adresse zeigen. Den Code habe 
weitgehenst von der Atmel Apnote übernommen. Wenn ich feststellen könnte 
wo das Programm hängt hätte ich schon gewonnen. Im Emulator läuft es 
problemlos und alle Register haben korekte Werte.

Kann es sein, dass die Variablen volatile sein müssen, da der Compiler 
sonst evtl. meint, dass du in den gleichen Speicher schreibst und das 
ganze deswegen wegoptimiert? Das widerspricht zwar der Aussage, dass es 
mit dem anderen µC funktioniert, aber wer weiss...

Ralf

Wie ist uint genau definiert?
Welches Speichermodell (Small, Large...)?

Matthias

Ich habe Dein Programm mal auf meinen AT89C51ED2 im PLCC-44 getestet, es 
läuft. Eine kleine Anpassung habe ich vorgenommen: Alle Variablen und 
auch die Zeiger selber liegen jetzt im internen RAM, unabhängig vom 
Speichermodell. (Während der Routine darf keine Variable im XRAM 
liegen!)

Kontrolliere mal die Einstellung des AUXR-Registeres. Nach dem Reset ist 
nicht der gesamte XRAM aktiv, nur 768 Byte. Musst erst XRS2/1/0 richtig 
setzen. Auch könnte das EXTRAM bit falsch gesetzt sein.

Matthias

1

// Typendefinition

2

typedef unsigned int uint;

3

typedef unsigned char uchar;

4

5

//-------------------------------------------------------------------------

6

void xram_eeprom (uint adr, uint len)

7

{

8

   uint data n,val,ie_save;

9

10

   //ie_save = IE;                             // Interuptstatus sichern     

11

   //IE    = 0x00;                             // alle Interrupts sperren    

12

   EA = 0; // alle Interrupts sperren  

13

   for (n=adr; n<len; n++)

14

   {

15

      EECON &= ~0x02;                        // XRAM Daten Mapping         

16

      val= *(uchar xdata* data)n;                 // Akku mit XRAM laden        

17

      EECON |=0x02;                          // EEPROM Daten Mapping       

18

      *(uchar xdata* data)n= val;                 // Akku in EEPROM schreiben    

19

      while (EECON & 0x01);                  // warten auf Busy 0          

20

   }

21

   EECON = 0x00;                             // XRAM Daten Mapping         

22

   //IE    = ie_save;                          // Interruptstatus herstellen 

23

   EA = 1; // alle Interrupts freigeben

24

}           

25

//------------------------------------------------------------------------- 

26

void eeprom_xram (uint adr, uint len)           

27

{

28

   uint data n,val,ie_save;

29

30

   //ie_save = IE;                             // Interuptstatus sichern     

31

   //IE    = 0x00;                             // alle Interrupts sperren    

32

   EA = 0; // alle Interrupts sperren  

33

   for (n=adr; n<len; n++)

34

   {

35

      EECON |=0x02;                          // EEPROM Daten Mapping       

36

      val= *(uchar xdata* data)n;                 // Akku mit EEPROM laden       

37

      while (EECON & 0x01);                  // warten auf Busy 0          

38

      EECON &= ~0x02;                        // XRAM Daten Mapping         

39

      *(uchar xdata* data)n= val;                 // Akku in XRAM schreiben       

40

   }

41

   EECON = 0x00;                             // XRAM Daten Mapping         

42

   //IE    = ie_save;                          // Interruptstatus herstellen 

43

   EA = 1; // alle Interrupts freigeben

44

}       

45

//-------------------------------------------------------------------------

Hallo zusammen,
erstmal vielen Dank für Eure Antworten,ich war übers Wochenende nicht 
Zuhause und es ist erst mal nichts mehr gelaufen.

@Ralf: wenn ich mir mit dem Emulator den übersetzten ASM-Code anschaue 
ist soweit alles i.o.

@Matthias: alle lokalen Variablen sind vom Speichertyp Small. Das AUXR 
Register habe initialisiert auf 1792 Bytes ( obwohl ich nur 200 Bytes 
brauche) und der Zugriff aufs Int.XRAM freigeben.

Ich habe langsam den Verdacht das mit den CPU's was faul ist 
möglicherweise RD statt ED Typen.

Leider komme ich diese Woche nicht mehr dazu weiterzumachen (ist ein 
Privatvergnügen :-) )ich werde mal versuchen ein paar neur CPU's 
aufzutreiben. Ich melde mich wieder wenn ich neue Erkenntnisse habe.

Gruß Jürgen

Hallo,
ich bin erst heute wieder dazugekommen an der Steuerung weiterzumachen 
und bin dabei auf ein ganz anderes Problem gestossen. Ich hatte vermutet 
das das Programm an der Stelle wo auf das EEPROM zugegriffen wird hängt. 
In diesen Feler hatte ich mich verrannt weil das Programm mit nur 
geringfügiger Änderung (auskommentieren des Busyflags EECON) auf einem 
AT89C55 problemlos läuft. Der Zugriff aufs int. XRAM geht natürlich ins 
Nirvana:-) . Wenn ich den AT89C51ED2 einsetze geht garnichts d.h. der 
Controller macht nichts! Programmiert hat ihn mir ein Kollege mit dem 
GALEP4. Wir haben das mehrfach ausprobiert. Ich habe mir das ALE-Signal 
angeschaut da ist alles OK abernach einem Reset wird kein Befehl 
ausgeführt. Hat jemand von Euch dazu eine Vermutung?
Gruß Jürgen

Da wird Hilfe schwer. Eine Ursache könnte ein falsch gesetztes BLJB-Bit 
im AT89C51ED2 sein. Dann startet nach Reset nicht Dein Programm sondern 
der Bootloader (Auslieferungszustand!).

Wenn Du die Möglichkeit hast, programmier mal seriell über den internen 
Bootloader mit FLIP-Software.

Hallo Matthias,
ich bin dabei die Schaltung so zu modifizieren das ich an PSEN und Reset 
herankomme. Ich werde es mit dem Bootlader probieren. Danke
Gruß Jürgen

Hi Jürgen,

achte darauf, dass du nicht direkt auf LOW ziehst, sondern über einen 
PullDown-Widerstand (ALE ist normalerweise ein Ausgang), sonst könntest 
du den µC zerstören. Ich meine, der Reset ist auch bidirektional, aber 
das weiss ich grad nicht sicher.

Ralf

Hallo,

@Matthias, bingo das BLJB Bit war's, wir haben im GALEP Programmer die 
Stelle gefunden wo dieses Bit gesetzt bzw. gelöscht wird. Funktioniert 
jetzt alles einwandfrei.
@Ralf, ich habe eine Schaltung gefunden die dies berücksichtigt.

Danke noch an alle gruß Jürgen