On Wed, Oct 28, 2015 at 6:06 AM, David Mandala david.mandala@linaro.org wrote:

On 10/27/15 1:25 PM, Grant Likely wrote:

...

Second posting. I've made some changes to the design. Things to note:

• VIO is selectable between 3.3V and 5V with a slider switch
• A through-hole stackable header is used
• silkscreen is cleaner

I think that covers all the outstanding comments. Attached are the schematic, design files, and a rendering.

Comments welcome. I hope to send this for a pre-production run next week.

g.

Inline image 1

Grant,

This looks very nice, so +1 from me.

Do you have a mechanical layout with measurements for each connector? If so I can get started on the Case additions for this now.

Look a the Sensors-layout.pdf file that I sent you. All of the information you need should be there.

g.

Hi David

Open the board in KiCAD, click on the component, and select the part. Open the properties and it will list the exact X,Y coordinate of the part. Then open the part and determine where the 0,0 for the part is. After that you have everything you need.

Lawrence King  lking@qti.qualcomm.com Engineer, Sr. Staff/Manager Qualcomm Canada Inc. (905)482-5403 desk (x25403) (416)627-7302 cell

-----Original Message----- From: David Mandala [mailto:david.mandala@linaro.org] Sent: Tuesday, October 27, 2015 10:57 PM To: Grant Likely grant.likely@linaro.org Cc: King, Lawrence lking@qti.qualcomm.com; mezzanine@lists.96boards.org; Gandhi, Ketal ketalg@qti.qualcomm.com; George Grey george.grey@linaro.org; Koen Kooi koen.kooi@linaro.org; 96boards-team 96boards-team@linaro.org; Mark Brown mark.brown@linaro.org Subject: Re: Sensors board Rev B - call for review (v2)

On 10/27/15 9:26 PM, Grant Likely wrote:

On Wed, Oct 28, 2015 at 6:06 AM, David Mandala david.mandala@linaro.org wrote:

...

On 10/27/15 1:25 PM, Grant Likely wrote:

...

Second posting. I've made some changes to the design. Things to note:

• VIO is selectable between 3.3V and 5V with a slider switch
• A through-hole stackable header is used
• silkscreen is cleaner

I think that covers all the outstanding comments. Attached are the schematic, design files, and a rendering.

Comments welcome. I hope to send this for a pre-production run next week.

g.

Inline image 1

Grant,

This looks very nice, so +1 from me.

Do you have a mechanical layout with measurements for each connector? If so I can get started on the Case additions for this now.

Look a the Sensors-layout.pdf file that I sent you. All of the information you need should be there.

g.

Grant,

Whoops I missed that.

That is most of what I need but P2, P3, P4, P5 are missing Y coordinates, 96B_SPI, P6, SW1 are missing x and y info.

I'm guessing that 96B_SPI GPIO2 and I2C0 are 7mm apart from the row above but it's not called out. If so that takes care of the y for them, but still need the X for 96B_SPI it's smaller then the connectors above it.

I am assuming that: A0, D7 A1, D6 A2, A6, I2C1 top D5 AT-I2C GPIO3 I2C1 bottom D4 respectively share the same Y offsets.

I am also assuming that AT-I2C, GPIO1, I2C0 and D3 y offset is 0 the front edge of the board.

Thanks,

David

-- David Mandala <david.mandala at linaro dot org> http://www.linaro.org/ Public Key id: 45B2D952 Murphy TX, 75094 +1.972.891.8436

Hi Grant,

I read your comments regarding I2C to Uchida-san and the comment on the doc https://docs.google.com/document/d/1GNoC-1C1xcejgLLvgm1JbpF7blwJigXq5XIB3Fvn...

I looked the datasheet of TXS0104 which is used for level shifting from 1.8V I2C to 5V I2C. http://www.ti.com/product/txs0104e The block diagram of TXS0104 shows that there are 10Kohm pull-up register inside, which is common value for regular pull-up register when converting from open drain TTL to data bus on CMOS IC. Also, on the datasheet, it says 2Mbps capability for open drain bus, so it should not cause any problem.

I remember even I used "10Kohm" pull up register when I was connecting 74LS TTL to 74HC series when I did not have 74 HCT series.

So TI's 10Kohm should not be problem according to the specification, but when I goodled about I2C transmission problem that data not reaching to the end of I2C bus, many people have been tweaking the pull-up register to be in between 2Kohm to 5Kohm to improve the compatibility of sending data reaching to the end of I2C bus. http://www.picfun.com/midi2c02.html (sorry it is in Japanese, but only the last sentence is important)

It looks like adding 3.3Kohm next to from B1(13) to B4(10) on TXS0104 would make the pull-up value to be 2.48Kohm, which might improve the situation.

If you have already done modification for a pre-production run next week, please ignore all of this. :)

I also welcome any idea or comments on this.^^

Or having extra space for adding any value on the line of B1 to B4 and able trying different value from 2.2Kowm to 4.7Kohm for the person who has an oscilloscope before finalizing the value for the real production might good. ^^

Akira

On 10/28/2015 03:19 PM, Grant Likely wrote:

On Wed, Oct 28, 2015 at 11:56 AM, David Mandala david.mandala@linaro.org wrote:

...

On 10/27/15 9:26 PM, Grant Likely wrote:

...

On Wed, Oct 28, 2015 at 6:06 AM, David Mandala david.mandala@linaro.org wrote:

...

On 10/27/15 1:25 PM, Grant Likely wrote:

...

Second posting. I've made some changes to the design. Things to note:

• VIO is selectable between 3.3V and 5V with a slider switch
• A through-hole stackable header is used
• silkscreen is cleaner

I think that covers all the outstanding comments. Attached are the schematic, design files, and a rendering.

Comments welcome. I hope to send this for a pre-production run next week.

g.

Inline image 1

Grant,

This looks very nice, so +1 from me.

Do you have a mechanical layout with measurements for each connector? If so I can get started on the Case additions for this now.

Look a the Sensors-layout.pdf file that I sent you. All of the information you need should be there.

g.

Grant,

Whoops I missed that.

That is most of what I need but P2, P3, P4, P5 are missing Y coordinates, 96B_SPI, P6, SW1 are missing x and y info.

Try the attached file.

...

I'm guessing that 96B_SPI GPIO2 and I2C0 are 7mm apart from the row above but it's not called out. If so that takes care of the y for them, but still

Correct

...

need the X for 96B_SPI it's smaller then the connectors above it.

Done

...

I am assuming that: A0, D7 A1, D6 A2, A6, I2C1 top D5 AT-I2C GPIO3 I2C1 bottom D4 respectively share the same Y offsets.

Yes

...

I am also assuming that AT-I2C, GPIO1, I2C0 and D3 y offset is 0 the front edge of the board.

Nominally, yes. No guarantees though.

g.

On Fri, Oct 30, 2015 at 12:12 PM, Akira Tsukamoto akira.tsukamoto@linaro.org wrote:

Hi Grant,

I saw the rev B (2) and it already has 2.2Kohm pull-up register on i2c. Please ignore my previous email.^^

I had other two reports from my friends who tried to use SPI.

(*)Seems to have signal lost or reflection with impedance mismatching The SPI bus between HiKey and the SPI device through LS connector never successfully able to talk each other, unless adding 75ohm register serial to the SDI. If the value of register is over or under magnitude like 470ohm did not help. Also tried push-pull/open-drain or adding pull-up register did not help. So suggested to have space to put Oohm dummy register on the line of SPI and I2C, and make it able to tweak the value on the boards.

After doing a bunch of testing here at home, I've got 22ohm resistors in series on the i2c, but I didn't add them to the SPI lines. The SPI lines are driven through a push-pull driver, will it still be necessary to have in-line resistors for SPI?

On i2c I'm having more problems with the i2c device not pulling the data line low enough, and increasing the strength of the pullups makes things worse. The pads for extra pullups aren't there right now. I don't know if I'd be able to add them back, there isn't much room.

I suppose I could add them to the backside. It wouldn't be very good for manufacturing, but it would leave the option if need be.

The board has already been sent to manufacturing. We're getting 10 built first for testing, followed by an additional 490. There is an opportunity to change the board layout if we run into problems with the first 10. I can add additional pads at that time.

(*)The 5V rail. The 3.3V rail is clean since it is created by LDO from 5V on the board but 5V rail has only 0.1uF by-pass capacitors on the board. The 5V rail is from 96boards through LS connector. The 5V rail is made on both HiKey and DragonBoard by buck switching converter and has switching noise. My friend suggested me that pull-up registers connected to 5V will injects noise to the SPI and I2C. So suggesting adding two 10uF capacitors on 5V rail.

There is very little room on the board, but I've managed to add 10uF on the VIO line before it goes to any of the devices. That is already in the design as sent to Seeed.

The board layout looks pretty crowded and I do not know it has enough space on the board for the above comments.....

Akira

On 10/28/2015 09:30 PM, Akira Tsukamoto wrote:

...

Hi Grant,

I read your comments regarding I2C to Uchida-san and the comment on the doc

https://docs.google.com/document/d/1GNoC-1C1xcejgLLvgm1JbpF7blwJigXq5XIB3Fvn...

I looked the datasheet of TXS0104 which is used for level shifting from 1.8V I2C to 5V I2C. http://www.ti.com/product/txs0104e The block diagram of TXS0104 shows that there are 10Kohm pull-up register inside, which is common value for regular pull-up register when converting from open drain TTL to data bus on CMOS IC. Also, on the datasheet, it says 2Mbps capability for open drain bus, so it should not cause any problem.

I remember even I used "10Kohm" pull up register when I was connecting 74LS TTL to 74HC series when I did not have 74 HCT series.

So TI's 10Kohm should not be problem according to the specification, but when I goodled about I2C transmission problem that data not reaching to the end of I2C bus, many people have been tweaking the pull-up register to be in between 2Kohm to 5Kohm to improve the compatibility of sending data reaching to the end of I2C bus. http://www.picfun.com/midi2c02.html (sorry it is in Japanese, but only the last sentence is important)

