-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Getting back on this, attached two patches..
This is definitely no fix but more a "works-for-me-HACK"! though it
might outline where trouble starts..

At least in two of my testbeds it improves owserver running reliable
with multiple DS9490 and long networks for days, instead of minutes.

Though it still doesn't resolve the problem, that when it hits a
reset-error on a "null" bus without id (which couldn't be), no real
action besides a NOOP-loop is IMHO taken. (as comment in patch)

The stuff in ow_usb_msg.c is only for debugging. Just adding this,
it's easy to see that after an usb-reset the adaptors go on
unitialized with wrong settings.


best regards,

Michael

Am 17.03.2012 17:23, schrieb Michael Markstaller:
> I changed the subject..
> 
> Am 16.03.2012 14:49, schrieb Paul Alfille:
>> To hunt this down, you find that heavy USB activity causes
>> communication failures and puts owfs is an unusable state?
> No, I don't think thats a root cause. My last tests where done with
> only 1-4 DS9490R on a powered hub without any other USB-devices
> active. Maybe heavy USB-traffic or long-lines intensify the problem
> but it also happens in simle setups.
> 
> Referring to my post: 
> http://article.gmane.org/gmane.comp.file-systems.owfs.devel/9120 
> #1) is pretty reproduceable, just a matter of time (minutes to
> hours), regardless wether there is one DS9490 and one sensor or 6
> and 50.. (leads to #2): the mode-register isn't set after a
> subsequent PoR of the DS2490 IMHO, only initially, so it's set to
> "standard" instead of "flexible" speed which doesn't work
> reliable. #3 (long lines): I *think* its mostly #1+#2: reset_errors
> occur faster on long lines and after the reset the BM is running at
> standard vs. flexible speed which then worses the problem until all
> sensors (including the 81.xx id-chip!) is lost.
> 
> As fas as I understand the code, what happens then is trying to 
> reset/reconnect the lost BM resulting in a noop: DEBUG:
> ow_ds9490.c:(513) Attempting RESET on null bus DEBUG:
> ow_reset.c:(48) Reset error. Reconnection 4/2
> 
> until a restart of owserver the whole bus is "lost"
> 
> 
> I experienced the problems with openwrt (current trunk)
> &owfs2.8p8/p14 and was able to reproduce them easily with 2.8p14 on
> ubuntu 11.10
> 
> 
> (#4 this might be related or not) - under openwrt I get masses of 
> usb 1-1.1: usbfs: usb_submit_urb returned -28 in dmesg
> 
>> I need to create a test bed to mimic and correct this.
> 
> Would be no issue to setup some systems for testing!
> 
> 
> best regards
> 
> Michael
> 
> ------------------------------------------------------------------------------
>
> 
This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure 
> _______________________________________________ Owfs-developers
> mailing list Owfs-developers@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk962lsACgkQaWRHV2kMuAL5oACeKI6g7RXbpcEjuSzmdmiGNUl5
46YAn1wGNog/F24zMGXKjUABMOuM0pt2
=DetY
-----END PGP SIGNATURE-----
--- owfs-2.8p14/module/owlib/src/c/ow_ds9490.c	2011-12-11 03:29:48.000000000 +0100
+++ module/owlib/src/c/ow_ds9490.c	2012-04-03 12:39:47.419243139 +0200
@@ -506,8 +506,10 @@
 	struct connection_in * in = pn->selected_connection ;
 	int readlen = 0 ;
 	
+	LEVEL_DEBUG("DS9490 RESET. changed %d, flex: %d", in->changed_bus_settings, in->flex) ;
+	
 	if (in->master.usb.usb == NULL || in->master.usb.dev == NULL) {
-		LEVEL_DEBUG("Attempting RESET on null bus") ;
+		LEVEL_DEBUG("Attempting RESET on null bus %d/%d", in->master.usb.usb, in->master.usb.dev) ; //FIXME! what doees it mean? no action/reconnect is even tried-> shouldn't we just drop this BM and let uscan rediscover it? DS9490 must always have an ID chip..
 		return BUS_RESET_ERROR;
 	}
 
@@ -530,7 +532,8 @@
 	}
 
 	// Send reset
-	if ( BAD( USB_Control_Msg(COMM_CMD, COMM_1_WIRE_RESET | COMM_F | COMM_IM | COMM_SE, USpeed, pn)) ) {
+	//FIXME: MM/ changed hard to flexible speed as it gets wrong somewhere, only want flexible
+	if ( BAD( USB_Control_Msg(COMM_CMD, COMM_1_WIRE_RESET | COMM_F | COMM_IM | COMM_SE, ONEWIREBUSSPEED_FLEXIBLE, pn)) ) {
 		LEVEL_DATA("Reset command rejected");
 		return BUS_RESET_ERROR;			// fatal error... probably closed usb-handle
 	}
@@ -545,18 +548,41 @@
 	switch( DS9490_getstatus(buffer, &readlen, pn) ) {
 		case BUS_RESET_SHORT:
 			/* Short detected, but otherwise no bigger problem */
+			LEVEL_DEBUG("DS9490_Reset: SHORT");
 			return BUS_RESET_SHORT ;
 		case BUS_RESET_OK:
+			LEVEL_DEBUG("DS9490_Reset: OK");
 			break ;
 		case BUS_RESET_ERROR:
 		default:
-			return BUS_RESET_ERROR;
+			LEVEL_DEBUG("DS9490_Reset: ERROR");
+			/* FIXME: FIXED. In ow_usb_msg.c an USB-reset was was issued:
+			* USB_Control_Msg(CONTROL_CMD, CTL_RESET_DEVICE, 0x0000, pn) ;
+			* So we need to setup the Adapter again 
+			* Though here is probably the wrong place, duplicated code from _setup_adaptor
+			*/
+
+    		// enable both program and strong pulses
+	        if ( BAD( USB_Control_Msg(MODE_CMD, MOD_PULSE_EN, ENABLE_PROGRAM_AND_PULSE, pn)) ) {
+		        LEVEL_DATA("EnableProgram error");
+	        }
+	        // enable speed changes
+	        if ( BAD( USB_Control_Msg(MODE_CMD, MOD_SPEED_CHANGE_EN, 1, pn)) ) {
+		        LEVEL_DATA("RESET_Error: SpeedEnable error");
+	        }
+	        // set the strong pullup duration to infinite
+	        if ( BAD( USB_Control_Msg(COMM_CMD, COMM_SET_DURATION | COMM_IM, 0x0000, pn)) ) {
+		        LEVEL_DATA("StrongPullup error");
+		        return gbBAD;
+	        }
+            DS9490_SetSpeed(pn);
+            return BUS_RESET_ERROR;
 	}
 	//USBpowered = (buffer[8]&STATUSFLAGS_PMOD) == STATUSFLAGS_PMOD ;
 	in->AnyDevices = anydevices_yes ;
 	for (i = 16; i < readlen; i++) {
 		BYTE val = buffer[i];
-		LEVEL_DEBUG("Status bytes[%d]: %X", i, val);
+		LEVEL_DEBUG("Reset: Status bytes[%d]: %X", i, val);
 		if (val != ONEWIREDEVICEDETECT) {
 			// check for NRS bit (0x01)
 			if (val & COMMCMDERRORRESULT_NRS) {
@@ -814,7 +840,7 @@
 // Delay delay msec and return to normal
 static GOOD_OR_BAD DS9490_PowerByte(BYTE byte, BYTE * resp, UINT delay, const struct parsedname *pn)
 {
-	LEVEL_DATA("start");
+	LEVEL_DATA("DS9490_PowerByte start");
 
 	/* This is more likely to be the correct way to handle powerbytes */
 	if ( BAD( USB_Control_Msg(COMM_CMD, COMM_BYTE_IO | COMM_IM | COMM_SPU, byte & 0xFF, pn)) ) {
@@ -826,6 +852,7 @@
 		return gbBAD ;
 	}
 	/* Delay with strong pullup */
+	LEVEL_DEBUG("DS9490_PowerByte DELAY:%d", delay);
 	UT_delay(delay);
 	DS9490_HaltPulse(pn);
 	return gbGOOD ;
@@ -886,7 +913,7 @@
 			return gbBAD;
 		}
 	} while ( timercmp( &tv, &tvtarget, >) ) ;
-	LEVEL_DATA("timeout");
+	LEVEL_DATA("DS9490_HaltPulse timeout");
 	return gbBAD;
 }
 
@@ -1036,7 +1063,7 @@
 		in->master.usb.datasampleoffset = PARMSET_DS0_W0R_8us;
 	} else {
 		/* This seem to be the default value when reseting the ds2490 chip */
-		in->master.usb.pulldownslewrate = PARMSET_Slew0p83Vus;
+		in->master.usb.pulldownslewrate = PARMSET_Slew1p10Vus; //FIXME: was: PARMSET_Slew0p83Vus Datasheet recommends PARMSET_Slew1p10Vus (0x4) ?!
 		in->master.usb.writeonelowtime = PARMSET_W1L_12us;
 		in->master.usb.datasampleoffset = PARMSET_DS0_W0R_7us;
 	}
--- owfs-2.8p14/module/owlib/src/c/ow_usb_msg.c	2011-11-20 22:39:51.000000000 +0100
+++ module/owlib/src/c/ow_usb_msg.c	2012-04-03 12:48:33.319248796 +0200
@@ -196,6 +196,46 @@
 		if (buffer[8] & STATUSFLAGS_IDLE) {
 #if OW_SHOW_TRAFFIC
 			_Debug_Bytes("USB status registers ---- idle ----", buffer, ret) ; // debugging
+			//FIXME: if the line below really works we dont nee the line above ;)
+			LEVEL_DEBUG("USB status registers EFlags:%u->SPU:%u Dspeed:%u,Speed:%u,SPUdur:%u, PDslew:%u, W1lowtime:%u, W0rectime:%u, DevState:%u, CC1:%u, CC2:%u, CCState:%u, DataOutState:%u, DataInState:%u", 
+			    buffer[0], (buffer[0]&0x01), (buffer[0]&0x04 ? 1 : 0), 
+			    buffer[1],
+			    buffer[2], 
+			    buffer[4],
+			    buffer[5],
+			    buffer[6],
+			    buffer[8],
+			    buffer[9],
+			    buffer[10],
+			    buffer[11],
+			    buffer[12],
+			    buffer[13]			    );
+		/*
+        Datasheet DS2490 page 29 table 16
+        0: Enable Flags: SPUE=1(bit0) If set to 1, the strong pullup to 5V is enabled, if set to 0, it is disabled. 
+        bit1 should be 0 but is 1 ?! SPCE = 4(bit2) If set to 1, a dynamic 1-Wire bus speed change through a Communication command is enabled, if set to 0, it is disabled.
+        1: 1-Wire Speed
+        2: Strong Pullup Duration
+        3: (Reserved)
+        4: Pulldown Slew Rate
+        5: Write-1 Low Time
+        6: Data Sample Offset / Write-0 Recovery Time
+        7: reserved
+        8: Device Status Flags: bit0: SPUA if set to 1, the strong pullup to 5V is currently active, if set to 0, it is inactive.
+            bit3(8): PMOD if set to 1, the DS2490 is powered from USB and external sources, if set to 0, all DS2490 power is provided from USB. FIXME: expose this to clients to check!
+            bit4(16): HALT if set to 1, the DS2490 is currently halted, if set to 0, the device is not halted.
+            bit5(32): IDLE if set to 1, the DS2490 is currently idle, if set to 0, the device is not idle.
+            bit5(64): EPOF: Endpoint 0 FIFO status, see: If EP0F is set to 1, the Endpoint 0 FIFO was full when a new control transfer setup packet was
+                received. This is an error condition in that the setup packet received is discarded due to the full
+                condition. To recover from this state the USB host must send a CTL_RESET_DEVICE command; the
+                device will also recover with a power on reset cycle. Note that the DS2490 will accept and process a
+                CTL_RESET_DEVICE command if the EP0F = 1 state occurs. If EP0F = 0, no FIFO error condition exists.
+        9: Communication Command, Byte 1
+        10: Communication Command, Byte 2
+        11: Communication Command Buffer Status
+        12: 1-Wire Data Out Buffer Status
+        13: 1-Wire Data In Buffer Status
+		 */
 #endif /* OW_SHOW_TRAFFIC */
 			if (*readlen > 0) {
 				// we have enough bytes to read now!
@@ -210,6 +250,20 @@
 		} else {
 #if OW_SHOW_TRAFFIC
 			_Debug_Bytes("USB status registers ---- Not idle -----", buffer, ret) ; // debugging
+			//FIXME: if the line below really works we dont nee the line above ;)
+			LEVEL_DEBUG("USB status registers EFlags:%u->SPU:%u Dspeed:%u,Speed:%u,SPUdur:%u, PDslew:%u, W1lowtime:%u, W0rectime:%u, DevState:%u, CC1:%u, CC2:%u, CCState:%u, DataOutState:%u, DataInState:%u", 
+			    buffer[0], (buffer[0]&0x01), (buffer[0]&0x04 ? 1 : 0), 
+			    buffer[1],
+			    buffer[2], 
+			    buffer[4],
+			    buffer[5],
+			    buffer[6],
+			    buffer[8],
+			    buffer[9],
+			    buffer[10],
+			    buffer[11],
+			    buffer[12],
+			    buffer[13]			    );
 #endif /* OW_SHOW_TRAFFIC */
 		}
 		// this value might be decreased later...
@@ -218,6 +272,7 @@
 			//reset USB device
 			// probably should reset speed and any other parameters.
 			USB_Control_Msg(CONTROL_CMD, CTL_RESET_DEVICE, 0x0000, pn) ;
+			//FIXME: really! we must setup the adapter settings and speed again! This is done in ow_ds9490.c for now
 			return BUS_RESET_ERROR;	// adapter never got idle
 		}
 		/* Since result seem to be on the usb bus very quick, I sleep
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Reply via email to