Bei einem aktuellen Projekt habe ich einen per UART angebundenen Bluetooth Chip und mehrere über I2C angebundene Sensoren. Das UART läuft mit Hardware Flowcontrol und ich bekomme auch keine Overflow Events des UART Internen Hardware FIFOs. Seit längerem habe ich merkwürdige Abstürze des Bluetooth Stacks wahrgenommen, die sporadisch nach 1-4 Stunden auftreten. Mittlerweile kann ich das Problem eingrenzen in: Ohne I2C aktivität läuft die Bluetooth Verbindung problemlos und unbegrenzt lang. Sobald ich jedoch das Auslesen der Sensoren per I2C aktiviere, bekomme ich die Abstürze. Um sachen wie Memory Corruption auszuschließen habe ich sogar das komplette Buffern der von den Sensoren ausgelesenen Daten deaktiviert, es wird also nur der Datensatz abgerufen und direkt verworfen. Ich habe bereits die Datenleitungen des UARTS per Oszilloskop auf übersprechen oder sonstige Vorkommnisse überprüft, und auch Baudrate oder I2C Clockrate zu verstellen bringt keinerlei änderung. Sowohl I2C als auch UART laufen interrupt basiert. Dabei habe ich bereits dem UART Interrupt die höchste Interrupt Priorität zugeteilt, sodass es auch nicht durch Unterbrechungen des UART Interrupts zu fehlern kommen kann. Weiterhin teilen sich die Beiden Treiber für die Schnittstellen keinerlei Variablen oder haben sonst irgend eine Abhängigkeit. Hat jemand eine Idee welche Probleme noch auftreten könnten die diese Symptome hervorrufen könnten? µC: LPC1115 IDE: LPCXpresso 6.1.0 Bluetooth Chip: CC2564 Sensoren: Mag3110, MMA8451, L3G4200
Hauke Radtki schrieb: > Hat jemand eine Idee welche Probleme noch auftreten könnten die diese > Symptome hervorrufen könnten? Hast Du mal die Spannung am Bluetoothchip angesehn und I2C/kein I2C verglichen? Vielleicht einfach mal nen C drauflegen falls die Sensoren rumsauen.
Hab ich bereits gemacht, und I2C ist nicht zu bemerken. Weiterhin stürtzt der Bluetooth Chip nicht ab, sondern nur das HCI H4 Transport Protokoll wird desynchronisiert. Denn ich bekomme noch Events und Daten vom Bluetooth Chip, wenn ich sie vom PC aus sende, nur in der gegenrichtung geht nichts mehr, weil der Stack denkt, die Buffer im Bluetooth Chip wären voll. Das passiert, da er wohl zufällig Paket Bestätigungsmeldungen des Bluetooth Chips nicht mehr mit bekommt. Ich habe vier Interrupt Prioritäten zur Verfügung. Momentan sehen sie folgendermaßen aus (niedrigste Prioritätsnummer = höchste Priorität bei der Ausführung) 0: UART Interrupt 1: I2C Interrupt 3: Mag3110 Interrupt (signalisiert vorhandene Daten) Dementsprechend kann UART nicht von I2C unterbrochen werden, umgekehrt jedoch schon. Trotzdem kommt es zu fehlerhaften oder verlorenen UART Bytes (lässt sich schwer aufspüren was genau fehl schlägt auf Grund der sporadischen Natur des Phänomens)