It looks like adding 3.3Kohm next to from B1(13) to B4(10) on TXS0104 would make the pull-up value to be 2.48Kohm, which might improve the situation.

If you have already done modification for a pre-production run next week, please ignore all of this. :)

I also welcome any idea or comments on this.^^

Or having extra space for adding any value on the line of B1 to B4 and able trying different value from 2.2Kowm to 4.7Kohm for the person who has an oscilloscope before finalizing the value for the real production might good. ^^

Akira

On 10/28/2015 03:19 PM, Grant Likely wrote:

...

On Wed, Oct 28, 2015 at 11:56 AM, David Mandala david.mandala@linaro.org wrote:

...

On 10/27/15 9:26 PM, Grant Likely wrote:

...

On Wed, Oct 28, 2015 at 6:06 AM, David Mandala david.mandala@linaro.org wrote:

...

On 10/27/15 1:25 PM, Grant Likely wrote: > > > > Second posting. I've made some changes to the design. Things to note: > - VIO is selectable between 3.3V and 5V with a slider switch > - A through-hole stackable header is used > - silkscreen is cleaner > > I think that covers all the outstanding comments. Attached are the > schematic, design files, and a rendering. > > Comments welcome. I hope to send this for a pre-production run next > week. > > g. > > Inline image 1

Grant,

This looks very nice, so +1 from me.

Do you have a mechanical layout with measurements for each connector? If so I can get started on the Case additions for this now.

Look a the Sensors-layout.pdf file that I sent you. All of the information you need should be there.

g.

Grant,

Whoops I missed that.

That is most of what I need but P2, P3, P4, P5 are missing Y coordinates, 96B_SPI, P6, SW1 are missing x and y info.

Try the attached file.

...

I'm guessing that 96B_SPI GPIO2 and I2C0 are 7mm apart from the row above but it's not called out. If so that takes care of the y for them, but still

Correct

...

need the X for 96B_SPI it's smaller then the connectors above it.

Done

...

I am assuming that: A0, D7 A1, D6 A2, A6, I2C1 top D5 AT-I2C GPIO3 I2C1 bottom D4 respectively share the same Y offsets.

Yes

...

I am also assuming that AT-I2C, GPIO1, I2C0 and D3 y offset is 0 the front edge of the board.

Nominally, yes. No guarantees though.

g.

Hi Grant

22 Ohms series resistor is fine. When you have something actually connected to the port then it may be necessary to change the resistance (although 22 is usually close enough). The 22 can stay as a place holder, and only those customers needing to fine-tune the signals can change to something different.

I believe that the GPIO drive strength can be modified (and if I am not mistaken it is currently set to 2mA). Please change the drive strength up to 16mA, this should make the low levels lower. Here is a somewhat simplified diagram of the I2C circuit:

[cid:image002.png@01D11BBC.1D4D6CB0]

When the SOC pulls it’s output low a number of things start to happen.

1) The SOC is sinking current from it’s internal pull-up resistor (R1)

2) The SOC is sinking current from the level shifter internal pull-up (R2)

3) As the levels drop to about 1V at the left side of the level shifter the pass transistor starts to turn on.

4) As the pass transistor turns on the voltage at the right side of the level shifter also starts to drop and current flows through the pass transistor towards the SOC.

5) As the levels on the right side of the level shifter get even lower, the SOC is sinking current from R3, R4, and R5 (all in parallel).

6) The SOC hits it’s current limit (2mA) and refuses to drive the output voltage lower. There is a small voltage drop across the pass transistor in the level shifter but for this simplified computation we can ignore it. Assuming we are using TXS0108E level shifter, approximate values for the resistors are: R1=40k (assuming you haven’t turned it off) R2=R3=40k Ohms (actually it starts out as 10kOhms and only after you get below 0.8V does it change to 40kOhms so the calculations below are optimistic) R4 = 5k Ohms (I am not sure what value you selected for your board) R5 = 2.2k Ohms (depends on what Seed Studio module you have connected, they seen to vary between 2.2k and 10k for the modules I have looked at).

