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
18

UPDATE: from strong efforts of the diligent coders, I’m delighted to report the UF2 Bootloader and PicoMite/WebMite application work together as expected on the RP2W RP2350. Cheers!

2 Likes
19

When I type I2C2 CHECK &H20<ENTER> I get an error message
“I2C Keyboard not responding”

20

I am not surprised, there are many hidden problems in the I2C routines.
I2C, I2C2, keyboard and RTC all share a badly implemented I2C protocol and the shared use of MM.I2C.