XMEGA USBSmart Stack Overflow im ControlJob

1
2
3
4
Page 2 of 4

pvs-deck

PowerUser

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

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 14.03.2018 - 14:24 · #9

Hallo rolf,

danke für die Info

Code

$TASKS_stk_chk          .EQU    02F65h          ; var iData  Process stack area
$TASKS_stk              .EQU    02F67h          ; var iData  Process stack area
$TASKS_stk_e            .EQU    03164h          ; var iData  Process stack area
$TASKS_frm_chk          .EQU    03165h          ; var iData  Process stack area
$TASKS_frame            .EQU    03167h          ; var iData  Process stack area
$TASKS_frame_e          .EQU    03364h          ; var iData  Process stack area

Das ist der Auszug, verstehe ich das richtig:

stk_chk ist das unterste Byte und auch die Adresse die beim CheckStackValid() Verwendung findet oder?

$TASKS_stk: ist dann der eigentliche Adressbegin
und
$TASKS_stk_e: Ist das Ende.

Aber warum wird im laufenden Betrieb immer der "CheckStackValid( ControlJob ) " als Überlauf angezeigt und im PDI-Debugger eben nicht?

Attachments


Filename:	14-03-_2018_14-29-39.jpg
Filesize:	46.43 KB
Title:	so
Information:	so
Download counter:	128

pvs-deck

PowerUser

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

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 14.03.2018 - 15:22 · #10

Hallo rolf,

so habe das ganze mal mit meinem Testprogramm gemacht, löst immer wieder ein Break aus.

Ich bin kein ASM-Profi, wie bekomme ich jetzt den Querverweis auf die Adresse im DisAssembler für meinen Code? oder zumindestens auf den das ASM-Listing. Damit ich das Problem weiter eingrenzen kann.

Ich sende Dir auch mal den Testcode als PM zu, ich habe da das meiste Zeug bereits rausgeschmissen.

In dem Testprogramm ist folgende StackAdresse:

Code

$TASKS_stk_chk .EQU 0293Ah ; var iData Process stack area
$TASKS_stk .EQU 0293Ch ; var iData Process stack area

Er bleibt immer an der selben Stelle im DisAssembler stehen (siehe Bilder)

Attachments


Filename:	14-03-_2018_15-01-30.jpg
Filesize:	46.47 KB
Title:	SetBreak
Information:	SetBreak
Download counter:	116


Filename:	14-03-_2018_15-06-23.jpg
Filesize:	410 KB
Title:	Break
Information:	Break
Download counter:	148

Thomas.AC

Benutzer

Gender: n/a
Age: 43
Posts: 308
Registered: 07 / 2013

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 15.03.2018 - 10:47 · #11

Wer weiß was RCALL -256 da gemacht hat?
Finde mal heraus welcher thread zum Stackpointer (zeigt auf $3851) gehört. Sieht nicht so aus, als ob es der Control-Job Task ist.

pvs-deck

PowerUser

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

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 15.03.2018 - 11:04 · #12

Quote by Thomas.AC

Wer weiß was RCALL -256 da gemacht hat?
Finde mal heraus welcher thread zum Stackpointer (zeigt auf $3851) gehört. Sieht nicht so aus, als ob es der Control-Job Task ist.

Soweit ich das sehe wurde ein Unterprogramm an Adresse 2639 aufgerufen, ich denke dort ist irgendwo der Fehlzugriff passiert. Das kann aber nur ein Treiber/Compilerfehler sein

Hast Du ein Vorschlag, wie ich das herrausfinden kann? Der Disassembler zeigt da leider keine Zuordnung, welcher Treiber / Funktion / Unterprogramm hier diesen Fehlzugriff gemacht hat.

Im ASM-Listing könnte man es Zuordnen, wenn ich irgendwie die Hexadresse zwischen ASM-Code und Disasembler abgleichen könnte. :banghead:

Thorsten

Thomas.AC

Benutzer

Gender: n/a
Age: 43
Posts: 308
Registered: 07 / 2013

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 15.03.2018 - 11:53 · #13

keine Ahnung wie man da am besten vorgeht.

Was ist denn mit dem Stackpointer? Zu welchem Stack gehört die Adresse $3851? Dann weißt man schon mal welcher Thread schuld ist.

Merlin

Administrator

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

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 15.03.2018 - 12:04 · #14

