| Menu | JAQForum Ver 19.10.27 |
| Menu | JAQForum Ver 19.10.27 |
Forum Index : Microcontroller and PC projects : PicoMite V6.01.00 release candidates
  Page 6 of 9   |
||||||
Jan You will have to stick with RC5 until I get home as I don't have access to a pico(2)-w |
||||||
Peter, Thanks for your message. I'm not in a hurry and can still move forward with V6.01.00RC3. I've looked further. The problem arose earlier, namely after version V6.01.00RC3. V6.01.00RC4, V6.01.00RC5, and V6.01.00RC6 have the same problem for the RP2040 and RP2350 WebMite modules. Regards, Jan. |
||||||
ignore Edited 2025-10-24 04:03 by matherp |
||||||
Peter and Gentlemen, Sorry, forget my reset complaint above. The problem was a hardware issue on my end. The USB cable was the problem, and I can now load the WebMite V6.01.00RC6 firmware onto the RP2040W and RP2350W modules without any problems. To be safe, I used the universal flash_nuke.uf2 (96 kB) for RP2040 and RP2350 for both modules, and put a new USB cable and the old cable in the gray bin. Have a nice evening, Jan. |
||||||
@Peter, The filemanager miniFM uses current font information, and reserved variables as MM.HRES to determine the screen format. Below is tested on RP2040 VGA PS2, and in both cases there was no console connection (that could have impact at screen settings). Attached are 2 screenshots of b20, and RC6, starting from a virgin system, where all OPTION's where set identical, and no prior program where run (that could impact font or resolution). b20 (correct screen buildup)  RC6 (screen is misaligned, width is incorrect, height is incorrect).  I have tried this with several versions of the filemanager. Versions that all operate correct with b20. Volhout |
||||||
For this MMBasic program the results are about the same as PicoMite V6.01.00RC5 On the 2040 WebMite it locks up using TeraTerm in under 20 seconds. Just press down and hold either the < or the > key on the keyboard and move the token back and forth on the line for 30 seconds. a$ = "=========================================================" r$=chr$(13) l = len(a$) cnt = 1 cnt2 = 1 Top_of_loop: b$ = left$(a$,cnt) + "|" + right$(a$, l - cnt) print cnt2;b$; " ";r$; Print cnt2;b$; " ";r$; print cnt2;b$; " ";r$; print cnt2;b$; " ";r$; print cnt2;b$; " ";r$; cnt2 = cnt2+1 c$ = inkey$ if c$ = "<" then cnt = cnt - 1 if cnt < 2 then cnt = 1 endif if c$ = ">" then cnt = cnt + 1 if cnt > l-3 then cnt = l-3 endif goto Top_of_loop Edited 2025-10-24 08:53 by EDNEDN |
||||||
EDNEDN, Thanks for the test program. I got the same result. Indeed, there's an improvement when using the arrow keys, and I try to use them as little as possible to prevent crashes. I use the mouse, Pg Up, Pg Down, and F1 a lot during editing. But I think we'll have to make do with this. Will an update to the Pico SDK bring improvement? Or will Peter come up with an improved solution? Regards, Jan. |
||||||
I suspect there is a buffer overflow or data corruption problem happening down in the SDK's USB code. RC5 did not touch anything down in the SDK. But the extra flushes it did definitely made things better. The good news is we have a reliable way to create the issue. So that helps a lot when trying to fix the problem. And the USB code isn't that big. I think somebody is going to be able find why things are getting locked up. Interestingly enough, the heartbeat LED never stops blinking even though the USB stack seems to be dead. |
||||||
@EDNEDN, Your test program is definitely overflowing the USB, as intended. A PAUSE 2 in the loop is sufficient to prevent the lockup. The issue with USB lack of flow control has been a problem since the beginning. Peter has looked at this without any simple solution. TeraTerm can keep up but MMCC can not. That is why there is a few seconds delay with the < > keys. I also get a few dropped characters. MMCC polls the serial every 50mS by default. I think the slow response in MMCC actually helps in this case but it is definitely worth preventing programs from flooding the USB. The occasional PAUSE will do wonders. Jim @Peter, RC6 looks good to me. |
||||||
Just flooding the buffers is 1/2 of the equation. The lockup also requires keyboard traffic going the opposite direction. Somehow, this Criss cross of traffic with the buffers full is a problem. I don't have a SWD device setup. And it is a fairly heavy lift to get GDB running on the PicoMite builds. I was hoping to avoid that. But maybe I have to bite the bullet and do that. Yes. That is why I specified Tera Term. It looks like MMCC has a pretty deep buffer. That kind of frustrates knowing the exact status at the moment, but it doesn't keep the situation from happening. Even with a MMCC client, the lockup in the Pico-SDK happens. Understood and agreed! The problem is a lot of information needs to be updated and communicated. In order to give the user a 'good experience' repainting the screen quickly is part of the recipe. Slowing things down can prevent the lockup. But I'm hoping we can find a couple line change down in the Pico-SDK so the user can have instantaneous screen refreshes. I've worked around the issue so far. Really??? The only time it has been unpreventable is when the user abuses the screen resize commands. If the user lays on the '<' or the '>' commands to expand or shrink the debug window size it works for a while. But it will eventually lock up. @matherp gave a list of requirements in order for MMDebug to be eligible to merge into the MMBasic code base. One of them is that the code is 'stabile'. So I'm caught in a Catch-22. Pretty much everywhere else in MMDebug's operation I've worked around the Lock Up problem. But so far, I haven't been able to work around the Lock Up on the Screen Resize. And the bug isn't even in my code. So I have a couple of choices. I could put a 100 millisecond delay after any screen resize to keep the problem from happening. Or I can hope the problem gets fixed in the Pico-USB stack. |
||||||
I get massively lockups with _NON_ USB versions. Just tested PicoMiteRP2350V6.01.00RC6 without anything but SDcard configured and: Cursor up/down and Page up/down are causing PicoMite to crash in internal editor and in the application FM where inkey$ is used plus there is disk access. In internal editor it happens when a program is longer than about 50Kb. At some point when scrolling down and thus keep pressing cursor down, the listing begins to slow down. Once it slows down it begins to leave rests of escape sequences in the program editing. If I keep on holding down it will crash for sure. I'm using Linux and I think that's why I'm the only one with this problem: With Putty under Linux I don't get these lockups that often. I get them when I use Xterm/cu as terminal emulation. And it locks up, when I accidentally upload with Autosave and FM is running listening with inkey$. But never with Autosave itself But I think whatever input comes through serial, it should never crash. I rather live with this problem than using anything else but Xterm/cu USB on the other hand side never crashed for me. On 2350HDMIUSB I can't upload via Autosave faster than 50mSec linedelay. This has changed since some releases ago. But this is my only problem with serial over USB Edit: if I upload with 25mSec it transfers but program is scrambled on lines >220 (about) characters In the past months I uploaded complete error free up to 500Mb in about 1500 times. I recalculated. Since 2350HDMIUSB has this problem with linedelay, I don't use it anymore Edited 2025-10-24 18:03 by dddns |
||||||
Linux does have problems with time-critical stuff. You can't just go stopping its interrupts as it depends on them. It's not the fault of Linux, it's up to the task to behave itself when running on a multi-user OS. :) |
||||||
Hi dddns, Is your problem with non usb different on b20? Volhout Picomite usb had problems before, and over the years people have found wars around these (line delays, use autosave versus XMODEM ). When things have eroded recently, it may be possible to reverse charges to a version that did not have the degradation. That happened once before. Edited 2025-10-24 19:02 by Volhout |
||||||
Hello Volhout, b20? Do you mean PicoMiteRP2350USBV6.01.00b20 ? If you are talking about this version it's very likely that it is fine again. Have to try..please confirm |
||||||
V6.01.00RC7 PicoMiteV6.01.00RC7.zip New functionality AUTOSAVE N This runs autosave as normal but does not echo the data back to the console. It waits for the first character to be sent and then uses a timer that checks for greater than 100mSec between characters. If it sees this delay it switches back to normal input mode and outputs the message You can then type additional characters to be saved or use one of the normal exits. This has been tested on standard PicoMite variants (USB-CDC) where in teraterm a paste delay per line of 1 mSec is required and transmit delays can be set to zero. On USB host variants it has been tested on my HDMIUSBI2S reference board with a baudrate of 460800 baud and all delays in teraterm set to zero. In this case transfer is almost instantaneous and appears completely reliable. Current status: Fixes silly bug introduced that Volhout reported WEB version issue reported by JanVolk confirmed as non-issue Possible cross talk between GP27 and GP28 reported by dddns - awaiting test by me Changes USB CDC polling interval from 1000uS to 400uS. This definitely improves performance of the RP2040 on EDNEDN's test program although this will be at the expense of a slight performance hit. I could go lower but it ran the test for me until I got bored (I get bored easily) I've tested non USB CDC variants (HDMIUSB) and I get no issue with teraterm on w11 set to a 20mSec paste delay per line (transmit delays set to zero) uploading large files with autosave (tested with miniFM and solar_eclipse @ 115200 or 230400 baud). This is the delay setting that I have always used and never had to change. I can't be responsible for other OS/terminal programs giving issues. Nothing has changed in this area of the code since forever. |
||||||
Hello, I thought of crosstalk too, then discarded this and thought it could be the different PWM channel 7 instead of 5. Now I found with 2350VGARC7 after a quick test, that reconfiguring VGA Pins to gp32,gp34 brings the error. Leaving them on default and it runs fine and no crashes with FM any more. In internal editor I had 1 left"[6" when scrolling through 40Kb source but no freeze I tinkered now a lot and have had sometimes the impression, that using pins gp30,31,32 maybe 33 can be a problem..could it be? |
||||||
@Peter, The 2040 VGA PS2 screen issue is fixed, thanks. The USB polling (1ms->0.4ms) is a performance impact of 5%-10% on 2040 (impact frame rate in games/logic analyzer averaged). In case it does not fix anything for the people that have issues with USB, I would love to see it reverted. But only when it doesn't fix anything. I have not tested RC7 on GameMite, but on 2040 VGA it runs fine. Volhout EDIT: RC7 tested on both Game*Mite 2040 and Game*Mite 2350, but no issues found. Edited 2025-10-25 04:58 by Volhout |
||||||
I'm trying to compile the RC7 firmware from UKTailwind's GitHub. I've downloaded and installed the SDK and made the changes to the SDK per instructions. When I start the make, I get this: In file included from /home/tom/picocalc/PicoMiteAllVersions/MMBasic_Includes.h:32, from /home/tom/picocalc/PicoMiteAllVersions/PicoMite.c:40: /home/tom/picocalc/PicoMiteAllVersions/MMBasic.h:284:35: error: 'MAXSUBFUN' undeclared here (not in a function) 284 | extern struct s_funtbl funtbl[MAXSUBFUN]; | ^~~~~~~~~ /home/tom/picocalc/PicoMiteAllVersions/PicoMite.c:237:73: error: 'FLASH_TARGET_OFFSET' undeclared here (not in a function); did you mean 'TARGET_OFFSET'? 237 | const uint8_t *flash_option_contents = (const uint8_t *)(XIP_BASE + FLASH_TARGET_OFFSET); | ^~~~~~~~~~~~~~~~~~~ | TARGET_OFFSET In file included from /home/tom/picocalc/PicoMiteAllVersions/PicoMite.c:34: /home/tom/picocalc/PicoMiteAllVersions/configuration.h:255:23: error: 'HEAP_MEMORY_SIZE' undeclared here (not in a function) 255 | #define MAX_PROG_SIZE HEAP_MEMORY_SIZE | ^~~~~~~~~~~~~~~~ /home/tom/picocalc/PicoMiteAllVersions/configuration.h:491:39: note: in expansion of macro 'MAX_PROG_SIZE' 491 | ((MAXFLASHSLOTS) * MAX_PROG_SIZE)) | ^~~~~~~~~~~~~ /home/tom/picocalc/PicoMiteAllVersions/PicoMite.c:240:68: note: in expansion of macro 'PROGSTART' 240 | const uint8_t *flash_progmemory = (const uint8_t *)(XIP_BASE + PROGSTART); | ^~~~~~~~~ /home/tom/picocalc/PicoMiteAllVersions/PicoMite.c: In function 'main': /home/tom/picocalc/PicoMiteAllVersions/PicoMite.c:5171:32: error: 'MIN_CPU' undeclared (first use in this function) 5171 | Option.CPU_Speed < MIN_CPU || Option.CPU_Speed > MAX_CPU || | ^~~~~~~ /home/tom/picocalc/PicoMiteAllVersions/PicoMite.c:5171:32: note: each undeclared identifier is reported only once for each function it appears in /home/tom/picocalc/PicoMiteAllVersions/PicoMite.c:5171:62: error: 'MAX_CPU' undeclared (first use in this function) 5171 | Option.CPU_Speed < MIN_CPU || Option.CPU_Speed > MAX_CPU || | ^~~~~~~ /home/tom/picocalc/PicoMiteAllVersions/PicoMite.c:5174:31: error: 'MagicKey' undeclared (first use in this function) 5174 | !(Option.Magic == MagicKey)) | ^~~~~~~~ /home/tom/picocalc/PicoMiteAllVersions/PicoMite.c:5490:32: error: 'MES_SIGNON' undeclared (first use in this function) 5490 | strcpy((char *)banner, MES_SIGNON); | ^~~~~~~~~~ make[2]: *** [CMakeFiles/PicoMite.dir/build.make:76: CMakeFiles/PicoMite.dir/PicoMite.c.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1819: CMakeFiles/PicoMite.dir/all] Error 2 make: *** [Makefile:91: all] Error 2 tom@TOM-HOME-PC:~/picocalc/PicoMiteAllVersions/build$ Footnote added 2025-10-25 10:51 by toml_12953 I managed to compile it now. I don't know what the problem was! Since I have a good WebMite compile, though, I'm not going to go looking for what I did wrong. |
||||||
What am I doing wrong here, or is this a mistake? > option list PicoMiteHDMI MMBasic USB RP2350A Edition V6.01.00RC7 OPTION SERIAL CONSOLE COM1,GP0,GP1 OPTION FLASH SIZE 4194304 OPTION COLOR CODE ON OPTION KEYBOARD US OPTION RESOLUTION 640x480 @ 252000KHz OPTION HDMI PINS 1, 3, 7, 5 OPTION SDCARD GP22, GP6, GP7, GP4 OPTION AUDIO GP26,GP27', ON PWM CHANNEL 5 OPTION MODBUFF ENABLE 192 OPTION PLATFORM OLIMEX USB > option resolution 800 > option list PicoMiteHDMI MMBasic USB RP2350A Edition V6.01.00RC7 OPTION SERIAL CONSOLE COM1,GP0,GP1 OPTION FLASH SIZE 4194304 OPTION COLOR CODE ON OPTION KEYBOARD US OPTION RESOLUTION 800x600 @ 360000KHz OPTION DISPLAY 50, 100 OPTION HDMI PINS 1, 3, 7, 5 OPTION SDCARD GP22, GP6, GP7, GP4 OPTION AUDIO GP26,GP27', ON PWM CHANNEL 5 OPTION MODBUFF ENABLE 192 OPTION PLATFORM OLIMEX USB > files A:/ Error : Not enough Heap memory > option resolution 640 > option list PicoMiteHDMI MMBasic USB RP2350A Edition V6.01.00RC7 OPTION SERIAL CONSOLE COM1,GP0,GP1 OPTION FLASH SIZE 4194304 OPTION COLOR CODE ON OPTION KEYBOARD US OPTION RESOLUTION 640x480 @ 252000KHz OPTION HDMI PINS 1, 3, 7, 5 OPTION SDCARD GP22, GP6, GP7, GP4 OPTION AUDIO GP26,GP27', ON PWM CHANNEL 5 OPTION MODBUFF ENABLE 192 OPTION PLATFORM OLIMEX USB > files A:/ <DIR> . <DIR> .. After this everything went back to normal. |
||||||
It has changed in b11. You need PSRAM to use files command in Resolution 800 |
||||||
| Page 6 of 9 |
||||||
 |
The Back Shed's forum code is written, and hosted, in Australia. |
