Teensy 4.1 Beta Test

Soldered a second PSRAM chip to the Teensy 4.1 underside and updated to Teensyduino 1.52 beta5.

Using Pauls´ sketch from #478 it detects both chips:

Code:
External RAM test

PSRAM size is 16 Mbyte
myint = 123456
myint = 123456
*pint = 12345678
*pint = 12345678
*pint = 6541230
*pint = 6541230

will now try the logger sketch.
 
@mjs: I was talking about the T4/T41 program flash (not the optional chips).
But now that I'm writing this... I'm not sure anymore .. maybe it is on the Flexspi2, too? (I'm too tired to look, now)
I've implemented a new way for stereo-decode on my sdr and take a nap now.

Edit: T4_Powerbuttons flexRamInfo() now displays the PSRAM-size. I've updated the lib a few minutes ago.
 
Last edited:
Sorry I know this is not T4.1 specific as it hits T4 as well. But what is the proper way to use PROGMEM on parameters passed to a function. Note: code I am extracting it from ran earlier on AVR boards and may still want it to...
Code:
const short cCoxaMin1[] PROGMEM = {0, 1, 2, 3};
void setup() {
  while (!Serial);
  Serial.begin(115200);
}
[COLOR="#FF0000"]short foo( const short *sMin PROGMEM  ) {[/COLOR]
  return 0;
}

void loop() {
  foo(cCoxaMin1);
}
I tried moving the PROGMEM to about 4 different place on this line, but in all cases it complains with:
Code:
zzz:6: error: section attribute not allowed for 'sMin'
 short foo( const short PROGMEM *sMin ) {
                         ^

So is there a proper format that works both for T4.x and Atmega328?
 
Edit: T4_Powerbuttons flexRamInfo() now displays the PSRAM-size. I've updated the lib a few minutes ago.

Excellent! :)
Code:
FLASH:  36048  0.44% of 7936kB (8090416 Bytes free) FLASHMEM, PROGMEM
ITCM:   24288 74.12% of   32kB (   8480 Bytes free) (RAM1) FASTRUN
PSRAM: 16 MB
OCRAM:
   524288 Bytes (512 kB)
-   12384 Bytes (12 kB) DMAMEM
-     208 Bytes (0 kB) Heap
   511696 Bytes heap free (499 kB), 12592 Bytes OCRAM in use (12 kB).
DTCM:
   491520 Bytes (480 kB)
-   12992 Bytes (12 kB) global variables
-    1284 Bytes (1 kB) max. stack so far
=========

   477244 Bytes free (466 kB), 14276 Bytes in use (13 kB).
 
But what is the proper way to use PROGMEM on parameters passed to a function.

Maybe I misunderstand something but why do you want PROGMEM in the parameter declaration? A pointer to a short is a pointer, it shouldn't play a role where it points to?

This
Code:
short foo(const short *sMin)
{
  return 0;
}

compiles and works?
 
Thanks Paul, but my issue is more that I want to compile the library differently depending on if their is external memory. The current hack is, in the
ILI9488_t3 header file has:

So it detected this and all of the library code changed to use 4 bytes instead of 2, DMA update code completely different...

So again looks like for libraries like this, need a different approach, which I have been thinking of doing anyway... But more work.

You can probably use:
Code:
extern "C" uint8_t external_psram_size;
and test if external_psram_size > 0 to include the buffer?
 
Maybe I misunderstand something but why do you want PROGMEM in the parameter declaration? A pointer to a short is a pointer, it shouldn't play a role where it points to?
...
compiles and works?

I wondered that too as ARM won't care - except then 'AVR' is noted. Once moved to PROGMEM an AVR build will need the notice for memory access.
 
My T_4.1's are in the mailbox ... got them and distracted ... have some chores first :(

@mjs513 - Paul p#470 made a note about 'more than 8MB' :: 2: To use more than 8 megabytes, you'll need to write FLEXSPI2_FLSHA2CR0 with a larger number.
> (afaik) That allowed the two PSRAM usage to be contiguous 16 MB.

RE: the PSRAM log error p#498 and data found corruption:
No joy from cache flush that should be right?
arm_dcache_flush_delete((void *)&dbuff0[saveidx], sizeof(datrec)); // write cache to memory
and
arm_dcache_flush_delete((void *)&dbuff1[saveidx], sizeof(datrec)); // write cache to memory

Summary - two PSRAM buffers in use. They are written from intervalTimer( _isr )
The one buffer "0" starting at 70050000 is found holding data intended for buffer "1" at 70090010
BUFF at 70050000
skipped 0 4595, 91901, 70090010, 1 kk==16385 ????

**: if that buffer boundary is not hit, or the _isr() speed is dropped - the data does not trigger as corrupted.
**: the buffer size was made { while still hitting that 'boundary problem' } so one would fit in RAM1 and the other in RAM2 - and that works.

@KurtE: Can you aim a display DMA buffer at
Each buffer is size of 294080 bytes ( 0x47cc0 ).
First (with trouble) starts at :: struct datrec *dbuff0 = (datrec *)0x70050000;
I just moved the 2nd to just above that :: struct datrec *dbuff1 = (datrec *)0x7005A000;
This puts 2nd buff just above 1st buff. The problem recurs in First buffer now at new address where 2nd buff data appears:

After dbuff1[] write with no errors, This shows first buffer dbuff0[] got filled. Then it was marked for write and at offset 2560 the initial writes to 2nd buffer dbuff1[]
Code:
>>>1>>>		 1 FULL D @ 18380 &dbuff>700A1CC0
 	 BUFF at 7005A000
	DONE 18379 >> 1838, 36759, 700A1CB0, 1	<<<<<<
1] 918.84 mSec fill [lp#3979718] 	Written dbuff1 to data file.  tmilli =  919  took  10.60 mSec

>>>0>>>		 0 FULL D @ 18380 &dbuff>[B]70097CC0[/B]
 	 BUFF at 70050000
skipped 6	2757, 55140, [B]7005A000[/B], 1	 	 kk==[B]2560[/B]  ????
skipped 0	2757, 55141, 7005A010, 1	 	 kk==2561  ????
skipped 2	1968, 39353, 7005A210, 0	 	 kk==2593  ????
	DONE 18379 >> 2757, 55139, 70097CB0, 0	<<<<<<
0] 919.13 mSec fill [lp#5] 	Written dbuff0 to data file.  tmilli =  1838  took  10.73 mSec
 
my issue is more that I want to compile the library differently depending on if their is external memory.

You can't know at compile time whether the PSRAM chip will be installed on the board.

I would create 2 different constructors for the library which initialize a constexpr pointer or other variable you use. If it's constexpr and initialized by the constructor, the compiler should optimize away code which reads it and decides which memory to use.
 
defragster said:
@mjs513 - Paul p#470 made a note about 'more than 8MB' :: 2: To use more than 8 megabytes, you'll need to write FLEXSPI2_FLSHA2CR0 with a larger number.
> (afaik) That allowed the two PSRAM usage to be contiguous 16 MB.
yes but unfortunately it halts the FLASH unless I can change it at run time? But have feeling maybe have to do a complete init. Also I am confused again with memory locations. Remember my little graphic:
Picture1.png
Well PSRAM0 still starts at 0x07000000u, and PRAM1 starts at an offset of 0x800000 which is after flash. FLASH starts at 0x07100000u (so offset still 0x01000000u, so flash goes from 0x71000000u through 0x71FFFFFEu). So for PSRAM to be continuous would the second PSRAM need to start at 0x07FFFFE and not 0x800000
 
I am wondering for 1.53, whether we need a class that sits between the audio readers (i.e. RAW, WAV, etc.) and the actual filesystem (SD, SD-Fat Beta, SPIFFS, SerialFlash, etc.). That way, you can easily slide in new filesystems without having to make new versions of the readers.

Yes, this was on my list of things to do in 1.52, but it's going to slip to 1.53.

This really is desperately needed.
 
Similarly, it would be nice if there was some way to figure out if 1 or 2 psram chips are loaded

1.52-beta5 adds this in the startup code. See the example code on msg #478.



With 1 PSRAM chip that is expected - the write works to cache - but dump of cache in code voids that value when it is not backed by a chip.

I don't know what "dump of cache" means. The cache functions are delete, flush, and flush_delete. None of them are named "dump". Normally these functions are only used with DMA and for special hardware testing. They should not be required or used in "normal" programs, unless DMA is accessing the memory.

Obviously if you delete data from the cache before it's been written back to memory (and you really have no way without DMA to know) then the data is deleted and gone forever. Data loss is the expected and correct behavior if using the delete function.

But if you lost data with the other functions, that's a serious matter. Please help me to reproduce the problem if you saw anything like that.
 
We will soon begin a public beta test for Teensy 4.1.

At this time, PJRC would like to offer free Teensy 4.1 boards to the following people:
../..
Everyone on this list who does not receive a pre-production board will be offered a free Teensy 4.1 from the first production batch (which will have all power pins correct). If you're busy right now, or you'd just prefer to wait for the production batch, there is no need to do anything right now. We expect to release Teensy 4.1 sometime in May, so the wait will not be long...
.

I'm not on the list but would love to test these pre-production boards early too for my current more challenging musical pcb projects, I would offer easily $10 for each of these beta boards too if it helps (and of course shipment too) :)
 
What is the plan if 16MB (or 32?) PSRAM occur? (Adresses)
It will take not too long and such things will be produced.
 
@Franck B :I know thanks, but if there is some stock left of beta ones, I would be interested to get some of them for my lab use, as every buck counts when you spend on pcb's and various parts ...
 
What is the plan if 16MB (or 32?) PSRAM occur?

Step 1 of the plan is to read their datasheets and hope the ID command can be used to detect which chip is used.

Assuming the ID is usable, the startup code will need to be changed to put the correct settings into FLEXSPI2_FLSHA1CR0 and FLEXSPI2_FLSHA2CR0 and write external_psram_size with the correct total size. But until different size chips can be purchased (no, never going to support the tiny & slow 23LC1024 chips) there's little point to making the code more complicated.

If the ID bytes are the same, any "solution" is probably going to start with a lot of swear words...
 
What is the plan if 16MB (or 32?) PSRAM occur? (Adresses)
It will take not too long and such things will be produced.

Paul showed some MATH once. Current market only showing 8MB was thought to be small layout PSRAM. Large Layout made room for 16MB+ on that channel thought to be - and early Beta shipped as FLASH.

That seemed to show there is some limit on the boundary setting - one chip limited to 8 MB and the other can be 16 MB or some much larger size - like to allow NAND versus smaller NOR capacity.
 
but if there is some stock left of beta ones

No. All those early boards were used up. Most shipped in the first couple days. A few lingered here until nearly the end of the beta test, but in the end all of them were shipped to beta testers. There are no leftovers.
 
No. All those early boards were used up. Most shipped in the first couple days. A few lingered here until nearly the end of the beta test, but in the end all of them were shipped to beta testers. There are no leftovers.

Well too bad for me and great for the testers of this batch, thanks for your reply and long life to 4.1, again another beautiful board.
Thank you for your sustained efforts, today I only use teensy boards for my new arduino projects, because your boards and libs are simply amazing, keep on the good work!
 
1.52-beta5 adds this in the startup code. See the example code on msg #478.

I don't know what "dump of cache" means. The cache functions are delete, flush, and flush_delete. None of them are named "dump". Normally these functions are only used with DMA and for special hardware testing. They should not be required or used in "normal" programs, unless DMA is accessing the memory.

Obviously if you delete data from the cache before it's been written back to memory (and you really have no way without DMA to know) then the data is deleted and gone forever. Data loss is the expected and correct behavior if using the delete function.

But if you lost data with the other functions, that's a serious matter. Please help me to reproduce the problem if you saw anything like that.

Opps word 'dump' was careless - but reference was to specific PJRC provided example code using :: arm_dcache_flush_delete()
> that was indicated by name below and what was tried and showed no effect.
-- > the same erroneous 'formatted' data appears where it should not be in the 'other' buffer.
> using the 'proper' eRAM write funcs (? as extended from PJRC sample by @mjs513 in SPIFFS and other testing) in that sample shows no error { forgot to note this was added/tried }
> same code using ptr's instead of PSRAM to RAM1 & RAM2 works - to replace the two PSRAM buffers.
> If the base pointer does not cross the 'recurrent' error boundary location then it works as expected with same size PSRAM buffers.

That error has shown for 3 of us - running same code that is doing Direct Pointer writes to PSRAM - write intended for dbuff1[] #2 of PSRAM seem to go there - but also 'ghosts' into some (small var size) portion of dbuff0[]

Paul: Will get back {Code has ping/ponged between myself and mjs513 recently} and post a clearer example. Have seen it repro today with PJRC PSRAM init so that removes the need for external lib - and it is also now running PSRAM at slower speed - but still shows up in repro case.
 
Sorry I know this is not T4.1 specific as it hits T4 as well. But what is the proper way to use PROGMEM on parameters passed to a function. Note: code I am extracting it from ran earlier on AVR boards and may still want it to...
Code:
const short cCoxaMin1[] PROGMEM = {0, 1, 2, 3};
void setup() {
  while (!Serial);
  Serial.begin(115200);
}
[COLOR="#FF0000"]short foo( const short *sMin PROGMEM  ) {[/COLOR]
  return 0;
}

void loop() {
  foo(cCoxaMin1);
}
I tried moving the PROGMEM to about 4 different place on this line, but in all cases it complains with:
Code:
zzz:6: error: section attribute not allowed for 'sMin'
 short foo( const short PROGMEM *sMin ) {
                         ^

So is there a proper format that works both for T4.x and Atmega328?

I would try to undef PROGMEN if the processor is ARM based.
 
I would try to undef PROGMEN if the processor is ARM based.

PROGMEM is needed to place data in the flash. It's for the linker.
Without it, you can't use very large data-arrays (like wavetables)

I guess we need a tutorial for things like FLASHMEM, PROGMEM in the WIKI.
Esp. FLASHMEM helps to save RAM... only a very few use it.
 
Back
Top