 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PicoMite V6.01.00D release candidates
| Author | Message | ||||
| EDNEDN Senior Member  Joined: 18/02/2023 Location: United StatesPosts: 229 |
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 |
||||
| ville56 Senior Member Joined: 08/06/2022 Location: AustriaPosts: 262 |
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 73 de OE1HGA, Gerald |
||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10531 |
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 |
||||
| ville56 Senior Member Joined: 08/06/2022 Location: AustriaPosts: 262 |
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 73 de OE1HGA, Gerald |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10531 |
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 |
||||
| dddns Guru Joined: 20/09/2024 Location: GermanyPosts: 673 |
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 |
||||
| dddns Guru Joined: 20/09/2024 Location: GermanyPosts: 673 |
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 /pico_upload.sh;ascii-xfr -s %f -l 25 Edited 2025-10-21 21:15 by dddns |
||||
| ville56 Senior Member Joined: 08/06/2022 Location: AustriaPosts: 262 |
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 73 de OE1HGA, Gerald |
||||
| ville56 Senior Member Joined: 08/06/2022 Location: AustriaPosts: 262 |
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 73 de OE1HGA, Gerald |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 229 |
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 |
||||
| ville56 Senior Member Joined: 08/06/2022 Location: AustriaPosts: 262 |
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 73 de OE1HGA, Gerald |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 229 |
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. |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8232 |
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. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 229 |
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. |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 229 |
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 |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
