Hallo,
Ich versuche gerade einen LPC2148 auf einer selbstgebauten PCB zum
laufen zu bekommen.
Ich lade den code via FlashMagic ins Flash, das funktioniert auch ohne
probleme.
Leider wird der code im chip nicht ausgeführt - das programm sollte nur
2 pins auf "1" setzen, diese bleiben jedoch auf 0.
int main (void)
{ /* LED var */
//IODIR1 = 0x00FF0000; /* P1.16..23 defined as
Outputs */
IODIR1 = 0x00000300; /* P1.16..23 defined as
Outputs */
IOSET1 = 0x00000300;
while (1)
{
}
}
das ganze ist eine geänderte kopie des keil projekts "blinky".
Zu den pins - nach dem programmieren starte ich das programm nochmal
explizit mit Flashmagix, beginnend bei adresse 0x00, wie im compiler
eingestellt.
P0.14 und RESET sind beide "high", dennoch startet das programm nicht,
bzw. werden die beiden pins nicht gesetzt.
Hat jemand eine Ahnung was falsch sein könnte?
rotary schrieb:> niemand eine idee dazu?
Mehrere:
- SCS Register vielleicht für Fast-IO konfiguriert?
- Prüfsumme im Interrupt-Vektor gesetzt (womit wird geflasht)?
- Zustand P0.31 u. P1.31 beim Reset?
- Passen Startcode und Linkerscript zusammen?
- ...
Es ist sinnlos bei nicht funktionierenden ARM-Programmen nur
Codeschnipsel zu posten. Beim AVR ist das schon grenzwertig
aber beim ARM gibt es einfach zu viele Stellschrauben.
Also ganzes Projekt zippen und anhängen.
Aber das mit den beiden Pins P0.31 und P1.31 solltest du
als erstes prüfen. Die dürfen nicht low sein, können aber
in der Luft hängen (interne pull-ups beim Start).
- Michael
Sieht eigentlich gut aus. SCS wird nicht angefasst und FlashMagic
(hattest du ja bereits geschrieben) setzt die Prüfsumme automatisch.
Ich habe mir jetzt also mein altes Eval-Board hervorgekramt
um das nachzumessen und bin bei den Ports stutzig geworden.
mit IODIR1=0x300 werden P1.8 + P1.9 als Ausgang konfiguriert.
Die werden aber doch gar nicht herausgeführt beim 2148.
Ich habe kein uvision installiert, kann das also nicht abändern.
Hast du es schon mit anderen Ports probiert?
- Michael
hi,
danke für den hinweis, ein übler fehler in meinem code - ich habe an den
pins 0.8 und 0.9 2 leds angeschlossen, habs jetzt mit port0 versucht,
aber leider immer noch keine reaktion bei den leds.
IODIR0 = 0x00000300;
IOSET0 = 0x00000300;
Das sieht nach einem Hardwarefehler aus. Mit leerem Flash
liegen and P0.8 u. P0.9 erwartungsgemäß 0V. Die Stromaufnahme
des Boards beträgt ~20mA. Mit deinem Programm steigt die
Stromaufnahme auf ~60mA und an P0.8 + P0.9 liegen 3.3V.
An P0.10 übrigens auch. An P0.11 liegen wieder 0V.
Das interessante ist das sich der Controller flashen läßt.
Er läuft also grundsätzlich. Einen internen Oszillator haben
die 21xx nicht. Der Quarz schwingt also. Es könnte sein das
die PLL nicht einrastet weil mit dem Quarz etwas nicht stimmt.
Welche Frequenz hat der?
VBAT und VREF gehören an VDD. Möglicherweise hat das
Nebeneffekte wenn das nicht der Fall ist.
- Michael
danke für den tip, habs mir im datenblatt nochmal angesehen - vbat dient
wohl nur zur versorgung der RTC, aref für den ADC - ich werds trotzdem
mal versuchen die 2 pins an vdd zu hängen.
Ich meine das es ein Errata gibt bezüglich VBAT. Da gehört
Spannung dran.
VREF muß, anders als beim AVR, in der Nähe von VDD liegen.
Der Pin ist nur herausgeführt damit man dort eine besonders
gesiebte Spannung anlegen kann.
Aber ob ein Fehlen der Spannung noch andere Komponenten als
den ADC beeinflußt weiß ich nicht.
> der quarz hat eine frequenz von 12MHz und schwingt
Sicher tut er das, sonst würde der Bootloader nicht
funktionieren. Die Frage ist nur ob das Signal "gut genug"
ist für die PLL. Wenn die nicht einrastet bleibt der Startcode
in einer Schleife hängen.
Ich halte das aber für wenig wahrscheinlich. 12MHz liegen
auch im zulässigen Bereich. War nur so eine Idee.
- Michael
Das bedeutet das die PLL nicht läuft. main() wird also gar nicht
erreicht. Könnte an der PLL selbst liegen oder aber das Programm
wird tatsächlich nicht ausgeführt.
Du könntest versuchen die Initialisierung der PLL zu überspringen
um das zu prüfen.
Vielleicht stimmt etwas mit der Reset/P0.14 Steuerung nicht und
der Controller bleibt jedes Mal im Bootloader stehen.
Ein "go" aus FM heraus funktioniert bei mir. Allerdings nur
wenn P0.14 high ist. Ein Kurzschluß zwischen Handshaking- und
Datenleitung könnte evtl. dazu führen das P0.14 im entscheidenen
Moment low ist.
Ansonsten bin ich da gerade etwas ratlos.
- Michael
danke schonmal für deine hilfe, werd das mit der pll mal testen - hab
jetzt mal einen reset-taster eingebaut, und am scope reset und
bootloader pin angeguckt, sieht beides super aus.
nach diversen tests wieder mal ein hilferuf :)
ich habe das initialisieren und umschalten der PLL in der startup.s
übersprungen, aber leider noch immer keine änderung - stromaufnahme mit
und ohne programm 16mA.
Ich hab jetzt einige Schaltpläne von anderen projekten gesehen, welche
bei den grundlegenden pins (versorgung, reset, etc) die gleiche
anschlussbelegung haben wie meiner, dennoch will der controller auf
meinem board keinen ton von sich geben.
bin für alle tips und anregungen dankbar :)
Einen hab' ich noch:
Ob weiterhin der Bootloader läuft, müßtest du wie folgt
herausfinden können:
1. Deaktiviere in den Einstellungen von FM ("advanced options"
glaube ich) die automatische Steuerung von Reset und P0.14.
2. Führe ISP->Read device ID aus.
Dann müßte der Chip antworten.
Wenn dem so ist stellt sich halt die Frage warum das Programm
nicht ausgeführt wird. Der einzige Grund der mir da einfällt
ist das die schon angedeutete Prüfsumme nicht stimmt.
Vielleicht ist die Version von FM die du verwendest kaputt.
- Michael
PS: Das es ohne PLL bei den 16mA bleibt ist normal. Die PLL erhöht
ja die Taktfrequenz des Controllers.