Assuming that the SOC output were able to drive to 0.4V (a nice valid low level, the total current from the 1.8V (Left) side of the level shifters (1.8-0.4=1.4V) would be: IL = 1.4/R1 + 1.4/R2 = 1.4/40,000 + 1.4/40,000 = 70uA (micro Amps, OK so far)

And on the right side (3.3-0.4=2.9V) (things get worse if you are running a 5.0V device). IR= 2.9/R3 +2.9/R4 +2.9/R5 = 72uA + 508uA + 1.32mA = 1.97mA

Total current IL + IR = 2.04mA or just above the limit of the SOC. Hence my recommendation to turn the drive strength of the SOC to max (16mA). This should really help your low levels.

One other thing I noticed with the TXS0108E, if you get too much capacitance load on the output (example a Seeed Studio hub and 3 devices, all connected by 6 inch Seeed cables) the output will burst into oscillation at ~35MHz. you can’t see this with a voltmeter, but everything stops working.

Lawrence King lking@qti.qualcomm.commailto:lking@qti.qualcomm.com Engineer, Sr. Staff/Manager Qualcomm Canada Inc. (905)482-5403 desk (x25403) (416)627-7302 cell

From: Mark Brown [mailto:mark.brown@linaro.org] Sent: Tuesday, November 10, 2015 9:34 AM To: Grant Likely grant.likely@linaro.org Cc: Akira Tsukamoto akira.tsukamoto@linaro.org; David Mandala david.mandala@linaro.org; King, Lawrence lking@qti.qualcomm.com; mezzanine@lists.96boards.org; Gandhi, Ketal ketalg@qti.qualcomm.com; George Grey george.grey@linaro.org; Koen Kooi koen.kooi@linaro.org; 96boards-team 96boards-team@linaro.org Subject: Re: Sensors board Rev B - call for review (v2)

On 10 November 2015 at 14:31, Grant Likely <grant.likely@linaro.orgmailto:grant.likely@linaro.org> wrote:

After doing a bunch of testing here at home, I've got 22ohm resistors in series on the i2c, but I didn't add them to the SPI lines. The SPI lines are driven through a push-pull driver, will it still be necessary to have in-line resistors for SPI?

Not an EE but the SPI designs I've seen with long traces have had them due to reflections.

Hi Srini:

The I2C bus specification has no concept of “Drive Strength”, it just assumes that the open collector can sink at least 4mA at 0.4V. Our ASICs certainly do have a concept of drive strength. All GPIOs have programmable drive strength of 2-16mA (see LM80-P0436-7 Rev B page 23). I2C “open collector” is ‘simulated’ by the QUP by either driving the GPIO pin low (normal GPIO drive) or setting the GPIO to input mode and letting the signal float to wherever it wants to (pull-up). The drive strength is programmed in the register TLMM_GPIO_CFGn (see LM80-P0436-13 Rev B “Hardware Register Description” Table 2-1 page 3013), the GPIO has no idea that the QUP behind it is simulating open collector. The GPIO has no special mode for open collector. In this specific case you want to change GPIO6 and GPIO7 (the I2C bus). I have the source code for a much older build of Linux on my computer, so I looked in ./410c/kernel/arch/arm64/boot/dts/qcom/msm8916.dtsi and I found this:

i2c4_default: i2c4_default { pinmux { function = "blsp_i2c4"; pins = "gpio14", "gpio15"; }; pinconf { pins = "gpio14", "gpio15"; drive-strength = <2>; bias-disable = <0>; }; };

Of course this is the wrong I2C for what we are doing (my build is old and we didn’t have I2C turned on at that time), but you can clearly see the Drive Strength setting. Please change it to “16”.

Lawrence King lking@qti.qualcomm.commailto:lking@qti.qualcomm.com Engineer, Sr. Staff/Manager Qualcomm Canada Inc. (905)482-5403 desk (x25403) (416)627-7302 cell

From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Grant Likely Sent: Wednesday, November 11, 2015 11:20 AM To: King, Lawrence lking@qti.qualcomm.com Cc: Mark Brown mark.brown@linaro.org; Akira Tsukamoto akira.tsukamoto@linaro.org; David Mandala david.mandala@linaro.org; mezzanine@lists.96boards.org; Gandhi, Ketal ketalg@qti.qualcomm.com; George Grey george.grey@linaro.org; Koen Kooi koen.kooi@linaro.org; 96boards-team 96boards-team@linaro.org; Srinivas Kandagatla srinivas.kandagatla@linaro.org Subject: Re: Sensors board Rev B - call for review (v2)

On Tue, Nov 10, 2015 at 6:58 PM, King, Lawrence <lking@qti.qualcomm.commailto:lking@qti.qualcomm.com> wrote: Hi Grant

22 Ohms series resistor is fine. When you have something actually connected to the port then it may be necessary to change the resistance (although 22 is usually close enough). The 22 can stay as a place holder, and only those customers needing to fine-tune the signals can change to something different.

I believe that the GPIO drive strength can be modified (and if I am not mistaken it is currently set to 2mA). Please change the drive strength up to 16mA, this should make the low levels lower. Here is a somewhat simplified diagram of the I2C circuit:

​ ​[cc'ing Sri ​ni​ , he may be able to help me here]​

​Do you know how to ​get Linux to change the drive strength on those pins? I assume it is a change to the DT, but I don't know the bindings used for the qualcomm pin controller. ​

[cid:image001.png@01D11C84.41DB7FE0]

When the SOC pulls it’s output low a number of things start to happen.

1) The SOC is sinking current from it’s internal pull-up resistor (R1)

2) The SOC is sinking current from the level shifter internal pull-up (R2)

3) As the levels drop to about 1V at the left side of the level shifter the pass transistor starts to turn on.

4) As the pass transistor turns on the voltage at the right side of the level shifter also starts to drop and current flows through the pass transistor towards the SOC.

5) As the levels on the right side of the level shifter get even lower, the SOC is sinking current from R3, R4, and R5 (all in parallel).

6) The SOC hits it’s current limit (2mA) and refuses to drive the output voltage lower. There is a small voltage drop across the pass transistor in the level shifter but for this simplified computation we can ignore it. Assuming we are using TXS0108E level shifter, approximate values for the resistors are: R1=40k (assuming you haven’t turned it off) R2=R3=40k Ohms (actually it starts out as 10kOhms and only after you get below 0.8V does it change to 40kOhms so the calculations below are optimistic) R4 = 5k Ohms (I am not sure what value you selected for your board)

​There is no R4 at the moment. The current board relies on the internal 10k. If any additional pull-up is added then the Grove RGB LCD isn't able to drive the data line low enough to register at the baseboard. ​

R5 = 2.2k Ohms (depends on what Seed Studio module you have connected, they seen to vary between 2.2k and 10k for the modules I have looked at).

Assuming that the SOC output were able to drive to 0.4V (a nice valid low level, the total current from the 1.8V (Left) side of the level shifters (1.8-0.4=1.4V) would be: IL = 1.4/R1 + 1.4/R2 = 1.4/40,000 + 1.4/40,000 = 70uA (micro Amps, OK so far)

And on the right side (3.3-0.4=2.9V) (things get worse if you are running a 5.0V device). IR= 2.9/R3 +2.9/R4 +2.9/R5 = 72uA + 508uA + 1.32mA = 1.97mA

Total current IL + IR = 2.04mA or just above the limit of the SOC. Hence my recommendation to turn the drive strength of the SOC to max (16mA). This should really help your low levels.

One other thing I noticed with the TXS0108E, if you get too much capacitance load on the output (example a Seeed Studio hub and 3 devices, all connected by 6 inch Seeed cables) the output will burst into oscillation at ~35MHz. you can’t see this with a voltmeter, but everything stops working.

​That is what I've heard from others is a limitation of this part. If I had more time I would have swapped it out for a different shifter IC, but the schedule of the hack-a-thon means I have to stick with what I've got. :-(

g.

Lawrence King lking@qti.qualcomm.commailto:lking@qti.qualcomm.com Engineer, Sr. Staff/Manager Qualcomm Canada Inc. (905)482-5403 desk (x25403) (416)627-7302 cell

From: Mark Brown [mailto:mark.brown@linaro.orgmailto:mark.brown@linaro.org] Sent: Tuesday, November 10, 2015 9:34 AM To: Grant Likely <grant.likely@linaro.orgmailto:grant.likely@linaro.org> Cc: Akira Tsukamoto <akira.tsukamoto@linaro.orgmailto:akira.tsukamoto@linaro.org>; David Mandala <david.mandala@linaro.orgmailto:david.mandala@linaro.org>; King, Lawrence <lking@qti.qualcomm.commailto:lking@qti.qualcomm.com>; mezzanine@lists.96boards.orgmailto:mezzanine@lists.96boards.org; Gandhi, Ketal <ketalg@qti.qualcomm.commailto:ketalg@qti.qualcomm.com>; George Grey <george.grey@linaro.orgmailto:george.grey@linaro.org>; Koen Kooi <koen.kooi@linaro.orgmailto:koen.kooi@linaro.org>; 96boards-team <96boards-team@linaro.orgmailto:96boards-team@linaro.org> Subject: Re: Sensors board Rev B - call for review (v2)

On 10 November 2015 at 14:31, Grant Likely <grant.likely@linaro.orgmailto:grant.likely@linaro.org> wrote:

After doing a bunch of testing here at home, I've got 22ohm resistors in series on the i2c, but I didn't add them to the SPI lines. The SPI lines are driven through a push-pull driver, will it still be necessary to have in-line resistors for SPI?

Not an EE but the SPI designs I've seen with long traces have had them due to reflections.

On Sat, Nov 14, 2015 at 12:15 PM, Srinivas Kandagatla srinivas.kandagatla@linaro.org wrote:

Hi Lawrence,

Thanks for the detailed explanation.

I have done few experiments with 16mA drive strength on Grove Gesture, Grove Digital light sensors and LCD RGB backlight. I hit 2 issues.

Issue 1: (With Digital Light sensor (0x29)) 10K on board pull up:

With the Rev A sensor board what Am seeing is a cross talk between SDA and SCL. The spikes are too high that the ACK is not detected by the master.

Attached are some waveforms to confirm this In the "Not-Detected-Cross-Talk-(0x29).BMP" waveforms we can see spikes which are at the rising edge of the clocks which is worst in the ack clk cycle.

I repeated same experiment by splitting the SCLK out of the Grove ribbon cable. "Detected-with-Split-Cable(0x29).bmp" has the captured wave form. Now the slave gets less spikes and the master can detect it.

Quick read on the internet suggested that the layout of the tracks or the ribbon cable which exceeds 10cm should be something of below order:

SDA - VDD - VSS - SCL

This arrangement would avoid cross talk between SDA and SCL. Grove connector cables are definitely in the order which are prone to cross talk. Not sure if we can fix though :-)

Are we taking care of this at layout level?

References: http://www.nxp.com/documents/user_manual/UM10204.pdf ( Section: 7.5 Wiring pattern of the bus lines)

Am not sure if Rev B is taking care of this or Is it possible to compensate such thing if external ribbon cables are in wrong order?

Issue 2: (With Gesture sensor) 2.2K on board pull up:

I cant detect this sensor, Possibly it might be a faulty one. Waveforms look normal. Will continue to debug with other devices.

Can you show a waveform of the ack cycle? I'd like to know how low the sensor is driving the data line.

g.

Hi Srinivas

We certainly can't do anything about the order of signals on the Grove cables. These were locked and in production long before we started this project. It is possible to add a ground trace between the traces on the board, but I don't think this help much. The physical design rules for the PCB won't permit placing a ground trace between tracks where the tracks must come close to each other in the vicinity of the level shifter.

The other way to reduce cross talk is to separate the traces, the usual rule of thumb is, if the separation is 3x the trace width then the cross talk will be quite low. I haven't looked at Sophie's layout but on my board the traces are 0.254mm wide, and the spacing between pins on the level shifters is 0.60mm so the track to space ratio can only be 1.3 in the vicinity of the level shifter pins. The I2C spec does point out that cross talk is really only an issue when the traces are longer than 10cm and the traces on the board are only about 3cm so I don't think the PCB layout is the major contributing factor.

The scope traces you have attached don't make sense to me. The vertical scale says that the signals are 200mV per division, and counting the number of divisions between a low and a high I see almost three divisions. This would indicate that the signal is only 600mV, which I feel is really wrong. The signal should be one of 1.8V, 3.3V or 5.0V. Possibly you are looking at a 5V signal, then the real scale is 2V per division (you need to tell the scope you are using 10x probes so that it correctly displays the volts per division). Adjusting the vertical positions of the traces so that the yellow '1' tag is exactly on the center division, and the cyan '2' tag is exactly on the first division up makes it easier to read the voltages.

I don't think the pulse in the photo (Zoom-In-CrossTalk.BMP) is cross talk, or at least it isn't cross talk on the cable. Signals move down the cable at a velocity of about one foot per nanosecond, you have approximately 1 foot of cable (6 inches to the end, and 6 inches back) so "cross talk" should only last about 1ns. The scope shows a pulse lasting almost 50ns. I think this is more likely the pulse circuit inside the level shifter firing, of course it is firing due to the original 1ns cross talk, so all we need to do is prevent the original bit of cross talk from triggering the level shifter pulse circuit. If the cross talk is on the 1.8V side of the level shifter then maybe there is something we can do in layout, but since separating the wires seems to resolve the problem, I suspect that the crosstalk is on the 5.0V side of the level shifters where we have very little control..

Can you do a few things for me so that we can debug this?: 1) take a photograph of your setup (show the board, the how the probes are connected, and the Grove cable leading to the device). The way the scope probes are connected can affect the measurements. 2) send me a link to the test program you are using to run the I2C bus. I can compile it and run it here. What Grove device are you driving so I can use the same device. 3) send me a link to the patch that enables 16mA drive current on the I2C bus. 4) take a scope trace with 2mA drive, and with 16mA drive. I want to see if we have resolved the marginal low levels. From the traces you included it is hard to be sure, but I think the low levels are much better.

