Closed
Description
- Type: Bug
- Priority: Blocker
Nucleo board reliable fails to get IPv6 address with LWIP6 enabled and using easy-connect.
10:45:36.473 | D1 <<< DutThread: [EasyConnect] IPv6 mode
10:45:36.474 | D1 <<< DutThread: [EasyConnect] Using Ethernet
10:45:53.207 | D1 <<< DutThread: [EasyConnect] Connection to Network Failed -3010!
10:45:53.208 | TC MainThread: Test Case fails because of: Failed to initialize connection
In the same network and with same application, K64F is able to connect with IPv6.
Activity
teetak01 commentedon Jun 2, 2017
@MarceloSalazar @bridadan @JanneKiiskila
0xc0170 commentedon Jun 2, 2017
cc @bcostm @adustm @LMESTM @jeromecoutant
JanneKiiskila commentedon Jun 2, 2017
Hei,
some extra info. Easy-connect, using tip of master, mbed OS 5.4.6 release.
You can use mbed-os-example-client for reproducing the issue.
https://github.com/ARMmbed/mbed-os-example-client
That already has the same things in place.
For the mbed_app.json, use this; https://github.com/ARMmbed/mbed-os-example-client/blob/master/configs/eth_v6.json
bridadan commentedon Jun 2, 2017
@teetak01 We have seen similar issues. Do you have multiple Nucleo F429ZI devices running network tests at once on the same network? All Nucleos 429ZI devices have the same MAC address, so it can fail to get an address this way.EDIT: I was totally wrong here, please ignore...
teetak01 commentedon Jun 5, 2017
@bridadan Yes we do, multiple devices. Should something like this be implemented for every board if the Hardware does not provide a unique one? #550
JanneKiiskila commentedon Jun 5, 2017
Yes, this is a serious problem and really, we should allow any board that doesn't support unique MAC address to be a reference for anything, really. It's not that a difficult thing to implement and one can use for example the unique chip id as the root for that.
jeromecoutant commentedon Jun 5, 2017
Hi
Note that ST doesn't provide any MAC address for any boards.
You have to code it.
JanneKiiskila commentedon Jun 5, 2017
Why? Code how, you should provide instructions.
SeppoTakalo commentedon Jun 5, 2017
I'm not sure that I'm looking at the correct location, but for me it looks like the functionality is already there:
https://github.com/ARMmbed/mbed-os/blob/master/features/FEATURE_LWIP/lwip-interface/lwip-eth/arch/TARGET_STM/stm32xx_emac.c#L480
https://github.com/ARMmbed/mbed-os/blob/master/features/FEATURE_LWIP/lwip-interface/lwip-eth/arch/TARGET_STM/stm32xx_emac.c#L498
Similar to NXP boards (K66F and K64F):
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/TARGET_FRDM/mbed_overrides.c#L45
Both seems to be using chip's unique ID reqisters to generate MAC addresses for testing purposes. Why this doesn't work, is beyond me...
jeromecoutant commentedon Jun 5, 2017
Yes, MAC coding is already there.
@bridadan
This is not normal.
Is it possible to display this MAC address in one test?
And ideally add this kind of code:
uint32_t ST_UID[3] = {0};
HAL_GetUID(ST_UID);
printf("Unique ID %08x %08x %08x\n", ST_UID[0], ST_UID[1], ST_UID[2]);
teetak01 commentedon Jun 5, 2017
It most likely is not MAC issue. I checked our logs from couple of last days:
So a specific board always has its own unique ID.
bridadan commentedon Jun 5, 2017
I ran some tests locally, turns out I was mistaken, thanks for not taking my word for it @teetak01!
Did this bug start appearing on 5.4.6? Was it ok with 5.4.5?
17 remaining items