cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 4 MCU

sele_2039411
New Contributor

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
Reply
7 Replies
HeLi_263931
Honored Contributor II

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

0 Likes
Reply
sele_2039411
New Contributor

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
Reply
sele_2039411
New Contributor

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
Reply
sele_2039411
New Contributor

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
Reply
HeLi_263931
Honored Contributor II

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
Reply
JoMe_264151
Expert II

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
Reply
HeLi_263931
Honored Contributor II

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
Reply