Call to arms | Teensy + SDRAM = true

Hey folks, any update on how the v5 devboards turned out? Is everything working as expected?

I'm about to head down the dual frame buffer + elcdif rabbit hole, and given @Rezo 's success I'm thinking the lastest schematic/pcb posted in this thread would be the best place for me to get started. Any notes on the new boards would be greatly appreciated 🙏
 
sndsgd said:
Hey folks, any update on how the v5 devboards turned out? Is everything working as expected?

I'm about to head down the dual frame buffer + elcdif rabbit hole, and given @Rezo 's success I'm thinking the lastest schematic/pcb posted in this thread would be the best place for me to get started. Any notes on the new boards would be greatly appreciated 🙏
Click to expand...
Some very strange crashes has appeared on all the devboards. But jmarsh figured out that increased the voltage just a little, seems to solve it completely. I'll let those guys post about it.
 
The new versions 4.5 and 5.0 of the DevBoards just arriving to larger test group. Some Crashes appeared not seen the same on the V4.0, except perhaps rarely.

It seems to be related to the use of the Industrial 528 MHz MCU. Also used at 600 MHz not paying attention to the chip type on the V4.0 board it seems the new PCB with altered layout and presentation of extended functionality seems to have put new 'stress' on the MCU in use.

Seeing Crashes at 600 it was dropped to 528 MHz and still crashing with a test sketch with the 1.15V voltage level set by the Teensyduino at that speed. Those crashes persisted until the voltage was elevated toward 1.25V used at 600 MHz (anything over 528) and that seems to have made it stable at 528 MHz.

And going over 528 MHz seems to be stable with an altered voltage curve that is under test with new PCB's using that lower speed Industrial part.
 
Assuming the 10x10 commercial variant of the MCU has the same ball layout as the industrial variant, you could probably just use it instead and avoid the issue. No idea what the availability is like though.
(In order to get the MIMXRT1062CVL5B to run at 600MHz, we have to overvolt it to 1.3V which is outside spec and possibly shortens the lifespan.)
 
Yes, it is the small 10x10 drop in T_4.0 sized replacement - but those are what @dogbone got it seems, as other use may call for it.

1.3V is higher than years tested T_4.x's have done. I wonder if there is something about the design that is wanting the higher voltage - assuming the spec PJRC used calls for 1.15 at 528 on normal 1062. Maybe the Industrial part has some other changed elements to be 'industrial' - beyond being 528 MHz spec? ANd it calls for hihger voltage to offset that and that is part of the 528 limitation?
 
Thanks for the details.

It sounds like the assumption right now is that using the ...DVJ6B chip variant available on the PJRC store and elsewhere on the internet would address the issue, but that particular variant is less available (or just not available) at fab houses that are used for PCB assembly. If this assumption is correct, I'd be happy to test the theory if I could get my hands on a v5 devboard. I believe I'd need to purchase a fresh MKL02 chip from PJRC if fuses have already been initialized, but that'd be fine as I'd need to get the DVJ6B IMXRT1062 chip anyway. And as far as soldering confidence goes, I've been able to replace BGA chips using hot air before, and I'm guessing QFN chips will work with similar treatment.

Either way, I intend to create some custom PCBs with the ...DVJ6B chip and SDRAM in the near future so I'm happy to help. That said, I'd rather not incurr the cost of a small batch of PCBs + partial assembly if there are known issues with untested or less than high confidence solutions.
 
Whoops, I just realized the significance of 10x10. It looks like the devboard should use the DVL6B variant of the chip? It looks like that is available at both Mouser and Digikey, so perhaps a rework attempt is still possible?
 
Last edited:
I wouldn't bother trying to retro-fit a "6" chip to the existing boards, it would be way more trouble than it's worth just to gain another "safe" 72MHz of clock speed. It's just something to consider for anyone making their own boards; the existing ones we can overclock to 600 if we really want to (at the risk of burning them out).
 
@PaulStoffregen do you happen to know if it's possible to detect which MIMXRT1060 variant is present? Possibly something in the fuses, because I noticed Teensys (DVJ6B) have bits 15, 13 and 12 set in HW_OCOTP_CFG5 while the devboards (CVL5B) have them cleared. Those bits are reserved according to the reference manual.
 
@Dogbone06 using the 528 MHz chip by design. For the more higher grade Industrial spec. of Temp Range etc.
Just understanding this - and generally the other boards he's made only run at 150 or 240 MHz.

So for these DevBoards we just need to adjust and they won't have reduced service life if OC's
 
defragster said:
@Dogbone06 using the 528 MHz chip by design. For the more higher grade Industrial spec. of Temp Range etc.
Just understanding this - and generally the other boards he's made only run at 150 or 240 MHz.

So for these DevBoards we just need to adjust and they won't have reduced service life if OC's
Click to expand...

528MHz is pretty fast, should be adequate for most applications.

I picked the CVL5B because it can do -40 to +105 celcius. While the commercial is like 0 to 95 Celsius. Not being able to handle negative degrees is pretty bad for real world usage.
 
@Dogbone06 did you make any updates to accomodate this comment?
Dogbone06 said:
The CC Pins are supposed to be connected to the USB-PD CC pins on the IC to negotiate. But they are not. The naming of them was wrong (human error). Good thing you catched this, the PCB's for Gen5 are not assembled yet, so I can pull the handbrake and alter them!
Click to expand...
I'm looking at what I believe is the last version of the schematic/pcb posted, but I think i need to connect cc1, cc2, dp, and dm from L10 (the IP6520) to USB2 as in this schematic found elsewhere on the net:
2024-07-10-091808-screenshot.png

That said, I have no idea where the 50k pullups mentioned in this comment are supposed to go:
jmarsh said:
5.1k pulldown is standard for ports on devices (ports that want power). 50k pullup is used on host ports (ports that supply power).
Click to expand...
For reference, I tried deciphering the datasheet from the component's custom properties but the language barrier is proving to be problematic, and I don't see any pullups on the "simplified application schematic" from the datasheet:
2024-07-10-093542-screenshot.png

Finally, regarding the SD card, do you think it makes sense to add the additional components as shown in the MIMXRT1060_EVK Design files?
2024-07-10-092054-screenshot.png


Seems like lots of additional complexity if what you already have is working fine, but figured I'd ask while I'm tweaking things. In my experience with sd cards I've had some success and some failures, so I'm just hoping to get it right this time around.

Thanks for any help, and sorry to keep pestering you.
 
Ok folks @KurtE and I was doing some more testing with the dev5 board and @KurtE's adapter.

Here is the results of some preliminary testing with an OV5640 using flex and a ILI9488 using SDRAM set at 206 Mhz
tft_vga sketch
1720619484838.jpeg


Notice the yellow tint on bright areas. @KurtE is seeing the same thing
1720619521747.png


Yet if I run the sdram_only sketch - not seeing it. More investigation needed
1720619556874.png


Now with a OV7675
1720619615447.png


Now to do a couple of things and back to playing
 
sndsgd said:
Seems like lots of additional complexity if what you already have is working fine, but figured I'd ask while I'm tweaking things. In my experience with sd cards I've had some success and some failures, so I'm just hoping to get it right this time around.
Click to expand...
I would take a look how Paul has it set up on the T4.1 board.

Havent tested sd yet but will soon.
 
Quick update - Looks like the CSI pins on the adapter/DB5 are working:
1720621260894.png


Here again shows the strange tint using the SDRAM...

Was able to choose the CSI by the method:
Code: 
#if defined(DB5_USE_CSI)
    // try using the CSI pins on devboard 5
    camera.setPins(65,  64, 17, 16, 57, 27, 26, 67, 66, 21, 20, 23, 22, 58);
#endif
 
As I posted in other area, I screwed up the connector to the RA8876 on the shield. The two columns of pins are swapped.
Also while trying this out, my DB5, decide to head south...

Note: I did a quick and dirty pin column swap adapter board:
1720633779255.png

Which I ordered a set of 3 from OSHPark with supper swift ($11.50)...
As always, no promises.
 

Attachments

  • RA8876_Row_Swap_gerber.zip
    7 KB · Views: 481
sndsgd said:
I'm looking at what I believe is the last version of the schematic/pcb posted, but I think i need to connect cc1, cc2, dp, and dm from L10 (the IP6520) to USB2 as in this schematic found elsewhere on the net:
View attachment 35002
That said, I have no idea where the 50k pullups mentioned in this comment are supposed to go:
Click to expand...
You only need to add pullup or pulldown resistors if you're going to have a "dumb" USB-C port (without any voltage negotiation). When using a controller like the IP6520 you just connect the lines directly to the IC.
 
Quick update on my DB5 that stopped working - with double blink.....
Not sure if the RA8876 had anything to do with it. Yes problem with my connector, where the two columns are reversed, so makes sense the
display did not work...

Maybe fixed now 🤞

The PC was not seeing it at all. clicking program button did nothing.
However I was able to load blink, by loading it up in IDE, then while holding the button down, plug it in, and then release
button. And it reprogrammed it, but then returned to double blinking:

Code: 
13:38:11.664 (loader): Auto Button event
13:38:11.664 (loader): Auto mode: disabled
13:38:13.426 (loader): Auto Button event
13:38:13.428 (loader): Auto mode: enabled
13:38:22.496 (loader): secure mode can be locked: this is Lockable Teensy
13:38:22.496 (loader): encryption is possible on this Teensy, but not yet configured
13:38:22.497 (loader): Device came online, code_size = 16515072
13:38:22.497 (loader): Board is: Teensy MicroMod (IMXRT1062), version 1.07
13:38:22.502 (loader): File "C:\Users\kurte\AppData\Local\Temp\arduino\sketches\2D4E605CFF04B7C1FBDB66300B809C80\Blink.ino.hex", 22528 bytes
13:38:22.503 (loader): File "Blink.ino.hex". 22528 bytes, 0% used
13:38:22.504 (loader): set background IMG_ONLINE
13:38:22.510 (loader): File "C:\Users\kurte\AppData\Local\Temp\arduino\sketches\2D4E605CFF04B7C1FBDB66300B809C80\Blink.ino.hex", 22528 bytes
13:38:22.512 (loader): File "Blink.ino.hex". 22528 bytes, 0% used
13:38:22.513 (loader): begin elf_guess_size
13:38:22.515 (loader): found elf file
13:38:22.516 (loader): read elf files into memory, 501756 bytes
13:38:22.516 (loader): elf appears to be for Teensy MicroMod (IMXRT1062) (16515072 bytes)
13:38:22.517 (loader): elf binary data matches hex file
13:38:22.518 (loader): elf file is for Teensy MicroMod (IMXRT1062) (id=26)
13:38:22.519 (loader): using hex file
13:38:22.520 (loader): begin operation
13:38:22.569 (loader): flash, block=0, bs=1024, auto=1
13:38:22.571 (loader): flash, block=1, bs=1024, auto=1
13:38:22.625 (loader): flash, block=2, bs=1024, auto=1
13:38:23.136 (loader): flash, block=3, bs=1024, auto=1
13:38:23.137 (loader): flash, block=4, bs=1024, auto=1
13:38:23.141 (loader): flash, block=5, bs=1024, auto=1
13:38:23.143 (loader): flash, block=6, bs=1024, auto=1
13:38:23.144 (loader): flash, block=7, bs=1024, auto=1
13:38:23.147 (loader): flash, block=8, bs=1024, auto=1
13:38:23.149 (loader): flash, block=9, bs=1024, auto=1
13:38:23.151 (loader): flash, block=10, bs=1024, auto=1
13:38:23.154 (loader): flash, block=11, bs=1024, auto=1
13:38:23.155 (loader): flash, block=12, bs=1024, auto=1
13:38:23.158 (loader): flash, block=13, bs=1024, auto=1
13:38:23.164 (loader): flash, block=14, bs=1024, auto=1
13:38:23.169 (loader): flash, block=15, bs=1024, auto=1
13:38:23.172 (loader): flash, block=16, bs=1024, auto=1
13:38:23.174 (loader): flash, block=17, bs=1024, auto=1
13:38:23.178 (loader): flash, block=18, bs=1024, auto=1
13:38:23.181 (loader): flash, block=19, bs=1024, auto=1
13:38:23.185 (loader): flash, block=20, bs=1024, auto=1
13:38:23.188 (loader): flash, block=21, bs=1024, auto=1
13:38:23.211 (loader): sending reboot
13:38:23.214 (loader): begin wait_until_offline
13:38:23.216 (loader): offline, waited 0
13:38:23.234 (loader): end operation, total time = 0.714 seconds
13:38:23.237 (loader): set background IMG_REBOOT_OK
13:38:23.246 (loader): redraw timer set, image 14 to show for 1200 ms
13:38:23.256 (loader): HID/win32:  vid:258A pid:0036 ver:0109  usb:0/140000/0/9/2/3
13:38:23.258 (loader): HID/win32:  vid:258A pid:0036 ver:0109  usb:0/140000/0/9/2/3
13:38:23.260 (loader): HID/win32:  vid:058F pid:9410 ver:0122  usb:0/140000/0/9/1/2
13:38:23.262 (loader): HID/win32:  vid:258A pid:0036 ver:0109  usb:0/140000/0/9/2/3
13:38:23.264 (loader): HID/win32:  vid:058F pid:9410 ver:0122  usb:0/140000/0/9/1/2
13:38:23.266 (loader): HID/win32:  vid:258A pid:0036 ver:0109  usb:0/140000/0/9/2/3
13:38:24.447 (loader): redraw, image 9

@mjs513 suggested then to plug it in while holding the program button again, and then continue to hold for 15 seconds, and then saw
the blink and released, and the solid yellow LED where it reprogrammed the processor and now the blink program appears to be running.

So keep fingers crossed!
 
KurtE said:
@mjs513 suggested then to plug it in while holding the program button again, and then continue to hold for 15 seconds, and then saw
the blink and released, and the solid yellow LED where it reprogrammed the processor and now the blink program appears to be running.

So keep fingers crossed!
Click to expand...
Maybe spoke too soon. Tried downloading new sketch and back to double blink...
Trying again with simpler program...

Tried just blink program and back to double blink...
 
You must log in or register to reply here.
Back
Top