PSOC 4 - ARM GCC 4.9 not pushing all ISR's working registers

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

cross mob
sele_2039411
Level 1
Level 1

Hi,

   

I was wondering why my "ARM GCC 4.9-2015-q1-update" does not push all ISR's working registers onto the stack.

   

This obviously causes any kind of random behavior and painstaking debug. I have not seen this behavior before on any other compiler. Below a code snipped of one of my ISRs (r2 and r3 are not pushed onto the stack, but used in the ISR; they are of course also used in the main program).

   

0x00000CA0 <PWM_Drive_ISR>:
 287: * Return: 
 288: *  void
 289: *
 290: *******************************************************************************/
 291: CY_ISR(PWM_Drive_ISR)
 292: {   
0x00000CA0 push    {r4, r7, lr}
0x00000CA2 sub    sp, #c
0x00000CA4 add    r7, sp, #0
 293:     uint16 curTimeStamep = 0;  
0x00000CA6 adds    r3, r7, #6
0x00000CA8 movs    r2, #0
0x00000CAA strh    r2, [r3, #0]
 294:     uint16 curPeriod = 0;
0x00000CAC adds    r3, r7, #4
0x00000CAE movs    r2, #0
0x00000CB0 strh    r2, [r3, #0]

   

What am I missing here? I cannot believe this is a bug, but have no other explanation. Is there any other version of GCC that is available for update in PSOC Creator 4.0 (4.0.0.432).

   

Best,

   

Severin

0 Likes
7 Replies
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Maybe gcc knows that these registers are never used in your code elsewhere? (Unlikely, but my only explanation so far)

0 Likes
sele_2039411
Level 1
Level 1

Hi hli,

   

sure, I was thinking of this too. But as I said, I get a weird behavior in my program as soon as interrupts are enabled. And as said above, in my main code, registers r2 and r3 are also used. So, the compiler should definitely push them onto the stack in any ISR.

   

Best,

   

Severin

0 Likes
sele_2039411
Level 1
Level 1

Hmm, I realize that in CortexM registers r0-r3 are automatically saved on the stack on context switch in ISR. My problem with register corruption must therefore have another origin.

0 Likes
sele_2039411
Level 1
Level 1

I know believe my observation was an artefact due to the debugger. When I run my code without debugging, it works as it should. However, depending on where I set my breakpoints, the results I observe are not as expected...

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Note that stopping the program in the debugger doesn't stop the hardware, so new interrupts might be triggered (and other stuff might happen) during looking at a stopped ISR.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

As a standard the compiler optimization level is set to "Debug". Setting this to "None" is giving better results when debugging.

   

Another tip: When debugging stopped the program, disable the interrupts (there is an icon for that) when you want to single-step. When continue to run, back enable them again.

   

And a last one: I am working with PSoCs for about ten years now and I can assure you that errors in compiler or components are very rare.

   

 

   

Bob

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

a.k.a "Select isn't broken". In my whole delevoper career I have found only compiler bug (and even for that one could have argued that its actually in the accompanying startup code).

0 Likes