Teensy 4.0 First Beta Test

defragster · Mar 11, 2019

Frank B said:
@Paul can you add small pads (large enough to solder thin wires) where the flash-chip signals are accessible (and a way to deselect its chipselect externally)?
It would open a way to add a PSRAM like this: https://www.electrodragon.com/product/2pcs-ipus-ips6404-iot-ram/
If you want see DOOM on the T4 we need this

8 MBytes of RAM for <$1 is amazing - last RAM I saw was 128 KB for multiple $'s

Frank are you saying you want to be able to use BOTH RAM and SD card? So extra pads and a way to take the SD card offline to use those pins for the RAM access? Or is there something else tied to the CS use in operation?

DOOM would be cool - and probably faster than the last computers some of us ran it on.

Frank B · Mar 11, 2019

If it is possible to use the flash-signals for the ram it would be cached automatically.. we could just copy the flash to the ram to avoid problems. dunno if the interface supports more chipselects? If yes, even simpler..

I saw ESP modules using PSRAM.

mxxx · Mar 11, 2019

PaulStoffregen said:
Before messing with the on/off pin, please try commenting out the CPU speed change in startup.c.

Code:

set_arm_clock(600000000);

thanks, Paul. i've tried but it doesn't help it, unfortunately. fwiw, i've tried with three different PSUs (both linear and switching), which either feed a local 5V LDO (800mA) or a RECOM DC/DC converter, which in turn feeds the VIN pin. for now / testing purposes, it's not a biggie, i can bring up the teensy with USB and only then power the boards, it looks though as if people will eventually will run into boot-up issues (my scenario, for example, would be fairly wide-spread in music electronics).

manitou · Mar 11, 2019

PaulStoffregen said:
RT1062 brings GPT2_CAPTURE1 to GPIO_AD_B1_03, which is routed to Arduino 15/A1.

Ah, thanks. 1060 reference manual Table 9-1 does not show that option, but it is documented in Chapter 10 MUX pad details.

Frank B · Mar 11, 2019

Tim, no,not the SD Interface. The quad-spi for the flash-chip is ideal.

Edit: ordered a hand full...

Should work with the audioshield, too, for the older Teensys. but without the cache and quad-spi. (Or, with my old memory board.. 6x8MB

have to check the exact package-size..

WMXZ · Mar 11, 2019

Frank B said:
@Paul can you add small pads (large enough to solder thin wires) where the flash-chip signals are accessible (and a way to deselect its chipselect externally)?
It would open a way to add a PSRAM like this: https://www.electrodragon.com/product/2pcs-ipus-ips6404-iot-ram/
If you want see DOOM on the T4 we need this

100MHz SPI clock, becomes interesting
On a previous T3.1 system, I did the following,
on data available from ADC store on extRAM via spi,
on uSD available get data from extRAM and store on uSD

NOW:
with uSD access via SDIO
and extRAM access vio QSPI

one could fill-up latest 400GB uSD cards very quickly
(8 channels 192 kHz 32 bit + 4.608 MByte/s = 22.1GB/hour)

at the same time 8 MB RAM would give a buffer for 1.3 s

(OK, after dreaming I will wait for final T4)

Frank B · Mar 11, 2019

I wish I had seen this RAM a bit earlier.

mjs513 · Mar 11, 2019

FLEXCAN CLOCK HELP
Hi all me again with FLEXCAN. For the life of me I can not get Flexcan working..... I ported the SDK version over to the T4 and its doing the exact same thing as @tonton81's library is doing, i.e., gets stuck on transmit (doesn't receive either). Doesn't look like there is an signal on pins 0,1 (CAN2). I also tried CAN1 and it doesn't work either so either its a problem with the way I am setting up the clock or pin configs.

I think I need a sanity check on how I am setting up the Flexcan clock first and then I can play with the pin configurations. So here goes.

In the SDK example the clock is configured with the following parameters:

Code:

/* Select 80M clock divided by USB1 PLL (480 MHz) as master flexcan clock source */
#define FLEXCAN_CLOCK_SOURCE_SELECT (2U)
/* Clock divider for master flexcan clock source */
#define FLEXCAN_CLOCK_SOURCE_DIVIDER (3U)
/* Get frequency of flexcan clock */
#define EXAMPLE_CAN_CLK_FREQ ((CLOCK_GetFreq(kCLOCK_Usb1PllClk) / 6) / (FLEXCAN_CLOCK_SOURCE_DIVIDER + 1U))

The sketch I have configures the clock as follows:

Code:

  CCM_CSCMR2 = (CCM_CSCMR2 & 0xFFFFFC03) | CCM_CSCMR2_CAN_CLK_SEL(2) |CCM_CSCMR2_CAN_CLK_PODF(3);

Then I enable the clock:

Code:

CCM_CCGR0 |= (0xF << 18);

I also tried:

Code:

  CCM_CCGR0 |= CCM_CCGR0_CAN2(CCM_CCGR_ON); 
  CCM_CCGR0 |= CCM_CCGR0_CAN2_SERIAL(CCM_CCGR_ON);

I think that is all I have to do to enable the Flexcan Clock. Assuming tonton81 and I did it right it should enable the clock.

For the pin config:

Code:

    //-------------------------------------//
    //rx configure pin for flexcan
    CORE_PIN0_CONFIG = 0x10;        // alt 0 is can2
    IOMUXC_FLEXCAN2_RX_SELECT_INPUT = 0x01;
  
    //pin1, can2 TX B0_02
    CORE_PIN1_CONFIG = 0x10;
    //uint32_t fastio =  IOMUXC_PAD_SRE | IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3);

    CORE_PIN0_PADCONFIG = 0x10B0;
    CORE_PIN1_PADCONFIG = 0x10B0;  // 0x1A081, 0x10B0

Tried a couple different pad configs as well.

Thanks
Mike

tonton81 · Mar 11, 2019

quad SPI could be interesting for slave mode setup between 2 T4’s (SPI_MST?)

Pensive · Mar 11, 2019

Frank B said:
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.

Zelda working perfectly for me now - thanks for the patches Frank;
"Global variables use 25280 bytes (9%) of dynamic memory, leaving 236864 bytes for local variables. Maximum is 262144 bytes."

Plenty of room left for multiple sound sources in memory - how exciting

PaulStoffregen · Mar 11, 2019

mxxx said:
i've tried with three different PSUs (both linear and switching), which either feed a local 5V LDO (800mA) or a RECOM DC/DC converter, which in turn feeds the VIN pin.

Do you have an oscilloscope? Any chance you could capture the VIN & 3.3V startup waveforms?

Or can you give me more precise info about the exact power supplies you're using, so I can try to duplicate it here?

Pensive · Mar 11, 2019

SimpleDrum example works fine but only while the serial monitor is open!!?? I must admit I had trouble getting it to run - had to try quite a few times and can't work out why...

edit: So resetting the board doesn't fix it - opening the serial monitor i only get one line - but resetting the board while the serial monitor is open makes the loop work

duff · Mar 11, 2019

PaulStoffregen said:
If anyone with the 1052 beta wants to hack their board for PMIC_ON_REQ, you can find a pair of (tiny 402 size) resistors just to the right hand side of the 3.3V regulator.

Where is the 3.3V regulator located on the board?

PaulStoffregen · Mar 11, 2019

duff said:
Where is the 3.3V regulator located on the board?

Just below and to the right of the USB connector. It's the square chip located above and slightly to the left of Arduino pin 1.

Pensive · Mar 11, 2019

MidiSynthLarge won't compile.

If I select plain old Midi under Tool > USB it hangs on the serial output usage.
If i select any of the other options with Midi and Serial (including Midix versions) i get "MidiSynthLarge:120: error: 'usbMIDI' was not declared in this scope".
So I tried going back to just MIDI and deleting all the Serial references - however as expected - this just brought me back to "usbMidi was not declared in this scope."

I'll write some simpler code to see if I can get usbmidi to work at all

Edit: Nope - even the example code here doesn't compile - same error.
So that's in and out usb midi not working at the moment.

Pensive · Mar 11, 2019

