To everyone having sporradic connection issues: it might be your
cable. I found out afterf much frustration that the one I have (ebay) needs to be held to one side to work right.
I'll be trying several from different suppliers.

hi guys,

my n900 seems to be temperamental, the usb keyboard works sometimes and when it does its for like 5 seconds. Any clue to why this is happening?

Does using it involve any - even slight - moving of the cables? due to nature of manual enumerating, even very short loss of connection (like not-thick-enough plugs) seems to be spoiling hostmode.

/Estel

I've checked the cables and they are fine. I have noticed the lights on the keyboard flash for a little while then switch off. I think its software related.

I guess it's simple overload of VBUS_5V. Use a powered hub! Make sure you use original H-E-N with my inproved booston.sh script (ships with recent H-E-N package) which should tell you about overload in a notifier and also by switching off the mce indicator LED pattern "PatternVboost"
If you don't have "PatternVboost" in /etc/mce/mce.ini :
PatternVboost=60;5;0;rB;9d80401a480040d948000000;9 d80400b2c900000 <--There's a space showing in my browser in between ";9 d80" which shouldn't be there :-/
goes before "[Vibrator]"
and add
"LEDPatterns=PatternVboost;PatternError;Patter..." to that line

if you don't like to use an editor and do it manually, those commands should establish that for you (I haven't tested it so no warranty taken for typos):

Using improved booston.sh, I'm sometimes hit by the "lights on the keyboard flash for a little while then switch off", but, it *doesn't* mean that keyboard worked, even for a few seconds. It is indication, that vbus power has been switched on. If you experiment a little, you will notice, that lights on keyboard blinks even if you *only* enable vbus, without enumerating.

If enumerating after vbus doesn't work, check dmesg ("kernel messages" from hostmode topdown menu) - you may notice that device wasn't enumerated successfully due to "device not accepting address <blabla>" or "high/low-speed device connected, but high/low-speed mode enabled" false messages.

Sometimes, it requires cycling hostmode on and off few times, until it will "tick" properly, even with perfect cables. Enumeration "just fails" sometimes, for reasons unknown (to someone with my level of understanding how it works, aka *small*).

As a sidenote - it tends to fail sometimes exactly the same way, while using (more popular) Pali's USB Mode frontend. Considering, that they all share common hostmode bits in kernel, bug is probably there.

/Estel

Hi Joe,

I do have PatternBoost there but the value is different. I have
35;5;0;b;9d8040000043fc0000000;9d800000

Should i change the value to yours and add the line "LEDPatterns=PatternVboost;PatternError;Patter ..."

?

I've run a testing session, as this temperamental behavior was bugging me. I was able to establish a 100% reproducible pattern (nothing really new&exciting here, just confirming older reports and summing different things up):

1. When hostmode goes haywire (doesn't want to enumerate device properly, give absurd errors about different speed-type device connected, or device "not accepting addres <>blabla>"), switching to USB peripheral with charging (aka disabling hostmode) *and* connecting briefly to charger fixes it. After disconnecting from charger and re-attempting, device enumerates like charm 100% times.

2. What is even more interesting, is that hostmode with charging *also* counts - i.e, if I enumerate device successfully, then switch to Peripheral (disable hostmode), and try to enter hostmode again shortly after (tested in less than minute), device fails to enumerate 100% of times. Hoever, if - after enumerating device successfully - I connect to charger (y_cable), enable hostmode with charging, then, disable hostmode and enter peripheral, I can re-enable hostmode and enumerate device without any problems, immediately.
---
Summing it up - just like known thing about possible "standby current" after using hostmode ("reset" by connecting to charger), there is something else, that interferes with hostmode, and get "fixed" by device entering into charging state. I suspect, that even "cheating" it that it entered charging - without any physical charger - would do the job, to, just like with fixing "standby current" bug.
---

It's a pity that we don't have competent kernel coder - knowledgeable about USB - handy - definitely something is "fishy" about chip's states after enumerating (successful or attempt). Maybe it is limitation of our hardware and patchwork hostmode, but, even then, hardcoding a forced "fake charging state" after every hostmode disabling (entering peripheral-ready mode), would - probably - serve as extremely dirty, but working, workaround.

/Estel

the problem isn't with kernel hacker but more specifically with a hw-savvy driver hacker. I suspect the issue is about power state of e.g. the ULPI or even the CPU<->musb-hdrc bus.
Did I dream of Pali once promising he would implement the full set of hostmode-kernel debug-features into KP eventually?

Just for the refference, I've forwarded above question to Pali:
http://talk.maemo.org/showpost.php?p...&postcount=192