Pico2 PicoMite v6.01.00b10 deadlock with command files "a:" from memory

PicoCalc
1

@pelrun @adcockm

During regression testing I ran into a deadlock situation that can only be solved by re-installing firmware on the Pico2.

I used https://github.com/pelrun/PicoMiteAllVersions (from today) (without changes) to generate “PicoMite_pico2.uf2” Next I used the edit command to create a test program with one line files "a:", closing the edit with F1. When I use runto execute the activity on I2C2 stops and the display shows “A:” on the top line. At that moment the PicoCalc is in a deadlock, the power button is inactive and a power reset does not recover. To recover the Pico2 has to be flashed with BOOTSEL. Sometimes this happens on the first try, if not, running another few times will cause the deadlock to be repeated.

One observance is that there is a longish delay before anything happens, this is most likely caused by saving the context before running. Initially I noticed the problem after starting a basic program from pcc.

2

Tested with a standard PicoMite RP2350 6.01.00RC2 build (not PicoCalc) and there is no issue

3

So it does seem to lock up for me if I use files in a program instead of live, regardless of whether I use a parameter of a:, b: or nothing. But a power-cycle gets me back to the prompt each time, no reflash needed.

Has files ever worked in a program?

4

I first noticed the problem using PCC when I tried to start a basic program, looking at the PCC source code I noticed that is uses save context therefor I used the files command because it shows the files. According to the documentation there is no restriction using it from within a program. I pulled out the original Pico1 (delivered with the PicoCalc) and ran the same test successful under V6.00.02RC23.

In the meanwhile I have done some more digging and found that the problem is most likely to do with Commands.c:SaveContext and Commands.c:RestoreContext. I removed all write and read statements from the routines and noticed something very strange. Running the same test many times will list the .vars and the bootcount files, after a few repetitions the bootcount file disappears.

Update: PicoMite RP2040 using the same source shows no problems.

Update:
V6.01.00b10 adcockm RP2040 no problems
V6.01.00b10 adcockm RP2350 no problems
V6.01.00b10 pelrun RP2040 no problems
V6.01.00b10 pelrun RP2350 fails

5

@pelrun

I have found where the problem occurs, I do not know how to fix it.

To test use the following program with a PicoMite RP2350 build from the pelrun sources. WebMite has not (yet) been tested.

For i=1 to 20
  Print i
  Save Context
Next

After 1 to 5 iterations the PicoCalc will hang, to recover the UF2 file has to be re-flashed. The builds from adcockm sources are not affected.

The function FileIO.c:392:fs_flash_erase calls the procedure flash.c:13:flash_erase. After a few iterations this procedure does not return.

Within the function there is the following:

if (ret != PICO_OK)
{
// need to debug all of these
while(1)
}

MMPrintString within this block did not fire.

6

Thanks for chasing that down - I put those traps in on purpose to catch any weird intermittent failure cases rather than let them silently cause issues, but it does require me to go in with the debugging tools to capture exactly what the failure is.

Will do that in a few days once I actually have a desk to put a computer on again.