PSRAM issues on custom overclocks (252 and 264 MHz)

[Macrosii]

Hi
I have had this issue before with PSRAM when using the Adafruit DVI library which over clocks to 252MHz..
I ended up editing the PSRAM.cpp file and hard coding the frequency into the code and all seemed ok.
I recently got a couple of Adafruit Feathers HSTX with PSRAM and the HSTX library over clocks to 264 MHZ.
Now I had lost my mods in upgrading the core to 4.4.4 so changed the "PSRAM.cpp" file as below.

    //Allow for custom psram clock if code is setting CPU frequency
    #ifdef PSRAM_CUSTOM_SYSHZ
    uint32_t sysHz = PSRAM_CUSTOM_SYSHZ;
    #else
    uint32_t sysHz = (uint32_t)clock_get_hz(clk_sys);
    #endif

then added a define to my code as follows; "#define PSRAM_CUSTOM_SYSHZ 240000000 // let the peram know the spped of the CPU". Unfortuantly this does not seem to work and things crash. For testing further I just modified a blink sketch as below and set an overclock from the IDE and then set the define to match the frequency. All is ok with an overclock @240MHz, but above that thing seem to fail. Are there other parameter that might need adjusting or am I just doing something stupid ?
Could some conditional defines be included into the core so that I and others don't need to keep track of this manually ?
Manky thanks

/*
  Blink without Delay

*/

#ifdef USE_TINYUSB
#include <Adafruit_TinyUSB.h>
#endif

//#define PSRAM_CUSTOM_SYSHZ 240000000 // let the peram know the spped of the CPU

// constants won't change. Used here to set a pin number:
const int ledPin =  LED_BUILTIN;// the number of the LED pin

// Variables will change:
int ledState = LOW;             // ledState used to set the LED

// Generally, you should use "unsigned long" for variables that hold time
// The value will quickly become too large for an int to store
unsigned long previousMillis = 0;        // will store last time LED was updated

// constants won't change:
const long interval = 1000;           // interval at which to blink (milliseconds)

void setup() {
  // set the digital pin as output:
  pinMode(ledPin, OUTPUT);
  Serial.begin(115200);
}

void loop() {
  // here is where you'd put code that needs to be running all the time.

  // check to see if it's time to blink the LED; that is, if the difference
  // between the current time and last time you blinked the LED is bigger than
  // the interval at which you want to blink the LED.
  unsigned long currentMillis = millis();

  if (currentMillis - previousMillis >= interval) {
    // save the last time you blinked the LED
    previousMillis = currentMillis;

    // if the LED is off turn it on and vice-versa:
    if (ledState == LOW) {
      ledState = HIGH;
    } else {
      ledState = LOW;
    }

    // set the LED with the ledState of the variable:
    digitalWrite(ledPin, ledState);
    Serial.println("Loop");
    Serial.print("CPU Freq");
    Serial.println(rp2040.f_cpu());
    Serial.print("PSRAM size");
    Serial.println(rp2040.getPSRAMSize());
  }
}

[earlephilhower]

Just for sanity's sake, make sure you're using master because there was a change to the order of operations for PSRAM clock setup when overclocking from the menus. #2824

[Macrosii]

Many thanks for the quick reply.
I updated to 4.4.4 in the IDE board manager and then updated the file psram.cpp in "/home/bobpi/.arduino15/packages/rp2040/hardware/rp2040/4.4.4/cores/rp2040", which was the only one i could fine. Is that correct ?

[Macrosii]

Ah, I think you told me this before (Doh!) , the master is on the root page so cannot be installed from the board manager ? In which case I could download a zip from the root page and select install from zip in the ide ?

[Macrosii]

Ah, that is for installing libs and not board packages. Forgive my lack of knowledge!! Do I need to install following the "Install from GIT" instructions ? Will this match where my Arduino installation is ?
Regards

mkdir -p ~/Arduino/hardware/pico
git clone https://github.com/earlephilhower/arduino-pico.git ~/Arduino/hardware/pico/rp2040
cd ~/Arduino/hardware/pico/rp2040
git submodule update --init
cd pico-sdk
git submodule update --init
cd ../tools
python3 ./get.py

[earlephilhower]

Yes, that's how you'd get the master branch. It installs in a different spot than IDE installed packages so be sure to select the one with (Sketchbook) or somesuch listed in the IDE menus.

[Macrosii]

