Servus,
ich kaempfe jetzt schon laengere Zeit mit dem LPC901, und komme
irgendwie nicht weiter.
Programmiert wird der LPC mit einem GALEP4, Programmieren und Verify
funktioniert fehlerfrei. Klemme ich anschl. die Versorungsspannung an,
so geschieht leider nichts.
Das Programm sollte einen Portpin toggeln:
1
#include<reg901.h>
2
3
voidmain(void)
4
{
5
P3M1&=~0x03;
6
P3M2|=0x03;
7
8
while(1){
9
P3=0x00;
10
P3=0x03;
11
}
12
}
Das UCFG Byte steht auf default, 0x63 sollte also passen.
Den LPC habe ich natuerlich auch schon (mehrmals) getaucht. Leider ohne
Erfolg.
Hat vielleicht jemand einen Tipp fuer mich?
PS: Ist mein erster Versuch mit einem 901. Sonst habe ich meistens die
935/936 im Einsatz.
Gruss,
Robert
Wie wird das Toggeln geprueft? Ich nehm mal an mit einem Oszi, nicht mit
einer LED? Falls LED, die koennte einfach nur ganz schwach leuchten,
evtl. nicht sichtbar.
901 und 935 sind eigentlich SEHR aehnlich, falls dasselbe Programm ohne
Aenderungen auf einem LPC935 laeuft ist das schon merkwuerdig.
Zur Programmierung kann ich nicht sagen, denn GALEP4 ist nicht in meinem
Erfahrungsbereich. Bei LPCtools gibt es alle moeglichen
Programmierhilfsmittel.
Leider kann ich im Moment auch nicht mehr helfen
Gruss, Robert
Also grundsätzlich würde ich auch sagen, daß alles korrekt ist.
Vielleicht probierst du mal ein paar Variationen aus. Probier mal den
externen Reset Pin zu deaktivieren mit UCFG = 0x23 oder anstatt dem
push-pull Mode einen anderen Mode der Pins.
Ciao,
Rainer
Robert Teufel wrote:
> Wie wird das Toggeln geprueft? Ich nehm mal an mit einem Oszi, nicht mit> einer LED? Falls LED, die koennte einfach nur ganz schwach leuchten,> evtl. nicht sichtbar.
Ich habe das Oszi drangehaengt. Da sieht man schoen, wie die IO-Pins in
der Gegend rum floaten. Das ist ja der default nach einem Power-On.
> 901 und 935 sind eigentlich SEHR aehnlich, falls dasselbe Programm ohne> Aenderungen auf einem LPC935 laeuft ist das schon merkwuerdig.> Zur Programmierung kann ich nicht sagen, denn GALEP4 ist nicht in meinem> Erfahrungsbereich. Bei LPCtools gibt es alle moeglichen> Programmierhilfsmittel.>
Danke fuer die Info, wenn garnichts hilft, wede ich mir wohl ein MCP900
zulegen muessen.
> Leider kann ich im Moment auch nicht mehr helfen>> Gruss, Robert
Fox Mulder wrote:
> Vielleicht probierst du mal ein paar Variationen aus. Probier mal den> externen Reset Pin zu deaktivieren mit UCFG = 0x23 oder anstatt dem
Deaktivieren des Reset -> keine Aenderung
> push-pull Mode einen anderen Mode der Pins.>
Ich habe alle Output-Modes ausprobiert -> Keine Aenderung
Aber jetzt kommts:
Ich habe UCFG=0x64 und UCFG=0x24 probiert. Diese Einstellung verwendet
den Watchdog Oszillator als Clock-source. Damit bekomme ich am Oszi ein
Rechteck Signal am Portpin.
Stelle ich UCFG wieder auf den RC-Oszi zurueck, geht wieder nichts mehr.
Hierbei spielt es keine Rolle, ob ich UCFG mit dem GALEP programmiere,
oder direkt im Programme via IAP-Calls den neu programmiere.
Mittleiweile habe ich 5(!) nagelneue 901'er probiert. Alle mit dem
selben Ergebnis: Mit WD-Oszi als Clock gehts, mit dem RC-Oszi als Clock
gehts nicht. Ich kann mir bei besten Willen nicht vorstellen, dass bei
allen fuenf 901'er der intere RC-Oszi defekt ist.
Ich wuesste auch nicht, was ich an meiner Testschaltung noch verbessern
koennte. Ich habe den 901 auf eien SO-DIL Adapter geloetet, 3.3V an Pin
1 und GND an Pin 8. Mehr ist nicht dran.
schoene Gruesse,
Robert
Hmm dann probier doch mal einen externen Quarz mit zwei Kondensatoren
als Taktquelle zu benutzen ob das geht.
Ich kann mir aber auch nicht vorstellen, daß bei allen Controllern der
interne RC Oszillator defekt ist. Vielleicht ist es irgend eine
Einstellung, die du (wir) bisher einfach übersehen haben.
Funktionieren denn deine 935/936 mit gleicher Programmierung und
internem RC Oszillator problemlos oder verwendest du bei denen einen
externen Quarz?
Der Einfachheit halber würde ich auch anstatt eines Portpins per
Programm dauernd zu toggeln die CLKOUT Funktion an Pin P3.0 mal testen.
Dazu musst du ja nur das Bit ENCLK im SFR TRIM setzen. Dann kannst du
mit dem Oszi den CCLK/2 an diesem Pin nachmessen. Ich denke der Pin muß
dafür natürlich auch vom Mode her richtig gesetzt sein. Für den Fall,
daß du den DIVM Taktteiler auf 1 stehen hast solltest du dann die halbe
Oszillatorfrequenz messen können. Bei Verwendung des externen Quarzes
geht das natürlich nicht mehr, da P3.0 dann für diesen benötigt wird.
Ciao,
Rainer
Dank an Fox Mulder fuer die Vorschlaege, hat leider auch nichts
gebracht.
Doch ich kann vermelden, dass ich den Fehler gefunden habe.
Es gibt da die Datei START900.A51 welche von der IDE beim Erstellen
eines neuen Projekts angelegt wird. Sie enthaelt Prozessor spezifischen
Initialisierungscode z.B. Stackpointer setzen, Speicher loeschen, etc.
Genau beim Initialisieren des IDATA Memory liegt der Fehler. Der 901'er
hat naemlich gar keinen IDATA Memory! Er schreibt also munter ins
Nirvana, und haengt sich fest.
So, jetzt kanns richtig losgehen. Nochmals vielen Dank fuer die Hilfe.
Gruss,
Robert
Du hast Recht.
Wenn ich ein neues Projekt für den LPC901 erstelle und die start900.a51
hinzufüge steht dort standardmäßig für die Speichergröße 0x100 (256)
drin. Leider gibt es auch nur eine einzige start900.a51 für alle LPC900
Typen, was natürlich schon nicht gut gehen kann, wenn man diese nicht
unterscheidet.
Da ich die Initialisierung des Speichers zu Beginn sowieso immer
abschalte, ist bei mir das Problem auch nie aufgetreten.
Aber dann hätte bei dir doch schon im Debugger eine Fehlermeldung kommen
sollen. Denn wenn ich bei mir den default Wert von 256 Bytes drin stehen
lasse und den Debugger starte kommt gleich eine Fehlermeldung genau
wegen dem Schreiben in den nicht vorhandenen Speicherbereich.
Aber trotzdem gut zu wissen, an was man alles denken muß. :)
Ciao,
Rainer
Fox Mulder wrote:
> Aber dann hätte bei dir doch schon im Debugger eine Fehlermeldung kommen> sollen. Denn wenn ich bei mir den default Wert von 256 Bytes drin stehen> lasse und den Debugger starte kommt gleich eine Fehlermeldung genau> wegen dem Schreiben in den nicht vorhandenen Speicherbereich.
Das hast Du natuerlich Recht. Aber ich war mir ja 100%ig sicher, das
mein Programm in Ordnung ist. Auf dem 935 hat es wunderbar funktioniert.
Deshalb bin ich nicht auf die Idee gekommen den Debugger zu starten.
Man lernt nie aus ...
Gruss,
Robert