Need help with PI PICO...

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