Forum: Mikrocontroller und Digitale Elektronik C167CS: Kein Pin - Ausgangssignal am GPT1 P3.3


von Mathias Q. (paolo_pinkel)


Lesenswert?

Hallo liebe Experten,

fuer mein Projekt - einer Drehzahlregelung eines Reihenschluss DC-Motors 
- expermentiere ich gerade mit dem C167CS-LM auf einem Phytec Evalboard 
KitCon-167.

Zum Ueben wollte ich das Hands-On Training von Infineon durchgehen. 
Dafuer habe ich DAvE einen Code fuer den GPT1 generieren lassen (Eine 
Schande - ich weiss, aber als Einsteiger...)

Das Evalboard ist mit zwei mal 256KB RAM (an CS1 und CS2) sowie zwei mal 
1MB Flash (an CS0 und CS3) bestueckt.

Die Startdatei Start167.A66 habe ich von DAvE erstellen lassen und 
folgende Register angepasst:

BUSCON0 = 0x04AF
BUSCON1 = 0x04AF
ADDRSEL1 = 0x0006

Den Code habe ich  angehaengt, interessant sind main.c und gpt1.c. Ich 
kompiliere und debugge mit Keil uVision3.

Die Einstellungen vom Target sind die Folgenden:
- 5Mhz Oszi
- ROM 0x0 - 0x4000
- RAM 0x40000 - 0x44000
- Monitor: Phytec KC167CR an COM1 bei 9600 Baud (mehr geht natuerlich 
auch)
- 8H-0BH, 0ACH-0AFH fuer Monitor reserviert

Der Timer wird in der Datei gpt1.C initialisiert und arbeitet 
folgendermassen:

- T2/T4 als Quellen fuer T3 (je nach T3 Toggle Latch)
- T3 als Timer mit Alternate Output P3.3

Wenn ich ein Oszilloskop an P3.3 (Pin 106 am X3 vom kitCON) anschliesse 
und debugge rauscht das Signal nur ein Bisschen, aber von Pulsen ist 
weit und breit nichts zu sehen.

Auch wundert mich, dass wenn ich mir die Timer im Debug Modus von 
uVision anzeigen lasse sind alle Register und Timer nach einem Stop auf 
"0".
Selbst wenn Sie die dann dort von Hand einstelle und das Toggle Latch 
staendig invertiert wird, sowie der Ausgang gesetzt ist (T3OE = 1, DP3.3 
= 1) tut sich nichts.


Hier meine main.c:
1
#include "MAIN.H"
2
3
void MAIN_vInit(void)
4
{
5
  GPT1_vInit();
6
  PSW_IEN = 1;
7
}
8
9
void main(void)
10
{
11
  MAIN_vInit();
12
  while(1) {};     
13
}

und meine GPT1-Initialisierung gpt1.c:
1
#include "MAIN.H"
2
3
void GPT1_vInit(void)
4
{
5
  T3CON          =  0x0201;      // load timer 3 control register
6
  T3             =  0x0000;      // load timer 3 register
7
  
8
  T2CON          =  0x0025;      // load timer 2 control register
9
  T2             =  0xC000;      // load timer 2 register
10
11
  T4CON          =  0x0026;      // load timer 4 control register
12
  T4             =  0x4000;      // load timer 4 register
13
14
  P3   = (P3   & ~(uword)0x0008) | 0x0008;    //set data register
15
  DP3  = (DP3  & ~(uword)0x0008) | 0x0008;    //set direction register
16
17
  T3CON_T3R      =  1;           // timer 3 run bit is set
18
19
}

Fuer Anregungen, Tips, Kritiken bin ich sehr dankbar. Langsam weiss 
alleine nicht mehr weiter.

LG Maze

von Mathias Q. (paolo_pinkel)


Angehängte Dateien:

Lesenswert?

hier ist meine Startup-Datei,
insgesamt sind folgende Dateien eingebunden:

start167.a66
main.c
 main.h
 intrins.h
 gpt1.h
gpt1.c

von Max Murks (Gast)


Lesenswert?

Läuft Dein Programm richtig hoch?
Toggle zuerst einen beliebigen Port. Kontrolliere diesen mit dem Oszi, 
oder besser gebe etwas über RS232 aus.

> ROM 0x0 - 0x4000
bist Du dir da sicher?

von Mathias Q. (paolo_pinkel)


Lesenswert?

Hi Max!

Zum Hochlauf:
Ich befürchte auch, dass das Programm nicht richtig initialisiert und 
werde das mit der Seriellen Schnittstelle oder nem getoggelten Pin 
prüfen, so bald ich wieder im Lab bin. Aber warum das so ist ist mir 
weiterhin leider ein Rätsel.

