To: Anyone using the Master SPI Bus Engine
Re: Bug fix update

I wanted to inform any Master SPI Bus Engine users that a bug has been found
that prevents proper SPI reception with most PICmicros. I'm very sorry if
this has caused any inconvenience to anybody, but the good news is that the
fix has already been tested and posted. The code error was completely caused
by myself in not performing extensive testing since I developed with older
PIC16F877 PICmicros and the MSSP operation with regard to the SDI line
behaves differently with certain older devices versus newer
PIC16F877/PIC16F877A PICmicros. The new MSBE.zip file can be download from
this location (under the MSBE folder):

http://members.localnet.com/~kmmp/PIC/

(You will find the new HEX files, a new PDF documentation file, and a new
'readme.txt' file. The ActiveX DLL and other files are not affected.)

Although this bug should have been caught, there is some history behind it
that explains why the initial release worked fine for me with the PICmicros
I had at hand. Perhaps this experience will help others and prevent them
from making the same mistake I did. To be quite honest, I was very surprised
to hear of this SPI reception bug report from a user because I tested the
Master SPI Bus Engine with SPI serial EEPROMs and actually saw the correct
data being received. "How could there be a reception problem?", I thought to
myself. If interested, please read on for the details that explains how this
was possible:


BUG REPORTED BY: Andras Pilinyi on 06-10-2004
Thanks goes to Andras Pilinyi, project manager of PowerStar Kft. in Budapest
Hungary for reporting this error.

PROBLEM: SDI I/O line was configured as an output (TRISC<4> = 0). SDI output
value was initialized to a '0' (low) -- PORTC<4> = 0.
CORRECTIVE ACTION: Changed SDI pin to an input (TRISC<4> = 1).


I developed this Master SPI Bus project with some very old PIC16F877
PICmicros:

PIC16F877-ES/P
9916SBN
(ICD 2 reports: B2, B3 revision)

PIC16F877-20/P
9916B3P
(ICD 2 reports: B2, B3 revision)

I did not know at the time that these devices had MSSP-related errata that I
should have researched:

From PIC16F87X Rev. B3 Silicon Errata Sheet (DS80052B):

This errata applies to all PIC16F877-20/P production devices marked with an
assembly date code prior to 9925.

1. Module: MSSP - SPI mode
The SDI pin is controlled by the module and not by
the state of the TRIS bit. This means that the SDI
pin cannot be an output when the MSSP module is in SPI mode.

Work Around: None for current silicon revision (fixed in silicon revision
B4)

To view the behavior that Andras reported (and keeping in mind I had
configured the SDI pin as an output with a initialized low level in the
original code), I connected an LED with a 470 ohm resistor from Vdd to the
PIC's SDI pin so that I could easily see if the SDI pin was configured as an
output with a logic low level (LED lights) or an input (LED does not light).
With the older two PICs listed above, it is clearly evident that the SDI is
an output because the LED lights up briefly until the MSSP module is
enabled, at which time the SDI pin becomes an input and the LED turns off.
The bug did not exist with these older PICmicros, and SPI communication
(both transmission and reception) worked just fine.

However, if I use a PIC16F877A-I/P 04023TD (ICD 2 reports B4 revision) it is
clear the behavior is completely different. The LED stays lit even after the
MSSP module is enabled, which means that the SDI line remained an output
even after the MSSP is enabled. This is contrary to how I interpreted the
data sheet ("SDI is automatically controlled by the SPI module") but this is
the exact behavior that Andras had reported. I had wrongly assumed from the
data sheet statement that once the MSSP module was enabled, the SDI pin
would automatically be made an input, regardless of the current setting of
the SDI pin TRIS bit (TRISC<4>).

Since I had tested the Master SPI Bus Engine with SPI EEPROMs using the
older PIC16F877s, everything worked correctly, since on those older
PICmicros, the SDI pin is controlled by the MSSP module and not by the
TRISC<4> state. However, on the later PICmicros it appears that, contrary to
how I interpreted the data sheet, the SDI pin is controlled by the TRISC<4>
state, not by the MSSP module. Since I failed to research early PIC16F877
device errata documentation, there was no reason for me to think that newer
PIC16F877/PIC16F877A PICmicros would act any differently than the earlier
counterparts.

When all is said and done however, 100% of the responsibility for this bug
lies with me. I made a big mistake -- plain and simple, but thankfully the
correction is easily made and is already posted for download. Proper testing
with the newer PIC16F877A-I/P 04023TD PICmicro that I had would have easily
caught this bug. Once again, please accept my sincere apologies for any
inconvenience and frustration this may have caused others when using the
Master SPI Bus Engine.

Humble regards,

Ken Pergola

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics