 |
 |
| View previous topic :: View next topic |
| Author |
Message |
thefloyd
Joined: 02 Sep 2009
Posts: 46
|
|
 Posted: Thu Aug 15, 2013 7:26 pm |
 |
|
Well, you were right on the money there.
Judicious use of delay_cycles(16) does indeed have the code running at SPI_CLK_DIV_64..
The bad news? The problem that existed @4mhz SPI exists at 1mhz SPI. The reads are still flaky, and I'm getting strange data back still. My output from a 1hz poll of the RTC looks like this:
7:27:33
7:27:34
7:27:34
7:27:37
7:27:37
7:27:38
7:27:38
7:27:40
7:27:40
7:27:43
7:27:43
7:27:44
Now - I can SEE the correct values on the wire when I connect my logic analyzer at the PIC pins. So .. wt%!!
I'm nearing the end of my rope on this one.. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19831
|
|
| Posted: Fri Aug 16, 2013 12:37 am |
|
|
Have you tried switching to SPI_MODE_3?.
The unit supports both, and it'll affect fractionally the timing of the read, relative to the clock edges. Some people on other forums, have reported problems using the chip with mode1, and faster transfers.
At least there is some progress!....
I'd possibly suggest reporting to Microchip, the problems with /64. Several other chips have documented errata with this, and it looks as if this one may have as well.
Best Wishes |
|
|
thefloyd
Joined: 02 Sep 2009
Posts: 46
|
|
| Posted: Fri Aug 16, 2013 7:05 am |
|
|
| Sadly, there's no difference. Mode 3 versus mode 1, the results are the same.. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1916
|
|
| Posted: Fri Jan 17, 2014 9:39 am |
|
|
| Ttelmah wrote: | I'm having a 'niggling' little memory....
What you are describing, is exactly what happens on some of the faster chips that have an erratum regarding loading the buffer immediately after the flag says the last transfer has completed.
A typical example is:
<http://ww1.microchip.com/downloads/en/DeviceDoc/80387a.pdf>
Basically on these, where you have:
| Code: |
spi_write(0x80);
spi_write(bin2bcd(s));
|
You technically have to add a tiny delay, and then try writing, then test the WCOL bit, and if this is set, write again... Rather complex.
However it has in the past worked for me, by adding a slightly longer delay between writes. So something like:
| Code: |
spi_write(0x80);
delay_cycles(16);
spi_write(bin2bcd(s));
|
It only happens when you run off /64, or the T2 clock, which would agree with what you are seeing.
Try with the delay, between any adjacent pairs of transfers, and see what happens.
Best Wishes |
I owe you a beer. Happens with the 18F2480 too, even though it's not listed in that chip's errata.
I love this forum. Changed my spi setup to try to eliminate a weird field issue and "bricked" the device. Started digging, found that it hung in the spi transfers. Searched this forum for "spi SPI_CLK_DIV_64", search for all terms, and bingo - here's my answer. Saved me hours if not days. |
|
|
|
|
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
