Forum Rule: Always post complete source code & details to reproduce any issue!
Page 56 of 91 FirstFirst ... 6 46 54 55 56 57 58 66 ... LastLast
Results 1,376 to 1,400 of 2253

Thread: Teensy 4.0 First Beta Test

  1. #1376
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,373
    Quote Originally Posted by defragster View Post
    @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.


    Quote Originally Posted by defragster View Post
    @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)

    Code:
    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....)...

  2. #1377
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,000
    Quote Originally Posted by PaulStoffregen View Post
    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?

  3. #1378
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,000
    @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?

    Code:
    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;
    }

  4. #1379
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,000
    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 :Click image for larger version. 

Name:	IDE_Froze1.jpg 
Views:	5 
Size:	99.0 KB 
ID:	15798

    After/as Compile starts : Click image for larger version. 

Name:	IDE_Froze2.jpg 
Views:	4 
Size:	90.9 KB 
ID:	15800

    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?
    Last edited by defragster; 02-03-2019 at 01:16 AM.

  5. #1380
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,874
    Quote Originally Posted by luni View Post
    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.
    Last edited by manitou; 02-01-2019 at 07:04 PM.

  6. #1381
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    400
    Cool, did you try reading as well? That was much slower than writing on the 1050.

  7. #1382
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,000
    @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:
    Code:
    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;
    }

  8. #1383
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,513
    @mjs, no problem
    did a little update of output_is2 - PLL freq is now calculated automatically from sample-frequency (thanks WMXZ)

  9. #1384
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,948
    @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
    Attached Files Attached Files

  10. #1385
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,964
    Quote Originally Posted by defragster View Post

    <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 :Click image for larger version. 

Name:	IDE_Froze1.jpg 
Views:	5 
Size:	99.0 KB 
ID:	15798

    After/as Compile starts : Click image for larger version. 

Name:	IDE_Froze2.jpg 
Views:	4 
Size:	90.9 KB 
ID:	15800
    I've always seen this lag issue when Opening a recent file in like, forever, it's an IDE issue im sure.

  11. #1386
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,373
    Quote Originally Posted by defragster View Post
    @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:
    Code:
    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?

  12. #1387
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,513
    @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.

  13. #1388
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,948
    Good night Frank. At least its the weekend

  14. #1389
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,000
    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.

  15. #1390
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,373
    @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...
    Click image for larger version. 

Name:	screenshot.jpg 
Views:	9 
Size:	47.7 KB 
ID:	15804

    With the displays:
    Click image for larger version. 

Name:	IMG_0656.jpg 
Views:	10 
Size:	96.9 KB 
ID:	15805

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

  16. #1391
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,948
    @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:
    Code:
    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.
    Last edited by mjs513; 02-02-2019 at 12:49 AM.

  17. #1392
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,000
    @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!
    Code:
    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 ????

  18. #1393
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,000
    Quote Originally Posted by mjs513 View Post

    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.

  19. #1394
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,948
    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.

  20. #1395
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,373
    Quote Originally Posted by mjs513 View Post
    @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.
    Attached Files Attached Files

  21. #1396
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,373
    Quote Originally Posted by defragster View Post
    @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!
    Code:
    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...

    Quote Originally Posted by defragster View Post
    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.
    Code:
    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

    Quote Originally Posted by defragster View Post
    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

  22. #1397
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,000
    Quote Originally Posted by KurtE View Post
    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.
    Code:
    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.

  23. #1398
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,000
    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: 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
    Quote Originally Posted by KurtE View Post
    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.
    Last edited by defragster; 02-02-2019 at 06:06 AM.

  24. #1399
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,000
    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):
    Code:
        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
    Last edited by defragster; 02-02-2019 at 08:08 AM.

  25. #1400
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,513
    Quote Originally Posted by mjs513 View Post

    @Frank
    Ran a few of the tests - no SD Card yet. But here is what I got:
    Code:
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •