• State
  • Locked Locked
  • Replies 23 replies
  • Subscribers 33 subscribers
  • Views 5102 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.

TM4C129XNCZAD: Ethernet PHY boots into a broken state when not used

Peter Borenstein
Mastermind 8695 points
Part Number: TM4C129XNCZAD
Other Parts Discussed in Thread: UNIFLASH,

TM4C129Xs fresh from TI following the data sheet's preferred practice are bricked.

The datasheet's table 31-7 says an unused Ethernet PHY should leave RBIAS not connected. This is the preferred practice. This bricks the chip.

I received unprogrammed TM4C129Xs from my CM without the 4.87k resistor connected to RBIAS. The micros could not be programmed. CCS gave me error 2062.

This thread gives us background: 

Error -2062 when programming a TM4C129XNCZAD processor, what does it mean? - Arm-based microcontrollers...

e2e.ti.com
Other Parts Discussed in Thread: TM4C129XNCZAD , UNIFLASH , TM4C129ENCPDT I am using the Black Hawk XDS100v2 JTAG emulator to program a TM4C129XNCZAD processor

Amit claims the error is caused by code within the micro trying to turn on the PHY. But these devices were never programmed.

I had to (1) remove the 25MHz crystals. (2) Flash in a bogus code that doesn't turn on the PHY. (3)Re-solder the 25MHz crystal. (4) Do real work.

