Teensy 4.0 First Beta Test

[KurtE]

@Paul - when I compile sometimes it is done and uploaded in ~5 secs. Other times the File save isn't shown done for 5 secs or 50 seconds to even start the compile. Maybe my SSD is funny? Or could it be T_ports?
I was going to ask when T_ports is queried and realized it is probably just before a connected T_sermon to T4 is set Offline - sure enough watching the title bar the compile doesn't start until T_sermon is [offline].
I think I've seen this sluggish behavior with no code changes - just doing Ctrl+U to get an Upload+Restart - but of course trying 20 Ctrl+U with no file save won't cause it now that I am looking at it - so maybe it is my SSD Teensy Drive. I suppose you'll know what the IDE does before T_ports disables Serial?

Note: I sometimes have found where I have done the start of a compile or upload and sometimes nothing really happens... Then I go back and do it again and it works...
Most of the time I attribute it to I must have done something wrong...

I have seen the if the processor dies and Serial monitor is in bad state, I need to close the window, before the build will happen.

@KurtE - wondering about the resiliency and independence of the systems [ SPI and _isr and Serial1.print and clock change ] of course I thought of something(s) I did before. RESULTS:: no problem.

@KurtE - looking at my Serial# printing under Fault problem (code used posted prior) - is there a reason or way to incorporate a fix for that in the code HardwareSerial? Where the FIFO gets empty but cannot summon an _ISR for normal operation - it would take an extra polling call perhaps a no_ISR_flush( with timeout ) to clear the buffer. As noted - when the buffer fills the current code does force out a char to FIFO to make room in the buffer - but that is not working in the general case to empty the buffer … under Fault. Perhaps the current .flush() code could have the interrupt level check added and when that is the case use code like I did to at least fill the FIFO once each call?

Yes the Hardware Serial code for both Teensy 3 and Teensy 4 for something like: Serial1.flush() will hang if it is running at a higher priority than the Serial port ISR or if interrupts are somehow disabled or ...
They both just do something like: (Serial1 T3.x/LC)

void serial_flush(void)
{
	while (transmitting) yield(); // wait
}

Where the ISR will clear the transmitting flag when the ISR has detected that the queue is empty and then the Transmit Complete (TC) condition is set.