I have attached a picture of how I think you should have the scope probes attached. I used a wire stripper to bare a little bit of wire in the grove cable so that I could clip the probes directly to the signal. I put a pin into the closest ground point and grounded both probes to this pin. Keep the probe wiring and ground wiring as short as possible.

Thanks.

Lawrence King  lking@qti.qualcomm.com Engineer, Sr. Staff/Manager Qualcomm Canada Inc. (905)482-5403 desk (x25403) (416)627-7302 cell

-----Original Message----- From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Grant Likely Sent: Sunday, November 15, 2015 10:42 AM To: Srinivas Kandagatla srinivas.kandagatla@linaro.org Cc: King, Lawrence lking@qti.qualcomm.com; Mark Brown mark.brown@linaro.org; Akira Tsukamoto akira.tsukamoto@linaro.org; David Mandala david.mandala@linaro.org; mezzanine@lists.96boards.org; Gandhi, Ketal ketalg@qti.qualcomm.com; George Grey george.grey@linaro.org; Koen Kooi koen.kooi@linaro.org; 96boards-team 96boards-team@linaro.org Subject: Re: Sensors board Rev B - call for review (v2)

On Sat, Nov 14, 2015 at 12:15 PM, Srinivas Kandagatla srinivas.kandagatla@linaro.org wrote:

Hi Lawrence,

Thanks for the detailed explanation.

I have done few experiments with 16mA drive strength on Grove Gesture, Grove Digital light sensors and LCD RGB backlight. I hit 2 issues.

Issue 1: (With Digital Light sensor (0x29)) 10K on board pull up:

With the Rev A sensor board what Am seeing is a cross talk between SDA and SCL. The spikes are too high that the ACK is not detected by the master.

Attached are some waveforms to confirm this In the "Not-Detected-Cross-Talk-(0x29).BMP" waveforms we can see spikes which are at the rising edge of the clocks which is worst in the ack clk cycle.

I repeated same experiment by splitting the SCLK out of the Grove ribbon cable. "Detected-with-Split-Cable(0x29).bmp" has the captured wave form. Now the slave gets less spikes and the master can detect it.

