This one is strange.

FW 5.09.00b6.

I will try updating to FW 6.00.03

Is anyone aware of this odd behaviour?
I have some PM Standard running on WS RP2040-Zero modules.
The program runs perfectly.
It can run perfectly for MONTHS on end.
But at some point, the module seems to crash, and the HW Watchdog DOES NOT restart the module as it should.

Watchdog HW 8000 being used in the code, which is within the boundry for the HW watchdog.
When a module seems to "Crash" like this, you can't talk to it - the VCP is gone.
No amount of tinkering, changing USB leads or ports allows it to connect, and the VCP is REALLY gone, cos Windows does not even make the "USB connected" sound - either when you connect, or you disconnect.

I would have HOPED that the HW watchdog on the 2040, would have kicked the module back to life again, but it doesn't seem to do that.  I've had a handful of boards do this now, all identical boards, all using the same FW version - but with no predicatibilty to the lock-up.  It just happens at some random point, then the module is dead to the world.    

Power is good, volts good to module, but nothing responds anymore.
Press RESET on the module, or cycle the power, and away it goes again happy as Larry - until the next time, that is.

Am I wrong in my understanding, that the HW watchdog should be able to recover from this kind of thing, as it is a HW watchdog, and I am NOT relying on the software watchdog built into MMBASIC.

This is very odd, and at the moment, I don't have any real explanation for this, but it is a major problem, cos the units just stop working at random.

Anyone got any ideas?

As I say - I will upgrade to the later FW, and I am just praying to the tech-gods, that the fix is in there.  I've never really ever known a HARDWARE watchdog to fail.  I've seen software ones fall-over, but the HW one should be able to kick the module back into life, even if MMBASIC has crashed BADLY for some reason.....

---

Smoke makes things work. When the smoke gets out, it stops!

Hi Grogster,

Can you determine if the watchdog really caused it -or- that it failed to kick in in a watchdog situation (and failed to revive the system).

Another thing I can think of is when the ARM is doing USB (which is infrequent and short..so.. "rare") while the watchdog kicks in (it is hardware, so independent of what software is doing) the USB stack is killed at an unknown state.

To be honest, I would not really be able to help you. Since I mostly run leading edge firmware, and only have few picomite systems that I turn off after use. I did not ever implement watchdog, they reboot every time I use them.

Volhout

AFAIK the hardware watchdog fires a CPU reset whenever it's counter gets down to zero. It's using the normal chip clock and shares part of the divider chain, but otherwise it's isolated from the rest of the chip apart from when it's counter register is accessed.

How all that works into MMBasic I don't know. I can't see any obvious explanation for what you're seeing. :(

I do know the watchdog works on pretty old versions of MMBasic. I have one running on my old fish tank controller. Occasionally the lights go off, the watchdog triggers, restarts the system and the lights fade up again. I've been unable to trace the cause of the problem though. That's using a YD-RP2040 with, IIRC, 5.07.04 or something like that.

Is the the program also frozen or just the USB interface?

The module doesn't appear to have a heartbeat LED so perhaps add some code to change the colour of the WS2812 on each pass through the main loop to show if that is still running.

  Mixtel90 said  

I do know the watchdog works on pretty old versions of MMBasic. I have one running on my old fish tank controller. Occasionally the lights go off, the watchdog triggers, restarts the system and the lights fade up again. I've been unable to trace the cause of the problem though..

That is worrying !! I am not sure how big the risk is for the fish but try to run without watchdog. I think you have published an earlier version of your fish tank program. I could look at it. Is there any reason why this could happen ? Does it also happen without watchdog ? Or is the watchdog causing more problems then relief.

The only experiency I have with long running programs is with the "wet sock" humidity detector (ran 2 months), and the mains voltage analyzer (half a year). These have run (without watchdog, but also without USB) without problems.

Regards,

Volhout

P.S. When Mick experiences it in 5.07.04 and Grogster in 5.09.00b6 it may still not be brought to Peters attention. IF it is the same.
Edited 2025-10-06 18:15 by Volhout

Your symptoms suggest the MMBasic program is still running, hence no watchdog, but the RP USB device has got locked up somehow. You can prove this one way or the other by including in your program a MMBasic heartbeat driving the onboard WS2812.

Mick, Grogster,

Both your projects have one thing in common. Both use a Pico Zero.

Volhout

Not mine. It uses a YD-RP2040 Pico clone. The *next* version of the board uses a Zero. :)  I still haven't finished messing with the software for the new one, that's why it's not running. It keeps getting put back...

