Re: Need help with PI PICO...

On 24/03/2024 07:23, Ahem A Rivet's Shot wrote:

On Sat, 23 Mar 2024 22:20:34 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
 

On 23/03/2024 18:37, Ahem A Rivet's Shot wrote:

 

Assuming you have access to the source of gpio_get() instrument
the inside of it with tracers (I'd use printf if there's anything
listening to stdout - otherwise find somewhere to put breadcrumbs that
you can see in real time (in ancient times I'd just watch the
blinkenlights). Wait for it to lock up and see what it's doing.
>

Well I did. That's how I got this far.

  Instrument /Inside/ gpio_get().

gpio_get (X) for presumably memory mapped IO is going to be little more than
           return (iobase & (1<<X ) ? 1:0);
However I found something i had forgotten...

 

I know it enters the routine, but never leaves, and the lack of GPIO
voltage suggest it is being stuck where it is.

  Right so the next step is the inside of the routine.
 

Alternatively run it under strace or similar and wait for it to
lock up or wait for it to lock up and attach gdb (you'll want to compile
with -g for that).
>

AIUI those are linux tools.

  Unix tools but yes.
 

We are running bare metal-ish here.

  Ah - no way to attach a debugger via the SDK ?
 

There may be but it would be more complex.

Back in the day I would have used a chip emulator with hardware break
points.

  An ICE is always nice if someone else is paying :)
 

Precisely!

It's odd, it may be something to do with short ultrasonic distances.  I
have the PCB just lolling around on the desk, and facing a wall a few
inches away seemed to make it crash moire predictably

  Hmm is there a minimum range spec ?
 

Not really  in practical terms.
However on trawling the internet I discovered a conversation  with someone else *on here* (c.s.r-pi) last year, who was finding that *sleep_us(x)* was highly inconsistent for certain (small) values of x. Sometimes taking a day to end.
Further investigation reveals that in fact it really is a 'sleep' with the processor being put in low power mode and requiring an interrupt to 'wake it up'.
I haven't thought it through, but it could be that too long a delay in some sense might miss a complete set of send and return pulses, leaving the thing stuck. Especially on a very short range echo.
So last night instead of leaving it facing a wall, I left it facing the opposite wall, and it's still blinken away...
There is an alternative to sleep_us, that simply involves a tight processor loop watching the clock, that might work better for these very small delays.
I am going to do a statistical test on both methods at long and short ranges.
(Fortunately, I managed to remove the existing radio sensor from the oil tank and on shaking, could hear water sloshing around inside. After emptying out and drying n the oven, it started working again. I don't think +60°C made it very accurate as it then showed a full tank, but it seems to have settled down to a figure consistent with what a dipstick shows. So there is no urgency to get the replacement PI sensor  working:-)
I am getting to really love these little PICOS, but there are a lot of quirks and bugs in the hardware and software.
Thank's for your input.
--
  “A leader is best When people barely know he exists. Of a good leader, who talks little,When his work is done, his aim fulfilled,They will say, “We did this ourselves.”
― Lao Tzu, Tao Te Ching