Weird problems with SPI on PIC24H

[cbarberis]

I seem to have some very weird issues, besides the fact that I spent almost one day trying to debug new firmware with what appears to be a faulty ICD-U64 (would not read any of the program variable values, everything read as zero) Once I replaced the debugger and went to the ICD3 I am now seeing some normality and I can read program variables. In any case that is not why I'm here asking for help. I am working with a PIC24HJ256GP206 which I have used many times before with the CCS PCD compiler. On this project I am using the SPI2 port running on mode 0. In the past I have used the following line to set-up my hardware spi port:

[jeremiah]

What were the values of SPI2STAT and SPI2CON when you read them while trouble shooting?

[FvM]

To allow others checking the generated code, you need to tell the PCD version.

[cbarberis]

My compiler version of PCD is the latest 4.135

If I use the preprocessor spi directive (works fine)
SPI2STAT = 0xC001
SPI2CON1 = 0x0121
SPI2CON2 - 0x0000

now if I use the setup_spi2() ( MOSI goes away)
SPI2STAT = 0xC000
SPI2CON1 = 0x01BD
SPI2CON2 - 0x0000

[cbarberis]

It looks like when I use the setup_spi2() function there is a difference in the SPI2CON bits, looks like bit 7 is being set (SSEN) which activates the slave SPI select pin, this definitely should not happen!!! as it is set for master mode the other item is the SPRE bit being set to 1:1 (I don't think that matters) Now I wonder if MOSI is affected by the SSEN bit?? I don't think it should?

[FvM]

[cbarberis]

The only part of the SPI code is just the read and write functions as shown below:
void w5100_write_reg(int16 addr, unsigned int8 data);
unsigned int8 w5100_read_reg(int16 addr);


void w5100_write_reg(int16 addr, unsigned int8 data)
{
W5100_CHIPSEL;
delay_us(15);
spi_read2(W5100_WRITE_CMD);
spi_read2(addr >> 8); // Send address msb
spi_read2(addr); // Send address lsb
spi_read2(data); // Write data to W5100
delay_us(15);
W5100_CHIPNOSEL;
}


unsigned int8 w5100_read_reg(int16 addr)
{
int8 retval;

W5100_CHIPSEL;
delay_us(15);
spi_read2(W5100_READ_CMD);
spi_read2(addr >> 8); // Send address msb
spi_read2(addr); // Send address lsb
retval = spi_read2(1); // Read data from W5100
delay_us(15);
W5100_CHIPNOSEL;

return(retval); }

[RF_Developer]

[Ttelmah]

Yes, SPI_MODE_8B, is specific to several of the 24 and 33 chips. They support 16bit hardware SPI, so you have settings:

SPI_MODE_8B
SPI_MODE_16B

available to enable this.

8B is the default on all these chips, and the define codes as '0', and does nothing. It is the 16B one that actually changes anything.....


Best Wishes

[FvM]

I don't see any issues with the SPI handling of PCD V4.135.

You can correct the configuration by adding SPI_SS_DISABLED to setup_spi2().

For the SPI speed settings, you should use the respective SPI_CLK_xx configuration constants.

I don't agree with some points said in the above post, e.g. about more more flexible operation of #use spi. It does e.g. not support reconfiguration of SPI, which is essential for a number of application.

The dataseheet also clarifies that hardware spi overrides port tristate settings.

[cbarberis]

In my case both setup_spi() #use spi are selecting the hardware functions of the PIC, not software spi and that can be easily seen by looking at the contents of SPI2STAT and SPI2CON. As far as selecting a Baud rate in the case of the #use api directive is because if you don't put in a baud rate it reverts to the highest speed available which may be not a good idea to use, so what else can you put in there when they are asking for a baud rate? I usually never treat the spi bus like the asynchronous serial port.

[FvM]