Can't use TCPSockets over 6LoWPAN on others targets than K64F

[pmancele]

Description

• Type: Bug
• Priority: Blocker

---

Bug

Target
STM32L476

Toolchain:
GCC_ARM

mbed-cli version:
1.0.0

Hardware
Firefly 6LoWPAN shield + STM32L476ZG

Expected behavior
We are using the last version of mbed-os and tried to run a simple easy-connect example using 6LoWPAN. It worked well on the K64F, we can create a NetworkInterface, open a TCPSocket, connect to a website ("linkedin.com") and send a simple HTTP GET request.

But we did not achieve to make this work on any other MCU. Our main target is a STM32L476ZG.
With the same program, it connects sucessfully to the 6LoWPAN network, we can create a socket but we cant connect to any website as the DNS requests are not working.

Both the K64F and the STM32L476 have the same main:

#include "mbed.h"
#include "easy-connect.h"

nsapi_error_t ret;

TCPSocket socket;
NetworkInterface* LoWPAN;
int main()
{
   LoWPAN = easy_connect(true);
   ret = socket.open(LoWPAN);
   if (ret != NSAPI_ERROR_OK) {
   	printf("Error opening socket : %d", ret);
   }

   //ret = socket.connect("2620:109:c002::6cae:a0a",80);
   ret = socket.connect("linkedin.com",80);
   printf("nsapi_error : %d \n", ret);

   if (ret == 0) {
   	printf("It's OK ! \n");
   }
   else {
   	printf("Failed ! \n");
   }
}

K64F output:

[EasyConnect] Using Mesh
[EasyConnect] Connecting to Mesh..
[EasyConnect] Connected to Network successfully
[EasyConnect] IP address 2001:470:1f13:af3:fec2:3d00:4:583
[EasyConnect] MAC address fc:c2:3d:00:00:04:05:83
nsapi_error : 0
It's OK !

STM32 Output:

[EasyConnect] Using Mesh
[EasyConnect] Connecting to Mesh..
[EasyConnect] Connected to Network successfully
[EasyConnect] IP address 2001:470:1f13:af3:fec2:3d00:4:583
[EasyConnect] MAC address fc:c2:3d:00:00:04:05:83
nsapi_error : -3009
Failed

The -3009 error is a DNS error. We debugged the program and the DNS packet seems to be built correctly but never sent by the firefly 6LoWPAN shield.
err = socket.sendto(SocketAddress(dns_servers[i], 53), packet, DNS_BUFFER_SIZE); indicate us that the DNS packet has been transmitted (size 512), but it seems it hasnt as we cant see it with whireshark sniffing our IPv6 network.

If we use socket.connect() with an IPV6 address instead of a website address it is working both on K64F and STM32L476..

Finally we used mbed-trace both on the K64F and on the STM32L476. On the K64F there is no error reported by mbed trace during all the process, but on the STM32 we have this ERROR occuring several times:

[ERR ][mMCp]: MAC tx fail

[DBG ][rplc]: Triggering parent selection due to ETX change on fc:c2:3d:00:00:04:df:8b

[ERR ][6lAd]: MCPS Data fail by status 233

How to fix it ? Have you any idea ?

We tried to use the same 6LoWPAN shied on NUCLEO_F401RE and NUCLEO_L152RE to try DNS resolution but we cant get it working. EasyConnect return -3012 error which is NSAPI_ERROR_DEVICE_ERROR.

[0xc0170]

cc @kjbracey-arm @SeppoTakalo

[kjbracey]

The errors suggest the radio is having problems - apparently its transmissions are not being acknowledged, and from your Wireshark trace, it appears it's the transmit getting lost, not the acks.

It's possible that it's due to a lack of memory, given that it managed to get onto the network, and only failed DNS later. But the RAM in that device should be more than adequate for 6LoWPAN. Maybe check the mbed-mesh-api.heap-size config setting?

On some boards there can be pin conflicts between on-board peripherals and the Arduino riser - could be that too.

I don't believe we've tested that particular board+radio combo yet, but we do have a STM32L476 board to hand - we'll can try it.

[kjbracey]

Do the two Nucleo boards get anywhere at all? Is that an immediate connection failure?

@JanneKiiskila, is there any K64F-specific magic for 6LoWPAN in EasyConnect? Any reason why it shouldn't work with the Atmel radio module on a different board?

[JanneKiiskila]

jankii01@ubuntu:~/mbed$ cd mbed-cloud-client-example
jankii01@ubuntu:~/mbed/mbed-cloud-client-example$ cd easy-connect/
jankii01@ubuntu:~/mbed/mbed-cloud-client-example/easy-connect$ git grep -i K64F
jankii01@ubuntu:~/mbed/mbed-cloud-client-example/easy-connect$ 

There isn't a single reference to K64F in the easy-connect repo, so there's no magic there.
https://github.com/ARMmbed/easy-connect

[pmancele]

@kjbracey-arm Hello and thank you for your answers.

Yes we thought it was a memory issue so we tried to modify the heap size with mbed-mesh-api.heap-size without success. We tried 10000 and 30000 of heap-size. (Btw its working with 30k on K64F but not with 10k)
We will check again for a pin conflict or bad pins configurations but we already tried it..

If you have a STM32L476 we are definetly interested for you to test the combo !

@JanneKiiskila Yes easy-connect seems working fine on our STM32L476ZG, as we can connect and get an IPv6, but the issue occurs while using the TCPSockets and DNS resolutions.

Therefore, on NUCLEO boards we cant connect with easy-connect, and it returns the same error that is returned when the shield is not plugged on the boards. So on nucleo it seems to be a pin issue, but all the arduino pins are well declared on the PinNames.h file and seems to be compatibles with the required functionnalities.

[0xc0170]

cc @bcostm @adustm You might be interested in this one.

[kjbracey]

The pins may be well declared in PinNames.h, but there can easily be a clash with the debug UART or something else. Sometimes a link might need changing on the board to make the declared pins reach the Arduino header.

I know we've had a problem with at least one Nucleo board not being useable with that Atmel radio. I forget what the precise pin clash was, but it wasn't possible to usefully work around.

(Minimum useable mesh heap size for a 6LoWPAN router should be something in the range 15K-20K).

[adustm]

Hello, just for my understanding : @pmancele I remember you are not working on the NUCLEO_L476RG but on another platform based on STM32L476ZG. Correct ?

[pmancele]

@adustm Yes we designed our own plateform based on a STM32L476ZG that we ported to mbed-os.
We also get recently the new STM32L496ZG but we have the exactly same issue.

We also have official mbed boards like K64F, NUCLEO F401RE and L152RE but we successfully tried 6LoWPAN on K64F only (with the atmel firefly shield).

[adustm]

Hello @jeromecoutant
Could you try the main code mentionned above with NUCLEO_L476RG + firefly 6LowPan shield ?
cheers
Armelle

[pmancele]

@kjbracey-arm Here is what trace prints while trying to solve DNS:

[DBG ][nsif]: socket_sendto(socket=0x2000a814) sock_id=2, ret=512
[DBG ][nsif]: socket_recv(socket=0x2000a814) sock_id=2, ret=-3001
[ERR ][mMCp]: MAC tx fail
[DBG ][rplc]: Triggering parent selection due to ETX change on fc:c2:3d:00:00:04:df:8b
[ERR ][6lAd]: MCPS Data fail by status 233

This is when a UDPSocket is created to send and receive the DNS packet. (But as i explained we dont see this DNS packet with wireshark)
The -3001 error of the socket.receive is NSAPI_WOULD_BLOCK

[kjbracey]

It may be that the radio is unusually unreliable.

I note that the nsapi_dns.cpp implementation makes no attempt to retry - it does only one transmission, and gives up if it doesn't get a response in 5 seconds. So it would be more vulnerable to unreliability than the network bringup or the TCP connection itself.

[kjbracey]

(That was 1 UDP/IP transmission - the IEEE 802.15.4 MAC layer should perform about 5 transmissions itself though, looking for an ack)

[pmancele]

@jeromecoutant @adustm I just got a NUCLEO_L476RG and tried on it. First it was impossible to connect to the shield due to a pin conflict with the LED. (PA_5).
After solving the issue i got the same behavior as on our STM32L476ZG. DNS resolution failed and the trace is still printing a lots of errors:

[ERR ][mMCp]: MAC tx fail
[DBG ][rplc]: Triggering parent selection due to ETX change on fc:c2:3d:00:00:04:df:8b
[ERR ][6lAd]: MCPS Data fail by status 233