Pic18F USB kommt nicht mehr hoch

[Thomas]

Hallo Mitstreiter

Ich hab hier ein sporadisch auftretendes Problem, welches sich bisher nur durch neu Flashen beheben läßt. Zuerst aber mal was zu meinen Umgebungsbedingungen.

Ich hab einen PIC18F4553, der über USB verschiedene Daten (Analogwerte, Digitale I/Os) an einen PC liefert.
Ich benutze den USB Stack von MC in Version 2.2, den ich zuerst auf dem DemoBoard und nun auf meinem Controller nutze. Was ich mit übernommen habe sind die LEDs, die mir den USB Bus Status anzeigen (sind ja in den Demoapplikationen für das DemoBoard auch mit dabei)

Nun ist es an einigen Leiterplatten schon ein paar mal aufgetreten, dass der Controller nicht mehr erkannt wird, wenn er in den PC gestöpselt wird (USB HID-Applikation). Eine genauere Analyse ergab, dass der USB im sogenannten POWERED_STATE hängt (Nur eine LED leuchtet) und nicht weiter läuft, wenn man ihn ansteckt. Nach der Recherche wann dieser Status eintritt ist mir folgendes Codeschnipsel aufegefallen:

Code:

void USBDeviceTasks(void)
{
....diverser Code....

    if(USBDeviceState == ATTACHED_STATE)
    {
        /*
         * After enabling the USB module, it takes some time for the
         * voltage on the D+ or D- line to rise high enough to get out
         * of the SE0 condition. The USB Reset interrupt should not be
         * unmasked until the SE0 condition is cleared. This helps
         * prevent the firmware from misinterpreting this unique event
         * as a USB bus reset from the USB host.
         */

        if(!USBSE0Event)
        {
            USBClearInterruptRegister(U1IR);// Clear all USB interrupts
            U1IE=0;                        // Mask all USB interrupts
            USBResetIE = 1;             // Unmask RESET interrupt
            USBIdleIE = 1;             // Unmask IDLE interrupt
            USBDeviceState = POWERED_STATE;
        }
    }

....diverser Code....
}

Dieses Codeschnipsel ist die einzige Stelle, die den POWERED_STATE bedient. (Ich habe im gesamten Code von mir keine andere Stelle gefunden.)
Wenn dieses Problem nun auftritt dann kann man den Controller nur durch neu flashen wieder zum laufen bringen.

Das SE0 bit wird ja durch den Transceiver im USB Configuration Register gesetzt. Kann es theoretisch möglich sein, dass der Controller, respektive der Transceiver durch äußere Einflüsse (EMV auf Kabel, oder durch andere magnetische Störungen) derart durcheinander gebracht wird, dass der Controller nicht mehr anläuft? Gibt es noch andere Punkte, wo ich mit der Fehlersuche ansetzen kann? Ist diese Stelle überhaupt der richtige Ansatz?

Ich bin über jede Antwort und Hilfestellung dankbar.


Grüße
Daimonion

[Coltfisch]

Hallo,

wenn der PIC im POWERED_STATE festhängt, dann kann es nicht an der SE0 condition liegen, denn in den POWERED_STATE gelangt der PIC nur, wenn die SE0 condition nicht mehr besteht.
Im POWERED_STATE wartet der PIC auf das Bus Reset Event, um danach in den DEFAULT_STATE zu wechseln.
Das Problem ist also, dass kein Bus Reset gesendet bzw. empfangen wird. Woran das liegt, kann ich Dir so pauschal aber auch nicht sagen. Sogar ein Hardwareproblem ist hier denkbar.

Wie sieht Deine Taktversorgung aus?
Wenn es sich um ein selbstgebautes Board handelt, gibt es einen Schaltplan/Layout?
Verwendest Du den USB-Stack pollend oder per Interrupt?
Ich glaube die aktuelle USB Stack version ist mindestens 2.4, vielleicht solltest Du mal updaten?

Gruß
Daniel

[Thomas]

Hallo und danke für deine Antwort.

Du hast recht. Ich vergess immer das "!" in dem Code reinzuinterpretieren Wenn ich die States als Stufen ansehe (was ja glaub ich auch so gedacht ist) dann macht das durchaus Sinn.

Nun gut, ich versuch dir mal die Fragen zu beantworten.

Als taktversorgung hab ich einen 20 MHZ Quartz Oszillator:
Configuration bits sind wie folgt:

Code:

#pragma config PLLDIV   = 5         // (20 MHz crystal)
#pragma config CPUDIV   = OSC1_PLL2   
#pragma config USBDIV   = 2         // Clock source from 96MHz PLL/2
#pragma config FOSC     = HSPLL_HS

Es ist ein selbstgebautes Board und es gibt auch einen Schaltplan bzw ein Layout. Nur muß ich da erst nachfragen ob ich das rausgeben darf!

Weiterhin nutze ich glaub ich den USB-Stack Pollend

Code:

usb_config.h:

#define USB_POLLING

Welche Unterschiede existieren denn in den Laufzeiten zwischen den Polling Mode und dem Interrupt mode? Wie aktiviere ich den InterruptMode und was müßte dann noch geändert werden?

Updaten will ich den Stack auch nicht, da ich der Meinung bin, dass das zum einen wieder ewig dauert, bis das alles passt und dadurch auch wieder unvorhergesehenes Eintreffen kann. In der freien Wirtschaft dreht es sich ja auch immer ein wenig ums Geld...

