USB driver failing to find or power USBs


#1

Hello,

We have purchased ~10 mangoh reds for building IoT devices, and have been trying to enable a wifi access point. We tried to use the out of the box wifi, but it seems like development is not yet complete on those drivers: MangOH Red , wifi client start failed and the executable fails:

root@swi-mdm9x15:~# wifi client start
ERROR: le_wifiClient_Start returns ERROR.

To work around this, we purchased some 300M Wireless USB adapters, but whenever we run lsusb, we get an error. We have tried lsub with at least 10 types of USBs, ranging from smart card readers to storage, all receive this error:

root@swi-mdm9x15:~# lsusb
unable to initialize libusb: -99

Those USBs with LEDs that light up when plugged into a traditional computer do not light up when connected to the mangoh. We checked the USB pins and they are receiving power. It seems as if the USB driver is not working.

Unfortunately, unlike this post here: Lsusb does not work on a brand-new mangOH Red from a box our device does not start working after plugging in any special USB dongles.

Is this a known issue? Are there any other mangoh red owner’s who have experienced this problem?

Thank you for the help in advance!


#2

We will be releasing tutorial for WP76 and mangOH Red WiFi in mid-Feb.
In meantime you can use the IoT WiFi card that has built in support .
https://www.digikey.com/product-detail/en/talon-communications-inc/MIRAGE-PIFA/1788-1008-ND/7243279


#3

Asyal,

Thank you for that suggestion. We have ordered that, but we still would like to use our USB slot for other purposes. Is the lsusb issue a known issue or is there a solution you have come across?


#4

The lsusb problem is known. I am not sure why it hasn’t been resolved yet as it has existed for a long time.


#5

@asyal and @dfrey,

I went with your suggestion and purchased the IoT WiFi Card. Unfortunately, the board is failing to start and the LED is not powering on:

The issue is that the wifi board is simply not being found/powered. This is happening on all of our Reds. It DOES work on the Green. But it is very important that it works on the red. What could be the issue?

root@swi-mdm9x15:~# wifi client start
successfully called start. //Not actually starting
root@swi-mdm9x15:~# app status
[running] atClient
[running] atServer
[running] audioService
[running] avcService
[running] cellNetService
[running] dataConnectionService
[running] fwupdateService
[running] gpioService
[running] modemService
[running] positioningService
[running] powerMgr
[running] secStore
[stopped] smsInboxService
[stopped] spiService
[stopped] tools
[stopped] voiceCallService
[stopped] wifi . //Not running
[stopped] wifiApTest
[stopped] wifiClientTest
[running] wifiService
[stopped] wifiWebAp

According the wifi driver tutorial here: http://mangoh.io/wifi-expansion-card states “The Wi-Fi LED on the Wi-Fi expansion card turns ON” - This is not the case. There is no indication that the command worked, as the app is off and the light is not on.

Passing this, I perform the next step “wifi client scan” and get the following result:

starting scan.
DEBUG: le_wifiClient_GetFirstAccessPoint ERROR

Here are the logs for both commands repeated one after the other:

wifi client start:

Jan 2 16:49:10 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | LE_FILENAME ExtractFileDescriptor() 33 | Received fd (10).
Jan 2 16:49:10 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | LE_FILENAME ExtractFileDescriptor() 33 | Received fd (11).
Jan 2 16:49:10 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=main | le_wifiClient.c le_wifiClient_Start() 560 | Client starts
Jan 2 16:49:10 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | le_wifiClient_server.c Handle_le_wifiClient_Start() 557 | Sending response to client session 0x27d3c : 4 bytes sent
Jan 2 16:49:11 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=main | le_wifiClient.c CloseSessionEventHandler() 414 | sessionRef 0x27d3c GetFirstSessionRef (nil)
Jan 2 16:49:11 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | le_wifiClient_server.c CleanupClientData() 195 | Client 0x27d3c is closed !!!
Jan 2 16:49:11 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | le_wifiAp_server.c CleanupClientData() 195 | Client 0x27cac is closed !!!

wifi client scan:

Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | LE_FILENAME ExtractFileDescriptor() 33 | Received fd (10).
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | LE_FILENAME ExtractFileDescriptor() 33 | Received fd (11).
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=main | le_wifiClient.c le_wifiClient_AddNewEventHandler() 508 | Add new event handler
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | le_wifiClient_server.c Handle_le_wifiClient_AddNewEventHandler() 461 | Sending response to client session 0x27cac : 4 bytes sent
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=main | le_wifiClient.c IsScanRunning() 430 | IsScanRunning .0
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=main | le_wifiClient.c le_wifiClient_Scan() 639 | Scan started
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | le_wifiClient_server.c Handle_le_wifiClient_Scan() 641 | Sending response to client session 0x27cac : 4 bytes sent
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=WiFi Client Scan Thread | LE_FILENAME PThreadStartRoutine() 362 | Set nice level to 0.
Jan 2 16:50:00 swi-mdm9x15 user.info Legato: INFO | wifiService[522]/daemon T=WiFi Client Scan Thread | pa_wifi_client_ti.c pa_wifiClient_Scan() 419 | Scanning
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=WiFi Client Scan Thread | le_wifiClient.c MarkAllAccessPointsOld() 317 | Mark all AP as old
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=WiFi Client Scan Thread | le_wifiClient.c MarkAllAccessPointsOld() 346 | Marked: 0
Jan 2 16:50:00 swi-mdm9x15 user.info Legato: INFO | wifiService[522]/daemon T=WiFi Client Scan Thread | pa_wifi_client_ti.c pa_wifiClient_GetScanResult() 484 | Scan results
Jan 2 16:50:00 swi-mdm9x15 user.info Legato: INFO | wifiService[522]/daemon T=WiFi Client Scan Thread | pa_wifi_client_ti.c pa_wifiClient_GetScanResult() 504 | PARSING:WIFICLIENT_START_SCAN : len:22
Jan 2 16:50:00 swi-mdm9x15 user.err Legato: =ERR= | wifiService[522] | command failed: No such device (-19)
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=WiFi Client Scan Thread | le_wifiClient.c ScanThreadDestructor() 395 | Scan thread exited.
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=WiFi Client Scan Thread | le_wifiClient.c PaEventHandler() 118 | Event: 2
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=main | le_wifiClient.c FirstLayerWifiClientEventHandler() 452 | Event: 2
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | le_wifiClient_server.c AsyncResponse_le_wifiClient_AddNewEventHandler() 398 | Sending message to client session 0x27cac : 8 bytes sent
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=main | le_wifiClient.c IsScanRunning() 430 | IsScanRunning .0
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=main | le_wifiClient.c le_wifiClient_GetFirstAccessPoint() 681 | Get first AP
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=main | le_wifiClient.c le_wifiClient_GetFirstAccessPoint() 700 | AP not found
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | le_wifiClient_server.c Handle_le_wifiClient_GetFirstAccessPoint() 683 | Sending response to client session 0x27cac : 4 bytes sent
Jan 2 16:50:00 swi-mdm9x15 user.err Legato: =ERR= | wifi[7459]/wifi T=main | wifi_client.c WifiReadScanResults() 123 | le_wifiClient_GetFirstAccessPoint ERROR
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=main | le_wifiClient.c le_wifiClient_RemoveNewEventHandler() 538 | Remove event handler
Jan 2 16:50:00 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | le_wifiClient_server.c Handle_le_wifiClient_RemoveNewEventHandler() 515 | Sending response to client session 0x27cac : 0 bytes sent
Jan 2 16:50:01 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/daemon T=main | le_wifiClient.c CloseSessionEventHandler() 414 | sessionRef 0x27cac GetFirstSessionRef 0x27cac
Jan 2 16:50:01 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | le_wifiClient_server.c CleanupClientData() 195 | Client 0x27cac is closed !!!
Jan 2 16:50:01 swi-mdm9x15 user.debug Legato: DBUG | wifiService[522]/framework T=main | le_wifiAp_server.c CleanupClientData() 195 | Client 0x27d3c is closed !!!

