Ich mache die ersten Gehversuche mit dem ARM Derivat LPC2106 und habe mir das Olimex Modul LPC2106 beschafft. Habe jetzt folgendes Problem: Die Ports P0.22 bis P0.31 lassen sich nicht ansprechen (ich toggle einfach alle Pins ). Auch Port 0.2 und 0.3 tut nicht so wie es soll. Alle anderen gehen wie gewünscht. Ich benutze JTAG Port1 zum Debuggen(geht auch). Gibt's da was zum Einstellen was ich noch nicht weiss? Danke für sachdienliche Hinweise.
Schon mal ins Datenblatt geschaut? Da steht drin, warum das nicht klappt. Eine Suche hier im Forum hätte es auch getan. Die Lösung Deines Problems liegt in der Verwendung eines anderen ARM-Derivats. Die LPC2106er sind für vieles einfach zu stark beschnitten.
Port 0.2 und Port 0.3 benötigen externe Pullups, auch wenn sie nicht als I²C-Schnittstelle genutzt werden. Das steht ärgerlicherweise nicht im Datenblatt oder Programmierhandbuch, im Gegensatz zur Einschränkung während des JTAG-Debugbetriebes.
@ Rufus Danke für den Tip , das könnte sein! @ Andreas Dein Beitrag hilft mir leider überhaupt nicht weiter. Man traut sich ja kaum noch was zu fragen oder zu posten!
Vielleicht kann ich hiermit einen praktischen Beitrag dazu leisten, dass das Secondary JTAP Port des LPC210x seinen "Schrecken" verliert und der Anwender 10 zusätzlich Pins nutzen kann (gegenüber der Primary JTAG Port Lösung) So geht's (bei mir): 1. Die PHILIPS Application Note AN10255 vergessen ! (hatte mich total verwirrt). 2. Die Pins des Secondary JTAG Ports im eigenen C-Programm auswählen. (oberste 5 bit in PINSEL1). Ein Hilfprogramm wird nicht benötigt! 3. Einmal das erzeugte Programm per ISP oder über das Primary JTAG Port in die CPU brennen.(ISP oder Primary JATG Port wir dann normalerweise nie mehr gebraucht, neue Programme werden über den Debugger am Secondray JTAG Port geflasht). 4. Den Debugger am Secondary JTAG Port anschliesen . Der Pin DBG der CPU muss LOW sein! RTCK funktioniert nicht im Secondary JTAG Port Mode, der Debugger muss also auch ohne RTCK arbeiten können. Der Debugger muss in einer Betriebsart schaltbar sein, die den JTAG TAP Controller in der CPU auch ohne gezogenem RESET initialisieren kann (Attache mode, etc.) 5. Debugger ganz normal starten. 6. Vergessen dass es das zweite JTAG Port gibt, solange man die Pinconfiguartion der Portpins P0.27 bis P0.31 nicht ändert. Wer im Programm die Konfiguration verändert, verliert die Kontrolle über das Programm. Wer die ersten Konfiguration nach Reset verändert, muss Schritt 3 wieder ausführen. Das eigene Programm startet natürlich und läuft einige 100ms (abhängig vom Debugger), bis der Debugger es "einfängt" und stoppt und man Kontrolle über die CPU hat. Wer das nicht möchte muss beim Debuggen eine Endlosschleife nach der Initialisierung einbauen und den PC dann manuell setzen.
Nur um präzise zu sein muss es heissen : .... 6. Vergessen dass es das zweite JTAG Port gibt, solange man die Pinconfiguartion der Portpins P0.27 bis P0.31 nicht ändert. Wer im Programm die Konfiguration verändert, verliert die Kontrolle über das Programm. Wer die ersten Konfiguration nach Reset verändert UND FLASHT , muss Schritt 3 wieder ausführen. ...
Danke für die Übersetzung der etwas umständlichen Beschreibung in der Philips-Applikation. Inzwischen debugge ich auch über den sekundären JTAG-Port des LPC2106. Das Aktivierungsprogrämmchen bleibt im Flash, mein Anwenderprogramm geht zum Debuggen ins RAM. Schöne Grüsse, Franz
Ergänzung zu meinem Hinweis zum Secondary Debug Port von 02.02.2005. Einige LPC2106 gehen nur "widerspenztig" über das Secondary Debug Port in den Debug Mode wenn man DBGSEL auf "0" und RTCK auf "1" legt. Dieses Verhalten ist (bei mir) verschwunden, wenn man den DBGSEL Pin auf "1" und dafür RTCK auf "0" legt (RTCK über 10K).
Bitte 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.