STM32F417 - any reason why a min PCLK2 speed is required for ethernet to work?

[peter-h]

With a 168MHz core, I am finding it runs with DIV8 i.e. 21MHz, or anything faster, but fails with DIV16.

There isn't anything in the ST ethernet code AFAIK which relates to PCLK2. Ethernet uses its own 48MHz source.

There are 2 timers - systick and tim6, both running at 1kHz, neither related to PCLK1.

Could it be there is some data sampling issue which requires PCLK2 to run at x times something?

Needless to say debugging this will be complicated.

I don't need 10.5MHz PCLK2; it is just handy for low baud rates:
https://www.eevblog.com/forum/microcontrollers/32f417-any-way-to-get-baud-rates-below-1200/

EDIT: it turns out somebody has been here before, and as usual without any resolution:
https://community.st.com/s/question/0D50X00009Xkgdi/ethernet-mac-stops-transmitting-when-apb2-divided-by-16-stm32f407

It appears that slowing down PCLK1 is ok, but that screws up SPI2,SPI3 and other stuff.

Problem is one can't use DIV8 (21MHz) because one doesn't know the margin, so the slowest sensible PCLK2 is DIV4 (42MHz) if you are using ethernet.

[wek]

Today I tried to set APB2 clock to AHB/16 on an 'F427 (which is almost identical to the 'F405/407/415/417) and ETH worked as usually.

I don't Cube.

Debug as usually - start with checking you have properly set clocks in RCC, check presence of the 25MHz/50MHz clock (do you use MII or RMII? What's your hardware? How do you generate the ETH clock?). Check, if SMII/MDIO works, observe waveforms on pins, check that PHY responds properly. Read out and check/compare ETH registers content.

> EDIT: it turns out somebody has been here before, and as usual without any resolution:

As usual, that somebody did not care to pursue the problem.

JW

[peter-h]

This is the clock config



There was another report somewhere of this issue, and it said that the width of the pulses on the ethernet cable shrinks when you do DIV16 on PCLK2.

This is not related to Cube IDE; well not in any obvious way.

The hardware is based on their dev board i.e. LAN8742 fed with a 50MHz clock from PA1. 32F417 xtal is 25MHz. The frequencies of PCLK1, PCLK2 have been checked in several ways, including viewing SPI2/3 clocks with a scope.

Of course, the cause could be some third factor.

Frankly, most people are not able to pursue this sort of thing, at the physical layer, because of the expertise required, not to mention the equipment, and they will already have spent so much time debugging the ST drivers.

[wek]

There was another report somewhere of this issue, and it said that the width of the pulses on the ethernet cable shrinks when you do DIV16 on PCLK2.

Can you please give a link to this claim?

This is not related to Cube IDE; well not in any obvious way.

No, the IDE is just that, an IDE (more precisely, Eclipse).  By Cube I mean the whole "ecosystem", of which the central part is the "library", in this case, CubeF4.

The hardware is based on their dev board

Who is "them", ST? Which dev board in particular?

PA1 is input in this case, ETH_RMII_REF_CLK. So the 50MHz clock is generated by PHY; what is the clock source to that PHY, then?

You can also try to run your code on said dev board, to have a "known good" reference point.

Frankly, most people are not able to pursue this sort of thing

That's why there are more ready-made solutions like the Wiznet chips, or boards like RPi, around.

JW

[peter-h]

The 50MHz comes from the LAN8742:



Same as the dev board, IIRC - the STM32F407G-DISC1. The ethernet stuff is on STM32F4DIS-EXT.

[wek]

The 50MHz comes from the LAN8742

Yes I see that, but what's the primary clock source of LAN8742?

STM32F4DIS-EXT

That module did not come from ST, although they do have a page for it (for historical reasons, they did actively promote some of the 3rd party stuff back then). As witnessed by the schematics (which is not available at ST, but at Farnell) was produced by a chinese company called Embest Technology, at the time when it had already been in the process of being absorbed into Farnell.

Although it uses LAN8720 rather than LAN8742 as PHY, there is perhaps enough similarity between these two chips. At any case, STM32F4DIS-EXT uses a 25MHz crystal with LAN8720 as its primary clock source, so for now I assume that's what you use, too.

The reason why I'm asking is, that it's a relatively common practice to feed the PHY's primary clock from a MCO output from the STM32. If that clock came from PLL, its jitter may result in the clock to be marginal for ETH (especially RMII), and changes in the RCC may indirectly cause it go out of spec range. There can of course be issues with marginal clock with different arrangement of the primary clock source, but in case of dedicated crystal oscillator directly on the PHY I find it unlikely to be related to APB clock (still not impossible, though, as improper power supply/ground/tracks arrangement can do wonders). That IMO is probably the cause of the issue you mentioned above, "pulse shrink on cable" - I'd like to see that source to confirm/reject.

So, assuming the primary clock source is PHY's dedicated crystal oscillator, and assuming that is precise and stable enough to be excluded as the source of troubles, you might want to concentrate on the debugging path I outlined in my first post, i.e. find out, what exactly "does not work" - check, if SMII/MDIO works, observe waveforms on MDIO/MCK pins, check that PHY responds properly. Check if PHY detects connected cable/speed properly. Check the waveforms on RMII pins. Read out and check/compare ETH registers content. Check if packets arrive and depart, by observing the behaviour of ETH registers.

JW


PS. For the laughs, a personal story of how did I find out the importance of clock integrity when it comes to ETH/STM32 here.

[peter-h]

" but what's the primary clock source of LAN8742?"

The CPU - 25 MHz out of PC9. The dev board circuit is this



but here we are getting the 25MHz out of the CPU's PC9. That came out of some other ST appnote, but I can't recall which. I found this

https://community.st.com/s/question/0D50X00009XkiAE/can-stm32f207xx-generate-50mhz-clock-for-rmii-ethernet-phy-

There is also this
https://docs.rs-online.com/97b6/0900766b813f6b00.pdf
(search for MCO) which shows the option for the CPU to generate the 25MHz clock.

What is somewhat worrying is the ambiguity on whether this needs to be 25MHz or 50MHz. I would think 25 must be fine since it is definitely fine with a 25MHz xtal.

You are right about possible jitter issue, but why would PCLK2 DIV16 affect that?

I did the hardware design, having read every word of the 32F4x7 300 page data sheet, but I didn't do the original investigation on this 25MHz setup. But yes this does show 50MHz for the reduced interface



The 8742 data sheet makes it clear you can use 25MHz from an oscillator, and therefore also from the 32F4, and the following is exactly what we are doing:



It would certainly be easy enough to scope this 25MHz, and do that with DIV16 and DIV8. Let me try that today.

[peter-h]

The PCLK2 divider value has no effect on the 25MHz coming out of PC9. And there is no difference in the jitter (invisible on a scope even at x10 mag; the photos below are just out of focus but I re-examined them later]. The following are from a 200MHz scope:

This is the 25MHz, 1V/div vertically, with DIV4 (42MHz) on PCLK2



This is with DIV16 (10.5MHz)



The 50MHz output of the LAN8742:



The 50MHz is going through a 22R, to reduce EM, but the waveform looks no different on the scope either side of that.

Previously there was a mistake there: that resistor was 220R and that made the waveform more like a sawtooth, but that had no bearing on this issue.

Doing a ping over the LAN, 1470 byte packets (about the max), is error free, over ~1000 packets.

Ping statistics for 192.168.1.63:
    Packets: Sent = 1000, Received = 1000, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 20ms, Average = 9ms

The lack of jitter tells me the 25MHz PC9 output is generated from the 25MHz 32F4 crystal oscillator directly, and not from the 168MHz core clock (which would need to be 150MHz to have any hope of an exact jitter-free 25MHz). I vaguely recall the 25MHz xtal being a required frequency for ethernet operation.

[harerod]

peter-h, how is your German? I don't want to re-iterate the whole story about PHYs on the STM32F4:
https://www.mikrocontroller.net/topic/360978

Long story short: myself and several customers who asked me to fix their designs, ran into issues with PHYs on the F4. One typical issue is with the clock. This is reliably solved by giving the PHY its own quartz. That issue was introduced with the F4's clock system. Other solutions might be possible.


A secondary issue is present and not documented in some PHYs. That issue stems from the PHY's internal reset circuitry, which requires a specific slope to work. If one faithfully follows the reference design, the issue will never surface. It took a while and a bit of wasted money, but Micrel helped me out, eventually.

BOTH issues described will not prevent a simple PING. However, during production operation with high LAN-load the connection will be slow and/or unstable. Both issues were a royal PITA to track down.

[peter-h]

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?

[ajb]

What is somewhat worrying is the ambiguity on whether this needs to be 25MHz or 50MHz. I would think 25 must be fine since it is definitely fine with a 25MHz xtal.

The LAN8724 datasheet explains this.  The reference clock can be a 25MHz crystal, a 25MHz clock, or a 50MHz clock.  For a 50MHz clock input, REF_CLK In Mode must be enabled (by strapping nINTSEL low). 

I'm not sure why you're focused on clock correlation between the PHY clock and the MAC clock, after all it's perfectly normal to have the RMII interface clocked by the PHY which may have an arbitrary relationship with the MAC's peripheral clock or other clocks in the processor.  The whole point of having a clock line on a bus interface is to not have to worry about the correlation of clocks between the devices on either end of that bus, and while timing issues are possible between the MAC's MII interface block and the parts that are synchronous with the internal bus clock that's something that should show up a lot given how common ethernet applications with either clock configuration are. 

It's also not clear what makes you seem to be so sure that the clock signal between the MAC and PHY is the problem and not something else.  Cube has a lot of layers between the API calls and hitting the peripheral registers in an attempt to make it all "just work" regardless of hardware and peripheral configurations, but that means lots of opportunities for bugs or missed cases.  In particular, the cube libraries provide a lot of automated clock tree handling, and it's entirely possible that there's some issue with how it handles the DIV16 in relation to configuring the MAC.  As wek has suggested, you should do some additional checks to see what is going on in the system.  Poke the SMI interface, check the configuration registers in the MAC (and compare the values in the working configuration with the non-working configuration) , probe the RMII interface and see if there's any activity, etc.

[peter-h]

I can make it work, or break it, by changing just the one line, defining the divisor of PCLK2.

/** Initializes the CPU, AHB and APB busses clocks
   * These settings override the stuff in SetSysClock which gets called earlier.
  */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;    // 42MHz - SPI2,SPI3,UART2,UART3,TIM2,3,4,5,6,7,12,13,15 etc
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV4;    // 42MHz - UART1,UART6

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5) != HAL_OK)
  {
    Error_Handler();
  }

