25AA02E48 Reg. MAC auslesen

[Ingo S. (schicki)]

Hallo Zusammen,

ich habe eine kleine Routne für einen 25AA02E48 Chip geschrieben. diese 
arbeitet aber nicht korrekt. Takt und Daten liegen an, allerdings 
bekomme ich keine Daten zurück.

/************************************************************************/
// 25AA02E48-Befehle
/************************************************************************/
#define READ    0x03    // Read data from memory array beginning at selected address 
#define WRITE   0x02    // Write data to memory array beginning at selected address   
#define WRDI    0x04    // Reset the write enable latch (disable write operations)
#define WREN    0x06    // Set the write enable latch (enable write operations)
#define RDSR    0x05    // Read STATUS register
#define WRSR    0x01    // Write STATUS register
/************************************************************************/

/************************************************************************/
unsigned char Read_Byte_25AA025E48(unsigned char unc_Register)
{
    unsigned char unc_Daten = 0;
    
    SPI1_Open(SPI1_DEFAULT);
   
    CS_1 = 0;
    __delay_ms(1);
    
    if(SSPSTATbits.BF)
    {
        SPI1_ExchangeByte(READ);
        SPI1_ExchangeByte(unc_Register);
        unc_Daten = SPI1_ExchangeByte(0x00);
    }

    __delay_ms(1);
    CS_1 = 1;
    
    SPI1_Close();
    
            
    return unc_Daten; 
}  
/************************************************************************/

    chr_MAC[0] = Read_Byte_25AA025E48(0xFA);
    chr_MAC[1] = Read_Byte_25AA025E48(0xFB);
    chr_MAC[2] = Read_Byte_25AA025E48(0xFC);
    chr_MAC[3] = Read_Byte_25AA025E48(0xFD);
    chr_MAC[4] = Read_Byte_25AA025E48(0xFE);
    chr_MAC[5] = Read_Byte_25AA025E48(0xFF);
    
    sprintf(chr_Temp, "MAC-Adresse:    %02X:%02X:%02X:%02X:%02X:%02X\n\r", chr_MAC[0], chr_MAC[1], chr_MAC[2], chr_MAC[3], chr_MAC[4], chr_MAC[5]);
    USART_Write_String(chr_Temp);

Ich bekomme nur 00:00.. zurück. Mit SPI arbeite ich zum ersten mal.Laut 
DB schreibt am ja 0x03 und das zu lesende Reg. Danach sollen die Daten 
kommen. Woran kann das liegen?

Die Leitungen CLK -> CLK. SDO -> SDI, SDI -> SDO. hold und WP sind über 
einen 100K an VCC angeschlossen.

VG
Ingo

[fop (Gast)]

SPI1_DEFAULT : aha...

Bedienst Du das Signal /CS ? Kommet es am Baustein an ?
Stimmen Ruhepegel und Flanken des CLK Signals ? (wobei vermutlich nicht 
nur Nullen, sondern falsche Daten kommen würden, wenn Du hier patzt)
Liegt /HOLD auf High ?
Hat der Speicherbaustein seine Spannungsversorgung ?
Ist der SCLK lahm genug, dass der Baustein mitkommt ?
Ist das Timing /CS zu SCLK langsam genug für den Baustein ?

[c-hater (Gast)]

Ingo S. schrieb:

>     SPI1_Open(SPI1_DEFAULT);

Aha...

Takt? Mode? Bitorder?

[Ingo S. (schicki)]

Hallo das mit dem Speed könnte sein. Laut Code Configurator sollten es 
6,25 Mhz sein. Das kommt auch als Takt am Oszi an. Mode 0 ist laut MCC 
konfiguriert. Die Daten kommen am Ende. Das Projekt und Schaltplan ist 
im Anhang.

Hold ist auf High, Spannungsversorgung stimmt. Verdrahtung Clk usw 
stimmt es kann eigentlich nur was an der Config sein..

[Ingo S. (schicki)]

Hallo,

Zwischenzeitlich habe ich die SPI-Libary neugeschrieben. Die HArdware 
unzählige male geprüft. Da sollte eigentlich kein Fehler sein. Den 
Conroller bzw. den Speicher habe ich auch einmal gewechselt. Keine 
Änderung.

Der 25AA02E48 arbeitet laut DB mit Mode 00 bzw. 11. Die Daten würde ich 
gerne am Ende samplen. Sobald ich Daten verschicke, antwortet der der 
Speicher nicht.

Folglich muss an der Initalisierung bzw. an der Abfrage etwas nicht 
stimmen. Kenn jemand dieses Problem.

Die Quelldaten sind inkl. Plän sind im Anhang. Ich komme da nicht 
weiter.. In der Hoffnung das jemand helfen kann.

VG
Ingo

[Frank K. (fchk)]

Ingo S. schrieb:

> Die Quelldaten sind inkl. Plän sind im Anhang. Ich komme da nicht
> weiter.. In der Hoffnung das jemand helfen kann.

Hast Du einen Logic Analyzer? So ein 10€-Teil von Amazon oder so reicht. 
Hänge Dich da mal an die SPI-Pins (CS, SCK, MISO, MOSI) und schaue, was 
da tatsächlich auf der Leitung rauskommt.

fchk

ps:
https://www.amazon.de/AZDelivery-%E2%AD%90%E2%AD%90%E2%AD%90%E2%AD%90%E2%AD%90-Logic-Analyzer-gratis/dp/B01MUFRHQ2

[Ingo S. (schicki)]

Hi Frank,

sorry der liegt im Büro. Irgendwie werden der SPI-Bus und ich keine 
Freunde. Ich habe den noch nie mögen. Es hätte ja sein können dass ich 
einen Pull-Up oder so nicht berücksichtigt hätte. Dann sitzt der Fehler 
ganz klar vor dem Rechner.

Sämtliche I2C Bausteine mit MAC habe ich zum laufen gebracht. Ein Kunde 
wünscht sich nun das via SPI. Obwohl ne MAC über ein 24AA025E48 bzw. 
über MCP794511 verfügbar wäre.

was soll man machen??

schönes Wochenende
Ingo

[Frank K. (fchk)]

SO, ich habe mir mal deine Pläne angeschaut. Du benutzt 
RC2(CS),RC3(SCK),RC4(SDI),RC5(SDO). Auf Sheet 5 werden RC4 und RC5 aber 
für einen MAX3232 und einem UART benutzt. Das geht natürlich so nicht. 
Alle Pins müssen zwingend ausschließlich für SPI verwendet werden und 
für überhaupt gar nichts anderes, weder in der Hardware noch in der 
Software. Auch das AT45DB011-Modul benutzt diese Pins, und vor allem 
benutzt es den gleichen CS.

Du hast auch beim RS485 eine Doppelbelegung von RC6 und RC7 mit dem 
RS232. Dss wird auch knallen.

Das wird Dein Problem sein.

Warum verwendest Du eigentlich nicht einen AT24MAC402 am I2C? Da kannst 
DU dann an den beiden Pins noch andere Sachen betreiben, und der Chip 
hat einerseits die vollen 2k an verwendbarem EEPROM und zusätzlich MAC 
und UUID auf einer anderen I2C-Adresse. Diese Teile setze ich auf allen 
meinen Baugruppen ein (ob sie Ethernet haben oder nicht), und damit ist 
jede Baugruppe eineindeutig identifizierbar.

fchk

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

Ingo S. schrieb:
> Die HArdware unzählige male geprüft.
Mit einem Logikanalyzer oder einem Speicheroszi? Passiert auf den 
SPI-Leitungen das, was das Datenblatt vorschreibt?

Frank K. schrieb:
> Das geht natürlich so nicht. Alle Pins müssen zwingend ausschließlich
> für SPI verwendet werden und für überhaupt gar nichts anderes, weder in
> der Hardware noch in der Software.
Man kann (Ausgangs-)Pins, die an Eingänge von externen Komponenten 
führen schon durchaus doppelt verwenden. Allerdings muss man dann die 
resultierenden Fehler tolerieren können oder Mechanismen schaffen, dass 
sie sich nicht schädlich auswirken.

> Auf Sheet 5 werden RC4 und RC5 aber für einen MAX3232 und einem UART
> benutzt. Das geht natürlich so nicht.
Beim RC5 ginge das noch. Kommen halt ab&zu eigenartige Zeichen über den 
UART.
Aber der RC4 wird ja gleichzeitig vom Ausgang des MAX und vom µC 
getrieben. Klassiche Buskollision. Da kommt kein brauchbares Signal am 
SI des EEPROMS an. Die sieht man mit einem Oszi sofort am "seltsamen" 
Logikpegel.

> Auch das AT45DB011-Modul benutzt diese Pins, und vor allem benutzt es
> den gleichen CS.
Ich dacht, das wäre "nur" der ISP-Stecker. Aber wenn da tatsächlich was 
drauf ist, dann ist das eine üble Sache.

[Ingo S. (schicki)]

Hi Frank,

das war das Wort zum Sonntag, Die Handshake Leitung ist mir nicht mehr 
in den Sinn gekommen. RS-232 und RS-485 funktionieren wunderbar 
parallel. Du darfst nur eine benutzen, die andere kann an im Notfall zum 
Debuggen verwenden.

Im Schulbetrtrieb ist es praktisch wenn du beides hast. Kaum war die 
Handshake Leitung gesetzt bzw. getrennt läuft alles.

Klasse. Super vielen Dank.

ein schönes Wochenende an alle
Ingo