PIC18F8722 SPI

[bela]

Hi.

I'm currently trying to impliment a CS5525 ADC with an 8722 pic over spi.

The problem is, I don't quite understand how to generate a clock for 24 bits of data.

Basically, I should be able to send an 0x94 to read the cfg regs and that will return 24bits.

If I do this:

spi_write(0x94); // read the config register (24 bits)
data1=spi_read(); //read hi byte
data2=spi_read(); // read mid byte
data3=spi_read(); //read low byte

The first byte is usually "something" where as the second / third are 00s or FFs.

If I do this:

spi_write(0x94); // read the config register (24 bits)
data1=spi_read(); // the clock for this byte was generated by spi_write
// according to the help file
data2=spi_read(0);
data3=spi_read(0);

It freezes up, assuming that it's waiting for data on data2?

I've also tried this:

spi_write(0x94);
data1=spi_read();
spi_write(0x00);
data2=spi_read();
spi_write(0x00);
data3=spi_read();

and it still freezes on data2.


Can anyone help wth this. It seems a difficult chip to use!


Also, the whole spi comms (with this chip) only seems to work if I use SPI_L_TO_H. I understand that passing a zero to spi_read will mean that it will generate a clock but send no data. Does this Zero change based on SPI_X_TO_X? For example, does the zero then need to be FF?

If I use SPI_H_TO_L, the spi_write()s freeze the program.

Thanks for any help; it's very much appreciated.

Darren.

[FvM]

There are different questiions raised with your posting.

1. Correct syntax for the SPI built-in functions. Clearly either a spi_write() or a spi_read() with data argument is necessary to generate a read clock.

2. Selecting the appropriate SPI mode. This is basically independant of the other points and must be done according to periperal requirements.

3. Freezing the chip with SPI communication should never happen! You may have managed to create the issue in other parts of your code, e. g. by defining unhandled interrupts, inappropriate watchdog settings or similar. Basically, the SPI driver in master mode doesn't wait for anything, it sends the output clock and reads SDI.

[ckielstra]

How are you setting up the SPI hardware in the PIC? Are you using the setup_spi() function or the new '#use SPI' directive? I prefer to use setup_spi() as this is tested functionality.
Note that you can't mix the new and old SPI methods.

From the CS5525 data sheet, figure 6:
- Clock level in inactive state is low.
- Data is clocked in at the positive clock edge.
Then read the SPI specifications at: http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
From this you can conclude the required SPI mode = 0 (CPOL=0 / CPHA=0)

I always have troubles understanding the non-standard CCS terminology for setting up SPI, so I created the defines below:

[bela]

Hello, here is my code. Sorry, it's more than 20 line but I believe that I need all of this in this order to correctly operate the cs5525 chip. Thanks for your help.

I have added comments so you can see what I'm trying to do.

[FvM]

The code can't work, cause no clock is send out with spi_read(). Use spi_read(0) instead.

[bela]

Hello. Thanks for you reply.

I should have made it clearer:

It's the spi_read(0)s that make the program halt, exactly at the spi_read(0), I've tested it by doing printfs between each line to see where it gets. This is why I changed the spi_read(0)s to spi_read()s. Now, the program doesn't halt but the second and third bytes are invalid.

I take it that because of the quote about spi_write(data) followed by spi_read(), the first byte will have a clock but the second and third byte will not? So, if it was to work, the code I should have is:

[Ttelmah]

First thing, the code as shown, will return the byte returned by the chip, _when you wrote to the config register_, in the first read. This is almost certainly not what you want. The 'problem' with SPI, is that it transfers data in both directions _at once_. This is good in terms of performance, but does make working out what you receive quite complex. I'd expect that in fact you need to generate 32 clocks, _not_ 24. The chip can't know what it is to send 'back', till it has received the first byte. So the sequence has to be:

Clock one control byte.
Throw away the return.

Repeat three times:
Clock one byte
Store the return

If you check the data sheet, you will see that this is what they show.

Now, SPI, for the master, _cannot_ stop on a SPI_READ(0)!... This command tells your hardware to generate the clock, and as soon as this is done, reads the byte. It only waits for the hardware to say that the data has been clocked. It doesn't wait for anything at all from the other end.

Before looking further at this, I have to query your oscillator selection.
You have 'HS' oscillator selection, and 32Mhz as the frequency. The _maximum_ supported frequency for the HS oscillator, is _25Mhz_. Parameter 1, Table 28-6. The chip is happy to _run_ at 32Mhz, but this requires that you either use an external oscillator (EC mode), or a crystal at 8MHz, and enable the PLL (HSPLL). This may be what is causing the problem. The SPI hardware, may be the first part 'complaining' about this section being incorrectly driven. You need to correct this.

Next comment, is 'what compiler version'. If the hardware is working correctly, the only way that the SPI_READ(0) can hang, is if something is incorrectly configured. If you are using an early 4.0xx compiler, then I'm afraid this may be causing the problem by not setting up the SPI correctly. Be 'dubious' of anything below perhaps 4.03x.

So, correct your clock, and check your compiler version, updating if it is an early V4 version, then see what happens.

Best Wishes

[bela]

Hello.

Thank you for your reply. I will look into the clock speed problem and try again.

The compiler version is 4.066.

Daz.

[bela]

Hello,

I have added all the things that were advised here. It no longer freezes, this fix was selecting the correct clock fuse.

I still get 00 when I try to read things. Can anyone help?

To prove a point, I followed part and then ALL of AN88 from Crystal/Cirrus Logic. I wrote a value to the gain register and then read it back and 3 bytes were 00s. What a suprise.

[PCM programmer]

You did not follow AN88 on the Cirrus website.
http://www.cirrus.com/en/pubs/appNote/an88.pdf
AN88 uses routines. You are using inline code. Using routines (functions)
is much better, because allows your program to be organized.

First, AN88 calls the 'initialize' routine. The 'initialize' routine does this:

1. It delays for 661 ms.
2. Then it sets \CS low.
3. It sends the value of 0xFF to the CS5525 chip, 15 times.
4. Then it sends one byte with a value of 0xFE.
5. Then it sets \CS high.

Your code does not do this.


My suggestion is, convert the AN88 code to CCS. Use routines, the
same as AN88 does. Then assuming that your hardware connections
to the CS5525 are correct, you will have a good chance to get the chip
working.

[bela]

Hello

Below is the code I have written to attempt to copy the AN88 demo code to the best of my ability (I don't know assembler that well.)

It didn't work.

This version gets stuck in the "poll the done flag" section because the data is 00s. As expected.

I already know about what I could improve on in this code but I am not concerned with that now. It should work but doesn't. Can anyone offer their kind help?

[PCM programmer]

I just glanced at your code and I see a problem. You have specified
"fast i/o" mode for all ports, but you have only set the TRIS for port C.
That means other all other pins will be left in the power-on state, which
is as "all inputs". This means, for example, that your Chip Select
signal will not work.

I suggest that you delete all the "fast io" statements and also delete
the set_tris_c() statement. Let the compiler handle setting the TRIS.
It will do it automatically. It's much easier to program the PIC when
you let the compiler handle the TRIS.

[bela]

Hello. Thanks for pointing that out.

I could see the chip select toggle on a scope at the correct times but made no difference when I removed the #use fast io and set_tris_c.

Is there anything else apparent?

Thanks.

[PCM programmer]

In two places in your program, you have this test:

[bela]

Hello PCM programmer,

Thanks for looking at this for me. The schematic for the micro page is here:

http://www.dazsworld.com/Tl10MicroPage.pdf

There's one other place the the SPI is connected to which is a wireless tansceiver. This device is curently not fitted.

EDIT One other thing: I am aware of the AIN+ and AIN- Double diode problem. The BAV199 is not fitted. Also, The Port Label +5V REF is actually +2.5V REF.


Thanks for your help.

Daz.