and then inside HAL_RCC_ClockConfig we have

    if(((RCC_ClkInitStruct->ClockType) & RCC_CLOCKTYPE_PCLK1) == RCC_CLOCKTYPE_PCLK1)
    {
      MODIFY_REG(RCC->CFGR, RCC_CFGR_PPRE1, RCC_HCLK_DIV16);
    }

    if(((RCC_ClkInitStruct->ClockType) & RCC_CLOCKTYPE_PCLK2) == RCC_CLOCKTYPE_PCLK2)
    {
      MODIFY_REG(RCC->CFGR, RCC_CFGR_PPRE2, (RCC_HCLK_DIV16 << 3));
    }

and MODIFY_REG is just a bit field merging macro.

I don't see any funny stuff there (like there is in say the UART baud rate setting code).

I don't think it is anything to do with the 25MHz clock, but that was suggested above, so I set out to see if there is anything in it.

[ajb]

Those code snippets are only one part of the equation.  Other parts of the Cube libraries, including the parts that set up the MAC, will often refer to the clock tree configuration when they set up peripherals, so you'd need to look at those calls as well to see what implications changing the APB2 divider configuration might have and where that might be going wrong.  IIRC cube keeps track of the various bus clock frequencies when the RCC configuration is changed so that other parts of the libraries can use that information without having to inspect the RCC registers, so there could also be a problem there. 

But again, you can shave the problem space down quite a bit by first doing some more basic checks of what's going on in the system when it doesn't work.

[peter-h]

OK so if I get this right, we have two assertions as to the possible cause:

1) There is something magical about using an xtal (or perhaps some other async clock source) for the 8742's 25MHz clock

2) There is a bug in ST's config code, where it extracts some bit field out of the PCLK clock config registers and does the wrong thing with it (I would have expected this to surface rather sooner, given how long ago it was first reported)

Point 2) may get checked by examining whether the ethernet config registers change between PCLK2 having a DIV4 v. DIV16 on it. Can someone suggest which ones to look at?

[Yansi]

Wrong.

The PCLK minimum clock speed is related to the correct operation of the synchronization logic in between the internal bus and the external asynchronous clock domain, that may be or is dictated by an external clock source.

This PCLK minimum applies to a lot more different peripherals, than just ETH.

The minimum PCLK2 clock speed for ETH operation is even clearly stated in the manual, so whats this fuss all about? This is not a bug.

