[ECOS] FW: PPC MPC 850 Serial driver

["Retallack, Mark (Siemens)" <mark dot retallack at siemens dot com>]

Good morning everyone (UK time), 

I have hit a 'problem' with the MPC850 serial driver and also found a
solution, but before I mark the problem has closed, I think it would be a
good idea to post a description of the problem and solution to make sure
that I am not fooling myself and to warn others.

I have been seeing a serial driver lockup on SCC 3. After a long period of
heavy use the serial driver fails to receave any more data. TX still works
with no problems. After halting the target by using a Bdi, it was possible
to view the Receive Buffer Descriptors. All the of the RxBD's had the Empty
bit flag clear and contained valid data, but the driver was not clearing out
the data. It was possible to unlock the driver by settings the Empty bit
usign GDB.   

The problem was that our application sometimes disabled the interrupts for a
long period of time (not my fault, 20 year old code). The 850 user manual
states that the PBPTR pointer in the SCC parameter RAM is set to the BD base
when the end of the BD table is reached, so if you are at the first bd
(rxbd=base), and the cpm has receaved lots of data, filling all the BD's,
the pbptr pointer is wraped around to the first bd. 

Sorry about the pasted code, no patch today, just switched to a new computer
and everything is still in the air.

The original code was:

    while (ctl->scc_scce & QUICC_SCCE_RX) {
        // Receive interrupt
        ctl->scc_scce = QUICC_SCCE_RX;  // Reset interrupt state;
        rxlast = (struct cp_bufdesc *) ((char *)eppc_base() + pram->rbptr);
        while (rxbd != rxlast) {
            if ((rxbd->ctrl & QUICC_BD_CTL_Ready) == 0) {
		
	Etc...


In the above situation, the line: "while (rxbd != rxlast)", will always
return false because the current BD (the first one that we are processing)
will match the last BD (the one that the CPM is processing) when all BD's
are full. 

I know this is a problem with out code causing the serial devices from
running out of space so we have increase the number of BD's and size of
buffers.  


Mark Retallack
Embedded Software Engineer
Siemens Traffic Controls 
Sopers Lane, Poole, Dorset. BH17 7ER. UK.
Tel: 01202 782844
Fax: 01202 782545
www.siemenstraffic.com

Committed to quality traffic solutions and service excellence


Todays Quote:

"The open-source approach is not a magic bullet for every type of software
development project."

  -- Brian Behlendorf on OSS (Open Sources, 1999 O'Reilly and Associates)  



Siemens Traffic Controls is a division of Siemens plc. Registered No.
727817, England. 
Registered office: Siemens House, Oldbury, Bracknell, Berkshire, RG12 8FZ. 

This communication contains information which is confidential and 
may also be privileged. It is for the exclusive use of the addressee. 
If you are not the addressee please note that any distribution, 
reproduction, copying, publication or use of this communication 
or the information in it is prohibited.  If you have received this 
communication in error, please contact us immediately and also 
delete the communication from your computer. 



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss