Teensy 4.0 First Beta Test

**defragster** · 02-02-2019, 11:43 PM

Originally Posted by KurtE

@defragster - Running your version of the sketch now...

In order to make it easier to read without magnifier, I changed setTextSize(2) instead of 1

I just screwed up and was thinking I was plugging in my USB to Serial adapter to my PC, but instead to wall wart (power for RPI3) and for some reason the Adafruit board started to show magic smoke... So now I am going into my parts and grabbing a different converter. Maybe Sparkfun FTDI Basic 3.3v version...

I had your version hang once... Did not have button hooked up nor other serial port... Current run > 88000

Need to setup the sparkfun hunit... Not sure if I will put on Serial1 or Serial4...

Kurt - see updated post above - all seems well!

And stop using those old school fangled gadgets - just break out a Teensy or two for SerMon Echo!

Larger font - DOH - that would be nice - Current run over 50K

SerMon and T4 USB ODDITIES
<edit>: Another Flakes run to 26K then I decided to unplug HUB with 3 Teensy's - SerMon and TLoader off and three windows of TyComm open - plugged in and up and running - no ODD/dead T4. And Flakes up and running at 10+K NOTE: IDE port/Teensy shows T4 and one T_3.1 but not the other T_3.1 now after the Hub cycle

<edit> Just confirmed with Two Hubs - Amazon Basics USB 3 and a USB 2 Rosewill:
>> Connect HUB unit with T4 and two SerMon ECHO T_3.1's running and it works.

>> Plug/Power Each T_3.1 and Windows 'welcomes' them. Then plug the T_4 and NOTHING.

Need to revisit this with new T4 USB update

**manitou** · 02-02-2019, 11:44 PM

Originally Posted by KurtE

.

Sounds like probably need to have some form of timeout here... May also need to do more efficient ISR handling. Although I tried to short cut some of this stuff...

I just added txbuf/rxbuf compare after transfer(txbuf,rxbuf,...), and changing while to use tx_count is NOT the solution, get lots of errors (but no hangs). using stock rx_count in while() seems to work error free at 20mhz or slower, but requesting 30 mhz or 40 mhz in SPISettings results in a hang. This is with flexio speed at 160mhz and using your latest from github.

Code:

  // err check jumper 2 to 3  MOSI to MISO
  for (int i = 0; i < sizeof(txbuf); i++) txbuf[i] = i;
  memset(rxbuf, 0, sizeof(rxbuf));
  assert_cs();
  SPIFLEX.transfer(txbuf, rxbuf, sizeof(txbuf));
  release_cs();
  SPIFLEX.endTransaction();
  int errs = 0;
  for (int i = 0; i < sizeof(txbuf); i++) if (txbuf[i] != rxbuf[i]) errs++;
  Serial.printf("errs %d [3] %d\n", errs, rxbuf[3]);

**KurtE** · 02-03-2019, 12:14 AM

Originally Posted by defragster

Kurt - see updated post above - all seems well!

And stop using those old school fangled gadgets - just break out a Teensy or two for

But I have several of these gadgets sitting around as I needed them for testing out USBHost code... Actually the one I fried, was one I just purchased a month or so ago as Lady Ada reported that it was not working with their boards...

@manitou - Probably for the higher speeds, I probably need to go to DMA, but as I mentioned this morning, I need to figure out what that means figuring out DMA stuff as it relates to FlexIO and only two DMAMUX_... for each FlexIO one I believe for shifters(0,1) and one for shifters(2,3) I think the example code if I am deciphering it properly is using shifters: 0, 2 and timers 0,1 (timers need to be contiguous)... I may need to hack up my library or usage to get shifters that will work.. But can be done.
May need to do a little hacking on knowing how I wish to use these...

**defragster** · 02-03-2019, 12:25 AM

Originally Posted by KurtE

But I have several of these gadgets sitting around as I needed them for testing out USBHost code... Actually the one I fried, was one I just purchased a month or so ago as Lady Ada reported that it was not working with their boards...

