Call to arms | Teensy + SDRAM = true

Dogbone06 said:
Do we have any idea at all to why this issue occurs? Is it like a memory issue or what exactly may it be?
Click to expand...
To be honest no - based on a couple of comments by @KurtE and looking at the lst's took a guess and just added a bunch of asm volatile("NOP")s (guess base on comments in the startup.c and some of it started working. Also didn;t like having that extra .h file in the core so just restricted it to the Teensy Micromod otherwise would have had to mod the other ld scripts and didn;t want to do that.

EDIT: Need to try the library with I2C and SPI to see if it works. But I am tired - maybe Tim could test that out.
 
mjs513 said:
@PaulStoffregen - @defragster - @Rezo - @Dogbone06
Think I found the solution that works for the Teensy 4.1, Teensy 4.0 and the dev board as well. Used alot of asm volatile("NOP")'s. Also put an ifdef around that 2mb region.

Pushed changes to the repo.

Have to test if lib still works - probably not.
Click to expand...
Integrated 'extSDRAM' cores into the evolving UART code. Working BEFORE and AFTER!
> Good work @mjs513 - at least on DevBoard. No longer using SDRAM_t4 library.

Moving from fixed 2 ports to array of 5 uarts - harwareSerial _isr()'s will be hyper active.
Change test to 20KB buffers and net throughput the same ~1.1 MB/sec with reduced loops per second waiting for 6Mbaud xfer.

Works same with DMAMEM using: #define sdram_malloc malloc
Both SDRAM and DMAMEM (which was same as DTCM) alloc()'s run at same loop/sec speed - the limiter is UART xfer rate it seems
> so far just two UARTS Write and Read at 6M baud so MAX expected would be 1.2M and they both xfer at 1.08M or 1.12M bytes per sec.
> still no errors with memcmp() testing each 20KB message.
Now with 200 char limit on 20KB buffer print:
2 Here TWO L/s=27 B/s=1082700 MEM=malloc DMAMEM
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\

1 Here ONE 284773 xb B[20050 20050] xb ERR[0 0]
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\
Click to expand...
and SDRAM:
2 Here TWO L/s=28 B/s=1122716 MEM=sdram_malloc
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]

1 Here ONE 8491 xb B[20049 20048] xb ERR[0 0]
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^
Click to expand...
 
Something funky with this Serial5?
Serial5.begin(6000000); // p# 20 Tx & 21 Rx
Click to expand...
With 5 UARTS 1<>2 were initially paired and working crossed to each other
Then added the other three chained 4>>5>>6>4 :: Arrays made the code smaller
> 5 kept getting errors when others would not.
> moved #4 to feed itself, 5 still an issue with 6 { #4 alone fine }
> moved 5 to feed itself and still an issue { 4<>6 fine }
> dropped #5 from the list and the other 4 no errors in two pairs 1<>2 and 4<>6
> same results SDRAM sdram_malloc, or with DMAMEM malloc
> have a delayMicroseconds(15); in the readBytes() loop: extended to 185 us and no help for #5
> used diff jumper wires and header solder looks good.
> sdram_malloc()'s are done in an array 3 per UART - moving #5 from the list moved it from #4 to #5 in the list so it isn't a problem with memory location (and same with DMAMEM).
>> Start of message 100% - but not getting full length into buffer in time?
> @KurtE Assuming all the UARTS using the same class code and nothing odd about Serial5?

CODE HERE: https://github.com/Defragster/EVKB_1060/tree/main/mallocSDRAM/examples/UART_extmem_ARR

Output snip: Even with 4 active 6M ports the limit is probably a few million too many UART interrupts
Serial2 Here 128812 #B:20074 #ERR:0 /s=22 B/s=1766512 MEM=sdram_malloc
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCD

Serial1 Here 128809 #B:20074 #ERR:0 /s=22 B/s=1766512 MEM=sdram_malloc
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCD

Serial6 Here 128821 #B:20074 #ERR:0 /s=22 B/s=1766512 MEM=sdram_malloc
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCD

Serial4 Here 128816 #B:20074 #ERR:0 /s=22 B/s=1766512 MEM=sdram_malloc
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCD
Click to expand...
> 1,766,512 B/sec with 4 ports Rx'ing and Tx'ing those bytes? So, only 1.7M up from 1.1M
> hardly enough speed to challenge SDRAM
> but the 14-17 sdram_malloc()'s are perfectly functional!

@mjs513 if repro desired with sketch above '#define USED_UARTS 4' excludes #5 unless edited from 4 to 5
Wiring: 1>16, 0>17 and 24>B1_01, 25>B1_00 and #5: 20>21
> should try here on a T_4,1 with DMAMEM
 
