Applikation haengt am Return

[Andi (Gast)]

Hi

ich benutze Keil uvison 4 und dort den debuger. Ich habe folgendes 
Problem:

Bei einigen Funktionen haengt sich mein programm auf. Was ich im 
Debugger sehe ist, dass er Program-Pointer immer an der selben Stelle 
haengt und nicht zurueckspringt aus der Funktion. Woran koennte sowas 
liegen?

Im dissembley steht:

  1490:    return(0);
0x08003F10 2A01      CMP      r2,#0x01
0x08003F12 DA01      BGE      0x08003F18
0x08003F14 2000      MOVS     r0,#0x00
  1491: }
  1492:
...
..


danach passiert aber nix mehr.

[Peter D. (peda)]

Sieht irgendwie nicht nach 8051 aus.

Wie wärs, mal wenigstens Compiler und Target zu benennen.

[Andi (Gast)]

GNU und STM32f103 (Cortex m3)

[Karl H. (kbuchegg)]

Andi schrieb:

> haengt und nicht zurueckspringt aus der Funktion. Woran koennte sowas
> liegen?

Am restlichen Code, den du nicht gezeigt hast

[Andi (Gast)]

es ist relativ viel code :(..

viel mehr wuerde mich interessieren woran es liegen KANN und wie ich das 
am besten "erforschen" kann. Glaube nicht, dass mir hier jemand direkt 
sagen kann woran es genau liegt.

folgendes kann ich aber noch sagen.

Ich habe einen Bootloader der bei 0x08000000 bis 0x08003000 liegt.

Mein projekt startet ab 0x08003000.. ich springe vom bootloader in die 
main meines programs. Ein einfaches programm laeuft auch ganz normal 
(z.b. endlos while mit paar additionen).

Benutze ich ein komplexes projekt haengt es an einigen Funktionen die 
relativ am anfang sind. Wenn ich eine Funktion auskommentiere an der es 
haengt.. haengt es an einer weiteren. Es sind alles return Funktionen.

koennte das etwas mit Interrupts zu tun haben?

Wichtig waere fuer mich einfach eine Moeglichkeit das zu debugen

[Karl H. (kbuchegg)]

Andi schrieb:
> es ist relativ viel code :(..
>
> viel mehr wuerde mich interessieren woran es liegen KANN

indem man zum Beispiel irgendwo den Stack niedergebügelt hat. Zum 
Beispiel mit Array-Zugriffen, die ausserhalb des erlaubten Bereichs 
liegen. Zum Beispiel mit String Operationen, die wieder ausserhalb des 
zugewiesenen Speichers irgendwelche Bytes verändern.


> koennte das etwas mit Interrupts zu tun haben?

möglich ist alles. Wenn du tatsächlich irgendwo den Stack zerschossen 
hast, kann man überhaupt nichts mehr ausschliessen. Die eigentliche 
Ursache muss noch nicht mal in der Nähe der bewussten Funktion bzw. des 
return sein.

[Andi (Gast)]

Den Stack zerschossen habe ich glaub ich nicht. Die Applikationen laufen 
ohne Bootloader ganz normal durch (evtl ein wichtiges Detail).

Es sieht manchmal so aus als ob der PC einfach irgendwo haengt.... wie 
kann er sich einfach so festbeissen? Er springt nicht herum.. laeuft 
eigentlich immer ganz genau den Programmcode ab nur irgendwann bleibt er 
einfach stehen.

[Karl H. (kbuchegg)]

Andi schrieb:
> Den Stack zerschossen habe ich glaub ich nicht.

Na dann eben nicht.
Es ist deine Entscheidung

[Andi (Gast)]

ich sage.. glaube :)

und anders gefragt.. wie kann ich das checken?

[Uwe (Gast)]

> wie kann ich das checken?
Wenn beim return was schiefgeht ist der Stackpointer nicht in Ordnung.

[amateur (Gast)]

Wenn hier gesagt wurde: Den Stack zerschossen, bedeutet das, dass der 
Stackpointer das einzige ist was noch stimmt. Der Inhalt ist hinüber und 
das ist ganz normales RAM.
Wenn z.B. eine Unterfunktion beendet wird und die Heimatadresse nicht 
mehr stimmt, so ist das Programm recht gutgläubig in nimmt das was da 
ist. Und tschüss.

[Andi (Gast)]

So langsam denke ich.. es liegt am stackpointer.

hab noch bei den Fault Reports (auf die haette man mich hinweisen 
muessen :-)) einen Hacken bei Memory Manage Faults:

"IACCVIOL" =  instruction access violation der direkt auftritt wenn ich 
in vom bootloader in die main springe.

Der Stckpointer haengt dann, wenn bei Busfaults folgende Hacken gesetzt 
sind:

PRECISERR
IMPRECISERR
STKERR


Erklaerung zu den Fehlern.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Cihcfefj.html

Nun muss ich wohl scheinbar rausfinden warum der Prozessor diese Flags 
setzt.

Meine Scatter files:

Von der eigentlichen App:
LR_IROM1 0x08003000 0x0001D000  {    ; load region size_region
  ER_IROM1 0x08003000 0x0001D000  {  ; load address = execution address
   .ANY (+RO)
  }
  RW_IRAM1 0x20000000 0x00005000  {  ; RW data
   .ANY (+RW +ZI)
  }
}

Vom Bootloader:

LR_IROM1 0x08000000 0x00003000  {    ; load region size_region
  ER_IROM1 0x08000000 0x00003000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
  }
  RW_IRAM1 0x20000000 0x00005000  {  ; RW data
   .ANY (+RW +ZI)
  }
}

Koennte mir vorstellen, dass hier irgendwas nicht stimmt.

[Andi (Gast)]

Ach ja.. hat echt mit dem Scatterfile zu tun.. hab nun:

   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)


bei beiden eingefuegt .. nun klappt alles wunderbar.