@manitou - Probably for the higher speeds, I probably need to go to DMA, but as I mentioned this morning, I need to figure out what that means figuring out DMA stuff as it relates to FlexIO and only two DMAMUX_... for each FlexIO one I believe for shifters(0,1) and one for shifters(2,3) I think the example code if I am deciphering it properly is using shifters: 0, 2 and timers 0,1 (timers need to be contiguous)... I may need to hack up my library or usage to get shifters that will work.. But can be done.
May need to do a little hacking on knowing how I wish to use these...

Well … you have one less now

- double bummer it was newest one bought for special purpose.

Now that all sermon is TyComm I've not seen trouble - newest restart (thanks larger font) reads 102,000 and counting with falling star flakes.

There is some perf hit early after setup() and something in IDE SerMon was triggering the T4 in a way that TyComm does not - so FlexSPI could use a touch of something to be immune to that.

**PaulStoffregen** · 02-03-2019, 01:25 AM

Originally Posted by KurtE

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...

Originally Posted by defragster

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.

I've added this to the issue list (msg #6) as "Arduino IDE unresponsive at times" (for lack of really understanding what's happening). Trying not to get into the Arduino IDE code right now, but definitely want to remember to fix this later.

**PaulStoffregen** · 02-03-2019, 01:35 AM

Edit: oh, nevermind... I just saw msg #1394. Added this to the issue list (msg #6)

Originally Posted by mjs513

@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.

Is this only with programs using audio?

**defragster** · 02-03-2019, 02:20 AM

Originally Posted by PaulStoffregen

I've added this to the issue list (msg #6) as "Arduino IDE unresponsive at times" (for lack of really understanding what's happening). Trying not to get into the Arduino IDE code right now, but definitely want to remember to fix this later.

Good collection of those issues. I added a note to 1379 :
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?

Not sure if this is on the list - SerMon and T4 USB ODDITIES
> it notes failure of T4 to 'arrive' on Windows when after other T_3.1's
> Also different behavior from TyComm versus IDE SerMon

BTW: with TyComm - before the unplug test for linked post 1426 - FlexSPI Flakes was over 400K, since restart back on hub it is powered up fine at 113K and counting.

**mjs513** · 02-03-2019, 02:29 AM

Originally Posted by PaulStoffregen

Edit: oh, nevermind... I just saw msg #1394. Added this to the issue list (msg #6)

Is this only with programs using audio?

So far yes. The hanging seems to especially prevalent when the sketch fails to run properly, really noticeable when I am running the wavetable sketches that I mentioned.

With "open recent" it does take a few seconds to open the sketch. But then again I am on my desktop with an i7 core. On the laptop it is another story.

@Paul
Not sure if this helps but I ran the playsynthmusic sketch (one of the ones giving me the problem) with the T4 on the breadboard so I could hook it up to the T3.2 for debugging. Sure enough, Tim's debug routing is tripping, here is the output:

Code:

***********IMXRT Startup**********
test 1 -1234567 3
CCM_ANALOG_PLL_USB1=80003000
  enable USB clocks
CCM_ANALOG_PLL_USB1=80003040
Increasing voltage to 1250 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 * 100 / 2 / 1
ARM PLL=80002042
ARM PLL needs reconfigure
ARM PLL=80002064
New Frequency: ARM=600000000, IPG=150000000
USB reset took 5 loops
analogInit
usb_cdc_line_coding, baud=0
before C++ constructors
after C++ constructors
before setup
usb_cdc_line_coding, baud=0
usb_cdc_line_coding, baud=115200
usb_cdc_line_coding, baud=115200
after setup
status = 000
Fault irq 3
 stacked_r0 ::  0CC20B12
 stacked_r1 ::  00020000
 stacked_r2 ::  00000030
 stacked_r3 ::  003F0030
 stacked_r12 ::  2020126A
 stacked_lr ::  0000000E
 stacked_pc ::  0000164C
 stacked_psr ::  01000056
 _CFSR ::  01000000
 _HFSR ::  40000000
 _DFSR ::  00000000
 _AFSR ::  00000000
 _BFAR ::  00000000
 _MMAR ::  00000000
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=80002064
ARM PLL needs reconfigure
ARM PLL=8000204B
New Frequency: ARM=300000000, IPG=150000000
Decreasing voltage to 1150 mV