@mjs513 - building for T_4.1 fails on the IDE 1.8.19 that has been in use: With edited CORES
<EDIT>: The build completed but the T_4.1 started and went OFFLINE
Adding CrashReport did not help. T_4.1 just went OFFLINE.
Tried building a BLINK with added CrashReport and it failed and saw no LED Toggle in setup() even flash.

Moved to IDE 2.2.1 ( and several restarts and closing IDE 1.8.19 ) - and getting FRESH 0.59.4 [ NO PRIVATE CORES YET ]
> Same Blink sketch worked. Then the UART_extmem_ARR using DMAMEM
Serial5 {linked to self} is a problem child here too! : Not each time but intermittently { at 6Mbaud }
Serial4 Here 2371601 #B:20076 #ERR:0 /s=17 B/s=1706289 MEM=malloc DMAMEM
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@AB

Serial5 Here 2371617 #B:20079 #ERR:6435 /s=17 B/s=1706289 MEM=malloc DMAMEM
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?
Click to expand...

Put the files from 'GitHub\EVKB_1060\mallocSDRAM\Core files' and build broke - doesn't include the imxrt.h? other?
Can't get a T_4.1 to build now on IDE 2.2.1, though building for the @Dogbone06 DevBoardv4 works fine.
 
Havent tried 1.8.19 but make a mod to startup.c so the if define micromod blocks out the scb 0x8... section:
Code: 
#if defined(ARDUINO_TEENSY_MICROMOD)
    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
    SCB_MPU_RBAR = 0x81E00000 | REGION(i++); // SEMC: SDRAM, NAND, SRAM, etc
    SCB_MPU_RASR = MEM_NOCACHE | READWRITE | NOEXEC | SIZE_2M;
#endif
 
defragster said:
Serial5 {linked to self} is a problem child here too! : Not each time but intermittently { at 6Mbaud }
Click to expand...
Simple answer is don't do that. 😉 :D
1704289463797.png
 
PaulStoffregen said:
Maybe a moot point now that development isn't using SDRAM_t4 library? But it will be there if anyone wants to revive the library approach to work with the official core library.
Click to expand...
First Happy New Year to you and Robin!!.