Do you have any idea why the IoT expansion card is not starting properly on the MangohRed?

Just for clarification, the Versions are up to date according to the tutorial(although it is a mangoh Green tutorial):

root@swi-mdm9x15:~# fwupdate query
Connecting to service …
Firmware Version: SWI9X15Y_07.12.09.00 r34123 CARMD-EV-FRMWR1 2017/04/26 23:34:19
Bootloader Version: SWI9X15Y_07.12.09.00 r34123 CARMD-EV-FRMWR1 2017/04/26 23:34:19
Linux Version: 3.14.29ltsi-961ca71325_ab5094eade #2 PREEMPT Thu Apr 27 02:17:10 PDT 2017
root@swi-mdm9x15:~# legato version
16.10.3_7776bb75a488e0db67b0d24975b46dd0

I believe it comes down to the wifi board not being recognized on the Red. Any suggestions? Thanks!


All wifi commands failing with Mirage board
#6

@asyal , is this a known bug?


#7

Hey Rauger1, is there any play on the IOT board in the amphenol connector? We had some IoT boards made and we found we weren’t getting a very good connection inside of the amphenol connector. As a result I had to add nylon washers under the board to prop the IOT board up slightly when it’s screwed on… This would force some contact.

I’m assuming this is likely not your problem, but it may be worth a quick test to check.


#8

Hi @coastalbrandon,

We took your suggestion and set the board to the left and right of the amphenol connector to no luck. Then we tried with a small piece of rubber underneath the board like your nylon washers and that did not help. We have a board that plugs into the amphenol which contains LEDs and small speakers that we can power from the board that does work, so the amphenol connector is not the issue.


#9

@asyal,
Is the wifi for the mirage board supposed to be supported for the mangoh red? Is there any update on usability of the usb port for the red?

Thanks.


#10

USB port on Red is usable. Could you let me know what the problem is?

For the mirage board, we will investigate what issue you are having next week.


#11

@asyal,

lsusb does not work, and we don’t have any way of interfacing with the USBs. The USBs we have with LEDs that light up when plugged into a traditional computer do not light up when connected to the mangoh. We checked the USB pins and they are receiving power. It seems as if the USB driver is not working.

As for the mirage board, I posted the error above. I am not quite sure what to make of it.

Thanks for your help


#12

Hi ,
I have opened a ticket on the lsusb with the modem team. For mirage board, @dclark75 can help.


#13

any further work or updates on this, we are facing a similar issue with an iot card, and its seriously holding us up in development and testing


#14

Here is apossible fix that was suggested to us by @davidc

"we need to add the following line to the end of the existing /etc/mdev.conf file

$DEVNAME=bus/usb/([0-9]+)/(0-9]+) 0:0 0666 =bus/usb/%1/%2
This will create the appropriate device nodes for USB devices (assuming that the device hasn’t matched a previous rule) as they are plugged into the WP into /dev/bus/usb, and remove them if the device is removed.

This will make lsusb/libusb work
"


#15

well i happened to come across usb-devices on the mangoh board also, which pretty much works


#16

i tried adding this rule to mdev.conf and i still get lsusb
root@swi-mdm9x15:~# lsusb
unable to initialize libusb: -99

so i pulled the usb device, and plugged it back in… now libusb works our code loaded… however we have a dilemma

the usb device is actually an iot card, this would mean having to pull / push the iot device every time… and its not feasible in the business model of deployed systems… ideas ??


#17

Here is a bit more detail on this, again from @davidc ,
"The second problem


The above was working for devices that were ‘hotplugged’ (i.e. plugged into the USB host port on the mangOH after it had booted). I still wasn’t seeing the onboard devices appear in the /dev/bus/usb directory. Interestingly, once one device had appeared in the directory, lsusb was happy and could see the rest of the onboard devices. Why? No idea.

