4
\$\begingroup\$

I'm attempting to interface a PIC18F4520 to a 25LC640 via SPI protocol. I'm using the built in MSSP hardware of the PIC. The PIC18F4520 is the only master on the bus. I'm reading 16 bytes of data from the EEPROM 32 times per second. I've double-checked the following items:

  1. TRIS Registers for SDI, SDO, SCK, and CS
  2. Baud Rate ~ 1 Mhz
  3. SPI Mode 0,0

I've checked the signals on an oscilloscope and everything looks fine. I've tried using a BusBee to log the data coming from the EEPROM and 99% of the time it's correct. Every once in a while there are a string of requests where the MOSI (SDO) line does not seem to contain the correct EEPROM read instruction causing the data being clocked into the micro to be invalid. This happens even though I'm writing the same read instruction in the SSPBUF each time. What else can go wrong with a SPI bus?

\$\endgroup\$
  • \$\begingroup\$ Do you have an oscilloscope to view the analog signal? Even if you don't have some expensive logging digital/analog MSO to capture the packet which contained the error, a few "single sample" runs can tell you (and people trying to help) a lot. \$\endgroup\$ – Kevin Vermeer Oct 25 '10 at 20:59
  • \$\begingroup\$ I've run the scope in single sample mode, but all the samples I capture look fine. The glitch happens so infrequently and for such short duration I have not been able to capture it on the scope only on the bus analyzer that does not show the analog voltages or pulse widths. \$\endgroup\$ – mjh2007 Oct 26 '10 at 12:44
4
\$\begingroup\$

In the past I have noticed that some of the PIC datasheets do not correctly show the SPI CPOL and CPHA registers, there was some issues that when looking at the output on a scope, two of the four combinations were back to front from what was expected. So double check you are actually getting the expected waveform out of your PIC and that the waveform matches what is needed on the EEPROM.

I have also come across some A/D converters that worked intermittently when I had incorrect SPI settings on a HC12, drove me banana's trying to work it out, was one of my first projects as a professional engineer, eventually I worked it out. But I digress. So it is possible to get intermittent problems using SPI bus due to incorrectly set CPOL/CPHA. As it is a shift register after all, and the last bit on one character may be being read of the first of the next character. This type of problem may not be noticed straight away either.

So ensure you have the correct settings on a scope, and do not relay on just setting the registers of the PIC.

\$\endgroup\$
  • 1
    \$\begingroup\$ I'm not sure if it was the PIC18F4520 or the 25LC640 that didn't work quite right in SPI Mode 00, but they both work in Mode 11. \$\endgroup\$ – mjh2007 Oct 27 '10 at 14:24
5
\$\begingroup\$

If you have a schematic, post it, also any information regarding how your treating the signal lines. At 1Mhz transmission line effects can come into play, you mentioned you scoped the signal and everything looked fine but did you verify rise/fall times, reflections and ringing? Are your signal line terminated and impedance controlled? How long are they?

Other random things it could be:

  • bug in code, create a minimal program that does nothing but read from the EEPROM to test
  • Check for proper CS setup and hold times before transfers begin
  • are you writing to the EEPROM as well? if so are you checking the status register to ensure the write is complete before you attempt a read?
  • Are you using slew rate control in the MSSP? Either way check that your min/max rise/fall times are within the EEPROMS limits.
\$\endgroup\$
  • \$\begingroup\$ I checked the rise times and fall times they are well below the datasheet maximum of 2 us. There does not appear to be any reflections or ringing on the signal. \$\endgroup\$ – mjh2007 Oct 26 '10 at 14:26
  • \$\begingroup\$ I thought slew rate control only applied to I2C. I'm sampling the data at the middle of the output time (SMP=0). \$\endgroup\$ – mjh2007 Oct 26 '10 at 19:22
  • \$\begingroup\$ CS setup and hold times are ~ 10 us datasheet says minimum time is 500 ns. Is there an issue with having too long a CS setup or hold time? \$\endgroup\$ – mjh2007 Oct 26 '10 at 19:24
  • \$\begingroup\$ shouldn't be an issue with long times on CS. If the signal integrity is fine, i would look to a bug in the uC code, create a minimalist test case. \$\endgroup\$ – Mark Oct 27 '10 at 1:20
0
\$\begingroup\$

I've had similar intermittent bugs and found that it was a bug in the code. It wasn't to do with SPI, but every so often the chip would reset and this would cause garbage to be written to on-chip memory; make certain your code is stable. One way to do this would be on reset to have you press a button so it does not restart automatically.

\$\endgroup\$
  • \$\begingroup\$ Good thought! I have a message that I print to RS-232 when I startup. The program does not appear to be resetting. \$\endgroup\$ – mjh2007 Oct 25 '10 at 20:26
  • \$\begingroup\$ Or flash a light on power up so it is obvious to you. \$\endgroup\$ – Kortuk Oct 25 '10 at 21:46
  • \$\begingroup\$ was the watch dog timer overflowing and causing the chip to reset? \$\endgroup\$ – SimonBarker May 30 '11 at 16:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.