Quick read on the internet suggested that the layout of the tracks or the ribbon cable which exceeds 10cm should be something of below order:

SDA - VDD - VSS - SCL

This arrangement would avoid cross talk between SDA and SCL. Grove connector cables are definitely in the order which are prone to cross talk. Not sure if we can fix though :-)

Are we taking care of this at layout level?

References: http://www.nxp.com/documents/user_manual/UM10204.pdf ( Section: 7.5 Wiring pattern of the bus lines)

Am not sure if Rev B is taking care of this or Is it possible to compensate such thing if external ribbon cables are in wrong order?

Issue 2: (With Gesture sensor) 2.2K on board pull up:

I cant detect this sensor, Possibly it might be a faulty one. Waveforms look normal. Will continue to debug with other devices.

Can you show a waveform of the ack cycle? I'd like to know how low the sensor is driving the data line.

g.

Hi Srinivas:

Thank you for the pointers.

Your scope setup is OK for the purposes of what we are trying to do.

I am still downloading and recompiling the latest kernel, so I'll report back on more findings tomorrow.

In the meantime I used my board with 2mA drive and recorded this waveform. This is pretty much what I expected. The 'low levels are not great, but acceptable (about 0.5V), this is due to the low drive current. In the picture the SOC releases the clock line (yellow waveform) and the voltage starts to rise, pulled up by the pull-ups on the line. About 40nS later the voltage crosses the threshold in the level shifter and the level shifter actively drives the signal high for about 20ns. While the clock is rising it cross talks to the data line (green trace) and you can see the data line levels rise to almost 1V (the threshold). It is surprising that this was not enough to trigger the level shifter to drive high, but if you had any more cross talk it would drive the level shifter over the threshold and it would actively drive the signal high.

The ringing is expected with long cables, and you can see the exponential decay which confirms that this is ringing. Ringing can be reduced by impedance matching the terminations on the cable to the cable impedance, or by adding a series resistor, but these methods are not options for us so we have to live with the ringing.

Your level shifter may have slightly different threshold, or your board layout might have a little more ground bounce, but in any event you are getting enough crosstalk to trigger the level shifter one shot. 16mA drive makes the low level a little lower and you need a bigger cross talk bump to get it over the threshold, that is why it is working (more or less) at 16mA drive levels. On my board I also has 5k pull-up resistors near the Grove connector so my thresholds and termination impedances will be different from yours.

I'll explore what we can do to reduce the crosstalk once I get the kernel recompiled with 16mA drive.

Lawrence King  lking@qti.qualcomm.com Engineer, Sr. Staff/Manager Qualcomm Canada Inc. (905)482-5403 desk (x25403) (416)627-7302 cell

-----Original Message----- From: Srinivas Kandagatla [mailto:srinivas.kandagatla@linaro.org] Sent: Monday, November 16, 2015 1:51 PM To: King, Lawrence lking@qti.qualcomm.com; Grant Likely grant.likely@linaro.org Cc: Mark Brown mark.brown@linaro.org; Akira Tsukamoto akira.tsukamoto@linaro.org; David Mandala david.mandala@linaro.org; mezzanine@lists.96boards.org; Gandhi, Ketal ketalg@qti.qualcomm.com; George Grey george.grey@linaro.org; Koen Kooi koen.kooi@linaro.org; 96boards-team 96boards-team@linaro.org Subject: Re: Sensors board Rev B - call for review (v2)

Hi Lawrence,

On 16/11/15 16:48, King, Lawrence wrote:

Hi Srinivas

We certainly can't do anything about the order of signals on the Grove cables. These were locked and in production long before we started this project. It is possible to add a ground trace between the traces on the board, but I don't think this help much. The physical design rules for the PCB won't permit placing a ground trace between tracks where the tracks must come close to each other in the vicinity of the level shifter.

The other way to reduce cross talk is to separate the traces, the usual rule of thumb is, if the separation is 3x the trace width then the cross talk will be quite low. I haven't looked at Sophie's layout but on my board the traces are 0.254mm wide, and the spacing between pins on the level shifters is 0.60mm so the track to space ratio can only be 1.3 in the vicinity of the level shifter pins. The I2C spec does point out that cross talk is really only an issue when the traces are longer than 10cm and the traces on the board are only about 3cm so I don't think the PCB layout is the major contributing factor.

The scope traces you have attached don't make sense to me. The vertical scale says that the signals are 200mV per division, and counting the number of divisions between a low and a high I see almost three divisions. This would indicate that the signal is only 600mV, which I feel is really wrong. The signal should be one of 1.8V, 3.3V or 5.0V. Possibly you are looking at a 5V signal, then the real scale is 2V per division (you need to tell the scope you are using 10x probes so that it correctly displays the volts per division). Adjusting the vertical positions of the traces so that the yellow '1' tag is exactly on the center division, and the cyan '2' tag is exactly on the first division up makes it easier to read the voltages.

Yes, that's true, I fixed the factor correctly now.

