This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

  • TI Thinks Resolved

TUSB8041-Q1: EEPROM Access

Prodigy 195 points

Replies: 18

Views: 112

Part Number: TUSB8041-Q1

Hi,

we're going to use this chip in our design but can you tell me, once it's embedded in the design, can we still program the attached EPROM via the USB2 Host interface?

So the connections would be:

USB2.0 Host (USB2.0 Link) ---> TUSB8041-Q1 ---> EPROM (over I2C)

Reason being, we want to be able to reprogram the EPROM any time in the future, depending on how things work out.

Thanks,

Elton

  • 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

  • In reply to 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

  • In reply to JMMN:

    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

  • In reply to Elton Mckenna:

    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

  • In reply to 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

  • In reply to Elton Mckenna:

    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

  • In reply to 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

  • In reply to 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

  • In reply to Elton Mckenna:

    Hi Elton,

    Here's how the hub loads in values in the various modes.  Once up and running and connected to a system, any I2C or pin configuration changes will not be seen by the hub until after the next assertion of GRSTz.  A SMBUS host can change the registers while the hub is connected, but it cannot be guaranteed the values will load in until the next time the hub is re-enumerated so the cleanest way to do it is to start fresh from an assertion of GRSTz.  You are correct that doing a reset after loading the values would just clear them out again.

    SMBUS MODE:

    • GRSTz assertion ends
    • Pin configurations loaded into hub
    • Hub sees SMBUSz low and enters programming mode
    • SMBUS host configures hub
    • SMBUS host sets cfgactive bit
    • Hub connects to host with latest values.

    I2C MODE:

    • GRSTz assertion ends
    • Hub determines EEPROM is attached
    • Hub loads in values from EEPROM
    • Hub connects to host with latest values,

    PIN CONFIGURATION MODE:

    • GRSTz assertion ends
    • Pin configurations loaded into hub
    • Hub connects to host with latest values.

    Regards,

    JMMN

  • In reply to JMMN:

    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

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.