I'm fairly upset at the time wasted. I assume this problem can remain hidden to TI because most customers would not buy this chip without the intent of using PHY. I intend on using PHY in the final design, but this order was a prototype which only tests the EPI and LCD interfaces.

  • 0
    Mastermind 8695 points
    In the cited post, Steven Wallcave never gets his problem solved...
  • 0 in reply to Peter Borenstein
    Guru 55713 points
    Hi Peter,

    Are you certain the CM pre-programmed the MCU?

    The issue you mention is clarified errata where the embedded ROM boot loader tries to access the Ethernet after POR when Flash memory is erased or (blank). Others have simply solder on a 4.87k 1% resistor near the pin using vey fin wire wrap or other means.
  • 0
    TI__Guru*** 135315 points
    Hello Peter,

    The 'preferred practice' also comes with a foot note that the internal PHY should not be activated and that if the ROM Boot Loader were allowed to execute with a 25MHz crystal on board, it would enable the PHY and cause the issue.

    It actually is a very common issue reported on the forums, so it's not a hidden problem to us. I believe Amit and Steven solved his further problem(s) offline as the posts seemingly halted once Amit made a suggestion to debug offline. Anyways, Steven aside, many many others have faced the RBIAS issue after that and solved it by adding RBIAS to their designs.

    With that in mind, another solution than desoldering/resoldering the crystal is what BP101 recommended which is to just add RBIAS.
  • 0 in reply to Ralph Jacobi
    Mastermind 8695 points
    The TM4C129XN only comes in a BGA package so I can't solder a resistor to it.

    Steven asks how to proceed 3 months after the proposed debug session.

    Back to the main point, the preferred practice for an unused signal bricks the micro upon arrival. Does that sound odd?

    I would expect the preferred practice to result in functional hardware. Wouldn't you?
  • 0 in reply to Peter Borenstein
    TI__Guru*** 135315 points
    Hi Peter,

    I don't disagree at all, even with the footnote having those options swapped would seem preferable. I wasn't around when the datasheet was made though so I don't know the logic that went into that choice.
  • 0 in reply to Ralph Jacobi
    Mastermind 8695 points
    Let me know if you ever need a vocal advocate for change
  • 0 in reply to Ralph Jacobi
    Guru 55713 points

    Hi Ralph,

    Ralph Jacobi said:
    The 'preferred practice' also comes with a foot note that the internal PHY should not be activated and that if the ROM Boot Loader were allowed to execute with a 25MHz crystal on board, it would enable the PHY and cause the issue.

    Perhaps I have missed something in the fact that when the Flash memory is not blank as Peter claimed (CM had programmed) in such case the ROM boot loader should not attempt to engage the MOSC 25Mhz crystal.

    How do we know the CM did not use the JTAG port to first program the flash and would JTAG DAP have a higher priority on AHB over that of document errata (ROMBL) failure from missing RBIAS resistor?

    Perhaps CM did not program the flash or was unaware it failed, posters question thus being answered by the explanation of certain errata from blank erased flash is known to exist?

  • 0 in reply to Genatco
    TI__Guru*** 135315 points

    Hello BP101,

    Peter also stated the devices were not programmed and they were fresh from TI, so it's not definitive one way or another. Based on symptoms and steps to resolve, it sounds very much like that was the case. But yes, Peter can (and probably should) confirm for us whether or not the CM actually programmed the devices.

  • 0 in reply to Ralph Jacobi
    Mastermind 8695 points

    The CM was a rapid prototype house. I only had 10 made to test a new RAM chip. CMs don't typically do things without being paid to do it.

    Without instruction, the CM would have to pick a program (built from ??? source code), buy a debugger, buy a special connector cable I use, set up a PC with some programming app, and then have someone on the line program. I suppose I could ask, but the idea is not fathomable in my mind. I shall ask anyways.

    Also, erasing the flash (with UniFlash) results in the same un-connectable state (error 2062). So that's proof a blank device will not work when the preferred practice is followed.

    On a side note, Tag-Connect makes the cable and they are super useful for minimalist programming pads. I do recommend. I think TI uses them too because I sse the same programming footprint on their launchpads.

  • 0 in reply to Peter Borenstein
    Mastermind 8695 points
    The chips were never programmed. The CM confirmed this.
  • 0
    Guru 55713 points

    Peter Borenstein said:
    I received programmed TM4C129Xs from my CM without the 4.87k resistor connected to RBIAS

    Perhaps you might edit the 1st post so future readers do not think the Flash was indeed programmed by CM. Do we not program an embedded MCU, slang for writing the application to flash?

    Has not the question been answered by myself and TI engineer?.

  • 0 in reply to Ralph Jacobi
    Guru 55713 points
    Hi Ralph,

    You never answered the question if JTAG DAP has priority over the ROM boot loader accessing EMAC0 if RBIAS is missing? In my mind the DAP should gain priority access to flash memory over EMAC0 on the AHB after an ARM core reset, perhaps even after POR.
  • 0 in reply to Genatco
    Mastermind 8695 points

    This post is more of a complaint than a question. The workaround is in the original post.

    I will give resolved credit and say nice things about anyone who posts "I will change the datasheet's preferred practice"

    You're thoughts are still valued! Interesting related insights are an opportunity to learn, but they don't quite merit being called a solution.

  • 0 in reply to Peter Borenstein
    Guru 117855 points

    Peter Borenstein said:
    Let me know if you ever need a vocal advocate for change

    First - small firm staff and I, "Feel your pain!"    Tighter client-user guidelines - beyond "best practice" - seem much in order.

    While your frustration is justified - your dealing w/skilled vendor agent here (who was & remains totally blameless) seemed at times - bit harsh.    (note that I too - on "not so few" occasions - have directed "Howitzer Fire" upon vendor's inane, "rules/regulations.")

    Your offer of "vocal advocacy" (to vendor's agent here) - may prove "less effective" than your, "Direct Contact w/vendor's nearest Sales Office."     (usually far "better equipped" to steer your factual protest "up channel" - where it enjoys the greatest hearing, thus "chance for success."    (having past worked for a similar Semi-giant - it must be noted that "VOLUME TALKS" - and most always "propels" such change!)

  • 0 in reply to cb1_mobile
    Mastermind 8695 points
    I didn't mean it to be mean. Sometimes people can get their actions blocked for not providing "customer value". We can get a petition going instead of yelling. Just trying to help...
  • 0 in reply to Peter Borenstein
    Guru 92251 points

    Peter Borenstein said:
    We can get a petition going.

    Datasheets for some other devices have a link to a Submit Documentation Feedback form.

    The link is missing from Tiva datasheets, but I think you could use http://www.go-dsp.com/forms/techdoc/doc_feedback.htm?litnum=SPMS444B&partnum=TM4C129XNCZAD to submit a suggestion on the TM4C129XNCZAD datasheet.

    In case you hadn't seen it, the following is a description of the problem from the device errata:

    Errata ETH#03 is documented as affecting all existing silicon revisions 1, 2 and 3, which is more reason for updating the preferred practice in the datasheet.

  • 0 in reply to Peter Borenstein
    Guru 117855 points

    I did not characterize your writing as "mean."     (it did target one who offered aid - thus proved ill-aimed - and harsh)

    Again - your best ability to impact this situation - to "vocally advocate" (just as you've offered) results from your visit to vendor's nearest Sales Office!

    "Petition going" has (little) chance - likely delays/defeats your declared purpose!     (by retreating - far - from your promise of "vocal advocacy"...)

  • 0 in reply to Genatco
    TI__Guru*** 135315 points

    Hi BP101,

    BP101 said:

    You never answered the question if JTAG DAP has priority over the ROM boot loader accessing EMAC0 if RBIAS is missing? In my mind the DAP should gain priority access to flash memory over EMAC0 on the AHB after an ARM core reset, perhaps even after POR.

    It got lost in my attempt to explain my interpretation of Peter's post.

    The JTAG unfortunately does not have priority over the ROM Boot loader, hence why this problem occurs somewhat regularly. Most of the posts on it begin with 'My JTAG isn't working!'... and the issue gets resolved with the addition of RBIAS and then the device and thus JTAG in turn are happy again.

  • 0 in reply to Ralph Jacobi
    TI__Guru**** 184426 points
    Hi BP101,
    Below is the excerpt from Cortex M4 TRM.

    For simultaneous accesses to the 32-bit AHB-Lite bus, the arbitration order in decreasing priority is:
    • Data accesses.
    • Instruction and vector fetches.
    • Debug.
  • 0 in reply to Charles Tsai
    Guru 55713 points
    Hi Charles,

    Chester posted the ETH#03 text "Then JTAG (may) not work when RBIAS is missing."

    Debug meaning JTAG simulator SWD being lowest priority and SWO mode meaning (Data access/port) DAP)) + (may) could result in control over Flash memory writing.

    There must be a timing limitation to when (may) actually works after RST and or DAP has priority control of AHB prior to EMAC0 peripheral clock being configured in ROM boot loader.
  • 0 in reply to Genatco
    Mastermind 8695 points

    >addition of RBIAS
    >BGA
    T_T

    BP101, I fixed the post. Sorry for the confusion about programming. My hands don't always type what's in my head perfectly.

  • 0 in reply to Genatco
    TI__Guru**** 184426 points
    Hi BP101,
    I think it may be a race condition between JTAG debug access to the CPU accessing the EMAC module. I never tried myself but If the debugger can halt the CPU before the CPU running the ROM bootloader is able to configure/enable EMAC after the reset then it maybe able to workaround the errata (non-working JTAG).
  • 0 in reply to Peter Borenstein
    Guru 55713 points

    Peter Borenstein said:
    My hands don't always type what's in my head perfectly.

    Who don't have that going on at times.

    Good news if PCB has reset button (may) be able to race ROM boot loader execution via LM flash programmer being made ready up to point of clicking on program button. Sure would beat taking XTAL off each time after a flash full erase. I know first hand the DAP can loose bus priority when watchdog timer is running background in a previous flashed application.