STM32CubeMX and DHCP + UDP + NOSYS : How to configure ?

florent239955 · ‎2017-06-23

Posted on June 23, 2017 at 17:49

Hello,

I start a project with STM32CubeMX and a NUCLEO-F207ZG board. My goal is to have a TFTP client, but for now I'm stuck getting an IP address with DHCP. You can find my project attached.

In the lwip.c, I had to modify the MX_LWIP_Init.c file of the generated code (not in the user section), otherwise the code stops in

LWIP_ERROR('netif is not up, old style port?', netif_is_up(netif), return ERR_ARG;);

What is wrong with the STM cube configuration ?

Plus, I never go to the ethernet interrupt. How the ethernet reception is handled when there is no operating system ? (NO_SYS configuration)

Do you have a STM Cube project with DHCP and UDP (and

no TCP and no OS

) working ?

Regards,

Florent

--------

Here is a summary of my configuration in STM32CubeMx

In STM32CubeMx, I enabled LWIP. In the LWIP configuration,

-> General settings I enabled :

- LWIP_DHCP

- LWIP_UDP

The others are wether disabled or let to theirs default values.

-> In 'Key Options :

- OS not used

- LWIP timer enabled

- LWIP ARP Enabled

- LWIP_NETIF_STATUS_CALLBACK Enabled

The others are wether disabled or let to theirs default values.

florent239955 · ‎2017-06-26

Posted on June 26, 2017 at 11:58

Also, I noticed the function low_level_output in ethernetif.c return an error. I go into this ''if'' function after 4 retries from DHCP stack :

/* Is this buffer available? If not, goto error */

if((DmaTxDesc->Status & ETH_DMATXDESC_OWN) != (uint32_t)RESET)

{

errval = ERR_USE;

goto error;

}

But the error is not shown as udp_sendto_if_src doesn't take the returned status into account.

florent239955 · ‎2017-06-27

Posted on June 27, 2017 at 16:09

After setting Wireshark on the Ethernet I see the ethernet is not sending anything. I can have it working when I use the example project with tcp and freertos. But there are a lot of difference in configuration in the Ethernet register (heth).

Also, I noticed I never enter in the following condition which start the transmission :

/* When Tx Buffer unavailable flag is set: clear it and resume transmission */

if (((heth->Instance)->DMASR & ETH_DMASR_TBUS) != (uint32_t)RESET)

{

/* Clear TBUS ETHERNET DMA flag */

(heth->Instance)->DMASR = ETH_DMASR_TBUS;

/* Resume DMA transmission*/

(heth->Instance)->DMATPDR = 0U;

}

How the ETH_DMASR_TBUS bit is supposed to be lached ?

I'm currently using the latest STM32CubeMX version, which is 4.21.0 with LwIP v2.0.0 (the one which comes with STMCube)

Bino · ‎2017-07-05

Posted on July 05, 2017 at 15:58

For the first issue mentioned in

lwip.c, it will be fixed in next STM32CubeMX release 4.22 (see

https://community.st.com/0D50X00009Xke68SAB

)

florent239955 · ‎2017-07-10

Posted on July 10, 2017 at 16:03

I finnally found the problem by comparing the STMcube project example on STM32F207ZG_NUCLEO_144. The STM cubeMX doesn't generate the proper code for the Nucleo board. First, the physical address need to be 0 instead of 1, and it only work in RMII mode.

florent239955 · ‎2017-07-10

Posted on July 10, 2017 at 14:05

Hello Eric,

I can see there is a release note of the 4.22 version, but no update available. Can you tell me when the update will be available ?

Thank you,

Florent

Stefan Hennig · ‎2017-08-31

Posted on August 31, 2017 at 09:30

That was really a helpful observation! Changing the following line in the file

C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeMX\db\mcu\IP\ETH-ethermac110_v2_0_Cube_Modes.xml

(STM32CubeMX Version 4.21.0)

from

to

fixed my CubeMX installation so that I can have my NUCLEO_F207ZG talk to the Ethernet.

It is merely a hack, I have no understanding of the inner workings of CubeMX and I don't know what else this change might break, but as the 207 is the only Ethernet-enabled target I'm working with, I can say: 'Works for me'.

Maybe someone from STM should have a deeper look into this.