Hallo! An eine EFM8BB1 (24M5Hz) habe ich ein 32KiB SRAM (23K256T, sequential mode) und einen 8MiB Flash Speicher geklemmt (beide am selben SPI Bus), um Nachrichten über I2C zu empfangen, im 32KiB SRAM zu speichern und später über ein einzelnes Kabel an ein „USB-Gerät“ (ATtiny85) zu schicken. Das klappt auch meistens ganz gut. Der Flash Speicher wird derzeit nicht genutzt (der kommt erst später bei Stromausfall ins Spiel... grins). Das Problem ist nun: Wenn ich die „Busy Bee“ mit 12M25Hz auf dem SPI Bus summen lasse, dann kommt es selten aber immer wieder zu Schreibfehlern, wobei im 32KiB SRAM nicht ein einziges Byte dort anzukommen scheint, wo es hingeschrieben werden sollte. Wenn ich nur noch die halbe SPI-Taktfrequenz (6M125Hz) nehme, dann passieren die Fehler nicht mehr. Wie kommt das? Ist es eher in Wirklichkeit eine kaputte Lötverbindung (ich kann die nicht mehr inspizieren, weil die schon mit Aquariumsilikon (das Gute mit der Essigsäure) verdeckt sind)? Ist es normal, dass SPI mit 12MHz nicht so richtig gut geht? Ist es üblich, das Geschriebene anschließend zu überprüfen? Kann man beim Schreiben von dem Ausgang (SO) des SRAM irgendwas nützliches schließen? (eigentlich sagt das Datenblatt „high impedance“) Dange. Bye Arne
ohoh... Die Fehler passieren immernoch... Und nicht einmal seltener... Dann werde ich wohl mal nur den SPI-Teil allein testen, falls es mit den Interrupts (I2C/ADC/MAT/Timer) zu tun hat... -Arne
Riddicc schrieb: > Ist es eher in Wirklichkeit eine kaputte Lötverbindung (ich kann die > nicht mehr inspizieren, weil die schon mit Aquariumsilikon (das Gute mit > der Essigsäure) verdeckt sind)? Etwas voreilig vermutlich. Es wäre nötig, sich die Signale mit einem Oszilloskop anzusehen.
Joe F. schrieb: > Es wäre nötig, sich die Signale mit einem Oszilloskop anzusehen. > hmm... Also ich konnte grad 65536 mal 64 einen Wert schreiben und wieder lesen, wobei bei jedem Zyklus ein anderer Wert als beim vorherigen Zyklus dran war. Dabei gab es keinen Fehler (ich hab das 2 mal wiederholt). Dann liegt es wohl daran, dass die ganzen ISRs sich gegenseitig behindern... <blush/> :) -Arne
Dann liegt es evtl. am Wetter oder an der Planetenkonstellation. Voreilige Schlüsse haben allerdings schon zu Weltkriegen geführt. Nein, im Ernst, spekulieren bringt nichts. Man muss dem Problem analytisch auf den Grund gehen, und das erste wäre zu überprüfen, ob die Bussignale gesund aussehen (Pegel, Flankensteilheit).
ohoh... Jetzt habe ich den Fehler gefunden: 1. Gestern habe ich den SPI Bus 3 Stunden lang ohne Unterbrechung mit 12MHz 64B schreiben und die dann wieder lesen lassen. Das Gelesene stimmte immer mit dem Geschriebenen überein. 2. Eben ist mir aufgefallen, dass der vermeintliche Fehler auftaucht, wenn ich eine Nachricht an das USB-Dingsy schicke, für die bisher nur Platz im Ring-Buffer reserviert wurde, ohne dass die Nachricht schon über I2C komplett übermittelt worden ist (ich speicher die Nachricht immer erstmal im XRAM, so dass der SPI Bus burst-mäßig benutzt wird). Btw: Mein „Oszi“ kann nur 1MHz... grins Sorry für diesen Thread... :) Aber vllt hat ja jemand mal son ähnliches Problem... Bye Arne
Was hängt denn alles am selben SPI? Der SPI darf nur von einer Instanz zur Zeit benutzt werden. D.h. von /SS=0 bis /SS=1 eines Slaves ist der Bus für alle anderen Tasks tabu. Manche Speicher haben auch eine Zeitsperre, d.h. nach dem Write-Enable-Kommando muß das Schreiben innerhalb einer bestimmten Zeit abgeschlossen werden. Lange Interrupttätigkeit kann dann ein Überschreiten der Write-Enable-Zeit bewirken.
Peter D. schrieb: > Was hängt denn alles am selben SPI? > Der SPI darf nur von einer Instanz zur Zeit benutzt werden. > D.h. von /SS=0 bis /SS=1 eines Slaves ist der Bus für alle anderen Tasks > tabu. > 1. EFM8BB1 2. 23K256T 3. S25FL164K Ist /SS das Gleiche wie /CS resp. CS#? Jedenfalls gibt es nur einen „Thread“ innerhalb des EFM8BB1, der SPI macht. Die ISRs beauftragen nur SPI Transfers beim Haupt-Thread (also der Reset-ISR...). Peter D. schrieb: > Manche Speicher haben auch eine Zeitsperre, d.h. nach dem > Write-Enable-Kommando muß das Schreiben innerhalb einer bestimmten Zeit > abgeschlossen werden. Lange Interrupttätigkeit kann dann ein > Überschreiten der Write-Enable-Zeit bewirken. > Ich übertrage nur höchstens 64 Byte pro SPI Transaktion. Sie dauert bei 12M25Hz also weniger als 100usec, weil ich bestimmt eine kleine Pause zwischen den einzelnen Bytes habe. Dazwischen kommen folgende ISRs: 1. Uhr für Zeitstempel: <10Hz (also >100msec) 2. I2C: <2kHz (also >500usec) 3. mein Spezial-One-Wire: <10kHz (also >50usec) So ein Interrupt dauert schätzungsweise nicht länger als 40usec (1000 Takte), so dass eigentlich ein SPI-Transfer nicht länger als 100usec+5*40usec=300usec dauern kann. Ich glaube, dass der bislang nicht genutzte S25FL164K das WREN Bit erst nach dem Ende der Schreib-Transaktion oder auf besonderen „Antrag“ (04h) zurücksetzt. Oder zerstehe ich das falsch? Der 23K256T ist immer ohne Weiteres bereit geschrieben zu werden. -Arne
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.