Forum: Mikrocontroller und Digitale Elektronik LPC901 - Programm laeuft nicht


von Robert W. (rweber)


Lesenswert?

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
void main(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

von Robert Teufel (Gast)


Lesenswert?

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

von R. W. (quakeman)


Lesenswert?

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

von Robert W. (rweber)


Lesenswert?

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

von Robert W. (rweber)


Lesenswert?

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

von R. W. (quakeman)


Lesenswert?

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

von Robert W. (rweber)


Lesenswert?

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

von R. W. (quakeman)


Lesenswert?

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

von Robert W. (rweber)


Lesenswert?

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

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
Noch kein Account? Hier anmelden.