Suggest MUX like 74HC4052 for 3.3V I2C bus

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a board that has an onboard I2C bus (or two internal buses actually), and one of the buses is now also required to access slave devices external to the board.

Because the external slaves are hot-pluggable, I don't want badly behaving slaves to jam the internal bus.

So has anyone succesfully used a 74HC4052 to mux a 3.3V I2C bus? I need up to 400kHz clock for internal buses, but have to limit to only 100kHz for the external ones. I can run the 4052 from a 5V supply if it makes things better.

Or would some other mux component be more suitable? I do want a cheap and readily available solution..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A 74HC4052 will do fine IMO, but put some transzorbs and series resistors on the "way out"

Nard

A GIF is worth a thousend words   She is called Rosa, lives at Mint17.3 https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ESD protection is already there, no series resistors on the external connector though.

Actually, the mux would not be directly connected to outside world.

Previously, there was an ASIC that had a built-in I2C master to access outside world through it. Now the replacement ASIC has only I2C pass-through to outside world, therefore the mux. Neither should require series resistors as per the manufacturer. I just want to use the mux as a precaution and make sure that if the external bus gets jammed, I can just reset the ASIC so that the rest of the system is unaffected.

In fact it needs some consideration if the ASIC pass-through feature also adds some series resistance like the mux would.

0R resistors would not hurt though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Either way, when you hot plug the device in, there will be the potential for erratic bus behavior for a millisecond or two as the part powers up.

Also, is everything on the bus running on 3.3v?

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ASIC is commanded to join the external bus to internal when connection is detected and things let to stabilise for a while. But yes, there will always be a chance of contact bounce or whatever even after that.

Everything connected to the mux would use 3V3 bus. ASIC would level translate to 5V external bus. The 4052 mux would just benefit from 5V supply.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since the ASIC is doing level translation and sensing a device being attached, why do you need the 4052 exactly? I read the OP and while the external bus runs slower, doesn't the firmware know when to slow down the data when it is to be sent to the external bus? My only guess is to isolate the two busses so the 4052's common is attached to the ASIC's TWI and a select pin from the ASIC tells the mux what TWI buss to attach to? Then firmware changes speed based on selection.
Correct?

EDIT: If the above is true, then why not put the mux inside the ASIC in firmware? Cuts component costs.

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not my ASIC so that's why :)

Well it seems that the ASIC is more than just a simple pass gate or mux. It seems to understand about the I2C protocol enough to switch data buffering direction between int->ext and ext->int when needed, and most likely clock is always buffered into int->ext direction, so clock stretching is not possible.

When shorting the external SDA, SCL or both to GND, I cannot see any problems whatsoever on the internal bus, of course the data read from external bus is not valid, but I can still control the ASIC through I2C to disconnect external I2C bus from internal.

Problem solved, no mux needed, no ASIC resetting needed because external bus does not jam internal bus.

To be honest, a mux would have solved a lot of I2C address problems, as there are a lot of components here, and without very careful design, the I2C component addresses would overlap.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It sounds like the ASIC is doing a lt more than originally thought. Looks like buffering is it's primary purpose.

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
It sounds like the ASIC is doing a lt more than originally thought. Looks like buffering is it's primary purpose.

Yes well, I was a bit hasty.

It is not the first time that a datasheet says the chip does something, but does not really mention how how it really does it.