Teensy 4.1 Beta Test

@defragster

Great that it worked for you :) was busy soldering up a T4.1 with 2 PSRAMs for testing :)

Worked up to this point - with changed code - on the 16MB 4.1:
>> uint32_t COUNT_ALLOC = 1250000;
Code:
  COUNT_ALLOC = (external_psram_size *1024*1024/3/sizeof(uint16_t))-16;
  buffer1 = (uint16_t*)malloc_extmem(COUNT_ALLOC * sizeof(uint16_t));
  buffer2 = (uint16_t*)malloc_extmem(COUNT_ALLOC * sizeof(uint16_t));
  buffer3 = (uint16_t*)malloc_extmem(COUNT_ALLOC * sizeof(uint16_t));

This just showed up … suppose there is some over flow wrap with the 16MB/3 math?::
Code:
Pass 1535 error count: 0
Pass 1536 error count: 0
Pass 1537 error count: 0
Pass 1538 error count: 0
31199 79df 603 7fdd
43999 abdf 603 addd
45023 afdf 603 a9dd
49119 bfdf 603 b9dd
Pass 1539 error count: 901
12095 2f3f 605 293b
15679 3d3f 605 3b3b
22501 57e5 604 51f1
27103 69df 604 7fdb
…
Pass 1617 error count: 1640554
8 8 752 65a
13 d 652 75f
14 e 1652 65c
18 12 752 640
Pass 1618 error count: 1922122
1 1 1753 652
2 2 1753 651
25 19 1653 64a
29 1d 653 74e
Pass 1619 error count: 1949024
Pass 1620 error count: 0
Pass 1621 error count: 0
Pass 1622 error count: 0
Pass 1623 error count: 0
Pass 1624 error count: 0
Pass 1625 error count: 0
Pass 1626 error count: 0
Pass 1627 error count: 0
Pass 1628 error count: 0
Pass 1629 error count: 0
Pass 1630 error count: 0
Pass 1631 error count: 0
Pass 1632 error count: 0
281867 4d0b 661 5b6a
623749 8485 661 92e4
624360 86e8 661 8189
624373 86f5 661 9094
Pass 1633 error count: 29
229968 8250 1673 9533
229974 8256 662 9534
229975 8257 662 9535
229976 8258 662 953b
…

the 8MB code running fine - and twice as fast :):
Code:
...
Pass 4050 error count: 0
Pass 4051 error count: 0
Pass 4052 error count: 0
Pass 4053 error count: 0
Pass 4054 error count: 0
...
 
Thought maybe it was loop_count wrapping ... but not that as it is already 16 bit limited.

Did a re-upload and got error right away.

Then did Power up and got error on start? Soldering - bad chip?

Something busted would explain the other PSRAM logger going bonkers once ...

Code:
T:\tCode\RAM\ExtAlloc\ExtAlloc.ino May 15 2020 12:27:51
External PSRAM size: 16
B1:70aaaac0 B2:70555580 B3: 70000040
517895 e707 1 e716
[3] addrs: 0x70BA78CE 0X7065238E 0x700FCE4E
517952 e740 1 f741
[3] addrs: 0x70BA7940 0X70652400 0x700FCEC0
517959 e747 1 f746
[3] addrs: 0x70BA794E 0X7065240E 0x700FCECE
517967 e74f 1 f74e
[3] addrs: 0x70BA795E 0X7065241E 0x700FCEDE
Pass 1 error count: 25
Pass 2 error count: 0
Pass 3 error count: 0
1356095 b13f 5 b13b
[2] addrs: 0x70D40D3E 0X707EB7FE 0x702962BE
1356095 b13f 5 b13b
[3] addrs: 0x70D40D3E 0X707EB7FE 0x702962BE
1356607 b33f 1004 b33b
[2] addrs: 0x70D4113E 0X707EBBFE 0x702966BE
1356607 b33f 1004 b33b
[3] addrs: 0x70D4113E 0X707EBBFE 0x702966BE
Pass 4 error count: 32
Pass 5 error count: 0
1305240 ea98 6 fa9e
[3] addrs: 0x70D27FF0 0X707D2AB0 0x7027D570
1305292 eacc 6 ebca
[3] addrs: 0x70D28058 0X707D2B18 0x7027D5D8
1305310 eade 106 ead8
[2] addrs: 0x70D2807C 0X707D2B3C 0x7027D5FC
1305310 eade 106 ead8
[3] addrs: 0x70D2807C 0X707D2B3C 0x7027D5FC
Pass 6 error count: 91
323391 ef3f 1007 ef38
[2] addrs: 0x70B4893E 0X705F33FE 0x7009DEBE
323391 ef3f 1007 ef38
[3] addrs: 0x70B4893E 0X705F33FE 0x7009DEBE
507871 bfdf 7 bfd9
[3] addrs: 0x70BA2A7E 0X7064D53E 0x700F7FFE
626143 8ddf 7 9dd8
[3] addrs: 0x70BDC67E 0X7068713E 0x70131BFE
Pass 7 error count: 20
Pass 8 error count: 0

Changed error print to show ADDR and split out the three test and it work 3 times then failed on the next:
Code:
T:\tCode\RAM\ExtAlloc\ExtAlloc.ino May 15 2020 12:23:13
External PSRAM size: 16
B1:70aaaac0 B2:70555580 B3: 70000040
Pass 1 error count: 0
Pass 2 error count: 0
828383 a3df 3 b3dc
[3] addrs: 70C3F27E706E9D3E 701947FE
828447 a41f 3 a51c
[3] addrs: 70C3F2FE706E9DBE 7019487E
828470 a436 3 a535
[3] addrs: 70C3F32C706E9DEC 701948AC
828495 a44f 103 a44c
[2] addrs: 70C3F35E706E9E1E 701948DE
Pass 3 error count: 28
Pass 4 error count: 0
Pass 5 error count: 0
Pass 6 error count: 0
Pass 7 error count: 0
Pass 8 error count: 0
Pass 9 error count: 0
Pass 10 error count: 0
Pass 11 error count: 0
85823 4f3f d 4f33
[2] addrs: 70AD493E7057F3FE 70029EBE
85823 4f3f d 4f33
[3] addrs: 70AD493E7057F3FE 70029EBE
108863 a93f d a933
[2] addrs: 70ADFD3E7058A7FE 700352BE
108863 a93f d a933
[3] addrs: 70ADFD3E7058A7FE 700352BE
Pass 12 error count: 123
13791 35df d 35d3
[3] addrs: 70AB167E7055C13E 70006BFE
14815 39df d 39d3
[3] addrs: 70AB1E7E7055C93E 700073FE
16863 41df d 51d2
[3] addrs: 70AB2E7E7055D93E 700083FE
17375 43df d 43d3
[3] addrs: 70AB327E7055DD3E 700087FE
Pass 13 error count: 4372
5439 153f f 1531
[2] addrs: 70AAD53E70557FFE 70002ABE
5439 153f f 1531
[3] addrs: 70AAD53E70557FFE 70002ABE
17727 453f f 4531
[2] addrs: 70AB353E7055DFFE 70008ABE
17727 453f f 4531
[3] addrs: 70AB353E7055DFFE 70008ABE

Changed loop() code and the altered ALLOC amount COMPLETE:
Code:
uint32_t COUNT_ALLOC = 1250000;
extern "C" {
	extern uint8_t external_psram_size;
	uint8_t *extmem_next_free;  // set in startup NULL if we don't have external memory
	uint8_t *malloc_extmem(size_t cb_alloc);
	void free_extmem(char *p);
}

uint16_t *buffer1;
uint16_t *buffer2;
uint16_t *buffer3;

void setup() {
	pinMode(13, OUTPUT);
	Serial.begin(115200);
	while (!Serial && millis() < 4000) ;
	Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);

	Serial.printf("External PSRAM size: %d\n", external_psram_size);
	Serial.flush();
	if (external_psram_size == 8) {
		extmem_next_free = (uint8_t*)(0x70800000l);
	} else if (external_psram_size == 16) {
		extmem_next_free = (uint8_t*)(0x71000000l);
	} else {
		Serial.println("No external memory");
		for (;;) {
			digitalWrite(13, !digitalRead(13));
			delay(250);
		}
	}
	COUNT_ALLOC = (external_psram_size * 1024 * 1024 / 3 / sizeof(uint16_t)) - 16;
	buffer1 = (uint16_t*)malloc_extmem(COUNT_ALLOC * sizeof(uint16_t));
	buffer2 = (uint16_t*)malloc_extmem(COUNT_ALLOC * sizeof(uint16_t));
	buffer3 = (uint16_t*)malloc_extmem(COUNT_ALLOC * sizeof(uint16_t));
	Serial.printf("B1:%x B2:%x B3: %x\n", (uint32_t)buffer1, (uint32_t)buffer2, (uint32_t)buffer3);
	Serial.flush();
}

uint32_t loop_count = 0;
void loop() {
	digitalWrite(13, !digitalRead(13));
	loop_count++;
	for (uint32_t i = 0; i < COUNT_ALLOC; i++) {
		buffer1[i] = i & 0xffff;
		buffer2[i] = loop_count & 0xffff;
		buffer3[i] = buffer1[i] ^ buffer2[i];
	}
	uint32_t error_count = 0;
	for (uint32_t i = 0; i < COUNT_ALLOC; i++) {
		if ((buffer1[i] != (i & 0xffff)) ) {
			error_count++;
			if (error_count < 5) {
				Serial.printf("%u %x %x %x\n", i, buffer1[i], buffer2[i], buffer3[i]);
				Serial.printf("[1] addrs: 0x%lX 0X%lX 0x%lX\n", &buffer1[i], &buffer2[i], &buffer3[i]);
			}
		}
		if ((buffer2[i] != (loop_count & 0xffff))) {
			error_count++;
			if (error_count < 5) {
				Serial.printf("%u %x %x %x\n", i, buffer1[i], buffer2[i], buffer3[i]);
				Serial.printf("[2] addrs: 0x%lX 0X%lX 0x%lX\n", &buffer1[i], &buffer2[i], &buffer3[i]);
			}
		}
		if ((buffer3[i] != (buffer1[i] ^ buffer2[i]))) {
			error_count++;
			if (error_count < 5) {
				Serial.printf("%u %x %x %x\n", i, buffer1[i], buffer2[i], buffer3[i]);
				Serial.printf("[3] addrs: 0x%lX 0X%lX 0x%lX\n", &buffer1[i], &buffer2[i], &buffer3[i]);
			}
		}
	}
	Serial.printf("Pass %d error count: %d\n", loop_count, error_count);
}

<edited: output line was MUNGED
 
Last edited:
@defragster - do a double check on the chip soldering - maybe something not good. As long as you didn't edit the chip size in startup should be good - going to let mine run and see what happens
 
@defragster - do a double check on the chip soldering - maybe something not good. As long as you didn't edit the chip size in startup should be good - going to let mine run and see what happens

Updated code above - hex addr output was blurred

Will - do that - something yesterday one time - not this is persistent all of a sudden ????

<edit> That update output shows errors seem to be on FIRST chip/BANK ??? On test buffers [3] and [2] ???

Where alloc seems top down? >> B1:70aaaac0 B2:70555580 B3: 70000040

