[Home]

Summary:DAHLIN-00112: [patch] SPI clock timing to SI3210/15 is not as per datasheet
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2009-06-03 04:39:27Date Closed:2009-09-15 15:52:24
Priority:MinorRegression?No
Status:Closed/CompleteComponents:wctdm
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) wctdm_spi_clocking.diff2.txt
Description:Referring to Silicon Labs Si3215 datasheet "Figure 7, SPI Timing Diagram", and capturing SCS, SLCK, SDO, and SDI on a scope revealed some discrepencies between data sheet and code.

The is true also of Zaptel Code.

The areas of concern are:
 1. Idle state of clock is shown in data sheet as logic 1, Both the write_8bits and read_8bits have code to SCLK to 1 before CS goes low.
read_8bits has code to set SCLK to logic 0 after CS has gone high.

 2. In read_8bits the reading of SD0 should happen after rising edge of clock.
Currently it's read immediatley after SCLK is driven low.

If the SCLK idle state of 0 was for safety reasons, what about SDO, it can be either 0 or 1. I don't think this was the reason.

Would these fix the code in wctdm_voicedaa_check_hook
/* Try to track issues that plague slot one FXO's */


****** ADDITIONAL INFORMATION ******

Concern 1:

Removing the setting of SCLK to logic 0 at the end of read_8bits, leaves SCLK at logic 1.
Which inturn allows us to remove the initial setting of SCLK to 1, at the beginning of both read_8bits and write_8bits.

Concern 2:
Gives SDO an additional ~600nS for data to settle before it's read.


Comments:By: Alec Davis (alecdavis) 2009-06-03 05:00:10

Tested with 2 versions of S100M FXS module, one with Si3210 and other with Si3215.
By: Alec Davis (alecdavis) 2009-06-03 06:44:28

please remove wctdm_spi_clocking.diff.txt

uploaded wctdm_spi_clocking.diff2.txt
includes ASCII art to attempt to illustrate SPI timing waveforms.
By: Shaun Ruffell (sruffell) 2009-06-03 10:29:48

I haven't looked at the data sheet, but at first glance it looks to be correct.  After the 2.2.0 final is released, I'll see about checking this out.
By: Alec Davis (alecdavis) 2009-06-03 14:21:24

In next day or so I'll be testing FXO to see if I can make the claim of 'found slot 1 FXO bug'

I need to know, the connection details for the modules, are the clock and data in parallel, or does it use the daisy chain pass through method.

As SDI-SDO passthrough has a propagation delay, which may be relevant here, which adds up as you go through each module.
By: Alec Davis (alecdavis) 2009-06-03 14:22:54

sruffell: Are zaptel branches still being maintained?
By: Shaun Ruffell (sruffell) 2009-06-03 14:51:40

alecdavis:  Short answer, no the Zaptel branches aren't being maintained.
By: Alec Davis (alecdavis) 2009-06-03 15:56:59

From what I can tell, this issue was introduced after the introduction of the single port FXS card, and any code that was based off that.

The original release of wcfxs.c 0.1.4 that I can find seems correct, with respect to reading and writing to the SPI.

http://svn.digium.com/svn/zaptel/tags/0.1.4/wcfxs.c first appeared and seems correct.
http://svn.digium.com/svn/zaptel/tags/0.2.0/wcfxs.c with read timing error.
http://svn.digium.com/svn/zaptel/branches/1.0/wcfxs.c with read timing error and attempt to fix with SCLK set at beginning of read and write routines.

Ok. I know obsolete and not maintained, but the issues this addresses have been around for a long time.

I feel this problem, should make it into DAHDI 2.2.0, it's not a feature, it's a major timing fix, and a fix for nearly every branch released.

edit: I see it's in the Roadmap for DAHDI 2.2.0, does this mean it's holding up release of DAHDI 2.2.0?


By: Shaun Ruffell (sruffell) 2009-06-04 10:19:50

alecdavis:  Hmmm..I made a mistake to flag it for 2.2.0.  But my strong preference is to let 2.2.0 go out without this change, since I haven't seen any reports of problems this causes and it's been in the code for so long.  Then it can go in early into trunk after 2.2.0 is released to let early adopters hammer on it until it's time for the next release.
By: Alec Davis (alecdavis) 2009-06-04 15:09:31

I first heard about the FXO slot 1 problem while on Asterisk BootCamp 18 months ago, and to avoid Slot 1 with an FXO.

But what are symptoms and the exact senario, is it documented anywhere?
By: Shaun Ruffell (sruffell) 2009-06-04 16:01:15

I haven't seen any documentation for it...just the comment in the code like you.
By: Alec Davis (alecdavis) 2009-06-23 18:33:24

DAHDI 2.2.0's out :)
Time for testing.


By: Alec Davis (alecdavis) 2009-07-13 19:39:08

Any chance of moving this forward?
By: Alec Davis (alecdavis) 2009-07-27 15:55:39

This has now been in a production box for nearly 2 months.

Hasn't missed beat.

<b>Ready for Testing</b>


By: Alec Davis (alecdavis) 2009-09-09 05:04:14

Sean:
Let's get this in testing before the hardware becomes obsolete :(
By: Shaun Ruffell (sruffell) 2009-09-09 10:04:11

alecdavis:  Sorry....yes....this week.
By: Alec Davis (alecdavis) 2009-09-14 15:08:42

sean: This week...

To every commiter:
How about a 'low priority' day and close some of the many low risk low priority bugs.
By: Shaun Ruffell (sruffell) 2009-09-14 15:45:25

yes...and I mentioned this issue this morning to dbailey.
By: Digium Subversion (svnbot) 2009-09-15 15:52:23

Repository: dahdi
Revision: 7140

U   linux/trunk/drivers/dahdi/wctdm.c

------------------------------------------------------------------------
r7140 | dbailey | 2009-09-15 15:52:23 -0500 (Tue, 15 Sep 2009) | 12 lines

Change WCTDM SPI clock off state polarity and read timing

Change the off state of the SPI clock to high and provide more time for data to
settle out on SPI reads.

(closes issue DAHLIN-112)
Reported by: alecdavis
Patches:
     wctdm_spi_clocking.diff2.txt uploaded by alecdavis (license 585)
Tested by: alecdavis, dbailey


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

http://svn.digium.com/view/dahdi?view=rev&revision=7140