Ethernet differences between STM32F767VGT and STM32F765VGT?

[Oliver Sedlacek]

Do to the ongoing lack of availability of the STM32F767VGT (and no news on when this will be resolved), we've dropped an STM32F765VGT on to the PCB as a possible substitute. STMCube32MX says I can map the pins the same way, but the Ethernet doesn't work.

Any clues as to where I need to start looking? I think there's a problem with the Phy MDI interface as all the Phy registers read FF.

[SofLit]

Hello,

In term of ETH peripheral there is no difference from SoC implementation point of view. If your project is already running well on the STM32F767VGT device it should work also on STM32F765VGT.

All other differences on the two devices are not related to the ETH.

Please refer to the datasheet (link) / Table 2.

[waclawek.jan]

> I think there's a problem with the Phy MDI interface as all the Phy registers read FF.

Observe the MDI signals. You can also try to bit-bang it, it's a relatively simple protocol.

(Read: I suspect you have a bad connection between mcu and PHY as in bad solder joint, or an inoperable PHY maybe due to clock problem).

JW

[Oliver Sedlacek]

So the MDC is approx 4MHz on the working 767 and approx 8MHz on the non-working 765. That looks like a clue to me! In ETH_MACIIAR the CR bit fields are set to 4 (div 102) and 0 (div 42) respectively. Why the difference is now the question.

Time to delve into the HAL :(

[Oliver Sedlacek]

So the Ethernet DMA never comes out of reset on the 765. Having failed to do this reset, the HAL code bypasses the setting of the MDC, so the wrong MDC frequency is a symptom, not a cause. The HAL code is:

/* Ethernet Software reset */
  /* Set the SWR bit: resets all MAC subsystem internal registers and logic */
  /* After reset all the registers holds their respective reset values */
  (heth->Instance)->DMABMR |= ETH_DMABMR_SR;
  
  /* Get tick */
  tickstart = HAL_GetTick();
  
  /* Wait for software reset */
  while (((heth->Instance)->DMABMR & ETH_DMABMR_SR) != (uint32_t)RESET)
  {
    /* Check for the Timeout */
    if((HAL_GetTick() - tickstart ) > ETH_TIMEOUT_SWRESET)
    {     
      heth->State= HAL_ETH_STATE_TIMEOUT;
  
      /* Process Unlocked */
      __HAL_UNLOCK(heth);
    
      /* Note: The SWR is not performed if the ETH_RX_CLK or the ETH_TX_CLK are  
         not available, please check your external PHY or the IO configuration */
               
      return HAL_TIMEOUT;
    }
  }

On the 767 it comes straight out of reset. Can't find any differences in the reference manual to explain this. The comments are interesting, so I'll look at the Phy.

[waclawek.jan · Accepted solution]

> Can't find any differences in the reference manual

You won't find any. The two chips are identical, literally, they are the same piece of silicon (bar different die revision).

Check the ETH clock - physically, measuring directly on pins (again, suspect bad solder joints).

JW

[Oliver Sedlacek]

Hot off the press progress, the Phy wasn't producing RefClk because the Phy LED2 configuration pin wasn't being pulled down. Fixing this has moved the problem along because it seems the link comes up, but I still can't ping the board.

[Oliver Sedlacek]

So the Ethernet did spring into life! I forgot that I'd seen this before, with ping just not working for a few minutes.