[Bug 1001124] New: Cortex M - stack corruption

[Bug 1001124] New: Cortex M - stack corruption

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001124

           Summary: Cortex M - stack corruption
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: normal
          Priority: low
         Component: HAL
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: ecos@hotmail.co.uk
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


It is possible to corrupt the stack during the board initialisation when
compiling a ROM application with the KERNEL package.

The RTC clock is started from cyg_hal_invoke_constructors() and, at this point,
the main stack pointer (MSP) and the thread stack pointer (PSP) are equal. In
case the eCos scheduler has not switched the PSP to a thread stack before the
first RTC interrupt happens, the stack get corrupted. This typically happens if
you have some debugging diag_printf in some of the constructors.

Christophe

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001124] Cortex M - stack corruption

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001124

--- Comment #1 from Christophe Coutand <ecos@hotmail.co.uk> 2011-01-20 18:09:15 GMT ---
Created an attachment (id=1091)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1091)
Fix stack corruption

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001124] Cortex M - stack corruption

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001124

Nick Garnett <nickg@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickg@ecoscentric.com

--- Comment #2 from Nick Garnett <nickg@ecoscentric.com> 2011-01-21 10:48:48 GMT ---
Christophe,

This is not right. It would leave the interrupt stack pointing to halfway
through the stack area. Since the interrupt stack is usually placed in on-chip
SRAM, this wastes some precious memory.

I am also not sure how you get any interrupts before the first context switch
moves to a real thread stack. The context switch code changes stack before
setting BASEPRI, which is when the first interrupt may occur. You should not be
getting any interrupts or exceptions before this point, if you are then I
suspect you have accidentally enabled interrupts in some piece of
initialization code.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001124] Cortex M - stack corruption

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001124

--- Comment #3 from Christophe Coutand <ecos@hotmail.co.uk> 2011-01-21 11:08:43 GMT ---
Hi Nick,

I have misunderstood hal_switch_state_vsr and the interrupt masking principle.
I thought hal_switch_state_vsr was moving PSP not MSP...

My initial undertanding was that masking interrupts with the BASEPRI register
was not stopping the system interrupt like the RTC interrupt from SysTick to
happen. I have to find out why I get the RTC interrupt.

Thanks,
Christophe

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001124] Cortex M - stack corruption

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001124

Christophe Coutand <ecos@hotmail.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |NOTABUG

--- Comment #4 from Christophe Coutand <ecos@hotmail.co.uk> 2011-01-23 08:58:43 GMT ---
Wrong setting of CYGNUM_HAL_CORTEXM_PRIORITY_MAX was causing interrupt to
happen..

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001124] New: Cortex M - stack corruption

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001124

           Summary: Cortex M - stack corruption
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: normal
          Priority: low
         Component: HAL
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: ecos@hotmail.co.uk
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


It is possible to corrupt the stack during the board initialisation when
compiling a ROM application with the KERNEL package.

The RTC clock is started from cyg_hal_invoke_constructors() and, at this point,
the main stack pointer (MSP) and the thread stack pointer (PSP) are equal. In
case the eCos scheduler has not switched the PSP to a thread stack before the
first RTC interrupt happens, the stack get corrupted. This typically happens if
you have some debugging diag_printf in some of the constructors.

Christophe

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001124] Cortex M - stack corruption

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001124

--- Comment #1 from Christophe Coutand <ecos@hotmail.co.uk> 2011-01-20 18:09:15 GMT ---
Created an attachment (id=1091)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1091)
Fix stack corruption

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001124] Cortex M - stack corruption

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001124

Nick Garnett <nickg@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickg@ecoscentric.com

--- Comment #2 from Nick Garnett <nickg@ecoscentric.com> 2011-01-21 10:48:48 GMT ---
Christophe,

This is not right. It would leave the interrupt stack pointing to halfway
through the stack area. Since the interrupt stack is usually placed in on-chip
SRAM, this wastes some precious memory.

I am also not sure how you get any interrupts before the first context switch
moves to a real thread stack. The context switch code changes stack before
setting BASEPRI, which is when the first interrupt may occur. You should not be
getting any interrupts or exceptions before this point, if you are then I
suspect you have accidentally enabled interrupts in some piece of
initialization code.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001124] Cortex M - stack corruption

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001124

--- Comment #3 from Christophe Coutand <ecos@hotmail.co.uk> 2011-01-21 11:08:43 GMT ---
Hi Nick,

I have misunderstood hal_switch_state_vsr and the interrupt masking principle.
I thought hal_switch_state_vsr was moving PSP not MSP...

My initial undertanding was that masking interrupts with the BASEPRI register
was not stopping the system interrupt like the RTC interrupt from SysTick to
happen. I have to find out why I get the RTC interrupt.

Thanks,
Christophe

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001124] Cortex M - stack corruption

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001124

Christophe Coutand <ecos@hotmail.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |NOTABUG

--- Comment #4 from Christophe Coutand <ecos@hotmail.co.uk> 2011-01-23 08:58:43 GMT ---
Wrong setting of CYGNUM_HAL_CORTEXM_PRIORITY_MAX was causing interrupt to
happen..

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.