I am having trouble getting certain odd frequencies working.
When the issue occurs, the usb interface never talks, and ide code never runs.
I have tried a few clocks, 175MHz, 275MHz, 137MHz and 139MHz.
All of these panic during set_sys_clock_khz because "System clock of %u kHz cannot be exactly achieved"
The datasheet recommends using the vcocalc.py tool to determine best settings for each clock speed.
Using the tool, I can replicate frequency error with every non working frequency by forcing refdiv to 1. but it seems like most of these are achievable if REFDIV is set to 2 when needed.
If you choose an invalid clock, the board just silently halts by hitting a breakpoint. Without a debugger attached, it will be difficult to troubleshoot.
Is it possible to dynamically set REFDIV and set the clock to the nearest achievable speed or failsafe in a way that someone without an external debugger can still access the device via usb?
I am having trouble getting certain odd frequencies working.
When the issue occurs, the usb interface never talks, and ide code never runs.
I have tried a few clocks, 175MHz, 275MHz, 137MHz and 139MHz.
All of these panic during set_sys_clock_khz because "System clock of %u kHz cannot be exactly achieved"
The datasheet recommends using the vcocalc.py tool to determine best settings for each clock speed.
Using the tool, I can replicate frequency error with every non working frequency by forcing refdiv to 1. but it seems like most of these are achievable if REFDIV is set to 2 when needed.
If you choose an invalid clock, the board just silently halts by hitting a breakpoint. Without a debugger attached, it will be difficult to troubleshoot.
Is it possible to dynamically set REFDIV and set the clock to the nearest achievable speed or failsafe in a way that someone without an external debugger can still access the device via usb?
Thanks, but how are you trying things like 137 and 139 since they're not in the menus?
I can repro the 175 and 275 failure on the Pico. Those should be moved to something that actually runs or dropped from the menus, agreed. Changing the REFDIV isn't really an option because we build that bit of the binary one time only (libpico.a).
Moving 175->176 and 275->276 makes things work properly as configured (well, the clock setting doesn't crash but 276MHz is not really a commonly good overclock!) for the RP2040 and RP2350. I'll be doing a PR for that.
Thanks, but how are you trying things like 137 and 139 since they're not in the menus?
I can repro the 175 and 275 failure on the Pico. Those should be moved to something that actually runs or dropped from the menus, agreed. Changing the REFDIV isn't really an option because we build that bit of the binary one time only (libpico.a).
Moving 175->176 and 275->276 makes things work properly as configured (well, the clock setting doesn't crash but 276MHz is not really a commonly good overclock!) for the RP2040 and RP2350. I'll be doing a PR for that.
I edited makeboards.py to add in the custom 137 and 139MHz clocks in the IDE menu to test if an in spec (<150MHz) clock had the same issue that the 175MHz and 275MHz OC clocks did. It was something mentioned in discussion #2841
Thanks for looking at this. Shame about REFDIV being a fixed value. It looks like something that may be difficult to change at runtime without disturbing both PLLs.
I edited makeboards.py to add in the custom 137 and 139MHz clocks in the IDE menu to test if an in spec (<150MHz) clock had the same issue that the 175MHz and 275MHz OC clocks did. It was something mentioned in discussion #2841
Thanks for looking at this. Shame about REFDIV being a fixed value. It looks like something that may be difficult to change at runtime without disturbing both PLLs.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I am having trouble getting certain odd frequencies working.
When the issue occurs, the usb interface never talks, and ide code never runs.
I have tried a few clocks, 175MHz, 275MHz, 137MHz and 139MHz.
All of these panic during set_sys_clock_khz because "System clock of %u kHz cannot be exactly achieved"
The datasheet recommends using the vcocalc.py tool to determine best settings for each clock speed.
Using the tool, I can replicate frequency error with every non working frequency by forcing refdiv to 1. but it seems like most of these are achievable if REFDIV is set to 2 when needed.
If you choose an invalid clock, the board just silently halts by hitting a breakpoint. Without a debugger attached, it will be difficult to troubleshoot.
Is it possible to dynamically set REFDIV and set the clock to the nearest achievable speed or failsafe in a way that someone without an external debugger can still access the device via usb?
Thanks, but how are you trying things like 137 and 139 since they're not in the menus?
I can repro the 175 and 275 failure on the Pico. Those should be moved to something that actually runs or dropped from the menus, agreed. Changing the REFDIV isn't really an option because we build that bit of the binary one time only (libpico.a).
Moving 175->176 and 275->276 makes things work properly as configured (well, the clock setting doesn't crash but 276MHz is not really a commonly good overclock!) for the RP2040 and RP2350. I'll be doing a PR for that.
I edited makeboards.py to add in the custom 137 and 139MHz clocks in the IDE menu to test if an in spec (<150MHz) clock had the same issue that the 175MHz and 275MHz OC clocks did. It was something mentioned in discussion #2841
Thanks for looking at this. Shame about REFDIV being a fixed value. It looks like something that may be difficult to change at runtime without disturbing both PLLs.