• State TI Thinks Resolved
  • Locked Locked
  • Replies 23 replies
  • Answers 2 answers
  • Subscribers 33 subscribers
  • Views 2174 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TUSB8044: issue with TUSB8044

ranchu
Guru 20755 points
Part Number: TUSB8044

Hello,

We got several days ago a new chip TUSB8044 from factory,and after adding it to board, we see that it is not working out-of the-box as before:

 Connecting to pc, it appears as "unrecognized device"

Is there a change in chip which can explain why with same chip TUSB8044 it worked without any issues ?

OLD working chip:

New non-functional chip:

Is it that chip is provided without any firmware ? Is it possible ?

Is it the same vendor/device ID ? Maybe vendor/device ID changed and are not supported/recognized by generic driver in PC ?

It's a bit urgent issue, because we didn't expect it to happen,

 I would appreciate assistance on this, 

Ran

  • 0
    TI__Guru 64326 points

    Ranchu,

    Could you try swapping the functional unit to the board with the non-functional unit (board in second picture). Test to see if the board in the second picture is the issue or if it is actually the "non-functional" part. Ensure that the solder connections are fully connected and that the thermal pad of the device in fully connected to ground.

    TUSB8044 has a built in state machine which should be operational upon the de-assertion of RSTN while SMBus is NOT held low.

  • 0 in reply to Malik Barton57
    Guru 20755 points
    Hi MaLik,

    Thank you for the quick response.
    I'll check it with HW staff,
    So, you don't think it is an issue of "empty" firmware ? Or a change in vencodor/device ID ? I ask becuase the PC is identifying "unrecognized device ". So, maybe there is a change in the vendor/device ID ?

    Regards,
    ran
  • 0 in reply to ranchu
    Guru 20755 points
    Hi,

    One more thing, how can I obtain tool for eeprom programming ?
    I can't find it in TUSB8044 page.

    Thank you,
    Ran
  • 0 in reply to ranchu
    TI__Guru 64326 points
    Ran,

    I will send you a message with the software attached. A change in VID or PID could lead to this issue. In order to test this I would suggest rewriting, using the software that I will send you, the default values as specified in section 8.5.3 - 8.5.6 of the TUSB8044 datasheet.
  • 0 in reply to Malik Barton57
    Guru 20755 points
    Hi Malik,

    Yes, please send me the tool (my email if required: ranshalit@gmail.com)
    I'll check that first thing in the lab tomorrow and update with results here.

    Thank you very much!
    Ran
  • 0 in reply to ranchu
    TI__Guru 64326 points
    Ran,

    You should have received the software through E2E.
  • 0 in reply to Malik Barton57
    Guru 20755 points
    Hi Makil,

    We continue now investigating the issue.
    I'll give more details:
    1. the working board (black board image above is actually EVM of the board TUSB8044RGCEVM.
    2. the board which is problematic is custom board, though the hub pins are the same.

    We shall try some more things which you have suggested, and I'll update results here.
    Anyway if you will have more ideas please let us know.

    Thank you very much,
    ran
  • 0 in reply to ranchu
    Guru 20755 points
    Hi,

    In continuity to previous details:
    1. with the new chip every reset we get different venodr/device ID !
    2. in EVB we get the same results (with correct vendor and product ID) every reset

    Regards,
    ran
  • 0 in reply to ranchu
    Guru 20755 points
    I have more update:

    In the custom new board the chip is TI 731 (non functional), while in the old custom board the chip is TI 741 , and it is functional.
    Since there are slight changes between these 2 custom boards, we shall replace the new custom board chip with the older chip (731), and see if it makes any difference.

    Regards,
    Ran
  • 0 in reply to ranchu
    TI__Guru 60865 points

    Hi Ran,

    It sounds like there may be an issue with the thermal ground pad connection on the TUSB8044.  Please make sure there is sufficient solder underneath the hub.  As Malik mentioned, the TUSB8044 is a state machine based device.  The EEPROM only provides configuration data at power on reset.  The VID/PID is hardcoded in the TUSB8044 unless overwritten by the EEPROM.

    Regards,

    JMMN

  • 0 in reply to JMMN
    Guru 20755 points

    Hello JMMN,

    Please see layout:

    1. pad size is 5.5x5.5 mm

    2. Size in layout is in millimeters units.

    Does the layout proves that there is an issue with not enough solid beneath the hub ?

    Best Regards,

    Ran

  • 0 in reply to JMMN
    Guru 20755 points

    Hi,

    We added a lot of solder... yet it has the same issue.
    Now we don't have our EVM any more, because trying to solder the chip back to EVM, results in high current in the EVM... :(
    Maybe the temperature when removing the chip from board, made damage to the chip ? No more EVM and more chips left, and we still don't know why it doesn't function, and has such instability with vendor id registers.

    If you have any more ideas please let us know.

    Thank you,
    Ran

  • 0 in reply to ranchu
    Guru 20755 points
    When replacing the "good chip" in the "problematic board", we still got unrecogized, so it is probably not issue of chip....
    Still struggling with it,. The problem is that now we don't have any more "good reference" to compare with , becuase trying to solder it back resulted in high current, as I mentioned before.

    Thank you,
    ran
  • 0 in reply to ranchu
    TI__Guru 64326 points
    Ran,

    Can you send or post a copy of the custom board schematic so I can take a look at it?
  • 0 in reply to Malik Barton57
    Guru 20755 points

    Hi,

    Here is the schematic.

    We also notice that if we reset hub, we read correct vendor ID, in smbus mode,

    yet, on doing the same HUB reset in the operational mode, we still get unrecognized (and wrong vendor id in windows).

    New and non-functional custom board schematics:

    BVA_SCHEMATIC_001 - PD_USB.PDF

    Thank you very much,

    Best Regards,

    Ran

  • 0 in reply to Malik Barton57
    Guru 20755 points

    Hi,

    I've also attached the bit older custom board with the same hub (which can be compared to the newer schematic from previous post)

    As I mentioned we first suspected that the hub version is the problem, but now we think that it is something with the new board.

    The old custom board had stability.

    We are still not sure why the new board has instability in recognizing PID/VID of usb hub.

    We also made experiment that we disconnected all upstream connectivity (type C/type A, PD (power delivery), and then we got first time recognize with the new board !

    Yet, after some resets the hub got crazy. we are not sure if it because we made some shortcuts in our cuttings and experiments....

    Maybe this whole issue relates to some instability or modifications in upstream wires from hub , which results in unrecognized device ?

    Thank you for the assistance,

    Ran

    Old and functional custom board schematics:

    BVA_SCHEM.pdf

  • 0 in reply to Malik Barton57
    Guru 20755 points

    Hello,

    We continue investigating this issue.

    We see that D+/D- lines behaves in a very strange way when there is unrecognized device:

    Just as if there is an issue with polarity. We see that the differential voltage between these pins is 1 or 0 volts instead of 3.3 volts.

    Please see attached image below.

    Regards,

    ran

  • 0 in reply to ranchu
    TI__Guru 64326 points

    Ran,

    A couple of items:

    1) The scope capture you posted seems to be normal when there is no connect device as the hub goes into suspend mode.

    2) Could you clarify this statement: "We also made experiment that we disconnected all upstream connectivity (type C/type A, PD (power delivery), and then we got first time recognize with the new board !"

    3) In the updated custom board schematic I suggest that you remove R35.x, R36.x, R37.x, (x = [1 - 4]). It seems these resistor are connecting the upstream port on the hub to multiple ports (Type-B and Type-C). Try using the Mux (U9) and always connect to the Type B port. Getting the hub to work on one port first should be easier than multiple ports at one time.

    Apologize for the blank post earlier. 

  • 0 in reply to Malik Barton57
    Guru 20755 points
    Hello Malik,

    your message is cut,
    Can you please write it again ?

    Thank you very much,
    ran
  • 0 in reply to ranchu
    TI__Guru 64326 points
    Ran,

    I edited my previous post for you to view.
  • 0 in reply to Malik Barton57
    Guru 20755 points

    Hello Malik,

    We shell definitely try your suggestion, as we are a bit confused now with this issue after several days.

    As to section 2 of your answer, we actually cut all the connectivity to hub except to 2 wires connecting the upstream directly to PC (without type b, type c, just wires).

    Yet, it was too soon to think that it made the bug difference, becuase it still was unstable (sometimes it recognized, but most of the time it didm't. they only difference it made is that before that it never recognized the device).

    I think we should try to stick exactly more to your suggestion, and we shall update here with the results.

    Thank you a lot for your suggestions,

    Ran 

  • 0 in reply to ranchu
    TI__Guru 64326 points
    Ranchu,

    Do you have any updates on this issue?
  • 0 in reply to Malik Barton57
    Guru 20755 points
    Hello Malik,

    We haven't resolved it yet.
    Only after removing the upstream connectivity except leaving a single type-A, we got the first "device recognition" with the new custom board.
    Yet, there was still instability (over current sometimes, and unrecognized device).
    So, I think that this is quite the same as you suggested in your last post, Right ?

    Next thing we are going to do is to check terminations.

    There is probably some difference between the old and new custom board which can explain this failure with the new custom board (I have attached both of schematics in previous posts).

    If you have other suggestion s you can tell me. I will update if we have any progress with this issue.

    Thank you very much,
    Ran