Call to arms | Teensy + SDRAM = true

@mjs513 - if github gets your best WIP I can see what shows here.
And it was noted there is NO .LD modification? I had seen that it didn't matter before IIRC - but it got to be a habit. That was only needed to export the SDRAM extmem values - the linker/build not placing anything there statically wouldn't need to know.
 
@mjs513 - if github gets your best WIP I can see what shows here.
Tim I am done for the day. The main branch is kind of final except for what Paul wants to do with startup. So have fun testing with your sketches remember to add no ops but one less tan Paul showed and comment out the 2mb region.
 
Last couple of days I have been getting a OV7650 camera working with the development board and using sdram for both the framebuffer and reading in the pixels.
That sounds like more fun!
Been using @KurtE's ILI9341_t3n and Arduino_OV767x (branch for Micromod) and the ILI9488 libraries (which need the framebuffer and pixel buffer in sdram). To do so had to hack the core_pins, digital.c and pins_arduino files to add in a pin that is available on the T41 but not the micromod. Finally got them working this morning for single frame capture and continuous stream modes - unfortunately the dmaupdate option didn;t work (seem to remember we always had problems with this with the HB01 library as well). Note: the Camera is using flexio since we don't have the CSI pins yet.
o_O - did not realize that part of the filename was a smilly face. I was earlier playing with the ILI9488_t3 library and with at least one example, I found a method I added to ILI9341_t3n (writeSubImageRect) was not implemented yet in this library. I have a local version, where I added it. Have not tested it fully yet as the camera image was not working.

An interesting issue cropped up - with the camera and display. When trying to run the ILI9341_t3n (no sdram needed) would loss the dev board until I commented out the SCB region. But if i just run graphicstest with it - no issues???
Wonder if it was setup that it was still trying to callocate 32 bits per pixel and did not fit?
 
@PaulStoffregen / @mjs513 / all: THAT WORKED!
- pulled the PJRC github LINKED startup.c - commented ONE //NOP - ALSO it goes back to 0x8---

ODD thing SDRAM_t4 library left at 0x9--- worked! ⁉️ {perhaps because warmstartup/upload SDRAM chip was already done .begin()}
Changed that SDRAM_t4 library to 0x8--- and LittleFS_SDRAM_Simple_Datalogger.ino WORKS! {after upload and Power On}

<edit> updated coreFiles\startup.c and SDRAM_t4[.h, .cpp]
Pushed Examples - note updated or cleaned and one a dupe
 
Last edited:
I'm trying to order the pcb through jlcpcb

The parts list for defragsters board shows an IMXRT1062DV_10X10

The only imxrt1062 jlpcb is showing in stock is MIMXRT1062CVL5B

Datasheet shows its the 10x10 chip. Will this work?
image001.png
 
Yes, the range is 80000000 to BFFFFFFF so of course 90000000 to 91FFFFFF is within that range.
Yes 'SIZE_1G;' would cover it? Just copy/pasted startup.c raw from github and looked at the start 0x80000000- then edited the SDRAM_t4 after first build/upload.
Will get the examples in order. Then post about the odd PSRAM fail when DEBUG.
 
@Dogbone06 do you have the pin spacings for your board? The vertical right rail and horizontal bottom rail positioning from your top horizontal rail. I assume they're standard 2.54mm between the pins

I use Kicad and would like to order a Breakout board at the same time to connect 24 bit parallel display and see if I can get the lcd_if pins working

*edit*
Do you have all 24 of the lcd_if pins exposed or just 16?
 
Last edited:
@Dogbone06 do you have the pin spacings for your board? The vertical right rail and horizontal bottom rail positioning from your top horizontal rail. I assume they're standard 2.54mm between the pins

I use Kicad and would like to order a Breakout board at the same time to connect 24 bit parallel display and see if I can get the lcd_if pins working

*edit*
Do you have all 24 of the lcd_if pins exposed or just 16?
Pins are 2.54mm pitch
All 24 data lines and additiona 4 control lines (hsync, vsync, pxclk, de) have been exposed.
As mentioned before, all 32 FlexIO2 pins have been exposed. LCD pins are on the same pads with a different ALT setting - You can find the pinout on page 1876 of the reference manual, chapter 35.4
 
o_O - did not realize that part of the filename was a smilly face. I was earlier playing with the ILI9488_t3 library and with at least one example, I found a method I added to ILI9341_t3n (writeSubImageRect) was not implemented yet in this library. I have a local version, where I added it. Have not tested it fully yet as the camera image was not working.
:) Yeah - the writeSubImageRect method is not implemented yet in the ILI9488 library - I pulled down the branch with the same name from you ILI9488 library for testing - maybe its time to push it up into the ILI9488 library?


Wonder if it was setup that it was still trying to callocate 32 bits per pixel and did not fit?
that looks like its been fixed with the addition of the nop's - I hope.
 
ODD thing SDRAM_t4 library left at 0x9--- worked! ⁉️ {perhaps because warmstartup/upload SDRAM chip was already done .begin()}
Changed that SDRAM_t4 library to 0x8--- and LittleFS_SDRAM_Simple_Datalogger.ino WORKS! {after upload and Power On}

<edit> updated coreFiles\startup.c and SDRAM_t4[.h, .cpp]
Pushed Examples - note updated or cleaned and one a dupe
@defragster - if you look at post #400 you will see I tested that as well.

Note I did my testing with 0x9..... didn't see the need to change the range.

Now if we are changing the lib to 0x8..... I have to retest my test cases.
 
@PaulStoffregen - @defragster
Tested the changes on the I2C test board (lidar lite, bno080, 055, mpu9250, ssd1306 and Fram) with the T41 and the devboard - no issues.

Also retested Camera/Display sketches from Post 400 and they worked as well.

So no issues with adding the nops and changing the address back to 0x8....

Just to confirm this is what was tested:

Code:
    SCB_MPU_RBAR = 0x80000000 | REGION(i++); // SEMC: SDRAM, NAND, SRAM, etc
    SCB_MPU_RASR = MEM_CACHE_WBWA | READWRITE | NOEXEC | SIZE_1G;
    // SDRAM PCB: https://forum.pjrc.com/index.php?threads/73898/#post-334041
    // software: https://github.com/mjs513/SDRAM_t4

    asm("nop"); // allow a few cycles for bus writes before enable MPU
    asm("nop");
    asm("nop");
    asm("nop");
    asm("nop");
    //asm("nop");

one less nop
 
I've added "Uses SDRAM_t4 library" with a link to the library on the T4 bootloader chip page, under "User Shared Projects". Hopefully if more people who want to use SDRAM find this (now over 400 messages) thread, this extra link will help them quickly get to the software they need.


Either then 0x8--- or 0x9--- : wasn't sure if there was a reason/preference.

I personally do not have any preference. For normal usage with sdram_malloc(), all access is done through the returned pointers so the user's program would automatically work regardless of the mapped address.

The large default range is meant to theoretically allow future custom PCBs to use the memory types SEMC can support. It can use more than just SDRAM. Even with SDRAM, I recall reading in the reference manual that it might be able to support up to 4 separate chips.
 
@mjs513 - the properties didn't include the supported class names as I was editing ... they should be added.
I still need to delete one of the examples I uploaded when seeing trouble and then comment and clean the others I have there.
 
I'm considering adding photos to those "User Shared Projects", so it will be visually interesting rather than looking like a footnote at the end of a long page.

@Dogbone06 - Do you have a photo I should use? Or should I just grab something from a prior message?
 
Back
Top