Memory Partitioning Problems

But did disabling the interrupts in PartCtrl() solve your problem?

The problem seems to be that your increment/decrement plus tests are not atomic operations. Disabling interrupts will solve this. But why can't you disable the interrupts for even a short while? This will normally ( but I am not familiar with your sustem) not result in loosing interrupts, it just delays them a little.

Not immediately, but they will be recognised as soon as the higer priority interrupt is finished or this is a very weird processor indeed.

But how fast are your interrupts coming and can you keep up?

It's been a while since I used a MC683xx type processor. IIRC they can output the current function code. So if you only need (write) access to the memory in supervisor mode, you could do the protection in hardware. You may also want to do something with the bus monitor so that you will get an exception when false accesses are attempted.

The part about bus address error exceptiions doesn't sound good. My concern here is that you may be attempting to mask a hardware problem with a software bandaid. Have you investigated the nature and cause of the errors and are you satisfied that there isn't an underlying problem that can and will bite you?

Stef schrieb:

The one which is problematic comes rather slow (30 ms) but the corresponding ISR has to catch a timer value. So if I miss one interrupt the timer value is lost. The timer value of the next interrupt is to far away from the missed one. Furthermore I am not able to reconstruct the missing timer value.

Unfortunately the function code pins are already used as chip selects.

Noway2 schrieb:

I have reinvestigated the cause of the problem and suddenly I saw the solution: I have to the the UnprotectCnt for beeing greater equal to 1:

case UNPROTECT_MEMORY: UnprotectCnt++; if (UnprotectCnt >= 1) { SetMemoryToReadAndWrite(); } break;

The reason is that increasing the UnprotectCnt and changing memory access can be interrupted it's possible for a different ISR to unprotect the memory too. If this happens with the old code the changing of memory access fails.

Thanks to all for your help!

You might have already considered and discounted this, but in situations where an interrupt has to catch a timer value, you can (usually) make it latency-independent by using a capture register - i.e. use the input transition to capture the timer value to an associated register *as well as* triggering an interrupt. So long as you service the interrupt before the counter rolls over, you're in business.

(Note: this does presuppose that you're using a timer capture pin as an interrupt, rather than a GP interrupt.)

Steve

Just to add some paranoia: make sure that the increment/decrement instructions cannot be interrupted somewhere in the middle. There may still be a minute chance of messing up the actual value of the UnprotectCnt variable and ending up with corrupt values.

Andrew