Not having device nodes for devices that appear early in the boot sequence is a known problem - it’s called ‘coldplugging’ - and essentially it means that the kernel has recognised the device/loaded module etc before the hotplug manager is alive. So to get around this, mdev has an option ‘-s’ (scan) that forces a manual rescan of /sys/class and re-evaluates all devices found there according to the rules in /etc/mdev.conf. It is intended that ‘mdev -s’ is called during the startup sequence to enumerate any devices that the kernel knowns about, but haven’t been configured yet.

But I found that ‘mdev -s’ was NOT enumerating the USB devices - even after adding the correct rule to mdev.conf. After a lot of head scratching, debugging and looking through the mdev source code, I found that mdev was only scanning /sys/class for device families - and somewhere between kernel 3.6 and 3.18, the kernel was no longer putting usb device descriptors into /sys/class/usb - but only into /sys/bus/usb - so mdev -s could not see the ‘coldplugged’ USB devices.

I found a hint on a forum that you could ‘force’ a hotplug event by echoing data to a file in /sys/bus/usb/devices/xxx/uevent, so I’ve hacked up a script that forces a ‘hotplug’ add event to all devices in /sys/bus/usb/devices - which then trips mdev and evaluates the correct mdev rule - which puts the correct device nodes /dev/bus/usb/

I’m not sure just where to put the re-scan script yet - probably edit the init script that calls mdev -s
"
In the short term , see if the following script helps:

#!/bin/sh

scanusb.sh

2018.02.09 D. Clement/Renfell Engineering

Force a hotplug add event of usb devices in /sys/bus/usb

This is required because linux kernels newer than

about 3.10 have moved the USB devices out of /sys/class/usb

and into /sys/bus/usb. This breaks the mdev -s coldplug

operation

/etc/mdev.conf ALSO needs modification to map the USB devices

into the /dev/bus/usb directory to support libusb

Add the following line to the end of /etc/mdev.conf

$DEVNAME=bus/usb/([0-9]+)/(0-9]+) 0:0 0666 =bus/usb/%1/%2

for I in find /sys/bus/usb/devices -maxdepth 1 -type l ; do

if [ -e $I/uevent ]; then
    echo add > $I/uevent
fi

done


Libusb partly working on red - cannot find usbfs
#18

thanks for that, unfortunatley it hasnt helped, still need to unplug/plug the usb device before its seen


#19

so… just to update everyone on this subject… after adding the magic udev rule to our build it seems that running i2cgpioctl enter “100” load setup defaults, enter “0” to exit does bring up the usb iot cards without having to reslot them, then simply running the pasted enableIoT2.sh
which is specific to IOT2 with notes on the others slots, might just get you there

cat enableIoT2.sh
#!/bin/sh

I2C bus switch on address 0x71

0xFC - expander #3, this has the IoT card reset lines

Expander #3 address 0x70 (after selecting expander 3 bus above)

Port A Pin I/O 2 = IoT port 2 Reset (low = reset, high = run)

Port A Pin I/O 3 = IoT port 1 Reset (low = reset, high = run)

Port A Pin I/O 4 = IoT port 0 Reset (low = reset, high = run)

NOTE:

The default programming loaded by the OS to this expander sees

port “a”, which contains these reset lines (which are “active low”)

configured in “inverted polarity”. (Reg 0x0d = 0xFF).

This means that to remove reset, we need to write a 0 to the appropriate

bit.

Relevent chip registers for expander:

0x0E Port B direction (0=out, 1=in)

0x0F Port A direction (0=out, 1=in)

0x0C Port B polarity (0=normal, 1=inverted)

0x0D Port A polarity (0=normal, 1=inverted)

0x10 Port B data

0x11 Port A data

echo ‘Switching bus to GPIO expander #3
i2cset -y 0 0x71 0xFC
echo ‘Release IoT2 Reset line’
i2cset -y 0 0x70 0x11 0xFB