3.3v <> 5v interfacing @ 15Mhz

Alison wrote:
> 
> Could you elaborate on this?  I can do this now but I'm not sure what goes
> where in terms of;
> R1 R2 R3 T1 T2
> 
> Roughly what values? and where do things go, BCE?
> 
> I'm fully stocked on resistors, and have quite alot of different PNPs and

If your want a working solution, use level translation IC.
They will work up to 30+MHz and easily available from
catalog suppliers like Digikey and Mouser.

 > dsPIC --------------- SD/MMC
 > CLOCK  (5v) ----> CLOCK (3.3v)
 > SPI OUT (5v) ----> DATA IN (3.3v)
 > CHIPSEL (5v) ----> CS (3.3v)

SN74LVC04A @ 3.3Vcc
Use two inverters in series as a 5V tolerant non-inverting buffer.

SN74LVC3G34 @ 3.3Vcc - three non-inverting buffer.

 > SPI IN (5v) <---- DATA OUT (3.3v)

SN74AHCT1G125 @ 5Vcc - 3.3V input levels, 5V output.

-- 
WBR, Yuriy.
"Resistance is futile"

rickman <gnuarm@gmail.com> wrote in message
news:1164503030.194876.309670@45g2000cws.googlegroups.com...
>
> The drawing from my other post did not inititially include the BCE
> markings, so I added them.  You can check the data sheet for the part
> to see where each function is on the package.  This will be very
> non-critical in terms of transistor selected or resistor value.  Just
> make sure you use an NPN or N-channel device.
>

tnx :-)

The reason why I believed that a 3.3v '1' would register as a '1' on a CMOS
dsPIC port is that there are quite a few examples on the net that say it
works...  That was my mistake, believing what I read on the Internet.

"It will work, but isn't within spec' so it's unreliable.  It's reliable at
a few Mhz at very most, when the parts are designed to go upto about 30Mhz."

"dsPIC parts CANNOT be directly interfaced to 3.3v devices!"

Alison

Yuriy K. <yktech@mail.ru> wrote in message
news:ekaq4c$9bb$1@news.netins.net...

Hi Yuriy,

..

>
> If your want a working solution, use level translation IC.
> They will work up to 30+MHz and easily available from
> catalog suppliers like Digikey and Mouser.
>
>  > dsPIC --------------- SD/MMC
>  > CLOCK  (5v) ----> CLOCK (3.3v)
>  > SPI OUT (5v) ----> DATA IN (3.3v)
>  > CHIPSEL (5v) ----> CS (3.3v)
>
> SN74LVC04A @ 3.3Vcc
> Use two inverters in series as a 5V tolerant non-inverting buffer.
>
> SN74LVC3G34 @ 3.3Vcc - three non-inverting buffer.
>
>  > SPI IN (5v) <---- DATA OUT (3.3v)
>
> SN74AHCT1G125 @ 5Vcc - 3.3V input levels, 5V output.
>
> --
> WBR, Yuriy.
> "Resistance is futile"

thanks :-)  apologies for missing you out.

All of this I'm logging.

Alison

Yuriy K. wrote:
> Alison wrote:
> >
> > Could you elaborate on this?  I can do this now but I'm not sure what goes
> > where in terms of;
> > R1 R2 R3 T1 T2
> >
> > Roughly what values? and where do things go, BCE?
> >
> > I'm fully stocked on resistors, and have quite alot of different PNPs and
>
> If your want a working solution, use level translation IC.
> They will work up to 30+MHz and easily available from
> catalog suppliers like Digikey and Mouser.
>
>  > dsPIC --------------- SD/MMC
>  > CLOCK  (5v) ----> CLOCK (3.3v)
>  > SPI OUT (5v) ----> DATA IN (3.3v)
>  > CHIPSEL (5v) ----> CS (3.3v)
>
> SN74LVC04A @ 3.3Vcc
> Use two inverters in series as a 5V tolerant non-inverting buffer.
>
> SN74LVC3G34 @ 3.3Vcc - three non-inverting buffer.
>
>  > SPI IN (5v) <---- DATA OUT (3.3v)
>
> SN74AHCT1G125 @ 5Vcc - 3.3V input levels, 5V output.

The DO to SPI IN will only work the buffer is powered from 5 volts or
the output can be pulled up to 5 volts with a resistor.  The signals in
the other direction don't need buffers at all, the resistors should
work just fine.

Alison, you have the transistors in your bin, right?  They should do
the job fine.  Go ahead and try them.  If they don't work, then
something else is wrong.

rickman <gnuarm@gmail.com> wrote in message
news:1164507843.258035.246450@n67g2000cwd.googlegroups.com...
>
> Alison, you have the transistors in your bin, right?  They should do
> the job fine.  Go ahead and try them.  If they don't work, then
> something else is wrong.
>

Hi Rickman,

Here's the outcome.  With the circuit it fails at 7.5Mhz.  If the circuit is
bypassed, it fails when switching to 15Mhz.

I've tried it with; two BC547C, two BC548, and two 2N3904.

Checking the circuit on the meter all is fine, it chucks out 5v.  It just
seems to be passing out at higher speeds when the circuit is used.

What does that tell us?  If the board fails at 15Mhz without the circuit,
and the board fails at 7.5Mhz with the circuit?

The transistors here are good for 100Mhz.  They are only 100mA though?

This R&S CP/M logic analyser with a 'storage' scope add-in board thing that
I have here, I'll try to use it tomorrow if I can figure out how to trigger
it, as I don't think I can use an external trigger which I would otherwise
set in software on another pin when switching Mhz to capture what's going
on.

Just wondering why I'm getting faster speeds without the circuit.  Oh don't
worry (I'm sure you're not) I'm not criticising at all, very grateful for
the help tbh :-)  It should be more reliable with.

Alison

Alison wrote:
> rickman <gnuarm@gmail.com> wrote in message
> news:1164507843.258035.246450@n67g2000cwd.googlegroups.com...
> >
> > Alison, you have the transistors in your bin, right?  They should do
> > the job fine.  Go ahead and try them.  If they don't work, then
> > something else is wrong.
> >
>
> Hi Rickman,
>
> Here's the outcome.  With the circuit it fails at 7.5Mhz.  If the circuit is
> bypassed, it fails when switching to 15Mhz.
>
> I've tried it with; two BC547C, two BC548, and two 2N3904.
>
> Checking the circuit on the meter all is fine, it chucks out 5v.  It just
> seems to be passing out at higher speeds when the circuit is used.
>
> What does that tell us?  If the board fails at 15Mhz without the circuit,
> and the board fails at 7.5Mhz with the circuit?
>
> The transistors here are good for 100Mhz.  They are only 100mA though?
>
> This R&S CP/M logic analyser with a 'storage' scope add-in board thing that
> I have here, I'll try to use it tomorrow if I can figure out how to trigger
> it, as I don't think I can use an external trigger which I would otherwise
> set in software on another pin when switching Mhz to capture what's going
> on.
>
> Just wondering why I'm getting faster speeds without the circuit.  Oh don't
> worry (I'm sure you're not) I'm not criticising at all, very grateful for
> the help tbh :-)  It should be more reliable with.

I am starting to think the voltage issue is a red herring.  Where did
you get your code to configure and operate the SPI port on the PIC?
The basic operation of the SPI port has four possible configurations
which differ in the polarity of the clock and the edge that is used to
clock in the data.  There actually is no spec on the SPI bus.  It was
invented by Motorola (now Freescale but that may have changed again)
when they came out with one of their many MCUs, perhaps the HC11.

If your code was from scratch, then I would suggest that you work on
making sure this is right.  If the code is from a reliable source that
has verified the correct configuration in this chip, then I still say
verify it yourself!  I'll try a couple of ascii drawings.

Sel ___|---------------------------------
Clk ______|---|___|---|___|---|___|---|__
Data __X=======X=======X=======X=======X=

Sel ___|---------------------------------
Clk __|---|___|---|___|---|___|---|___|--
Data __X=======X=======X=======X=======X=

This will look right if you view it in a fixed width font.  You may
need to copy it to a text editor and view it in a font like "Terminal"
in Notepad.  The first configuration has data changing on the falling
edge of Clk.  The second configuraton is using the rising edge of the
clock to shift the data out.  In each case, the data should be read
into the PIC on the opposite edge.  This gives you the most setup and
hold time.  If you try to sample it on the same edge that shifts out
the data, you will be reading it when it is changing.

The clock can also be inverted in polarity, but that also changes the
edge the data is shifted on so it will be the same problem.  You can
try changing the two configuration parameters in the software and see
which ones work best.  Then you should verify all this with the scope
when you get it.

