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