Call to arms | Teensy + SDRAM = true

Other clocks might be possible with more fiddling. Maybe. Not planning to do that unless capacitor testing really needs finer control of the frequency.
 
Ok updated the readme and examples in the library.

@Dogbone06 - think that pretty much finishes off the library now you should just be able to test.
 
@defragster - SDRAMdiy_Test.ino still has no comment explaining what it does, and why someone would use it rather than the other SDRAM_Test.ino example. Please add a comment explaining what this example does and why users should (or should not) use it.
 
Other examples also need info. Also looks like ListFilesLFS.ino has a leftover comment. As I understand this example, it's demonstrating use of a ramdisk in the SDRAM memory. Is that correct? If so, the comment at the top shouild at least have a few words to explain the purpose of this example (as opposed to perhaps using SDRAM memory for buffering data before writing to a LittleFS filesystem...)
 
PaulStoffregen said:
@defragster - SDRAMdiy_Test.ino still has no comment explaining what it does, and why someone would use it rather than the other SDRAM_Test.ino example. Please add a comment explaining what this example does and why users should (or should not) use it.
Click to expand...
Understood and known/acknowledged ... been on a break after the rush with a short vacation ...

Now that Beta 5 is out with a CLEAN install and the lib in a final form going to go through them as planned.
 
I'm not sure why people keep mentioning about the core changes / Teensyduino-1.59-b5, I never had any problem with that since I use a copy of cores kept in sync with Paul's github.

What I do have an issue with is the SDRAM_t4 library not being as simple/straightforward as it could be, e.g. not working with a board that hasn't been manually modified from the posted design, having a "size" argument which is irrelevant because the initialization routine is hardcoded for one specific chip, having broken malloc code because the base address is defined separately in multiple places, etc.

Personally I think SDRAM should be treated the same way as PSRAM is handled for the T4.1:
- initialized automatically by startup() when the board target is a micromod
- if above initialization is successful and memory seems present, allocate the heap for extmem_malloc and any EXTMEM static variables. The size can be static 32MB; anyone using a different size is already going to have to manually modify the SEMC initialization, so they'll have no trouble adjusting the size as well.
- modify the micromod linker script to define the sdram base address and maximum size. This is no different from how PSRAM is handled for the T4.1 - whether it's physically present or not, the compiler always thinks it exists for that board.
- get rid of the need for any external library, all support in cores with FLASHMEM functions (the micromod has plenty of flash, nobody is likely to complain about code bloat)

Nobody is going to have PSRAM and SDRAM present on the same board, because it makes no sense - if you have SDRAM it's already the superior option and makes PSRAM redundant. For the sake of simplifying cores and making it possible to reuse/recycle any existing Teensy code that makes use of EXTMEM or extmem_malloc (e.g. taking code that was originally designed to work with PSRAM and using it with SDRAM instead), it is the obvious route to take.

Now we could argue back and forth about why SDRAM support should/shouldn't be tied to the micromod board id but that would imply a hypothetical situation where somebody would go to all the effort of making their own SDRAM-based board design and then use a smaller flash chip based on the T4.0 or T4.1 design - the same way someone could, in theory, design a board that exposed the PSRAM pins but used the T4.0 flash chip, which wouldn't work with the current PSRAM code in the core library since it's all tied to the T4.1.
There's obvious places to draw lines here and it's just overcomplicating things not to do so.
 
@mjs513 - suggest with some Beta 5 of TD 1.59 testing the core files get dumped and ReadMe updated to say 1.59b5 required.
@jmarsh - p#459 provides more info - but, prior pages found that SDRAM can be implemented like for PSRAM - but that is not an option as this is not a PJRC product to include in Cores and risk the SparkFun T_MM codebase just because of the 16MB Flash.
With release of TD 1.59b5 and later the DevBoard with SDRAM might now be considered ready to move from ALPHA testing - still the same DevBoard - but with the CORES settled and alpha testing weeks old - maybe all will get cleaned to be what it can be for a USER BUILT example of SDRAM ready for BETA testing.

... gotta run ...
 
jmarsh said:
Personally I think SDRAM should be treated the same way as PSRAM is handled for the T4.1:
Click to expand...
Have a version that does that by @Paul does not want to modify the core files that way for a development board that is not Teensy. Personnally I don't blame him. If you want to modify your version to do that see https://github.com/mjs513/TeensyCore---SDRAM. But that is non-supported right now.

When and if Paul ever creates a board with SDRAM then it will be a possibility
 
defragster said:
@jmarsh - p#459 provides more info - but, prior pages found that SDRAM can be implemented like for PSRAM - but that is not an option as this is not a PJRC product to include in Cores and risk the SparkFun T_MM codebase just because of the 16MB Flash.
Click to expand...
Actually, we might be able to I think?
With a custom linker file this can be achieved in IDEs such as VSC. I did this to get PSRAM working on the 1st gen dev board @Dogbone06 had created that had a single 8mb chip on board, without touching cores. Just importing some of the PSRAM init code and some of the other bits and bobs needed (what we already have in t4_sdram) and then just added the external memory address to the linker file. I pointed my build config to the new linker file within the project and voila - it worked using the EXTMEM macro.
So while this is still not out of the box, it was with very minimal effort
 
Rezo said:
Actually, we might be able to I think?
With a custom linker file this can be achieved in IDEs such as VSC. I did this to get PSRAM working on the 1st gen dev board @Dogbone06 had created that had a single 8mb chip on board, without touching cores. Just importing some of the PSRAM init code and some of the other bits and bobs needed (what we already have in t4_sdram) and then just added the external memory address to the linker file. I pointed my build config to the new linker file within the project and voila - it worked using the EXTMEM macro.
So while this is still not out of the box, it was with very minimal effort
Click to expand...
Quite possible/promising to find a way for the Linker to get the needed info for static reservations with minimal cores changes and not needing to do a whole new board with massive cores edits/#ifdef's. Once SDRAM gets as far a stable BETA using TD 1.59 with more than 2 board users... When @Dogbone06 approached me I had no idea Paul would pull the SEMC/SDRAM setup code out in a matter of hours - best hope was maybe about now it would be close to starting to work. Except the BEST HOPE was that, as it worked out, the PJRC/FORUM would come together as it has - impressive as usual with it all coming together. Board was here Saturday before Christmas and it was working the next days on/before Christmas Monday - and FedEx waffled and said the board wouldn't even arrive until Wednesday after Christmas - but did a 'weekday' delivery on Saturday!

With the release of TD 1.59 when proven it can be a stable base - as stuff comes around for TD 1.60. @KurtE posted a suggestion towards 'Variant' Boards that might get a further look as a solution to Teensy and DIY variants as well.
 
Was using IDE 1 since it was easier to have multiple installs and edit to cores.
Using TD 1.59 now with IDE 2 and using TyCommander for SerMon with this:
"C:\Users\yourname\AppData\Local\Arduino15\packages\teensy\hardware\avr\0.59.5\platform.local.txt"
tools.teensyloader.cmd.path=T:\T_Drive\TyComm\TyCommanderC.exe
tools.teensyloader.upload.pattern="{cmd.path}" upload --autostart --wait --delegate "{build.path}/{build.project_name}.hex"
Click to expand...
With TyComm installed in the indicated .cmd.path - the upload will cause TyComm to allow device select and then stop Serial to allow Auto Upload.
 
Here is the bottom line folks the official core installled with the ide's will not be changed to include a extsdram like extmem as far as I understand from Paul's many messages on this topic. This includes @KurtE's variant technique (at least at this point in time).

If you all want to create a work around for your local use don't think that will be an issue.

Cheers. Count me out on this one unless @PaulStoffregen says go for it. Then I will incorporate what I have into the core but you will have absolutely no control over clock speed or cap/nocap.
 
So I had a go at it
modified my custom linker file to account for SDRAM:
Code: 
ERAM (rwx):  ORIGIN = 0x80000000, LENGTH = 32768K

