MAC Configuration STM32F4-Discovery board

[Raymond Buck]

I am using STM32CubeIDE to generate the code.

The only MAC address that will work is 02:00:00:00:01. This address shows up in

the LWIP\Target\ethernetif.c file in the static (void low_level_init(struct netif *netif) function. If I change it to anything else, the board no longer responds to ping.

In the /* USER CODE BEGIN MACADDRESS */ section I tried assigning another MAC address to the board but the board then doesn't respond to ping. If I assign the MAC address as 02:00:00:00:00:01 in this section it does respond to ping.

There is another reference to MAC addresses at Section 1: Ethernet peripheral configuration in the stm32fxx_hal_conf.h file. This is what displays:

#define MAC_ADDR0  2U

#define MAC_ADDR1  0U

#define MAC_ADDR2  0U

#define MAC_ADDR3  0U

#define MAC_ADDR4  0U

#define MAC_ADDR5  1U

However, I can change the #define statements to anything and is has no affect, the system still answers pings.

Exactly how do you set the MAC address for the board? Since the STM32 doesn't have a unique MAC address I will use a Microchip 11AA02E48 to obtain an address.

[Raymond Buck]

Further investigation reveals the board will also work with a MAC address of 03:00:00:00:00:01. And reading on Wikipedia indicates that these 2 MAC addresses are locally administered addresses instead of universally administered.

So the question is "Has ST somehow hardcoded something on the Discovery board that prevents you from assigning a MAC address to the board?" I have tried everything I can think of for the last 8 hours to assign another MAC address to the board and can't find a way to do it.

I wanted to test 2 Discovery boards for passing Ethernet packets back and forth between the boards before designing a custom board for my application. My concern now is whether I will be able to assign MAC addresses to the STM32F407 on my custom boards.

Or is the MAC address assigning problem really a STM32CubeIDE bug? Does anyone have any suggestions? I am totally stumped at this point.

[Piranha]

For a typical configuration to work, eventually the same MAC address must be in two places - in the respective ETH MAC peripheral registers and in netif->hwaddr of lwIP. If that's the case and the address is not conflicting with any other device in your local network, then you have some other problem. But I can assure you that the problem is not in MCU internal hardware or lwIP, but only in ST's software - HAL/CubeMX code. You can see my Ethernet demo to see that I know what I'm talking about. And even more important - see my topic of network issues.

> really a STM32CubeIDE bug?

HAL/CubeMX code is non-working bloatware. It's so broken, that "workarounds" require more work than a complete rewrite from scratch. OK, for F4 series it's not so tragic - it can even be made somewhat working, but it's still buggy and incomplete. For a serious projects in the long term only one thing can be recommended - to drop the HAL/CubeMX code completely and use CubeMX only as a pin selection helper tool, when designing PCB.

[Raymond Buck]

Piranha, thank you for the reply. I had previously read your two references while trying to solve this problem.

As far as I can tell, the MAC information only shows up in the ethernetif.c file that is in the LWIP->Target directory. In that directory there is a function named

static void low_level_init(struct netif *netif). If I use CubeMX to assign a MAC address of 02:00:00:00:00:01, the code that gets generated is this:

static void low_level_init(struct netif *netif)
{ 
  uint32_t regvalue = 0;
  HAL_StatusTypeDef hal_eth_init_status;
  
/* Init ETH */
 
  uint8_t MACAddr[6] ;
  heth.Instance = ETH;
  heth.Init.AutoNegotiation = ETH_AUTONEGOTIATION_ENABLE;
  heth.Init.PhyAddress = DP83848_PHY_ADDRESS;
  MACAddr[0] = 0x02;
  MACAddr[1] = 0x00;
  MACAddr[2] = 0x00;
  MACAddr[3] = 0x00;
  MACAddr[4] = 0x00;
  MACAddr[5] = 0x01;
  heth.Init.MACAddr = &MACAddr[0];
  heth.Init.RxMode = ETH_RXPOLLING_MODE;
  heth.Init.ChecksumMode = ETH_CHECKSUM_BY_HARDWARE;
  heth.Init.MediaInterface = ETH_MEDIA_INTERFACE_RMII;

further down in that function this appears:

/* set MAC hardware address */
  netif->hwaddr[0] =  heth.Init.MACAddr[0];
  netif->hwaddr[1] =  heth.Init.MACAddr[1];
  netif->hwaddr[2] =  heth.Init.MACAddr[2];
  netif->hwaddr[3] =  heth.Init.MACAddr[3];
  netif->hwaddr[4] =  heth.Init.MACAddr[4];
  netif->hwaddr[5] =  heth.Init.MACAddr[5];

In the stm32f4xx_hal_conf.h file there is this reference to the MAC address:

#define MAC_ADDR0   2U
#define MAC_ADDR1   0U
#define MAC_ADDR2   0U
#define MAC_ADDR3   0U
#define MAC_ADDR4   0U
#define MAC_ADDR5   0U

but I don't know what they are doing here. I can ping the board with the code shown above.

If I then run CubeMX again and change the MAC address to 00:80:E1:00:00:01 and re-generate the code, I can no longer ping the board.

The static void low_level_init(struct netif *netif) function does show the new MAC address but the #define statements in stm32f4xx_hal_conf.h file do not change.

If I use CubeMX to change the MAC back to 02:00:00:00:00:01 the board then once again responds to pings.

The only place I can find anything about the ETH MAC peripheral resgisters is in the stm32f4xx_hal_conf.h file. Is there somewhere else that the MAC information is stored? It doesn't matter what MAC address I try to use, the only one that works is 02:00:00:00:00:01.

"For a serious projects in the long term only one thing can be recommended - to drop the HAL/CubeMX code completely and use CubeMX only as a pin selection helper tool, when designing PCB." -- That would mean writing all of the STM32 Ethernet code from scratch which could take years. Am I missing something?

EDIT: Piranha, you were right, it was another problem.

I am using a Linux server as my DHCP server. I cleared the DHCP leases from the server and now the STM32 Discovery board will work with a different MAC address. I am not sure what is going on with the DHCP daemon. I also found out the #defines in stm32f4xx_hal_conf.h are not needed. I can comment them out and the board still works. Again, I don't have any idea what ST is doing with those.