v01d opened a new issue #3423:
URL: https://github.com/apache/incubator-nuttx/issues/3423


   ```
     Description: There is bit bit logic in up_fullcontextrestore() that 
executes on
                  return from interrupts (and other context switches) that 
looks like:
   
                    ldr r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value 
*/
                    msr cpsr, r1 /* Set the CPSR */
   
                    /* Now recover r0 and r1 */
   
                    ldr r0, [sp]
                    ldr r1, [sp, #4]
                    add sp, sp, #(2*4)
   
                    /* Then return to the address at the stop of the stack,
                     * destroying the stack frame
                     */
   
                    ldr pc, [sp], #4
   
                  Under conditions of excessively high interrupt conditions, 
many
                  nested interrupts can occur just after the 'msr cpsr' 
instruction.
                  At that time, there are 4 bytes on the stack and, with each
                  interrupt, the stack pointer may increment and possibly 
overflow.
   
                  This can happen only under conditions of continuous 
interrupts.
                  One suggested change is:
   
                    ldr  r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value 
*/
                    msr spsr_cxsf, r1 /* Set the CPSR */
                    ldmia     r0, {r0-r15}
   
                  But this has not been proven to be a solution.
   
                  UPDATE:  Other ARM architectures have a similar issue.
   
     Status:      Open
     Priority:    Low.  The conditions of continuous interrupts is really the 
problem.
                  If your design needs continuous interrupts like this, please 
try
                  the above change and, please, submit a patch with the working 
fix.
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to