TCP transactions fail when GPIO2 activated (MT7697 WiFi)

mangOH Red
1

Hi All,

There is a peculiar behavior observed in our application.
I have been investigating the WiFi initiation and connectivity issues during bootup with a legato app initializing WLAN1.
Issue under discussion is at

Once the Application starts, connectivity to external IPs is lost (ex. a ping command to GoogleDNS, etc). Our app is expected to send a file to an external host.

After a step-by-step review and troubleshooting, found that a call made to reset UC IOT card through GPIO2, is the culprit. After the call, all TCP transactions from the mangOH red are stopped. And it’s not recovered until reboot.

Did anyone come across similar issues? Is there an explanation and possible solution to this?

Thanks in advance.
Madan

2

Hi @Madan,

That’s very odd.

I’ve just had a quick look through the 'Red schematics, and it appears that the GPIO2 line is only (after going an and gate) only attached to the IoT connector nRESET pin.

Does the same happen if you only use the cellular connection (i.e. don’t configure the WiFi)?

ciao, Dave

3

Hi @Madan
Just off the top of my head it sounds like the application is in a sandbox and you will need to unsandbox the app to allow network connectivity: https://docs.legato.io/latest/conceptsSecuritySandboxOverview.html

If you have tried that and things still don’t work can you attach some of your network parameters from the script and then network parameters from a ssh shell to compare. Either run old route(1), ifconfig(1), … or you could use iproute2 commands like “ip r”, “ip l” (note you can print the policy table from iproute2 which may help you further). See if all of that makes sense and are the same.

If you still can get things to work, can you elaborate on “step-by-step review and troubleshooting” to come to the conclusion that a reset of UC IOT card through GPIO2 is the culprit. Being new to this forum (just joined), btw, what does UC stand for? Regards,

Zahid

4

Hiya @Zahid ,

Good point - I forgot about that.

If you don’t run your app un-sandboxed, your app cannot get access to the current version of /etc/resolv.conf (the DNS resolver setup). This becomes an issue as various network connection events (such as the le_data_Connection service) write to /etc/resolv.conf when the network state changes.

BTW, I reported this as an issue maybe 2 years ago…

ciao, Dave

5

Hi @Zahid, @davidc,

Thanks for your inputs.

I did think of some permission issues as the application was failing to send data, but ping in the initialization app worked. so I made the Initialization app un-sandboxed earlier. But it didn’t solve. As it was not only application losing the TCP functionality on WiFi, but also the shell (ping), so i didn’t take it forward to make my app un-sandboxed.

Regarding the root-cause steps, it was back-track the changes made to the application one by one. it got me to the line of code where GPIO2 being activated. UC IOT card is - Universal Converter IoT card from Energiya.

However, I tried now building the app as un-sandboxed. Even then, it failed with GPIO2 calls. When I removed it (GPIO2 calls), it works again.

// le_gpioPin2_TryConnectService();
// le_gpioPin2_EnablePullUp();
// le_gpioPin2_SetPushPullOutput(LE_GPIOPIN2_ACTIVE_HIGH, true);
// le_gpioPin2_DisconnectService();

I am not sure why this is happening.

Regards
Madan

6

Hi @Madan,

Just a thought … have you tried running your code without the IoT card in the slot? Maybe comment out the code that accesses the card, but leave in the code that tickles the GPIO.

I’m wondering if there is some interference happening between one of the interfaces on the IoT slot when the card is enabled and the interface used to communicate with the WiFi chip?

ciao, Dave

7

@davidc,

I think your suspicion is right.

  1. GPIO code uncommented. & rest of the calls to IOT are commented.
  2. IoT not inserted.
  3. Ping success, after the app started.
  4. Now, insert the card and power it.
  5. Ping unsuccessful, after the app started.

And one more observation (if it was not mentioned earlier)…
The device crashes after some time , when this case (ping fail) is seen. And when ping is successful, it doesn’t crash. I sent log files to Ashish and David F.

And to reiterate, without the GPIO2 call, other IoT ADC calls are NOT hindering the PING/TCP functionality. So I dont think the rest of the UC IoT calls can be eliminated from the issue.

Will share this info with Energiya Team as well,

Regards
Madan

8

Correction…

I meant rest of the call are out of the scope for the issue.