Similiar Problem with PassThroughUSB - setting USB type to Audio doesn't allow the example to compile at this time.

Pensive · Mar 11, 2019

PaulStoffregen said:
Yes, indeed USB is very complicated. The controllers in this new chip are basically the same as the 2nd port on Teensy 3.6 (where we've only supported host mode, never device mode). It's completely different than the main port on all Teensy 3.x boards. The hardware is far more powerful, but also more complex, and that's all on top of the tremendous complexity of USB in general.

I'm planning to make some changes from the overall USB stack design from Teenxy 3.x, mainly with how memory is allocated. Most of those design choices were made in 2011-2012 for Teensy 3.0 with only 16K RAM. Those choices also revolve around that controller's hardware operating at the USB token level. Now that we have far more RAM, 20X the bandwidth (480 Mbit vs 12 Mbit), and a controller scheme designed around the USB transfer level, I'm planning to do things differently. The main difference will involve the memory allocation. I want to get away from a shared pool of buffers at the device level. The general idea for 4.x is memory allocated by the interface level code.

So the code for Teensy 3.x isn't a good road map for how I want this to work on Teensy 4.

that explains it

I'll move on to FastLED for now

defragster · Mar 11, 2019

Pensive said:
that explains it I'll move on to FastLED for now

As you found - Serial goes blocking when used if SerMon is not online - also Serial is T4 write only with NOP's for most of the rest of the func()'s - but a bit faster than T_3.x's. Have to use a Serial# port if bidirectional I/O is needed. Suppose you found the Serial4 Tx pin presents debug info? New USB stack is in Paul's queue.

Pensive · Mar 11, 2019

FastLED won't accept any kind of data pin value. It looks like there needs to be some kind of pin mapping added for this particular board. I'm using the DemoReel100 example.

I'm keeping it simple with a 7 LED neopixel jewel running at maximum 5% on the 3.3v output. I'm not sure if that's going to do some electrical mischief at this stage but I doubt it given the low brightness setting - I'm also not sure if there are any 5v tolerant pins but i doubt it very much - I;ve assume dnot and dont want to complicate things with a converter if I can avoid it. I'm using a 220Ohm resistor on the data pin. I tried multiple data pins - they all came back with the same error.

Think I'll drop down to one neopixel tomorrow, to be safe. Was hoping for some ridiculously fast fastled action but maybe next time

Code:

In file included from C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:1:0:

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:573:2: warning: #warning "No pin/port mappings found, pin access will be slightly slower. See fastpin.h for info." [-Wcpp]

 #warning "No pin/port mappings found, pin access will be slightly slower. See fastpin.h for info."

  ^

In file included from C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:1:0:

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:17:21: note: #pragma message: FastLED version 3.001.008

 #    pragma message "FastLED version 3.001.008"

                     ^

In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:68:0,

                 from C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:1:

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/fastspi.h:110:23: note: #pragma message: No hardware SPI pins defined.  All SPI access will default to bitbanged output

 #      pragma message "No hardware SPI pins defined.  All SPI access will default to bitbanged output"

                       ^

In file included from C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:1:0:

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h: In static member function 'static CLEDController& CFastLED::addLeds(CRGB*, int, int)':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:238:62: warning: large integer implicitly truncated to unsigned type [-Woverflow]

    case WS2801: { static WS2801Controller<DATA_PIN, CLOCK_PIN> c; return addLeds(&c, data, nLedsOrOffset, nLedsIfOffset); }

                                                              ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h: In static member function 'static CLEDController& CFastLED::addLeds(CRGB*, int, int)':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:251:73: warning: large integer implicitly truncated to unsigned type [-Woverflow]

    case WS2801: { static WS2801Controller<DATA_PIN, CLOCK_PIN, RGB_ORDER> c; return addLeds(&c, data, nLedsOrOffset, nLedsIfOffset); }

                                                                         ^

In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:51:0,

                 from C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:1:

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/fastpin.h: In instantiation of 'class FastPin<1u>':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/platforms/avr/clockless_trinket.h:96:49:   required from 'class ClocklessController<1u, 99, 248, 149, (EOrder)66u, 0, false, 10>'

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/chipsets.h:468:7:   required from 'class WS2812Controller800Khz<1u, (EOrder)66u>'

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:104:52:   required from 'class WS2812<1u, (EOrder)66u>'

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:298:39:   required from 'static CLEDController& CFastLED::addLeds(CRGB*, int, int) [with CHIPSET = WS2812; unsigned char DATA_PIN = 1u; EOrder RGB_ORDER = (EOrder)66u]'

C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:32:64:   required from here

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/fastpin.h:207:2: error: static assertion failed: Invalid pin specified

  static_assert(validpin(), "Invalid pin specified");

  ^

Error compiling for board Teensy 4-Beta1.

SO, I tried adafruit neopixel library "strandtest" instead - also not compiling unfortunately.

Code:

In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb_desc.c:34:0:

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb_desc.h:686:28: error: 'ENDPOINT_TRANSMIT_ONLY' undeclared here (not in a function)

   #define ENDPOINT1_CONFIG ENDPOINT_TRANSMIT_ONLY

                            ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb_desc.c:1559:2: note: in expansion of macro 'ENDPOINT1_CONFIG'

  ENDPOINT1_CONFIG,

  ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb_desc.h:687:28: error: 'ENDPOINT_RECEIVE_ONLY' undeclared here (not in a function)

   #define ENDPOINT2_CONFIG ENDPOINT_RECEIVE_ONLY

                            ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb_desc.c:1564:2: note: in expansion of macro 'ENDPOINT2_CONFIG'

  ENDPOINT2_CONFIG,

  ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c: In function 'endpoint0_setup':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:311:23: error: 'CDC_ACM_ENDPOINT' undeclared (first use in this function)

   endpoint_queue_head[CDC_ACM_ENDPOINT*2+1].config = (CDC_ACM_ENDPOINT << 16);

                       ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:311:23: note: each undeclared identifier is reported only once for each function it appears in

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:312:23: error: 'CDC_RX_ENDPOINT' undeclared (first use in this function)

   endpoint_queue_head[CDC_RX_ENDPOINT*2+0].config = (CDC_RX_SIZE << 16) | (1 << 29);

                       ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:312:54: error: 'CDC_RX_SIZE' undeclared (first use in this function)

   endpoint_queue_head[CDC_RX_ENDPOINT*2+0].config = (CDC_RX_SIZE << 16) | (1 << 29);

                                                      ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:313:23: error: 'CDC_TX_ENDPOINT' undeclared (first use in this function)

   endpoint_queue_head[CDC_TX_ENDPOINT*2+1].config = (CDC_TX_SIZE << 16) | (1 << 29);

                       ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:313:54: error: 'CDC_TX_SIZE' undeclared (first use in this function)

   endpoint_queue_head[CDC_TX_ENDPOINT*2+1].config = (CDC_TX_SIZE << 16) | (1 << 29);

                                                      ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:338:3: error: 'usb_cdc_line_rtsdtr_millis' undeclared (first use in this function)

   usb_cdc_line_rtsdtr_millis = systick_millis_count;

   ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:339:3: error: 'usb_cdc_line_rtsdtr' undeclared (first use in this function)

   usb_cdc_line_rtsdtr = setup.wValue;

   ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c: In function 'endpoint0_complete':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:433:10: warning: variable 'setup' set but not used [-Wunused-but-set-variable]

  setup_t setup;

          ^

Error compiling for board Teensy 4-Beta1.

PaulStoffregen · Mar 11, 2019

PaulStoffregen said:
Or can you give me more precise info about the exact power supplies you're using, so I can try to duplicate it here?

I'm building a DC-DC switcher board right now, using a LM2671-5V chip, which has a configurable soft-start feature. I put a 22 nF capacitor on the soft start pin. Hopefully that will be enough?

MichaelMeissner · Mar 11, 2019

defragster said:
As you found - Serial goes blocking when used if SerMon is not online - also Serial is T4 write only with NOP's for most of the rest of the func()'s - but a bit faster than T_3.x's. Have to use a Serial# port if bidirectional I/O is needed. Suppose you found the Serial4 Tx pin presents debug info? New USB stack is in Paul's queue.

Yeah, I had just noticed that. I was hoping it might be a known bug. I must admit that I really like the ability in T3 to do Serial print's, not worrying whether the USB was connected or not.

defragster · Mar 11, 2019

MichaelMeissner said:
Yeah, I had just noticed that. I was hoping it might be a known bug. I must admit that I really like the ability in T3 to do Serial print's, not worrying whether the USB was connected or not.

Seems it worked non-Blocking in Dec - then went blocking after next Beta …

defragster said:
...
Yes Kurt - Serial writes Block with no SerMon - that was my request looking for confirmation in post #381

I noticed that Last Year Dec 31st in post #182 and it got logged … That came with Beta #4 in post #180 - it worked non-blocking in the prior beta - at the same time startup entry and Serial online came 100 [or more ] ms later than prior beta 3.

No doubt it will get fixed - but like the dead cycle counter it can mess with testing - I was doing the 1.5 MB SPEW testing and then killing SerMon to save the USB overload - and was testing for 'if ( Serial )' that came online in Beta 3 - then it went blocking … thought it was my machine as nobody else noticed.

<edit> From that post going back a couple of days to 2nd Jan Paul noted my post … waiting to follow up on my end when USB stack update is delivered.

From :: 12-31-2018, 10:55 AM post #182 after Beta 4 release

defragster said:
Downloaded and installed: Good work.

CycleCounter Problem solved in the sketches I ran - CycleCounter was active coming into setup()!

<edit>: And the USB debug control of LED_BUILTIN is out so the LED BLINKS right!

I see that :: while ( !Serial && millis() < 1000 ); now leaves the loop for Serial==TRUE! at millis=543 ! Though BLINK stops when SerMon Closed until opened
...

mxxx · Mar 11, 2019

PaulStoffregen said:
Do you have an oscilloscope? Any chance you could capture the VIN & 3.3V startup waveforms?

Or can you give me more precise info about the exact power supplies you're using, so I can try to duplicate it here?

sure, this is one i had access to this morning. yellow is VIN, blue is 3v3:

in this case, the 5V regulator is a LM1117, with 10uF at the input + output (this is the thing in question). (the LM1117 here is fed from a -/+12V supply (2.4A), but details here are beyond control of the designer, so to speak, there's a huge variety of +/- 12V PSUs people will use for powering synths).

the exact same board works for teensy 3.2 (without further ado) and teensy 3.6 (needs a MIC803).

Frank B · Mar 12, 2019

Paul, any chance for the PSRAM?

PaulStoffregen · Mar 12, 2019

I'm investigating the power startup issue now.

I can reproduce the problem here, at least in some cases. So far, I can only get it to happen when the 12V power starts up very slowly. Even with a 5V circuit having a long soft-start time, I can't make the problem happen if the 12V supply is already on and I connect the 12V power to the 5V supply by plugging in a connector. But if I turn a very slow starting 12V supply on/off, it's startup is so slow it affects the 5V startup, and that is affecting everything else enough to cause the startup problem.

If you could do another test, any chance you use that 3rd scope channel to monitor the 12V power too? Can you test whether turning the 12V supply on/off versus connecting an already-on 12V supply make a difference?

I can also say the PMIC_ON_REQ change makes a huge difference. So far I have not been able to get the problem to ever happen on the board with that change. I'm going to add more wires to both boards, so I can watch the startup of both 1.1V power, and maybe the 2.5V PLL power too. I have a couple theories about what might be happening here, but more work needed to really get to the bottom of this.

If you can do another test, to check whether the 12V supply's startup is a factor (difference between starting up the 12V supply while connected, versus pre-starting the 12V supply and then plugging it into the 5V regulator) that info would really help me to know whether I should focus more testing effort on the 5V stuff. I do have some LM1117 chips here, but they're all 3.3V, not 5V. I can get the 5V one in a few days, but maybe it's really that 12V 2.4A supply I need?

Teensy 4.0 First Beta Test

Senior Member+

Senior Member

Well-known member

Senior Member+

Senior Member

Well-known member

Senior Member

Senior Member+

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Senior Member+

Well-known member

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member

Well-known member