- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maybe gcc knows that these registers are never used in your code elsewhere? (Unlikely, but my only explanation so far)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).