//EDIT: Just looked in the refmanual, and huh, the minimum of 25 MHz is specified for HCLK, not PCLK2.  Interesting.... Now I take back what I have said, no idea what the issue with PCLK2 is then. Thought the ETH is tied to PCLK2 domain... which it is not.

[bson]

Note that with RMII the ref clock is 50MHz, not 25MHz on the RMII interface.  Unless the 8742 has an internal PLL to double (I see it has a PLL) the 25MHz clock you might need to feed it a 50MHz clock.  This is not unusual with PHYs.

[peter-h]

It must have a doubler otherwise it would not work with a 25MHz xtal, which is shown.

I wonder if ST's ethernet code uses any of the timers on APB2/PCLK2 i.e. TIM1,8,9,10,11...

[bson]

Does the ethernet controller sit on APB2?  It might need a minimum clock to work.

[Yansi]

Ethernet peripheral seems to be AHB bus master - it even has it's own linked-list DMA.  (Dunno why I thought it was APB2...)

But... maybe part of the interface sits on APB2? Who knows...  Only ST knows and hard to get anything out of them.

[peter-h]

I have raised a ticket on the ST website.

This sort of thing could easily have remained undiscovered for years, because why should anybody run PCLK2 that slowly? The only reasons would be to get baud rates below 1200 (UART 1 or 6) or to make TIM1,8,9,10,11 etc run slowly. But only 2,5 are 32-bit and they are on PCLK1.

[Yansi]

Let's hope they will respond with anything useful.

Btw, what does one need baud below 1200?  (as was probably said, could be done by simple software bitbang) ... but what is the real application these days?

[Siwastaja]

Have you carefully verified that any part of the library ethernet code does not use any peripheral clocked by the APB2 domain? I mean, maybe they use something else than the ETH itself for auxiliary functions, for example some timer to trig something. That something would start operating differently if you just change the divider but don't regenerate the whole code with the correct clock information; or that something might have a bug or undocumented limitation ("feature") preventing operation with clock too slow.

[peter-h]

I asked the guy who implemented the ST ETH library on this target and he is pretty sure no TIMs are used, but it does hook up into the 1kHz tick. Obviously timers are needed for ethernet. I did a search of the whole code tree for TIMx and found nothing.

If you look at what APB2/PCLK2 drives, it's hard to imagine any of it could be used for ETH code. It is this lot




Regarding < 1200, this is indeed very rare these days. It had been used for slow links especially 20mA loop ("TTY") which believe it or not is still used. There is some amazingly old legacy stuff installed. But in my business I have other products which can do everything down to 30 baud so they can use those

Probably the main application for low baud rates (below 9600) is licence free radio modems. They are supposed to implement a hardware handshake, allowing the host bitrate to be say 9600, even if the link bitrate is something slower. There are also some silly low rates in remote metering, as in talking to electricity power meters.

At the other end of the scale there are some bizzare high rates e.g. 500kbps which were always a PITA to do because the divisors are small; I used to buy special xtals, and do it with a product I had which used an 85C30, with its own xtal, for two serial ports, and then anything was possible. The 32F4 does all these values really well, with error < 1%.

[ajb]

Ethernet itself doesn't require any timers (unless maybe you're using ingress/egress timestamping), but a lot of the IP stack above that does.  Depending on which parts of the stack you're using there are a handful of different task functions that need to be executed periodically to maintain ARP, DHCP, IGMP, TCP, etc.  I could imagine there being an issue with the way Cube handles those based on various clock configuration options. 

I assume Cube uses LWIP for its IP stack, in which case you could look for where it's timer functions are called from, for example `etharp_tmr` (since you're certainly going to be relying on ARP for anything IP).  That could provide a hint about how Cube handles periodic timing and will also give you a reasonable entry point to debugging the IP stack, as seeing which functions are executing will give you some idea of what's working and what isn't.

[peter-h]

Yes, LWIP.





How this hangs together, I don't know. It either hooks up the 1kHz tick (and there are two of those, one from SysTick and one from TIM6, and if you ask why there are two 1Khz ticks, yes it seems dumb, but search for FreeRTOS interrupt priority issues with Systick; it seems a well known issue and this is the approach they recommend) or there is some timer associated with the ETH hardware (like ETH has its own DMA controller). Or it is using one of the 32F4 timers in which case we may have found something, but why isn't that all over google?

LWIP is running as a task under FreeRTOS.