Stack pointer value does not change in application

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Markus00
Level 1
Level 1
First like given 5 sign-ins First reply posted

Hello,
I am new to the Aurix processors and I am currently evaluating an Aurix TC387QP.
I use the Aurix Dev Studio.

I have tested several demo applications from the GIT repository, for example the "Multicore_1_KIT_TC387_TFT" and the "Blinky_LED_1_KIT_TC387_TFT".
The applications work fine and they to what they should do.

But when I connect to the target with the onboard debugger and would like to view the stack pointer register (A10), it does not change its value.
It is correctly initialized to 0x70039600 (core 0) but it does not change even when I step through several function calls.
The other registers work fine in the debug view so (IMHO) it should not be an debugger issue.

The same issue occurs for the other cores.
The stack pointers do have the correct initial values but do not seem to change their values.

Thank you,
Markus

0 Likes
1 Solution
Di_W
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 250 solutions authored

Hi Markus,

The workaround I tested is for a function call with parameters like:

 

 

funcTest1(int a,int b, int c)
{
    int tmp[3];
    tmp[0]=a;
    tmp[1]=b;
    tmp[2]=c;
}

 

 

 Then you can see the change of A10 in Position 2 of last thread.

In assembly code, you could find lines with [SP] name inside, generally it predicts an A10 change.

dw

View solution in original post

0 Likes
4 Replies
Di_W
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 250 solutions authored

Hi Markus,

The phenomenon you found will be reported to development team for investigation. Thank you for your report.

A workaround I found is as below, if you found Position 1 has no change, then you could Watch the A10 register, and then monitor the change in Position 2. As I seen, it works for stack operations: push in/pop up.

dw_0-1657765202000.png

dw

0 Likes
lock attach
Attachments are accessible only for community members.
Markus00
Level 1
Level 1
First like given 5 sign-ins First reply posted

Hello dw,
thank your for your quick reply.

I already tried that solution before and unfortunately it does not work, too.
It displays the same constant value.

Maybe it is also my wrong understanding of the TriCore/Aurix processor architecture but on every other platform I have used so far, every C function called (which is not an inline function or an quasi-inline function by compiler optimizations) should cause the stack pointer to in- or decrease (dependend on platform type).

(IMHO) at least the jump from the (generated) Aurix Dev Studio init code to the "core_main0" function should change the stack pointer value.

I have added 2 screenshots displaying the state before and after the jump.
I used the "Multicore_1_KIT_TC387_TFT" demo application.

I also have not found a single instruction fetching or storing data from/to the A10 register in the near assembly code which is (IMHO) also quite "strange.

Thank you,
Markus

0 Likes
Di_W
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 250 solutions authored

Hi Markus,

The workaround I tested is for a function call with parameters like:

 

 

funcTest1(int a,int b, int c)
{
    int tmp[3];
    tmp[0]=a;
    tmp[1]=b;
    tmp[2]=c;
}

 

 

 Then you can see the change of A10 in Position 2 of last thread.

In assembly code, you could find lines with [SP] name inside, generally it predicts an A10 change.

dw

0 Likes
Markus00
Level 1
Level 1
First like given 5 sign-ins First reply posted

Hi dw,
thanks for that example - that solved that problem.
With that example (the last assignment has to be tmp[2] instead of tmp[3] 😉 I was able to see both, the stack pointer and stack content, changing.

Nevertheless I am a bit confused because I have some custom C functions with 4+ (value) parameters and 3+ local variables that do not use the stack at all but use the GPR registers and memory accesses instead.

Thank you,
Markus

0 Likes