ENC28J60 - sendet nichts

[Paketstapel (Gast)]

Hallo

Ich versuche seit einiger Zeit einen ENC28J60 davon zu überzeugen mit 
meinem Rechner zu reden... vergebens.

Zur Hardware:

Ein ATMega32 (interne 8Mhz), angeschlossen an den ENC28J60 (Revision B5, 
25Mhz Quarz), SPI per Software. Zwecks Debugging ein LCD angeschlossen

Die Software:

Zum größten Teil von Beitrag "ENC28J60 Basics[Beispielprogramm in AVRGCC für atmega8]" 
kopiert (Danke Nik!), ein paar Modifikationen um dem Errata zu 
entsprechen.

Zum Problem:

Das Ding sendet nichts! Mittlerweile empfängt er ARP-Pakete und zeigt 
die Quell-MAC und IP richtig an. Im Wireshark sehe ich die vom PC 
gesendeten Pakete, doch der Chip antwortet nie, obwohl er zur 
send-funktion kommt. Ich weiß mittlerweile echt nicht mehr weiter.

Code ist im Anhang, die wichtigsten Stellen hier nochmal als Auszug:

void InterruptHandler()
{
  unsigned length = enc28j60PacketReceive(sizeof(ethernet_buffer), ethernet_buffer);
  if (length)
  {
    struct Ethernet_Header *ether = (struct Ethernet_Header *)ethernet_buffer;
    if (ether->EnetPacketType == 0x0608) // ARP
    {
      struct ARP_Header *arp = (struct ARP_Header *)(ethernet_buffer + ARP_OFFSET);
      if (pos < 1)
        pos = 1;
      if (arp->ARP_Op == 0x0100)
      {
        if (ethernet_buffer[0] == 0xff && ethernet_buffer[1] == 0xff && ethernet_buffer[2] == 0xff &&
        ethernet_buffer[3] == 0xff && ethernet_buffer[4] == 0xff && ethernet_buffer[5] == 0xff &&
        equalmem(ethernet_buffer + 38, myip, 4)) // request to us
        {
          if (pos < 2)
            pos = 2;
          // ARP Request for us
          uint8_t remote_mac[6];
          uint8_t remote_ip[4];
          movemem(remote_mac, &ether->EnetPacketSrc, 6);
          movemem(remote_ip, &((struct ARP_Header *)(ethernet_buffer + ARP_OFFSET))->ARP_SIPAddr, 4);
          BuildEthernetFrame(ethernet_buffer, remote_mac);
          BuildARPReplyFrame(ethernet_buffer, remote_mac, remote_ip);

          enc28j60PacketSend(sizeof(struct Ethernet_Header) + sizeof(struct ARP_Header), ethernet_buffer); // <--- paket kommt nie an

MfG Paketstapel

[Paketstapel (Gast)]

Nachtrag:
Die Link-LED geht an, die beiden sind also Verbunden. Am TX-pin messe 
ich auch ein Signal, also irgentwas sendet er, nur kommt nix an.

[Juergen G. (jup)]

Hast Du schon mal an die Hardware gedacht?

MagJack ist der richtige?
MagJack kurz am ENC angebunden?
Alle 3.3V Spannungspins am ENC haben 3.3V, auch beim senden?

Der SW-Stack ist normalerweise erprobt und tut was er soll.

Ju

[Paketstapel (Gast)]

Hallo

MagJack müsste der richtige sein, viel näher dran geht es auch nicht 
mehr. Der Chip ist an allen VDD/VSS-paaren mit 100nF abgeblockt, VCC 
selber nochmal mit 200µF. Die Spannung ist an VDDTX/VSSTX auch schön 
stabil, nichts was den Chip zu solchen Fehlfunktionen bewegen könnte.

(Es ist übrigens Version B7, nicht B5. Dem Aufdruck nach sollte es B5 
sein aber das Register sagt B7)

Ich habe mal aus Spaß statt eine ARP-Antwort zu senden in einer 
Endlosschleife gesendet. Ergebnis war dass die Grüne LED (als TXRX 
konfiguriert) am blinken war, allerdings nur für ca. 1-2 Sekunden, 
danach war sie aus.

Als ich die Endlosschleife rausgenommen habe und mir mal NACH dem 
sendevorgang die Register EIR und ESTAT angeguckt habe, kam heraus dass 
in EIR kein Fehler angezeigt wird, es ist nur 0x08, also das "Transmit 
complete" Bit gesetzt, in ESTAT nur CLKRDY.

Die ganze Zeit läuft Wireshark mit und es kommt nichts vom Chip an.

[Juergen G. (jup)]

>viel näher dran geht es auch nicht mehr
Das ist schon richtig aber bedenke das das HF ist mit dem Du es zu tun 
hast und das was zum MagJack geht Stromausgaenge sind.
OK, ich kann mich irren, aber ich meine das die stehenden R's zwischen 
dem MagJack und dem ENC nicht unbedingt unter die Kategorie, HF Design 
fallen.

Wenn Dein ENC empfaengt und sendet, aber am PC nichts ankommt, heisst 
das fuer mich, dass der Strom oder die Amplitude der Frequenz zum 
Sende-Trafo zu gering sind.

Ju

[Sascha W. (sascha-w)]

Paketstapel schrieb:
> Die ganze Zeit läuft Wireshark mit und es kommt nichts vom Chip an.
wie ist dein Board mit dem Rechner verbunden?
Wenn du gar zu großen Mist sendest, und die beiden über einen Switch 
verbunden sind, könnte auch diese schon das Paket aussortieren.

Sascha

[Paketstapel (Gast)]

Sascha Weber schrieb:
> wie ist dein Board mit dem Rechner verbunden?
> Wenn du gar zu großen Mist sendest, und die beiden über einen Switch
> verbunden sind, könnte auch diese schon das Paket aussortieren.

Er ist über ein 1m Lankabel direkt mit der Netzwerkkarte meines Rechners 
verbunden. Ich habe auch mal die Onboardkarte getestet, in beiden Fällen 
das selbe Fehlerbild.

Juergen G. schrieb:
> Das ist schon richtig aber bedenke das das HF ist mit dem Du es zu tun
> hast und das was zum MagJack geht Stromausgaenge sind.
> OK, ich kann mich irren, aber ich meine das die stehenden R's zwischen
> dem MagJack und dem ENC nicht unbedingt unter die Kategorie, HF Design
> fallen.

Ich hab die beiden Leitungen (+/-) extra so eng wie es geht parallel 
nebeneinander zur Buchse laufen lassen. Als 50Ohm abschluss hab ich 2 
100Ohm parallel genommen um die Induktivität zu verringern. Und da er ja 
empfängt scheint die eine Seite ja zu funktionieren.

Juergen G. schrieb:
> Wenn Dein ENC empfaengt und sendet, aber am PC nichts ankommt, heisst
> das fuer mich, dass der Strom oder die Amplitude der Frequenz zum
> Sende-Trafo zu gering sind.

Anders kanns mittlerweile nicht mehr sein. Ich habe gestern Abend 
nochmal den Stack aus dem ersten Post (siehe link ganz oben) getestet, 
also die erste Revision. Der Stack empfing Pakete (und zwar richtige, IP 
und MAC stimmten), ging in die Senderoutine und die TXRX-LED leuchtete 
kurz auf. Es kann eigentlich nurnoch an der Hardware liegen. Ich werde 
das gleich mal untersuchen.

MfG Paketstapel

[Paketstapel (Gast)]

Nach nochmaligem Testen bin ich jetzt völlig Ratlos :(

Ich habe die MAC-Addresse des Chips mal statisch hinzugefügt, um ihn 
anpingen zu können. Jetzt kommen die Pingpakete zuverlässig an, aber er 
antwortet immernoch nichts. Habe auch mal auf Verdacht hin T+ und T- 
getauscht, kein unterschied. Am RX sieht man sehr schön das Ping-paket, 
DC-offset 1V und beim empfangen 1V Amplitude. Was mich etwas wundert ist 
dass der Linkimpuls auf der RX-Seite sehr sauber mit 1V Amplitude 
ankommt, auf Sendeseite aber nur 0,75V Amplitude hat.

[Juergen G. (jup)]

Wo misst Du denn die 1V oder 0,75V?

[Volker (Gast)]

Versuch doch mal dein Glück mit einer erprobten Software - z.B. 
ethersex.
So könntest du wenigstens einen Softwarefehler ausschliessen.

[Paketstapel (Gast)]

Habe die Verdrahtung nochmal ordentlich gemacht, in der Hoffnung dass es 
irgentwas bewirkt. Die Messung mit den 1V und 0.75V bitte ignorieren, 
das war ein Messfehler. Im Anhang einmal TX+ und TX-, jeweils direkt am 
Chip gemessen, beim senden einer ARP-Antwort (Auf die Mindestlänge von 
64 Byte erweitert). Das rauschen kommt von der etwas entfernten 
Masseklemme, direkt am Chip gemessen ist es deutlich besser.

Zusätzlich nochmal das mainfile, auf ein absolutes Minimum reduziert. 
Mit der LCD-ausgabe habe ich versucht zu debuggen was ankommt. An sich 
stimmt alles (Broadcast, quellmac, magicnumber für ARP, der ARP-Header, 
quellmac, zielmac, quellip, zielip). Sobald der Sendevorgang 
abgeschlossen ist, wird die Debug-LED (ein Pin am ATMega) gesetzt. Das 
passiert auch sehr zuverlässig.

Allerdings sehe ich nach wie vor keine Antwort in Wireshark. Während ich 
das schreibe blinkt ab und zu fröhlich die RXTX-Led am Magjack...

Bevor ich mich wieder durch ein komplett neuen Stack wühle will ich 
wenigstens mal eine Antwort vom Chip :( das kann doch nicht so schwer 
sein...

MfG ratloser Paketstapel

[Michael H. (michael_h45)]

Paketstapel schrieb:
> jeweils direkt am
> Chip gemessen

Miss das lieber mal hinter dem Übertrager. Du hast ziemlich sicher da 
einen Fehler.

[Juergen G. (jup)]

Michael H. schrieb:
> Miss das lieber mal hinter dem Übertrager. Du hast ziemlich sicher da
> einen Fehler.

So sehe ich das auch.
Am Chip messen bringt nur insofern etwas, das Du weisst er sendet was.

Ich sehe den Fehler
1. im Uebertrager(MagJack in Deinem Fall)
2. in der Stromversorgung des ENC

Klemm mal zwischen den Kontakten des RJ45 Stecker und MagJack ein Stueck 
Entloetlitze und messe da mal AC waehrend des sendens dann DC um die 
Polaritaet zu sehen.

PS:
hast Du ein Datenblatt von Deinem Magjack?

haeng mal an!

[Sascha W. (sascha-w)]

@Paketstapel

der Magjack sieht wie der von Pollin (450001) aus - den solltest du so 
wie im Anhang beschaltet haben!?

EDIT: im PDF nur S.1 + S.5 relevant

Sascha

[Paketstapel (Gast)]

Hallo :)

Nach längerer Pause melde ich mich mal wieder, die Idee mit dem 
Hardwarefehler war gut, ich habe alles nochmal getestet aber kein fail 
gefunden. Zwischen Ethernetbuchse und Kabel hab ich auch keine 
Entlötlitze bekommen ohne direkt alles kurzzuschließen. Ich habe aber 
mal alle Kabel und alle Netzwerkkarten durchprobiert.

Erstaunlicherweise hat es mit einem längeren Kabel und der 
Laptop-Netzwerkkarte teilweise funktioniert, der Code ist immernoch der 
aus dem letzten Post, also die Minimalversion die nur ARP beantwortet, 
zusammen mit dem enc28j60.c (rev 90). Diesmal beantwortet der Chip die 
ARP-Anfrage, aber um 1 Byte versetzt.

Wenn ich per

enc28j60PacketSend(64, ptr + 1);

Ein Byte überspringe kommt die ARP-Antwort erstaunlicherweise an und 
wird vom PC erkannt (und in die ARP-tabelle eingetragen).

Wo kommt dieser Byteoffset her???

MfG Paketstapel

[Juergen G. (jup)]

nimm mal diese Software, das ist der Webserver von Ulrich Radig leicht 
modifiziert.
Lauft definitiv auf einem Mega32A mit dem ENC.

Wenn Du and den Pins der Eingaenge oder Ausgaenge was anderes haengen 
hast, dann einfach im main.c die Pin Config auskommentieren.

Wenn das mal laeuft, kannst Du Dich ja in die Details haengen.

Ju

[... (Gast)]

Paketstapel schrieb:
> die Idee mit dem
> Hardwarefehler war gut,

Bisher haben wir noch keinen Stromlaufplan von dir gesehen....
Aber meine Glaskugel sagt mir du verwendest einen falschen Rbias.
Der sollte bei den z.Z. ausgelieferten ENC 2,32KOhm betragen. 1,5K und 
820 Ohm in Reihe.
Außerdem sollte der VCAP an Pin 1 , der 10µF, ein Typ mit geringem ESR 
sein. Am besten ein keramischer SMD-Typ.

[Paketstapel (Gast)]

Hallo

Mittlerweile hab ich das Ding zum laufen bekommen, aber ich bin mir 
nicht ganz sicher warum:

Die Software von Ulrich Radig hab ich getestet, jedoch funktioniert die 
auch nicht.

Nach langem suchen hat sich aber herausgestellt, dass der ENC28J60 das 
Controlbyte mit raussendet, das erklärt auch den Byteoffset.

Auszug:

// write per-packet control byte
uint8_t crtl = 0;
enc28j60WriteBuffer(1, &crtl);

// copy the packet into the transmit buffer
enc28j60WriteBuffer(len, packet);

Das funktioniert NICHT. Egal welchen Wert ich nehme, es wird immer mit 
übertragen und ist im Wireshark zu sehen (Ulrig Radig nimmt ebenfalls 
0). Wenn ich das einfach rausnehme und garkein Controlbyte schreibe 
klappt es problemlos (habe gestern mit einem Kumpel daraus ein kleines 
UDP-Terminal gebaut), ich kann das Ding auch anpingen, ARP funzt 
natürlich auch, alles.

Sehr seltsam

Was ist da los? Schon wieder ein Fehler in der Software? Bug im enc 
selber?

... schrieb:
> Aber meine Glaskugel sagt mir du verwendest einen falschen Rbias.

Ich hab extra einen 2.32kOhm 1% Widerstand dafür bestellt ;)
Die Hardware dürfte also so weit in Ordnung sein, es lag nur an dem 
Controlbyte. Die Frage ist nur, warum?

[Georg G. (df2au)]

Paketstapel schrieb:
> Die Software von Ulrich Radig hab ich getestet, jedoch funktioniert die
> auch nicht.

Die UR-Soft ist nicht ohne Ecken und Kanten, läuft aber hinreichend gut 
in Dutzenden von Geräten.


> Nach langem suchen hat sich aber herausgestellt, dass der ENC28J60 das
> Controlbyte mit raussendet, das erklärt auch den Byteoffset.

Dann setzt du entweder das Controlbyte doppelt oder ein Pointer, Zähler, 
xxx sitzt falsch. Der ENC braucht das Controlbyte. Und mit "NULL" ist es 
sehr gut vorbelegt - dann gelten für alle Pakete die gleichen 
Bedingungen.

[Paketstapel (Gast)]

Originalauszug aus der im moment funktionierenden enc28j60.c:

unsigned char SoftwareSPI(unsigned char in)
{
  unsigned char data = 0;
  for (unsigned i = 0; i < 8; ++i)
  {
    // write
    if (in & 128)
      ENC28J60_SPI_PORT |= (1 << ENC28J60_SPI_MOSI);
    else
      ENC28J60_SPI_PORT &= ~(1 << ENC28J60_SPI_MOSI);
    in <<= 1;

    _delay_us(3);
    // read
    data <<= 1;
    if (ENC28J60_SPI_PIN & (1 << ENC28J60_SPI_MISO))
      data |= 1;

    // clock
    ENC28J60_SPI_PORT |= (1 << ENC28J60_SPI_SCK);
    // clock low
    ENC28J60_SPI_PORT &= ~(1 << ENC28J60_SPI_SCK);
  }
  return data;
}

void enc28j60WriteBuffer(unsigned int len, unsigned char* data)
{
  // assert CS
  ENC28J60_CONTROL_PORT &= ~(1<<ENC28J60_CONTROL_CS);
  
  // issue write command
  SoftwareSPI(ENC28J60_WRITE_BUF_MEM);

  while(len--)
    SoftwareSPI(*data++);

  // release CS
  ENC28J60_CONTROL_PORT |= (1<<ENC28J60_CONTROL_CS);
}

void enc28j60PacketSend(unsigned int len, unsigned char* packet)
{ 
  if (enc28j60Read(EIR) & EIR_TXERIF)
  {
    //Errata: Transmit Logic reset
    enc28j60WriteOp(ENC28J60_BIT_FIELD_SET, ECON1, ECON1_TXRST);
    enc28j60WriteOp(ENC28J60_BIT_FIELD_CLR, ECON1, ECON1_TXRST);
  }
  // Set the write pointer to start of transmit buffer area
  enc28j60Write(EWRPTL, TXSTART_INIT && 0xff);
  enc28j60Write(EWRPTH, TXSTART_INIT >> 8);
  // Set the TXND pointer to correspond to the packet size given
  enc28j60Write(ETXNDL, (TXSTART_INIT+len) & 0xff);
  enc28j60Write(ETXNDH, (TXSTART_INIT+len) >> 8);

  // copy the packet into the transmit buffer
  enc28j60WriteBuffer(len, packet);
  
  // send the contents of the transmit buffer onto the network
  enc28j60WriteOp(ENC28J60_BIT_FIELD_SET, ECON1, ECON1_TXRTS);
}

Hab ich das Controlbyte übersehen? Auf jedenfall funktioniert der Code 
im Moment.

[Simon K. (simon)]

Hast du bei "SoftwareSPI" auch den richtigen SPI-Modus in Verwendung? 
Wie sieht das aus mit Pause nach/vor CS setzen/releasen?

Ansonsten wüsste ich da auch gerade nicht weiter. Hab aber auch gerade 
keine Zeit dafür.

[Paketstapel (Gast)]

Simon K. schrieb:
> Hast du bei "SoftwareSPI" auch den richtigen SPI-Modus in Verwendung?

Was heißt richtigen SPI-Modus? Aufgrund der Verdrahtung nutze ich das 
Hardwaremodul nicht sondern setze Daten und Takt manuell (in Software 
halt).
Ich lege mein Bit an und lese das vom Chip aus, danach takte ich einmal. 
Wenn die SPI-Funktion nicht funkionieren würde würde ja jede 
Kommunikation mit dem Chip fehlschlagen, daran kann es also nicht 
liegen.

Wie wahrscheinlich ist ein Bug im ENC ? Ist ja nicht grade Bugfrei das 
Teil

[Michael L. (michaelx)]

Paketstapel schrieb:
> Was heißt richtigen SPI-Modus? Aufgrund der Verdrahtung nutze ich das
> Hardwaremodul nicht sondern setze Daten und Takt manuell (in Software
> halt).
> Ich lege mein Bit an und lese das vom Chip aus, danach takte ich einmal.

Wenn du das genau so machst, dann ist das definitiv falsch! Das Bit vom 
ENC kannst du erst nach dem Takt lesen.

[Simon K. (simon)]

Paketstapel schrieb:
> Simon K. schrieb:
>> Hast du bei "SoftwareSPI" auch den richtigen SPI-Modus in Verwendung?
>
> Was heißt richtigen SPI-Modus? Aufgrund der Verdrahtung nutze ich das
> Hardwaremodul nicht sondern setze Daten und Takt manuell (in Software
> halt).
> Ich lege mein Bit an und lese das vom Chip aus, danach takte ich einmal.
> Wenn die SPI-Funktion nicht funkionieren würde würde ja jede
> Kommunikation mit dem Chip fehlschlagen, daran kann es also nicht
> liegen.
Du bist aber ganz schön mutig im Ausschließen von Fehlern!

http://de.wikipedia.org/wiki/Serial_Peripheral_Interface#Protokollablauf_und_Einstellm.C3.B6glichkeiten

> Wie wahrscheinlich ist ein Bug im ENC ? Ist ja nicht grade Bugfrei das
> Teil
Unwahrscheinlich.

[Georg G. (df2au)]

Paketstapel schrieb:
> Wie wahrscheinlich ist ein Bug im ENC ? Ist ja nicht grade Bugfrei das
> Teil

Die Soft von UR funktioniert bei n+1 Leuten ohne Probleme. Bei dir 
funktioniert sie nicht.
Wie wahrscheinlich ist es dann, dass ein Bug im ENC für das Problem 
verantwortlich ist?

Zumindest hast du ein gesundes Selbstvertrauen. Du solltest Chef werden 
:-)

[Paketstapel (Gast)]

Ich habe Tage verbracht den Bug in der Software und der Hardware zu 
suchen. Jetzt ist es umgekehrt, es funktioniert und die Frage ist, warum 
funktioniert es obwohl es das eigentlich nicht sollte?

Um ein UDP-Packet komplett richtig zu lesen müssen hunderte Bits gelesen 
werden, wenn in der SPI-Routine auch nur ein kleiner Fehler wäre würde 
es nicht funktionieren. Warum klappt der Rest fehlerfrei aber dieses 
eine Controlbyte nicht? Daher nehme ich mal ganz mutig an, dass der Bug 
nicht im SPI-Teil liegt ;)

[Maxx (Gast)]

Paketstapel schrieb:
> wenn in der SPI-Routine auch nur ein kleiner Fehler wäre würde
> es nicht funktionieren.

Nein.
Es kann durchaus passieren, dass der Fehler eher zufällig aussieht.
Kommt halt ganz auf Timings und Bitfolgen an, wie er durchscheint.

Stell dir mal die Fragen:
Wann erwartet der ENC die Daten stabil auf der MOSI Leitung?
Wann sind die Daten auf der MISO stabil?
Was passiert, wenn du jeweils zur falschen Zeit den Pegel setzt/prüfst? 
Gibt es dann eine generellen Fehler, oder kannst du es gar nicht sagen? 
Spielen dann Zeitkonstanten in der Hardware oder minimale Unterschiede 
in der Softwaregeschwindigkeit (IRQ Zeitpunkte, etc) zu 
unterscheidlichen Fehlerbildern?

[Paketstapel (Gast)]

Maxx schrieb:
> Nein.
> Es kann durchaus passieren, dass der Fehler eher zufällig aussieht.
> Kommt halt ganz auf Timings und Bitfolgen an, wie er durchscheint.

Wie erklärst du dann dass das Controlbyte vor das Paket kommt? Ich hab 
schon mehrere Werte für das Byte durchprobiert, jedesmal wurde genau 
dieses eine Byte in Wireshark als erstes Byte angezeigt, mit einem 
Timingfehler ist das nicht zu erklären. So einen Fehler kann man nur 
durch 2 Szenarien erklären, das Byte wird doppelt gesendet oder ein 
interner Pointer steht ein Byte zu wenig.

Realistisch gesehen, wie wahrscheinlich ist es dass durch ein 
Timingfehler das Byte doppelt gesendet wird, wenn alle anderen Bytes 
normal ankommen?

Ein Kumpel hat ebenfalls einen ENC bestellt, er will diese Woche das 
Ding mal in Betrieb nehmen. Das wird interessant :)

Ich sehe mittlerweile keine andere Möglichkeit mehr, aber ich wäre froh 
wenn der Fehler bei mir liegt, dann kann ich zumindest dem Chip wieder 
trauen ;)

[Maxx (Gast)]

Paketstapel schrieb:
> Wie erklärst du dann dass das Controlbyte vor das Paket kommt?

Da gibt es eine Reihe Möglichkeiten. Was macht der ENC, wenn dein Paket 
nicht vollständig gefüttert wurde/die SPI Übertragung in einen 
undefinierten Zustand endet?

Es ist doch jetzt nicht so schwer das zu prüfen. Datenblatt und checken 
ob dein SPI Modus stimmt.

[Juergen G. (jup)]

Hol Dir erst mal ne Tasse Caffe uns schau in eine andere Richtung als 
Dein Bildschirm.

Mir geht es auch manchmal so, dass ich den Wald vor lauter Baeumen nicht 
mehr sehe.
Da schiessen einem die veruecktesten Dinge durch den Kopf.

Ich geh dann mit meinem Hund spazieren und wenn ich zurueck komme seh 
ich das der Fehler bei mir lag und eigentlich ganz simpel ist.

[Paketstapel (Gast)]

Juergen G. schrieb:
> Ich geh dann mit meinem Hund spazieren und wenn ich zurueck komme seh
> ich das der Fehler bei mir lag und eigentlich ganz simpel ist.

Nichts lieber als das, aber ich kann bei solchen Problemen schlecht 
abschalten :( Da komm ich mental nicht von weg.

Laut Datenblatt sampled der Chip die Daten auf MOSI wenn der Takt HIGH 
wird und liefert wiederrum seine Daten auf MISO wenn der Takt LOW wird. 
Also lege ich meine Daten an und lese gleichzeitig ein, danach takte ich 
kurz HIGH. Die SoftwareSPI liest somit 1 Byte ein und schreibt 
gleichzeitig 1 Byte. Da der Chip aber erst auf anfrage antwortet (also 
das erste Byte eh verworfen wird) sind die Daten gültig.

[Juergen G. (jup)]

Paketstapel schrieb:
>Da komm ich mental nicht von weg.

Da genau liegt der Hase im Pfeffer. Du musst mental weg davon.
Im Hinterkopf arbeitet das Problem weiter und es wird rational 
verarbeitet.



Paketstapel schrieb:
> Also lege ich meine Daten an und lese gleichzeitig ein, danach takte ich
> kurz HIGH.

Das musst Du uns mal erklaeren wie Du "lege ich meine Daten an und lese 
gleichzeitig ein" machst.

bei meinen MCU's sind das ein paar Instruktionen in Sequenz.

bin jetzt nicht auf dem Laufenden.
Hast Du uns schon Deine SoftSPI gezeigt?

[Juergen G. (jup)]

Juergen G. schrieb:
> Hast Du uns schon Deine SoftSPI gezeigt?

Ich zitier mich mal selbst.

hab Deine SPI routine gefunden.

Allerdings ist die nicht in Uebereinklang zu bringen mit dem
was Das Datenblatt sagt und Du selbst schreibst.


>Laut Datenblatt sampled der Chip die Daten auf MOSI wenn der Takt HIGH
>wird und liefert wiederrum seine Daten auf MISO wenn der Takt LOW wird.

Du schreibst aber, liest dann und wackelst am Schluss erst mit dem 
Clock.

meiner Meinung sollte es

Bit schreiben
Clock High
Clock Low
Bit lesen

sein

[eProfi (Gast)]

enc28j60Write(EWRPTL, TXSTART_INIT && 0xff);
  enc28j60Write(EWRPTH, TXSTART_INIT >> 8);
  // Set the TXND pointer to correspond to the packet size given
  enc28j60Write(ETXNDL, (TXSTART_INIT+len) & 0xff);
  enc28j60Write(ETXNDH, (TXSTART_INIT+len) >> 8);


Vergleiche nochmal die 1. mit der 4. Zeile.

[eProfi (Gast)]

Schau Dir mal meine Treiberversion an, da habe ich einiges optimiert:
Beitrag "ENC28J60 correct value of PHLCON and mirrored registers"

Es gibt sogar weitere Verbesserungen, aber die sind noch nicht 
veröffentlicht.

[Paketstapel (Gast)]

eProfi schrieb:
> enc28j60Write(EWRPTL, TXSTART_INIT && 0xff);
>   enc28j60Write(EWRPTH, TXSTART_INIT >> 8);
>   // Set the TXND pointer to correspond to the packet size given
>   enc28j60Write(ETXNDL, (TXSTART_INIT+len) & 0xff);
>   enc28j60Write(ETXNDH, (TXSTART_INIT+len) >> 8);
>
>
> Vergleiche nochmal die 1. mit der 4. Zeile.

Dieser epische Moment wenn man die Zeilen vergleicht, das nicht glaubt, 
nochmal hinguckt und es langsam realisiert... Aua... nun, damit kann ich 
zumindest dem Chip wieder vertrauen :) Ich will nicht die Stunden 
aufaddieren die ich an diesem einen Bug schon saß... Aua²

Es funktioniert jetzt auch mit dem Controlbyte.

@SPI:

Juergen G. schrieb:
> Bit schreiben
> Clock High
> Clock Low
> Bit lesen

Wenn die Clock LOW geht legt der Chip das Bit an, aber das neue. Aus dem 
Timingdiagram geht hervor, das noch vor dem ersten Clock-LOW ein 
gültiges Bit anliegt, nämlich das was beim letzten Clock-LOW ein Byte 
vorher angefallen ist.

Bsp:
Man überträgt ein Byte und liest im Anschluss ein Byte. Dazu taktet man 
die Daten ganz normal nach dem Schema {Daten anlegen, Clock HIGH, Clock 
LOW} in den Chip. Da man beim ersten Byte noch nicht liest, kann man das 
auslesen sparen, bzw es hat keinen Effekt. Sobald das letzte Bit 
gesendet ist (und die Clock noch HIGH ist), hat der Chip das Byte fertig 
empfangen und fängt jetzt an zu senden. Wenn der Hostcontroller die 
Clock auf LOW setzt (und damit eine SoftwareSPI-Routine abgeschlossen 
ist) legt der ENC das erste Bit an. Da die Routine schon 8 Bit gesendet 
hat ist sie fertig und springt zurück. Das Bit bleibt aber gesetzt bis 
die Clock-Leitung erneut fällt.

Um Dieses Bit jetzt abzuholen muss ich vor der nächsten fallenden 
Clock-flanke lesen, würde ich danach lesen würde ich das Bit verpassen 
und das nächste abholen. Daher lese ich direkt bevor ich takte. Der 
erste Aufruf von SoftwareSPI schickt das Byte und veranlasst den 
Controller das erste Bit schonmal anzulegen, der nächste Aufruf holt es 
dann ab. Da der Controller nur auf Anfrage antwortet wird ein 
SPI-vorgang der lesen soll immer diesen Zustand vorfinden, ihm ist ein 
SPI-schreibbefehl vorausgegangen.

Danke an alle die geholfen haben, besonders eProfi. Da ich eine andere 
SPI-Routine hatte habe ich die anderen Stacks nicht per c'n'p eingefügt 
sondern abgetippt... Grmpf!

MfG Paketstapel

[Michael H. (michael_h45)]

Paketstapel schrieb:
> Wie wahrscheinlich ist ein Bug im ENC ? Ist ja nicht grade Bugfrei das
> Teil

Paketstapel schrieb:
> Ich sehe mittlerweile keine andere Möglichkeit mehr, aber ich wäre froh
> wenn der Fehler bei mir liegt, dann kann ich zumindest dem Chip wieder
> trauen ;)

