RP2W RP2350 PicoMite troubleshooting

PicoCalc
1

Hello,

I am using RP2350 with PicoCalc UF2 Loader version 2.3.

After loading PicoMite screen stays black.

I was trying both original clockwork PicoMite version V6.00.02RC23 and madcock version V6.00.03 for RP2.

I am able to load other UF2 files like frotz, terminal, rogue.

Somewhere on the forums it is mentioned that flash_nuke.uf2 can help, it did not.

There is a pull request from pelrun into madcock repo, did anyone try to build and check if that works?

Any idea on how to troubleshoot this?

Thanks,

wakeup

1 Like
2

This is a known issue. There were mentions of working on a fix but I havenā€™t seen it mentioned in a while.

3

Software which expects to write to the full flash on the board such has Picomite/Webmite, MicroPython, and my own zeptoforth generally do not play nice with the UF2 loader, because they are apt to corrupt the UF2 loader in flash.

4

My PR is the fix, thereā€™s nothing to troubleshoot. I suppose I can put a build up on my fork until madcock makes another build himself.

1 Like
5

Sorry Iā€™ve been absent lately. I still havenā€™t merged your changes into the fork cleanly, but thatā€™s partly because Iā€™ve spent the time I had using it.

There are things to troubleshoot. :wink:

While Picomite will build with your forkā€™s changes using set(COMPILE PICORP2350), WebMite doesnā€™t build with those changes, by commenting the PicoMite compile line, and using set(COMPILE WEBRP2350). I think it has to do with the way the original source for WebMite uses the cores. Itā€™s been a little while since I tried to build it, but I should probably post the build error and some comments on github. It had to do with the multicore related code.

As for PicoMite, while it does boot up, and mostly works, Iā€™ve seen some erratic behavior I havenā€™t been able to nail down regarding flash access. Several times now, Iā€™ve had it get into a weird state where I canā€™t boot it again, and Iā€™m pretty sure it has to do with saving code in one of the autoboot flash slots and then something bad happening when the autorun triggers shortly after boot that causes it to get locked in a reset loop with a fatal error. The really weird thing is that it continues to have that problem if I load PicoMite again from the u2floader, and the only way Iā€™ve been able to get it back working again was to nuke everything and start over.

Saving OPTION commands to flash seems to work ok though. Saving those same options to disk and then restoring them later to flash also seems to work, but I had one time where it got into the reset loop again, though it might have been caused by something else. In a general sense, if someone doesnā€™t mind using PicoMite ā€œblankā€ each time, then it seems as solid as the non-u2floader version. I did have it just randomly reset on me once after running a program, but that could have just been natural PicoMite weirdness and instability.

The mainline sources have seen some updates that I havenā€™t merged in and tested yet too. But based on the discussion on TheBackShed it sounded like for a time there was file corruption going on, and I didnā€™t want to mess with those changes until something less likely to cause problems was available. Also didnā€™t sound like many of the changes going on would be useful for the PicoCalc build anyway. And like always while there were some fixes for bugs, there were new bugs created, and itā€™s not clear whether itā€™s worth updating or not.

At this point Iā€™m not very enthusiastic about PicoMite in general, but I still think it would be good to get something relatively stable (for both PicoMite and WebMite) working with the u2floader, if possible. Then everyone can decide for themselves if PicoMite/WebMite is worth using.

2 Likes
6

The uf2loader will only overwrite the core picomite application, it doesnā€™t wipe the rest of the flash - so anything still present in the picomite option or program storage (including a buggy autorun program) will persist. I think I need to add a key combo in the menu for clearing the app partition fully.

Iā€™ll have a look at the webmite build. The CMakeLists.txt is as cursed as the rest of the codebase, which means I want to fix it but I also donā€™t want to maintain it. Iā€™m tempted to just write a clean new one that handles the builds we care about.

7

and I2C.

I fully agree with you, at the moment I am trying to find the reason why the I2C bus does not perform as expected with PicoMite. There is another big problem hiding in the code which makes I2C difficult (or impossible) to use under Basic.

1 Like
8

Having a way to clear out the flash like that in an ā€œemergencyā€ would be helpful.

Regarding the CMakeLists.txt, someone else made an attempt to clean it up and submitted a PR back to the mainline repo, but Peter basically told them to piss off. Might be worth looking at if it saves you some effort.

While Iā€™ve tried to keep the code changes clean to make future merges easier, the makefile might be a useful exception. It already needs to be different for the PicoMite build, and while I kept the changes minimal for it too, Iā€™ve never been happy with my hack on top of the existing mess. Itā€™s also something that Peter doesnā€™t seem to change that often. Iā€™m totally on board with your cleanup of the hacks that were required for the SDK files as well (gpio.c etc.) That was probably the worst thing in the original repo since it affected anything else built with the SDK and basically assumed no one would ever want to build anything other than PicoMite, or if they did, theyā€™d have to maintain two separate SDK insatllations. And like the makefile, itā€™s something that probably wonā€™t change from upstream that often.

1 Like
9

It is interesting that the original programmer of MMBasic wrote it because he needed a Basic interpreter, but the Bywater Basic interpreter he wanted to use was a mess, so he wrote his own. Now here we are more than a decade later discussing what a mess the child of MMBasic, PicoMite Basic is.

10

I contacted Peter by PM on the backshed where I lurk. The reason he said he didnā€™t accept the cmake change was that it broke it. He said he does this for fun and hasnā€™t got the time or inclination to enter into discussions on github as to why a change isnā€™t correct. Easier to just nack it.

I also questioned the sdk issue and the response was that originally all the changes were to apply individual bug fixes that were in the sdk github development branch but were needed to fix current MMbasic issues. He did accept that the change to gpio.h shouldnā€™t have been done and should have been in the main firmware even though it was part of a workaround for E8. He said the single change to gpio.c is to lock the gpio interrupt handler into ram and that this was needed for various time critical events.

11

I really enjoy programming in BASIC. It had been decades since I last did it, and Iā€™m having a lot of fun with it again.
I also think UF2 Loader is an amazing tool ā€” itā€™s a pity that MMBASIC (or whatever name it goes by) isnā€™t compatible with it.

Question: how difficult would it be to fix a version of this BASIC so that itā€™s stable, compatible with UF2 Loader, and then ā€œfreezeā€ the development at that point (at least for now)?
Or, alternatively, start a new development branch based on that ā€œfrozenā€ versionā€¦

1 Like
12

Seriously, DO NOT contact him, and donā€™t post on thebackshed about picocalc/picomite. Peter is being completely disingenuous when he says ā€œitā€™s easier to nack than to deal with broken PRā€™sā€ - he literally has said on multiple occasions that he accepts no changes of any sort, and his existing code is so incredibly bad that he has zero credibility in judging other peopleā€™s code. He doesnā€™t even try to improve his own code. He just writes more shit.

It must be some weird ego thing, and there is no way to interact with him where he will act in good faith. So just donā€™t.

13

Iā€™m having no problem with i2C under Picomite ??. Currently daisychaining four devices, and adding more soonā€¦. RTC, FRAM, temp/Humid, accelerometer/magnetometer, 5-port adaptorā€¦.

No issues so far. For example FRAM writing 1084b/s (bytes per second) at the default 10Khz bus speed, zero errors.

20250930_200656
20250930_2006561221Ɨ2086 408 KB

14

  1. type I2C2 CHECK &H20<ENTER> followed by ? MM.I2C<ENTER>, the expected result should not be 0, note that MM.I2C is common to I2C and I2C2

  2. LIST SYSTEM I2C , repeat this a few times and notice that phantom devices are listed.

see above

15

Iā€™m aware of that issue, possibly a side effect of modifying the original Picomite for Picocalc use (or clashes with the STM32).

Yet writing and reading from my devices is 100% error free at over a kilobyte per second and Iā€™m happy of course. You are talking of one buggy command that isnā€™t of use during normal direct i2C device communicationā€¦..

16

Works like a charm.

Thank you!

17

I think the bootloader is a wonderful utility and I would love to see it work with the PicoMite/WebMite application. It would be a shame if the utility could not support the application that I originally bought to use with the PicoCalc. Hopefully we can get these two working together, to really expand the device functionality!

2 Likes