**PaulStoffregen** · 02-03-2019, 03:05 AM

Originally Posted by Frank B

Hm.
@Paul: What shall we do with the Design-Tool ? There are big differences.. 2nd I2S.. MQS, SPDIF-In and more..
a) Copy it and create different versions (T3/T4)
b) Hack the tool and make it more intelligent with a drop-down for the model

Long-term, planning to make the gui more intelligent.

Short-term, let's just add stuff and let the list of inputs & output grow, but keep it as a local file, not on the public website until T4 is officially released.

Originally Posted by Frank B

I killed my audio shield.
Wouldn't be such a problem (have replacement) if I still had long pins...

Please email Robin and we'll get replacement hardware sent out on Monday. Even if you already put an order in, please contact Robin directly so we can send you a package by fast DHL.

I got 10 more of those breakout boards last week. 2 are built so far, still waiting on parts for the other 8. Might as well send an extra of those, just in case.

**defragster** · 02-03-2019, 04:29 AM

Originally Posted by mjs513

So far yes. The hanging seems to especially prevalent when the sketch fails to run properly, really noticeable when I am running the wavetable sketches that I mentioned.

With "open recent" it does take a few seconds to open the sketch. But then again I am on my desktop with an i7 core. On the laptop it is another story.

@Paul
Not sure if this helps but I ran the playsynthmusic sketch (one of the ones giving me the problem) with the T4 on the breadboard so I could hook it up to the T3.2 for debugging. Sure enough, Tim's debug routing is tripping, here is the output:

Code:

***********IMXRT Startup**********
   // …
Fault irq 3
 stacked_r0 ::  0CC20B12
 stacked_r1 ::  00020000
 stacked_r2 ::  00000030
 stacked_r3 ::  003F0030
 stacked_r12 ::  2020126A
 stacked_lr ::  0000000E
 stacked_pc ::  0000164C
 stacked_psr ::  01000056
 _CFSR ::  01000000
 _HFSR ::  40000000
 _DFSR ::  00000000
 _AFSR ::  00000000
 _BFAR ::  00000000
 _MMAR ::  00000000
// …

Cool - code as added wasn't faulty. So far that code just replaced what Paul had with labels on the values shown - courtesy of NXP community page.

Mike - can you catch me up - what do I need to download/install/update to run the Audio stuff and get where you are? Is it FrankB's github with Core and Audio update? Then your/other changes since then?

<edit>:
Mike/Frank - I get good working sound from >> "...\Audio\examples\Synthesis\Guitar\Guitar.in o"

And from "...\examples\Synthesis\PlaySynthMusic\PlaySynthMu sic.ino" I get the same fault as Mike.

**defragster** · 02-03-2019, 04:48 AM

Originally Posted by Frank B

Bounce does not work for Pin 1 (?) Can someone test this?

Frank - what sketch - how are you seeing "doesn't work"? Never returning a connect press - or not debouncing well? I'm testing on p#23 because I have a button there and will have to move Serial1 to test on Pin 1.

<EDIT>: it seems to be detecting my button presses on PIN#1 - I had to modify the bounce sketch to :: pinMode(BUTTON,INPUT_PULLUP);
Since my button just goes Pin# to GND

Mike are you using TyComm for upload and or sermon? I know Frank and luni have looked at the beta for TyComm. I tried and abandoned it at first because of odd USB - but it seems that was from mixed use - not dedicated.

**mjs513** · 02-03-2019, 06:26 AM

Originally Posted by defragster

