My setup is a WP7607, mangOH Green, TI WiFi WL1835MOD MirageRev3 IoT card in slot IOT0, Talon CAN IoT board in slot IOT1, and I’m using Legato R10.1.
I have added “GpioExpander” (from https://github.com/mangOH/GpioExpander) and “MuxControl” (from https://github.com/mangOH/MuxControl) to my Legato system as I need the “mux” command (available when installing the MuxControl app) to correctly start the Talon CAN IoT board. I have tried to replicate the “mux” behaviour by using the “gpioexp” Legato system command without success, so I gave up after several days of trying.
This is what I tried in the pass without success and finally end up using the “mux 5” and “mux 16” calls:
START_CAN script that is WORKING for me:
drv="can_iot.ko" kmod unload $drv # Output 1 to IoT slot 1 GPIO2 echo 7 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio7/direction echo 1 > /sys/class/gpio/gpio7/value # Route SPI to IoT slot 1 mux 5 ### gpioexp 1 1 enable ### gpioexp 1 15 output normal low ### gpioexp 1 14 output normal high # Reset IoT slot 1 mux 16 ### gpioexp 3 3 output normal high kmod load $drv ip link set can0 type can bitrate 125000 triple-sampling on ifconfig can0 up
The issue here is that I need the “mux” command which comes with the “MuxControl” app, so I also need the “GpioExpander” app, which I guess is conflicting the I2C access of the TIWIFI scripts available at: “/etc/init.d/tiwifi”.
The problem is that this behaviour is not deterministic, I would say that the tiwifi script to up/down the wlan0 interface works 95% of times, but not always.
After a clean reboot it usually works, showing the “mangOH green board” message, when ifup or ifdown wlan0 manually, and the 2 LEDs on the IoT0 board are switched ON of OFF correctly. This also works well then the “dataConnectionService” activates the WiFi interface when apply the following settings, and you initiate a connection with AirVantage or via MQTT, etc.:
$ config set dataConnectionService:/wifi/SSID "SSSSSSSSSSSS" string $ config set dataConnectionService:/wifi/passphrase "PPPPPPPPPPPPPPPP" string $ config set dataConnectionService:/wifi/interface wlan0 string $ config set dataConnectionService:/wifi/wpaSupplicantDriver wext string $ config set dataConnectionService:/wifi/secProtocol 3 int
BUT, after few minutes of using my app, where then the GpioExpanderServiceGreen service and RAW le_gpio APIs calls are used to manage some status LEDs, if there is a network disconnection (for any reason) and the “dataConnectionService” tries to start the TI WiFi again, it fails!.
After that point the tiwifi script doesn’t work correctly any more, no matter if you call ifdown wlan0 or ifup wlan0 manually, or whatever you try.
In particular the “gpioexp 3 4 output normal low” line fails accessing the I2C at address 0x70 (address of Expander3, port 4), and then the script enters in the “mangOH red board” side of the IF, failing to deselect the SDIO_SEL line and reset the IOT0_GPIO2 line…
If I stop my TUNIT app at that point and call the following, I could recover:
root@swi-mdm9x28-wp:~# ifdown wlan0 mangOH red board sh: write error: Operation not permitted ERR* failed to read i2c data ERR* I2c get addr 0x3e value failureERR* Set mode 0 failureERR* failed to read i2c data ERR* I2c get addr 0x3e value failureERR* Set polarity 0 failure ERR* failed to read i2c data ERR* I2c get addr 0x3e value failureERR* Set output 1 failure root@swi-mdm9x28-wp:~# ifup wlan0 mangOH green board root@swi-mdm9x28-wp:~# ifdown wlan0 mangOH green board
But with the TUNIT app running (using the GpioExpanderServiceGreen service) I guess there is no way to recover from this situation.
So, for me it would be desirable if I could avoid the use of the GpioExpanderServiceGreen and MuxControl at all by my application, that I guess they are creating the conflict after a while with the I2C ports (called from the “gpioexp” command called by the “tiwifi” script), but I didn’t find the way to avoid them safetly (as I need the mux command for starting the CAN IoT1 side).
Any recommendation to access the GpioExpander chips more safetly way from my application without using the 3rd-party “GpioExpander” and “MuxControl” apps which I guess they are conflicting the “gpioexp” system command (needed by the tiwifi driver)?.