Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: The Natural Philosopher <tnp@invalid.invalid>
Newsgroups: comp.sys.raspberry-pi
Subject: Need help with PI PICO...
Date: Sat, 23 Mar 2024 17:45:05 +0000
Organization: A little, after lunch
Lines: 63
Message-ID: <utn4f2$3p985$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: dont-email.me; posting-host="02773e8b0c26e99995a7aebdd3f578a7";
	logging-data="3974405"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/qswn1epu6PYqwMJAWIF47ntiY3QVHTxo="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:SiEm1q4ZU68WVxbSrn7de9OiJfg=
Content-Language: en-GB
Bytes: 2966

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