SPI1 doesn't work in PIC18F47J13-TQFP.

[Josep Robert]

Problem Description:

I’m using PIC18F47J13-TQFP.

Working with SPI I realized the following:

Using SPI1 with default pins it doesn’t work but using SPI2 and remapping pins to match the default pins (to maintain the hardware) then it works correctly.

SPI1 code, it doesn't works:

[Ttelmah]

Not that I know of.

You should either use #use, or setup. Not both. With #use, uses spi_xfer, not spi_read/write. They are two different not compatible sets of code. Look at the manual. setup makes no reference to #use. #use only uses spi_xfer.
You shouldn't mix these two setups.
Use #use and spi_xfer. This is the more flexible set of code.
I've used both ports on the surface mount version of this chip without problems. I used #use only.

[Ttelmah]

Just went and had a look at my code.
What happens if you select a lower bit rate?.

[Josep Robert]

I've just compiled your code, adding a comma,
#USE SPI(SPI1, MODE=0, STREAM=SPI_TEST, BITS=8, BAUD=400000)
and the problem is the same I posted, look at the oscilloscope:
https://imgur.com/a/CzMk4

---------------------------------------------------------------------------------

Same problem with the following code using SPI2:

[PCM programmer]

One problem is that you are not doing things in the correct order.
The compiler has to know what pins to use before it sees the
#use spi() statement.

If you do it the way you posted it, the compiler uses SPI1:

[Josep Robert]

Summary

PIC18F47J13 SPI1
setup_spi (SPI_MASTER | SPI_L_TO_H | SPI_XMIT_L_TO_H);
spi_write(0x55);
It doesn't work!

PIC18F47J13 SPI1
#USE SPI(SPI1, MODE=0, STREAM=STREAM_SPI, BITS=8)
spi_xfer(STREAM_SPI, 0x55);
It doesn't work!

PIC18F47J13 SPI2
#pin_select SDI2 = PIN_C4 // SPI2 Data Input Pin 42
#pin_select SDO2 = PIN_C5 // SPI2 Data Output Pin 43
#pin_select SCK2OUT = PIN_C3 // SPIC2 Clock Output Pin 37

setup_spi2 (SPI_MASTER | SPI_L_TO_H | SPI_XMIT_L_TO_H);
spi_write2(0x55);
It works!

PIC18F47J13 SPI2
#pin_select SDI2 = PIN_C4 // SPI2 Data Input Pin 42
#pin_select SDO2 = PIN_C5 // SPI2 Data Output Pin 43
#pin_select SCK2OUT = PIN_C3 // SPIC2 Clock Output Pin 37

#USE SPI(SPI2, MODE=0, STREAM=SPI_TEST, BITS=8)
spi_xfer(SPI_TEST,0x55);
It works!


Finally we decided to change the problematic PIC18F47J13 with the better in all aspects PIC18F47K40.

Thanks for your patience with my first post in this forum. I've learnt a lot from you.

Josep Robert

[Ttelmah]

It should have worked for SPI1 with the comma added. I cut out the stream name I was using, and typed in a new one, and managed to omit the comma, but that is working 'as is' except for this on my board. As I said though the key difference is I'm selecting a lower baud rate, and it was this I wanted you to test. I have a nasty suspicion that this chip is showing the same fault that a couple of others in the near family show, and won't work with a /1 division on SPI1. You added the comma, but also then had it selecting the maximum baud rate, which omitted what I wanted you to test... :(
Going to a better chip is definitely a good idea.

[Josep Robert]

With your original code:

[Ttelmah]

It is very strange.

Looking at the listing generated, it is writing 0x55 to the correct register, so ought to be working. The clock is being generated, so it is seeing a write as happening, but the data is not being output. I'ts more like it is clocking back out the 'old' contents of the buffer register clocked 'in' on the last transaction.
Now there is an issue with this chip, when operating in I2C mode, that it can't accept a write to the register for a few cycles after the flag sets to say that it can be written. I'm getting suspicious that the same issue is present in SPI mode. Now I'd have never noted it, since my code is doing a lot of other stuff between loading the buffer, so there is significant delay.
So something like:

[Josep Robert]

With the modifications still doesn’t work.

MPLAB X IDE v4.15
PCH Compiler CCS v5.076

Target device PIC18F47J13 found.
Device ID Revision = 0x1

[Ttelmah]

Start by talking to CCS. The basic example, and see what they say.
It may come down to needing to talk to MicroChip if there is a hardware problem with the chip, but CCS should be the first port of call here.

[RF_Developer]

Hmm, if I'm reading them right, all the 'scope readings show Voh of no more than 2.5V, which would barely be satisfactory at 3.3V Vcc, and totally unacceptable at 5V. If they are a indication of the true voltages, it would not surprise me at all that it didn't work or was "flakey", and works sometimes and not others for no obvious reason.

What is your circuit? What is your hardware set up? Where are these voltages measured?

[Josep Robert]

I've repeated the measurements with VDD=3.3V

https://imgur.com/a/tpuB6

Seems same result.

Thank you very much.

Best Regards,
Josep Robert

[Ttelmah]

Does your Vcap/Vddcore capacitor meet the ESR requirements?. This needs to be a low ESR type (not a general electrolytic) and mounted close to the chip.

[Ttelmah]

I would add the following change to the code: