cancel
Showing results for 
Search instead for 
Did you mean: 

MX 5.4.0 Bug? MX_ETH_Init() assigning to uninitialized MACAddr pointer.

Harrold
Associate II

The generated code for MX_ETH_Init() has changed. Previous generated code:

  uint8_t MACAddr[6] ;
 
  heth.Instance = ETH;
  MACAddr[0] = 0x00;
  MACAddr[1] = 0x80;
  MACAddr[2] = 0xE1;
  MACAddr[3] = 0x00;
  MACAddr[4] = 0x00;
  MACAddr[5] = 0x00;
  heth.Init.MACAddr = &MACAddr[0];

New code generated by CubeMX 5.4.0:

  heth.Instance = ETH;
  heth.Init.MACAddr[0] =   0x00;
  heth.Init.MACAddr[1] =   0x80;
  heth.Init.MACAddr[2] =   0xE1;
  heth.Init.MACAddr[3] =   0x00;
  heth.Init.MACAddr[4] =   0x00;
  heth.Init.MACAddr[5] =   0x00;

But as far as I can see, MACADDR is still declared as a a uint8_t pointer (see stm32h7xx_hal_eth.c) and this pointer is never initialized.

So how can this work correctly?

Best regards,

Harrold

2 REPLIES 2
Piranha
Chief II

Can you post here the MAC address related generated code from low_level_init() in ethernetif.c?

The file ethernetif.c is only generated if Middleware LWIP is enabled. I'm using lwIP, but not the version and driver provided by CubeMX. So in my case this option is disabled. I enabled it for test and this is the code generated for low_level_init():

static void low_level_init(struct netif *netif)
{
  ...
  uint8_t MACAddr[6] ;
  heth.Instance = ETH;
  MACAddr[0] = 0x00;
  MACAddr[1] = 0x80;
  MACAddr[2] = 0xE1;
  MACAddr[3] = 0x00;
  MACAddr[4] = 0x00;
  MACAddr[5] = 0x00;
  heth.Init.MACAddr = &MACAddr[0];
  ...
}

So, this looks better. Well as long as MACAddr is only accessed within function scope, but I assume this is the case.