I declared two buffers in EXTMEM(EXTMEM uint16_t buffer1[800*480*3]; EXTMEM uint16_t buffer2[800*480*3]; )
Then initialized SDRAM as usual, printed their address to confirm propper allocation.
Then I set a value in each buffer at a random position and printed them back - works fine!

Here is the serial output
Code: 
No Crash Data To Report
  Hopefully all is well, but certain types of crashes can't be reported:
    stuck in an infinite loop (technically, hardware still running properly)
    remaining in a low power sleep mode
    access to certain peripherals without their clock enabled (eg, FlexIO)
    change of CPU or bus clock speed without use of glitchless mux
  Breadcrumb #1 was 1514806437 (0x5A4A1CA5)
  Breadcrumb #5 was 914675323 (0x3684D67B)
SDRAM WORKING :).....
buffer1: 0x80232800, buffer2: 0x80000000
buffer1[0]: 1042, buffer2[11652]: 1707

To confirm this is in SDRAM, I removed the sdram.begin() from my setup and got it to crash and reboot:
Code: 
CrashReport:
  A problem occurred at (system time) 0:1:3
  Code was executing from address 0x3144
  CFSR: 400
    (IMPRECISERR) Data bus error but address not related to instruction
  Temperature inside the chip was 51.43 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected
buffer1: 0x80232800, buffer2: 0x80000000


Attached is the project in VS Code.
Only thing you need to alter is the linker file path in the platfom.ini file
 

Attachments

  • Teensy_MM_SDRAM_test.zip
    370.5 KB · Views: 551
Yep you still need the lib @mjs513 but it works :)
I know @Dogbone06 was hoping there is a way to use the EXTMEM macro or something similar rather than sdram malloc as it looks a bit neater in the code.
 
@Dogbone06 / @PaulStoffregen : did an upload of example with usage commenting https://github.com/mjs513/SDRAM_t4/blob/main/examples/CapReadSDRAM/CapReadSDRAM.ino

It works with TD 1.59b5 with current SDRAM_t4 as the board here as configured without CAP at 166 MHz on 32 MB. On default start it takes 93 seconds to run all tests with a 3 times read/test for once written data.
--- START 57 test patterns ------ with 3 reReads ... wait ...
#############............................................
No Errors. All memory tests passed :) (time 93.38 secs)
Click to expand...
Send on SerMon repeats that current test so for a quick 'sniff' whether testing SDRAM alone, or for CAP selection that would be first step.
For extended testing these are the current options that might run for 60 or 600 minutes - still waiting for 100 reread to complete:
Send to restart. '1' or 'k' for 100 or 1,000 reReads and 's' for start fast test.
--- START 57 test patterns ------ with 100 reReads ... wait ...
#############............................................
No Errors. All memory tests passed :) (time 2726.12 secs)
Click to expand...
<edit> so 45 minutes for 100 reRead and test after 1 write and guessing about 10 times that going to 1,000 from 100.
 
Last edited:
Rezo said:
Yep you still need the lib @mjs513 but it works :)
I know @Dogbone06 was hoping there is a way to use the EXTMEM macro or something similar rather than sdram malloc as it looks a bit neater in the code.
Click to expand...
Understood.

But for the next revision of the board suggest that we create a new core for the SDRAM Dev board. In the long run this might be easier. When playing with testing the camera I had to HACK the core to add an additional pin that was on the T4 but not on TMM. It was frankly a pain. Had to modify digital.c, core_pins.h, and pins.h. Didn't touch any other files like I2C or Serial which probably should be updated. But we should do that in the new core. Then we could do the EXTSDRAM thing since I believe you want to support both SDRAM and PSRAM - just in case.

More work but with next rev of the board it is going to be a lot more capable and alot more pins to deal with.

Thoughts
 
mjs513 said:
Here is the bottom line folks the official core installled with the ide's will not be changed to include a extsdram like extmem as far as I understand from Paul's many messages on this topic. This includes @KurtE's variant technique (at least at this point in time).

If you all want to create a work around for your local use don't think that will be an issue.