There's no risk to the fish as on the old version both the filter pump and heater have relays who's coils are simply switched to 12v, not under software control.

This is the board that had a Pico W in it originally. I never did manage to sort that out.
Edited 2025-10-06 23:21 by Mixtel90

Sorry,

I assumed you where running the NEXT version already. It's been a while since you published it.

Volhout

Yeah, well... it sort of got pushed to one side as life impinged on hobbies. Then my thoughts moved onto other ideas.  :)

I have the next system planned out and, once again, the heater is directly powered and the pump is on simple control. Basically it's a lighting controller, but more complicated this time. As I have the display and buttons there's a fair bit more to think about - there was no way to set times or anything originally, it needed a USB lead across the carpet!

Hi Mick,

You could use a wireless USB lead. I have 2 of these ESP8266-01 talking to each other without wireless connection.

Volhout

I haven't played with the newer MMbasic for the RP2040 still doing water controllers.

now sure how to read/write these registers.

Watchdog Reset:
A hardware-based reset that can be triggered by the watchdog timer expiring or by directly setting a trigger bit.

Scratch Registers:
The watchdog has eight scratch registers that retain their values across resets, which can be used for advanced debugging and booting.

Reason Register:
A register that indicates the cause of the last reset, allowing the system to determine if it was a watchdog-induced reset.

Control Register:
Controls the enabling and triggering of the watchdog timer.

hope this is of use
Quazee137
Edited 2025-10-07 00:17 by Quazee137

  matherp said  

Your symptoms suggest the MMBasic program is still running, hence no watchdog, but the RP USB device has got locked up somehow. You can prove this one way or the other by including in your program a MMBasic heartbeat driving the onboard WS2812.

  phil99 said  

Is the the program also frozen or just the USB interface?

No, the MMBASIC program has crashed or otherwise stopped, along with the VCP also.
None of the buttons that are supposed to do things when pressed, respond when pressed.

RESET the module, and away it goes again.

So, it's a hard-crash of some kind, but the watchdog is NOT firing to force the module to recover.  It's quite odd, cos it runs just fine for sometimes weeks on end(or months) before this happens....  Very strange.

MM2 chips are easy to get again now post COVID, so I might just design a wee module in the WS-Zero footprint, to replace the 2040, with the standard MM2 chip.  They NEVER gave any issues, but during the COVID chip shortages, I HAD to do something, and so used the 2040 chips and modules as you could get those!  

To conserve battery power, I am using "OPTION CPUSPEED 48000".
Could THAT be screwing with the HW watchdog somehow?

I have programmed up a module, with the latest FM(6.00.03), and added a routine to blink the WS2812 LED every second as a heartbeat.  That was a good idea, suggested by a couple of members, and I should have had that in place from day-1, really - I mean - the LED is right there on the module, why not use it.

I've also gone back to the software watchdog just for now, and will see what happens.
Edited 2025-10-07 10:13 by Grogster

Instead of just blinking the WS2812 LED you can get more information about where in the program it stops.
At 6 points in the program change it's colour. When running normally it should blur together and appear white while it will have a fixed colour when it stops. The problem will be between that colour change point and the next.
The colours most easily distinguished are red, yellow, green, cyan, blue and magenta.

If it stops at random places it may have nothing to do with the program but if the stopped colour is always the same there may be an issue in that section.

You could then move all the change points to that section to narrow it down further.
Edited 2025-10-07 13:56 by phil99

That's a clever idea!  

I have discovered that neither the HW watchdog, or the software one work if you slow the CPU clock down to 48000 - this is a problem.

Test code is in this image, but I set the software watchdog to 8000, then force a crash/bug via a divide-by-zero command.  The PM never restarts, with either the software OR hardware watchdog command.  It just sits there forever, and I can come back minutes later, and still access the console - but the watchdog is NOT firing(either type) with the CPU clock speed set to 48000.





EDIT: OK, Watchdog IS working if I replace the divide-by-zero command, with a simple DO:LOOP - that done, both the HW and the software watchdog work.  Both at the default CPU speed, and also at 48000.

But I thought that the watchdog was ALSO supposed to kick the CPU, if there was a bug in the code(such as my divide error) that dropped the code back to the command prompt?

That's the kind of error I need to trap - if the code runs into an error and drops back to the command prompt for whatever reason.
Edited 2025-10-07 14:27 by Grogster