CPM command processing
Till Straumann
strauman at slac.stanford.edu
Sun Jan 13 22:25:16 UTC 2008
My usual 2-cents:
Busy-waiting with interrupts disabled is evil.
Such a loop *must* IMHO implement a timeout
so that the worst-case impact on latency other
tasks have to suffer from is guaranteed.
-- Till
Leon Pollak wrote:
> Hello, all.
>
> Both files
> ..lib/libcpu/powerpc/mpc8260/cp.c
> ..lib/libcpu/powerpc/mpc860/cp.c
> contain the same code:
>
> void m8xx_cp_execute_cmd( uint32_t command )
> {
> uint16_t lvl;
>
> rtems_interrupt_disable(lvl);
> while (m8260.cpcr & M8260_CR_FLG) {
> continue;
> }
>
> m8260.cpcr = command | M8260_CR_FLG;
> rtems_interrupt_enable (lvl);
> }
>
> The problem with this code is (based on my experience with both CPU's) that it
> does not check the result of a command execution. Although Motorola's
> specification states that CPM should finish the command processing in about
> 20 cycles, my 13 years experience shows that there are cases when the command
> is not executed and the flag bit remains "1".
>
> Therefore, I swap the operators in my code:
>
> m8260.cpcr = command | M8260_CR_FLG;
>
> while (m8260.cpcr & M8260_CR_FLG) {
> continue;
> }
>
> and cause system reset if it remains "1" for too long.
>
> I have no explanation to this, because after reset the system returns to the
> same exactly sequence and now it passes. We have such problem once on each
> 20-25 units based on MPC8260, but I remember this to occur on MPC860 units
> too.
>
> Hope this will be useful...
>
More information about the users
mailing list