Additional PSRAM ID that works plus goodies

I updated with Paul's latest startup.cpp and FS.h in cores along with the LittleFS.cpp, LittleFS.h and LittleFS_NAND.cpp library files.

My combined PSRAM and Flash test program that was hanging now runs OK with 16MB PSRAM and 2Gb NAND Flash. Also tested on a 8MB PSRAM and 2Gb Flash setup.

I then tried h4yn0nnym0u5e's test program in #82 again that was hanging on me. I commented out the PSRAM stuff since it isn't supported in Paul's stuff and changed it to NAND flash and it now also runs OK on my setup.

I then tried the updated test program in #93 after changing it to NAND Flash and it also runs OK, so good progress I think.
Code:
PSRAM 16MB: IDs deadbeef, cafebabe; QSPI base: 01000000 (16M)
LittleFS_QSPIFlash on W25N02KVZEIR
Bytes Used: 262144, Bytes Total:265289728
testFile2.txt contains 'Test file exists'
 
Noticing something quite odd with something that shouldn't be related whatsoever to PSRAM.
Try the following sketch:

Code:
#define CHECK 6
void setup() {
        CCM_CCGR7 &= CCM_CCGR7_FLEXSPI2(~CCM_CCGR_ON);
        CCM_CBCMR = (CCM_CBCMR & ~(CCM_CBCMR_FLEXSPI2_PODF_MASK | CCM_CBCMR_FLEXSPI2_CLK_SEL_MASK))
                | CCM_CBCMR_FLEXSPI2_PODF(6) // divisor + 1
                | CCM_CBCMR_FLEXSPI2_CLK_SEL(1); // clock 720/7=102.85
        CCM_CCGR7 |= CCM_CCGR7_FLEXSPI2(CCM_CCGR_ON);
        while(!Serial); // wait
        pinMode(CHECK, INPUT_PULLUP);

}

void loop() {
        Serial.println(digitalRead(CHECK));

}

digitalRead always returns zero...
What am I affecting?
 
@KenHahn
Don't have any 16mb qspi chips so ran with what I have doing the same thing that you described and running the #93 sketch:

Code:
PSRAM 8MB: IDs deadbeef, cafebabe; QSPI base: 00800000 (8M)
LittleFS_QSPIFlash on W25Q128JV-Q
Bytes Used: 16777216, Bytes Total:16777216
Attempt to create test file
testFile2.txt contains 'Test file exists'

Unfortunately cant find my Teensies with the nand chips to test

EDIT: Just as a further test for LittleFS on the Flash chip I ran the Integrity test sketch which seems to work indicating nothing broke on that end.
 
Last edited:
Is the chip access the same? 8MB .vs. 16MB ? What happens if the chip ID is just hacked/swapped to 'pretend' until more show up and limit access to 8MB?
 
digitalRead always returns zero...
What am I affecting?
Its been a while since I played with the clocks but you might have to stop the clock first, configure it and then restart the clock

EDIT> Know when I did for PSRAM:

C++:
void update_psram_speed(int speed_mhz) {
    // What clocks exist:
    static const int flexspio2_clock_speeds[] = { 396, 720, 665, 528 };

    // See what the closest setting might be:
    uint8_t clk_save, divider_save;
    int min_delta = speed_mhz;
    for (uint8_t clk = 0; clk < 4; clk++) {
        uint8_t divider = (flexspio2_clock_speeds[clk] + (speed_mhz / 2)) / speed_mhz;
        int delta = abs(speed_mhz - flexspio2_clock_speeds[clk] / divider);
        if ((delta < min_delta) && (divider < 8)) {
            min_delta = delta;
            clk_save = clk;
            divider_save = divider;
        }
    }

    // first turn off FLEXSPI2
    CCM_CCGR7 &= ~CCM_CCGR7_FLEXSPI2(CCM_CCGR_ON);

    divider_save--; // 0 biased.
    Serial.printf("Update FLEXSPI2 speed: %u clk:%u div:%u Actual:%u\n", speed_mhz, clk_save, divider_save,
        flexspio2_clock_speeds[clk_save]/ (divider_save + 1));

    // Set the clock settings.
    CCM_CBCMR = (CCM_CBCMR & ~(CCM_CBCMR_FLEXSPI2_PODF_MASK | CCM_CBCMR_FLEXSPI2_CLK_SEL_MASK))
                | CCM_CBCMR_FLEXSPI2_PODF(divider_save) | CCM_CBCMR_FLEXSPI2_CLK_SEL(clk_save);

    // Turn FlexSPI2 clock back on
    CCM_CCGR7 |= CCM_CCGR7_FLEXSPI2(CCM_CCGR_ON);
}
 
Its been a while since I played with the clocks but you might have to stop the clock first, configure it and then restart the clock

EDIT> Know when I did for PSRAM:

C++:
void update_psram_speed(int speed_mhz) {
    // What clocks exist:
    static const int flexspio2_clock_speeds[] = { 396, 720, 665, 528 };

    // See what the closest setting might be:
    uint8_t clk_save, divider_save;
    int min_delta = speed_mhz;
    for (uint8_t clk = 0; clk < 4; clk++) {
        uint8_t divider = (flexspio2_clock_speeds[clk] + (speed_mhz / 2)) / speed_mhz;
        int delta = abs(speed_mhz - flexspio2_clock_speeds[clk] / divider);
        if ((delta < min_delta) && (divider < 8)) {
            min_delta = delta;
            clk_save = clk;
            divider_save = divider;
        }
    }

    // first turn off FLEXSPI2
    CCM_CCGR7 &= ~CCM_CCGR7_FLEXSPI2(CCM_CCGR_ON);

    divider_save--; // 0 biased.
    Serial.printf("Update FLEXSPI2 speed: %u clk:%u div:%u Actual:%u\n", speed_mhz, clk_save, divider_save,
        flexspio2_clock_speeds[clk_save]/ (divider_save + 1));

    // Set the clock settings.
    CCM_CBCMR = (CCM_CBCMR & ~(CCM_CBCMR_FLEXSPI2_PODF_MASK | CCM_CBCMR_FLEXSPI2_CLK_SEL_MASK))
                | CCM_CBCMR_FLEXSPI2_PODF(divider_save) | CCM_CBCMR_FLEXSPI2_CLK_SEL(clk_save);

    // Turn FlexSPI2 clock back on
    CCM_CCGR7 |= CCM_CCGR7_FLEXSPI2(CCM_CCGR_ON);
}
Clock _IS_ stopped first.
It's as if any changes to CCM_CCGR7 causes the issue.
This causes the same problem:
Code:
        CCM_CCGR7 &= CCM_CCGR7_FLEXSPI2(~CCM_CCGR_ON);
        CCM_CCGR7 |= CCM_CCGR7_FLEXSPI2(CCM_CCGR_ON);

Nevermind, stupid mistake, "~" in the wrong place (facepalm)
 
Last edited:
ISSI chips are generally more expensive than ApMemory, and this new chip is twice the size. I'm curious to hear your thoughts about whether a more expensive PSRAM chip will be "worth it". Maybe for some applications but not for others?

I'm specifically asking about the qty=1 or qty=2 price for people building a one-off project with Teensy 4.1. Volume pricing matters for other people, but I'm really asking about building a memory intensive project with Teensy 4.1 where you build just 1 unit using just 1 or 2 chips.

Of course, nobody knows what price we'll eventually see for this new chip, but since ISSI's 8Mbyte chip has qty=1 price $4.45 at Digikey (about double the qty=1 price for ApMemory's chip of the same size), so a hypothetical qty=1 price around $9 seems possible if the price scales by memory size / silicon die size. Of course I hope it'll be less, but until better info becomes available, let's just hypothetically imagine people building one-off projects will pay $9 for this chip, or $18 to get 2 of them for 32MB.

That's quite a bit more than we're used to with the 8Mbyte ApMemory part. It is still worthwhile?
 
Last edited:
I'd imagine it's worthwhile for some applications, maybe where larger RAM plus Flash would be useful and an SD card can't be used (e.g. high vibration environments). Also it's not a ridiculous cost, given the Teensy 4.1 is over $30, so by the time you've built something useful you could easily be closing in on $100 once you've added display, controls and casework. At that point, an extra $14 to go from 16MB to 32MB feels less painful.
 
I am in the process of placing a production order, so I have some final pricing. ETA is not yet confirmed, but I don't think it will be very far out, probably sometime in August.

I don't know if these parts will eventually become available through normal distribution or not. If they do put it into their catalog it may be non-stocked with a minimum order requirement since it is a pretty niche product.

My plan is to offer them as a build option on my preconfigured Teensy 4.1's as well as to make the parts available for DIY people just wanting a couple.

Since part of my goal is to help make these parts available to the Teensy community, pricing would be set at volume pricing even for qty 1 which would put them at around $5.25 assuming no big surprises on the tariff side of things. I think these should be a very viable option for the Teensy crowd in a lot of cases. To h4yn0nnym0u5e's point, most of my customers are buying the Teensy 4.1 for best performance, not lowest cost.

The parts I have coming in are in trays, so will need to figure out a reasonable way to ship small qty. I don't usually ship SOIC loose in an ESD bag, so need to figure that out. Can probably tape them down to conductive foam with Polyimide tape.

Of course another step in the process will need to be a Teensyduino release with support for these parts or at least an accessible beta 5 release.
 
My plan is to offer them as a build option on my preconfigured Teensy 4.1's as well as to make the parts available for DIY people just wanting a couple.
sounds good to me - cant wait to order a couple :)

Since part of my goal is to help make these parts available to the Teensy community, pricing would be set at volume pricing even for qty 1 which would put them at around $5.25 assuming no big surprises on the tariff side of things. I think these should be a very viable option for the Teensy crowd in a lot of cases.
Thanks Ken - that is very generous of you, especially for the DIYers among us. Would normally go that route but soldering!!!
 
ISSI chips are generally more expensive than ApMemory, and this new chip is twice the size. I'm curious to hear your thoughts about whether a more expensive PSRAM chip will be "worth it". Maybe for some applications but not for others?

I'm specifically asking about the qty=1 or qty=2 price for people building a one-off project with Teensy 4.1. Volume pricing matters for other people, but I'm really asking about building a memory intensive project with Teensy 4.1 where you build just 1 unit using just 1 or 2 chips.

Of course, nobody knows what price we'll eventually see for this new chip, but since ISSI's 8Mbyte chip has qty=1 price $4.45 at Digikey (about double the qty=1 price for ApMemory's chip of the same size), so a hypothetical qty=1 price around $9 seems possible if the price scales by memory size / silicon die size. Of course I hope it'll be less, but until better info becomes available, let's just hypothetically imagine people building one-off projects will pay $9 for this chip, or $18 to get 2 of them for 32MB.

That's quite a bit more than we're used to with the 8Mbyte ApMemory part. It is still worthwhile?
Paul

For one off projects that should be no big problem.
Shipping would be higher.

I'm from the EU (aka outside the US) and then things get even worse. Shipping and customs handling are a substantial part. And then I'm not talking about tariffs, which are at the moment almost nothing, thus at the moment of writing.
 
I committed another update to LittleFS to remove the last 8MB offset stuff.

Preparing now to package up 1.60-beta5 with all the core library PSRAM and clock setup changes, and LittleFS which should automatically adapt to whatever PSRAM size is used.

Over the last week I've done quite a bit of testing using these 4 boards. Thanks to @KenHahn for sending me 3 of his ISSI sample chips. The first 2 of these 4 boards have those 16MByte chips.

1753086646241.png


For several days I was stuck on a difficult combination of lingering 8MB offset and a stubborn problem on 1 of the boards, which turned out to be a pin on 1 of the NAND flash chips not fully soldered. That "simple" mistake (which appeared as if certain PSRAM config was interfering with LittleFS QSPI NAND) is the main reason you haven't heard more from me on PSRAM for the last several days!

I've also updated the reference manual with annotations about the PFD clock gate trouble (pages 1029 and 1115-1116).
 
Last edited:
It would be nice if the configure_external_ram() function was moved out of startup.c (probably into extmem.c) to make it easier to replace without having to edit the core library, in case some other new chips show up (or in the case of SDRAM, configuring a completely different subsystem).
 
@KenHahn let me know (just found out) the 16MB PSRAM's may be a month away - perhaps longer - hopefully less if a partial shipment comes around. His order exhausted on hand production at the factory, so they penciled in a date late September to make more IIRC - to complete his order before shipping and other orders.
 
@defragster has it correct.

Since you cannot order the chips directly from the factory you have to go through distribution. The factory has indicated that they are fine with shipping a partial against the order, but they need the distributor to authorize it since they are the ones that actually placed the PO on my behalf.

Earlier this week I requested that their buyer amend their PO to the factory authorizing partial shipment. If that all happens as planned, the parts are probably about 3 weeks out. Worst case, if we have to wait for the new production run to complete, it would be more like late Oct to have parts.
 
@KenHahn, I idly dropped by your website, and noticed you stock the 23LC1024T for use as audio delay memory.

You may be interested to know that the standard PSRAM can just be dropped in as a replacement, and if my over-3-year-old PR ever gets pulled, people will actually get the benefit of 95s available delay memory o_O . Either way, when you run out, you could retire the 23LC1024T as a stock item.

Hmmm … I should update the code to allow use of the 16MB PSRAM, really … watch this space.
 
Since you cannot order the chips directly from the factory you have to go through distribution. The factory has indicated that they are fine with shipping a partial against the order, but they need the distributor to authorize it since they are the ones that actually placed the PO on my behalf.

Earlier this week I requested that their buyer amend their PO to the factory authorizing partial shipment. If that all happens as planned, the parts are probably about 3 weeks out. Worst case, if we have to wait for the new production run to complete, it would be more like late Oct to have parts.
@KenHahn

Thanks for the update Ken - cant wait. Already know what I want as well as a couple of other things going to order at the same time
 
My improved AudioEffectDelayExternal object has now been updated to allow the use of the 16MB PSRAM on the Audio Adaptor, as well as the older SPI-based options, 8MB PSRAM, 8x8MB PSRAM, EXTMEM and heap. It is of course much slower than fitting it as EXTMEM.
 
Back
Top