PIC18F46K22 & DS3234/SPI woes

[thefloyd]

OK folks, I've got a good one (I'm good and stumped!).

Setup:
PIC18F46K22 with an SPI EEPROM, SPI RTC (DS3234), SPI ethernet (Wiz820io). 16mhz external crystal with 4xPLL (64mhz system clock).

In SPI mode 0 I can speak to the EEPROM and Wiz820io as expected. I can set registers on the wiznet module and read them back. I can read things from my EEPROM. So I know SPI works..

The RTC doesn't speak mode 0, only 1 or 3. So when I'm getting ready to drive the RTC's SS line low, I switch to SPI mode 1 (or 3 - doesn't matter) and delay for some time (currently 50ms, but have used more/less with no difference). I've made all sorts of attempts at getting reliable communication working but to no avail.

Out comes the old logic analyzer - and this is where it gets fun.

Following the datasheet, I write 0x80 to the DS3234, followed by seconds, minutes, hours. For testing, I used values 2, 5, 3. I can see these go to the RTC just fine.

I then read back the values - write 0x00, then 3 spi_read(0) calls. I see my test values on my logic analyzer (2, 5, 3) on the MISO line - which is connected DIRECTLY to the pins on my PIC. But reading back and printing my values gives me 3, 4, 3. Wait, what?!

What could I be missing here? I'm literally snooping the hardware right at the PIC pins and see the values just fine. My SPI setup works just fine with other peripherals. This seems to rule hardware out. The code is as simple as can be, see below..

[Ttelmah]

Try disabling the SPI, then changing mode.
I think you will find some options can't be switched, while the peripheral is enabled. Hence you end up sampling on the wrong edge.
So:

[thefloyd]

[Ttelmah]

Rats.
It was the only 'obvious' idea I had!....

I'd suggest taking a 'step back'.
First just setup the SPI to talk to the DS3254. Prove that this works without the other SPI settings, It could be that there is something simply wrong with the mode being used. It looks like the PIC is reading the data on the wrong clock edge.

Then, once this is working, use something like MPLAB SIM, and put a breakpoint at the place the first DS3254 transaction occurs. Note down all the SPI config register settings at this point.
Now add the other SPI setup, and repeat the test.
Are the register settings the same?.
If not, then the problem becomes working out how to get them the same.

Best Wishes

[thefloyd]

Good idea. This is a new piece of hardware and I've been testing each piece bit by bit (first the eeprom, then the wiz820io, finally the RTC). What I didn't do was disable each piece (the first two worked so well, so I didn't need to!) when moving on to the next.

I'll create a fresh project and target only the RTC and then go from there if it works.. Thanks for the advice!

[thefloyd]

OK, so stripped down to just RTC access I'm still seeing the same thing:

sample main function:

[thefloyd]

.. and as quickly as that I'm on to something..

Change SPI MODE to 3 and it looks like it may be working.. I'll keep quiet for now ;)

[thefloyd]

So, after taking a couple of days off and fiddling around (rebuilt a whole new circuit on a breadboard) I've finally gotten somewhere (and I found out my hardware isn't faulty .

First - it seems 4mhz is too fast to talk to the DS3234. Other peripherals on my SPI bus work at 4mhz but the DS3234, even when re-done on a breadboard with just the PIC and RTC is unreliable. The datasheet lists 4mhz as the max, but since I don't NEED 4mhz for my RTC and my communications seem reliable at 1mhz I'm not inclined to pursue this too much further.

NOW here is where the fun begins. Both my prototype PCB as well as my breadboard setup are PIC18F46K22, PDIP 40 pin, 16mhz external crystal. A working setup is:

#use delay(clock=16MHz,crystal=16MHz)
setup_spi(SPI_MASTER | SPI_MODE_3 | SPI_CLK_DIV_16);

However, no matter WHAT I do, this does not work:

#use delay(clock=64MHz,crystal=16MHz)
setup_spi(SPI_MASTER | SPI_MODE_3 | SPI_CLK_DIV_64);

What happens? Well, on the latter setup my code freezes at my calls to spi_write/spi_read. If I change the second setup to SPI_CLK_DIV_16 all of my SPI peripherals work and I just read wrong data from the RTC (both on the isolated breadboard setup as well as my prototype pcb).

So what gives? Why does a 1mhz SPI clock derived from a 16mhz system clock and SPI_CLK_DIV_16 work, whereas a 1mhz SPI clock derived from a 64mhz system clock and SPI_CLK_DIV_64 freezes?

[Ttelmah]

If you are not using T2, try setting the SSP to clock from this, and programming that for 1MHz.
I'd traditionally suspect an erratum at this point, but none listed on this chip about this.
The symptom suggests it is not actually clocking.
What compiler version are you on?. The current releases seem to set the right values into the SSP registers, but it might be that yours puts a corrupted number into these.

Best Wishes

[thefloyd]

Can't get T2 to clock slow enough.. the slowest is T2_DIV_BY_16 which, at 64mhz, is no different than SPI_CLK_DIV_16.

I've tried compiler version 5.011 and 4.141.

Same thing both times. My program freezes at spi_write() calls.

[thefloyd]

An interesting tidbit - I seem to hang when I call spi_write(0) or spi_write(0x00).

I recompiled and ran under the debugger. I can get as far as spi_write(0x8E) and the next spi_write(0x00) I never return from.

[Ttelmah]

It's the output of T2 used.
It is fed with Fosc/4, so you can do /4, /16, then maximum of /256 to give a maximum possible division of 16384.....

To give 500KHz, you'd want:
setup_timer_2(T2_DIV_BY_1,31,1);

1MHz
setup_timer_2(T2_DIV_BY_1,15,1);

Clock/4, over the second number+1.

4KHz
setup_timer_2(T2_DIV_BY_16,255,1);

Clock /4, /16, /256 = 3906Hz.

Best Wishes

[thefloyd]

Aha. Thanks! That makes more sense..

Sadly, it doesn't seem to help much. Changing my setup_timer_2 statement to EACH of the examples you gave yields the same results as I was seeing with a 4mhz clock - garbage data. Polling the RTC once a second yields several seconds with the same number followed by a 2-3 second jump (same for minutes! seconds wrap around and minutes stay the same and then jump after a 2nd or 3rd cycle!).

I've found a few things that get reliable communication:

- changing the system voltage to 5V (from 3.3v), this yields stable communication with the RTC all the way up to 4mhz (DS3234 datasheet says 4mhz should be fine > 2.7v, so something isn't working here..)
- disabling the 4xPLL and using the system at 16mhz, with SPI_CLK_DIV_16 yielding a 1mhz SPI clock

What should work - 64mhz system clock with SPI_CLK_DIV_64. It doesn't. I'm dumbfounded.

[thefloyd]

Out came the logic analyzer again and double checked everything.

The RTC is definitely returning the expected/proper data. The different SPI clock frequencies are definitely working.

I think at this point I can narrow this down to the 18F46K22 operating at 64mhz and 3.3v. Raising the system voltage works. Lowering the clock speed works. What I don't understand is WHY this isn't working and why it's only affecting the PIC's ability to get data from the DS3234 RTC. My PCB prototype has an SPI eeprom and a wiz820io ethernet module and they all work just fine.

[Ttelmah]

I'm having a 'niggling' little memory....

What you are describing, is exactly what happens on some of the faster chips that have an erratum regarding loading the buffer immediately after the flag says the last transfer has completed.

A typical example is:
<http://ww1.microchip.com/downloads/en/DeviceDoc/80387a.pdf>
Basically on these, where you have: