Has anyone experimented/used the Ethernet MAC built into the STM32F407?

I have a use for ethernet directly on an MCU (not the wiznet boards or enc28j60). The stm32f407 has this, but I only have the f4 discovery board on hand. I’ve seen people wire up the PHY DP83848 breakout as a mess of wires like this:

IMG_20160521_210009-20p.jpg (155.56 KiB) Viewed 1384 times

Update: I moved the wiring for the MDIO bus (imagine a ~2.5MHz i2c bus to get/set the PHY’s registers) and now my link is stable! But my data isn’t reliable. I suspect the 50MHz clock is getting everywhere due to the mess-of-wires. I see it on the MDIO bus even, which it should not be there.

I don’t think anyone has looked into this.

Everyone uses external interfaces (as they generally use the F103 which doesn’t have on board Ethernet)

RogerClark wrote:I don’t think anyone has looked into this.

Everyone uses external interfaces (as they generally use the F103 which doesn’t have on board Ethernet)

Dan

Cool…

For net connections, I suspect a lot of people just use Wifi.

I normally connect a ESP8266 to the F103 via HW Serial 1, and write custom code on the ESP8266 to send or receive whatever data I need.
(However this only works if you are sending small amounts of data)

I recall that after years, mbed never did have a viable stable version of lwip for the ‘1768 chip’s on-board ethernet MAC. Among the other issues with on-board layer 1.5, 2 and 3 Etherent and TCP/IP, are the dependence on threads or a polling loop.

For wired ethernet, it is orders of magnitude simpler to us off-boarded TCP/IP/Mac layer as in the Wiznet chips/boards.

I suspect that ST’s Std Peripheral Lib and HAL lib for TCP/IP with onboard MAC uses something like lwip and it’s “as-is” in reliability. I will say that ST’s adaptation of FATFS from ChanFS is very reliable. Don’t know about their TCP/IP stack though.

WiFi seems to be the thing now, for embedded.

stevech wrote:
<…>
WiFi seems to be the thing now, for embedded.

stevech wrote:I recall that after years, mbed never did have a viable stable version of lwip for the ‘1768 chip’s on-board ethernet MAC. Among the other issues with on-board layer 1.5, 2 and 3 Etherent and TCP/IP, are the dependence on threads or a polling loop.

For wired ethernet, it is orders of magnitude simpler to us off-boarded TCP/IP/Mac layer as in the Wiznet chips/boards.

I suspect that ST’s Std Peripheral Lib and HAL lib for TCP/IP with onboard MAC uses something like lwip and it’s “as-is” in reliability. I will say that ST’s adaptation of FATFS from ChanFS is very reliable. Don’t know about their TCP/IP stack though.

Hi! I have watched Roger’s video on yourtube “https://www.youtube.com/watch?v=-zwGnytGT8M” he said that “The board is connected via a USB to serial adapter, which is connected to Serial1 on the STM32.” by that what do he mean? Do he mean that he is using a simple USB cable to connect STM32 with PC or using some hardware device to connect STM32 with a PC.

As I’m using STM32 Discovery F407 Discovery with Arduino 1.5.8 with windows 8 and while uploading the same I2C program it is showing me an error:

“Cannot run program “{runtime.tools.arm-none-eabi-gcc.path}/bin/arm-none-eabi-g++”: CreateProcess error=2, The system cannot find the file specified”.

Could you please let me know the reason behind this issue as I really need it urgently.

Waiting for your kind response.

Regards,
Touseef

That is an old video

Use version IDE Version 1.6.9 as 1.5.8 is no longer supported

I tried it with 1.6.9 and here’s the error:

