Currently based off of PicoMite V6.01.00RC4.    

The PicoMite V6.01.00RC4D firmware is 100% compatible with the PicoMite V6.01.00RC4 firmware except it has the MMDebug module ready to wake up and help you with your debugging needs.

You must have a VT100 compatible terminal connected to the PicoMite in order to use the debugger.  Both Tera Term and MMCC are extensively tested and work with the debugger.   If you can get command prompts and issue commands to MMBasic, the debugger should be available.


PicoMite-v6.01.00RC4D_Documentation.zip


PicoMiteV6.01.00RC4D_Firmware.zip
Edited 2025-10-21 01:42 by EDNEDN

There seems to be a problem with uploading programs to the pico under RC4D. I tried to upload a larger program with about 1500 lines of code and it constantly terminates at the last line with

upload completed 201
***TIMEOUT***

and the pico is unresponsive, hardware reset needed. Program to upload is MMCC, latest version (from today).

I've tried to narrow it down a bit and found out this behavior is related to the enabling of PSRAM. As long as do not state

OPTION PSRAM PIN GP19

it loads and runs with RC4D.


Gerald
Edited 2025-10-21 18:52 by ville56

Gerald

You need to test on the normal release and if there is an issue report on that thread. Only if that works should you report an issue here with the clear comment that it is a specific debug version problem. In the specific case you raise you should also test with teraterm to confirm the issue.
Edited 2025-10-21 18:56 by matherp

Peter,

you are right. Of course I did test with RC4 and RC4D to find out if there is a difference. It worked with RC4 which I didn't mention.

But your point to test with Teraterm was important. So RC4D works with Teraterm XMODEM but doesn't quite with YMODEM. It hangs with the send window open after almost 100%. Pressing "Cancel" and then LIST reveals that the program has been transfered correctly.

Summing up my 5 cents:
- RC4D and MMCC seem to have an issue with larger programs (in my case >50 kb) if PSRAM enabled.
- XMODEM transfers without any issues on RC4 and RC4D.
- YMODEM transfers blazingly fast but Teraterm hangs on the "closing part" of the transfer on a larger prog. This applies to RC4 and RC4D.

Gerald

Gerald
Please confirm
transferring from the PC to the Pico?
transferring to memory or to a file (if file which disk)?
if memory, does it work to a file OK?
thanks

Also, you can try this version and see if any different

PicoMite.zip
Edited 2025-10-21 20:28 by matherp

  ville56 said  

Peter,

you are right. Of course I did test with RC4 and RC4D to find out if there is a difference. It worked with RC4 which I didn't mention.

But your point to test with Teraterm was important. So RC4D works with Teraterm XMODEM but doesn't quite with YMODEM. It hangs with the send window open after almost 100%. Pressing "Cancel" and then LIST reveals that the program has been transfered correctly.

Summing up my 5 cents:
- RC4D and MMCC seem to have an issue with larger programs (in my case >50 kb) if PSRAM enabled.
- XMODEM transfers without any issues on RC4 and RC4D.
- YMODEM transfers blazingly fast but Teraterm hangs on the "closing part" of the transfer on a larger prog. This applies to RC4 and RC4D.

Gerald

It has changed about 15 releases before: I need to increase the linedelay to 50ms that it gets transferred with Autosave method.

That is on 2350HDMIUSB with a standard USB converter
Compared to a 2350VGA where I can use 25ms.
On LCD SSD1963 which is fast enough I can transfer on 2350USB even _with_ enabled
Option lcdpanel console with 25ms permanently error free.

I didn't check with VGAUSB

Hope that helps


edit:
On the other hand side 2350VGA always crashes when there is an overflow in keybaord buffer. That happens only for keys with ESC sequence like cursor up/down
Then the sequence gets not interpreted correctly and Pico crashes.(or leaves rests when editing like "[") Edit: starting with souce > 40Kb
This happen also in Editor. Hitting the bottom line and is is a question of time in seconds that it freezes

That all doesn't happen with USB converter
Edited 2025-10-21 20:59 by dddns

I think it has to do with line continuation feature

Edit: Forgot to say, all my experience is based using Putty or Xterm/cu on Linux

Transfer with
Edited 2025-10-21 21:15 by dddns

First part of my answers:

- transferring from the PC to the Pico?
 o PC to Pico

- transferring to memory or to a file (if file which disk)?
 o to memory

- if memory, does it work to a file OK?
 o will test that later today

