N900 will not allow USB OTG! - Page 79 - maemo.org

Active Topics

Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 1 day, 16 hrs ago
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 1 day, 17 hrs ago
Maemo repository (3)
to Community by torsen - 2 days, 9 hrs ago
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 3 days, 6 hrs ago
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 4 days, 13 hrs ago
more...

Page 79 of 110

Thread Tools

	joerg_rw	2010-05-07 , 21:28
	Posts: 2,222 \| Thanked: 12,651 times \| Joined on Mar 2010 @ SOL 3	#781

Fr 7. Mai 2010] [21:28:13] <javispedro> btw in case you're interesting when looking through the kernel, the n8x0 host stuff is in the n900 kernel. instead of omap2430.c they use http://mxr.maemo.org/fremantle/sourc...usb/tusb6010.c
[Fr 7. Mai 2010] [21:57:05] <DocScrutinizer> 597 * REVISIT: It would be possible to add support for changing between host
[Fr 7. Mai 2010] [21:57:05] <DocScrutinizer> 598 * and peripheral modes in non-OTG configurations by reconfiguring hardware
[Fr 7. Mai 2010] [21:57:05] <DocScrutinizer> 599 * and then setting musb->board_mode. For now, only support OTG mode.
[Fr 7. Mai 2010] [21:57:29] <DocScrutinizer> from http://mxr.maemo.org/fremantle/sourc...usb/tusb6010.c

The Following User Says Thank You to joerg_rw For This Useful Post:
S0urcerr0r

Matan	2010-05-07 , 21:40
Posts: 1,224 \| Thanked: 1,763 times \| Joined on Jul 2007	#782

Originally Posted by blue_led

and if we find what bme discuss with system watchdog a simple timer routine can tickle both bq24150 and system watchdog every 30s to leave us alone with our tests.

Are you sure BME does something with watchdogs? There are two watchdogs known to the kernel (OMAP and TWL), and both are handled by DSME.

__________________
My repository

"N900 community support for the MeeGo-Harmattan" Is the new "Mer is Fremantle for N810".

No more Nokia devices for me.

The Following 3 Users Say Thank You to Matan For This Useful Post:
egoshin, joerg_rw, S0urcerr0r

blue_led	2010-05-07 , 21:49
Posts: 306 \| Thanked: 566 times \| Joined on Jan 2010 @ Romania	#783

found on ulpi erata

Depending on the application, the link should enable or disable the appropriate Vbus interrupts. Example
settings for typical applications are given in Table
Application VbusValid(*) SessValid SessEnd
Standard Host Yes No No
Standard Peripheral No Yes No
OTG A-Device Yes Yes No
OTG B-Device No Yes Yes
Table – Vbus indicators in the RXCMD required for typical applications
* The VbusValid indicator in the RXCMD comes from either the internal VbusValid comparator, or the external Vbus
indicator

and for shure 1707 pin layout seem to be a standard
another chip found ( without charger detection )
http://www.st.com/stonline/products/.../stulpi01a.pdf

tusb6010.c
957 if (!(musb_readl(tbase, TUSB_DEV_OTG_STAT)
958 & TUSB_DEV_OTG_STAT_ID_STATUS))
959 musb_writel(tbase, TUSB_INT_SRC_SET,
960 TUSB_INT_SRC_ID_STATUS_CHNG);

funny but not for n900

Last edited by blue_led; 2010-05-07 at 22:19.

The Following 4 Users Say Thank You to blue_led For This Useful Post:
egoshin, javispedro, joerg_rw, S0urcerr0r

egoshin	2010-05-07 , 23:08
Posts: 992 \| Thanked: 995 times \| Joined on Dec 2009 @ California	#784

Originally Posted by javispedro

When vbus is detected by twl3040 twl3040-usb fires a sysfs-node changed event (linkstat) which I believe bme is listening to, which then proceeds to read the charger sysfs node thus causing musb_verify_charger to run thus causing DP & DM pull downs to be disabled and strong pull up on DP to be enabled (thus entering gadget/peripheral mode)

Confirmed:

connecting charger causes VBUS signal, some application (BME?) reads /sys/devices/platform/musb_hdrc/charger --> calls musb_charger_detect() and if a charger is a high-performance charger (not PC) then VDAT signal enforces a call to musb_verify_charger().

The last function clears DP/DM PULLDOWN and sets only DM_PULLDOWN.

But this happens only for high performance charger.

The Following 3 Users Say Thank You to egoshin For This Useful Post:
javispedro, joerg_rw, S0urcerr0r

	joerg_rw	2010-05-08 , 01:20
	Posts: 2,222 \| Thanked: 12,651 times \| Joined on Mar 2010 @ SOL 3	#785

Originally Posted by egoshin

The last function clears DP/DM PULLDOWN and sets only DM_PULLDOWN.

I wonder why it sets any pulldown at all, actually I'd think even chrg_det won't work with both pulldowns set, it rather should use a pullup on one dataline, and a (much larger) pulldown plus voltage comparator on the other dataline for detection of D+/- short.
Then when a high power charger is detected, any D+/- meddling is highly senseless, as you'll notice unplugging of the charger anyway, by VBUS drop (if you simply switch off the charger, no side effects will arise from that either, as next return of VBUS - when you plug the wallwart to the wall again - will trigger another D+/- short detection cycle).

My 2 cent
/j

[edit]
Nokia-N900-02-8:~# cat /sys/devices/platform/musb_hdrc/charger /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus
1) nothing attached
0 0
2) blank cable, D+/- short
0 0
3) VBUS (from hub downstream)
0 1
4) VBUS plus D+/- short
1 1
5) like 3) but after 4)
1 1

we see
a) /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus is 5V VBUS detection, probably from twl4030
b) /sys/devices/platform/musb_hdrc/charger is D+/- short detect, aka charger_detect, probably from 1707
c) charger_detect only works (or is triggered) when VBUS is applied
d) charger_detect is 'stricky', se 3) vs 5) above. I.E. it is reset to 0 only when vbus is removed (I have not checked to keep D+/- short while removing VBUS, but I'd expect the standard charger when unplugged from mains does exactly that, and it results in 0 0 )

bme_RX-51 open files:

Code:

Nokia-N900-02-8:~# lsof -p 712    
COMMAND   PID USER   FD   TYPE     DEVICE    SIZE  NODE NAME
bme_RX-51 712 root  cwd    DIR      254,1    1704     1 /   
bme_RX-51 712 root  rtd    DIR      254,1    1704     1 /   
bme_RX-51 712 root  txt    REG      254,1  105500 17456 /usr/sbin/bme_RX-51
bme_RX-51 712 root  mem    REG      254,1  119108    88 /lib/ld-2.5.so     
bme_RX-51 712 root  mem    REG      254,1 1164232   121 /lib/libc-2.5.so   
bme_RX-51 712 root  mem    REG      254,1   45696   252 /lib/libgcc_s.so.1 
bme_RX-51 712 root  mem    REG      254,1   90612    87 /lib/libpthread-2.5.so
bme_RX-51 712 root  mem    REG      254,1   28428    84 /lib/librt-2.5.so     
bme_RX-51 712 root  mem    REG      254,1  868892  5664 /usr/lib/libglib-2.0.so.0.2000.3
bme_RX-51 712 root  mem    REG      254,1  450020    75 /lib/libm-2.5.so                
bme_RX-51 712 root  mem    REG      254,1   22112  6076 /usr/lib/libcal.so.1.0.0        
bme_RX-51 712 root  mem    REG      254,1    7600  6481 /usr/lib/libdsme.so.0.2.0       
bme_RX-51 712 root    0u   CHR        5,1           995 /dev/console                    
bme_RX-51 712 root    1u   CHR        5,1           995 /dev/console                    
bme_RX-51 712 root    2u   CHR        5,1           995 /dev/console                    
bme_RX-51 712 root    3r   CHR      10,63          1636 /dev/twl4030-adc                
bme_RX-51 712 root    4u   CHR       89,2          1496 /dev/i2c-2                      
bme_RX-51 712 root    5u   CHR       89,2          1496 /dev/i2c-2                      
bme_RX-51 712 root    6u   REG       0,11      80  3156 /nosmq                          
bme_RX-51 712 root    7r   REG        0,0    4096   951 /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus
bme_RX-51 712 root    8r   REG        0,0    4096   989 /sys/devices/platform/musb_hdrc/mA                  
bme_RX-51 712 root    9r   REG        0,0    4096   991 /sys/devices/platform/musb_hdrc/charger             
bme_RX-51 712 root   10r   REG        0,0    4096   994 /sys/devices/platform/musb_hdrc/suspend             
bme_RX-51 712 root   11u  unix 0xcfc0da80          3172 socket                                              
bme_RX-51 712 root   12u  unix 0xcfc0de00          3174 /tmp/.bmesrv                                        
bme_RX-51 712 root   13u  unix 0xccbd7700          4651 /tmp/.bmesrv                                        
bme_RX-51 712 root   14u  unix 0xcc88d540          3776 socket

I wonder what /dev/twl4030-adc might do...

Last edited by joerg_rw; 2010-05-08 at 04:08.

The Following 2 Users Say Thank You to joerg_rw For This Useful Post:
egoshin, S0urcerr0r

egoshin	2010-05-08 , 03:59
Posts: 992 \| Thanked: 995 times \| Joined on Dec 2009 @ California	#786

OK, last result about VBUS -

I repeated the test (boost VBUS with DRVVBUS of OTG_CTRL register of TWL4030 chip) with naked cable and multimeter:

N900 --- cable --- USB memory stick

and measured voltages.

Between black and red cable - 3.5V
Between red and another cable - 2.5V

Another combinations gave me around 0 or 1.5V

EDIT: this time a can't get a repeated session setup. Only "cable problem" or so message. However, it was in HOST mode - it tries to enumerate usb1-0.

Last edited by egoshin; 2010-05-08 at 04:01.

The Following 3 Users Say Thank You to egoshin For This Useful Post:
javispedro, joerg_rw, S0urcerr0r

	joerg_rw	2010-05-08 , 04:11
	Posts: 2,222 \| Thanked: 12,651 times \| Joined on Mar 2010 @ SOL 3	#787

well, TWL4030 boost mode does not work, I told you before. Maybe now you believe me. Also take care, we do not know what happens to TWL4030 when enabling the boostmode and no capacitor is on the chargepump. It might break.

The Following 2 Users Say Thank You to joerg_rw For This Useful Post:
javispedro, S0urcerr0r

egoshin	2010-05-08 , 04:17
Posts: 992 \| Thanked: 995 times \| Joined on Dec 2009 @ California	#788

Originally Posted by joerg_rw

a) /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus is 5V VBUS detection, probably from twl4030

3.5V - it is from my experiment, see my previous post.

b) /sys/devices/platform/musb_hdrc/charger is D+/- short detect, aka charger_detect, probably from 1707

Sure - 1707, it is from code.

c) charger_detect only works (or is triggered) when VBUS is applied

It is a pure wish of BME and we are not sure then it reads file '.../charger'

d) charger_detect is 'stricky', se 3) vs 5) above. I.E. it is reset to 0 only when vbus is removed (I have not checked to keep D+/- short while removing VBUS, but I'd expect the standard charger when unplugged from mains does exactly that, and it results in 0 0 )

charger_detect is called by reading file /sys/devices/platform/musb_hdrc/charger and it seems that BME reads it after it gets signal about VBUS UP.

The Following User Says Thank You to egoshin For This Useful Post:
S0urcerr0r

egoshin	2010-05-08 , 04:19
Posts: 992 \| Thanked: 995 times \| Joined on Dec 2009 @ California	#789

Originally Posted by joerg_rw

well, TWL4030 boost mode does not work, I told you before. Maybe now you believe me. Also take care, we do not know what happens to TWL4030 when enabling the boostmode and no capacitor is on the chargepump. It might break.

Sorry, Joerg, I believe multimeter. It is possible to create multiple explanations but fact is - 3.5V between red and black cable, after I set DRVVBUS in DEVCTL of TWL4030.

The Following User Says Thank You to egoshin For This Useful Post:
S0urcerr0r

	joerg_rw	2010-05-08 , 04:26
	Posts: 2,222 \| Thanked: 12,651 times \| Joined on Mar 2010 @ SOL 3	#790

Originally Posted by egoshin

Sorry, Joerg, I believe multimeter. It is possible to create multiple explanations but fact is - 3.5V between red and black cable, after I set DRVVBUS in DEVCTL of TWL4030.

Aha, so why don't you believe your multimeter then wrt to 3.5V being a definitely broken non-functional state for the TWL4030 chargepump, and also completely useless for any attached USB device?
We need five Volt, not 3.5. Of course a chargepump without charge-pumping capacitor can forward the battery voltage (well maybe), this only shows clearly the capacitor on TWL4030 actually is missing