C:\Arduino\arduino-builder -dump-prefs -logger=machine -hardware “C:\Arduino\hardware” -hardware “C:\Users\Touseef\AppData\Local\Arduino15\packages” -tools “C:\Arduino\tools-builder” -tools “C:\Arduino\hardware\tools\avr” -tools “C:\Users\Touseef\AppData\Local\Arduino15\packages” -built-in-libraries “C:\Arduino\libraries” -libraries “C:\Users\Touseef\Documents\Arduino\libraries” -fqbn=Arduino_STM32:STM32F4:discovery_f407 -ide-version=10609 -build-path “C:\Users\Touseef\AppData\Local\Temp\build4dc6be27fba7112c8a9cc5df7190763e.tmp” -warnings=none -prefs=build.warn_data_percentage=75 -verbose “C:\Users\Touseef\AppData\Local\Temp\arduino_modified_sketch_658121\sketch_jun04a.ino”
C:\Arduino\arduino-builder -compile -logger=machine -hardware “C:\Arduino\hardware” -hardware “C:\Users\Touseef\AppData\Local\Arduino15\packages” -tools “C:\Arduino\tools-builder” -tools “C:\Arduino\hardware\tools\avr” -tools “C:\Users\Touseef\AppData\Local\Arduino15\packages” -built-in-libraries “C:\Arduino\libraries” -libraries “C:\Users\Touseef\Documents\Arduino\libraries” -fqbn=Arduino_STM32:STM32F4:discovery_f407 -ide-version=10609 -build-path “C:\Users\Touseef\AppData\Local\Temp\build4dc6be27fba7112c8a9cc5df7190763e.tmp” -warnings=none -prefs=build.warn_data_percentage=75 -verbose “C:\Users\Touseef\AppData\Local\Temp\arduino_modified_sketch_658121\sketch_jun04a.ino”
WARNING: Category ” in library RTClock is not valid. Setting to ‘Uncategorized’
WARNING: Category ” in library SPI is not valid. Setting to ‘Uncategorized’
WARNING: Category ” in library UIPEthernet is not valid. Setting to ‘Uncategorized’
Warning: platform.txt from core ‘STM32F4 boards’ contains deprecated recipe.ar.pattern=”{compiler.path}{compiler.ar.cmd}” {compiler.ar.flags} {compiler.ar.extra_flags} “{build.path}/{archive_file}” “{object_file}”, automatically converted to recipe.ar.pattern=”{compiler.path}{compiler.ar.cmd}” {compiler.ar.flags} {compiler.ar.extra_flags} “{archive_file_path}” “{object_file}”. Consider upgrading this core.
“C:\Users\Touseef\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-g++” -c -g -Os -w -ffunction-sections -fdata-sections -nostdlib –param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_discovery_f407 -DVECT_TAB_BASE -DERROR_LED_PORT=GPIOD -DERROR_LED_PIN=14 -w -x c++ -E -CC -mcpu=cortex-m4 -DF_CPU=168000000L -DARDUINO=10609 -DARDUINO_STM32DiscoveryF407 -DARDUINO_ARCH_STM32F4 -DMCU_STM32F406VG -mthumb -DSTM32_HIGH_DENSITY -DSTM32F2 -DSTM32F4 -DBOARD_discovery_f4 -mthumb -D__STM32F4__ “-IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple” -IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple/usbF4 -IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple/usbF4/STM32_USB_Device_Library/Core/inc -IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple/usbF4/STM32_USB_Device_Library/Class/cdc/inc -IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple/usbF4/STM32_USB_OTG_Driver/inc -IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple/usbF4/VCP “-IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple” “-IC:\Arduino\hardware\Arduino_STM32\STM32F4\variants\discovery_f407” “C:\Users\Touseef\AppData\Local\Temp\build4dc6be27fba7112c8a9cc5df7190763e.tmp\sketch\sketch_jun04a.ino.cpp” -o “nul”
“C:\Users\Touseef\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-g++” -c -g -Os -w -ffunction-sections -fdata-sections -nostdlib –param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_discovery_f407 -DVECT_TAB_BASE -DERROR_LED_PORT=GPIOD -DERROR_LED_PIN=14 -w -x c++ -E -CC -mcpu=cortex-m4 -DF_CPU=168000000L -DARDUINO=10609 -DARDUINO_STM32DiscoveryF407 -DARDUINO_ARCH_STM32F4 -DMCU_STM32F406VG -mthumb -DSTM32_HIGH_DENSITY -DSTM32F2 -DSTM32F4 -DBOARD_discovery_f4 -mthumb -D__STM32F4__ “-IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple” -IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple/usbF4 -IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple/usbF4/STM32_USB_Device_Library/Core/inc -IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple/usbF4/STM32_USB_Device_Library/Class/cdc/inc -IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple/usbF4/STM32_USB_OTG_Driver/inc -IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple/usbF4/VCP “-IC:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple” “-IC:\Arduino\hardware\Arduino_STM32\STM32F4\variants\discovery_f407” “C:\Users\Touseef\AppData\Local\Temp\build4dc6be27fba7112c8a9cc5df7190763e.tmp\sketch\sketch_jun04a.ino.cpp” -o “C:\Users\Touseef\AppData\Local\Temp\build4dc6be27fba7112c8a9cc5df7190763e.tmp\preproc\ctags_target_for_gcc_minus_e.cpp”
C:\Users\Touseef\AppData\Local\Temp\arduino_modified_sketch_658121\sketch_jun04a.ino:30:18: fatal error: Wire.h: No such file or directory