I don't think the pulse in the photo (Zoom-In-CrossTalk.BMP) is cross talk, or at least it isn't cross talk on the cable. Signals move down the cable at a velocity of about one foot per nanosecond, you have approximately 1 foot of cable (6 inches to the end, and 6 inches back) so "cross talk" should only last about 1ns. The scope shows a pulse lasting almost 50ns. I think this is more likely the pulse circuit inside the level shifter firing, of course it is firing due to the original 1ns cross talk, so all we need to do is prevent the original bit of cross talk from triggering the level shifter pulse circuit. If the cross talk is on the 1.8V side of the level shifter then maybe there is something we can do in layout, but since separating the wires seems to resolve the problem, I suspect that the crosstalk is on the 5.0V side of the level shifters where we have very little control..

Can you do a few things for me so that we can debug this?:

1. take a photograph of your setup (show the board, the how the probes are connected, and the Grove cable leading to the device). The way the scope probes are connected can affect the measurements.

Attached is the photograph of the setup I use, I attached the connectors directly to the leads on the back of sensor board.

2. send me a link to the test program you are using to run the I2C bus. I can compile it and run it here. What Grove device are you driving so I can use the same device.

Its a standard "i2cdetect" program, which can be installed and run in ubuntu as below:

~# sudo apt-get install i2c-tools ~# i2cdetect -r 0 0x29 0x29

and I use "Digital light sensor" http://www.seeedstudio.com/wiki/Grove_-_Digital_Light_Sensor which has an i2c address of 0x29.

3. send me a link to the patch that enables 16mA drive current on the I2C bus.

Attached patch "0001-arm64-dts-set-the-default-i2c-pin-drive-strength-to-.patch" changes the drive strength to 16mA on default i2c pins.

4. take a scope trace with 2mA drive, and with 16mA drive. I want to see if we have resolved the marginal low levels. From the traces you included it is hard to be sure, but I think the low levels are much better.

For some reason with 2mA both SCL and SDA stay high after start condition, am not sure if this because of very drive strength requirement on the SOC side. I have attached the waveforms for your reference.

with 16mA drive strength I have attached both full waveform and a cross-talk pulse zoom-in.

Thanks, srini

I have attached a picture of how I think you should have the scope probes attached. I used a wire stripper to bare a little bit of wire in the grove cable so that I could clip the probes directly to the signal. I put a pin into the closest ground point and grounded both probes to this pin. Keep the probe wiring and ground wiring as short as possible.

Thanks.

Lawrence King lking@qti.qualcomm.com Engineer, Sr. Staff/Manager Qualcomm Canada Inc. (905)482-5403 desk (x25403) (416)627-7302 cell

-----Original Message----- From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Grant Likely Sent: Sunday, November 15, 2015 10:42 AM To: Srinivas Kandagatla srinivas.kandagatla@linaro.org Cc: King, Lawrence lking@qti.qualcomm.com; Mark Brown mark.brown@linaro.org; Akira Tsukamoto akira.tsukamoto@linaro.org; David Mandala david.mandala@linaro.org; mezzanine@lists.96boards.org; Gandhi, Ketal ketalg@qti.qualcomm.com; George Grey george.grey@linaro.org; Koen Kooi koen.kooi@linaro.org; 96boards-team 96boards-team@linaro.org Subject: Re: Sensors board Rev B - call for review (v2)

On Sat, Nov 14, 2015 at 12:15 PM, Srinivas Kandagatla srinivas.kandagatla@linaro.org wrote:

...

Hi Lawrence,

Thanks for the detailed explanation.

I have done few experiments with 16mA drive strength on Grove Gesture, Grove Digital light sensors and LCD RGB backlight. I hit 2 issues.

Issue 1: (With Digital Light sensor (0x29)) 10K on board pull up:

With the Rev A sensor board what Am seeing is a cross talk between SDA and SCL. The spikes are too high that the ACK is not detected by the master.

Attached are some waveforms to confirm this In the "Not-Detected-Cross-Talk-(0x29).BMP" waveforms we can see spikes which are at the rising edge of the clocks which is worst in the ack clk cycle.

I repeated same experiment by splitting the SCLK out of the Grove ribbon cable. "Detected-with-Split-Cable(0x29).bmp" has the captured wave form. Now the slave gets less spikes and the master can detect it.

Quick read on the internet suggested that the layout of the tracks or the ribbon cable which exceeds 10cm should be something of below order:

SDA - VDD - VSS - SCL

This arrangement would avoid cross talk between SDA and SCL. Grove connector cables are definitely in the order which are prone to cross talk. Not sure if we can fix though :-)

Are we taking care of this at layout level?

References: http://www.nxp.com/documents/user_manual/UM10204.pdf ( Section: 7.5 Wiring pattern of the bus lines)

Am not sure if Rev B is taking care of this or Is it possible to compensate such thing if external ribbon cables are in wrong order?

Issue 2: (With Gesture sensor) 2.2K on board pull up:

I cant detect this sensor, Possibly it might be a faulty one. Waveforms look normal. Will continue to debug with other devices.

Can you show a waveform of the ack cycle? I'd like to know how low the sensor is driving the data line.

g.