EDIT : started early fails - now being sane/stable again????
Code:
T:\tCode\RAM\ExtAlloc\ExtAlloc.ino May 15 2020 12:27:51
External PSRAM size: 16
B1:70aaaac0 B2:70555580 B3: 70000040
517895 e707 1 e716
[3] addrs: 0x70BA78CE 0X7065238E 0x700FCE4E
517952 e740 1 f741
[3] addrs: 0x70BA7940 0X70652400 0x700FCEC0
517959 e747 1 f746
[3] addrs: 0x70BA794E 0X7065240E 0x700FCECE
517967 e74f 1 f74e
[3] addrs: 0x70BA795E 0X7065241E 0x700FCEDE
Pass 1 error count: 25
Pass 2 error count: 0
Pass 3 error count: 0
[B]…       // many bad with strings of good [/B]
Pass 69 error count: 0
Pass 70 error count: 0
2625341 f3d 47 f7b
[3] addrs: 0x70FAC93A 0X70A573FA 0x70501EBA
2626169 1279 47 133e
[3] addrs: 0x70FACFB2 0X70A57A72 0x70502532
Pass 71 error count: 2
1811423 a3df 48 b397
[3] addrs: 0x70E1F27E 0X708C9D3E 0x703747FE
1811534 a44e 48 a407
[3] addrs: 0x70E1F35C 0X708C9E1C 0x703748DC
1811593 a489 48 a4d1
[3] addrs: 0x70E1F3D2 0X708C9E92 0x70374952
1812015 a62f 48 a677
[3] addrs: 0x70E1F71E 0X708CA1DE 0x70374C9E
Pass 72 error count: 6
Pass 73 error count: 0
Pass 74 error count: 0
Pass 75 error count: 0
[B]…     // ALL GOOD[/B]
Pass 1016 error count: 0
Pass 1017 error count: 0
Pass 1018 error count: 0
Pass 1019 error count: 0
Pass 1020 error count: 0
...

Not taken offline to resolder yet - if reading Addressing right then it is the SMALL first PSRAM that is failing?
Both chips are same make - and it was the SMALL one that soldere more easily - with less heat and less rework and nicer joints :)
 
Last edited:
@defragster

Great that it worked for you :) was busy soldering up a T4.1 with 2 PSRAMs for testing :)

Well, I finished soldering up my new one with two chips in it and washed and dried...)

Ran my version of the test and it is failing

Maybe my math is failing. I was getting ready to post, saying I wonder if someone else how has 16mb installed could try it out...
 
<above post #604 updated in place>

Just did a 15s Restore and restart - started good ...

Will mod sketch to eat 8MB in a bit and just put the three buffers in the next three allocs since it is that chip that seems to have the issue.
 
Well, I finished soldering up my new one with two chips in it and washed and dried...)

Ran my version of the test and it is failing

Maybe my math is failing. I was getting ready to post, saying I wonder if someone else how has 16mb installed could try it out...

See Prior Paul post #589 - I found that last night

buffer2 = loop_count & 0xffff; NOT buffer2 = loop_count & 0xff;
 
@KurtE - I saw no trouble on 16MB with your edited sketch

Can you give @mjs513 mod sketch in p#602 pjrc.com/threads/60532-Teensy-4-1-Beta-Test

after 15s Restore and restart no trouble yet:
Code:
T:\tCode\RAM\ExtAlloc\ExtAlloc.ino May 15 2020 12:27:51
External PSRAM size: 16
B1:70aaaac0 B2:70555580 B3: 70000040
Pass 1 error count: 0
Pass 2 error count: 0
Pass 3 error count: 0
…
Pass 316 error count: 0
Pass 317 error count: 0
Pass 318 error count: 0
Pass 319 error count: 0
…
 
@KurtE - I saw no trouble on 16MB with your edited sketch

Can you give @mjs513 mod sketch in p#602 pjrc.com/threads/60532-Teensy-4-1-Beta-Test