Not really a moot point. If its not in the core the library does not work. :(

Secondly, Since the changes to create a EXTSDRAM space was requested and a nice exercise to see how to do it probably won't use it in the future since too many changes have to be made to core and I can never keep up. Personally, will probably use the library when the 1.59 comes out - will add a few bells and whistles to make it easier. In addition to get SPI and I2C working together I had to add in a whole bunch of NOP's which I don't like so really a kludge to get it working.

Even with adding that change back in it fails for the Teensy 4.1 - the 4.1 and 4.0 goes offline - not sure why. Thats why recently I added a ifdef (ARDUINO_TEENSY_MICROMOD around it.

If you ever figure it out let me know.
 
As a another test point I ran the SDFat Bench test on a Adafruit SPI SMT SD Card, the fastest was able to clock SPI was at 16Mhz:
Code: 
Use a freshly formatted SD for best performance.

Type any character to start
FreeStack: 449392
Type is FAT16
Card size: 0.52 GB (GB = 1E9 bytes)

Manufacturer ID: 0XB
OEM ID: XT
Product: XTSDA
Version: 1.1
Serial number: 0X7000AE4F
Manufacturing date: 9/2014

FILE_SIZE_MB = 5
BUF_SIZE = 512 bytes
Starting write test, please wait.

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
1475.80,95727,280,346
1518.37,96475,280,337

Starting read test, please wait.

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
1822.16,282,280,280
1823.49,282,280,280

Done
Type any character to start

Same thing on a Regular Micromod board so no issue with SPI so far with the limited testing
 
KurtE said:
Simple answer is don't do that. 😉 :D
Click to expand...
Took a minute for the penny to drop reading that odd table from some ref book it seems :)
- PJRC.com suggests 6M is supported - and it works on Serial 1,2,4, and 6 but has those fails on Serial5.
On Teensy 4 boards, the serial ports normally are limited to 6 Mbit/sec baud rate.
Click to expand...
Setting the UARTS to a common 5,000,000 baud and all 5 are working now: DMAMEM and SDRAM - net throughput the same on both and from 6Mbaud with 5 ports at 1.7 MB/sec. below snip at 39 secs - but still going no errors on any port at 3+ minutes.
Serial2 Here 39399 #B:20073 #ERR:0 /s=17 B/s=1706205 MEM=sdram_malloc
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCDE

Serial1 Here 39396 #B:20073 #ERR:0 /s=17 B/s=1706205 MEM=sdram_malloc
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCDE

Serial6 Here 39407 #B:20073 #ERR:0 /s=17 B/s=1706205 MEM=sdram_malloc
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCDE

Serial4 Here 39402 #B:20073 #ERR:0 /s=17 B/s=1706205 MEM=sdram_malloc
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCDE

Serial5 Here 39413 #B:20073 #ERR:0 /s=17 B/s=1706205 MEM=sdram_malloc
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCDE
Click to expand...
 
mjs513 said:
Even with adding that change back in it fails for the Teensy 4.1 - the 4.1 and 4.0 goes offline - not sure why. Thats why recently I added a ifdef (ARDUINO_TEENSY_MICROMOD around it.
Click to expand...
Indeed, not seeing good T_4.1 builds with hodgepodge of cores edits currently in use in the IDE 1.8.19 install.
@mjs513 : I don't see imxrt.h (PJRC current) in this folder: https://github.com/Defragster/EVKB_1060/tree/main/mallocSDRAM/Core files

If you catch up with edits and see a working T_4.x build and can update that on github, can give it a try here.
Bummer that change breaks anything - perhaps just a conflict with T_4.1 and T_4.0 and T_MM without PSRAM test would work if?:
#ifndef ARDUINO_TEENSY41
Click to expand...
was placed around that MPU edit? Then it would work for any future custom board that added SDRAM - and not break T_4.1?
Not that I wired a T_4.0 or T_MM to test.
 
IDE 1.8.19 works for Teensy 4.0! Mapped and just wired each port to self Rx<>Tx and builds and works with DMAMEM malloc's
#ifdef ARDUINO_TEENSY40
HardwareSerialIMXRT *psAll[DB_SERIAL_CNT] = { &Serial1, &Serial2, &Serial3, &Serial4, &Serial5 };
char SerNames[DB_SERIAL_CNT][16] = { "Serial1", "Serial2", "Serial3", "Serial4", "Serial5" };
#else
HardwareSerialIMXRT *psAll[DB_SERIAL_CNT] = { &Serial1, &Serial2, &Serial4, &Serial6, &Serial5 };
char SerNames[DB_SERIAL_CNT][16] = { "Serial1", "Serial2", "Serial4", "Serial6", "Serial5" };
#endif
Click to expand...
Then building with T_4.1 (UARTS cross wired like for T_MM) under current same IDE 1.8.19 cores and board Programs then Goes Missing - even with CrashReport.

Moving back to IDE 2.2.1 without most SDRAM_DevBoard Edits over 0.59.4 and there it builds and runs as before/above.

If the cores here is messed up - the mess is only on T_4.1 with it working on DevBoard as T_MM and T_.40
 
mjs513 said:
If you ever figure it out let me know.
Click to expand...

I'll do more testing here, probably over the weekend. Working on another thing right now....

Edit: but I did test the Wire library Scanner example (new version which scans all ports) and it definitely started working with this change, so I merged it to make more testing easier.

Maybe we should consider mapping SDRAM at 0x90000000 or higher?
 
Last edited:
To map at a different address, just change to write to SEMC_BR0. In SDRAM_t4 it's at line 284. This 1 place determines where the SDRAM will be mapped.

github.com

EVKB_1060/SDRAM_t4/SDRAM_t4.cpp at ac048f663c30fcbf311775ad2db20eb6f8008aee · Defragster/EVKB_1060

EVKB for 1062 tests and notes. Contribute to Defragster/EVKB_1060 development by creating an account on GitHub.
github.com github.com

With the default MPU config allowing 1GB address space, you have a lot of flexibility where to map a 32GB memory chip.

Of course, then update the base address in SendIPCommand() and in your malloc and other places.
 
0x90000000 sounds good if that eliminates any other 1062 teensy conflicts.
Odd that T_4 builds to work and T_4.1 won't.

@mjs513 - let me know if you can do that and update github with full current set of needed files in sync. About lunch time here so offline an hour+
I could do a quick hack on the old UART code that manually uses 0x80000000 with simple edit - but going through Extmem and .LD is stuff you covered.
1704318630298.png
 
PaulStoffregen said:
Edit: but I did test the Wire library Scanner example (new version which scans all ports) and it definitely started working with this change, so I merged it to make more testing easier.

Maybe we should consider mapping SDRAM at 0x90000000 or higher?
Click to expand...

Not a problem - will give it a try - thought had crossed my mind but.... Interesting thing was I found that to get I2c and SPI working I needed both those changes and the nops - strange.

Will change that tonight and do some testing - kind of have that down to a science :)

@defragster - not a problem to change for me. Probably nothing will be posted until tomorrow - getting diner time around here and I tend not to do much after that. :)
 
PaulStoffregen said:
Jury is still out. So far I tested only I2C, and only the Scanner example, and only on Teensy 4.1 without SDRAM.

Much more testing to be done...
Click to expand...
Did a quick and dirty test - changed the core files (malloc version). Ran graphicstest and scanner012 on the dev board and it worked. Then ran graphicstest on the 4.1 and seems to be working.

Looks promising.

Still want to do a bunch more testing - now off to diner.

Why moving it to 0x90000000 works? Any other regions you want me to try?
 
You must log in or register to reply here.
Back
Top