PSRAM clocking incorrect

[Macrosii]

Hi

Many thanks for this great library.
FYI I have two Feathers HSTX, one with PSRAM. Without the PSRAM all is fine.
However with PSRAM there are unpredictable failures. I believe this is due to the 264MHz overclock, as the PSRAM timings are set from the frequency selected from the IDE. I have created a "Discussion" on this here;
[https://github.com/earlephilhower/arduino-pico/discussions/2841]

I was wondering on the 264MHz overclock and what was behind this ? I was under the impression that in using the HSTX (due to it writing on rising and falling clock pulses) would result in lower overclock than if using PIO. I thought one could get 640x480 at stock frequency?

[jepler]

This library uses many modes based around 1280x720@50p, which requires a 528MHz HSTX bit rate. This requirement/limitation is inherited from the original dvhstx project.

Making it more flexible so that it did not use a large overclock with 640x480 would be a very good addition.

[Macrosii]

Many thanks for the reply. I will post a request on the original dvhstx project (which seems to be related to Pimoroni ? Who also sell PICO boards with PSRAM).
Interestingly with a 300MHZ overclock (from the IDE) and a PSRAM frequency of 75MHz, a basic script accessing PSRAM works, but with the 264MHz overclock and a PSRAM frequency of 88MHz or 66MHz it crashes. So its not just the absolute value!

[jepler]

I wish I understood the clocking details better myself.

Early during board boot clocks are configured in a specific way here and then when a display is actually started further modifications are made.

[Macrosii]

So to give you an update and thanks to @dan2wik for help on the previously mentioned discussion.

1. To get the Feather HSTX (no psram) reliably running with this library I have had to up the CPU vore voltage to 1.25v. This is found in "dvhstx.cpp"(around line 293) as follows "vreg_set_voltage(VREG_VOLTAGE_1_25)"
2. To get psram working I had had to adjust the psram timings in the @earlphilhower core. This is in the file psram.cpp around line 198. The mods are show below with the data "07MAR2025"

Its been running ok for over an hour now. I will report back if I have any further issues!

Regards

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 | 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);
}

[jepler]

That's good info. I think we'll have to cooperate with @earlephilhower so that the correct OC settings for DVHSTX can be chosen in the Arduino configuration menus. But before I can propose anything I have to understand the reasons for the current clocking settings.

Howerver I notice that there is a function psram_reinit_timing and the comment says // update timing -- used if the system clock/timing was changed.. Maybe try experimentally adding a call to this somewhere, like at the top of setup(), or at the bottom of display_setup_clock_preinit in Adafruit-DVI-HSTX.

If adding the call at the bottom of display_setup_clock_preinit fixes your psram problems that would be a great PR for you to offer us.

[Macrosii]

@jepler
So after around two hours the setup hung. So currently running on a Feather HSTX with no psram to see if its still related to the core voltage or the PSRAM timing. Will leave running overnight and get back Then will give the "psram_reinit_timing" a look at.
BTW just seen the video of "Text mode HSTX DVI output on the Fruit Jam", looks great (will be getting one of those when it weaves its was over to the UK). Are you going to release a demo of that mode here ?

[Macrosii]

Just to update this thread. Using new PSRAM timing from @Michealbell I was able to get PSRAM running with some simple testing. However in trying to do extensive PSRAM tests at the same time as some real HSTX video work I was getting some crashes. However it might not be PSRAM issues, as with HSTX included but no graphics commands in "loop" I can perform full multiple testing of PSRAM. I think I need to understand the library operation better!
@jepler Where is the best place to ask questions on the library operation and integration with Adafruit GFX ?

[jepler]

If you have a simple, minimized crash reproducer then opening an issue is most appropriate. Otherwise, the adafruit forum & adafruit discord are places for open-ended dicussion.

[jepler]

as for psram timing my colleague @eightycc has been looking at how to configure PSRAM when overclocking over at
adafruit/pico-mac#7

Compared to the arduino-pico set_psram_timing, I think the following details are observed:

• properly set the rxdelay register
• toggle "wrap boundary mode"

We're currently validating this code on Fruit Jam, which has an AP6404 PSRAM. And by we, I mean @eightycc because I'm about to leave on vacation.

[ladyada]

hiya im around. tbh we aren't using the psram much yet with this code. i also just pushed the overclock down to 240mhz and 720p seems to still work, and it should improve the USB host support. if you have a PR and test example im happy to run it on hardware here