junge, runter von deinem ross...
du kriegst n 10er von mir, wenn das n fehler im enc ist...

[Paketstapel (Gast)]

Michael H. schrieb:
> junge, runter von deinem ross...
> du kriegst n 10er von mir, wenn das n fehler im enc ist...

Verglichen am Errata haben da schon eine menge Leute 10er bekommen ;) In 
allen Threads liest man dies und das funktioniert nicht, hätte ja sein 
können  dass da nochwas ist

[Michael H. (michael_h45)]

ja, in deinem thread liest man auch "das und das geht nicht". heißt noch 
lange nicht, dass es nicht am TO liegt...

[Simon K. (simon)]

Paketstapel schrieb:
> Michael H. schrieb:
>> junge, runter von deinem ross...
>> du kriegst n 10er von mir, wenn das n fehler im enc ist...
>
> Verglichen am Errata haben da schon eine menge Leute 10er bekommen ;) In
> allen Threads liest man dies und das funktioniert nicht, hätte ja sein
> können  dass da nochwas ist

Ich glaube du überschätzt das etwas. Soweit ich weiß ist im ENC28J60 
kein wirklich ernsthafter Bug drin, der einem das Leben jetzt schwer 
macht. Das Ärgerlichste, an das ich mich erinnere war, dass die 
Checksummenerzeugung, die man beim Paketversand wählen konnte dafür 
gesorgt hat, dass mal Pakete im Empfang verloren gingen, weil es da 
irgendwelche DMA Konflikte gab.