 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Bones
Joined: 11 Apr 2014
Posts: 7
|
| SPI trouble - no sck or sdo activity at all |
 Posted: Fri Apr 11, 2014 12:17 pm |
 |
|
I'm programming a PIC18F45K50 with MPLAB X v2.05 + CCS v5.024
I'm using the internal osc.
I can't get the SPI to do anything no matter what I try. I'm newish to PICs so it could be something obvious. I've used the Wizard to produce a noddy test prog, listed below.
The LED flashes at the correct rate. (I haven't bothered with chip select in this quick test as I'm just trying to see something on the SPI SCK and SDO).
I'm talking to a 12 bit DAC LIN2636.
If I set the SCK and SDO pins to GPIO I can waggle them happily.
| Code: | #include <18LF45K50.h>
#device ADC=16
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES NOFCMEN //Fail-safe clock monitor disabled
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOPBADEN //PORTB pins are configured as digital I/O on RESET
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#device ICD=TRUE
#use delay(internal=2MHz)
#define LED PIN_C7
#define DELAY 1000
#include <mainspi.h>
#USE SPI (MASTER, SPI1, BAUD=125000, MODE=0, BITS=8, STREAM=SPI_1, MSB_FIRST)
void main()
{
int8 Data = 0xA5;
spi_init(SPI_1, TRUE);
//Example blinking LED program
while(true)
{
output_low(LED);
delay_ms(DELAY);
spi_xfer(SPI_1, Data);
output_high(LED);
delay_ms(DELAY);
}
} |
Any clues guys and gals? |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Apr 11, 2014 1:19 pm |
|
|
You're sending only a short single burst of pulses once every two seconds.
How do you see them ? Are you using a logic analyzer to capture the
pulses ? With a scope you probably wouldn't see them.
Try something like this. Then you can look at the SDO line with a scope:
| Code: |
while(1)
{
spi_xfer(SPI_1, 0x55);
delay_us(100);
} |
|
|
|
Bones
Joined: 11 Apr 2014
Posts: 7
|
|
| Posted: Sat Apr 12, 2014 1:43 am |
|
|
Point taken PCM, I'll adjust the timing, but we have a nice storage oscilloscope and I can capture the GPIO waggling from the same loop. (I've just made this project for the post, I have a fuller programme running faster)
Any other tips?
Do I have to set up any other clock connections for running from internal clock? My loop timing is correct so the internal clock is running as intended - perhaps the SPI clk is not connected???
DO you have to do anything to declare the SPI pin function as you would for GPIO or is that all handled by the #USE SPI declaration? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Apr 12, 2014 4:43 pm |
|
|
Are you really using the LF chip ?
What is the Vdd voltage of the PIC ? Is it 3.3 volts ?
Did you build the PIC board yourself, or did you buy it ? If you bought
the board, post a link to the webpage for it.
What package is your PIC ? Is it DIP-40 or TQFP-44 or QFN-40 ?
On your PIC board, what PIC pins are used for ICSP ?
(This is an issue if you are using the TQFP-44 package).
I need to know all these details because I am trying to make a more
simple SPI test program for you.
If I Google this, I get only your post on CCS. What is the LIN2636 ?
Post a link to the webpage for it.
Can you disconnect the LIN2636 DAC from the PIC during
testing, to isolate the PIC's SPI pins from external circuits ? |
|
|
Bones
Joined: 11 Apr 2014
Posts: 7
|
|
| Posted: Sat Apr 12, 2014 10:49 pm |
|
|
Thanks for taking the time PCM.
I can't check details until Mon am, but from memory:
Well spotted, it's not the LF chip just F, finger trouble on selecting the drop down list for this example program. I'll change that first thing Mon, but I'm pretty sure my original program had the correct include file.
The Linear DAC is http://www.linear.com/product/LTC2636
PIC voltage is 5V.
I think the package is 40 pin QFN.
The debugger is connected through the normal RB6/7 PGC/PGD pins - will verify on Mon.
The board is our own design. It's a pretty small design so I can't disconnect the SPI pins easily, but as I say, when I assign them as GPIO I can waggle them just fine. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19346
|
|
| Posted: Mon Apr 14, 2014 3:44 am |
|
|
Try specifying the number of bits to send. So:
spi_xfer(SPI_1, Data, 8);
The 'bits' in the #use SPI, is the maximum that can be transferred, and it should default to this, if you don't specify a number of bits, but I have found it much more reliable to actually set this in each transfer.
Just worth a try.
Had a quick look at what it is doing, and initially it looks 'right', except for the baud rate selection which seems to give 31250Hz (2 for the low four bits of SSPSTAT). Changing to select 500000 bps, correctly switches to '0' here, but it seems to not want to select '1' here whatever I try....). However shouldn't stop the value being output. Question is which pin it thinks SDO is on?. Note that this is fuse selectable on this chip, with SDOC7 or SDOB3. By default it should be on B3. The compiler is correctly clearing the TRIS on B1 and B3, and SDOB3 is being selected, so the data should be there. Are you sure you are testing the right pin?.
Last edited by Ttelmah on Mon Apr 14, 2014 4:25 am; edited 1 time in total |
|
|
Bones
Joined: 11 Apr 2014
Posts: 7
|
|
| Posted: Mon Apr 14, 2014 3:46 am |
|
|
Thanks for the tip.
I think I've literally just cracked it, just in the middle of checking it all out. Will report back. |
|
|
Bones
Joined: 11 Apr 2014
Posts: 7
|
|
| Posted: Mon Apr 14, 2014 4:27 am |
|
|
OK, as usual is a mixture of dumb mistakes and oddities which spread the fog of confusion.
I think my simple example program didn't work because I accidentally selected 18LF45K50 instead of 18F45K50 (haven't had time to recheck yet). But that is now working as expected.
Back to the main program, the wizard inserted
#use FIXED_IO( B_outputs=PIN_B4 ) for one of my chip select outputs. This FIXED_IO on the B port seems to stop the SPI working. Haven't had time to look yet, but will once I have the test frame running.
One oddity, my demo example had
| Code: | | #USE SPI (MASTER, SPI1, BAUD=125000, STREAM=SPI_1, MODE=0, BITS=8, MSB_FIRST) |
using MODE=0. Great all is well. I put this in my main program, it worked a few times then it stopped compiling. Now I've had to switch to
| Code: | | #USE SPI (MASTER, SPI1, BAUD=125000, BITS=8, STREAM=SPI_1, MSB_FIRST, SAMPLE_RISE, IDLE=1) |
instead, it won't accept MODE=0 anymore!???
Thanks for the keen eyes PCM, we're under way again!
One more query. My data is 24 bits. Is it better to do 3 transfers
| Code: | spi_xfer(SPI_1, bCommand, 8);
spi_xfer(SPI_1, bDataMSB, 8);
spi_xfer(SPI_1, bDataLSB, 8);
or one?
spi_xfer(SPI_1, uData, 24); |
If 24, are the top 3 bytes of the int32 sent, or the bottom 3? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19346
|
|
| Posted: Mon Apr 14, 2014 4:29 am |
|
|
Just checked further, the compiler is correctly disabling the analog inputs on these pins, and the comparators.
It looks as if it should work. |
|
|
Bones
Joined: 11 Apr 2014
Posts: 7
|
|
| Posted: Mon Apr 14, 2014 5:09 am |
|
|
| It's not clear to me but with FIXED_IO, if its not declared as an output on that port, then it is fixed as an input. And my SPI pins are outputs on B1 and 3, and presumably being messed up by this port wide directive. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19346
|
|
| Posted: Mon Apr 14, 2014 7:02 am |
|
|
That is in the manual.
"The pins are programmed according to the information in this directive (not the operations actually performed)."
So operations like SPI, serial etc., do not control the IO. The directive does.
The compiler _only_ takes responsibility for controlling TRIS, when standard_io is used.
Nowhere in what you post do you mention fixed_io.... |
|
|
Bones
Joined: 11 Apr 2014
Posts: 7
|
|
| Posted: Mon Apr 14, 2014 8:00 am |
|
|
| Quote: | That is in the manual.
"The pins are programmed according to the information in this directive (not the operations actually performed)."
|
Yes, I read that line and it didn't make any sense. After reading more about STANDARD_IO and how it flips pin function according to the operation, I can see how they came to it.
Unfortunately the "wizard" used a port wide FIXED_IO for port B because I had one output pin on it B4, ignoring the fact that I had also selected SPI1. Not so magic.
I hadn't mentioned the code in the main prog (the FIXED_IO stuff) as my noddy example seemed to have failed too. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
