Port Identifiers on OSX

[Al B]

I connected the IOIO OTG to my mac with a micro-B USB cable. It is not externally powered, but the red pwr LED is constantly on. I've have now tried with both host mode switch on the OTG board auto ("A") position and host ("H") position, but I am still not able to see the /dev/tty.usb* directory in my 10.8 OSX system.  I can only see the /dev/tty.Bluetooth-Modem and the   /dev/tty.Bluetooth-PDA-Sync directories.

Do I need to install or run something else?

TIA!

[Ytai Ben-Tsvi]

Switch needs to be in the A position. Port should appear as /dev/tty.usbmodem*

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ioio-users+...@googlegroups.com.
To post to this group, send email to ioio-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ioio-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Al B]

Yes, I set it back to "A" and I still cannot see any /dev/tty.usbmodem directory.

[Ytai Ben-Tsvi]

Try bootloader mode perhaps. Otherwise try recalibrating the oscillator. Details on the wiki.

On May 9, 2013 11:38 PM, "Al B" <cagi...@gmail.com> wrote:

Yes, I set it back to "A" and I still cannot see any /dev/tty.usbmodem directory.

--

[Al B]

Putting the IOIO into a bootloader mode did the trick.  Now /dev/tty.usbmodemfa131 is listed when I run "ls /dev/tty.usb*" so thanks for that tip.

One thing I noticed though, is that the stat LED never blinked after I removed the jumper so hopefully nothing is wrong with my brand new IOIO-OTG.

[Al B]

I failed to mention in my previous post that once I power off & on the IOIO-OTG (which caused it to exist the bootloader mode) and if I try the "./ioiodude --port=/dev/tty.usbmodemfa131 versions" command when the IOIO is connected and running the standard firmware, then nothing is returned by the command. According to the wiki, I should see the message below, but I don't.  Could it be that something is wrong with my IOIO-OTG board from Jaycon Systems?

IOIO Application detected.

Hardware version: SPRK0020
Bootloader version: IOIO0400
Application version: IOIO0330

[Ytai Ben-Tsvi]

Maybe you have a bad app firmware. Try getting the device into bootloader mode and use IOIODude to reflash it with V3.30 or V4.00 application firmware.

[Al B]

The board is now back into bootloader mode so do you want me to run this?

ioiodude --port=/dev/tty.usbmodemfa131 --force --reset write Boot-IOIO0311-App-IOIO0400.ioioimg

[Ytai Ben-Tsvi]

No. Just the app firmware (.ioioapp) file.

On May 10, 2013 5:37 PM, "Al B" <cagi...@gmail.com> wrote:

The board is now back into bootloader mode so do you want me to run this?

ioiodude --port=/dev/tty.usbmodemfa131 --force --reset write Boot-IOIO0311-App-IOIO0400.ioioimg

--

[Al B]

As you suggested, I ran this:

./ioiodude --port=/dev/tty.usbmodemfa131 --force --reset write App-IOIO0400.ioioapp

and I got this:

[########################################]
Writing fingerprint...
Done.

However, /dev/tty.usbmodemfa131 is gone as soon as I exist the bootloader mode.  I am not sure what is going on since the HelloIOIO app works fine.

The wiki page says "If you just got a new IOIO-OTG, chances are that the initial calibration procedure has been done for you at the factory, so if the LED does not blink, it does not mean that something is wrong."

Does the above mean that stat yellow LED should blink a few times every time the IOIO is turned ON?

Because in my case, only the red LED lights up when I power the IOIO in normal mode.

[Al B]

So do you think this is still a problem with software or is it a problem with the board hardware?

[Ytai Ben-Tsvi]

The stat LED does not blink upon normal start-up when using bootloader V4.x. It will only blink if you enter bootloader mode or if your oscillator is not calibrated.

Have you tried going through the oscillator calibration procedure?

It is very unlikely a hardware issue, since the bootloader does manage to establish a solid connection.

Does running dmesg on a shell after a failed attempt show anything related?

On Sat, May 11, 2013 at 10:49 AM, Al B <cagi...@gmail.com> wrote:

So do you think this is still a problem with software or is it a problem with the board hardware?

[Al B]

I executed the Boot Sequence while pin 1 is shorted to GND.  However, when the IOIO-OTG is powered on, the stat (yellow) LED doesn't blink at all. I still went ahead and connected it to a USB host.  Maybe I am missing some steps.

I ran "sudo dmesg", the output is quite long.  Should I look for something specific (e.g. Error string or a particular message)?

Thanks Ytai!

[Ytai Ben-Tsvi]

You missed something. The yellow LED should blink quickly if you follow the procedure correctly.

Work with an external power supply, not with the IOIO connected to the host.

Power on when pin1->GND and boot->GND.

While powered on, detach boot from GND.

Then, if you power cycle, you should see the fast blink. Attach to host and see the fast blink stop.

[Al B]

I followed your steps:

I used the power supply and not the host laptop to power the IOIO.
Then, I powered on the IOIO when pin1->GND and boot->GND were connected.The yellow LED stay on all the time.

While powered on, I detached the boot from GND. At that moment, the yellow LED started blinking quickly.
While it was still blinking and powered with the power supply, I connected the USB cable to the laptop.  The yellow LED stopped blinking for less than second, then it blinked 3 times, and then completely stop blinking.
Then, I powered everything off, disconnected pin1 from GND, and connected only the USB cable to the IOIO, but the laptop still cannot see it as tty.usb* port unless I set it back to bootloader mode.

Did I missed anything?

[Ytai Ben-Tsvi]

That's what I meant. You seem to have followed all the right steps, and the fact that the bootloader behaves differently than the app is very surprising.

This shouldn't matter unless I have a bug somewhere, but is your host mode switch in the "A" position?

--

[Ytai Ben-Tsvi]

Correction: looking at the code, it seems like the bootloader will act as a device regardless of the OTG role (which is arguably a bug, but not a terrible one).

So the behavior you're seeing is very likely to be a result of the IOIO thinking it is a host when running the app, either because of the switch position set to "H" or because some USB cable is acting funny, or otherwise some short on the board.

[Al B]

Yes, the host mode switch has been in the "A" position all the time.

I've been using the cable from Sparkfun and using a adapter to connect the IOIO to the laptop (see pics below).  Do you think that is the problem?  Or if it is short on the board, then is there a way I can validate that?

Thanks again Ytai for your help with this!

[Ytai Ben-Tsvi]

Something in your story is very weird:

WHY and HOW would you connect the IOIO to your PC using SparkFun's adapter (it's the wrong gender...)???

You don't need any adapter, just a standard micro-B USB cable from the PC to the IOIO...

[Al B]

Ok, the cable I use to connect the Android phone to the laptop/charger has a standard micro-B USB cable so I am now using it to connect the laptop to the IOIO.  Same results though (it cannot see it as USB port).

Could the SparkFun's adapter have caused any damage to the IOIO (e.g. a short on the board)?

[Ytai Ben-Tsvi]

I have no idea how you've actually physically managed to connect the IOIO to the PC using the adapter...

Starting from square one:

• Use the same cable you would normally use to connect the PC to your Android WITHOUT the adapter (which is only for host mode, i.e. connecting the IOIO to Android or to a BT dongle).
  
• Make sure the host mode switch is in the "A" mode.
  
• Do not externally power the IOIO.
• Connect the IOIO to the PC, make sure the red LED is on.
• Check whether it enumerates. If not, repeat the oscillator calibration process again, and also check whether it works with the bootloader running.

[Al B]

Sorry Ytai, but I am not I follow.

What do you mean with "Check whether it enumerates"?

Also, regarding the the oscillator calibration process, this the only description I have found:

"the IOIO-OTG bootloader is capable of automatically calibrate the oscillator, by synchronizing itself on a clock provided by a USB host. When the IOIO-OTG is powered on, if the bootloader detects that there is no current tuning value, it will start blinking the stat (yellow) LED very quickly, signaling that it is expecting you to connect it to a USB host. Once you do that, it will calibrate itself, store the value in Flash memory and move on. Upon next power-up, the value will be read from Flash and the calibration process is skipped."

The above is quite confusing since the only time I see the yellow LED blinking is when I execute the Boot Sequence.  Are there any other step-by-step description for the oscillator calibration process in the wiki?

[Ytai Ben-Tsvi]

In the same page you're quoting from (https://github.com/ytai/ioio/wiki/IOIO-OTG-Bootloader-and-IOIODude), one paragraph up is an explanation of how to do a configuration wipe, which will reset the oscillator calibration settings.

[Al B]

Ytai,

Please take a look at these 3 videos and let me know if I am doing something wrong.

In the first one, I just connect the IOIO to the laptop via the USB cable showing that it doesn't enumerates.

https://vimeo.com/66116538

In the 2nd one, I just try to Boot Sequence, but without the power supply. No sure if it relevant though.

http://www.youtube.com/watch?v=GYn53eGAl10

In the final one, I just execute the steps you indicated yesterday.

http://www.youtube.com/watch?v=ysKyiQMMZug

Thanks!

[Ytai Ben-Tsvi]

You seem to be doing everything OK. It would be interesting to see whether the IOIO works fine with Android over USB and/or with Bluetooth. Currently, my suspicion is that for some reason the IOIO is being forced into host mode, e.g. the host mode switch or the USB connector is shorting USBID to GND. Using Android or BT, you could also verify that your app firmware is in good shape.

[Al B]

Yes, the IOIO works fine with the Android over USB.

I slightly modified the IOIOSimpleApp to open a digital input and everything works fine (see link to video below).

http://www.youtube.com/watch?v=Og3arYTfn7w

Any other suggestions or tests that you want me to do?

Thanks again Ytai!

[Ytai Ben-Tsvi]

No idea at this point other than what I said above.

You could test my guess by seeing whether you're getting a short to GND on the output of the host mode selection switch when it's in the "A" position (there should be a short when it's in the "H" position).

[Ytai Ben-Tsvi]

Oh, and another thing to verify, now that you have it working with Android, is that the app firmware version is 3.30 or greater.

[Al B]

Ytai,

Notice that it always worked fine with the USB cable connected to the Android device and the board powered by a power supply.

What we are trying to figure out is why it doesn't enumerate when the IOIO-OTG is connected to the laptop while the switch is set to auto ("A") position.

The IOIO firmware is IOIO0400 s well as the IOIO bootloader since last week you asked me to install App-IOIO0400.ioioapp.

[Ytai Ben-Tsvi]

I'll explain more clearly:

There's a net on the IOIO board called USBID. It is used by the app firmware to detect whether the IOIO should be acting as a USB device or host. When left floating, the IOIO will act as a device, when pulled to GND, it will act as a host. The device bootloader (v4.x) ignores this line and always acts as a device.

This line can be pulled to GND by either:

• Plugging in an OTG cable into the IOIO's USB jack (such as the red one you got from SparkFun).
• Setting the host mode switch to the "H" position.

All your symptoms so far indicate that your setup has the USBID signal constantly pulled low for some reason. This may be a faulty host-mode switch, or the switch not fully in the "A" position, or an actual short on the board / inside the USB jack. If you have a continuity tester, you can test this guess of mine and see whether that's actually what's happening. If so, you can try to track down the root cause of this and possibly fix it / have the board replaced by the vendor.