Mittlerweile hab ich das defekte Board auch auf meinem Schreibttisch. Ich hab dann mal spaßeshalber, den code ausgelesen (war zum Glück noch der Stand vor dem Copy Prtection) und hab den kompletten Code auf ein anderes Board gespielt. Dieses hat dann genau das selbe Fehlverhalten aufgezeigt. D.h. für mich, das das Problem irgendwie mit sich verändernder Software zu tun hat. Wie gut ist denn so ein QFN Pic18F4553 bzw. dessen FlashRom vor magnetischen Einflüssen und EMV geschützt? Direkt schräg über diesen Pic ist ein Hall Effekt Joystick. Könnte der da mit eine Rolle spielen? Außerdem wird das Gerät in einer rauen Bedingung (Industrie) eingesetzt wo durch Schritt- und Servomotoren doch ein wenig EMV da ist... Wie empfindlich ist der Pic denn da?

Danke für eure Antworten

[Thomas]

Hallo Leute 

Wie ihr unschwer an dem Smiley neben der Überschrift erkennen könnt, bin ich total Happy, den Fehler gefunden zu haben. (der Fehler ist zwar die Ursache für das hängen bleiben, doch leider noch nicht die Herkunft des Fehlers)

Zur Erklärung.

Zur Überprüfung der Pics kann ich vom PC aus eine Zahl (Seriennummer) in den EEPROM schreiben. Wenn ein Gerät nun zurück kommt, kann ich dann natürlich auch prüfen welche Seriennummer dieses Gerät hat.

Die Seriennummer umfasst 13 Stellen und beginnt am ersten Byte des EEPROM.

Code:

snblock[0] = ReceivedDataBuffer[1];
snblock[1] = ReceivedDataBuffer[2];
snblock[2] = ReceivedDataBuffer[3];
snblock[3] = ReceivedDataBuffer[4];
snblock[4] = ReceivedDataBuffer[5];
snblock[5] = ReceivedDataBuffer[6];
snblock[6] = ReceivedDataBuffer[7];
snblock[7] = ReceivedDataBuffer[8];
snblock[8] = ReceivedDataBuffer[9];
snblock[9] = ReceivedDataBuffer[10];
snblock[10] = ReceivedDataBuffer[11];
snblock[11] = ReceivedDataBuffer[12];
//Schreibe Daten in EEProm
eeWriteBlock(0x0,snblock,SN_LENGTH);

Normalerweise steht an der ersten Stelle, also im ersten Byte entweder eine 1 oder eine 0, also eine 0x30 oder eine 0x31.

Wenn ich nun aber dort eine 0x00 reinschreibe oder wenn diese aus irgendwelchen, noch nicht nachvollziehbaren Gründen reingeschrieben wird, dann zeigt der Pic genau das verhalten, welches ich oben beschrieben habe.

Nun meine Fragen an euch:

Wieso bockt der Pic wenn ich im ersten Byte eine 0x00 stehen habe. Meine EEPROM schreib und Lesebefehle werden nur auf Geheiß des PC ausgeführt. (case anweisung) Kann es ein Bufferoverflow sein oder was kann mir da noch dazwischenfunken?


Danke für eure Antworten.

[Coltfisch]

Nach dem Beschreiben des EEPROMs mit dieser 0 an der ersten EEPROM-Zelle wird der PIC also bei erneutem Anstöpseln nicht mehr vom Betriebssystem erkannt? Du willst damit sagen, dass Du die USB-Funktionalität gezielt durch das Beschreiben des EEPROMs außer Gefecht setzen kannst!?
Und dies ist auch reproduzierbar?

Tja, dann geht wohl 1.) etwas beim Beschreiben des EEPROMs schief oder 2.) der Inhalt des EEPROMs hat für die Ausführung der Controllerfirmware eine größere Bedeutung, als Du bisher erläutert hast.
Beides - ohne weiteren Code zu sehen - schwierig zu analysieren.

[AndreW]

Mal ein Schuss ins Blaue - du verwendest doch die Firmware von MC für den USB Teil? - verwendest du auch durch Zufall den Bootloader von MC? - bin mir jetzt nicht sicher ob der durch das 0. Byte im EEprom oder das 255. Byte im Eeprom aktiviert wurde. Das würde eventuell das Verhalten erklären, das die Hardware dann den Bootloader aktiviert und so nicht mehr als das Gerät erkannt / sichtbar wird was du erwartest?

André

[Thomas]

Hallo und danke für eure Teilnahme an meinem Problem.

Ich hab wieder ein wenig mehr rausgefunden und weiß nun, warum die Schnittstelle abschmiert wenn eine 00 im EEPROM steht.

Die Seriennummer des Gerätes, also die 12 Bytes die im EEPROM stehen, werden beim hochfahren in den Device Descriptor geschrieben. (Von mir so programmiert)
PC seitig scheint dann was diese 00 nicht richtig zu interpretieren (ich denke da an C-String und die Terminierung solcher Strings) Jedes mal wenn da irgendwo in dem String 00 steht kackt er ab. Das ist reproduzierbar. Ich werd jetzt beim schreiben und lesen Verifizierungsalgorithmen reinbauen, damit so was nicht mehr passiert.

Fraglich ist allerdings noch wie die 00 in den EEPROM gekommen ist. Das muß ich irgendwie nochmal genauer untersuchen. Selber geschrieben hab ich sie jedenfalls nicht, denn nach der fertigen Programmierung und der Auslieferung an den Kunden geht ja erst mal alles.

Danke für eure Hilfe.

Grüße
Daimonion