Ok, so now 300MHZ overclock from IDE works if I set.
sysHz = 300000000;
volatile uint8_t clockDivider = 4;
Unfortunately with the HSTX driver code and 264MHz set from code it fails with the following settings
sysHz = 300000000;
volatile uint8_t clockDivider = 4; //tried 3 4 and 5

[Macrosii]

sorry typo
sysHz = 264000000;
volatile uint8_t clockDivider = 4; //tried 3 4 and 5

[earlephilhower]

The QSPI interface has configurable timing adjustments beyond just the divider. The SparkFun code I lifted has some "safe" values which work great at normal speeds but maybe aren't right if you go for a 33% overclock. Check the values being set to qmi_hw->m[1].timing. A sampling oscilloscope would also be handy to check setup/hold times...

[Macrosii]

OK thanks. My oscilloscope is only 50MHz so not much use I am afraid. I do have a fast logic analyzer, but not sure I would be able to get this onto the soldered part.
I noticed @dan2wik had done some testing in #2818. Maybe i could reach out to him to see if he would not mind looking at 264Mhz!, but I do see in that post that there are other failures like 175Mhz and 275Mhz.

[dan2wik]

My scope isn't fast enough to capture the signalling at these speeds but I can test some things on my board at least.

I have a Pimoroni Pico 2 Plus.
Unmodified master repo attempts to run PSRAM at a divisor of 3 at both 252 and 264mhz for 84MHz and 88MHz respectively.
On my board I'm running a modified PSRAM Test example sketch to print QSPI register info,
252MHz passes the test, 264MHz fails the test.
Forcing divisor to 4 causes both to pass.

I do know that my PSRAM runs stable above 88MHz as I have run it up to 109MHz with the core set to 109MHz, and 100MHz at 200MHz core.
However, I am running my core at 360MHz for my project and I have been forced to run clockdiv of 5 for 72MHz psram instead of the theoretical safe max of 90MHz at div 4.

Going through section 12.14 of the rp2350 datasheet, there are additional timings that are based on system clock, ignoring the divisor.
Some examples;
Section 12.14.3.1: "RXDELAY counts delay in half system clock cycles, instead of SCK cycles." this sets sampling delay based off sysclock.
Section 12.14.3.2: Multiple settings here for chip select timings based off sysclock.
Section 12.14.3.4: "The QMI interface is timed using the internal system clock." This section is about AC timing and skew settings, also based on sysclock.

It's likely that these are the key to getting PSRAM (and the onboard flash) operating more stable at higher core speeds, and reduce latency at lower core speeds.

[dan2wik]

Something else I noticed. I'm dumping the format, read and write timing registers.
At 150MHz they dump as such:
[0]RFMT 000492a8
[0]WFMT 00001000
[0]TIM 60007203
[1]RFMT 000612aa
[1]WFMT 000012aa
[1]TIM 61a48102

[0] is the flash, [1] is the psram.
Am I correct in assuming the write format for the flash hasn't been programmed?
This means writes to flash may be significantly slower than it can be.

[earlephilhower]

I would assume so. You can't write to flash with the XIP anyway so it's not necessary to set it up. Flash writes are special cased.

[dan2wik]

Is this XIP no write thing a software or a hardware limitation?
The documentation seems to imply that XIP is capable of writing sflash by stating it can cache writes as well as reads.
Even if XIP is unable to write, you could still send the writes directly through QMI which would require the write format to be set correctly.

I'll poke around and familiarize myself more with this part of the upstream sdk.

[earlephilhower]

Flash doesn't write like PSRAM. You can't just rewrite data, you need to erase an entire page/sector and write minimum amounts or it just won't work. And writing and erasing are very slow (and only a limited number of cycles before the chip dies). So XIP cache will never write to flash. It's perfectly good, though, at caching reads from it. :)

[dan2wik]

It would appear that changing QMI_M1_TIMING_RXDELAY_LSB in PSRAM.cpp from 1 to 2 allows me to reach the max valid PSRAM speed at;
264MHz (88MHz PSRAM),
300MHz (100MHz PSRAM) and
324MHz (108MHz PSRAM).

327MHz (109MHz PSRAM) and 360MHz (90MHz) were intermittently unstable and required a bump to 3.
I suspect >150mhz needs 2 until >300mhz which needs 3, then assumedly >450mhz needs 4.

It seems like MIN_DESELECT and MAX_SELECT are calculated correctly against sysclock, but SELECT_HOLD, COOLDOWN and RXDELAY are all statically set. I am unsure if these other timings need modifications too but it passes the simple PSRAM test sketch.

[Macrosii]

@dan2wik
Many thanks for your work on this. Unfortunately my Feather HSTX with psram still crashes with clock divider 3 and QMI_M1_TIMING_RXDELAY_LSB = 2 or 3. Am i modifying psram.cpp correctly ?

//-----------------------------------------------------------------------------
/// @brief Update the PSRAM timing configuration based on system clock
///
/// @note This function expects interrupts to be enabled on entry

static void __no_inline_not_in_flash_func(set_psram_timing)(uint32_t sysHz) {
    // Calculate the clock divider - goal to get clock used for PSRAM <= what
    // the PSRAM IC can handle - which is defined in SFE_PSRAM_MAX_SCK_HZ
  //  volatile uint8_t clockDivider = (sysHz + SFE_PSRAM_MAX_SCK_HZ - 1) / SFE_PSRAM_MAX_SCK_HZ;
  
  sysHz = 264000000;  //07MAR2025
  volatile uint8_t clockDivider = 3;  //07MAR2025

    uint32_t intr_stash = save_and_disable_interrupts();

    // Get the clock femto seconds per cycle.

    uint32_t fsPerCycle = SFE_SEC_TO_FS / sysHz;

    // the maxSelect value is defined in units of 64 clock cycles
    // So maxFS / (64 * fsPerCycle) = maxSelect = SFE_PSRAM_MAX_SELECT_FS64/fsPerCycle
    volatile uint8_t maxSelect = SFE_PSRAM_MAX_SELECT_FS64 / fsPerCycle;

    //  minDeselect time - in system clock cycle
    // Must be higher than 50ns (min deselect time for PSRAM) so add a fsPerCycle - 1 to round up
    // So minFS/fsPerCycle = minDeselect = SFE_PSRAM_MIN_DESELECT_FS/fsPerCycle

    volatile uint8_t minDeselect = (SFE_PSRAM_MIN_DESELECT_FS + fsPerCycle - 1) / fsPerCycle;

    // printf("Max Select: %d, Min Deselect: %d, clock divider: %d\n", maxSelect, minDeselect, clockDivider);

    qmi_hw->m[1].timing = QMI_M1_TIMING_PAGEBREAK_VALUE_1024 << QMI_M1_TIMING_PAGEBREAK_LSB | // Break between pages.
                          3 << QMI_M1_TIMING_SELECT_HOLD_LSB | // Delay releasing CS for 3 extra system cycles.
                          1 << QMI_M1_TIMING_COOLDOWN_LSB | 3 << QMI_M1_TIMING_RXDELAY_LSB |  //07MAR2025 change QMI_M1_TIMING_RXDELAY_LSB to 2 or 3 
                          maxSelect << QMI_M1_TIMING_MAX_SELECT_LSB | minDeselect << QMI_M1_TIMING_MIN_DESELECT_LSB |
                          clockDivider << QMI_M1_TIMING_CLKDIV_LSB;

    restore_interrupts(intr_stash);
}

[dan2wik]

May I ask how you're observing the crash, and if you're applying extra core voltage?
My Pico2 is marginally stable at 290MHz and default voltage. I would have to run 1.15v to pass multiple stress tests, and 1.20v to guarantee stability at both your listed frequencies. My project runs 1.25v to reach 360MHz.

Your Feather HSTX is specced with the same PSRAM chip as my Pimoroni Pico2 Plus, just in a different package so other than trace differences, our boards should behave the same.

I have a Pico Probe on the way so if I can replicate your crash, I can debug it when it gets here.

[Macrosii]

@dan2wik
Observation is the HDMI monitor , and serial monitor in Arduino IDE. Whats strange . the HSTX display seem to keep running until I open up the Arduino IDE monitor. Then I may get a few messages printed out from "loop" (once a second) before it crashes.
So I am not changing the voltage myself, the library "https://github.com/adafruit/Adafruit-DVI-HSTX" sets the overclock, not sure what it does with the voltage. I will give a go without the lib and overclock from the IDE menu (I assume the voltages are also increased when overclocking from the menu)

[Macrosii]

Ok, I found the clock frequency setting in the lib as (below) at 1.15v, I will try upping to 1.2 as you suggest.

    // We're going to go fast, boost the voltage a little
    vreg_set_voltage(VREG_VOLTAGE_1_15);

[Macrosii]

@dan2wik
Thank you very much. It seems to be running stable @1.2v, clockdiv = 3 and QMI_M1_TIMING_RXDELAY_LSB =2.
Assumption is always my enemy. IE assuming the core voltage would be taken care of!!

[Macrosii]

Ah, spoke too soon, just crashed again!! Will try 1.25V

[Macrosii]

So @1.25v still running after 15 mins. Fingers crossed!. Its really sunny out so going to go for a walk and see when I get back.
I found a nice article on overclocking the RP2350 here https://learn.pimoroni.com/article/overclocking-the-pico-2
The author happens to be the original author of the HSTX library!! So in his tests the Pico 2 seems to be stable at 312Mhz and 1.1v, hence I guess setting to 1.15V in his library.
So another learning for me! Not all boards are equal with regards to overclocking!
Thanks again for the help and thanks to earlphilhower for giving us Arduino support!

[dan2wik]

I haven't had a chance to play around with the HSTX peripheral but I do know it can be pretty intense on the system.
It's possible for it to completely max out an entire read port with 100% utilization which can reveal memory/bus stability problems.
Without debugging the device, it's difficult to say what part of the chip is failing.
If I get a chance to (which won't be any time soon with this cyclone I'm in), I may try the HSTX DVI example myself.

[Macrosii]

Doh!. Run for around two hours and then crashed. Will try without the PSRAM to see if the same!

[jepler]

The dvhstx library uses some very specific clock settings. I don't fully understand them yet, but from what I can see:

• It wants to achieve an exact hstx clock frequency at runtime for various video modes
• To do so, it will dynamically reconfigure pll_sys when configuring clk_hstx
• So everything else is clocked from pll_usb, which is configured for 528MHz
• clk_sys = pll_usb/2 (264MHz) clk_peri = pll_usb/4 (132MHz) , clk_usb = clk_adc = pll_usb/11 (48MHz)
• All clocking besides pll_sys and clk_hstx is done very early in startup before main, by low level linker trickery

I don't know exactly why 264MHz was selected for the CPU speed, though considering my recent problem with disabled interrupts during SPI transfers I suspect that this is simply how fast the CPU needs to run in order to generate the video data, particularly in the fancy text mode.

Would you be amenable to adding a "264MHz (HSTX)" overclock to the menu, if one was contributed? It doesn't feel particularly clean that this one particular library should have to require the core to change just for its clocking requirements, but I don't see any other great ways forward.

fwiw while the FruitJam DOES have psram, I have not done a PSRAM-using HSTX project yet so I can't comment on the stability. Without PSRAM in the mix, the overclock has been stable, running text mode and graphics mode demos for 24+ hours at a time.

[jepler]

@MichaelBell is there any possibility you can add or clarify anything about why dvhstx sets the clocks as it does?

[MichaelBell]

That's all correct - the idea was to run everything except for the HSTX off the USB PLL, to allow the freedom to use any video mode without having to have the system clock frequency tied to the video mode.

264MHz was picked because it seemed to be stable, and allows both PSRAM and flash to be run at 132MHz, which is their max rated speed. We (either me personally or Pimoroni) haven't done much with this library yet though, so you're the first to push out those overclock settings on a wider variety of hardware, which might have variations in how fast it can run. In particular while I have tested PSRAM with RP2350 running at 264MHz, and this library at 264MHz, I haven't done a stress test of them both running together.

As you note, the text rendering is very tight on CPU budget, so reducing the overclock might break it. Potentially you could get away with 240MHz (I'd suggest settting pll_usb and clk_sys to 240MHz, clk_peri to 120MHz and clk_usb = clk_adc to 48 = 240/5), which would also avoid the PLL output frequency being much faster than is likely to have been tested by RPi.

[MichaelBell]

On the PSRAM timing setup, I haven't looked at the Arduino Pico implementation at all, but for reference here's my Micropython version: https://github.com/pimoroni/micropython/blob/feature/psram/ports/rp2/rp2_psram.c#L107-L134

I believe that should set timing that works reliably across a wide range of clock speeds (including 264MHz), at least on the Pimoroni Pico Plus 2 😄

[Macrosii]

@MichaelBell
Many thanks for your input and thanks for the library and the great overclocking article @pimoroni! I am now following you on blue-sky now!
My Feather HSTX (no PSRAM) is still running with core voltage @ 1.25v. Going to leave overnight to see! Will try out your PSRAM timings tomorrow if I can work out how to successfully integrate into "psram.cpp". Hoping it will be mainly cut and paste!
Regards

[Macrosii]

Still running , so stable at 1.25v with no psram. Will try the mods to psram timings later today!

[Macrosii]

Now running HSTX code, 264Mhz, 1.25v and @MichaelBell PSRAM timings. So far so good!

[MichaelBell]

Cool! It would be interesting to know if you really need the core voltage that high.

[dan2wik]

It's likely up to silicon lottery. I'm able to run the HSTX DVI example at 264MHz and 1.2v just fine in my pimoroni pico2 plus.
At 1.15v it crashes after an hour or 2.

[Macrosii]

@dan2wik , yes likely. I will try a Pico plus 2 today i I get a chance!
@MichaelBell, pretty sure I was having issues with core voltage without PSRAM but will revisit just to make sure!
The Feather HSTX with psram, 1.25V and new psram timing ran all night.
I think i need to do further testing;

1. I need to write something to exercise the psram better, unless anyone has something already ?
2. Try the new psram timings without HSTX on the overclocks from the IDE
3. Will try with a Pico Plus 2 and PGA2350 with and without HSTX

[MichaelBell]

I've got a project based on the RandMem Benchmark, if that's of interest: https://github.com/MichaelBell/rp2350-psram-test/tree/main

[Macrosii]

@MichaelBell , will take a look. Thanks

[Macrosii]

@earlephilhower
Have I mucked up my installation.
For Pimoroni Pico Plus 2 and RP2350, I don't get PSRAM options in the IDE menu any more (i do for Feather HSTX).
Core 4.4.4
IDE1.8.19

[dan2wik]

For boards that only come with 1 type of psram pre soldered, there is no options since we know what the board comes with.

[Macrosii]

Sorry that should be Pico Plus 2 and PGA2350

[Macrosii]

Ah, I really should have thought of that (feeling stupid)! Thanks.
Testing on Pico Plus 2

[Macrosii]

So far tested on PGA2350 with more comprehensive test of PSRAM
150 MHz IDE- Pass
175 MHz IDE- No Boot
225 MHz IDE- Pass
250 MHz IDE- Pass
264 MHz (HSTX and still at 1.25v currently) - Pass
275 MHz IDE- No Boot
300 MHz IDE- Pass
I notice the 175 and 275 MHz failed for @dan2wik in previous tests with original code.

@MichaelBell I see you have defined " const int max_psram_freq = 133000000;" So the datasheet I downloaded (APS6404L-3SQR QSPI PSRAM) has; "133MHz for 32 Bytes Wrapped Burst operation at VDD=3.0V+/-10%" but "109MHz for 32 Bytes Wrapped Burst operation at VDD=3.3V+/-10%" ?

Hacked psram.cpp timing section.

//-----------------------------------------------------------------------------
/// @brief Update the PSRAM timing configuration based on system clock
///
/// @note This function expects interrupts to be enabled on entry

static void __no_inline_not_in_flash_func(set_psram_timing)(uint32_t sysHz) {
    // Calculate the clock divider - goal to get clock used for PSRAM <= what
    // the PSRAM IC can handle - which is defined in SFE_PSRAM_MAX_SCK_HZ
  //  volatile uint8_t clockDivider = (sysHz + SFE_PSRAM_MAX_SCK_HZ - 1) / SFE_PSRAM_MAX_SCK_HZ;
  


    uint32_t intr_stash = save_and_disable_interrupts();
    
    //08MAR2025 Use psram timing from @MichaelBell
    //https://github.com/pimoroni/micropython/blob/feature/psram/ports/rp2/rp2_psram.c#L107-L134
    
    // Set PSRAM timing for APS6404
    //
    // Using an rxdelay equal to the divisor isn't enough when running the APS6404 close to 133MHz.
    // So: don't allow running at divisor 1 above 100MHz (because delay of 2 would be too late),
    // and add an extra 1 to the rxdelay if the divided clock is > 100MHz (i.e. sys clock > 200MHz).
    

    
    const int max_psram_freq = 133000000;
    //const int clock_hz = clock_get_hz(clk_sys);  
    const int clock_hz = 300000000;     //Only seems to work if I hard code the frequency
    int divisor = (clock_hz + max_psram_freq - 1) / max_psram_freq;
    if (divisor == 1 && clock_hz > 100000000) {
        divisor = 2;
    }
    int rxdelay = divisor;
    if (clock_hz / divisor > 100000000) {
        rxdelay += 1;
    }

    // - Max select must be <= 8us.  The value is given in multiples of 64 system clocks.
    // - Min deselect must be >= 18ns.  The value is given in system clock cycles - ceil(divisor / 2).
    const int clock_period_fs = 1000000000000000ll / clock_hz;
    const int max_select = (125 * 1000000) / clock_period_fs;  // 125 = 8000ns / 64
    const int min_deselect = (18 * 1000000 + (clock_period_fs - 1)) / clock_period_fs - (divisor + 1) / 2;

    qmi_hw->m[1].timing = 1 << QMI_M1_TIMING_COOLDOWN_LSB |
        QMI_M1_TIMING_PAGEBREAK_VALUE_1024 << QMI_M1_TIMING_PAGEBREAK_LSB |
        max_select << QMI_M1_TIMING_MAX_SELECT_LSB |
        min_deselect << QMI_M1_TIMING_MIN_DESELECT_LSB |
        rxdelay << QMI_M1_TIMING_RXDELAY_LSB |
        divisor << QMI_M1_TIMING_CLKDIV_LSB;
    //END - Use psram timing from @MichaelBell

/*  08MAR2025 Comment out
    // Get the clock femto seconds per cycle.
    sysHz = 264000000;  //07MAR2025
    volatile uint8_t clockDivider = 3;  //07MAR2025

    uint32_t fsPerCycle = SFE_SEC_TO_FS / sysHz;

    // the maxSelect value is defined in units of 64 clock cycles
    // So maxFS / (64 * fsPerCycle) = maxSelect = SFE_PSRAM_MAX_SELECT_FS64/fsPerCycle
    volatile uint8_t maxSelect = SFE_PSRAM_MAX_SELECT_FS64 / fsPerCycle;

    //  minDeselect time - in system clock cycle
    // Must be higher than 50ns (min deselect time for PSRAM) so add a fsPerCycle - 1 to round up
    // So minFS/fsPerCycle = minDeselect = SFE_PSRAM_MIN_DESELECT_FS/fsPerCycle

    volatile uint8_t minDeselect = (SFE_PSRAM_MIN_DESELECT_FS + fsPerCycle - 1) / fsPerCycle;

    // printf("Max Select: %d, Min Deselect: %d, clock divider: %d\n", maxSelect, minDeselect, clockDivider);

    qmi_hw->m[1].timing = QMI_M1_TIMING_PAGEBREAK_VALUE_1024 << QMI_M1_TIMING_PAGEBREAK_LSB | // Break between pages.
                          3 << QMI_M1_TIMING_SELECT_HOLD_LSB | // Delay releasing CS for 3 extra system cycles.
                          1 << QMI_M1_TIMING_COOLDOWN_LSB | 2<< QMI_M1_TIMING_RXDELAY_LSB |  //07MAR2025 change QMI_M1_TIMING_RXDELAY_LSB to 2 or 3 
                          maxSelect << QMI_M1_TIMING_MAX_SELECT_LSB | minDeselect << QMI_M1_TIMING_MIN_DESELECT_LSB |
                          clockDivider << QMI_M1_TIMING_CLKDIV_LSB;
    */

    restore_interrupts(intr_stash);
}

[MichaelBell]

175MHz or 275MHz are not possible for the PLL to generate from a 12MHz clock source, which explains the failures there. In general over 133MHz only multiples of 2 work and over 266 only multiples of 4 work (many other frequencies also work, but those always will).

Hardcoding the clock frequency to 300MHz in that snippet will make the max select time too long at lower frequencies. Probably unlilkely a problem in practice, but you're going out of spec. Is the problem that this setup is being run before the clock frequency is changed?

On the 133MHz vs 109MHz maximum, we found on PicoVision that a little over 133MHz worked in practice at 3.3V (which is 3.0V+10%) - a couple of modes on PicoVision use 135MHz. Though if your voltage regulator is a bit high then maybe you could run into issues. The implementation only allows PSRAM clock speeds over 109MHz when you're overclocking the RP2350 above 218MHz so I felt this was well into the region of "if it works in practice then let's do it".

[dan2wik]

Using the vcocalc.py tool from the sdk, 175MHz is possible with a REFDIV of 2.
275MHz does not appear possible. the closest I can get the tool is 274.8MHz.

[Macrosii]

@MichaelBell , many thanks fir the explanations (I have some PicoVision). I was matching the hard-coded frequency to whatever was selected on the IDE.
" Is the problem that this setup is being run before the clock frequency is changed" seems likely but @earlephilhower would be able to confirm.

[Macrosii]

Although looking at the code again I am thinking I should try setting to sysHz which is passed into the function!

[Macrosii]

Feather HSTX 8MB PSRAM
Passes ok at 150,200,225,240,250,300 MHz. Passes at 264Mhz with HSTX library. Will leave running overnight!