XMEGA USBSmart Stack Overflow im ControlJob

1
2
3
4
Page 3 of 4

Administrator

Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 16.03.2018 - 10:56 · #17

Hallo,

mit "SYSTEM.Lxxxx" ist ein Label gemeint, aber keine Adresse und auch keine Zeile.

rolf

Administrator

Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 16.03.2018 - 12:45 · #18

Hallo Thorsten,

Dein Test Programm funktioniert bei mir auf dem XMega Board.
Auch im ICE habe ich keine Probleme. Nur im SIM gibt es Probs.
Kommt wahrscheinlich daher dass der SIM mit dem USB nix anfangen kann.

rolf

pvs-deck

PowerUser

Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1340
Registered: 02 / 2009

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 16.03.2018 - 14:47 · #19

Quote by rh

Dein Test Programm funktioniert bei mir auf dem XMega Board.
Auch im ICE habe ich keine Probleme. Nur im SIM gibt es Probs.
Kommt wahrscheinlich daher dass der SIM mit dem USB nix anfangen kann.

Kein Fehlerhafter Zugriff auf den TaskStack-Bereich? hmm...
Beim Stop auf dem Bild sieht man doch eigentlich klar, das im Bereich des Display-Process (StackPtr 3851) im Z-Reg die Adresse auf den Stack des Task gesetzt wurde, bevor der Stop ausgelöst wurde.

Ich bekomme dauerhaft immer wieder den CheckStackValid() als Überlauf angezeigt und der Freie Stack-Speicher ist "-1"

Kann ich einen Stop auf das ZReg legen? Damit ich herausfinden kann, wo und wann die Adresse 293A ins ZReg geschrieben wird?

Thorsten

Attachments


Filename:	14-03-_2018_15-06-23.jpg
Filesize:	431.59 KB
Title:	Stack
Information:	Stack
Download counter:	51

Merlin

Administrator

Gender:
Age: 24
Posts: 1373
Registered: 03 / 2005

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 16.03.2018 - 15:49 · #20

Hi Thorsten.

The ZReg comprises 2 registers, _ACCCLO and _ACCCHI. But even if you can put a stop on these locations it will not really help, because they change all the time. Besides, 293Ah ($TASKS_stk_chk) is loaded to these registers whenever you call CheckStackFrame, so you may be chasing a red herring.

pvs-deck

PowerUser

Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1340
Registered: 02 / 2009

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 16.03.2018 - 16:22 · #21

Quote by Merlin

Hi Merlin,
ok, I can see that. But since I do not access the task stack with any of my functions or routines, either directly or indirectly. Can it really only be a driver problem during compilation or it is loaded at runtime a wrong address from one of the graphic functions.

At the stop, I can see that this is happening in the display process. The system is running, but always shows stack overflow.

It is then only a matter of time until the malfunction occurs during operation. So the faulty memory access has to get out of this!

Any idea how I could find this mistake?

Thorsten

pvs-deck

PowerUser

Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1340
Registered: 02 / 2009

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 16.03.2018 - 16:48 · #22

@rolf;

Die Meldung / Anzeige im Debugger kommt nicht mehr, das ist richtig!

Bitte beachte aber mal:

Code

   iControlJob := CheckStackValid( ControlJob ); // Ist Immer $FFFF
   wControlJob := GetTaskStackFree;  // zeigt rund 500 an
   BControlJob := ( iControlJob = $FFFF);  // ist immer TRUE

Gruß
Thorsten

Merlin

Administrator

Gender:
Age: 24
Posts: 1373
Registered: 03 / 2005

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 16.03.2018 - 17:33 · #23

I am sorry, I don't.

But knowing how the system works I would be looking for something like a buffer overrun. The buffer immediately below the stack areas is GraphColArr, so I would be looking at anything that sets elements of that to $FF. The space allocated to that array is 2K (2048 bytes) so any +1 error would overwrite the task area, and certainly cause problems. (Well, strictly needs to be more than +1 to actually cause problems).

But the only places that I can find this array referenced are in the system routines system.gDispRefresh and System._GraphCmd. _GraphicCmd(1) does initialise the entire 2K, but I can't see any obvious overrun there. Similarly system.gDispRefresh treats the display as 32*64 bytes, a more likely place to see a problem, but again, it looks OK to me.

So all of that is no help at all!

It does kind of support your suspicions that it may be in the graphic area. Maybe something like trying to draw off the edge of the screen or something like that.

The other possibility is that it really is a stack overflow, for example caused by unbalanced PUSH and POP somewhere, but it doesn't sound like that if it is immediate, and if the stack grows downwards through memory so I would expect to maybe see weird artifacts on the display just before it fails. You could check that by looking at sph and spl (this is where the current stack pointer is stored). It will of course behave erratically, but if the general trend is in one direction then you have a problem. Unfortunately it gives no clue as to where.

Sadly in any system this kind of problem is a nightmare to track down.

Sorry I can't be of more help.

pvs-deck

PowerUser

Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1340
Registered: 02 / 2009

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 16.03.2018 - 21:28 · #24

Hallo rolf,

ich habe die fehlerhafte Funktion eingekreist, bitte kontrolliere mal Deine Funktion
"gClearView(wmClrPix);"

Diese schreibt über den GraphColArr, so wie es aussieht wohl nicht viel. Aber ich bin wie gesagt kein ASM Programmierer.

Vielleicht hat es was mit der Pixcel Anzahl zu tun? Schleifenfehler?

Code

// LCD-Display-Daten
  LCDGraphic     = 256,64, 8;               { x-pix, y-pix, accesswidth        }
  LCDgraphMode   = readonly, iData;

// LCDgraphMode   = column, iData;
  DefCharSet     = 'Graphchars.pchr';
  GViewports     = 1, iData;                { logical ViewPorts, scalings      }
  TGraphStr      = 24;

Beim Fuß hatte ich noch 262 anstelle von 255 drinnen (war noch aus den ersten Versuchen).
Sobald man hier über den echten Wert kommt schreibt der Graphics-Treiber über seinen Speicher, wahrscheinlich nur eine Adresse weiter.

Habe die Funktion bei mir rausgenommen und lösche den Bildschirm mit

Code

gFillRect(0,0,255,63,$00);

Also hat die Lösung für mich erstmal ein paar Tage zeit

War jetzt ne Menge Arbeit, aber jetzt bin ich mir wenigstens sicher, dass ich keinen STACK Überlauf habe.

Thorsten

Attachments


Filename:	16-03-_2018_20-47-40.jpg
Filesize:	66.76 KB
Title:	Puffer
Information:	Puffer
Download counter:	30

1
2
3
4
Page 3 of 4

XMEGA USBSmart Stack Overflow im ControlJob

Attachments

Attachments

Registered users in this topic