Arm Mbed and Pelion Device Management support forum

EthernetInterface in mbed OS5 with lan8720

#1

Does OS 5 support lan8720 in EthernetInterface? If not, how can I include the driver?

#2

on which platform? In STM32 HAL, the LAN8720 is not handled correctly and I have opened already an issue in mbed-os for that.
The issue adresses the autonegotiation. When it can be set to fixed speed, you can do this in stm32f4_eth_conf.c as a workaround.

#3

Hi, on the LPCxpresso1769

#4

it should work on LPC1769. When you check the source for this emac, you’ll find the the phy id is read and the LAN8720 is handled, although the file suggests different.

#5

Thank you Johannes for sharing this info! I have spent a lot of time trying to fix that, however with no success.
I don’t know how to turn the autonegotiation off by modifying the ‘stm32f4_eth_conf.c’ file. But after changing the ‘mbed-os\features\netsocket\emac-drivers\TARGET_STM\stm32f4xx_emac.cpp’ file (Edit: ‘stm32f4xx_hal_eth.c’ was a mistake) as below the LAN8720 started to work with my STM32F407VET6 like a charm:

bool STM32_EMAC::low_level_init_successful()
#ifndef ETH_IP_VERSION_V2
{
    /* Init ETH */
    uint8_t MACAddr[6];
    EthHandle.Instance = ETH;
    //EthHandle.Init.AutoNegotiation = ETH_AUTONEGOTIATION_ENABLE;
    EthHandle.Init.AutoNegotiation = ETH_AUTONEGOTIATION_DISABLE;
    EthHandle.Init.Speed = ETH_SPEED_100M;
...
}

Best regards, Zoltan

#6

Hi Zoltan,
instead of modifying mbed-os source, you can use a custom target to change this setting. Fortunately, the function _eth_config_mac() is called after the general init and a custom init can overwrite the settings.
I’m using the same board as you and you can find a custom target definition in my github repo:

#7

That’s definitely a cleaner solution. :slight_smile: Thank you Johannes.

#8

Hi Zoltan, Johannes

I’m new to this… where exactly would I put these custom_targets in my project directory structure?

For some reason I’m finding the DP83848 a little flakey… sometimes failing to get a DHCP address and unreliable with ping replies, so keen to try the LAN8270

Cheers

PS: I’m using the STM32F407VET6 Blackboard

#9

You can put it anywhere in your project structure.
I‘m using the same board, so my repo should work for you also.

#10

Thanks Johannes,

Cool, I’ll simply put the custom_targets directory from your GitHub straight into my project “root” directory

Awesome

Cheers

#11

Johannes,

I also notice I can’t see any reference to the LAN8720 per se. Does that mean this will also disable AUTONEG and force 100M/Full when using the DP83848?

#12

yes, thats right. These lines could be removed when using a DP83848, but I think today its most common to use >= 100 MBit and it should be no problem.

#13

Thanks Again,

I had to move custom_targets.json to the root of the project as opposed to in the custom_targets directory because I could find the target.

Now, I can select STM32F407VE_BLACK as the target

Do a clean build, and it shows

| custom_targets/TARGET_STM | 1020(+1020) | 0(+0) | 0(+0) |

So I assume its found and compiled the new code properly.

However, I get the same result as prior to the customisations … the LAN8720 flashes at various rates with no pattern I can figure. DHCP server (Linux) doesn’t see any packets (according to tcpdump).

Am I missing anything? Any thing else I should try? What other information should I be giving you?

Thanks again for the help

#14

Ha, …it helps if I st-flash the correct binary!! Of course its in BUILD/STM32F407VE_BLACK/ARMC6 now :slight_smile:

Now I have another issue in that D2 just flashes 4 long then 4 (maybe 3) short… so off to look at that now, and hopefully after that I’ll change the DP83848 to LAN8720 and it will work

#15

The flashing pattern looks like mbed die, that’s more likely a wrong pin assignment to some peripherals. Can you connect a terminal program to the serial out? That will help you to catch the reason earlier.

#16

Thanks Johannes,

It turns out that if I use PA_9 & PA_10 for my serial connection, it works Ok. If I use PB_6 and PB_7, it works for the ARCH_MAX target, but not the STM32F407VET6.

Unfortunately, I’ve had daughter boards made using PB_6 & 7, so unless you can think of a software fix, I’ll have to use the ARCH_MAX and forgoe using LAN8720 - No big deal really

Cheers

#17

Hi Andy,

I’ve checked the schematics and the the pinnames.h. PB_6 and PB_7 is used for the nRF socket, and PB_6 is used for SPI_CS. This can be the only reason for a problem, I have no code in the custom_targets that use these pins.

#18

Hi Johannes,

Thanks for that. Maybe you can help me understand something… if the ARCH_MAX is supposed to be interchangeable with the F407VET6 (as per Zoltans page), why would the PinNames.h be different?

Cheers

#19

The programs will compile and run, but in detail there will be some pins different. LED, Button, serial port and others can be different and are set in the PinNames.h.