CPM command processing

Till Straumann strauman at slac.stanford.edu
Sun Jan 13 16:25:16 CST 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 rtems-users mailing list