after 15s Restore and restart no trouble yet:
Code:
T:\tCode\RAM\ExtAlloc\ExtAlloc.ino May 15 2020 12:27:51
External PSRAM size: 16
B1:70aaaac0 B2:70555580 B3: 70000040
Pass 1 error count: 0
Pass 2 error count: 0
Pass 3 error count: 0
…
Pass 316 error count: 0
Pass 317 error count: 0
Pass 318 error count: 0
Pass 319 error count: 0
…
That's the sketch I am currently running. Wanted to match what you had.
Code:
  for (uint32_t i = 0; i < COUNT_ALLOC; i++) {
    buffer1[i] = i & 0xffff;
[COLOR="#FF0000"]    buffer2[i] = loop_count & 0xffff;[/COLOR]
    buffer3[i] = buffer1[i] ^ buffer2[i];
  }
 
That's the sketch I am currently running. Wanted to match what you had.
Code:
  for (uint32_t i = 0; i < COUNT_ALLOC; i++) {
    buffer1[i] = i & 0xffff;
[COLOR="#FF0000"]    buffer2[i] = loop_count & 0xffff;[/COLOR]
    buffer3[i] = buffer1[i] ^ buffer2[i];
  }

Good to know.

All good so far after 15s Restore ….
I ran okay to Pass #413. Did Upload(restart w/program) to #28 … new upload to #30 … new upload to #119 … new upload to #100 … new upload to #50 ...

Not sure what 15s Restore might do that could affect?
The PSRAM chips do not power down on upload - I wonder if they can get into a strange state? Though my first fail above didn't fail until pass #1538

Once messed up it would repro early and more often than not.

QUESTION: Is my p#604 EVAL right that all my troubles show on SMALL chip in LOWER PSRAM space of the two?

Test would run 2X faster if the top 8MB were blocked off for me - but that may change everything ????

Will let it run as is on this 16MB T_4.1 … no issues as noted above at pass #50 and counting
 
@defragster
Just as a note:
Code:
uint32_t COUNT_ALLOC = 1250000;
This is what we are using for buffersize.

EDIT> Up to pass 1650 with no errors
 
@defragster
Just as a note:
Code:
uint32_t COUNT_ALLOC = 1250000;
This is what we are using for buffersize.

EDIT> Up to pass 1650 with no errors

Indeed - I didn't refactor the CAP_CASE_NAME but - made a variable and ::

Code:
	[B]COUNT_ALLOC = (external_psram_size * 1024 * 1024 / 3 / sizeof(uint16_t)) - 16;[/B]
	buffer1 = (uint16_t*)malloc_extmem(COUNT_ALLOC * sizeof(uint16_t));

Current run here at #405 and counting ….
 
8MB T_4.1 :: running and good up to 5970 for the second time with no error … and counting

16MB T_4.1 :: with noted 5 restart/re-program after 15s Restore fine at 740 and counting.

Going to go out in the sun and cut the grass and let it run ….

<Note: I did have an unused SD Card in the socket when it failed - that was removed at some point after first fail >
 
Just inserted a SD card at pass2175 lets see what happens. Time for a nap.

EDIT: just as note I am testing with a T4.1 with 16Mb PSRAM.
 
Quick update... At first my 16mb was not working, then working... Then figured out the USB connector was loose... Worked in other T4.1s... but... So switched to different cable... Figured maybe bad solder. so I touched up. Programmed first time, where my updated sketch bypassed that high memory chip was working, disable that part, reprogrammed and then T4.1 DEAD. Nothing, shown on USB... tried different cable nothing, tried holding in program button nothing.

Went to other room, finished lunch, plugged back in and it is working... Maybe I did not let it dry out long enough after solder/wash... So far no errors this time, up to pass 647...
 
<edit> did not DIE - the test went fail as shown now up to 3160 and counting fine no errors?

Only thing soldered to this new T_4.1 is the two PSRAMs - no pins.

I just came in to check progress - was going to put in SD card … IT DIED when I touched it:

