CubeMX : new USER CODE section needed in ethernetif.c

software · ‎2015-10-06

Posted on October 06, 2015 at 12:59

In source code generated by CubeMX would be useful to add a new USER CODE section in ethernetif.c in order to allow the user to change the MAC address.

For example:

.....

MACAddr[0] = 0x00;

MACAddr[1] = 0x80;

MACAddr[2] = 0xE1;

MACAddr[3] = 0x12;

MACAddr[4] = 0x34;

MACAddr[5] = 0x56;

heth.Init.MACAddr = &MACAddr[0];

heth.Init.RxMode = ETH_RXINTERRUPT_MODE;

heth.Init.ChecksumMode = ETH_CHECKSUM_BY_HARDWARE;

heth.Init.MediaInterface = ETH_MEDIA_INTERFACE_RMII;

/* USER CODE BEGIN x */

heth.Init.MACAddr = &MyMacAddr[0];

/* USER CODE END x */

hal_eth_init_status = HAL_ETH_Init(&heth);

.....

Regards

Mario

Nesrine M_O · ‎2015-10-22

Posted on October 22, 2015 at 17:57

Hi Mario,

Your request is reported to our team as an enhancement.

-Syrine-

stm32cube-t · ‎2015-11-16

Posted on November 16, 2015 at 11:28

Dear user,

Can you please give a rationale for this request since you can already use CubeMX user interface to specify your MAC address: open the Ethernet configuration window from CubeMX Configuration tab and change the default MAC address there.

Thanks for your feedback

andrew · ‎2015-11-17

Posted on November 17, 2015 at 12:13

I'm not the original poster but I consider the current Cube-generated Ethernet startup code to be next to useless for real world applications. W.r.t. MAC addresses, they are unique identifiers and must be different for every device on the network. Thus, any product that's actually doing Ethernet properly will have some kind of routine to load/create a unique MAC address when it powers up. The only thing the current Cube code can do is specify the same fixed ''default'' MAC for every device.

Of course, the programmer can jump through hoops to override the Cube-specified MAC in application code after the Ethernet startup is finished (or just disable Ethernet code generation in the Cube and do it all themselves), but then what's the point of having this Cube feature at all?

In my not-so-humble-opinion Cube code generation should allow for the user to insert their own MAC initialisation routine in low_level_init(), with the Cube MAC settings serving as the fall-back defaults should this user function fail (or none is specified).

stm32cube-t · ‎2015-11-26

Posted on November 26, 2015 at 15:56

Hello Andrew,

Thank you for the feedback. The original request for enhancement (introduce a user section for overwriting CubeMX default MAC address) has been logged.

We may later have the possibility to work out the MAC initialisation at a lower level and we keep your request in mind.

Best regards

matthewgkerr · ‎2016-04-21

Posted on April 21, 2016 at 14:25

I didn't realise that my chip (STM32F427) doesn't come with an assigned MAC Address. My understanding is that I should use the chips unique ID to create a unique locally administered MAC address. As others have highlighted, Cube doesn't seem to allow me to override the MAC address in the low_level_init() function. How would you suggest I go about overriding the value generated by Cube? Thanks.

stm32cube-t · ‎2016-10-06

Posted on October 06, 2016 at 16:34

Dear user,

Please check out STM32CubeMX 4.16 that introduces a new user section.

matthewgkerr · ‎2017-05-22

Posted on May 23, 2017 at 01:32

Hi Andrew,

I am having some issues with the Cube generated Ethernet startup code. I suspect I am discovering limitations in the generated code because of assumptions Cube is making of my hardware. I intend to raise a separate thread, but you made a point that I'd like you to elaborate on; '

I consider the current Cube-generated Ethernet startup code to be next to useless for real world applications'. In short, I would like to know if you (or anyone) actually uses the Cube generated code in real world applications?

For reference my setup is as follows:

MCU: STM32F427ZITx on a custom made PCB

Cube: STM32Cube FW_F4 V1.13.1

IDE: System Workbench V1.11.0.201610101240

PHY: MICREL KSZ8863MLL Integrated 3-Port 10/100 Managed Switch with 2 PHYs

Access to PHY control registers using MIIM

The issues I am faced with include:

1. Overriding the default MAC Address. I have resolved this issue. I'm using an EEPROM with a pre-programmed EUI-48 MAC address. I've added my own code to the new user block just after the MAC is defaulted. This works ok.

2. Cube assumes I have a single PHY. In my instance I need to configure 2 PHY. This involves modifying the HAL Ethernet driver. There are no user blocks so I'm unsure how to make the necessary changes.

3. Cube assumes I can perform certain functions on the PHY. For example, it assumes I can do a soft reset using register 0. This is not supported on my PHY. Performing a reset overrides the register defaults and put the PHY into an unexpected state.

4. Cube assumes I have access to the extended registers. The MIIM interface gives me limited access to registers. If I enable auto-negotiation, the last step of Ethernet initialisation in the HAL driver is to read back the Ethernet speed and duplex. Since I can't access the extended registers, the resulting values to the read call (which passes) is 0xFF. Further processing on the value read back results in unintended behavior.

I have already setup cube to minimise the code it generates; for example, it does not generate any tasks (other than default), semaphores, queues, etc. Base on your comment, I'm thinking I should also switch off the Ethernet initialisation code. I'll still use the Cube generated code as a starting point.

I'm very interested in hearing how other are using Cube in real world applications. Its been great getting me to this point, but i'm starting to find that i'm fighting the auto code generator. I'd love to hear your thoughts.

Regards, Matt.