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.

TUSB3410: USB Standard Configuration Descriptor

Part Number: TUSB3410
Other Parts Discussed in Thread: TUSB2046B

Hi team

Could you tell me about my customer's question.

My customer wants to change the bmAttributes to "Bus powered" in "USB Standard Configuration Descriptor".

But, they can't write the bmAttributes to "0xC0".

When I checked the follow question, I thought the firmware may be you have.

e2e.ti.com/.../2175911

If you have the firmware, would you give me?

Best regards.

Hayashi

  • Hayashi-san,

    I am working on generating the firmware file. I will provide it to you soon.

    Regards,
    Jorge
  • Jorge - san

    Thank you for your support.
    I'm waiting for your new firmware.

    Best regard

    Hayashi

  • Jorge - san

    Thank you for your support.
    If you get the new firmware, would you send me soon?
    if not, when will you send me the new firmware?

    Best regard

    Hayashi
  • Hayashi-san,

    My apologies for the delay on this; it took us some time to setup the required compilation environment.

    I am attaching the requested firmware binary setting bmAttibutes to 0xC0 (Self-powered configuration)

    Regards,

    Jorge

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/umpe3410-self.I51

  • Jorge - san,
    Thank you for your support.
    I am going to check the firmware.
    Best regards,
    Hayashi
  • Jorge - san,

    Thank you for your supports.
    And, my customer has new questions.
    Would you let me know the follow questions?

    I. Is it OK to recognize that the USB Standard Configuration Descriptor is not read from the EEPROM and it is necessary to change the F / W? Also, is this F / W that Descriptor will be read from EEPROM? Or is it F / W fixed as Self Powered?

    II.My customer did not store F / W in EEPROM but planned to download from Host. I think that the file you sent is F / W when storing in EEPROM, but you can also provide F / W when downloading from Host Is not it?
    Also please tell me how to test its behavior.
    C: \ Program Files (x86) \ Texas Instruments Inc \ TI_WDF_USBUART_SINGLE_DRIVER_V6.7.2.0_WHQL \ 64-bit umpf3410.i51 can be replaced only?

    III.The customer's device configuration is as follows.
    Host (PC) -> TUSB 2046 B (Self powered setting) -> TUSB 3410 -> MPU
    As same board from TUSB2046B to MPU, they operate with self power.
    When performing the Chapter 9 test on TUSB 3410 in this configuration, the following error has appeared in Configuration Descriptor Test.

    ERROR Device Reports BUS Powered in configuration descriptor and is currently SELF powered.
    FAIL (9.6.3.25) A Device must report the same type of power in the configuration descriptor as in GetStatus.
    I do not understand why Get Status reports as Self-powered, can you teach me?
    Also, is there any harm in using this condition without correcting FW? They do not plan to acquire the USB logo and I think that it is no problem can be made if the operation is not harmful.

    Best regards.
    Hayashi
  • Hayashi-san,

    I. That is correct. Current firmware isn't apparently prepared to load the bmAttributes configuration from the EEPROM headers, hence the value cannot be customized using the EEPROM burner utility and value has to be changed on the firmware code (as we did)

    II. Unfortunately that won't be posible. The firmware file loaded by the driver is digitally signed along with the driver binaries. If you simply replace the firmware binary with a different one, that would invalidate the driver's digital signature and Windows will prevent user's from loading the driver (at least without a warning when disabling driver signature enforcement).
    Any customizations would require you to load the customized firmware from the EEPROM, otherwise you would need to sign the driver and firmware binary with your own certificate.

    III. I am guessing the firmware is designed to report itself as self powered when requested through GET STATUS. I would need to check the firmware to confirm that. Anyway, if no USB compliance logo is pursued, this won't represent any harm to the hardware configuration; although I would assume the issue/reported error would go away now that the configuration descriptor is also reporting a self-powered configuration. Thanks for bringing this to our attention.

    Regards,
    Jorge