Call to arms | Teensy + SDRAM = true

Hi Dogbone06, I have notice that you have order DevBoard5 frmo JLC some time before. Do you have already finish test of the board and if it is work OK. or have you test DevBoard 4.5. Is it work OK. Thanks.
As far as I can remember, I never said they were ordered from JLC, what's that?
 
I just want to know if the DevBoard5 has been tested. And it works.
I suggest that you read through this thread. Sure it may take a little time but there's a ton of information and knowledge in here that has gathered over the course of time when we developed this. There's code and pin mappings. Which you will need to find the board useful.

Atleast read throught the last 25 pages if you're in a hurry. Your question will be answered in doing that.
 
Indeed, a batch of the DB 5.0 boards were made and distributed months back and they are working well. A batch of DB 4.5's were also made and distributed to a few people and they work and have seen use, but the DB 5.0 layout came with extended pins and features and is the main board being used the most.

One critical change for the SDRAM function is having the 10 pF capacitor in place for reliable use, especially when over clocked.

The boards were made with the 528 MHz Automotive type part and work well - even at 600 MHz but required a modification to the voltage curve. Using the standard temp 600 MHz part should not have this concern.

<edit> missed page change and final posts ... indeed above summary should be correct to many prior postings.
 
Hey all! I'm playing with a 5" 16 bit screen using eLCDIF together with LVGL which works nicely.
Me and @Rezo are a little curious on how to use the Pixel Pipeline to rotate the screen. Seems that Mike made a library.

Library: https://github.com/mjs513/T4_PXP

It would be nice to be able to do something like "lcd.rotate(90);"
Is it also possible to rotate odd numbers like say 33 degrees or is it just 4 rotations available?
What would be the proper way to do this having eLCD and PXP work together?

I use two buffers stored in SDRAM.
1731058739940.png


I then have the LVGL display flush function.
1731058777066.png


Display stuff is initialized here:
1731058853497.png
 
Hey all! I'm playing with a 5" 16 bit screen using eLCDIF together with LVGL which works nicely.
Me and @Rezo are a little curious on how to use the Pixel Pipeline to rotate the screen. Seems that Mike made a library.

Library: https://github.com/mjs513/T4_PXP

It would be nice to be able to do something like "lcd.rotate(90);"
Is it also possible to rotate odd numbers like say 33 degrees or is it just 4 rotations available?
What would be the proper way to do this having eLCD and PXP work together?
Been a while since I played with pixel pipeline but from what I remember you can only rotate in 90 degree increments.

Not sure how to incorporate into LVGL. This example would probably help.
 
Thanks for all the people that worked on this to figure it out how to add sdram and creating libraries to work with it. I certainly would not have tried as it is beyond the scope of what i know how to do. So . . . I am starting to work on creating a custom board for a project of mine and wanted to use what was presented here as a basis for it. Unfortunately I am no master at routing and have no clue what I am doing. I didnt want to do a copy paste as I am using an mcu with a slightly larger footprint and doesnt align to this one (same mcu just different size as I already have a stock of them). shown below is a general trace layout of a 6 layer board between the 2 chips (left is sdram same as the one used in this thread and right is the imx). I have not added any additional circuitry or components yet as I wanna make sure the routes work for this before i go ahead and add em in. The idea is to use the sdram at the rated max of 166MHZ. bottom layer is the data lines and top layer is the address and control lines. i wasnt to sure about the length matching as i dont really understand how the timings work so generally followed this doc by issi (https://www.issi.com/WW/pdf/appnotes/dram/AN42S01.AN.pdf) which has general rules for layout of sdram. The only thing i am unsure about is the lengths. The difference between the longest and shortest lines is about 14mm for data lines and 10mm for address lines. In the guide they state a max difference of 20mm is needed. This would be on a more space constrained board so i needed the sdram to be as close to the mcu as possible (plus i just hear that it should be like that in general). also this does have a ground plane between the lines its just not active in the images. Idk what other information is needed but the connections are the same as in the dev boards, just routed to be closer. Maybe yall cant say with certaincy if it will or wont be fine but as a general is it ok to have that much difference between the longest and shortest path. Also forgot to mention the longest trace is 21mm if that has any bearing on this. Oh and what is the purpose of the zero ohm resistor on the clock line? Is it just to be able to swap resistors to get different impedences on the fly?
 

Attachments

  • front.png
    front.png
    495.5 KB · Views: 36
  • back.png
    back.png
    506.9 KB · Views: 38
Last edited:
Been a while since I played with pixel pipeline but from what I remember you can only rotate in 90 degree increments.

Not sure how to incorporate into LVGL. This example would probably help.
I recall reading in the RM that the PXP can work async with the eLCDIFA bit on each of their control registers needs to be enabled.
Then you can feed the PXP with to partial/full screen sized buffers, it will swap between them automatically and push the rotated image out to the LCD controller.
Section 36.3.1.19 - LCDIF Handshake on page 1927

So the way I understand it, the PS buffer would actually be one of the LVGL allocated buffers (which are allocated to SDRAM) , and the out buffer are actually two smaller buffers in SRAM and work directly with the LCDIF.
@jmarsh have you ever played with PXP and the eLCDIF and handshake before?
 
Last edited:
Maybe yall cant say with certaincy if it will or wont be fine but as a general is it ok to have that much difference between the longest and shortest path.
I basically copied the traces from the MIMXRT1060_EVK design files on the NXP site. I certainly can't tell if what you have will work, but here are some details from the kicad trace inspector for the GPIO_EMC_* traces in my design:
2024-11-10-135120-screenshot.png
 
You need to map the pad to the “pin”
The technical manual has two very long tables of each packages pad name and assigned pin/port.
 
You need to map the pad to the “pin”
The technical manual has two very long tables of each packages pad name and assigned pin/port.
thanks for the reply. I had just looked into how to actually do the math for the timings and yeah . . . i am way off . . .
 
I'm finally finding the time to try and make an sd ram board.

I've been using the teensy 4.1 schematic and have managed to open up dogbones Gerber files in kicad to look at the routing.

@Dogbone06 would I be able to get a copy of your schematic?

Also do you think 0805 sized components would work instead of 0402 or would the distances be to great from the pins for some of them? Hoping to solder the pcb myself and I have tons of 0805 components
 
I'm finally finding the time to try and make an sd ram board.

I've been using the teensy 4.1 schematic and have managed to open up dogbones Gerber files in kicad to look at the routing.

@Dogbone06 would I be able to get a copy of your schematic?

Also do you think 0805 sized components would work instead of 0402 or would the distances be to great from the pins for some of them? Hoping to solder the pcb myself and I have tons of 0805 components
Regarding 0805 is not possible when it comes to the IMXRT dependencies. Meaning caps and resistors that it need. As the space is very crammed. I suggest using what I use to minimise error and faults.

This thread is super long and I don’t have the time right this moment to search it. But it’s all in this thread, schematic and all.

I don’t know how skilled you are with soldering but I highly suggest letting a PCB factory do the job. Soldering BGA-196 is no easy task.
 
Last edited:
Regarding 0805 is not possible when it comes to the IMXRT dependencies. Meaning caps and resistors that it need. As the space is very crammed. I suggest using what I use to minimise error and faults.

This thread is super long and I don’t have the time right this moment to search it. But it’s all in this thread, schematic and all.

I don’t know how skilled you are with soldering but I highly suggest letting a PCB factory do the job. Soldering BGA-196 is no easy task.

Thanks. I decided to go the easy route and get your board premade. Will be a bit before it gets here.

As for the sdram and extra pin support. Do yiu have a downloadable copy of your micromod setup? (Perhaps you should link that into the first post of this thread) Was the sdram set into a library or you baked it in to the micromod changes?

Many thanks!
 
Thanks. I decided to go the easy route and get your board premade. Will be a bit before it gets here.

As for the sdram and extra pin support. Do yiu have a downloadable copy of your micromod setup? (Perhaps you should link that into the first post of this thread) Was the sdram set into a library or you baked it in to the micromod changes?

Many thanks!
In order to avoid using custom cores to support the added pins for this project, we configured those extra pins on the MUX level, on a need to basis.

So using standard Teensy APIs on the newly exposed pins for Analog,Digital,PWM etc won’t work without mods

@KurtE did did some work for a Teensy Cores Variant that defines the extra pins with numbers etc.. but I never fully tested it
 
@KurtE did did some work for a Teensy Cores Variant that defines the extra pins with numbers etc.. but I never fully tested it
Note, my fork/branch is probably somewhat out of date, with the most recent cores. That is, I believe I am 6 commits behind the master
branch. At some point I will probably rebase on the current stuff. However, I am not sure if/when that might happen.

My guess is that Paul is not interested in supporting variants. As none of the changes have not been pulled in, nor have I seen any feedback on them. Currently playing on other stuff...
 
get your board premade
That CAP over (USB left and slikscreen DevBoard upright) the 1062 worked out at 10 pF - not sure if that was in the order as placed? IIRC it worked at spec speed of 166 MHz without - but that value seemed to generally work up to and a bit over 200 MHz.
 
That CAP over (USB left and slikscreen DevBoard upright) the 1062 worked out at 10 pF - not sure if that was in the order as placed? IIRC it worked at spec speed of 166 MHz without - but that value seemed to generally work up to and a bit over 200 MHz.

Is that C29? BOM is showing c29 as 10pf. It connects to B7 which is EMC_39
 
Power comes through USB as used here, never looked beyond that.

I don't see a battery "PIN" for the RTC section.

I do see silkscreen "8-32 V Input" on the corner silkscreen by the " + / - " - but not ever used that.
 
A
Power comes through USB as used here, never looked beyond that.

I don't see a battery "PIN" for the RTC section.

I do see silkscreen "8-32 V Input" on the corner silkscreen by the " + / - " - but not ever used that.

Ahh yep. I'm trying to work put how the power delivery goes (I don't have the schematic but have exported the board to kicad board viewer)

I though Vin and Gnd dual pin might be a battery port. They connect to an IP6520 which I think is a usb c power delivery chip (handles higher input voltage and handshakes for usb c charging?)

But I don't see the usb port connected to it, so perhaps I'm completely wrong.
 
Back
Top