ENC28J60 hänger sig

[Rick81]

Har kopplat en Microchip ENC28J60 via SPI till PIC18 och STM32 och har fått problem med att den hänger sig när man skickar en större mängd data ca > 1000 kB (men data är betydligt mindre än TX buffrar). Data skickas korrekt men sen hänger den sig. Med hänger sig så menas att det inte längre går att läsa ut data som har skickats till den. Om jag beordar en ominitiering där MAC och register resettas över SPI så fungerar den igen. Det är alltså inte PIC18 eller STM32 som hänger sig utan själva ENC28J60.

Det händer även att den gå in i detta läge ibland utan att jag kan förklara varför. Även om buffrarna blir fulla så borde den inte totalhänga sig.

Är det någon som också fått detta problem och har någon bra ide hur man får den stabil?

[blueint]

Finns bättre kretsar:
http://elektronikforumet.com/wiki/index ... erienheter

[Rick81]

Det var inte andra kretsar jag frågade efter. Och vad säger att inte de också hänger sig...

[sodjan]

Sidan blueint länkar till ser lite oseriös ut med lite väl svepande
formuleringar utan grund. Det är klart att en ENC28J60 "fungerar"
med sina eventuella fel och brister som sannolikt även de andra har.

Ditt problem går nog inte att svara på den knapphändiga informationen.
Det behöver sannolikt debuggas i den verkliga miljön med lämpliga verktyg.
Alternativt försöka på Microchips eget forum, då får du world-wide stöd.

[limpan4all]

Vi drabbades av detta problem för en 5-6 år sedan, efter 4 manmånaders felsökning så gav vi upp och slängde ut skiten.
Konstruerade om 3 kort och det var ett mycket sunt beslut, fick dessutom 100Mbit/s "på köpet".

[Walle]

Sidan blueint länkar till ser lite oseriös ut med lite väl svepande
formuleringar utan grund. Det är klart att en ENC28J60 "fungerar"
med sina eventuella fel och brister som sannolikt även de andra har.

Instämmer, fast jag tycker du var lite väl snäll. I mitt tycke är den wiki-sidan helt värdelös, just för att det inte finns några referenser. Hur vet vi att de/den som har skrivit på den sidan inte är helt inkompetenta och anser att kretsarna fungerar dåligt bara för att det har programmerats fel?

För att inte förstöra den här tråden så kan de som är intresserade diskutera vidare på den aktuella wiki-sidans diskussionssida.

[blueint]

Vill nog dock tillägga att kommentarerna på wikisidan kommer allihop då de specifika kretsarna diskuterats på EF. Refenser finns i wikikoden så de kan letas fram vid behov. De flesta är gjorda av gamla EF rävar så det är inte helt taget ur luften.

[calmar]

Glöm inte att spana in erratan.

[AndLi]

Walle: Såklart du inte kan veta, men så är det ju med all info på internet och detta forum. Vi kanske ska börja med referenskrav på allt vi säger?

chip select trasig -> http://elektronikforumet.com/forum/view ... 2&p=741570

[Walle]

AndLi: Nej, det tycker jag inte, men just på dylika wiki-sidor bör det finnas referenser. I forumet är det anorlunda, om jag påstår att något är värdelöst så kan ni fråga mig varför jag tycker så. Det går inte riktigt på en wiki.

[Rick81]

Den erratan gav inte det mest förtroendegivande intrycket. Måste varit en praktikant som designade ENC28J60

Den "buggen" som verkar ge mina symptom verkar kunna lösas genom att aldrig sätta nextpacketpekare till jämna värden, vilket i sig är en spännande bugg. Ska testa att göra en fix för detta.

[blueint]

Då förlorar man hälften av buffertkapaciteten?

[Icecap]

ENC28J60 är ju ganska ökänd för sin dåliga funktion och har varit det länga. Vad jag vet har Microchip gjort ett program (till PIC) som överbryggar alla (eller de flesta?) problem med den krets men det vore nog ganska mycket bättre att välja en annan krets med färre sjukdomar. Kretsen är rakt av dålig vilket rätt tydligt framgår av dess errata.

