C-Programm auf XC866 'verzählt' sich

[Ampfing]

Nichts zu danken.
Ehrlich gesagt würde ich schon auch gerne wissen, warum es nicht funktioniert. Hab mich jetzt - voerst! - mal mit dieser Lösung abgefunden, damit ich an meinem restlichen Problem weiter machen kann. Endgültig begraben habe ich das Ganze aber noch nicht.
Also wenn du mit deiner Frage meinst, ob eine Beeinflussung der 2^7-Leitung durch den Strobe stattfinden kann, dann muss ich sagen: elektrisch nicht! Ich habe die Leitungen extra nochmal durchgepiepst und sie sind nicht verbunden. Ist halt ein ganz normales Flachbandkabel. Wäre mir neu, dass sich da die Leitungen gegenseitig beeinflussen. Und vor allem, es passiert ja nur (und ausschließlich!), wenn im 1. Byte das 8. Bit gesetzt ist. Bei allen anderen Bytes ja nicht. Wenn es wirklich ein elektrisches Problem wäre müsste das doch bei allen Bytes auftreten und nicht nur beim Ersten, oder?

Viele Grüße

[PicNick]

Tscha, erst wenn wir wissen, was es ist , wissen wir, was es NICHT ist, vorher kannst du nur spekulieren.
Es ist ja so, daß beim 2.Isr von dem 2^7 vom 1. ja weit und breit keine Rede mehr ist. Weiters ist durch einen Überspruch eher ein Level-Interrupt gefährdet, und kein Flanken-fuzzy. Immerhin muß die Strobe Leitung ja erstmal runter und dann erst wieder rauf, die Datenleitungen sind während der Flanke aber stabil.
Die einzige Stelle, wo das 128-er Bit überlebt, ist ja time1 und wie soll das beim 2.ISR eine Rolle spielen
Der Inhalt des Datenbytes beim 2.ISR ist ja offensichtlich wurst.
Deswegen bin ich ja überzeugt, daß der Hund im Programm liegt und nicht in der Physik (Dort liegt er meistens).
Na wie auch immer, wir lassen uns das von einem bescheuerten Silzium-plättchen nicht bieten. schaun wir mal.

[Ampfing]

Genau das ist ja mein Problem. Ich sehe nicht, wie das 1. Byte überhaupt Einfluss auf den Interrupt des zweiten Bytes nehmen könnte!
Der Interrupt geht definitiv auf die Flanke, nicht auf den Zustand (geht bei dem Interrupt-Kanal nämlich gar ned anders). Und auf meinem Oszi-Bild ist definitiv nur eine Flanke beim 2. Byte drauf. Insofern stimme ich dir also zu, dass es nicht von der Physik kommen KANN.
Was mir wie gesagt noch eingefallen ist: Wenn das 2^7-Bit gesetzt ist, dass er sich dann irgendwie das Register IRCON0 (beinhaltet die IR-Bits für meine Interrupts - und zwar alle, nicht nur den Trigger) überschreibt und dadurch das IR-Bit setzt. Das Problem an der Theorie ist halt, dass IRCON0 (0xB4) von der Adresse her nichtmal in der Nähe von time1 (0x0B) liegt. Außerdem würde er mir ja dann jetzt auch noch einen anderen Interrupt (Interrupt 8 mit ISR ShootISR) auslösen. Und das tut er definitiv nicht. Hatte ja auch mal den Trigger-Interrupt auf den Kanal 8 gelegt (zum Testen) und er wurde trotzdem ausgelöst.
Diese Theorie ist also wohl auch nicht haltbar fürchte ich.
Was kann denn noch Ursache für so nen dummen Interrupt sein? Ich dachte immer nur ein IR-Bit oder ein externes Ereignis, aber offensichtlich noch mehr...

[PicNick]

Ich hab mir die XC866-Doku runtergezogen und versucht, aus der gemappten-Memory-Bank-Extension Philosophie schlau zu werden (diese Bank-Orgie geht mir, ehrlich gesagt, auch bei den PIC... auf den Geist)
Verdacht: Ich seh in der Disassemblerliste keine Stack-Pointer festlegung. (das muß nix heißen) ABER:
Lt. Datasheet ist der SP initial mit 0x07 definiert. Das wäre saumäßig. denn durch die volatile -definition hat der Compiler auch time1----etc. alles da unten addressiert.
Spekulation: 0x80 und größer (kleiner nicht) sind mögliche Flash-Addressen. wenn du also in den Clinch mit dem Stack kommst und ihm eine 0x80.. addresse als return reinschreibst, kommt auch so ein Gefuddel dabei raus (2.ISR)
Ein sinnvoller werte für den SP wäre z.B. 7F (RAMEND)

Es kann aber sein, daß der C in der disassemblerliste nur seine SP-definition unterschlagen hat, dann isses natürlich wieder nix.
Mach dich einmal beim C-Manual /Workbench schlau, wie denn das so ist mit dem SP, in den Infineon Unterlagen steht da natürlich nix.
*seufz*