Cheers. Count me out on this one unless @PaulStoffregen says go for it. Then I will incorporate what I have into the core but you will have absolutely no control over clock speed or cap/nocap.
Click to expand...
Sorry not typing much still...

I want to setup variant again. After not hearing any feedback, I lost some of it with these updated betas.
But I would like a setup that does not screw up the normal Micromod setup...

I do think there is benefit to making a few minor changes to the core. To allow variants, especially if it does not require changes to require current boards to convert to using variant.

Like the ability to check for variant.h and use it. Assumes that it defines the pins: So I have:
1705584223983.png


For Bootdata, I had the variant lie to also define the MICROMOD as the board, but needed to include the variant file, like:
1705584331832.png

Similar for EEPROM: Currently same edit:

But I also might tend to make it overwritable like:
Code: 
#ifndef FLASH_BASEADDR
#if defined(ARDUINO_TEENSY40)
#define FLASH_BASEADDR 0x601F0000
#define FLASH_SECTORS  15
#elif defined(ARDUINO_TEENSY41)
#define FLASH_BASEADDR 0x607C0000
#define FLASH_SECTORS  63
#elif defined(ARDUINO_TEENSY_MICROMOD)
#define FLASH_BASEADDR 0x60FC0000
#define FLASH_SECTORS  63
#endif
#endif
So the Variant.h could simply define then directly...

But again not sure if worth investing time on this if very little chance that any of this will go anywhere.

But if it does work and if possibility, then next would be to see about moving the variant completely out of the Teensy install. Could be own install or in <sketches>/hardware... But not sure how fully yet.

Kurt
 
@PaulStoffregen
Would you consider adding just @KurtE's ifdef to the certain cores files, i.e.,
Code: 
#if __has_include("variant.h")
#  include "variant.h"
#endif
at a later date. No other changes should be needed - all moded files for custom boards would be included in the local variants directory or such. We could demo it with the new dev board to see how it works.
 
KurtE said:
But if it does work and if possibility, then next would be to see about moving the variant completely out of the Teensy install. Could be own install or in <sketches>/hardware... But not sure how fully yet.
Click to expand...
Unclear if any of this will ever be pulled in, but still playing. I was having problems getting a version to build outside of the main Teensy folder,
So I opened up a thread on Arduino forum:
forum.arduino.cc

How to create a board variant as separate install

@ptillisch @Merlin513 Fixed this last issue (for IDE2): updated the platform.txt line to: ## Precompile Arduino.h header recipe.hooks.sketch.prebuild.1.pattern="{teensytools.path}precompile_helper" "{build.core.path}" "{build.path}" "{compiler.path}{build.toolchain}{build.command.g++}" -x...
forum.arduino.cc forum.arduino.cc

With help from @PerT and @mjs513 both for suggestions and sounding board, I think I have a version that compiles:

Mostly the issues were self-inflicted. In that the boards.txt file when I simply copied my boards.local.txt from
the Teensy install, it does not work... You need to add in the stuff from the top of the boards.txt which defines the menues...

The other thing that hit me, was in platform.txt - the precompiler helper app command line. I had modified it earlier to
include the variant directory on the include search. But the issue I ran into here is I believe that @PaulStoffregen setup this
line awhile ago to not use the {build.cores.path} setting and instead built your own... I believe such that when run from Arduino 1.x it would not go to the Teensy install within the Arduino15 stuff...

So in my version here I undid that and now it is building...

Lots of little details left to update/fix...
like: Has anyone yet generated Arduino pin numbers for all of the pins on the devboard 4? If so would be fun to include that here.

Like the hacks I did to eeprom.c and bootdata.c, could either wait to see if it will be pulled in, or next up try adding files to compile in the variant and add if it overrides the one in core...

Need to update how pin table is generated. And/or allow for the table only overwritten and/or modified version of file... Ditto for where the functions like: digitalWriteFast is defined. Which could also take the approach of simply using the passed in index into the pin table array, and for constant value passed in appears to generate the same code...

But for now time to rest hands...
 

Attachments

  • teensy-dev.zip
    6.1 KB · Views: 66
You must log in or register to reply here.
Back
Top