Cool - code as added wasn't faulty. So far that code just replaced what Paul had with labels on the values shown - courtesy of NXP community page.

Mike - can you catch me up - what do I need to download/install/update to run the Audio stuff and get where you are? Is it FrankB's github with Core and Audio update? Then your/other changes since then?

Hi Tim,
Right now just using Frank's GitHub with the core and Audio update. Haven't put my changes in, wanted to focus on testing the changes Frank made first. Before he had the issue with his shield he said he was working on audio input. One question on the dump though, why is the ARM clock going back down to 300Mhz? also after that nothing is printed to the T3.2. The other thing is when I ran the flexcan sketch we were working on all I see are the status messages on the T3.2?

Mike are you using TyComm for upload and or sermon? I know Frank and luni have looked at the beta for TyComm. I tried and abandoned it at first because of odd USB - but it seems that was from mixed use - not dedicated.

I have been using the IDE and Sermon pretty much exclusively. I also use TyComm only for serial monitoring when I have more than one Teensy attached (just for serial monitoring though - not upload).

**defragster** · 02-03-2019, 06:41 AM

Originally Posted by mjs513

Hi Tim,
Right now just using Frank's GitHub with the core and Audio update. Haven't put my changes in, wanted to focus on testing the changes Frank made first. Before he had the issue with his shield he said he was working on audio input. One question on the dump though, why is the ARM clock going back down to 300Mhz? also after that nothing is printed to the T3.2. The other thing is when I ran the flexcan sketch we were working on all I see are the status messages on the T3.2?

We cross posted - I just updated above - I found Frank's post and link ...
Mike/Frank - I get good working sound from >> "...\Audio\examples\Synthesis\Guitar\Guitar.in o"
And from "...\examples\Synthesis\PlaySynthMusic\PlaySynthMu sic.ino" I get the same fault as Mike.

Dropping the ARM clock was an Idea I had to drop voltage/temp and chance of MCU abuse if it faults - it isn't going anywhere - and lower MHz gets dropped voltage - especially if the fault occurred running over 600 MHz with above standard voltage it is a safety net.

That is the base fault dump - similar to what T_3 offers - except in release builds that is turned off with "#if 0" - for now in Beta T4 that is pushed out with LED #13 blink - except I forgot to change the wait counts so the panic blink rate is slow at 300 MHz

I have been using the IDE and Sermon pretty much exclusively. I also use TyComm only for serial monitoring when I have more than one Teensy attached (just for serial monitoring though - not upload).

I'm wondering if that might be causing some USB confusion - mixing TyComm and IDE SerMon

Trying to find another to alternate with to test first upload all TyComm. Suppose any sketch … this on faults too :: "\examples\Synthesis\pulseWidth\pulseWidth.ino "

Mike: Using TyComm I can compile and upload GUITAR and then a BlinkMin sketch back and forth with no problem - no button.

**defragster** · 02-03-2019, 08:18 AM

Mike - I got as far as the sketch with debug_tt. Line numbers will change from insertions to Audio\examples\Synthesis\PlaySynthMusic\PlaySynthM usic.ino
It passes setup and enters loop() and on the 6th time after doing CMD_PLAYNOTE the first 5 times it finds 'if(c < 0x80)' - my line 258 shows it as 1 resulting in a 425 for d_time.
{didn't find my way yet in Audio to know where the interrupt takes it }

It then calls delay() and dies before it returns. I replaced that with delayMicroseconds(1000*d_time) - so it isn't the call - but the background interrupts in the lib where the fault happens?
When the fault happens I enter 'd' on the Serial1 sermon and it calls my local sketch function where I have it dump out the Trace that follows showing the code path as recorded.

Code:

loop256() stack var: 2001FFC4
_:L=258: c=1
_:L=259: d_time=425

debug_tt:: Fault irq 3
 stacked_r0 ::  cc20b12
 stacked_r1 ::  20000
 stacked_r2 ::  30
 stacked_r3 ::  3f0030
 stacked_r12 ::  2020126a
 stacked_lr ::  e
 stacked_pc ::  2d54
 stacked_psr ::  1000056
 _CFSR ::  1000000
 _HFSR ::  40000000
 _DFSR ::  0
 _AFSR ::  0
 _BFAR ::  0
 _MMAR ::  0

 userDebugDumptt() IN debug_tt  ___ 

 F_CPU=300000000
 >>>> debug_fault   >>>> debug_fault   >>>> TYPE:T_4
Debug Info:
1 => 1	0x1	[L#260_C#1
2 => 425	0x1A9	[L#261_C#2 _<< last func::loop

 >>>> debug_fault   >>>> TYPE:T_4

--- Halting >>>>  'y' to continue ...
	 'd' to call Debug_Dump()
	 'b' Teensy Bootloader
	 'r' Restart Teensy
	 'z' Zero Debug logs
Debug_Dump13() stack var: 2001FDD4
 User Custom Debug Dump. Micros==7065960
#1: (ii=25): CycCnt 557503636	line 255	func delay(d_time) pre
#2: (ii=24): CycCnt 557503579	line 220	func Loop Enter
#3: (ii=23): CycCnt 557503515	line 297	func loop
#4: (ii=22): CycCnt 557503473	line 295	func loop
#5: (ii=21): CycCnt 557503302	line 287	func CMD_PLAYNOTE
#6: (ii=20): CycCnt 557503243	line 220	func Loop Enter
#7: (ii=19): CycCnt 557503179	line 297	func loop
#8: (ii=18): CycCnt 557503137	line 295	func loop
#9: (ii=17): CycCnt 557502966	line 287	func CMD_PLAYNOTE
#10: (ii=16): CycCnt 557502907	line 220	func Loop Enter
#11: (ii=15): CycCnt 557502844	line 297	func loop
#12: (ii=14): CycCnt 557502802	line 295	func loop
#13: (ii=13): CycCnt 557502630	line 287	func CMD_PLAYNOTE
#14: (ii=12): CycCnt 557502571	line 220	func Loop Enter
#15: (ii=11): CycCnt 557502508	line 297	func loop
#16: (ii=10): CycCnt 557502466	line 295	func loop
#17: (ii=9): CycCnt 557502294	line 287	func CMD_PLAYNOTE
#18: (ii=8): CycCnt 557502235	line 220	func Loop Enter
#19: (ii=7): CycCnt 557502173	line 297	func loop
#20: (ii=6): CycCnt 557502132	line 295	func loop
#21: (ii=5): CycCnt 557501937	line 287	func CMD_PLAYNOTE
#22: (ii=4): CycCnt 557501872	line 220	func Loop Enter
#23: (ii=3): CycCnt 557033613	line 209	func AudioMemoryUsageMaxReset
#24: (ii=2): CycCnt 557033575	line 206	func AudioProcessorUsageMaxReset
#25: (ii=1): CycCnt 557033535	line 201	func setup done
#26: (ii=0): CycCnt 308960580	line 163	func setup

** lines 295 and 297 are before and after call to AudioInterrupts

**defragster** · 02-03-2019, 09:57 AM

Frank / Mike:
it dies on this memset: ...\teensy\avr\libraries\Audio\output_i2s.cpp

Code:

void AudioOutputI2S::isr(void)
// …
	} else {
  deb_tt( 4, dest );
    debTrace_tt( (uint32_t)dest, __LINE__, "memset(dest,0,AUDIO_BLOCK_SAMPLES * 2)" );
		memset(dest,0,AUDIO_BLOCK_SAMPLES * 2);
		return;
	}

This entry 4 from :: deb_tt( 4, dest );

Code:

Debug Info:
1 => 1	0x1	[L#261_C#1312
2 => 425	0x1A9	[L#262_C#1313
4 => 536896804	0x20006524	[L#291_C#1319 _<< last func::isr
5 => 536896804	0x20006524	[L#274_C#1318

These entries 1 and 4 from :: debTrace_tt( (uint32_t)dest, __LINE__, "memset(dest,0,AUDIO_BLOCK_SAMPLES * 2)" );
And entry #7 is from loop where it did the delay(d_time)

Code:

#1: (ii=486): CycCnt 536896804	line 292	func memset(dest,0,AUDIO_BLOCK_SAMPLES * 2)
#2: (ii=485): CycCnt 558447482	line 262	func DMA is transmitting the first
#3: (ii=484): CycCnt 558447381	line 256	func AudioOutputI2S::isr
#4: (ii=483): CycCnt 536896548	line 292	func memset(dest,0,AUDIO_BLOCK_SAMPLES * 2)
#5: (ii=482): CycCnt 557576734	line 268	func DMA is transmitting the second
#6: (ii=481): CycCnt 557576633	line 256	func AudioOutputI2S::isr
#7: (ii=480): CycCnt 557517658	line 256	func delay(d_time) pre
#8: (ii=479): CycCnt 557517601	line 221	func Loop Enter
#9: (ii=478): CycCnt 557517539	line 298	func loop
#10: (ii=477): CycCnt 557517497	line 296	func loop
#11: (ii=476): CycCnt 557517325	line 288	func CMD_PLAYNOTE

The example examples\Synthesis\pulseWidth\pulseWidth.ino seems to die in the same place - neither 'dest' is NULL:
This recorded it here in DEC then HEX:: 4 => 536880044 0x200023AC [L#291_C#903 _<< last func::isr

Code:

#1: (ii=903): CycCnt 536880044	line 292	func memset(dest,0,AUDIO_BLOCK_SAMPLES * 2)
#2: (ii=902): CycCnt 438280737	line 262	func DMA is transmitting the first
#3: (ii=901): CycCnt 438280636	line 256	func AudioOutputI2S::isr
#4: (ii=900): CycCnt 536879788	line 292	func memset(dest,0,AUDIO_BLOCK_SAMPLES * 2)
#5: (ii=899): CycCnt 437409997	line 268	func DMA is transmitting the second
#6: (ii=898): CycCnt 437409897	line 256	func AudioOutputI2S::isr
#7: (ii=897): CycCnt 536880044	line 292	func memset(dest,0,AUDIO_BLOCK_SAMPLES * 2)
#8: (ii=896): CycCnt 436539249	line 262	func DMA is transmitting the first
#9: (ii=895): CycCnt 436539149	line 256	func AudioOutputI2S::isr
#10: (ii=894): CycCnt 436144353	line 59	func setup

**mjs513** · 02-03-2019, 12:24 PM

Tim/Frank

Wow Tim, you been busy when I was sleeping after my last post. Was going to try and reread how to use you debug sketch. But the other thing I was thinking about that could be different on the installs is Frank's DMA change. Its just a thought that crossed my mind.

Mike: Using TyComm I can compile and upload GUITAR and then a BlinkMin sketch back and forth with no problem - no button.

Yep, I agree. Same with the IDE. Seems to happen when there is a hard fault.

EDIT: No, that wasn't it, incorporated the change based on the pull request but still faults.

**manitou** · 02-03-2019, 02:25 PM

flexio PWM

Not that we need more PWM pins, but I decided to play with flexio PWM from SDK example
boards/evkbimxrt1050/driver_examples/flexio/pwm
My small T4 test sketch is at https://github.com/manitou48/teensy4.../flexiopwm.ino
I hooked scope to pin 12, but didn't get the frequency I expected. I assumed pll3_sw_clk is running at 480mhz, but the output on pin 12 suggests 400mhz?? Maybe it's something in my flexio register config or ?? I hacked the sketch to use 400mhz.

EDIT: ooops, my prescaler divider field already had a 1 in it, and or'ing in 4 resulted in 5 (so divider is 6), github updated. Frequency and duty look good now.

**KurtE** · 02-03-2019, 04:39 PM

@manitou - Flexio PWM sounds like fun. Maybe have to integrate in some time...

Right now hacking up my set of FlexIO code to enable DMA on the SPI. Right now setting up code to try to request shifters that have different DMA channels for TX and RX, and now setting up callback... So hopefully soon will be able to get a DMA transfer to work.

But maybe diversion - looks like it is starting to sort of snow here, for the first time this season, so want to enjoy it!

**Frank B** · 02-03-2019, 06:12 PM

Tim / Mike:
Can you zip your Arduino-folder und send it to me?
All examples still work for me.. and I have no upload-problems.

Been on a family visit a long time today, and couldn't do much. But I would like to have a look at it now. I found a temporary solution for my audioshield problem with some wires and a new shield.

Edit: Tim, that memset-crash.. any idea what the reason is?

**Frank B** · 02-03-2019, 06:18 PM

Ha !
Just tried something and used "Optimize Debug" - now I have upload-problems and the crash, too

Before that I had set it to "fast", which worked.

With "Debug" :

Click image for larger version.

Name: 2019-02-03 19_21_22-Start.jpg
Views: 4
Size: 55.5 KB
ID: 15817

With "Fast" (works):

Click image for larger version.

Name: 2019-02-03 19_22_31-Start.jpg
Views: 5
Size: 55.5 KB
ID: 15818

Edit: Other issue:
If I use "Fastest- pure code" I get :

Code:

:\Arduino\hardware\teensy\avr\cores\teensy4\pwm.c: In function 'flexpwmFrequency':

C:\Arduino\hardware\teensy\avr\cores\teensy4\pwm.c:107:1: error: insn does not satisfy its constraints:

 }

 ^

(insn 32 27 28 2 (set (reg:SI 31 s15 [orig:114 D.5835 ] [114])

        (mem/v/c:SI (reg/f:SI 2 r2 [175]) [4 F_BUS_ACTUAL+0 S4 A32])) C:\Arduino\hardware\teensy\avr\cores\teensy4\pwm.c:87 615 {*thumb2_movsi_vfp}

     (nil))

C:\Arduino\hardware\teensy\avr\cores\teensy4\pwm.c:107:1: internal compiler error: in extract_constrain_insn, at recog.c:2246

Please submit a full bug report,

with preprocessed source if appropriate.

See <http://gcc.gnu.org/bugs.html> for instructions.

**mjs513** · 02-03-2019, 06:41 PM

Frank/Tim
Before I posted the Arduino folder (its 276mb zipped - don't think email would work) I tried to compile with Fast to see if it would work. Still get the upload problem and the crash. I created a shared folder on google drive that you can pull it down from: https://drive.google.com/drive/folde...xq?usp=sharing

Tim, if you want to put yours there as well, have fun.

**Frank B** · 02-03-2019, 06:43 PM

Thank you

**Frank B** · 02-03-2019, 07:28 PM

Yes, it crashes with your arduino folder.
Ok.. quick test, i deleted "your" teensy4 subfolder and copied mine.
works.

This is my version: https://drive.google.com/open?id=1UZ...p5yOh1BlcPvRr_

**MickMad** · 02-03-2019, 07:45 PM

Hey there! For some reasons, I just found out this thread!

I'm thrilled by the possibilities! This is amazing

Is there any plan on giving out more prototypes? I would very much love to test this for use in an upcoming product!

**defragster** · 02-03-2019, 07:50 PM

Originally Posted by Frank B

Yes, it crashes with your arduino folder.
Ok.. quick test, i deleted "your" teensy4 subfolder and copied mine.
works.

This is my version: https://drive.google.com/open?id=1UZ...p5yOh1BlcPvRr_

Frank - with your Teensy4 folder it builds as Fast' and runs to make sound.

Glad you had enough wires to connect your new shield.

Thread: Teensy 4.0 First Beta Test

Thread Tools

Search Thread

Display

Posting Permissions