[cc'ing mezzanine mailing list. As much as possible, we should be
discussing these things in public forums]
Hi Sophie. Good work. Comments below.
On Wed, Nov 25, 2015 at 10:15 AM, Sophie Haynes
<sophie.haynes(a)linaro.org> wrote:
> Morning Grant!
>
> So, I had a bit of a nightmare with KiCad the past week (Libraries not being
> visible, PCBnew being unable to read the netlist, footprints not showing)
> but it all seems to be working now. The problems seemed to be caused by me
> stripping back an old template and hashing it to work for me (worried this
> may be an issue with people using my git project if the rename it?).
Might be. You'll need to experiment with clean installs to see if it
causes a problem
> Anyway, I've pushed the project to github
> (https://github.com/sophie-haynes/96boards-mezzanine-project-template.git).
> If you have a moment, would you be able to look over the schematic? Still
> not 100% sure if it's correct electronically?
This is good work. I've got lots of comments, but don't let that
discourage you. It's to be expected at this stage of a new project.
Comments on the project:
- The way most people will use this repository is they will go into
their KiCad templates directory ($HOME/kicad/templates) (which may
already contain templates for other projects) and do a "git clone
<url>" to get the template files. You need to make sure the project is
set up to support that. Right now I think the files are two levels too
deep. Move all files up so they are at the root of the directory and
it should work correctly. (You'll need to experiment though).
I found an example of a Raspberry Pi template that looks like a good
example to follow:
https://github.com/xesscorp/RPi_Hat_Template
- The project needs a license. Since we want anyone to use this
without restriction, I want to use BSD. Create a COPYING file at the
root of the directory tree containing the BSD 2-clause license:
http://choosealicense.com/licenses/bsd-2-clause/
- Copyright also needs to be specified. The readme file can list your
name as the author, but the copyright is held by Linaro, Inc. (Your
contract assigns all of your Linaro work to the company)
- Remove the specification pdf. Instead, put a link to the CE spec in
the README file. Including the specification messes anyone cloning the
project into their templates directory.
- Ask Shovan for a 64x64 png of the 96Boards Logo to put into the meta
directory as icon.png.
- I saw something in the KiCad manual about string replacement rules
when creating a project from a template, but I couldn't find out what
they are. It might be that there is something there that will fix your
library problems. Alternately, it might be that if you change the
libraries to something other than "mezza.*" that kicad will stop
renaming them and make everything work. Again, you'll need to
experiment.
Comments on the schematic:
- I would drop the second expansion connector footprint. Just use one
and we'll switch the design to using the through-hole stackable
connector that I'm using on the new Sensors board. That will make
things simpler.
- Add labels for every signal on the expansion connector, not just the
ones that are currently in use. It will make it convenient for anyone
starting a new project.
- If you flip the USB connector vertically then the shell pins will be
on the left and the data signals on the right. That will make the
schematic cleaner, and it is what the other mezzanine schematics look
like. That way the USB+/- and VBUS signals can go straight into U2
without looping around.
- +1V8 needs to be split into two separate power rails. +1V8 is
supplied by the expansion connector, but the USB FTDI device needs to
be powered independently. Create a +1V8F rail specifically for the
FTDI.
- Similarly, rename the +3V3 rail to +3V3F because it is specific to
the FTDI chip. That leaves the +3V3 signal available if someone wants
a 3.3V rail powered by the expansion connector. Rename +3V3_FTDI to
+3V3F also. (I'm suggesting to use F instead of _FTDI simply because
that's the terminology we've used on the Sensors schematic. It's not a
big deal, but consistency is nice)
- The regulator needs to be swapped out. The CJT1117-3.3 is a 3.3V
regulator, but you want to regulate down to 1.8V. There is a XC6206
regulator on the Sensors board schematic that you can use. If fact,
looking at the Sensors design is a good guide for what the schematic
should look like.
https://github.com/96boards/96boards-sensors
- Rename "GPIO-A" to "GPIO_A" (underscore instead of dash). Every
other signal is using the underscore as a separator.
- Drop the level shifter from the schematic for now. We'll talk about
adding it back later.
- Wire the FTDI up to UART1 instead of UART0. You don't need to
connect the RTS/CTS signals.
- Add a couple of LEDs to CBUS0 and CBUS1 for TX/RX indications
- Add a LED to each of the power rails. People like lights. :-)
- Insert 220R resistors between CBUS2/3 and PWR_BTN/RST_BTN. This
gives a bit of protection to the baseboard in the case of something
driving the line when it shouldn't.
Comments on the layout:
- Move the USB connector to the exact same position as it is on the
Sensors board.
- If you're not laying out traces to the components (except for
connectors) then delete them from the project entirely. There isn't
much value in placing them without traces.
Phew. That looks like a lot, but it is just a lot of little details.
When you're finished, we'll need a blog post to publicize the template
a bit and also document it on the 96boards website.
> Also, is there anything you need me to do in regards to the debugging of the
> grove board? I was thinking of doing a little post on our findings.
Not just yet. I've got other investigation I need to do. I'd like to
have a better resolution before doing another post, but I would like
to co-author something with you when I'm done.
g.
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.
[image: Inline image 1]
Hi all,
(This got interesting enough that I ended up also making it a blog post
here: http://www.secretlab.ca/archives/164)
I've made some progress on the i2c issues seen with the sensors board. I
hooked up a pca9306 level shifter and compared the behaviour on the sensors
board using an oscilloscope. All of this testing is done with Seeed's Grove
RGB LCD module. The LCD module is useful because it actually has 2 i2c
devices embedded in it, the LCD controller at address 0x3e, and the RGB
controller at 0x62. The two devices operate independently with different
electrical properties.
On Hikey+sensors (TXS0108) the LCD locks the bus, and RGB will work, but
only after pulling the ribbon cable apart to reduce crosstalk due to
insufficient pullups
On Hikey+pca9306 the LCD isn't detected and the RGB works correctly
(undetermined if there are crosstalk issues)
The traces below show both sides of the level shifter. Green and blue on
the top for the data line. Orange and purple on the bottom with the clock.
First, what I saw on using Hikey+pca9306+RGB:
[image: Inline image 1]
And with the LCD:
[image: Inline image 2]
In both traces you can see the start condition (data goes low while clock
is high), the 7 bits of address (7 rising clock edges), the R/W bit (1
rising clock), and then the acknowledgement bit driven by the device. If
the controller doesn't see the device drive the data line low on the 9th
clock, then it decides the device isn't there and it terminates the
transaction. It is easy to recognize the ack bit because the device has a
different drive strength and the voltage level is different.
The RGB controller is a happy little device and it jumps at the chance to
drive the data line low. It goes right down pretty close to 0V. The LCD on
the other hand is sulky and doesn't drive the line quite as low as the
controller can. About to 1V. 1V is probably recognized as a logic low on a
5V device, but with 1.8V it is not even less than half. The way the pca9306
level shifter works is there are pull-up resistors on either side of the
device that draws each side up to its respective high level. In this case,
1.8V and 5V. When either side gets driven low, the level shifter begins to
conduct and the other side also gets drawn down to the same voltage, but it
can only go as low as the voltage it is driven to. If it only gets driven
down to 1V, then it will never get low enough for a 1.8V controller to
recognize it as a low state.
It may be that with weaker pull-ups the LCD will be able to drive to a
lower voltage level. I'll need to experiment more, but in the mean time
let's move onto the Sensors board. Back to the traces:
First, here is a transaction to address 0x63 with no device present:
[image: Inline image 3]
Looks perfectly normal so far. Next, the RGB device at address 0x62:
[image: Inline image 4]
Also behaving the same way as it did with the pca9306. Finally, an LCD
transaction:
[image: Inline image 5]
Again we see the start condition, the 7 data bits and 1 r/w bit, but the
ack bit looks weird. The LCD successfully drives the data bit low enough to
be recognized, but then something weird happens. The data line stays low
and the clock stops running. I don't know actually know what is happening
here, but I've got my suspicions. The LCD is continuing to drive the data
line low, (you can tell by the slightly different voltage level) but
keeping data low should not stop the clock. I suspect the txs0108 is
getting confused and driving the clock line high. I've come across reports
from others having trouble with the txs010x series on i2c. It has
'one-shot' accelerators to reduce rise time by driving the line high.
Now I need to decide what to do next. Rev B of the design is ready, but
there is still the i2c issue that needs to be solved. I may need to put the
pca9306 parts into the design which will require some more rework before it
goes to manufacturing.
g.