[Rick81]

Testade koden:

Kod: Markera allt

unsigned int enc28j60PacketReceive(unsigned int maxlen, unsigned char* packet)
.
.
.
	// Försök med bugfix på RX buffer
	
	if((NextPacketPtr & 1) == 0)	// Kolla om NextPacketPtr är jämn!
	{
		UART_PutString("NextPacketPtr jamn: ");
		sprintf(string, "0x%X\r\n", NextPacketPtr);
		UART_PutString(string);

		// Jämnt värde, specialkod!
		//if (NextPacketPtr == ERXST)
		if(NextPacketPtr == RXSTART_INIT)
		{
			UART_PutString("ERXRDPT = ERXND\r\n");
			//ERXRDPT = ERXND;
			enc28j60Write(ERXRDPTL, RXSTOP_INIT&0xFF);
			enc28j60Write(ERXRDPTH, RXSTOP_INIT>>8);
		}
		else
		{
			//ERXRDPT = NextPacketPtr – 1;
			UART_PutString("ERXRDPT = NextPacketPtr - 1\r\n");
			enc28j60Write(ERXRDPTL, (NextPacketPtr - 1)&0xFF);
			enc28j60Write(ERXRDPTH, (NextPacketPtr - 1)>>8);
		}
	}
	else
	{
		// Udda värde, kör som vanligt
		enc28j60Write(ERXRDPTL, (NextPacketPtr)&0xFF);
		enc28j60Write(ERXRDPTH, (NextPacketPtr)>>8);
	}
	// slut på bug fix

	// Orignal koden
	// Move the RX read pointer to the start of the next received packet
	// This frees the memory we just read out
	//enc28j60Write(ERXRDPTL, (NextPacketPtr)&0xFF);
	//enc28j60Write(ERXRDPTH, (NextPacketPtr)>>8);
	// Slut orignalkoden

Och denna koden i sig löste inte problemet men med denna koden så återställer sig enc28j60 om man läser ut macaddressen (testade detta för att se att inte MAC ballat ur enligt annan bugg):

Kod: Markera allt

	sprintf(string, "MAADR5 = 0x%x\r\n", enc28j60Read(MAADR5));
	UART_PutString(string);
	sprintf(string, "MAADR4 = 0x%x\r\n", enc28j60Read(MAADR4));
	UART_PutString(string);
	sprintf(string, "MAADR3 = 0x%x\r\n", enc28j60Read(MAADR3));
	UART_PutString(string);
	sprintf(string, "MAADR2 = 0x%x\r\n", enc28j60Read(MAADR2));
	UART_PutString(string);
	sprintf(string, "MAADR1 = 0x%x\r\n", enc28j60Read(MAADR1));
	UART_PutString(string);
	sprintf(string, "MAADR0 = 0x%x\r\n", enc28j60Read(MAADR0));
	UART_PutString(string);

Jag fattar verkligen inte hur denna krets fungerar....kan nog instämma med övrig förslag att enc28j60 bör undvikas. Fast jag ger inte upp så lätt.

[Rick81]

Hahah vilken mongokrets!

Moddade koden så att:

Kod: Markera allt

	//ERXRDPT = NextPacketPtr – 1;
	DebugUARTString("ERXRDPT = NextPacketPtr - 1\r\n");
	enc28j60Write(ERXRDPTL, (NextPacketPtr - 1)&0xFF);
	enc28j60Write(ERXRDPTH, (NextPacketPtr - 1)>>8);
	readMac = true;	// Ingen aning om varför man måste läsa mac för att slippa hängning...

och

Kod: Markera allt

unsigned int enc28j60PacketReceive(unsigned int maxlen, unsigned char* packet)
{
	unsigned int rxstat;
	unsigned int len;
	
	if(readMac == true)
	{
			sprintf(string, "Read MAADR5 = 0x%x\r\n", enc28j60Read(MAADR5));
   			DebugUARTString(string);
			readMac = false;
	}

och nu har den än så länge varit stabil....