Code:
Pass 2939 error count: 0
Pass 2940 error count: 0
Pass 2941 error count: 0
Pass 2942 error count: 0
Pass 2943 error count: 0
Pass 2944 error count: 0
Pass 2945 error count: 0
1138782 5555 b82 6bdc
[1] addrs: 0x70CD6B7C 0X7078163C 0x7022C0FC
1138782 5555 b82 6bdc
[3] addrs: 0x70CD6B7C 0X7078163C 0x7022C0FC
1138783 5555 b82 6bdd
[1] addrs: 0x70CD6B7E 0X7078163E 0x7022C0FE
1138783 5555 b82 6bdd
[3] addrs: 0x70CD6B7E 0X7078163E 0x7022C0FE
Pass 2946 error count: 4
Pass 2947 error count: 0
Pass 2948 error count: 0
Pass 2949 error count: 0

Back to running fine.

@KurtE - (this time) I managed to be patient: Soldered - alcohol brush/rinse - shake/pat dry then hairdryer - let sit 15 mins - warm again with hair dryer - and then plug in a couple minutes later.
 
Just got up and now at 4560 with no errors with a SD Card in it.

@KurtE - great that its working again.

Going to stop the test - forgot to solder something onto the breakout board I am using.

EDIT: @defragster if you just touched the sd card reader and then restarted may solder joint is not good?
 
On mine I am going to try some python but what would be better two psram chips or one and a flash chip?
 
@DaQue - T_4.1 python port not aware of PSRAM yet AFAIK - just a T_4.0 with more mapped pins

@mjs513 - I had a nitrile work glove on the grab hand - grabbed by edges and saw SerMon jump. Does not repro - may have been carrying static charge? At 3410 now and running … Touched and put SD card in there … okay and then Ctrl+B … bootload upload …

8MB T_4.1 now at 11618.
 
My Teensy 4.1 beta has still not arrived, but reading the comments of RAM tests and the datasheets of the RAM, I stumble upon:
Page size 1024 bytes ... Linear burst can cross page boundary under following conditions: operative clock frequency <= 84 MHz CE# low pulse width <= tCEM(max)

Could this be some effect of the 88MHz SPI overloading the PSRAM internal bus and interfering with the refresh logic?
So some time later errors show up?
 
In from grass cutting in the sun. Since last restart - no signs of errors or issues - and just bare handed touched it again ...
Code:
Pass 3479 error count: 0
Pass 3480 error count: 0
Pass 3481 error count: 0
Pass 3482 error count: 0
Pass 3483 error count: 0

My Teensy 4.1 beta has still not arrived, but reading the comments of RAM tests and the datasheets of the RAM, I stumble upon:
Page size 1024 bytes ... Linear burst can cross page boundary under following conditions: operative clock frequency <= 84 MHz CE# low pulse width <= tCEM(max)

Could this be some effect of the 88MHz SPI overloading the PSRAM internal bus and interfering with the refresh logic?
So some time later errors show up?

Bummer on the delayed board arrival :(

Saw that in the spec and have been trying to trigger it and not seen and way to do it since first early beta board arrived with PSRAM attached.
> all of PSRAM
- > small blocks
- > big blocks
- > start base address offset by 1 to force breaking all even boundaries 2,4,8, … 1024

Generally everything has worked direct use and lots of little PSRAM under SPIFFS testing. It seems the MCU is aware or doing it safely by accident only doing small block writes not crossing pages.
 
@defragster thanks. Got a psram coming from PJRC I can use later I guess or with Arduino. I bet the flash would hold 30 seconds of audio.for a project I have in mind I could do in Arduino if 12 bit audio sounds good enough. The source is definitely not very hifi and the SD card would be way overkill I think.
 
The 8 MB T_4.1 happily running STILL at "Pass 44884 error count: 0"

The 16 MB T_4.1 happily running again at "Pass 11686 error count: 0" and running fine after the '4740' after the time is spaz'd when I touched it.

Have purposefully touched and handled the 16MB with no side effect - but may have been discharged? Maybe in touching I smashed the solder and pin together? Will have to go reflow that chip which I have not done yet looking for repro.

The DataLogger I abuced from a sample has been made into a Library - and just got an update that does validation on collected data with SD writes … will let that run.
 
Back
Top