CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
SPI mode sometimes fails on power up

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Eugeneo



Joined: 30 Aug 2005
Posts: 155
Location: Calgary, AB

View user's profile Send private message

SPI mode sometimes fails on power up
PostPosted: Sun Feb 26, 2006 4:59 am     Reply with quote
I had a pic talking to a pic via spi mode. When the system is running, the master talks to the slave flawlessly. But sometimes on power-up the spi interrupt doesn't work at all.

When this condition occurs, i;ve checked the following:

1 I've checked the master and it is sending the correct data.
2 When this happens the slave still allows all other chip functions except the spi.
3 This is what my setup_ looks like

Code:

setup_spi(SPI_SLAVE | SPI_H_TO_L | SPI_CLK_DIV_16 | SPI_SS_DISABLED);
enable_interrupts(INT_SSP);


I've ensured that if the data gets corrupted, it will still recover and communicate.

Any suggestions would be helpful

Thanks
Ttelmah
Guest
PostPosted: Sun Feb 26, 2006 5:31 am     Reply with quote
Usually the problem is sequencing. Assume that when you switch the master to SPI mode, the lines were intially floating. The clock line may or may not have been at the 'active' level. Then when you switch to SPI, mode, the hardware takes over, and a spurious clock signal may be seen on the bus. Assuming the slave was already in receive mode, it is now 'out of sync' with the master...
On my own SPI systems, talking between PICs like this, I add a large resistor (100K), to the clock line, ensuring that it is biased to the SPI inactive state, when the pins are programmed as inputs (the default on power up). I have similar resistors on the two data lines. In the slave, I pull the DOUT pin down, and then wait to see the DIN pin drop. When I see this, I program the slave to SPI slave mode. In the master, I wait till I see it's DIN pin drop (implying the slave has started), then pull the DOUT pin down, wait a few moments, then program SPI master mode. I then wait a moment longer, and start the initialisation transmissions.
I also have watchdog timeouts in the master 'wait, and it has the ability to reset the slave. If the slave does not signal itself as active, in a reasonable time, I trigger a restart of the master code, and a slave reset.
With the resistors, and signalling, the latter basically does not happen.
This has been 100% reliable, over several hundred systems for the last couple of years.

Best Wishes
Eugeneo



Joined: 30 Aug 2005
Posts: 155
Location: Calgary, AB

View user's profile Send private message

PostPosted: Sun Feb 26, 2006 11:48 am     Reply with quote
Ttelmah wrote:
Usually the problem is sequencing. Assume that when you switch the master to SPI mode, the lines were intially floating. The clock line may or may not have been at the 'active' level. Then when you switch to SPI, mode, the hardware takes over, and a spurious clock signal may be seen on the bus. Assuming the slave was already in receive mode, it is now 'out of sync' with the master...
Best Wishes


I was looking over and over on my inter-character out of sync problems. I completely forgot about inter-byte out of sync... Thnaks for that.


Ttelmah wrote:

On my own SPI systems, talking between PICs like this, I add a large resistor (100K), to the clock line, ensuring that it is biased to the SPI inactive state, when the pins are programmed as inputs (the default on power up). I have similar resistors on the two data lines. In the slave, I pull the DOUT pin down, and then wait to see the DIN pin drop. When I see this, I program the slave to SPI slave mode. In the master, I wait till I see it's DIN pin drop (implying the slave has started), then pull the DOUT pin down, wait a few moments, then program SPI master mode. I then wait a moment longer, and start the initialisation transmissions.
I also have watchdog timeouts in the master 'wait, and it has the ability to reset the slave. If the slave does not signal itself as active, in a reasonable time, I trigger a restart of the master code, and a slave reset.
With the resistors, and signalling, the latter basically does not happen.
This has been 100% reliable, over several hundred systems for the last couple of years.



What do you think of this. Since I can not add a hardware auto slave reset as you mentioned, I have a pre-determined inter character and package(8 characters) time. Do you think setting up a reset based on two things would work.

1 The SPI buffer initiatied.
2 The time has exceeded the inter-character delay.

One more quick quesiton. How do I check if the spi buffer is partially filled at the end of the timer? How do I reset the spi hardware.


Thanks for the help.
Ttelmah
Guest
PostPosted: Sun Feb 26, 2006 3:31 pm     Reply with quote
That is where the hardware reset line comes in. :-)
You should find though that if you can bias the clock line, the problem will disappear. You can clear the SPI, by clearing, and then resetting the SSPEN bit. remember also, that if you get noise on the clock line during wakeup, SSPOV, may be set.

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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