Harerod - thank you. I must be missing something because I read through that thread, and the two linked ones, and there is no actual information there.
What I don't get is why, when the 8742 "works" with a 25MHz xtal, it "should not work" with the 25MHz coming from the 32F4.
This has to be "nonsense"
But it is possible, for unrelated reasons e.g.
- it needs a sinewave input, and/or is somehow sensitive to the waveform, risetimes, over/undershoots, etc, which just "happen" to not be present with a xtal osc
- giving it its own xtal means its 25M clock is de-correlated with the 32F4 clock, and this avoids some subtle data sampling issues, possibly related to metastability BUT these issues will still occur periodically each time the two clocks pass each other, which given say a 20ppm difference will happen a few hundred times per second BUT it won't be noticed unless there is actual data being sampled AND it is within the metastability window (which is extremely narrow, with GHz-speed logic of the 32F4) AND if it corrupts data nobody will notice because of error detection/correction at the TCP/IP layer
whereas if one uses the 32F4's 25MHz output then the two are obviously correlated and if there is a problem, it will be there never, or all the time.
So unless I see something concrete, I don't buy this.
My hunch is that IF this was related to the 25MHz clock out of the 32F4, it would be a subtle sensitivity (of the 8742) to the waveform. I have seen this many times; Xilinx FPGAs (X3k, X4k) were notoriously sensitive to the edges on the config load clock.
BUT, as you can see in the photos above, the 25MHz out of the 32F4 looks exactly the same whether PCLK2 has a DIV4 or a DIV16 on it. On DIV16 the thing is totally unresponsive, on DIV8 or less it runs fine. That points to some sampling issue inside the 32F4.
What I can't determine is whether the DIV4 v. DIV16 shifts some data sampling internal to the 32F4 and exposes this problem. One of the old threads posted earlier alluded to delays between configuring one clock and configuring another clock so maybe somebody had this same idea. It is like the issue with the UARTs, where if you change the baud rate, it doesn't become active until the various counters have got all shifted out.
The PCB was done as carefully as I could. You can see the 8742 (IC17) and the 32F4. R87 is a 22R on the 50MHz clock
The integrated-magnetics RJ45 is an Hanrun HR911105A which is a very common part. There are many variations of it, and many more counterfeits (marked Hanrun too). We have tested a few of these and all work the same. I am inclined to go for a particular fake variant which is not only half the cost of Hanrun but has capacitors in series with the 75R resistors since this prevents the RJ45 smoking when somebody plugs in one of the chinese dumb POE injectors; another common problem...
"Both issues were a royal PITA to track down."
What did you actually find?