• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 1868 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C1294NCZAD: RBIAS when not using Ethernet PHY

D House
Intellectual 275 points
Part Number: TM4C1294NCZAD
Other Parts Discussed in Thread: MSP432E401Y, TM4C129ENCPDT

Does the RBIAS resistor need to be placed even if the Ethernet PHY is not being used?

  • 0
    Mastermind 8695 points

    Yes. Unprogrammed devices will attempt to enable the PHY when a 25MHz crystal is present. Doing this makes the chip unable to talk to the debugger.

  • 0 in reply to Peter Borenstein
    Guru 117855 points

    Agreed - and well noted is the "tech" justification - in good support of your conclusion...
    This fact - which is "missed" by many - likely indicates that this requirement demands "greater & improved vendor emphasis..."

  • 0
    TI__Guru**** 191906 points
    Thanks to both Peter and cb1.

    Here is the errata.


    ETH#03 RBIAS Resistor Required Independent of the use of On-Chip Ethernet PHY
    Revision(s) Affected: 1, 2, and 3.
    Description: As per the data sheet the acceptable practice for Ethernet PHY enabled parts is a no
    connect (NC) to the RBIAS pin if on-chip PHY is not used. However the ROM Boot
    Loaders enable the Ethernet PHY when the Flash is erased for Ethernet PHY parts
    which causes the ROM Boot Loader to fail. Also if a 25MHz crystal is used without
    RBIAS resistor, then JTAG may not work.
    Workaround(s): A RBIAS resistor is required even if the application does not require the Ethernet PHY.
    In this case, a 4.7KOhm 10% tolerance resistor can be used in place of 4.87KOhm 1%
    tolerance resistor between the RBIAS pin and GND
  • 0 in reply to Charles Tsai
    Guru 117855 points

    While this "errata note" IS clear - we all know - that "not everyone" makes the time/effort to FIND - and then properly READ/REVIEW - such data.

    I hold by the belief that the MCU Manual (ideally) has INADEQUATELY ALERTED client-users - to this "Non-Obvious" (add so precise a resistor value) circuit requirement.

    Is not the PROOF of the "Warning's FAILURE" - the many posters - who (like the one here) express "grave uncertainty - or (even) MISS" - such warning?"

    Is it not "poetic" - that MCUs (so often employed in "Control Applications") would enable their Client Warning Systems - to operate without "proper" (i.e. ANY) vital client-user (corrective) Feedback?

  • 0 in reply to cb1_mobile
    TI__Guru**** 191906 points
    Hi cb1,
    I acknowledge your concern. There is currently no plan to update the datasheet in the short term. But I can see if adding additional notes into the TM4C129 System Design Guidelines application note will help the users.
  • 0 in reply to Charles Tsai
    Guru 117855 points

    Hi Charles,

    The workload IS - and remains - HIGH.      Yet the "TOO OFTEN OCCURRENCE" of such issues (should) concern - should it not?

    It is noted that there WAS "Time & Energy & (mistaken) EFFORT" - to  behead  "LIKE!"     Yet RARELY - time/energy/effort - to resolve LONG LINGERING Issues/Problems.    

    The (endless) repetition - forced upon (your) Vendor Staff - not to mention the "confusion & delay - suffered by your client-users" - points to the NEED for (some) improvement...   (one would hope...)

  • 0 in reply to Charles Tsai
    Mastermind 8695 points

    The note on table 31-7 in the datasheet is appropriate. Maybe it could be clearer. I fancy myself as competent and yet I fell victim to this issue. The datasheet is over 2,000 pages. I perform many rolls within a small company, and it seems unreasonable that a missed footnote causes such problems.

    What do you think is the root problem of this issue? It is tempting to blame the ROM bootloader, but a bootloader would intentionally turn on the PHY if the goal is to receive firmware via Ethernet.

  • 0 in reply to Peter Borenstein
    Guru 117855 points

    Might the "FIX" - which clearly results from a,  "BOLDER,  better HIGH-LIGHTED & more  "prevalent/recognizable/repeated"  WARNING" - be far  "faster & easier" to implement - than any,  "Root Problem Analysis?"

    Does NOT  "INERTIA" - operate  greatly against - so (demanding) an identification - which (STILL) - fails to insure ( and even BEGIN to Implement) a "FIX?"

    Your "role" of trouble-shooter must embrace reality - is that not so?

  • 0 in reply to Peter Borenstein
    Guru 92251 points

    Peter Borenstein said:
    It is tempting to blame the ROM bootloader, but a bootloader would intentionally turn on the PHY if the goal is to receive firmware via Ethernet.

    The MSP432E series appears to based upon the TM4C129 series, but with some errata fixes. The list of published errata for the MSP432E is less than that of the TM4C129.

    E.g. ETH#03 is NOT listed in the MSP432E errata SLAZ709 dated October 2017.

    Having saved the ROM contents of a TM4C129ENCPDT silicon rev A2 and a MSP432E401Y silicon rev A2 the ROM contents from 0x01000000..0x0100E6FF was exactly the same.

    The MSP432E does have changed silicon because the the Class field in the DID0 register is different (0xa for a TM4C129 and 0xc for a MSP432E), based upon diagnostics from a program which identified the size of the ROM and saved the ROM contents to the PC for inspection:

    On a MSP432E401Y:
Running on Device Class=0xc Major Revision=0x0 Minor Revision=0x2
DID0=0x180c0002 DID1=0x102dc06e
ROM version 0x301 size is 0xe700 bytes

On a TM4C129ENCPDT:
Running on Device Class=0xa Major Revision=0x0 Minor Revision=0x2
DID0=0x100a0002 DID1=0x102dc06e
ROM version 0x301 size is 0xe700 bytes

    I.e. don't think the ROM bootloader is the cause.

    I haven't attempted to test a MSP432E401Y to check ETH#03 has actually been fixed.