CPM command register - spurious command execution??

[ru92]

Anyone with experience with Quic - CPM command register.  We seem to be observing some strange behaviour.   We set up the MPC860T communications (SCC1,SCC2, etc) we are also using SMC2 as a UART.  Everything is fine.   The very last command to the CPCR is Init RX and TX params on SMC2.

The unit will run for days, then the SMC2 uart behaviour becomes erratic.  We have found the cause to be that during operation the Init TX and RX params command is resent to the CPM.

Our core is not resending this command (by setting the FLG bit), but the command still remains in the CPCR opcode and channel register as a leftover from the initialization at powerup.   It seems the CPM is somehow fooled into reprocessing this command.

We thought that by setting the opcode and channel to a benign operation like close Rx buffer SMC2 might resolve the problem for us, since SMC2 is a TX uart only.   We have found that sending this command repeatedly during run mode has no ill effects.  

Does anyone else have experience with leftover commands suddenly being executed by the CPM?

Are there other consequenses that we are not considering? 

Thanks

[genuap]

Check the assembly for when you write the CPCR register. Depending on the compiler it might be generating byte load/store instructions (lbz & stb). This could cause erratic operation.

Some other thoughts:
 - is internal memory space marked as cache-inhibited & guarded?
 - did you do any synchronization after writing the CPCR, either use of a sync instruction or reading the CPCR back after writing it?

 ... Paul

[ru92]

Paul, 

Thanks for your response.   I am trying to evaluate all of your suggestions.   I have looked at the Assembler and did notice something.   The C code is simply

void RiscIssueCommand( Word module, Word command)

{

    while(quicc->cpcr & CR_FLG_CP_PROCESS);

   quicc->cpcr = command | module | CR_FLG_CP_PROCESS;

}

I don't believe we are doing any synchronization, though since we are processing many commands are all except the last command synced by reading cpcr prior to issuing a "new" command.   Should we add some code to "read" the cpcr to syncrhonize at the end of this function.  Or can you point to the "synchronization" command you are referring to.   I can not find anything in documentation about synchronization.

Interestingly, this C code has been recently "optimized" with different compiler settings, we have older products that do not "seem" to exhibit this erratic behaviour.   Its assembly is thus:

lis          R5, 0xf00

//while (quicc->cpcr & CR_FLG_CP_PROCESS)

lhz        R11, 0x9c0(R5)

clrlwi     R11, R11 0x1f

cmpwi  R11, 0x0

bne       0x939b88

lis          R5, 0xf00

//quicc->cpcr = command | module |  CR_FLG_CP_PROCESS;

or           R11, R4, R3

ori          R11, R11, 0x1

sth         R11, 0x9c0(R5)

blr

The new code that has erratic behaviour (though only some units, and after many days of normal operation)

lis          R5, 0xf00

//while (quicc->cpcr & CR_FLG_CP_PROCESS)

lhz        R11, 0x9c0(R5)

rllwinm   R11, R11, 0, 31, 31

bc           4, 2, -0x000c

//quicc->cpcr = command | module |  CR_FLG_CP_PROCESS;

or           R11, R4, R3

ori          R11, R11, 0x1

sth         R11, 0x9c0(R5)

blr

Despite these differences it does not show a "byte" access as you thought might be causing a problem, so I am still at a loss to explain what we are seeing.

As for the "internal memory" being cache inhibited and guarded, I am not sure what memory you are refering to.  Are you refering to the 5K of static ram within the CPM that is dual port ram with RISC controller, the SDMA and the CPU?

My biggest concern is why does this erratic behaviour only show up after days of normal operation.  If the assembly for the CPCR was wrong I would expect units to occasionaly fail, but the problem would occur at power up ( the only time we configure the CPM).  Once the unit is running, we no longer read or write the CPCR register, yet the erratic behaviour can be reproduced by simply sending the Init Tx and Rx params to the SMC2 channel. In our case this is just sending the CPCR that we left in the register following our initialization.  Almost as if the FLAG was set on its own.  Maybe this could be explained by the synchronization or cacheing you are refering to?

On failure or SMC (uart) transmitter seems to fill its buffer descriptors and then burst transmit all the buffers, when under normal operation it sends out the buffers as they are ready for transmit.  While resending the "Init Tx and Rx" causes the same behaviour we observe on the failed units, could there be another reason?  The Init Tx and Rx will restore the parameter RAM to the values they had after the last reset of the CP.  Could something else be happening to transmit and receive parameters?  Is a cacheing error in the parameter RAM a possible cause? 

Thanks

Dan

[genuap]

Dan:

I was out of the office for a while so missed your reply. Is this still an issue, or have you gotten any further? Looks like the assembly doesn't have the byte write problem I was thinking of.

Synchronization is in the core user's manual - is this an e500 or e300 system? This is usually the sync, eieio, or isync command.  Its mentioned in this guide (which is e300 based, but reasonably applicable to e500 as well):
http://www.freescale.com/files/product/doc/MPCFPE32B.pdf

Since the PowerPC is an "out of order machine" synchronization is sometimes necessary to ensure order of reads & writes. I also have this appnote on the topic.



As for the cahche-inhibited & guarded question, I mean the entire internal memory region. Again, depends on what processor this is (and if its e300 if you have the MMU turned on), but if the MMU is on the entire internal space, including the DPR, registers and CPM registers should be marked as cache inhibited & guarded.

 ... Paul