Hallo Leute! Ihr seid meine letzte Hoffnung. Ich habe vor einiger Zeit einen seriellen Treiber für den LPC2138 programmiert. Habe diesen auch ausgetestet, aber anscheinend nicht genau genug. Dieser Treiber kann IRQ gesteuert Daten senden und empfangen. Das Problem: Wenn ich Daten vom µC sende und dieser gleichzeitig Daten erhält, dann stürzt er ab und startet neu und ich habe keine Ahnung warum. Ich habe jetzt das Programm soweit verkleinert und auch die Initialisierungen minimiert. Ich habe den Stack vergrößert. Das Hauptprogramm holt ein empfangenes Zeichen ab und und sendet bei jedem Durchlauf ein 'X' raus. Mehr macht das Programm zur Zeit nicht. Es ist nur der Empfangs- und SendeIRQ eingeschaltet. Die Empfangs-IrQ-Routine holt sich das Zeichen in eine Variable und setzt das Flag rx_counter1. Somit weiß das Hauptprogramm, dass es etwas zu holen gibt. Wird ein Sende-IRQ ausgelöst, so wird die Variable tx1sendezel auf 0 gesetzt, somit weiß PUTCHAR, dass ein weiteres Zeichen gesendet werden darf. Nun könnte man natürlich sagen, dass das Ganze natürlich ohne IRQ-Routine wesentlich konfortabler funktionieren würde, aber es handelt sich hierbei normalerweise um eine hochfunktionale Routine, die den Hardwarebuffer vollständig ausnutzt und zudem noch einen Sofwarebuffer besitzt. Das Witzige ist, dass wenn ich in UART1-IRQ.c bei der Funktion putchar die Zeile tx1sendezel++; durch die Zeile tx1senezel=1; ersetzte, dann stürzt der Kontroller bei einem Empfang nicht mehr ab?!? Hei, bitte Profis. Schaut euch den Code bitte mal durch. Ich weiß nicht, wo der Fehler liegen könnte. Danke. Gruß, Martin
Das sieht fischig aus:
status=U1IIR&0x0F; // Statusregister abfragen.
// Sende-IRQ wird jetzt gelöscht.
switch(status)
{
case 0x04: // Empfangen
// Hardware-Buffer wird entleert und
// in den Soft-Buffer geschoben.
rx_buffer1=U1RBR;
rx_counter1=1;
break;
case 0x02: // Senden
// Kein Zeichen befindet sich mehr im Hard-Buffer.
// Zähler auf 0.
tx1sendezel=0;
break;
}
status schreit nach Bitabfrage. Dein switch-code geht schief, wenn
gleichzeitig das Statusbit für Empfangen und für Senden gesetzt sind (=
case 0x06). Genau der Fall "Crash beim gleichzeitigen Senden und
Empfangen".
Statt dem Switch/Case würde ich if-Abfragen mit anständiger Bitmaske
programmieren.
Martin, sollte der Vorschlag von Stefan zur Behebung Deiner Probleme fuehren, einfach diesen Beitrag ignorieren, anderfalls mal in Erwaegung ziehen. Ein Schuss ins Blaue. Bitte mal die Application Note ueber "Spurious Interrupts" lesen. http://www.standardics.philips.com/support/documents/microcontrollers/pdf/an10414.pdf Zusammenfassend, unter bestimmten Umstaenden ist es moeglich Interrupts zu bekommen, die keinen Vector zugeordnet haben. Dazu sollte dann eine Routine da sein, die diese abfaengt. War gerade ein grosses Thema im LPC2000 Forum unter Yahoo mit den Praktikern, die sagen, ein Interrupt der keine identifizierbare Source hat wird einfach weggeworfen und dem akademischen Ansatz der sagt, es darf keine unidentifizierbaren Interrupts geben. Hoert sich jetzt vielleicht etwas off topic an aber deine Symptome sind recht typisch fuer Spurious Interrupts. Robert
"und dem akademischen Ansatz der sagt, es darf keine unidentifizierbaren Interrupts geben." In meinen Augen ist das kein akademischer Ansatz sondern eine Frage der Zuverlässigkeit ! Wenn die es nicht mal schaffen, die Interruptlogik vernünftig gebacken zu kriegen, wie soll man dann dem Rest vertrauen können ? Beim 8051-er habe ich noch nie einen Interrupt verloren oder zuviel gehabt. Ist es denn wirklich zuviel verlangt von einen 32-Bitter genau so zuverlässig zu sein, wie ein 8-Bitter ? Falsche Interrupts dürften in jedem Fall ein absolutes K.O.-Kriterium für den militärischen oder medizinischen Einsatz sein. Peter
Peter, anscheinend ist es zuviel verlangt zuerst zugehoerige Information in der Applikation Note zu lesen. Sorry, falls ich da zuviel erwartet hab. Robert
Also ich verfolge auch gerade die Mailings in der LPC2000-Group. Philips hat sich mit den Teilen nicht mit Ruhm bekleckert. Die LPCs sind ja anscheinend ein Sack voller Bugs. Erstaunlich, wo die doch schon relativ lange auf dem Markt sind. Vielleicht sollte Philips mal wieder weg von der "Umsatz, egal wie"-Devise und ein bißchen mehr auf Qualität achten. Haben die überhaupt eine vernünftige Qualitätssicherung? Oder liegt das daran, daß Philips einfach nur unerfahren ist mit Controllern, die komplexer sind als die uralten 8051er?
@Robert, sorry. So ich habe jetzt die AN gelesen und finde das ganze nur umso seltsamer. Der Interrupt-Bug ist also von den ARM-Entwicklern so vorgegeben und darum mußte ihn Philips mit einbauen und darum wird es wohl auch keinen Bugfix bei neueren LPCs geben. Mein Kollege benutzt ja den LPC2129 und hat auch genau diesen Bug festgestellt (hatte aber einige Tage gedauert), er muß Interrupts zeitweise disablen, um 1-wire Sensoren abzufragen. Für mich bleibt es jedenfalls ein kritischer Bug, egal wer dafür verantwortlich ist und ich werde solche Bauteile meiden. Peter
P.S.: Bin ich etwa vom 8051 zu sehr verwöhnt worden, was die Zuverlässigkeit und Vorhersagbarkeit betrifft ? Peter
@Peter, nun mal ganz ehrlich, es gibt bessere Interrupt Controller als den auf irgeneinem ARM (oder Intel x86 oder PPC oder AVR..) und die sind auf den Infineon Chips. Falls mir der Interrupt das wichtigste Feature ist, dann hab ich noch nichts besseres als den 166 im 16-bit und den TriCore im 32-bit gefunden. Wuerde ich diese Chips deshalb einsetzen? Vielleicht den 166, zumindest in der Vergangenheit war der Chip eine Klasse fuer sich, fuer TriCore gibt es spezielle Anwendungen wie Motormanagement, da ist der kaum zu schlagen aber ich mache keine Motormanagement Anwendungen also ist der fuer mich nicht so attraktiv. Genug der Lobeshymnen fuer Konkurrenzprodukte ;-) Der ARM Interrupt Controller ist "OK" egal ob er VIC, AIC oder sonstwie heisst, alles ist besser als das original ARM Schema mit IRQ und FIQ, (das weiterhin benuetzt werden kann falls so gewollt). Im Prinzip handelt es sich um eine Kombination von Pipeline Effekt und kaskadierter Interrupt Controller. Wir von Philips versuchen wo irgend moeglich original ARM Komponenten einzusetzen, der VIC gehoert dazu. Warum? Kompatibilitaet und Tool Unterstuetzung von Compilern bis Operating Systems. Nun zum eigentlichen Punkt der sporadischen Interrupts wie in der ApNote beschrieben; ist das was schoenes? Nein, aber es ist ungemein schwierig den ARM Core zu nehmen, einen verbesserten vorgeschaltenen Interrupt Controller einzubauen und nicht in ein solches Dilemma zu laufen. Es scheint, es hat noch keiner geschafft. Alle mir bekannten Loesungen von anderen Herstellern verweissen irgendwo auf aehnliche Probleme. Schau die ApNote als Workaround an. Die entscheidende Frage fuer mich ist allerdings, soll mich diese "Unschoenheit" davon abhalten Microcontroller mit dem besten Preis/Leistungsverhaeltnis einzusetzen, mal egal von welcher Firma sie hergestellt werden? Die Antwort muss sich jeder selbst geben. p.s verwoehnt vom 8051? In 2 Punkten vielleicht schon, Interrupts inklusive Registerbankswitch und Bitverarbeitung, da ist der schon seiner Zeit lange voraus gewesen bei der Einfuehrung 1979! Gruss, Robert
@Robert, Unter "2.3 Handling of spurious interrupts" steht ja, daß ich die Interruptquelle herausfinden und behandeln muß. Da kann ich mir ja gleich verschiedene Vektoren für verschiedene Interrupts schenken und alles in diesem einen Interrupthandler machen (müssen). Ich hatte eigentlich so gedacht, daß ich für den spurious Interrupt einfach einen leeren Interrupthandler aufsetze, damit mein Programm nicht abschmiert und daß ich danach den richtigen Interruptvektor kriege, da ich ja keine Interrupt-Flags lösche. Peter
Hmmmm, mal eine Frage als nicht ganz so Versierter: Was sind denn spurious interrupts und warum sind sie so schlimm? Bei meinem Linux erscheint auch ab und an so ein Eintrag mit diesen Interrupts im Log. Abgeschmiert ist das aber bisher noch nicht.
"Was sind denn spurious interrupts und warum sind sie so schlimm?" Wenn dieser spurious Interrupt eigentlich den Airbag in Deinem KFZ auslösen hätte sollen, wäre das etwa nicht schlimm ? Peter
Es gibt 2 Sachen, die mir am 8051 gegenüber dem ARM besonders gefallen: 1. Nach einem Interrupt wird immer erst eine Instruktion des Main ausgeführt. Sollte mal die CPUs mit Interrupts zugeschissen werden, läuft sie immer noch, zwar sehr langsam, aber sie läuft. Ich hab z.B. mal Debugausgaben über die UART gemacht, als Interrupthandler hats nicht funktioniert, aber im Main im Polling-Mode habe ich alle Debugausgaben erhalten. 2. Jeder Zugriff auf die Interruptregister sperrt Interrupts auch für den nächsten Befehl und startet die Interrupterkennung neu. Somit kann es nie passieren, daß sich Interruptlogik und CPU in die Quere kommen. Ich weiß natürlich, daß man den ARM nicht so einfach verbessern kann, weil es ein Standard ist. Aber ärgerlich ist es schon, daß CPU-Entwickler zu selten über den eigenen Tellerrand schauen. Peter
"Wenn dieser spurious Interrupt eigentlich den Airbag in Deinem KFZ auslösen hätte sollen, wäre das etwa nicht schlimm ?" Hallo Peter, ein nicht ausgelöster Interrupt ist natürlich ist natürlich schlimm, aber mit ist immer noch nicht klar, was das eigentlich ist. Ist das ein Interrupt, der nicht als solcher erkannt wurde bzw. der unter einer anderen Quelle erscheint?
Hallo Leute!
Danke für die Antworten.
Ich habe jetzt das probiert, wozu mir Stefan geraten hat. Bist jetzt
hat alles einwandfrei funktioniert.
Ich muss aber nocht Tests mit den komplexeren Teilen des Programmes
durchführen. Aber in der Light-Version funktioniert das Senden und der
Empfang bestens.
Aber was ich nicht verstehe: Auf Seite 105 im Datenblatt (Ver:
22.11.2004) ist das ganze so beschrieben, als ob die verschiedenen IRQs
- Receive-Line-Status, Receive Data Available, Character Time-Out usw.
verschiedene Prioritäten aufweisen.
Aus diesem Grund habe ich ja auch eine Switch-Anweisung geschrieben, da
ich mir dachte, dass auch wenn zwei IRQ gleichzeitig auftreten, nur
einer im Statusregister angezeigt wird, nämlich der mit der höheren
Priorität. Wenn man dann den mit der höheren Priorität abgearbeitet
hat, dann sollte, der mit der niedrigeren angezeigt werden. So war
meine Idee. Ist diese denn so falsch? Vermischen sich hier wirklich die
verschiedenen IRQ's im Statusregister U1IIR?
Dies mit der IF-Abfrage und der Maskierung funktioniert ja nur beim
Senden und Empfangen, aber nicht im folgenden Beispiel.
(Bit 3:1)
011 RLS - Fehler
010 RDA - Empfang
110 CTI - Character Time-out
001 THRE - Senden
Wenn ich nun die Abfragen maskiere.
if((status&0x04)==0x04) // Empfang - RDA
{
rx_buffer1=U1RBR;
rx_counter1=1;
}
if((status&0x0C)==0x0C) // CTI- Character Time-Out
{
..
}
Wenn nun im obigen Beispiel ein Time-Out-Irq ansteht, dann glaubt der
Controller anhand der Maskierung, dass nicht nur der Time-Out-Irq
ausgelöst wurde, sondern auch ein Zeichen empfangen wurde. Wie löst man
dieses Problem?
Danke, Tschüss, Martin
Es ist Zufall, dass der Code jetzt funktioniert.
Du darfst nicht ein einzelnes Bit abfragen, sondern musst die drei Bits
zusammen abfragen. Das war richtig von dir gedacht.
status &= 0b00001110; // Bits 3:1 gelten
status >>= 1; // um Bit 0 wegzubekommen ;-)
if ( status == 0b010 ) // Empfang - RDA
{
rx_buffer1 = U1RBR;
rx_counter1 = 1;
}
else
if ( status == 0b110 ) // CTI- Character Time-Out
{
...
}
Jetzt bietet sich auch wieder ein switch/case an.
status = U1IIR & 0x0E; // Bits 3:1 sind relevant
switch ( status )
{
case 0x04: // Empfang - RDA
rx_buffer1 = U1RBR;
rx_counter1 = 1;
break;
case 0x0C: // CTI- Character Time-Out
...
break;
...
default:
ASSERT(...); // ;-)
break;
}
Ups. Das ist wieder an deine Ausgangsversion. Fast ;-) bis auf die
Maske (früher: 0x0F jetzt 0x0E). Deine Ausgangsversion ist schief
gegangen, wenn Bit 0 in status gesetzt war.
HI. Hi. Hi. Du bist ein Genie. Danke. Jetzt ist es mir logisch, warum es hier Probleme gab, weil das Interrupt-Pending-Bit nicht rausgelöscht wurde. Ich werde das mal alles testen. Tschüss, Martin
Hi Hab noch einen kleinen Nachtrag zu obenstehendem Problem. Wie Robert bereits erwähnt hat, bieten andere Controller nicht nur einen Empfangs Interrupt. Da wird beispielsweise auch bei einem falschen Daten Frame ein IRQ auf einem anderen Vektor ausgelöst. Ist dieser nicht implementiert, kann es vorkommen, dass bereits beim Einstecken des RS232- Kabels ein solcher fehlerhaftes Datenpaket entstehen kann. Ist der enstprechende Vektor nicht definiert, hängt die CPU. (Mir bereits geschehen, aus Schaden wird man klug) Desshalb mein Rat: Immer sämtliche Empfangs IRQ- Vektoren mit Rücksprungadressen versehen. Gruss Andy
Hallo Leute! Ich habe mich leider zu früh gefreut. Leider hat diese Umstellung nichts gebracht. Der Prozessor startet trotzdem immer wieder neu. Wahrscheinlich muss ich mir doch das Datenblatt, welches mir Robert empfohlen hat anschauen. Aber eines weiß ich. Wenn ich herausgefunden habe, wo hier die Ursache liegt, dann habe ich garantiert viel gelernt. Gruß, Martin
Hallo! Ich habe noch eine Frage: Im AN10414 Datenblatt, indem die spurious Interrupts beschrieben werden, ist es so, dass der Interrupt-Controller mit "VICVECTAdrr=0xFF;" am Ende einer Interrupt-Routine geresettet wird. Doch in den anderen Datenblättern steht immer "VICVECTAdrr=0x00;". Was ist richtig? Oder gibt es beide Varianten. Tschüss, Martin
Hallo Leute! Ich habe jetzt das mit dem spurious-IRQ versucht. Der µC stürzt zwar jetzt nicht mehr ab, aber das heißt nichts, da es nach Veränderung einer Programmzeile wieder zu einem Absturz kommen kann. Was mir Sorgen macht ist, dass der Kontroller nicht in die Spurious-Routine springt. Im Datenblatt steht auch, dass der Spurious-Interrupt nur dann ausgelöst wird, wenn RDA und CTI-IRQ verwendet werden. Nur der (CTI)-Time-Out-IRQ wird in der jetzigen Version nicht mehr verwendet, sondern nur noch der Sende und Empfangs-IRQ und kein Hardwar-Buffer mehr. Ich habe euch das Programm nochmal reingestellt. Die Spurious-Handler-Routine wurde von mir wieder auskommentiert. Diese Programm-Version stürzt immer wieder ab, wenn man dem Kontroller Daten schickt. Dazu habe ich einfach ein 12KByte-File angelegt, um dieses an den µC zu senden. Das Lustige ist, dass dieser dann nicht mehr abstürzt, wenn man im file UART1-IRQ.c, in der IRQ-Routine die beiden Zeilen. IOSET1=0x01<<18; .. .. IOCLR1=0x01<<18; wieder aktiv setzt. Leider habe ich immer mehr das Gefühl, dass es sich um einen Prozessor-Bug handelt. Hey Profis, bitte helft mir. Ich habe soetwas noch nie erlebt. Ich dachte, wenn ich das Programm vereinfache, dann kann man den Fehler leicht finden, aber ich finde keinen Fehler. Danke im Voraus. Schönen Gruß, Martin
Hallo Martin, ist leider etwas Offtopic, aber vielleicht nützt es ja: Ich persönlich würde ein Embedded-OS wie z. B. eCos probieren. Da ist die serielle Schnittstelle, Interrupt-Handling, Scheduling usw. schon alles wunderbar implementiert. Ist außerdem GPL-Software. Gruß Olaf http://ecos.sourceware.org/
Danke Olaf, aber ein Embedded-OS kommt für mich nicht in Frage. Ich habe jetzt die ganzen Modi abgeklappert: Undef_Addr SWI_Addr PABT_Addr DAbt_Addr Aber der Kontroller bleibt nur beim Breakpoint - Reset_Addr stehen. Auch der Verdacht, dass versehentlich die Reset-Leitung gezogen werden könnte, bestätigte sich nicht. Gruß, Martin
Hallo Martin, warum kommt ein Embedded-OS nicht in Frage? eCos kannst Du durch compile-Schalter bis auch wenige K kleinkriegen. Du kannst Dich z. B. auf den HAL für bestimmte Hardware beschränken, ohne Scheduler oder anderen Schnickschnack. Gruß Olaf
Hallo Olaf! Dies wäre natürlich schon auch interessant. Nur habe ich jetzt von Embedded-OS-System absolut 0 Ahnung. Die Einarbeitungszeit würde wahrscheinlich einige Zeit in Anspruch nehmen. Es ist aber so, dass ich solche technischen Probleme, wie sie z.B. hier jetzt vorherrschen immer gelöst haben möchte oder zumindest die Antwort darauf haben möchte, warum so ein Ding nicht funktioniert. Auf diese Weise lernt man immer eine Menge. Aber vielleicht schaue ich mir so ein System mal an. Wäre es möglich, dass du mir deine E-Mail-Adresse zukommen lässt, falls ich mal zu diesem Thema Fragen habe. Keine Sorge, ich werde dich nicht ständig mit E-Mails bombardieren, aber für einen Einstieg ist es immer wichtig, dass man die richtigen Fragen stellen kann und ein paar Hilfestellungen bekommt, damit das Ganze leichter geht. Aber zuvor möchte ich dieses Problem lösen, weil von dieser Lösung abhäng, ob ich den Prozessor in Zukunft überhaupt noch verbauen werde. Gruß, Martin
Hallo Martin, Ok. Ich schick Dir meine Email-Adresse. Solltest Du sie nicht erhalten, poste hier nochmal. Gruß Olaf
Hallo Leute! Hey, das kann doch nicht sein, dass hierzu niemand etwas weiß. Es gibt so viele hier im Forum, die mit ARM-Prozessoren arbeiten. Da muss doch schon mal jemand eine IRQ-Gesteuerte UART-Routine programmiert haben und hierzu Erfahrungen gesammelt haben. Also mit meinen guten alten AVR-Atmel Prozessoren hatte ich in dieser Richtung noch nie Schwierigkeiten. Da lief immer alles bestens. Der ARM7 von Philips wäre der allerbeste Prozessor, mit dem ich jemals Projekte realisiert habe. Wie ihr erkennt schreibe ich hier leider in der Konjunkiv II-Form. Leider, diese Bugs, die der Benutzer alle selbst ausbügeln muss, sind relativ lässtig sind. Man kann sich dann nicht voll auf das Projekt konzentrieren, sondern muss immer im Hinterkopf haben, wie man jetzt eventuell auftretende Probleme und Bugs des Prozessors beseitigt. Schade, der Prozessor hätte eine Menge von Vorteilen: 32-Bit-Timer, DA-Wandler, viel SRAM, viel Flash, abwechslungsreiche Peripherie. Gruß, Martin
Tja, geschenkt kriegt man nichts. Wenn Du einen 32-bitter willst, mußt Du eben auch mit seiner erheblich größeren Komplexität zurechtkommen. Der Preis eines Chips ist nicht entscheidend für dessen Verwendung. Blöd wäre natürlich, wenn Du den 32-Bitter deswegen nimmst, um Programme mit vielen Wait-Loops und vielen Portsetzen zu beschleunigen, damit ists Essig. Vielleicht versuchst Du ja erstmal den ganzen UART-Schrunz im Pollingmode zu implementieren. Und erst, wenn das perfekt läuft, fügt man diese Routine in den Interrupt ein. Besonderes Augenmerk ist auf Register und Variablen zu legen, die im Main und im Interrupt gleichzeitig verwendet werden, dann den Main-Zugriff mit Interruptsperre klammern. C-Ausdrücke sind per default nicht atomar ! Wirkt sich aber erst bei echten Interupts aus, nicht bei Abfrage im Polling. Und beim Interrupt Sperren eben den Spurious Interrupt Handler aufsetzen. Peter
Ohne den ganzen Thread gelesen zu haben: Was spricht gegen die Verwendung des UART-Codes von Bill Knight / R O Software (file-Archiv LPC yahoo-Gruppe.) Ich nutze den recht oft, bisher keine Probleme. Allerdings auch nur bei relativ geringen Baudraten getestet. Die Abfrage der Statusbits ist dort etwas anderes geloest, es werden jedoch alle "Ereignisse" verarbeitet. Betr. Spurious Interrupt sind die Erläuterungen von ARM selbst und Atmel auch recht informativ. "Nicht ausloesen" eines Interrupts gibt es nicht - zumindest nicht meines Wissens. Endweder kann der VIC/AIC den Interrupt verarbeiten oder er "kommt nicht dazu" und ruft dann den default/spurious-Handler, in dem dann der Enwickler fuer die korrekte Weiterverarbeitung Sorge tragen muss. Weiterhin gibt es ja noch FIQ als zusaetzliche "Verarbeitungsebene" die bei einigen Problemstellungen weiterhelfen kann (wohl aber nicht im konkreten Fall). Nichts desto trotz - keine glueckliche Loesung. Schade, dass Philips, Atmel, ST etc. bei ARM keine bessere Loesung erwirken konnten. Analog hat bei den ADuC7k scheinbar gleich ganz auf eine Vectored-Interrupt-Controller-Zelle verzichtet, fragt sich, ob aus Kostengruenden oder weil man dem Problem aus dem Weg gehen wollte. Martin Thomas
Hallo Peter! Das Dumme ist, dass man sich doch zu Beginn besser über entsprechende Fehlverhalten informieren sollte. Das habe ich nun gelernt. Aber mit den Fehler, die im Errata-Sheet beschrieben sind, kann ich eigentlich leben. Leider erfährt man zu Beginn nicht immer alle Nachteile und kann erst nach einer gewissen Einarbeitungszeit erkennen, ob man mit den Nachteilen leben kann oder möchte. Ich finde aber, dass es hier nicht um Komplexität geht, wie du beschreibst, denn der Kontroller ist relativ verständlich aufgebaut. Das Dumme ist nur, wenn an derartigen architektonischen Nachteilen der Endbenutzer zu knabbern hat. Leider steht im Datenblatt nicht: "Unser Prozessor ist zwar super, aber Sie müssen auf folgende Bugs achten und Sie müssen auf die Surious-IRQs achten und ......" Es ist mir schon klar, dass es bei jedem µC architektonische Nachteile gibt, aber diese hier finde ich schon relativ gravierend. Das mit dem Polling waren meine ersten Übungen. Hallo MThomas. Ich habe in die yahoo-group reingeschaut, aber ich habe den UART-Code nicht finden können. Kannst du mir bitte einen Link schicken? Gruß, Martin
Hallo Leute! Ich möchte euch jetzt mal den Zwischenstand mitteilen. Das Programm wurde von mir so umgeschrieben, dass nicht die UART1, sondern die UART0 verwendet wird. Das brachte keinen Erfolg. Statt des C-ARM-Keil-Compilers versuche ich nun den Real/View. Auch jetzt stürzt der Kontroller noch ab. Ich habe ein selbstgebautes Board und ein Keil-Board. Beide stürzen ab. Zusätzlich habe ich jetzt als letzten Verzweiflungsversuch alle Variable auf 32-Bit umgestellt. Auch das brachte nicht den Erfolg. Jezt habe ich schon sehr viel versucht und ich bin immer noch so gescheit oder so blöd wie vorher. Profis, was kann das nur sein? Gruß, Martin
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.