Quote

In the ASM listing, you could assign it if I could somehow match the hex address between ASM code and disasembler.

Rather than using the .ASM file, you could use the .LST file that is produced. This also has the addresses that you need.

pvs-deck

PowerUser

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

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 15.03.2018 - 15:13 · #15

Quote by Merlin

Quote

In the ASM listing, you could assign it if I could somehow match the hex address between ASM code and disasembler.

Rather than using the .ASM file, you could use the .LST file that is produced. This also has the addresses that you need.

@Merlin; Thank you

Die Adresse $2738 ist wohl eine Einsprungadresse für eine "SYSTEM._GraphCmd" Funktion!
Warum diese den Stack vom Task zum überlaufen bringt, bzw. in diesen Bereich schreibt, dazu habe ich keine Ahnung

, da fehlt mir das ASM-Wissen.

Der Sprung vor der RET (Break Marke $2739) vergleicht das Register _ACCBLO mit der Konstante $000h, danach Springt er bedingt an "BRNE" auf SYSTEM._L0498.

Ist damit nun die Zeile 0498 oder die Adresse $0498 gemeint? Oder ist damit die folgende Sprungmarke gemeint an Adresse.

Code

13033  263C            SYSTEM._L0498:
13034  263C       30A1                         CPI       _ACCBLO, 001h
13035  263D       F449                         BRNE      SYSTEM._L0499
13036  263E       E0A0                         LDI       _ACCBLO, 00800h AND 0FFh
13037  263F       E0B8                         LDI       _ACCBHI, 00800h SHRB 8
13038  2640       E3EA                         LDI       _ACCCLO, GraphColArr AND 0FFh
13039  2641       E2F1                         LDI       _ACCCHI, GraphColArr SHRB 8
13040  2642            SYSTEM._L0505:
13041  2642       9321                         ST        Z+, _ACCALO
13042  2643       9711                         SBIW      _ACCBLO, 01h
13043  2644       F7E9                         BRNE      SYSTEM._L0505
13044  2645       EF1F                         SER       _ACCA
13045  2646       9508                         RET
13046  2647            SYSTEM._L0499:

Wenn ich das richtig verstehe "13041 2642 9321 ST Z+, _ACCALO", kopiert er hier die Daten an das Z-Register und das Z-Register hat zu dem Zeitpunkt die Adresse des TaskStack_Check $293A.

Das ganze spielt sich im Process "LCD_Displ" ab, dieser hat aber einen eigenen Stack / FRAME.

@rolf; Hier scheint ein BUG vorhanden zu sein, die GraphicFunctionen dürften doch gar keinen Zugriff auf den TaskStack haben, oder?

Ich lege mal das .lst hier im Anhang rein, ist sowieso nur ein gekürztes Test-Programm.

Thorsten

Attachments


Filename:	pvs2018_Test_CPU_LST.zip
Filesize:	168.68 KB
Title:	Das ist die Datei pvs2018_Test_CPU.lst
Information:	Das ist die Datei pvs2018_Test_CPU.lst
Download counter:	30

Thomas.AC

Benutzer

Gender: n/a
Age: 43
Posts: 308
Registered: 07 / 2013

Subject:

Re: XMEGA USBSmart Stack Overflow im ControlJob

· Posted: 15.03.2018 - 19:20 · #16

Puh, meiner Meinung wird hier 2938h in das Z_Register geschrieben.

Code

13046  2647            SYSTEM._L0499:
13047  2647       01F8                         MOVW      _ACCCLO, _ACCB
13048  2648       5CE6                         SUBI      _ACCCLO, -0213Ah AND 0FFh
13049  2649       4DFE                         SBCI      _ACCCHI, -0213Ah SHRB 8

Hier wird das Registerpaar _ACCB und _ACCA in das Z-Register geladen und dann 213Ah addiert
_ACCB und _ACCA wurden vorher durch Aufruf von SYSTEM._GraphCalcAdr gesetzt.

Gut möglich, dass bereits bei SYSTEM._GraphCalcAdr eine falsche Adresse berechnet wurde.
Keine Ahnung, wann so etwas passieren könnte. Kenne das LCDGraph nicht.

1
2
3
4
Page 2 of 4

XMEGA USBSmart Stack Overflow im ControlJob

Attachments

Attachments

Attachments

Registered users in this topic