will also test the attached build then

Gerald

Peter,

forget all the details so far .... they are all secondary symptoms, I think.

I suppose that the MMCC upload is appearantly spoiling the COM-port on the Pico (usb) side.
- After a hang, the port is visible in Windows, but seems not to respond to a connect request, an app connecting to the port just hangs and must be killed.
- After a HW reset, the port can be connected and the pico responds like normally but the uplouad via ymodem hangs on finishing.
- After a power-cycle all runs as expected.

addendum:
just tried to disconnect the hanging usb port softwarewise with "USB Device Tree Viewer". The app also hangs at startup and only proceeds when the Pico USB port is physically disconnected. So I guess that something in the Pico USB port on the Pico side gets spoiled. And this occurs exactly at the end of the transfer. Maybe something is overwritten ....

Gerald

  ville56 said  

addendum:
just tried to disconnect the hanging usb port softwarewise with "USB Device Tree Viewer". The app also hangs at startup and only proceeds when the Pico USB port is physically disconnected. So I guess that something in the Pico USB port on the Pico side gets spoiled. And this occurs exactly at the end of the transfer. Maybe something is overwritten ....

That is good information.   There is one errata I know about on the MMDebug version of the firmware.    If you 'abuse' the '<' and '>' keyboard buttons, you can lock up the PicoMite.  It is a random buffer overflow problem.   And it only happens when there is a lot of keyboard (repeat) traffic at the same time the screen is getting repainted with lots of activity.

I traced the failure into the USB stack and decided to leave the issue alone because I didn't want to make any changes to the USB software stack and affect the 100% compatibility.   MMDebug uses the exact same serial character routines for input and output that MMBasic use.  And MMBasic doesn't have that errata.   But maybe with XModem and YModem that statement isn't true?  

Anyway...    If you bring up the debugger screen and just lay on the '<' and then the '>' keyboard shortcut, you will eventually be able to lock up the PicoMite.  Just push the border back and forth for a minute or two and you will probably get the lockup I'm talking about.   And the lock up is happening deep inside the USB code.

I think there is a fair chance that might be what we are seeing with the XModem and Ymodem problems.
Edited 2025-10-22 02:38 by EDNEDN

latest finding:

seems to be related to the hardware. I've changed from RP2350-plus with psram soldered atop the flash to an Olimex pico2-xxl with presoldered psram and I can't reproduce the problem. Maybe something has changed in the psram timing sometimes in the course of V6.01.00 development. With the RP2350-plus it can be reproduced consistently as soon as psram is enabled. I didn't check for the latest version that was working on the RP2350-plus HW. At least beta 13 did.

Sorry to bother you .....

Gerald

  ville56 said  

Sorry to bother you .....

No Problem!!!  Also...  Just so we are all on the same page...   I have seen very similar USB connect and disconnect problems as what you described up above.   I have seen them with the standard PicoMite firmware and the 'D' version.

Sometimes when I flash new firmware to the PicoMite, the firmware gets loaded, but the VT100 terminal program I'm using can't connect to the PicoMite.   It can see that there is a Serial USB connection available, and it even thinks it is connected, but there is no data transfer.

Here is the weird thing:    If I set aside whatever VT100 terminal program I'm using and switch to another one, magically the connection gets made and starts working.

Once again...   this problem is deep in the USB firmware stack.  It would be good if we can fix it for the PicoMites, but I'm hesitant to do it for the Debug version because I'm trying to keep 100% compatibility.  

There are definitely some bugs hiding in the SDK-USB code.

USB isn't brilliant on any platform. Windows is well known for strange things going on with USB. There's just too much stuff going on in it, it's the best solution we have though.

  Mixtel90 said  

USB isn't brilliant on any platform. Windows is well known for strange things going on with USB. There's just too much stuff going on in it, it's the best solution we have though.

Yes...   This is all true.   And then you compound the situation by trying to make the USB stack as small and fast as possible (to fit into the Pico-SDK), you know there are going to be problems.

Updated version of MMDebug based off of PicoMite V6.01.00RC5.

- Debug Window resizing is much more stable.  

- XModem and YModem transfers are much better behaved.

- Documentation update suggesting a preference of using V5.3.4 of MMEdit over earlier releases.


PicoMite-v6.01.00RC5D_Documentation.zip


PicoMiteV6.01.00RC5D_Firmware.zip
Edited 2025-10-23 07:57 by EDNEDN