"Ghost" driving SDO pin in SPI mode

[mcpublic]

I am using a PIC18F2420 as an SPI master to drive a MAX532 dual 12-bit DAC. This has been working 99% of the time, but I am occasionally seeing what seems like a "ghost" driving my SDO pin in SPI mode. There is nothing else sharing this pin in software or hardware. I initialize the TRIS, and that's it.

What I am seeing on the scope is the SDO pin change state between transmitted bytes, and also sometimes even between clock pulses. The result is glitches in the analog output. What I'm trying to drive onto the SPI bus is not the same as what appears on the bus. A scope trace can be found at

http://www.4004.com/spi-ghost-scope-trace.bmp

Channel 2 is the SCK and Channel 3 is SDO. Notice how it changes before the burst of clock pulses and stays high afterwards.
The scope was triggered when the analog signal went out-of-bounds. Here is another scope trace with the SDO changing between clock pulses.

http://www.4004.com/between-ck-pulses-scope-trace.bmp

I added the 1us delays during debugging because the Silicon Errata suggested that there might be some hardware bugs in the MSSP module.

Anyone seen anything like this? This is very strange.

[Ttelmah]

You say you are setting TRIS. Are you selecting 'fast_io' mode?. If not, the compiler will still control TRIS. How are you generating the SPI data?. Is this using the chip's hardware, or one of the software implementations (as in many of the example files, or using the new ability to do this in V4)?.

Best Wishes

[mcpublic]

Thanks for the suggestion. This firmware doesn't #use fast_mode. But I wouldn't expect this to be an issue as I don't do any explicit I/O on the SDO pin. I just let the MSSP module control it.

My next experiments I'm thinking of are (a) to add a pull-down resistor to the SDO line, and (b) lift the SDO pin. The pull-down will tell me if the TRIS is being messed with, and the lifted pin will let me see if anyone else is driving the bus (it could only be the DAC input pin, but maybe there are ESD protection diodes that are doing something funky.

[mcpublic]

P.S. I am using the PIC18F2420's MSSP hardware to generate SPI signals.

[Ttelmah]

OK.
I'd suggest making a bit define of the SPI buffer empty status bit. Write the data, then wait till this goes true, _before_ doing your extra delay. I have a nasty feeling you are being hit by a MSSP hardware problem (there are a hell of a lot on some of these chips...), which the internal functions may be not helping with...

Best Wishes

[mcpublic]

That's a very good suggestion. And I agree with your diagnosis,
as I've pretty much confirmed that it is either a hardware bug
or a bug inside CCS C "PCH" SPI library (I suppose it may
have gotten fixed/worked-around after version 3.236;
I'll upgrade if it definitely did)

Here's what I did to isolate the problem:

First I used spi_read() to verify if what I was passing to
spi_write() was actually getting written onto the bus.
It wasn't.
Then I implemented "bit-banged" SPI in software.
No more glitches. And a loss of only half the SPI bandwidth.
(1.25MHz instead of 2.5MHz using SPI_CLK_DIV_16)
I never had to lift a soldering iron or cut any 30GA wire, whew!

[scorp]

I had nearly the same problem using PIC18LF4620 and PIC18LF2420. On PICLF2420 i just decided to use my software SPI functions and problem had gone. Recently, on PIC18LF4620 I decided to dig into the problem and found that hardware SPI works unpredictable if PIC has floating pins(unconnected and programmed as inputs). Reprogramming unused I/Os as output solved issue. I always used fast_io.
Can anybody prove or disprove it, please?

[Ttelmah]

Having floating input pins is 'bad practice' anyway. Will result in increased power consumption, and more risk of ESD problems. Rules generally are, that unused pins should always either be programmed as outputs, or tied to a rail with a resistor (this is 'better', than shorting directly to a rail, since it prevents damage, if you latter accidentally drive the pin, and on a couple of older CMOS families, avoids a potential 'latch up' problem).
Now, on the PIC in general, there are significant oddities with a number of pins, if they float, and the protection diodes come into play. In general, some features that are turned off, can start to actually work, if a pin goes outside the supply rails. In particular, for the SPI, I'd not be at all surprised if the slave select line, could actually deselect the input, even if disabled, if this happens...

Best Wishes