Zum Speichermodell:
So wie ich das verstanden habe kann ich mir aussuchen wo ich meine 
Adresse von RAM und Flash hinlege und lege das mit den ADDRESELx 
Registern fest. Oder sehe ich das falsch? Auf jeden Fall läuft ein 
simples LED blinky mit dieser Konfiguration.

so far...

von Max Murks (Gast)


Lesenswert?


von Mathias Q. (paolo_pinkel)


Lesenswert?

Hallo Max,

den thread hatte ich mir schon mal durchgelesen. Ich hatte zunächst auch 
das Problem "Connection to Target System lost", aber mit den 
(hoffentlich) richtigen Einstellungen für Monitor, Target und 
Initialisierungsregistern (auch auf die Waitstates achten!) habe ich das 
in Griff bekommen.

Leider scheinen meine Timer nicht initialisiert zu werden (alle Register 
sind auf Restet-Wert) - daher kein Ausgang....aber leider auch nicht 
wenn ich ToggleBit, T3OE und DP3.3 manuell setze.

Hat keiner sonst einen Schimmer? Wäre echt super!

von David (Gast)


Lesenswert?

Hatte damals ebenfalls probleme mit den timern im debbuging modus (u3V). 
Woran es lag habe ich leider nie genau kappiert, aber wenn ich nicht im 
debbuging modus war, und vom flash bootete hatte ich damit nie 
probleme...

habe mit einer älteren Dave version gearbeitet, ist mir nicht ganz klar 
wofür PSW_IEN steht (Interrupt enable?, PWM-Generator?) Aber wenn du 
einem pin ne spezielle funktion gibst, kanst du diesen normalerweise im 
debbugingmodus nicht mehr von hand verstellen..., tippte daher auf einen 
initialisierungsfehler (wobei was ich hier sehe, soweit passen sollte)

von Mathias Q. (paolo_pinkel)


Lesenswert?

Hi David.

Flash:
Ich habs auch schon mal als H86 geflashed - ging leider auch nicht. Aber 
ich probiere es nochmal.

PSW:
Steht für Prozessor-Status Wort. Eigentlich sind darin die Interrupt/PEC 
Level des derzeitig ausgeführten Programmes drinn. PSW_IEN spiel hier 
eigentlich keine Rolle. Das Bit sperrt oder gibt global alle Interrupts 
frei (außer NMI = Non Maskerable Interrupts)

Debugg-Modus:
Das könnte sein, allerdings erlaubt mir uVison, das setzen von Bits im 
Debug-Modus (Peripherals). Weiss nicht genau was das bewirkt - nen 
Pulsausgang jedoch leider nicht...

von Gerald (Gast)


Lesenswert?

sperrt PSW_IEN = 0 auch die SSC Interrupts, Timer Interrupts, ASC 
Interrupts und die PEC Interrupts?

was ist ein Non Maskerable Interrupt?

kann ein interrupt einen anderen unterbrechen? wie kann man das 
deaktivieren so das die interrupts hintereinander kommen...sonst kann 
man eventuell probleme mit dem stack bekommen wenn ich im interrupt eine 
variable anlege?

lg

von tom (Gast)


Lesenswert?

MAtthias,

Vielleicht hilft Dir etwas grundsätzliches weiter...

Mit diesem uC muss Dein code aus dem RAM laufen wenn Du das über den 
Debugger u. per BSL machst, d.h. Du solltest das RAM ab adresse 0x000000 
mappen (buscon register usw. usf, RTFM !).

Was benutzt DU da ? Keil oder Tasking ?

Warum ?

Per BSL wird der Monitor des debuggers in das RAM geladen (guck nach, 
welcher Speicherbereich dafür reserviert werden muss (also in der 
User-appic excludiert !), ist meist im IRAM), der dann mit dem debugger 
kommuniziert und das eigentliche Nutzer-Programm rauflädt. C167 hat 
keine On Chip Debug Funktionalität, also muss dein code im RAM liegen, 
sonst nix source-level debugging ;-). ISR-table ist ab adresse 0x000000, 
da will/soll Dein Programm ja auch loslaufen, also muss da RAM sein und 
im startup-code deines programmes darfst du dann auch da 
speicherinterface nicht verbiegen (am besten die einstellungen des 
debug-monitors 1:1 übernehmen...).
In deiner applic darfst du auch den NMI und den UART-Interrupt + Rx/Tx 
pins, welche der monitor benutzt nicht benutzen !


Wenn später einmal dein fertiges programm aus dem flash laufen soll, hat 
das einen anderen startup-code, welcher das businterface entsprechend 
mappt  (i.d.R. flash ab adresse 0x0000) !

gruss, tom.

P.S. Fall du selbst ein C167 eva-board haben möchtest kann ich es 
günstig abgeben - mail an: tom at tktronic punkt de

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.