So yest potentially the yield here could detect some of these conditions and do something like what the Serial1.write(x) does when the queue is full and it knows that the ISR will not be called (Note does not check for ISR's disabled....)...

[defragster]

I'm not getting a clear picture of what's really happening on your screen from only "the File save isn't shown done for 5 secs or 50 seconds to even start the compile".

Any chance you could record a screencast, so I can watch it happen?

Picture isn't clear - it is a surprise - but bottom line as stated :: Ctrl+U … IDE UI DEAD for 5 to 50 seconds. TaskMan does not show HIGH use on any process. Double click on a word in CODE usually select/highlights that word … UI is non-responsive … then the word will highlight as the compile begins. No response from MENU during dead IDE UI.

IDE Screen image is frozen:
> Code Console area is not cleared
> sometimes the IDE UI Upload Arrow is Yellow, sometimes not.
> The 'Code Changed' indicator in the sketch file name tab is present and goes away when the compile starts and the console clears.
> Any code highlight events are then processed as compile begins.

Just found 'WinKey+G' has GameCast built into OS - saved a 3MB Mp4 of a 30 second screencast - and repeated twice and both worked without delay. Just did it again and it did pause some short seconds :: SPI_Transfer_test _ Arduino 1.8.8 2019-02-01 09-35-08.zip
You can see I added 'xx' to sketch, that is deleted to cause file change, mouse moves to Upload - then a pause with no UI change for some couple of seconds until console window comes to life. Had to put the MP4 into zip to get it to upload.

If you can determine and let me know some idea of when T_ports or order of other events happen within the IDE before the file is saved and the Compile/Upload clears the console and begins.
Either from your reading/understanding of the IDE's JAVA code or T_ports give some UI indication in the IDE when it is started and working/waiting? If T_ports could inject 'debug' a LINE to the Console { or do a popup window? } as it starts and finishes I could easily see where that appears. Perhaps record Start Time when T_ports is called and End Time when it completes the SerMon search to take offline and show that when the compile is complete.

NOTE: moving the mouse in the IDE window, giving it focus or taking focus and returning to the IDE window does not cause the compile to begin … it is hanging under the covers and not waiting to get attention as IIRC seems to be the case on some MAC issue?

[defragster]

@KurtE - were the additions of the 500K _isr()'s with Serial1 print and the added CPU speed change in any way good tests/stresses of the SPI Async processing?

Indeed I saw the .flush code - it probably works well when not faulted.

I'll rewrite the code I hacked into the RTS() code into the Flush() if I can with the check on priority. Assuming you scanned that prior code and don't see it being a faulty Cut/Paste of existing code that would break normal operation.

Looking at Serial/Flush looks like :: void Serial.flush()
where 'flush() inherits from the Stream utility class. '
And Reference/StreamFlush looks like :: boolean stream.flush(), though it does not say when return is T .vs. F

For my purposes having a Boolean return 'True' when chars pushed to FIFO would allow waiting for buffer to be empty: while ( Serial1.flush() ) { delayMicroseconds(10); }

Given "class HardwareSerial : public Stream" Can the flush void return be changed to Boolean?

boolean serial_flush(void)
{
     boolean bRetVal = transmitting;

     // Insert interrupt function test here for alternate push chars to FIFO like hacked bool HardwareSerial::attachRts 

	while (transmitting) yield(); // wait
     return bRetVal;
}

[defragster]

Paul - the Win Game screen cast can capture the prior 30 seconds of a window - I just did that because an edit { added comment with 'xx' moved curse left between x's } and Ctrl+U took that long … only two screen shows are needed to show the action as nothing changes on screen with frozen UI as noted.

<EDIT> Paul: I also find the File / 'Open Recent' and picking a recent sketch can take a long time with frozen UI as well - after a few seconds I started counting seconds and got to 40 or 60. If T_ports is not involved in that then the problem is elsewhere.

While frozen 30+ seconds :

After/as Compile starts :

NOTE:: Setting IDE to 'use external editor' seems to stop this from happening both Ctrl+U and it seems 'Open Recent' takes only a couple second when it must parse external libs?

[manitou]

Did you use those tightly coupled GPIO registers the rt1060 has? They claim to get 150MHz using the new registers. See chapter 3.2.2 in this document https://www.nxp.com/docs/en/applicat...te/AN12240.pdf

OK, the 1060 fast GPIO on GPIO6-8 looks good. My scope is probably the limiting factor. So with 10 nop's between toggles I have a nice sine wave on scope (49 Mhz, period 20.4 ns, Vpp 1.68v). Faster toggle rates reduces the Vpp to a ripple. My testing was hampered by NXP's API GPIO_PinInit(GPIO6, 19, &led_config) which caused hard fault, so I had to use GPIO6->GDIR = 1<<19, toggling with GPIO6->DR_TOGGLE = 1<<19. And before setting GDIR, enable the fast GPIO with GPIO6 IOMUXC_GPR->GPR26 |= 1<<19. The GPIO6-8 share the PAD settings for GPIO1-3.

[luni]

Cool, did you try reading as well? That was much slower than writing on the 1050.

[defragster]

@manitou - That sounds promising for 1062 use in T4! Does that mean it is FASTER than T_3.6 given that your scope can keep up with T_3.6 toggle?

@KurtE - I removed my prior hack and migrated the code to flush() like this and it seems to work. I sketched in the bool return - but it is not needed:

void HardwareSerial::flush(void)
{
	bool bRetVal = transmitting_;
	int priority = nvic_execution_priority();
	if (priority <= hardware->irq_priority) {
		uint32_t head, tail, n;
		head = tx_buffer_head_;
		tail = tx_buffer_tail_;
		while (((port->WATER >> 8) & 0x7) < 4)
		{
			bRetVal = true;
			if (head == tail) break;
			if (++tail >= tx_buffer_total_size_) tail = 0;
			if (tail < tx_buffer_size_) {
				n = tx_buffer_[tail];
			} else {
				n = tx_buffer_storage_[tail-tx_buffer_size_];
			}
			port->DATA = n;
		}
		tx_buffer_tail_ = tail;
		if (head == tail) {
			port->CTRL &= ~LPUART_CTRL_TIE; 
  			port->CTRL |= LPUART_CTRL_TCIE; // Actually wondering if we can just leave this one on...
		}
	}
	else {
		while (transmitting_) yield(); // wait
	}
	// return bRetVal;
}

[Frank B]

@mjs, no problem
did a little update of output_is2 - PLL freq is now calculated automatically from sample-frequency (thanks WMXZ)

[mjs513]

@manitou - got me worried for a minute - great news.

@Frank
Tried modifying input_i2s to see if I can get it to work but keep running into the dumbest problem. I did do a little modification of you output_i2s file just for simplicity for me. Anyway here is what I did so far in case you are interested:

Just do a compile of our example and you will see what I mean

[tonton81]

<EDIT> Paul: I also find the File / 'Open Recent' and picking a recent sketch can take a long time with frozen UI as well - after a few seconds I started counting seconds and got to 40 or 60. If T_ports is not involved in that then the problem is elsewhere.

While frozen 30+ seconds :

After/as Compile starts :

I've always seen this lag issue when Opening a recent file in like, forever, it's an IDE issue im sure.

[KurtE]

@manitou - That sounds promising for 1062 use in T4! Does that mean it is FASTER than T_3.6 given that your scope can keep up with T_3.6 toggle?

@KurtE - I removed my prior hack and migrated the code to flush() like this and it seems to work. I sketched in the bool return - but it is not needed:

void HardwareSerial::flush(void)
{
	bool bRetVal = transmitting_;
	int priority = nvic_execution_priority();
	if (priority <= hardware->irq_priority) {
		uint32_t head, tail, n;
		head = tx_buffer_head_;
		tail = tx_buffer_tail_;
		while (((port->WATER >> 8) & 0x7) < 4)
		{
			bRetVal = true;
			if (head == tail) break;
			if (++tail >= tx_buffer_total_size_) tail = 0;
			if (tail < tx_buffer_size_) {
				n = tx_buffer_[tail];
			} else {
				n = tx_buffer_storage_[tail-tx_buffer_size_];
			}
			port->DATA = n;
		}
		tx_buffer_tail_ = tail;
		if (head == tail) {
			port->CTRL &= ~LPUART_CTRL_TIE; 
  			port->CTRL |= LPUART_CTRL_TCIE; // Actually wondering if we can just leave this one on...
		}
	}
	else {
		while (transmitting_) yield(); // wait
	}
	// return bRetVal;
}

I guess the real question to me, is, what should the yield do when the priority is inverted, like you mentioned.

That is in normal cases, the calls like Serial1.flush() will not return until the last byte that was queued to output on Serial1 has output including all of the bits shifted out, and if there is a transmitter pin enabled on that pin, it will have changed states.

With your above code the flush in the inverted case will return after filling up the output queue... But before the actual data has been transmitted. Probably fine as it would just have hung in current code base.

If desired, I could probably update the above to do the full flush, but not sure if that is what you expect (or want) in this case?

[Frank B]

@mjs - did more updates (https://github.com/FrankBoesing/audio_imxrt) effects and more updated to #if defined(__ARM_ARCH_7EM__)
Now, more sketches should work (everything untested)

Did not work on i2_input, yet..

Good night.

[mjs513]

Good night Frank. At least its the weekend

[defragster]

KurtE - As written the normal case is excluded under the else - it won't try to yield in the inverted priority. I wasn't sure what that might do in the fault condition with the evolning yield during fault.

This isn't 'normal' and generally this is just a bandaid for fault condition. Though I suppose flush() could be called with inverted priority?

It would he cleaner and more consistent if it stayed until head==tail and buffer was empty. If it at least moves data to FIFO that is what is working, if it stayed until the buffer was empty that would be better.

In the T_3 code Paul handles this that test of public registers for each port - though that code is " #if 0 " in release code. And his current debugprint.c with dedicated Serial4 does well with direct write with a local printf routine.

[KurtE]

@defragster - I will play with it and see what you think.

Also I need to play with your SPI test program... Was gone some of the day and then played around some more with my hacked up Adafruit_SSD1306 display driver code.
It now supports both SPI flex objects as well as SPI objects.

Also added in the ability to call the update display function to do this Async... Then hacked up the display test program to now have two of these Teensyview objects connected up to the T4 One on the FlexSPI object and the other on the SPI ... So far I have not worked very hard at using the Async support. I did some primitive stuff on the last repeating display where I start up the update display of the SPI object and then call the normal update of the Flex object (have not added DMA support yet)...

But the simple setup did give me me both SPI units outputting at same time...


With the displays:


Not sure maybe I upload this updated SSD1306 driver to own project...

[mjs513]

@KurtE

Not sure maybe I upload this updated SSD1306 driver to own project...

That sounds good.. Guess I will have to pick up a couple teensyviews to play with now

@Frank
Ran a few of the tests - no SD Card yet. But here is what I got:

simple_drum    - no
PlaySynthMusic - no
Guitar         - yes
SimpleWaveTable- lost usb
Zelda          - .data' will not fit in region `DTCM'
Chorus         - needs input i2s
VolumeRamp     - need dac
ToneSweep      - modified for sgtl500, works
               - using audioShield np work

Assumed anything with AudioInput or DAC or ADC hasn't been implemented yet. Doesn't leave much. Wish the breakout board had extra pins on the side to do jumpering and for inputs to test a few more of the sketches. Guess its time to make one up.

EDIT: Almost forgot
@Paul. Not sure this is related to USB issues or unique to the audio library but sketches don't always upload automatically - most of the time on the first load I have to press the button.

EDIT2: Just order a couple of kits from PJRC (buttons/knobs etc) to experiment with.

[defragster]

@KurtE - I'm sure whatever makes sense to you from that will be good

QUESTION: Is necessary to have inside the while()? When I was testing the debug_tt trace I put a trace on nvic_execution_priority() and it was called MANY times!

size_t HardwareSerial::write9bit(uint32_t c)
// ...
	while (tx_buffer_tail_ == head) {
		int priority = nvic_execution_priority();

Hope the adds to your SPI test are reasonable - they seemed like they would add stress - and it did not interfere with your SPI code or the timing.

Looking at NXP to see if they did any DOC Rev's and the new ones seemed minor - in the process I read about the 1060 FlexIO's #3 channel having better/faster clock option - not sure if you saw that and if it will help.

Let me know about the TeensyView - if you give me the wire diagram I'll hook one up - hopefully the cracked glass isn't a bad sign. I do have another new in box.

I think I have one of the ssd1306 units that is typically i2c - the 64 high not 32 like the TView - that must be SPI as it has extra pins on the breakout including CS and DS - but still has pins labelled SDA SCL not MOSI MISO ????

[defragster]

…
EDIT: Almost forgot
@Paul. Not sure this is related to USB issues or unique to the audio library but sketches don't always upload automatically - most of the time on the first load I have to press the button.

Mike - one note says 'lost usb' - if anything in prior sketch/upload messes with USB function - or faults - that would require a button to update.

[mjs513]

Mike - one note says 'lost usb' - if anything in prior sketch/upload messes with USB function - or faults - that would require a button to update.

Tim - haven't experienced that in a very long time now. So far this is the first occurrence I have seen, since first getting the board. Specifically, the audio examples.

[KurtE]

@KurtE
That sounds good.. Guess I will have to pick up a couple teensyviews to play with now

I put current version up at: https://github.com/KurtE/SSD1306_FlexIO
Requires my FlxIO project: https://github.com/KurtE/FlexIO_t4
Current Beta should have all of the updated core stuff...

Should work with most SPI SSD1306 displays. I have somewhere some I got from Amazon, when testing on 3.5/6... They were 128x64, Will dig through my piles of stuff!

Pins For SPI object used standard SPI pins, plus any pins for DD, CS, Reset, in example: 21, 20, 15, which were the pins I setup originally on my Teensyview boards as they are CS pins on T3.5/6...

For FlexIO pin. I setup FlexSPI object on pins (2, 3, 4, -1) (MOSI, MISO, SCLK, CS) These need to be FlexIO pins and on the same FlexIO object (in this case 1:nn) then again CS, DC, RESET can be any digital pin.

[KurtE]

@KurtE - I'm sure whatever makes sense to you from that will be good

QUESTION: Is necessary to have inside the while()? When I was testing the debug_tt trace I put a trace on nvic_execution_priority() and it was called MANY times!

size_t HardwareSerial::write9bit(uint32_t c)
// ...
	while (tx_buffer_tail_ == head) {
		int priority = nvic_execution_priority();

I agree, I just copy and pasted from the T3.x function like what is in core3/serial1.c.

My guess is there is a slight possibility in the SerialX.write() case, that maybe there could be a usage case where maybe the SerialX. is called at a high priority, a higher priority IRQ happens, which maybe changes the priority of the mainline so when it returns, that maybe the condition changed? Again long shot, but figured it did not hurt anything as the code is mostly spinning doing nothing while it waits for data to be shifted out the UART...

Hope the adds to your SPI test are reasonable - they seemed like they would add stress - and it did not interfere with your SPI code or the timing.

Thanks, it is currently running on my machine I did have to edit it and replace the few Serial.print... to DBGSerial.print... where DBGSerial was defined as Serial4. With it calling the USB... Ran for awhile and now looks like I got a crash to look at.

ests completed
Press any key to run test
Ready to start tests
IntvTimer jj=1835312	IntvTimer jj=1836258	ms Time=3679
	ms Time=3680    deg C=36.55
Increasing voltage to 1300 mV
need to switch to alternate clock during reconfigure of ARM PLL
USB PLL is running, so we can use 120 MHz
Freq: 12 MHz * 67 / 1 / 1
ARM PLL=8000203A
ARM PLL needs reconfigure
ARM PLL=80002043
New Frequency: ARM=804000000, IPG=201000000
need to switch to alternate clock during reconfigure of ARM PLL
USB PLL is running, so we can use 120 MHz
Freq: 12 MHz * 67 / 1 / 1
ARM PLL=80002043
ARM PLL already running at required frequency

Fault irq 3
 stacked_r0 ::  4A65A527
 stacked_r1 ::  0001FBD0
 stacked_r2 ::  00410002
 stacked_r3 ::  00000000
 stacked_r12 ::  4659E827
 stacked_lr ::  0000022F
 stacked_pc ::  46D90002
 stacked_psr ::  0001008A
 _CFSR ::  00020000
 _HFSR ::  40000000
 _DFSR ::  00000000
 _AFSR ::  00000001
 _BFAR ::  E000ED38
 _MMAR ::  FFFFFFF1
need to switch to alternate clock during reconfigure of ARM PLL
USB PLL is running, so we can use 120 MHz
Freq: 12 MHz * 75 / 3 / 1
ARM PLL=80002043
ARM PLL needs reconfigure
ARM PLL=8000204B
New Frequency: ARM=300000000, IPG=150000000
Decreasing voltage to 1150 mV

Looking at NXP to see if they did any DOC Rev's and the new ones seemed minor - in the process I read about the 1060 FlexIO's #3 channel having better/faster clock option - not sure if you saw that and if it will help.

Let me know about the TeensyView - if you give me the wire diagram I'll hook one up - hopefully the cracked glass isn't a bad sign. I do have another new in box.

I think I have one of the ssd1306 units that is typically i2c - the 64 high not 32 like the TView - that must be SPI as it has extra pins on the breakout including CS and DS - but still has pins labelled SDA SCL not MOSI MISO ????

Now back to playing... Also digging out the other displays

[defragster]

I agree, I just copy and pasted from the T3.x function like what is in core3/serial1.c.

My guess is there is a slight possibility in the SerialX.write() case, that maybe there could be a usage case where maybe the SerialX. is called at a high priority, a higher priority IRQ happens, which maybe changes the priority of the mainline so when it returns, that maybe the condition changed? Again long shot, but figured it did not hurt anything as the code is mostly spinning doing nothing while it waits for data to be shifted out the UART...

Good point - it isn't going anywhere - if polling that keeps it out of trouble then the processor should be doing that.

Thanks, it is currently running on my machine I did have to edit it and replace the few Serial.print... to DBGSerial.print... where DBGSerial was defined as Serial4. With it calling the USB... Ran for awhile and now looks like I got a crash to look at.

ests completed
Press any key to run test
Ready to start tests
IntvTimer jj=1835312	IntvTimer jj=1836258	ms Time=3679
	ms Time=3680    deg C=36.55
Increasing voltage to 1300 mV

Awesome - the code change provided gives fault info as desired and works for somebody besides me! It looks like that is at 800 MHz - just transitioning from 100MHz? It ran as I provided to you overnight here with no issues. Not sure why it failed there unless 800 Mhz triggered something on that T4? you can see I put delay(500) before and after speed change to distance that from the test at hand.

I did move some output to USB just so it would be visible as the other two windows scroll faster and I didn't want to pollute the other Serial since it was printing from _isr - so DBGSerial a good place to put it. I just edited the _isr Serial1.print to show high digit of F_CPU so you can clearly see the current speed and change which is missing on fast scrolling DBGSerial.

Here is my current ver moved to DBGSerial w/no USB like yours - I also added 'Tests completed == 25' since running count is handy and if it fails again you'll know how quickly :: SPI_Transfer_test.ino

Now back to playing... Also digging out the other displays

I suppose I should wire up the TView display and see if it works.

[defragster]

Paul: Since the last Odd behavior all has been well - lots of debug_tt then Kurts Ansync SPI that was running last. Unplugged all for the TView SPI to follow and back into same USB hub on same PC USB, though cable swap ended T4 on different hub plug.

Powered and no sign of T4 again - as before the _T3.2's were online. Unpowered the T_3's and then repowering the T4 makes it show up. I had IDE and TLoader closed for wiring the TeensyView. Here is what TLoader Verbose recorded:

NoT4onrewire.txt

T4 was listed in T_ports when T_3's were off, now only the two T_3's show - but COM20 SerMon was opened when it existed and it persists. New upload gave this where it did ???? … {EDIT} TLoader says reboot okay and the orphaned T_sermon was coming back online - but IDE was confused? I closed the T_sermon and only IDE SerMon then connect … Kurt's SparkFun sketch had no !Serial wait … so it is working on IDE port SerMon.

Found 3 Teensy boards, but using auto-search to find board for upload.
Please use Tools > Ports(Teensy) to select the specific board.
Unable to open COM19 for reboot request
Windows Error Info: Access is denied.
more ideas... https://forum.pjrc.com/threads/40632...l=1#post126667

I put current version up at: https://github.com/KurtE/SSD1306_FlexIO
Requires my FlxIO project: https://github.com/KurtE/FlexIO_t4
Current Beta should have all of the updated core stuff...
...

Kurt - pulled down the INO and two github Zips. Set up the wires on breadboard as indicated in the sketch and SPI. I have falling snow flakes - screen not cracked - it is just the one dark layer angled across … didn't come up right away - did another upload and repowered in some fashion - given the above - screen data was just random specs. Pulled reset and it went dark - replugged just that wire in the process. at some point it came to life with your unchanged sketch. Nothing plugged in for second display2(). The Demo screens but one in the middle {edit:: odd inversion is perhaps by design} look clean and good - ends up with nice flake fall.

[defragster]

KurtE - something goes wrong … I was here and looked down and the stars were falling slowly if at all - I restarted and left - and they were stopped on return - without a flicker of the LED.

I'll look to integrate some debug tracing to see what is going on where … first time I change rand of the stars to random(2,4) wondering if it was the math … it was not it seems.
Just went through the code and pulled all the display2 - in no time the stars have fallen still after a great start through all prior screens. The one screen I thought was perhaps trashed is just an odd/unclean inversion.

<edit>: after I put in Serial1 tracking prints so I could see how long it took to fail and know if it was still running just not hitting display - it hasn't stalled again … of course.
It did 'stop' once after display2 code was removed - so it didn't seem to be that.
So I reduced delays in all test prior to the flakes so I could get there faster - no problem and no fail.
I put a falling int on pin #23 with a button to trigger - so I could really know if it was dead when it stops … not slowed or stopped.
I did a little speed up on the Async Flakes and 210K iterations and no fail - before speed up I got to 4K twice - have restarted at least once for edit after 100K no problem.
Restarted to reduce output including debug library note that Async already started from this speedup code and cycle time is 1 or 2 ms with delay(1):

    display1.displayAsync(); // Show the display buffer on the screen
    while ( !display1.displayAsync() ) delayMicroseconds( 10 );
    delay(1);        // Pause for 1/10 second

and again - no problems … now at 320K flake cycles

Wondering if one of the prior tests that ran longer before were getting the display controller in an odd state? Stopped flakes after 474K loops.
Took the end of setup into a function called from loop() and removed the call to the flake testanimate() …

With reduced delays the first 14 tests run in 4.4 seconds … let that run 50 passes. Have restored full run time to scroll test - a pass now takes 14.4 secs.
That ran 25 passes - so added flakes back in for 5K passes per loop - total per pass 23 secs … will see in a couple hours. Nothing odd after 18 passes.
Flake random(1,6) restored.

… 85 passes - no signs of trouble - maybe it was just not getting a clean reset as it was not very long before stalling before - and my initial power up experience was odd even though I had all 'connected' wires right …

except one missing - it was not powered on 3.3V pin - just feeding off of signal wires … back to the start KurtE test sketch after 101 passes on the prior - and it stopped perhaps a minute after the flakes started … no instrumentation installed for more info. Just this from the SerMon:

2002
timer index: 0 shifter index: 0 mask: 1
Before configure flexio
CCM_CDCDR: 33f71f92
FlexIO bus speed: 30000000
VERID:2100404 PARAM:1 CTRL:1 PIN: 0
SHIFTSTAT:1 SHIFTERR=0 TIMSTAT=0
SHIFTSIEN:0 SHIFTEIEN=0 TIMIEN=0
SHIFTSDEN:0 SHIFTSTATE=0
SHIFTCTL:830402 501 0 0
SHIFTCFG:0 0 0 0
TIMCTL:1c30601 0 0 0
TIMCFG:1002200 0 0 0
TIMCMP:f01 0 0 0
x: 74 y: -16 dy: 3
x: 9 y: -16 dy: 2
x: 73 y: -16 dy: 3
x: 19 y: -16 dy: 3
x: 3 y: -16 dy: 3
x: 107 y: -16 dy: 2
x: 23 y: -16 dy: 2
x: 111 y: -16 dy: 2
x: 63 y: -16 dy: 3
x: 110 y: -16 dy: 2

[Frank B]

@Frank
Ran a few of the tests - no SD Card yet. But here is what I got:

simple_drum    - no
PlaySynthMusic - no
Guitar         - yes
SimpleWaveTable- lost usb
Zelda          - .data' will not fit in region `DTCM'
Chorus         - needs input i2s
VolumeRamp     - need dac
ToneSweep      - modified for sgtl500, works
               - using audioShield np work

Assumed anything with AudioInput or DAC or ADC hasn't been implemented yet. Doesn't leave much. Wish the breakout board had extra pins on the side to do jumpering and for inputs to test a few more of the sketches. Guess its time to make one up.

Thank you for testing!
The Wavetable-examples need a "PROGMEM" before the const tables - I'e done that for Zelda and "Simple", but hear some clicks (with headphones) - don't know what that is. Never tried that on a T3.
Can you try the other wavetable examples and add the missing "PROGMEM" to all of them? (and create a pull-request to the repo?)

PlaySynthMusic works for me without problems.

Updated the repository.