So maybe you don't need the voltage buffers anyway.  But it would be a
good idea to keep them in as the voltage problem can get worse if the
temperature of the circuit gets extreme one way or the other.  Voltage
thresholds are very sensitive to temperature.

rickman wrote:

>>  > dsPIC --------------- SD/MMC
>>  > CLOCK  (5v) ----> CLOCK (3.3v)
>>  > SPI OUT (5v) ----> DATA IN (3.3v)
>>  > CHIPSEL (5v) ----> CS (3.3v)
>>
>> SN74LVC04A @ 3.3Vcc
>> Use two inverters in series as a 5V tolerant non-inverting buffer.
>>
>> SN74LVC3G34 @ 3.3Vcc - three non-inverting buffer.
>>
>>  > SPI IN (5v) <---- DATA OUT (3.3v)
>>
>> SN74AHCT1G125 @ 5Vcc - 3.3V input levels, 5V output.
> 
> The DO to SPI IN will only work the buffer is powered from 5 volts or
> the output can be pulled up to 5 volts with a resistor.  

Check datasheet for the HCT/AHCT series. Strangely enough, VinH >= 2.0V, 
VinL <= 0.8V. Just right for the 3.3V system.

> The signals in
> the other direction don't need buffers at all, the resistors should
> work just fine.

Yeah, right. Especially at 10+ MHz.

> Alison, you have the transistors in your bin, right?  They should do
> the job fine.  Go ahead and try them.  If they don't work, then
> something else is wrong.

If the goal is to solve the problem, use an appropriate components.
In this particular case use IC with voltage translation capability.

If the goal is to entertain yourself, try different combinations of 
discrete components. Some of them might even work.

Which way to choose depends on what the *real* goal is.

-- 
WBR, Yuriy.
"Resistance is futile"

rickman wrote:

> I am starting to think the voltage issue is a red herring.
 > ...
> So maybe you don't need the voltage buffers anyway.  

dsPIC I/O port VinH requirement is 0.8*Vcc.
At 5V it gives us VinH >= 4.0V.
It's a little high for 3.3V circuit, isn't it?

-- 
WBR, Yuriy.
"Resistance is futile"

Hi Alison,

> I've tried it with; two BC547C, two BC548, and two 2N3904.
>
> Checking the circuit on the meter all is fine, it chucks out 5v.  It just
> seems to be passing out at higher speeds when the circuit is used.
>
> What does that tell us?  If the board fails at 15Mhz without the circuit,
> and the board fails at 7.5Mhz with the circuit?
>
> The transistors here are good for 100Mhz.  They are only 100mA though?

While the transistors may have an ft of 100Mhz their switching response
can be quite poor. You could try one in common base mode. Emitter to DO
of the 3v3, 2k2 from base to 3v3 and the collector to DI of the PIC
with a 1K0 pullup to +5V.

<snip>

> Just wondering why I'm getting faster speeds without the circuit.  Oh don't
> worry (I'm sure you're not) I'm not criticising at all, very grateful for
> the help tbh :-)  It should be more reliable with.

While VIH is specced at  0.8 * Vsupply the parts with CMOS inputs will
generally switch at about 2.5 volts. The 0.2*VDD for VIL and 0.8*VDD
for VIH are the guaranteed levels.

Regarding your driving the 3v3 inputs from the PIC. The input
capacitance your SPI device could be 'thumb-sucked' at about 20pF. Your
1K8 and 3K3 gives a node impedance of about 1k1 which when combined
with the 20pF gives a delay of about 20nsec. The gap between clock
edges at 15Mhz is only 33nsec. Combined with logic propagation delays
this could easily cause data corruption.

A way to get around this would be to fit a cap of about 33pF across the
1K8 resistor  - the idea is the same as used on the 10megohm scope
probe inputs. The cap may have to be bigger or smaller depending on the
actual input capacitance of the device, but I would guess that the 33pF
would probably fix it.

Regards
Rocky

Yuriy K. wrote:
> rickman wrote:
>
> > I am starting to think the voltage issue is a red herring.
>  > ...
> > So maybe you don't need the voltage buffers anyway.
>
> dsPIC I/O port VinH requirement is 0.8*Vcc.
> At 5V it gives us VinH >= 4.0V.
> It's a little high for 3.3V circuit, isn't it?

Haven't you been reading the thread?  We discussed that and Alison
added transistor buffers that should have fixed the problem and instead
made it worse.  That says to me that although driving from 3.3 may not
be meeting the spec, it is working in her case and she has another
issue.