[Ampfing]

Hallo Robert,

hm, wenn ich das mal geahnt hätte...
Ich habe - wie von Infineon mit ihrem Easy-Kit empfohlen - eine StartUp-Routine in mein Projekt integriert. Diese wird natürlich zum Code dazugebunden und vor meiner main ausgeführt. Dort habe ich auch einen Eintrag für den SP gefunden.
Weiter unten findest du zum einen den Code der StartUp, zum anderen eine Übersicht über die Adresse, wo der SP hininitialisiert wird (0x20, was direkt in meinen Interrupt-Vektoren liegt!). Wie kommt Keil drauf, den einfach mal so dahin zu legen? Die müssten doch auch wissen, dass in der Gegend die IR-Vektoren liegen, oder??
Ich weiß ja nicht, ob es wirklich daran liegt, aber kann ich den Eintrag einfach so verändern - ohne, dass mein Programm dann gar nicht mehr läuft?
Wobei ich dann immer noch nicht wirklich den Grund erkennen kann, warum es nur beim 1. Byte schiefgeht und warum er nur den einen Interrupt zweimal ausführt (schließlich liegen auf Adressen näher an 0x20 noch 2 andere IR-Vektoren)!?

Startup:

                 STARTUP1:
C:0x09BD    787F     MOV      R0,#0x7F
C:0x09BF    E4       CLR      A
                 IDATALOOP:
C:0x09C0    F6       MOV      @R0,A
C:0x09C1    D8FD     DJNZ     R0,IDATALOOP(C:09C0)
C:0x09C3    90F000   MOV      DPTR,#0xF000
C:0x09C6    7F00     MOV      R7,#0x00
C:0x09C8    7E02     MOV      R6,#0x02
C:0x09CA    E4       CLR      A
                 XDATALOOP:
C:0x09CB    F0       MOVX     @DPTR,A
C:0x09CC    A3       INC      DPTR
C:0x09CD    DFFC     DJNZ     R7,XDATALOOP(C:09CB)
C:0x09CF    DEFA     DJNZ     R6,XDATALOOP(C:09CB)
C:0x09D1    758120   MOV      SP(0x81),#0x20
C:0x09D4    02086F   LJMP     main(C:086F)

Memory:

C:0x0020    00       NOP      
C:0x0021    00       NOP      
C:0x0022    00       NOP      
C:0x0023    00       NOP      
C:0x0024    00       NOP      
C:0x0025    00       NOP      
C:0x0026    00       NOP      
C:0x0027    00       NOP      
C:0x0028    00       NOP      
C:0x0029    00       NOP      
C:0x002A    00       NOP      
C:0x002B    02092A   LJMP     T2ISR(C:092A)
C:0x002E    00       NOP      
C:0x002F    00       NOP      
C:0x0030    00       NOP      
C:0x0031    00       NOP      
C:0x0032    00       NOP      
C:0x0033    00       NOP      
C:0x0034    00       NOP      
C:0x0035    00       NOP      
C:0x0036    00       NOP      
C:0x0037    00       NOP      
C:0x0038    00       NOP      
C:0x0039    00       NOP      
C:0x003A    00       NOP      
C:0x003B    00       NOP      
C:0x003C    00       NOP      
C:0x003D    00       NOP      
C:0x003E    00       NOP      
C:0x003F    00       NOP      
C:0x0040    00       NOP      
C:0x0041    00       NOP      
C:0x0042    00       NOP      
C:0x0043    0208D3   LJMP     ShootISR(C:08D3)
C:0x0046    00       NOP      
C:0x0047    00       NOP      
C:0x0048    00       NOP      
C:0x0049    00       NOP      
C:0x004A    00       NOP      
C:0x004B    020800   LJMP     TriggerISR(C:0800)

Außerdem sind in der Startup folgende Dinge eingestellt:

• IDATA memory length 0x0080
  XDATA memory start address 0xF000
  XDATA memory length 0x0200
  PDATA memory start address 0x0000
  PDATA memory length 0x00

Und es gäbe einen Eintrag "Reentrant Stack Initialization", bei dem man für das SMALL, LARGE und COMPACT-Modell jeweils "top of stack" einstellen kann.

In den Projekteinstellungen habe ich noch folgende Zeile gefunden:
Code(C:0x0-c:0x2fff, c:0xa000-c:0xafff), XDATA(X:0xf000-X:0xf1ff)

Wenn du jetzt sagst "Mensch, warum schreibt der das denn nicht gleich, dann hätten wir das Problem in 5 Minuten gelöst gehabt!", dann muss ich mich entschuldigen, aber auf solche Zusammenhänge wäre ich wahrscheinlich in 5 Jahren nicht gekommen. Zu meiner Verteidigung sei gesagt, dass das erst der 2. Microcontroller ist, den ich bislang programmiere. Wir hatten das Fach an der Schule und davor habe ich noch nie was von C - oder gar Assembler! - gehört gehabt...

Viele Grüße
Michael

[PicNick]

Du brauchst dich weder zu entschuldigen noch zu verteidigen, ich programmier jetzt 25 Jahre und bin noch immer jederzeit imstande, absoluten Schwachsinn zu produzieren.
Bei den kleinen Kisten ist ein Stack/Daten Konflikt immer leicht möglich.
Aber jetzt schau'n wir erstmal, ob's wirklich daran liegen kann.
Die Hoffnung stirbt zuletzt.
EDIT Code verändern: Alles sichern und in der Kopie rumzangeln, was du willst. Nie mehr als eine Sache verändern (beim probieren), druch falschen Code kann der Chip nicht abrauchen, also nur der Himmel ist die Grenze.

[Ampfing]

Du brauchst dich weder zu entschuldigen noch zu verteidigen, ich programmier jetzt 25 Jahre und bin noch immer jederzeit imstande, absoluten Schwachsinn zu produzieren.

Danke. Schwachsinn zu produzieren ist ja auch gar nicht das Problem, sondern eher sinnvolle Programm, oder?

Okay, hab jetzt also in der Startup den SP mit 7F initialisiert. Und siehe da, das Problem besteht weiterhin...
Genau das selbe Phänomen. Hab auch nochmal im Speicher nachgeschaut, in der Gegend von 7F ist weit und breit nix (außer NOPs natürlich) - hab so bis Adresse 0x130 geschaut oder so.
Das wars dann wohl leider auch nicht...

[PicNick]

Ist auch gut. Jede Fehlerquelle, die man ausschließen kann, wollen wir als Erfolg betrachten.
Ich muß jetzt schauen, ob man als Programm erkennen kann, ob man in einer ISR ist oder nicht. Wär fein, damit wir das vom Tisch haben.
(?Schauen, ob (IRCON0 & 8 ) überhaupt gesetzt ist, und wenn nicht, was dann ?)

Um endgültig die Hardware draußen zu haben:
Schicke >127, schreib's aber nicht nach Time1
Schicke <127, schreib's aber 128 nach Time1
Fehler bei 1 --> HW
Fehler bei 2 --> SW

Einkreisen Time1/Speicheradresse : Füg hinten noch ein Byte an (Zzz1) und verwende es anstatt Time1 (der platz von time1 soll aber belegt bleiben)

Checken Counter: fang mal mit 1 an und zähl von dort rauf.
ev. dasselbe machen wie mit Time1

Ich überleg noch, warum er ausgerechnet diese ISR ganz vorne eingeschlichtet hat, alle andern aber irgendwo (muß nix heißen)

[Ampfing]

Hallo Robert,

es war natürlich doch die Hardware...

Moment, mir fällt gerade was ein.
Erstmal was ich gerade noch gedacht habe: P3.7 ist gleichzeitig als Alternativbelegung der externe Interrupt 4. Die ext. IR 3-6 teilen sich einen IR-Vektor und damit eine ISR!! Man kann auch nur alle 4 IR freigeben oder sperren, nicht einzeln. Deswegen dachte ich, würde er die gleiche ISR nochmal anspringen.
Dann ist mir aber der Knackpunkt aufgefallen: Ich habe ja auch versucht einen anderen Interrupt zu nehmen. Und das war der ext. IR 2! Der hat aber ein extra Enable bit und teilt sich mit niemandem seine ISR! Und das Phänomen ist trotzdem aufgetreten.
Also kann es das doch fast auch nicht sein, oder?
Außerdem habe ich mal gemacht, was du vorgeschlagen hast. Es wird jedesmal (!) definitiv das IR-Bit des ext. IR 3 gesetzt (hab ich mit IRCON0 & 8 ausprobiert).
Das ist dann wohl der Todesstoß für diese Theroie...

Hab auch das mit <127 und so ausprobiert.
Wenn ich >127 schicke und nicht nach time1 schreibe ruft er trotzdem zweimal die ISR
Schicke ich <127, schreibe aber 128 in time1 ruft er die ISR nur einmal. Heißt also wohl oder übel doch die HW. (insofern stimmt wenigstens der erste Satz noch )

Leider muss ich mich jetzt auch schon wieder auf den Heimweg machen (ich würde wirklich gerne weiterbasteln, aber ich hab noch was vor...). Bin aber natürlich weiterhin dankbar für jede Anregung und setze sie gleich morgen früh um (nehm mir für morgen abend mal nichts vor, damit ich für den Fall der Fälle auch länger machen kann!).

Viele Grüße nach Wien und einen schönen Abend noch
Michael

[PicNick]

So vergeht die Zeit, wenn man Spaß hat.
Die Frage ist ja, wieso wiederholt er den ersten Interrrupt nicht. Wir müssen einkreisen, welcher Interrupt nun was tut. In welchen Zeitabständen kommt denn der Strobe ?