TUSB8041-Q1: EEPROM Access

Hi Elton,

Yes, the EEPROM can be reprogrammed over USB 2.0, but it does require the EEPROM programming tool be used and the driver to be loaded on the hub.  Do you have the utility?  Accept my friend request and send me a message if you need the utility.

Regards,

JMMN

Hi JMMN,

I do have the tool, yes, but how would I use that? Is that for bench programming, so needs a person to physically be there? If so, that's not what I meant. To be clear, any scenario that involves a person being there is no use. We want the option of programming in the field. 

Thanks,

Elton

Hi JMMN, can I get answer to this please as I need to move forward and make a decision on how to program the device in the field. 

If we can't update it via USB then we'll have to use the I2C/SMBus interface, but I have questions about that as well.

Such as in the documentation it says things like "the I2C supports a single master.... connection to a dedicated I2C EEPROM...".

The word "dedicated" implies the hub can only connect to one device and that device must be an EEPROM - is this correct? 

I ask because I was toying with the idea of putting our processor into slave mode and using the hub to get updates from it. 

Would that be possible in your opinion? (For clarity reasons, can you also confirm it definitely can't be part of a Multi-Master set up?) 

So if we can't use I2C there's SMBus, but again, in the documentation, it only says it supports read block and write block protocols,

so does this mean it doesn't support single reads and writes? 

Sorry, I don't want to inundate you with too many questions. I just want to clearly understand how we're going to control this device in practice.

So if you have a programming guide or something with more detail as to how the thing actually works, I'd be grateful. 

Many thanks,

Elton

Hi Elton,

Reprogramming the EEPROM over USB requires a manual driver installation so yes it requires a user to be involved.

When the hub is in I2C master mode, it is only expecting a single EEPROM to be connected and it only checks the EEPROM after reset.  If the EEPROM was updated or changed after that point, the hub wouldn't see it until  after the next reset.  

Using a SMBUS host is typically the easiest way to support applications where the register values of the TUSB8041 may need to change.  Again the hub is really designed to only be configured at reset, so there isn't a way to dynamically reconfigure the hub without at least forcing a soft reset over SMBUS.

Regards,

JMMN

Hi JMMN, thanks for getting back to me. 

In looking at it, I'm now of the same opinion and think SMBus slave is the way forward. To make a final decision though, can you confirm that the device does support single byte read/writes, and not just block reads/writes? I figure we'd only ever need to change around 7 registers, so could easily do them one at a time. 

And what you say about "at least forcing a soft reset over SMBus" is interesting. This says we could avoid a full hard reset yes? So how do we do a soft rest "over SMBus"? Is there a particular register or bit that controls this? We can do a hard reset, I was just curious as to doing it the other way. Options are always good.

And one more detail if you don't mind - can we use the stsOutputEn bit in the Additional Features Config. Reg. to mask the external config. resistor pulls? So for example, at reset the SMBUSz pin has a resistor pull that sets the device to be an SMBus slave, but we go in and set the stsOutputEn bit to tristate the HS/SS & HS/SS_SUSPEND outputs (SS_SUSPEND = SMBUSz), then reboot the device so it ignores the external pull and uses the internal pull to become an I2C Master?

Many thanks,

Elton

HI Elton,

I'm tracking down with design where the "block protocol" note in the datasheet originated since I typically just write / read individual registers in SMBUS mode without any issue.  Please note that the hub will by default load in settings from the pin configurations and then these can be overwritten by a SMBUS host in SMBUS mode.  Also, once SMBUSz mode is enabled, the hub will not operate as a hub until the cfgactive bit is set in the registers.

There isn't a true soft reset in the registers, but there is a SMBUS reset which sets the registers back to their default state and then the hub can be reconfigured.  It is still best to do a hard reset, then configure SMBUS to ensure that the hub disconnects and re-enumerates with the latest configurations loaded.

Unfortunately, it isn't possible to mask the pin configuration settings.  The hub is hard coded to sample the pins as it exits reset and latch the values internally and then the pins become status outputs or whatever their secondary function is.

Regards,

JMMN

Ah, the block read / write access is in addition to supporting the single read / write access.  That should have been more clearly stated in the datasheet.

Regards,

JMMN

Hi JMMN,

thanks for your help and clearing up my questions. 

So, if I could clarify the correct steps when making register changes if you don't mind:

Boot as normal-->Load pin config settings (SMBUs enabled)-->Change settings (over SMBUs)-->Reboot

Is this correct?

If so, first question is, won't the hub just reload the pin config settings again after a reboot, and put things back to square one?

If you don't need to reboot, is it just a case of setting the cfgactive bit instead of rebooting, and then the device will be off and running?

Many thanks,

Elton

Hi JMMN, thanks very much for the detail. 

OK, I don't quite know what to do with this now to be honest. So we can make changes to the settings and HOPE they stick, or we can do a reset

and guarantee they won't! 

That's both hilarious and yet not hilarious, all at the same time :(

So what options do we have? Hmmm...

I suppose we could just get the settings perfect, from the start. Can I borrow the Ti company time machine for the weekend please?

Or what about the smbusRst bit in the Device Status and Command Register - what does that do?

Is that the "soft" reset you mentioned before? 

And can I just check a couple of things with you please:

- The way it's wired up at the moment, I was going to toggle the core 1V1 supply to do the reset as the global reset is being used in a different way. 

Will this be OK and have the same effect as toggling GRSTz?

It won't introduce any POR issues in the chip as the 3V3 will remain constant?

- What are the default register settings? Is there a list I can have?

- What size is the OTP, and can you confirm that it definitely comes empty yes?

Thanks again,

Elton

Let me clarify, any time you write the registers over SMBUS the values you write will load into the hub, but the host controller won't go out and read the hub descriptors until the next USB enumeration event.  The only way to force an enumeration event  from the hub in a connected system is to assert reset to the hub.  That's why I was recommending starting from a reset, set all the values and then the host will enumerate the hub.and read in the latest values. 

The TUSB8041 is a state machine based design with limited configuration options so we don't have many customers that adjust the register values outside of the development phase.  What values do you think might change?  The default register values are listed in the datasheet, this document has some additional information on the registers:

Pulling 1.1V low won't reliably reset the hub, only pulling GRSTz low will do that.  

Section 8.3.3 in the datasheet explains what the OTP can be used to control.  The OTP bits come cleared, but they can only be used to adjust polarity, VID/PID,non-removable status, and a few other options.

Regards,

JMMN

Hi JMMN, thanks again for your help and clarification. That makes a lot more sense which I'm really glad to hear because we've designed it in now!

I/we really don't know what might change further down the line because this hub is providing USB to our "Future Expansion" ports which will accommodate plug in cards.

Some of these will be off the shelf reference designs, but we may design our own and we may want to turn on battery charging for example, or the Ganged power feature.

We just don't know.

The chances are we won't, but it's all about keeping our options open. 

If I can ask a couple more questions I think I'm done:

Just to clarify that the OTP is One Time Programmable yes? Just that there were a few conflicting references that seemed to indicate it's not one-time and you're done.

And what does JMMN stand for?! :) 

Thanks,

Elton

Julie. Hello... it's nice to have a name, not an alphanumeric :) 

Thanks for your concern. It's nice to hear because I've not really chosen a USB hub before, hence all the questions.

And thanks for your warning on the EPROM. I have left an EPROM on there just in case, but just to clarify, if I have the pull-down on SMBUSz to put it into SMBus mode,

it'll always boot into SMBus slave mode, never into I2C master mode correct?

If that's correct, great, but are you then saying that if, further down the line, our settings are stable and we want to just let the hub boot from a PROM, IF that PROM is empty

the hub will go into programming mode and just sit there?

Thanks,

Elton

So just to be crystal clear Julie, even if we have the SMBus Slave mode pull-down, if there's also an EPROM attached, it'll still enter programming mode?

So the presence of the EPROM will override the pull-down.