Loading...
 

System Workbench for STM32


STM32CubeMX LWIP not working

I have just started experimenting with ST products. I have a STM32F4 Discovery board. I bought a DP83848 PHY on Ebay and connected it to the Discovery board. I downloaded a hex file from here:http://blog.tkjelectronics.dk/2012/08/ethernet-on-stm32f4discovery-using-external-phy/Question

I am able to ping the board and access the web page with no issues.

I then used CubeMX to create a project with nothing but LWIP and two GPIO pins. I figured I would start out simple. The goal was to see if I could get LWIP working. I generated the code and imported it into System Workbench and used STLink to program the board.

I cannot ping the board (I enabled ICMP in CubeMX) and it does not make a DHCP request. I know the request is not being made because Wireshark never sees it.

Do I have to put anything in the main() while loop for lwip to work? Do I need to make any modifications to use the DP83848? I noticed in CubeMX that in the Ethernet Settings, it states LAN8742A for the PHY. Maybe this is my issue? If so, what modifications need to be made to tell CubeMX to use the DP83848?

I have been working on this for two days and making zero progress. I am using Windows XP and the latest versions of CubeMX and System Workbench

Hi rcbuck,

Check if the configuration of GPIO clocks are suitable.
The following 3 functions must be called for enabling ethernet clock:
__HAL_RCC_ETHMAC_CLK_ENABLE();
__HAL_RCC_ETHMACTX_CLK_ENABLE();
__HAL_RCC_ETHMACRX_CLK_ENABLE();

Furthermore, you may verify if the following GPIO pin are configured in Input mode
ETH_CRS, ETH_RX_CLK, ETH_COL, ETH_TX_CLK, ETH_RX_DV, ETH_RX_D0, ETH_RX_D1, ETH_RX_D2, ETH_RX_D3

Souleymane
AC6

Souleymane,

I confirmed all of the clocks are enabled and the GPIO pins are in Input mode. So ST32CubeMX generated that code properly.

If I modify the code to put in the MAC address that is used by the Hex code(that works) that I downloaded from the other website, Wireshark sees the board when it is started:
2 12.739183 0.0.0.0 255.255.255.255 DHCP 350 DHCP Discover - Transaction ID 0x5851f42d
3 12.740327 44:8a:5b:d3:4c:8b Broadcast ARP 60 Who has 172.16.1.109? Tell 172.16.1.1__

But the board doesn’t respond when the DHCP server asks “who has 172.16.1.109”. That is the IP address that the server assigns to the Hex file that does work. The DHCP entry is still in the lease table of the server, so the server knows that MAC address is supposed to be 172.16.1.109.

I’m sure the problem is related to me using the DP83848 instead of the LAN8742A PHY. But I don’t know what to modify to correct the problem.

Ray

Hello,
I am also facing similar issue, its been an year since your last post,. I hope you might have got it working. If so, can you pls post the solution that you had found. That would be useful for newbies of STM32F4-Discovery like myself.

Thanks in advance
Srinivasan


Srinivasan,

Yes, I got it working. I zipped up my code and you can download it from this link:

https://we.tl/t-6nBJYiIcJbQuestion

The name of the file is STM_Ethernet.zip. The link will remain valid for 7 days.

I presently do not have any STM development tools installed on my computer so I cannot be of further assistance. Hopefully my source code will help you to solve your problem.

Ray

Thanks a bunch.

I know its been a year after your initial post. However, do you remember what was the solution that you found? If so, i request you to post it here, so that it might be beneficial for others as well.

I am having the same issue.
Do you mind sharing the code once again?

-thanks


Srinivasan,

Unfortunately I do not remember what the solution was. After I got it working I put everything away and haven’t worked with the STM32 parts since then. I may do some work with STM parts in the future, but at this point I have moved onto other projects.

You can compare my code to your code and possibly find what makes your project work. As a first test, you could load my hex file that is in the Release folder into your board and see if it works.

Ray

Ray,
I could finally solve the issue with my TCP IP connection.

In the new version of STM32F4-Discovery which is now known as STM32F407G-DISC1, it looks like PHY chip seems to be LAN_8742A instead of LAN_8720 as it was in earlier version.

STMCube selection of LAN_8742A “did not” set the right set of External PHY configuration parameters. For example, when we select ETH in STMCUBE for STM32F4-discovery board selection, the default selection of PHY was LAN_8742A_PHY and with PHY address as 1 and other values set accordingly.

With those values, the issue found was the HAL_ETH_GetReceivedFrame function always failed to pass through the following statement if(((heth->RxDesc->Status & ETH_DMARXDESC_OWN) == (uint32_t)RESET)) returning HAL_ERROR everytime.

When I had changed this PHY_ADDRESS to 0 and few other PHY parameters in accordance with 8742A registers, we could get the TCP communication working..

Thanks for your support and taking your time in digging and sharing out your old code :-)

- Srinivasan

Srinivasan,
I’m also have the same problem as you did.
I have tried with PHY_ADDRESS 0, but no luck.
Can you please share what other PHY parameters you changed.

Thanks in advance
Mats


Srinivasan,
I’m also have the same problem as you did.
I have tried with PHY_ADDRESS 0, but no luck.
Can you please share what other PHY parameters you changed.

Thanks in advance
Mats