Call to arms | Teensy + SDRAM = true

Rezo said:
@mjs513 @defragster could either of you supply an image of the dev board from up top for the pjrc bootloader page?
Click to expand...
IMG_1056.jpg


@Paul - I can resize it if you want
 
Received my board today.

Unfortunately I can't get the SDRAM to function correctly - SDRAM_t4::begin reaches the bottom and fails the pattern check. The same with pretty much any other test, the entire SDRAM always reads 0 no matter what/where is written.

Edit: Figured out why... you guys hardcoded the SDRAM_t4 library to configure the board as if the DQS has no capacitor on it.
 
Last edited:
jmarsh said:
Received my board today.

Unfortunately I can't get the SDRAM to function correctly - SDRAM_t4::begin reaches the bottom and fails the pattern check. The same with pretty much any other test, the entire SDRAM always reads 0 no matter what/where is written.
Click to expand...
Unless/until you desolder this CAP
1705472297804.png

You need to edit the library code in SDRAM_t4.cpp to pass the ELSE case
//if(NOCAP == 1) { SEMC_MCR |= SEMC_MCR_MDIS | SEMC_MCR_CTO(0xFF) | SEMC_MCR_BTO(0x1F) | SEMC_MCR_DQSMD; //} else { // enable SEMC_MCR_DQSMD (EMC_39 // SEMC_MCR |= SEMC_MCR_MDIS | SEMC_MCR_CTO(0xFF) | SEMC_MCR_BTO(0x1F); //}

Note: CAP is gone here. Had a wide tip on the iron and some flux paste and it pushed off easy - tweezers ready to grab it from the iron.
 
Last edited:
That seems a bit silly when the default hardcoded speed is 133MHz which works fine with DQSMD set to zero. If someone is going to edit the code to adjust the speed they can also change the MCR register setting, otherwise the default setting should work with unmodified boards...

The malloc stuff is also broken because the base address was changed back to 0x80000000 but extmem.c is still checking for 0x9 in the most significant bits.
 
Last edited:
I would perhaps move the CAP/NOCAP to be in the begin function call. For example: sdram.begin(32, NOCAP); and perhaps also another argument to change the speed from 133 to the other higher options
 
The SDRAM part is spec'd at 166MHz. Not sure why clockdiv = 5; set for 133 MHz ? It should be running at 166 MHz based on part spec and the testing done here.

AFAIK the cap was only included on these DEV boards because the NXP board may have had it. The value is wholly wrong for any use - and without the cap the SDRAM runs seemingly fine at 198 MHz - and with 'HACKY' CAP adjustment it works somewhat at 212 - but that was just answering a question Paul had and with a proper cap it may function at 212 MHz ... but way OC'd for marginal gain over 198 MHz.

@jmarsh - the silkscreen notes 'DevBoard' and the prior rev didn't seem to work at all for @Dogbone06 - he only made two with the first coming here to quickly see it work over Christmas weekend - so another batch of 5 without changes was made for this wider release.

The extmem won't have support - that requires larger changes in PJRC/cores. So the SDRAM_t4 library was extended to offer dynamic malloc support - but nothing compile time static like for PSRAM on the T_4.1 PJRC product at this point with TD 1.59 in late beta with minimal MPU change to allow the SDRAM_t4 lib to work without edits to the main startup.c file - and include the needed SEMC raft of #defines for addressing access {in beta 5 AFAIK - until then manual overwrite}.

Also complete pin support is lacking from T_MM - even though it is identified as a T_MM because it has a 16 MB Flash on the bottomside. The left side labels follow from T_MM but the right side - while having some T_MM pins - was designed as 16 bit port support for the work @Rezo has with larger displays.

Yes, it might be nice to control the SDRAM speed from a parameter - and the NOCAP option is just a DevBoard artifact as it has been found that it is not required or desirable with the code Paul supplied when the errant CAP is removed.

Not claiming to be qualified to use a soldering iron - but it worked easily and far enough from the MCU chip that flux paste residue wiped off without needing to wash the board. Even managed to solder and remove 30ga WW wires for CAP testing without issue. So, suggest removing it given the tools and some experience fo knowing which end it the hot one :)

The change to 166 MHz with clockdiv = 4; was just pushed to github. The CAP did not live long on the board here and most extensive testing done at 166 MHz or higher so use at 133 MHz was early or by accident.

I need to get back to cleaning the examples I touched - With busy holidays been on a break with wife having a couple days off - and it being awful cold with the woodstove getting more attention.
 
There's a public facing PJRC page with a picture of "DevBoard 4.0", linking to the current board's design, with a link to the github repo saying "Uses SDRAM_t4 library" - which doesn't work properly out of the box. Sure, it is clearly stated to be a user-created project but if someone actually went to the effort of making their own they would expect the linked software to support it by default...
 
jmarsh said:
There's a public facing PJRC page with a picture of "DevBoard 4.0", linking to the current board's design, with a link to the github repo saying "Uses SDRAM_t4 library" - which doesn't work properly out of the box. Sure, it is clearly stated to be a user-created project but if someone actually went to the effort of making their own they would expect the linked software to support it by default...
Click to expand...
And it will when TD 1.59 Beta 5 releases. Again (p#438 notes) this came to life in the past weeks faster than a Beta update could be validated and published. When that happens the CoreFiles folder can go away and no user mods will be needed - and for now those files are included in the github repo.

I just used the latest SDRAM_t4 and built and ran ~5 test sketches to work at the pushed 166 MHz speed. If pulling the library and dumping the two CORES files doesn't work, please make notes. Beta 5 is coming in some few days ideally and all will be easier.

readme:
Currently two additional core files have been changed imxrt.h and startup.c. These are located in the coreFiles directory of the repository. When Teensyduino version < 1.59 is used you will need to copy these files to the teensy 4 cores directory on the computer.
Click to expand...
 
Obviously you've modified the board from the design that is linked, to remove the capacitor.
And the repo is still additionally broken because the earlier issue I pointed out in extmem.c hasn't been corrected, so I don't know how all your tests are functioning correctly.
 
Just fed the woodstove and cat on the way to Zzzz's

@mjs513 crafted the repo from the sources started on an untamed @defragster repo, when there was one board in the wild for some 10 days until @mjs513 got the second about New Years - and the added boards are just arriving and the Beta 5 of TD 1.59 hasn't dropped to ease the process.

There is an extmem.c file - that provides only the needed sdram_malloc() [etc.] DYNAMIC interface to the struct smalloc_pool sdram_smalloc_pool;

Not sure what is there on github that isn't here - but SDRAM.BEGIN() works - there is no Static alloc from EXTMEM/PSRAM type usage supported as that cannot be safely added to PJRC cores for a T_MM variant without creating a NEW BOARD ... where some 21 files have obvious #ifdef.

@PaulStoffregen has some odd fascination with SDRAM {so his post for hardware 'nobody' has may be have been some days hasty) and has been beyond valuable in getting this working with needed code in SDRAM_t4 for .begin() and a way was found to support the dynamic malloc - or brute 0x800000 addressing - of the SDRAM. And copies of the DevBoard PCB layout maybe here - but not seen the @Dogbone06 has posted them fully with updates for no cap and maybe a larger footprint for that - even unlikely anybody else could have them in hand yet.
 
Th DevBoard is just that, a devboard. It was made for one reason: Make SDRAM run on the Teensy platform. In the NXP EVAL schematic, the cap was present. What I did was simply copy it as closely as possible. I even did the same thing with the traces. All to eliminate human error.

The DevBoard will never be sold (atleast not by me, feel free to do so if you want). It's just a development platform.
Altho I plan to make a gen5 of it with more pherips sich as USB HOST, SDCARD and a few other things.

In just weeks, Defragster, Mjs513, KurtE and Paul has slapped together this library. It works but may still have bugs or faults.

In the end, this was all done in record time which is impressive. Anything that's not perfect yet, we can all help out to make it so. :)

I still don't know if the Cap should be there or not as "standard". Since the SDRAM is made for 166MHz, that's also what it should run at as standard. Anyone wants to go higher fine! But that's overclocking.

So please let me know, should the Cap be a standard thing or not?
Paul wants me to try different values and I plan to do so, once the library is considered Complete by everyone.
 
jmarsh said:
The malloc stuff is also broken because the base address was changed back to 0x80000000 but extmem.c is still checking for 0x9 in the most significant bits.
Click to expand...
Thanks for pointing that out - was not changed back from 0x9.... Just pushed that changed. But becareful when you say broken because it is working and putting things in the right places based on testing.

github.com

changed extmem.c to 0x8... · mjs513/SDRAM_t4@a131d07

Contribute to mjs513/SDRAM_t4 development by creating an account on GitHub.
github.com github.com

jmarsh said:
current board's design, with a link to the github repo saying "Uses SDRAM_t4 library" - which doesn't work properly out of the box. Sure, it is clearly stated to be a user-created project but if someone actually went to the effort of making their own they would expect the linked software to support it by default...
Click to expand...
Be advised the final board, i.e., cap or no cap, is still up in the air. The lib was designed around NOCAP since I assumed the cap would be absent in future designs. The code was left in place just in case just commented out. Note in my testing running at 166Mhz did cause some issues with framebuffers when testing with the ILI9488 as I mentioned in another post of the 400+ that we are at.

Rezo said:
I would perhaps move the CAP/NOCAP to be in the begin function call. For example: sdram.begin(32, NOCAP); and perhaps also another argument to change the speed from 133 to the other higher options
Click to expand...
@Rezo - good idea - will to that today.
 
Dogbone06 said:
So please let me know, should the Cap be a standard thing or not?
Paul wants me to try different values and I plan to do so, once the library is considered Complete by everyone.
Click to expand...

So far we only have Defragster's initial testing which shows the capacitor seems to allow better timing. Final word on the best capacitor value to use really depends on better testing.

Did you get the candidate capacitors from Mouser that I recommended?


jmarsh said:
Obviously you've modified the board from the design that is linked, to remove the capacitor.
And the repo is still additionally broken because the earlier issue I pointed out in extmem.c hasn't been corrected, so I don't know how all your tests are functioning correctly.
Click to expand...

He's using the latest core library from Github. Things have moved quickly here!

This is typically how software development works. Software transitions from "development" to "beta" to "stable". Sometimes more names like "alpha" or "release candidate" are used. But the general idea is the same. The Github repository gives access to the very latest code. Over time, as testing is done, releases are made at specific points where we believe the software is suitable for a wider audience. Those releases always lag behind, because testing takes time and pretty much always involves uncertainty before reported issues are fully understood.

I had meant to release 1.59-beta5 a couple days ago. But I got bogged down in testing compile errors with certain libraries (and a variety of problems with the script I use to test compiling hundreds of libraries against a couple hundred combinations of hardware and settings). You can see on Github that commits have recently been made to address other non-SDRAM issues. At this very moment I'm still investigating a problem on Windows where the wrong board is rebooted, which I really want to fix before publishing 1.59-beta5. This is the very nature of making a release rather than using the lastest in-development code... reported issue deemed to be important are investigated and fixed or at least addressed.

If you had the impression this SDRAM dev board would be like a finished product, well, the reality is you joined the party a little too soon. In time 1.59-beta5 and finally a stable 1.59 software release will code. Eventually this lingering question about the capacitor will get sorted out (and I personally hope we'll really discover how the capacitor affects timing rather than just saying it works well enough without any capacitor), and future hardware will presumably be made with whatever capacitor is chosen. But right now, the reality isn't a clean and tidy final release. This is the unfinished in-development state that things have before they become final finished products!
 
Since this board is still kind of in the development phase, I changed
Code: 
begin
to

Code: 
begin(uint8_t external_sdram_size = 32, uint8_t NOCAP = 1, uint8_t clock = 4)

This will give you all bit more control without having to modify the library. Going to run some of the examples before finalizing.

@PaulStoffregen
Is this correct for the clocks:
Code: 
    /* Experimental note (see https://forum.pjrc.com/index.php?threads/call-to-arms-teensy-sdram-true.73898/post-335619):
    *  if you want to try 198 MHz overclock
    *  const unsigned int clockdiv = 2; // PLL2_PFD2 / 2 = 396 / 2 = 198 MHz
    */
    if(clockdiv == 2) {
        CCM_CBCDR = (CCM_CBCDR & ~(CCM_CBCDR_SEMC_PODF(7) | CCM_CBCDR_SEMC_ALT_CLK_SEL)) |
        CCM_CBCDR_SEMC_CLK_SEL | CCM_CBCDR_SEMC_PODF(clockdiv-1); 
    /* If it doesn't work, maybe try soldering a 5pF or 10pF capacitor at C29
    */
    } else {
    // use PLL3 PFD1 664.62 divided by 4 or 5, for 166 or 133 MHz
    // 5 = 133mhz
    // 4 = 166mhz - SDRAM rated,  see post #60
    // 3 = 221mhz
        CCM_CBCDR = (CCM_CBCDR & ~(CCM_CBCDR_SEMC_PODF(7))) |
            CCM_CBCDR_SEMC_CLK_SEL | CCM_CBCDR_SEMC_ALT_CLK_SEL |
            CCM_CBCDR_SEMC_PODF(clockdiv-1);
    }
 
If begin() will take optional input, please consider the 2nd parameter could be an integer for the desired clock speed rather than exposing low-level implementation details. So something like begin(32, 166000000) for 32 MB running at 166 MHz. Or maybe begin(32, 166).

Speed of 133 MHz or lower implies NOCAP.
 
PaulStoffregen said:
If begin() will take optional input, please consider the 2nd parameter could be an integer for the desired clock speed rather than exposing low-level implementation details. So something like begin(32, 166000000) for 32 MB running at 166 MHz. Or maybe begin(32, 166).

Speed of 133 MHz or lower implies NOCAP.
Click to expand...
Good idea - still working on first cup of coffee
 
@PaulStoffregen
Just a follow up - not sure running at 133 mhz implies NOCAP
Just Ran sdram_test (memtest of random and fixed patterns) (I have removed my cap so nocap =1 )
1. at 198 Mhz - PASSED: 42.81 seconds
2. at 133Mhz - PASSED: 48.02 seconds
3. at 221Mhz - FAILS :) with no cap.

So looks like I can run from 133 up to 198 with no problem with nocap - think Tim said this in one of his earlier tests

Begin now looks like this:
Code: 
begin(uint8_t external_sdram_size = 32, uint8_t clock = 166, uint8_t NOCAP = 1);

Will push the change for all your testing - will update examples accordingly. Will also have to do some more explaining in the readme so may take rest of day by the time I get done
 
Last edited:
You must log in or register to reply here.
Back
Top