I am using embOS v3.82o on the PIC18F46K22 processor, my compiler is C18 version 3.38. I have been
troubleshooting a memory corruption issue that I think is being caused by the
embOS assembler part. In the RTOS.asm file, OS_StartASM routine, the following
assembly code is present:
MOVFF POSTINC0, FSR1L
MOVFF POSTINC0, FSR1H
This restores the 16-bit stack pointer (FSR1), changing it
from pointing to the system stack area, back to the task stack area. Unfortunately,
a high priority interrupt can interrupt this code – the assembler part enables
interrupt shortly before these lines. If the high priority interrupt occurs in
between the two instructions listed above (a rare yet possible event), the high
priority ISR will begin executing with the FSR1 register containing the high
byte from one stack pointer and the low byte from another stack pointer. This
means that FSR1 will have an invalid value. The first thing that the
high-priority interrupt does is start pushing registers on to the stack (pointed
to by FSR1)! This means that if the high priority interrupt occurs at exactly
this instant a memory corruption will occur - basically a ‘random’ location in
RAM will get overwritten. I can consistently catch this situation with my
hardware debugger. I see the two stack pointers, and see that FSR1 contains the
high byte from one and the low byte from the other, and the mixed FSR1 value is
dereferenced with several write operations.
Have you seen this before? It seems that the non-atomic
modification of FSR1 should not be done with interrupts enabled - do you agree?
Can you confirm that this is a problem – or is my understanding incorrect in
some way?
troubleshooting a memory corruption issue that I think is being caused by the
embOS assembler part. In the RTOS.asm file, OS_StartASM routine, the following
assembly code is present:
MOVFF POSTINC0, FSR1L
MOVFF POSTINC0, FSR1H
This restores the 16-bit stack pointer (FSR1), changing it
from pointing to the system stack area, back to the task stack area. Unfortunately,
a high priority interrupt can interrupt this code – the assembler part enables
interrupt shortly before these lines. If the high priority interrupt occurs in
between the two instructions listed above (a rare yet possible event), the high
priority ISR will begin executing with the FSR1 register containing the high
byte from one stack pointer and the low byte from another stack pointer. This
means that FSR1 will have an invalid value. The first thing that the
high-priority interrupt does is start pushing registers on to the stack (pointed
to by FSR1)! This means that if the high priority interrupt occurs at exactly
this instant a memory corruption will occur - basically a ‘random’ location in
RAM will get overwritten. I can consistently catch this situation with my
hardware debugger. I see the two stack pointers, and see that FSR1 contains the
high byte from one and the low byte from the other, and the mixed FSR1 value is
dereferenced with several write operations.
Have you seen this before? It seems that the non-atomic
modification of FSR1 should not be done with interrupts enabled - do you agree?
Can you confirm that this is a problem – or is my understanding incorrect in
some way?