From: tnp@invalid.invalid   
      
   Ok, this is the one destined to be an oil level sensor and I have been   
   working on getting a stable TCP/IP and Wi-Fi stack, which seems to have   
   been achieved, as its talking reliably, albeit with delay, to my most   
   remote Wi-Fi AP at a signal level  generally around -87dbM.   
   That is not, however the problem (although I thought it was). The   
   problem seems to be that very very occasionally and as far as I can tell   
   *completely randomly*, it fails to return from the function listed   
   below. Cargo culted from the module manufacturers application notes   
      
   This is for the ultrasonic transducer module.   
   When it fails, all GPIO pins to and from the transducer module measure  LOW.   
      
   static float get_distance()   
   	{   
   	int i;   
   	absolute_time_t start;   
   	absolute_time_t end;   
   	static int64_t us_delay;   
   	gpio_put(ULTRASONIC_OUT,0);   
   	sleep_us(2);   
   	//set output pin high   
   	gpio_put(ULTRASONIC_OUT,1);   
   	sleep_us(10);   
   	gpio_put(ULTRASONIC_OUT,0); //reset the input   
   	// wait for echo pulse start   
   	while(!gpio_get(ULTRASONIC_IN))   
   		;   
   	//read clock and store   
   	start=get_absolute_time ();   
   	//wait for echo pin to go low;   
   	while(gpio_get(ULTRASONIC_IN))   
   		;   
   	end=get_absolute_time ();   
   	//get clock difference   
   	us_delay=absolute_time_diff_us(start,end);   
   	//convert to float and return it as cm   
   	return (((float)(us_delay))*0.034/2);   
   	}   
      
   It would seem from the pin states that it gets permanently stuck in 	   
      
   while(!gpio_get(ULTRASONIC_IN))   
   		;   
      
   Which as understand it is waiting for the module (HCSR04) to *start* to   
   send a pulse.   
      
   Now obviously infinite loops with no termination condition under fault   
   conditions are poor code, but I am leaving it there until I understand   
   why the code is in fact hanging.   
   Someone online suggested that asynchronous interrupts may be the issue,   
   but I cant see why or what interrupts to disable.   
      
   Can anyone cast any light on this one?   
      
   Or suggest a bug hunting methodology?   
      
   --   
   “The fundamental cause of the trouble in the modern world today is that   
   the stupid are cocksure while the intelligent are full of doubt."   
      
       - Bertrand Russell   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)