cancel
Showing results for 
Search instead for 
Did you mean: 

Ethernet does not turn on after hard reset

drobison
Associate II
Posted on October 01, 2013 at 23:13

The original post was too long to process during our migration. Please click on the attachment to read the original post.
4 REPLIES 4
Posted on October 02, 2013 at 02:43

Any particular board/phy?

How about a reset via ETH->DMABMR  |= ETH_DMABMR_SR; then spinning while it's set
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
drobison
Associate II
Posted on October 02, 2013 at 17:58

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6dO&d=%2Fa%2F0X0000000bsB%2F2VIuFrLRL77a5lVmsvLivO997XpwQiv3jO5d1YNM3iQ&asPdf=false
Posted on October 02, 2013 at 18:19

Yeah, doing things at this level is a bit nuanced, the USB/Ethernet cores come from Synopsis, if I recall, and the documentation is best reviewed in context with the software demos. Assume the technical writers grasp neither the silicon or the software to the level that might be desirable.

There are likely external and internal clock dependencies, and certainly some conditions that expect certain clocks to be on and others off. The MAC/PHY are two separate parts, but are interdependent thus requiring the GPIO interfaces to be up.

I did find your brute force assembler style to be somewhat amusing. <G>

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on October 03, 2013 at 06:49

> the documentation is best reviewed in context with the software demos.

Nicely said.

The documentation is crap. That the chip is hastily stitched up from purchased IPs, is no excuse. I am buying chips from ST, not from Synopsis, ARM, or whoever else contributed.

> There are likely external and internal clock dependencies,

Indeed. My finding was, too, that the reset never finished until the external clock to MAC was available (in my case, the clock (I use external oscillator for RMII) got damped to nil due to poor design of the EVAL board, I reported on this forum). You might want to keep this in mind for failure diagnosis in production/service. IIRC, the example/''library'' employs a timeout in waiting for the reset to complete; and the application might provide an error message or other diagnostics upon this timeout, if applicable.

JW