#include <Wire.h>

^

compilation terminated.

exit status 1
Error compiling for board STM32 Discovery F407.

I tried 1.6.9 but it’s uploading yet and shows a different kind of error:
#include <Wire.h>

^

compilation terminated.

exit status 1
Error compiling for board STM32 Discovery F407.

Partially my fault : I’ve manually copied the Wire library from F1 into F4 more than a year ago, but I’ve never committed it.

martinayotte wrote:Partially my fault : I’ve manually copied the Wire library from F1 into F4 more than a year ago, but I’ve never committed it.

The Wire library been copied, it has nothing to do with the Serial COM1.
SerialMonitor could not open port for some other reason.
Are you sure it is on COM1 ? Did you look at the DeviceManager ?

I have develpoed my eth stack from ARP up to MQTT on websocket with my STM32F407 devboard (I bought it from waveshare)
I have used RMII config (this is the devboard hw configuration)
With my eth stack I have developed a eth thermostat and seems It is working properly.

I have used the same PHY board I think the problem may be the long wires.
Do you have used the ST library firmware for MAC-PHY connection ?

The main problem with ethernet interface is the MAC address. For hobbistic project you can use a random unique number but for commercial product i think you must buy a OUI.

accacca wrote:I have develpoed my eth stack from ARP up to MQTT on websocket with my STM32F407 devboard (I bought it from waveshare)
I have used RMII config (this is the devboard hw configuration)
With my eth stack I have developed a eth thermostat and seems It is working properly.
I have used the same PHY board

I have two prblems
…Writing in english…
and the time passed since I wrote this driver….but I try help you

I will study the stm32f4xx_hal_eth.c

In my ethernet NIC task I have these states:
my task poll every 100ms the PHY status
You can do the same check? if the low level link is stable the problem is not hw.

(the code contain also my vars and my defs I think is not very clear to read but ask for help)


case ETH_NIC_LINK6:
if (!ETH_PHY_READ_REGISTER(ETH_PHY_ADDRESS, PHY_SR)) break ;
eth_nic.state = ETH_NIC_LINK7 ;
break ;

case ETH_NIC_LINK7:
eth_nic.state = ETH_NIC_LINK8 ;

if ((ETH->MACMIIDR & PHY_SR_LINKED_STATUS))
{
if (eth_nic.Flinked == 0)
{
eth_nic.mac_cfg.FullDuplex = (ETH->MACMIIDR & PHY_SR_DUPLEX_STATUS) ? 1 : 0 ;
eth_nic.mac_cfg.Speed100M = (ETH->MACMIIDR & PHY_SR_SPEED_STATUS ) ? 0 : 1 ;

ETH_MAC_Config(&eth_nic.mac_cfg) ;

ETH_DMA_Init() ;
ETH_MAC_enable() ;

eth_nic.Flinked = 1 ;
}
// else nothing to do
}
else
{
if (eth_nic.Flinked == 1)
{
eth_nic.Flinked = 0 ;
eth_nic.state = ETH_NIC_LINK0;
}
}
break ;

case ETH_NIC_LINK8:
if (synctimer_100MS_timeout())
{
eth_nic.state = eth_nic.Flinked ? ETH_NIC_LINK6 : ETH_NIC_LINK4 ;
}


martinayotte wrote:The Wire library been copied, it has nothing to do with the Serial COM1.
SerialMonitor could not open port for some other reason.
Are you sure it is on COM1 ? Did you look at the DeviceManager ?

accacca wrote:I have two prblems
…Writing in english…
and the time passed since I wrote this driver….but I try help you

I’m unable to understand why it’s not showing me any port option

Under Win10 I use the following trick in device manager:
– disable device
– enable device
By re-scanning the hardware the USB port will be enumerated as COM port.