Teensy 4.1 psram memtest

I think i know how to distinguish write/read failures. 1) Copy array with default slower 88MHz clock - verify data is same 2) Change clock to faster 3) Try to reproduce read failure 4) Copy array again with faster clock 5) Switch to default clock and verify data is same, if not - write failure

I will come back with a sketch in a day or two...
 
Pencioner said:
I think i know how to distinguish write/read failures. 1) Copy array with default slower 88MHz clock - verify data is same 2) Change clock to faster 3) Try to reproduce read failure 4) Copy array again with faster clock 5) Switch to default clock and verify data is same, if not - write failure

I will come back with a sketch in a day or two...
Click to expand...
Yes, that worked on the SDRAM - though had to change clock setting only - resending the IP commands to the SDRAM causes it to lose prior data. That may not apply to the PSRAM as it persists across warm restarts where the full init is already repeated using same SPI setup.
 
Well, long story short:

I got two 4.1s:

Name it Unit1 - no ethernet one and have two Adafruit PSRAMs installed, currently is soldered to a prototype. The PSRAM test sketch passes on all frequencies including 133MHz and below (120MHz, 110.77Mhz, and default 88MHz is what i tried)
Unit2 - one with ethernet chip (i don't think it makes a difference though), one Adafruit PSRAM and W25Q01JVZEIQ (1Gbit NOR flash) installed. On tests it was powered via USB. The PSRAM test sketch fails on 133MHz but passes on lower freqs

Story: as i posted, when i changed the frequency to 120MHz on Unit1, it was having a failure reads (bad data) from array in PSRAM. As i mentioned, i do not use Arduino in this project, so i patched startup code which sets clock for PSRAM. I realized what actually happens when i had no more ideas and i verified all bits of my code. So I made a copy of data in tightly coupled fast RAM and was comparing what it reads from both locations, flashing led if it is not equal. It was a surprise, as this unit passes test on 133Mhz. only with 110.77MHz or less it was stable. Other unit, Unit2, which can't pass test sketch on 133MHz was giving no issues on 120Mhz.

Story 2: I was trying to make an Arduino sketch to reproduce this issue with no luck. After quite a while i got an idea. As i said, the PSRAM clock code in startup.c was patched directly to set higher freq. Then i reverted this change, but instead, did a clock change later before i use PSRAM in my project. Damn! Issue disappeared! By some bad luck, it happens only when i set 120Mhz directly on startup code, and only on one of my two Teensies...

So, given that i spent a lot of time already, and it is hardly reproducible, i believe i will leave this mistery with no further investigation. The smallest code which can reproduce it, only will reproduce if you patch the startup.c directly to set 120Mhz and only on one of my two units

C: 
EXTMEM uint8_t rom_e[16 * 1024];
extern uint8_t rom[16 * 1024];

extern "C" int main(void) {
    uint8_t data, data2;

    for (int i=0;  i< 16 * 1024; ++i) {
        rom_e[i] = rom[i];
    }

    __asm volatile ( "dsb \n" );
    __asm volatile ( "isb \n" );
    __asm volatile ( "dmb \n" );
    for (int i=0;  i< 16 * 1024; ++i) {
        data2 = rom[i];
        data = rom_e[i];

        if (data != data2) {
            pinMode(13, OUTPUT);
            while (1) {
                digitalWriteFast(13, LOW);
                delayMicroseconds(500000);
                digitalWriteFast(13, HIGH);
                delayMicroseconds(500000);
            }
        }
    }

    return 0;
}

PS Not sure which of asm commands is enough to reset/flush caches (maybe you need only one, i added all i found just in case, without those this code works well)
 
That only tests 16KB, meaning it's probably skipping an entire chip in the case of the board with 2x8MB PSRAMs. I can't see at all how this is more of an in-depth test than the existing code.

Edit: actually at only 16KB, the entire test data would fit within the data cache. So it's not testing the physical memory at all.
 
i didn't mean that code posted is a complete testing. i only say that in my case i have this issue with as little as 16K of data (the rom content is in another file). if asm commands are removed it doesn't make any error because of cache of course, though i only undertand what 'dmb' does yet (other two i just picked after some googling), and the difference with existing test sketch as i understand is that sketch uses FlexSPI, while acessing an array/variable uses AHB bus. btw since it doesn't reproduce with another Teensy, it migh be some issue with particular PSRAM chip + some very exact timing. if anyone wants to have this one which has the issue, we can exchange - i'll send you my Teensy, you send me another. i'm not going to dive into it anymore, i don't have enough knowledge, and i want use the time for something more interesting. the strangest thing is: set clock in srartup code - problem is ON, change clock later - problem is OFF - that's what i really do not understand at all. if anyone is interested, i can tarball complete buildenv so you can try it yourself, but i'm not spending more time on it ))
 
In msg #20 you wrote "PSRAM memtest provided is not completely trustful and may say "all is fine" while it is really not".

In msg #23 I asked if you would share the specific test code you believe should be incorporated into the PSRAM test. So far only 1 program has been shown in msg #28, which is obviously not a valid test.

Just to be clear, I am not going to even look at this until a complete program is shown which can be used with Arduino IDE (allowing for the speed edited in the startup code but absolutely no edits in board.txt or platform.txt or other build settings). If a program which reproduces the problem with Arduino IDE can't be shown, I will not investigate.

I'm not saying the PSRAM test is absolutely bug free. Unlikely as it seems, you may have found a previously unknown problem. But I am saying I will not investigate problems without a test case shown. Test cases need to be usable with Arduino IDE without altering the compiler command line or other build settings.
 
Those asm instructions don't do anything with the cache, there is no feasible reason for them to be the difference between the test failing or succeeding.
 
on Arduino IDE it is not reproducible because it fails only if startup.c is patched with a clock change to 120MHz. if i change clock in setup() or loop() before doing anything, the issue is gone. that's a mystic bug tho. no need to investigate and i'm not asking you to do so. still, i believe that test is incomplete because it tests only the FLexSPI access to PSRAM while the AHB access is untested, that's why i said so - i hope you get now why i said "memtest provided is not completely trustful" - i had no intention to insult you. sorry. case closed, i'll be changing the clocks later, not in startup code, and then it works as it should

@jmarsh i think i remember now where i took those asm instructions... i found arm_dcache_delete implementation somewhere...
 
I believe i might undestand what happens (to some extent)

The code which detects PSRAM chips are switching them to SPI by issuing 0xF5 (exit QPI mode), then resets chips and uses 0x9F (read ID bytes) to detect is it is PSRAM or not, but command 0x9F as per Adafruit's datasheet is "similar to Fast Read, but there are no wait cycles and the device outputs EID value instead of data". So it is similar to "SPI Fast Read ‘h0B (Max frequency: 104 MHz)" - which means that if i switch to higher frequency (say, 120Mhz) right before it runs chip detection code, it just might fail as it is overclocked for this command and operation is not guaranteed, which means that chips are not detected or whatever shit happens... That explains why my problem occurs. So, you shoudn't initialize PSRAM clock with high freq, you should change it later, after detection. I have to admit that i was quite wrong with assumption that AHB is making problems while raw FlexSPI doesn't - it doesn't seem to be true. So my statement "memtest provided is not completely trustful" is a complete bullshit (but i wasn't too much into low level bloody details and didn't really understand a lot of stuff at the moment of writing). I'm sorry for that
 
You must log in or register to reply here.
Back
Top