![]() |
Forum Index : Microcontroller and PC projects : Minimum clock RP2040 (48MHz)
Author | Message | ||||
some_rando Newbie ![]() Joined: 25/03/2025 Location: AustraliaPosts: 7 |
In MMBasic version 5 on RP2040, I down-clocked to 48MHz to reduce power consumption. RP2350 has lower power consumption out of the box, so it's not so much of a problem. In version 6, we install an MMBasic variant depending on the CPU, HDMI and USB peripherals, and some of these at least have minimum clock speeds. I sympathize with Peter keeping track of all of the parameters, and I think I have discovered a bug. OPTION LIST shows "Picomite MMBasic RP2040 Edition V6.00.01". OPTION CPUSPEED 48000 is accepted, however on every subsequent reboot, the error message "Invalid clock speed - reset to default" is reported, and the clock speed is reset to 133MHz. Evidently, I must be the only person down-clocking. Everyone seems hell bent on going as fast as the hardware will allow ![]() |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10067 |
Works for me PicoMite MMBasic RP2040 Edition V6.00.02RC8. Of course it can only work for the PicoMite firmware and not VGA etc. |
||||
Grogster![]() Admin Group ![]() Joined: 31/12/2012 Location: New ZealandPosts: 9486 |
I set OPTION CPUSPEED 48000 on heaps and heaps of PicoMite boards for low-speed applications, to save on current consumption if and when they need to revert to the backup 9v battery operation if the main power fails, and have never had a single issue or error message as described after I set that. As with what Peter mentioned in his post above, these are plain PicoMite modules that are NOT using VGA, they are just the plain embedded controller firmware. I suspect that is where your problem is, cos 48MHz will be too slow to drive the VGA controller on the 2nd core of the 2040, so MMBASIC detects this, and over-rides your OPTION CPUSPEED setting, so that the VGA output will still work - otherwise the VGA would not work, and it could result in LOTS of head-scratching as to why not, if you are using the VGA firmware. Can you confirm if you are using the VGA firmware, or the plain embedded controller firmware? Smoke makes things work. When the smoke gets out, it stops! |
||||
some_rando Newbie ![]() Joined: 25/03/2025 Location: AustraliaPosts: 7 |
I'm pretty sure that this was PicoMiteRP2040V6.00.01.uf2 (an early version), non-VGA, and non-USB. The only non-standard quirk was that the installation is on a Pimoroni board with more Flash. I have to do a little fiddling to get to the CPU and reload it. |
||||
some_rando Newbie ![]() Joined: 25/03/2025 Location: AustraliaPosts: 7 |
All fool's day. Sorry, this isn't an April Fool's joke, and I have been able to reinstall MMBasic and replicate the problem. This is my second attempt to post some diagnostics, and I lost my post, which is wearing a bit thin. So bare with me. I have Geoff's ASCII Video Terminal (AVT) connected via GP0/GP1, and the CPU is a Pimoroni PIM560 Pico LiPO RP2040 with 16MB Flash. I applied the *old* Clear Flash utility, and then installed PicoMiteRP2040V6.00.01.uf2, then communicating via screen set OPTION CPUSPEED 48000 OPTION SYSTEM SPI GP14,GP15,GP12 OPTION SDCARD GP13 OPTION SERIAL CONSOLE GP1,GP0 with breaks in between commands when the system resets. So at this point, I confirm the plain embedded controller firmware, not VGA firmware. I install routines in the library, and my main program. Switching over to communicating via the AVT, a cold restart then reports Invalid clock speed - reset to default OPTION LIST shows Picomite MMBasic RP2040 Edition V6.00.01 OPTION SERIAL CONSOLE COM1,GP0,GP1 OPTION SYSTEM SPI GP14,GP15,GP12 OPTION FLASH SIZE 16777216 OPTION LIBRARY_FLASH_SIZE 20000 OPTION SDCARD GP13 I can then try OPTION CPUSPEED 48000 again from the prompt, which returns after a small delay. OPTION LIST shows Picomite MMBasic RP2040 Edition V6.00.01 OPTION SERIAL CONSOLE COM1,GP0,GP1 OPTION SYSTEM SPI GP14,GP15,GP12 OPTION FLASH SIZE 16777216 OPTION LIBRARY_FLASH_SIZE 20000 OPTION CPUSPEED 48000 'KHz OPTION SDCARD GP13 If I try CPU RESTART, I get a prompt, and the lower CPU speed is still enabled. But if I power cycle the hardware, it returns the invalid clock speed message, and the CPUSPEED option is lost. Is there any other diagnostic information that I can provide? And ... nobody else has seen this issue? |
||||
Grogster![]() Admin Group ![]() Joined: 31/12/2012 Location: New ZealandPosts: 9486 |
I use version 5.09, cos that is stable and works for me. I will see what happens, if I load version 6.00.01 onto a WS Zero module. What routines are you saving in the library? Could they potentially be causing the interpreter to reset to default clock speed? I don't really see how, cos if you CPU RESTART, if that was the source of the issue, you'd still have the same problem, but you don't unless you power-cycle.... What happens if you load an earlier version of the FW, such as v5.09 that I am using, and see if you still get the same problem? If you DON'T then something odd is going on with v6 of the FW. If you DO then it has to be something in the program, and you'd need to post your code along with any routines you have stored in the library, so that others can see if they can replicate or pinpoint your problem. Smoke makes things work. When the smoke gets out, it stops! |
||||
some_rando Newbie ![]() Joined: 25/03/2025 Location: AustraliaPosts: 7 |
Thanks Grogster. It would be fantastic if you could confirm the issue. I had been using version 5 without any issues, this is a recent discovery on version 6, and perhaps with the more flashy ![]() Ok, I have lots of stuff in the library to make it disappear from view, and to escape the code space boundary that I was pushing on. Nothing that plays with clock speed. There is a vt100 class, with a bunch of ASCII "applications" as simple as a clock in Jumbo digits. Access to epoch, and that kind of thing, but nothing remotely connected to clock speed. Hard to replicate exactly in version 5, because well ... code size. |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 4854 |
Hi Some rando, Just curiosity, are you doing Some time critical stuff like WS2812, DS18B20, using ADC at fast sampling rate. I see you are not using audio, so that can not cause this message. Maybe USB CDC needs a higher CPU speed. You could try to relocate console to a UART. I think this is more for Peter. Volhout Edited 2025-04-01 16:56 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
some_rando Newbie ![]() Joined: 25/03/2025 Location: AustraliaPosts: 7 |
Hi Volhout, Nice to make your acquaintance. Another legend ![]() Does anyone have a PIM560 sitting in their build box? Regards |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10067 |
Have you tied 6.00.02RC8? I tested on this and can't replicate |
||||
mozzie Senior Member ![]() Joined: 15/06/2020 Location: AustraliaPosts: 109 |
G'day Some_Rando, Not sure if this is good news or bad.... After finding the Pico Lipo in the "collection" and loading V6.00.01 with most of the options shown, PicoMite MMBasic RP2040 Edition V6.00.01 OPTION SERIAL CONSOLE COM1,GP0,GP1,BOTH OPTION SYSTEM SPI GP14,GP15,GP12 OPTION FLASH SIZE 16777216 OPTION CPUSPEED 48000 'KHz So far it has been stable. Power cycles and resets have shown no change from CPUSPEED 48000 Also tried a standard Pico 1 and no problems, I also try these at 48000 to minimize power consumption and haven't hit this problem before. This is with no program running, next thing to try. Is the library stored in the external flash? Perhaps trying to access this at the slower clock speed is causing a problem. Maybe try a slightly higher speed (64000?) and incrementally increase to see if that changes anything. Does the program run ok at the normal clock speed? (just for reference) Regards, Lyle. |
||||
some_rando Newbie ![]() Joined: 25/03/2025 Location: AustraliaPosts: 7 |
Thanks everybody for your help. I haven't finished with this yet. The ball is in my court to replicate this in the simplest way possible. I'm not sure what to try first. There are a few different options. Possibly I will upgrade to the latest version as recommended by Peter, and see if the issue disappears. I do have a duplicate board missing a couple of resistors which is a candidate for swapping in and out. It all detracts from writing entertaining code, and I have Pico/2/Computer reference boards on the way which will certainly be a major distraction. Yes, runs as expected. I should mention that I am using a 2 row, 20 pin DIL connector to take signals off of the board, and onto a front panel, then through the same physical arrangement into another board with the AVT hardware. Serial is running at 115k. I came to this arrangement to increase my PCB real estate, but it's possibly not ideal. Anyway, thanks again for your help, and leave it with me. |
||||
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |