Teensy 4.0 First Beta Test

Status
Not open for further replies.
I found some strange behavior with T4:
Using this code (the delay example):
Code:
// Delay demonstration example, Teensy Audio Library
//   http://www.pjrc.com/teensy/td_libs_Audio.html
//
// Creates a chirp on the left channel, then
// three delayed copies on the right channel.
//
// Requires the audio shield:
//   http://www.pjrc.com/store/teensy3_audio.html
//
// This example code is in the public domain.

#define ledPin 13

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveformSine   sine1;          //xy=158,74
AudioEffectEnvelope      envelope1;      //xy=232,156
AudioEffectDelayExternal         delay1;         //xy=393,238
AudioMixer4              mixer1;         //xy=532,205
AudioOutputI2S           i2s1;           //xy=611,61
AudioConnection          patchCord1(sine1, envelope1);
AudioConnection          patchCord2(envelope1, delay1);
AudioConnection          patchCord3(envelope1, 0, i2s1, 0);
AudioConnection          patchCord4(delay1, 0, mixer1, 0);
AudioConnection          patchCord5(delay1, 1, mixer1, 1);
AudioConnection          patchCord6(delay1, 2, mixer1, 2);
AudioConnection          patchCord7(delay1, 3, mixer1, 3);
AudioConnection          patchCord8(mixer1, 0, i2s1, 1);
AudioControlSGTL5000     sgtl5000_1;     //xy=195,272

// GUItool: end automatically generated code

void setup() {
  // allocate enough memory for the delay
  AudioMemory(120);

  // enable the audio shield
  sgtl5000_1.enable();
  sgtl5000_1.volume(0.5);
  pinMode(ledPin, OUTPUT);

  // configure a sine wave for the chirp
  // the original is turned on/off by an envelope effect
  // and output directly on the left channel
  sine1.frequency(1000);
  sine1.amplitude(0.5);

  // create 3 delay taps, which connect through a
  // mixer to the right channel output
  delay1.delay(0, 110);
  delay1.delay(1, 220);
  delay1.delay(2, 330);
}

void loop() {

  envelope1.noteOn();
  delay(36);
  envelope1.noteOff();
  delay(4000);

}
freezes the MCU.The culprit is this line:
Code:
pinMode(ledPin, OUTPUT);
The code as such works for T36 and also for the internal delay. Commenting above line unfreezes the T40. This happens both on the Audo Shield and the BA TGA.
Please advise.
 
Running this code on T4 Beta breakout with Audio Shield and I hear only left channel tone. So it isn't processing the right channel audibly.

Indeed that pinMode() in setup() causes the left channel to go silent.

It isn't Faulting - but it is halting. Code below in setup() prints the "d" line but not the "e" line - after sine1.frequency() it won't accept delay() or delayMicroseconds() and continue.
Code:
  sine1.frequency(1000);
  Serial.printf(" setup d::  %u\n", micros());
  delayMicroseconds(36000);
  Serial.printf(" setup e::  %u\n", micros());

If pinMode() moved after that but before sine1.amplitude() - the same behavior repeats after next delay.

The problem is with :: AudioEffectDelayExternal delay1; //xy=393,238
Removing all refs to that delay1 - the tone still comes out in left channel and then pinMode() doesn't cause any trouble.

And this works in setup or loop() :: digitalWriteFast( ledPin, !digitalReadFast( ledPin ));
 
Your described behavior is a little different to my observation (i.e freezing the T40), but indeed removing all references to delay1 does work (without delay effect of course). Not that it really matters (as a workaround I can remove the pinmode statement), but I don't understand, why this command has this impact on T40 and not on T36. Ledpin 13 and SPI are AFAIK not related.
 
Your described behavior is a little different to my observation (i.e freezing the T40), but indeed removing all references to delay1 does work (without delay effect of course). Not that it really matters (as a workaround I can remove the pinmode statement), but I don't understand, why this command has this impact on T40 and not on T36. Ledpin 13 and SPI are AFAIK not related.

Because the SPI0 clock signal (SCK) for the T40 is on pin13 and for the T36 it is on pin14. And that signal is needed to access the external memory chip.
 
Because the SPI0 clock signal (SCK) for the T40 is on pin13 and for the T36 it is on pin14. And that signal is needed to access the external memory chip.

Is it? The T36 has 2 SCK0 signals, one on 13 and and on 14 (as sck0). I guess you meant that signal (sck0).
And should this: digitalWriteFast( ledPin, !digitalReadFast( ledPin )); toggle the LED?(it doesn't);
Actually I found this in the external_delay code:
Code:
#define SPIRAM_MOSI_PIN  7
#define SPIRAM_MISO_PIN  12
#define SPIRAM_SCK_PIN   14
So, Pin 13 is not used here.
https://www.pjrc.com/store/teensy3_audio.html
And this here supports the pin 13 theory. Very strange.
 
Last edited:
Is it? The T36 has 2 SCK0 signals, one on 13 and and on 14 (as sck0). I guess you meant that signal (sck0).
And should this: digitalWriteFast( ledPin, !digitalReadFast( ledPin )); toggle the LED?(it doesn't);

Yes, on the T4 with original sketch watch the T4's pin #13 LED when the pinMode() is commented. The light is glowing as it is being used as SCK on T4 during SPI access.

I picked an audio board with SPI Flash on it as I saw the header for that - but then I neglected to make the connection with the glowing LED that neurofun did - where the board is sitting the LED is not in line of sight.

When the pinMode alters that pin #13 with pinMode is breaks the setup done for SPI.

Not sure what should be on the flash or if it should be RAM for the delay … but changing the pinMode on that SCK pin in use for SPI explains the failure as observed.
 
Yes, if the SCK and LED share the same pin, that explains the whole mess. And yes, I can see the dim LED. What I still don&t understand, that the exernal delay is working at all, when there pin 14 is used.
 
Yes, if the SCK and LED share the same pin, that explains the whole mess. And yes, I can see the dim LED. What I still don&t understand, that the exernal delay is working at all, when there pin 14 is used.

Not sure about that comment and p#14? On Teensy4 - Pin #14 isn't valid for alternate SCK like T_3.6 and others.

The 1062 has so many pins that possible Alt funcs got distributed in wildly different ways it seems so picking pins with needed function didn't allow for other present pins to be usable ALT pins
 
Yes, if the SCK and LED share the same pin, that explains the whole mess. And yes, I can see the dim LED. What I still don&t understand, that the exernal delay is working at all, when there pin 14 is used.

The SPI pin definitions in effect_delay_ext.cpp don't matter when using a T4 since it has no alternate pins for SPI. Thus the pin numbers are hard coded as seen in the T4 portion of SPI.cpp.
Code:
void SPIClass::setMOSI(uint8_t pin)
{
	// Currently only one defined so just return...
}

void SPIClass::setMISO(uint8_t pin)
{
	// Currently only one defined so just return...
}

void SPIClass::setSCK(uint8_t pin)
{
	// Currently only one defined so just return...
}
 
Paul: Just notice triggering a 15 sec Restore on T4. Press button - Red LED dark - Red BLIPS at 15 seconds. I held it some time after that expecting it to bypass the RESTORE and when released it did the restore? Is there a expected to be a set timeout where Restore is aborted?
 
Hello everybody. I don't know if I'm writing in the right forum. A question. I have to buy a Teensy. If I buy a teensy 4 is it recognized as a midi tool by windows? Or from OSX? From what I understand in teensyduino 1.49 have implemented this possibility. If I can't do it with the Teensy 4 I will buy a Teensy 3.6.
 
Please don't ask the same question in multiple PJRC forums.

If you install Teensydunio 1.49, it has options for configuring a Teensy 4.0 with various MIDI options, just like it does for the Teensy 3.6 (and 3.5/3.2). Whether it has the complete support, I don't know, since I don't use it. But I know the options now exist.
 
Paul: Just notice triggering a 15 sec Restore on T4. Press button - Red LED dark - Red BLIPS at 15 seconds. I held it some time after that expecting it to bypass the RESTORE and when released it did the restore? Is there a expected to be a set timeout where Restore is aborted?

Came to say it seems like that shouldn't be an issue … then a couple of posts up I see this waiting an answer …

So I tried it again actually watching a clock and it does timeout and not Restore if held some few seconds after the Restore indication period starts.
 
The red LED "blip", which marks the moment releasing the button will trigger restore, happens after 13 seconds.

After 17 seconds, releasing the button will not trigger a restore. So you have 4 seconds from the "blip" on the LED to release the button. If you release more than 4 seconds after the "blip", restore is not triggered and it's treated like an ordinary press of the button which puts Teensy 4.0 into bootloader mode.

These times can vary up to ±3%, since they've based on a non-crystal oscillator inside the MKL02 chip.
 
Ok, now I'm closing this thread.

If there's anything still in need to fixing, or more questions to be asked & answered, now that we've had 3 software releases since this beta period ended, it should be post as a new thread or as a reply to thread about that specific issue.

This massive old thread about the T4 beta test, which ended several months ago, is now closed.
 
Status
Not open for further replies.
Back
Top