Teensy 4.0 First Beta Test

Status
Not open for further replies.
@Frank B
I added an I2Cscanner function to the playsynthmusic.ino and it does recognoize a i2c device:
Code:
Begin C:\Users\Merli\AppData\Local\Temp\arduino_modified_sketch_641255\PlaySynthMusic.ino
setup done
Scanning...
I2C device found at address 0x0A  !
done

Proc = 1.38 (1.42),  Mem = 2 (5)
Proc = 2.74 (2.82),  Mem = 2 (16)
 
I am doing some Serial port tests, and my updates for Serial2 -

My Serial test program however is having some issues with Serial6 and Serial 7... I deleted Serial8

Code:
//connect  Serial1 TX -> Serial2 RX, Serial2 TX -> Serial3 RX, Serial3 TX -> Serial4 RX....


#define SPD 1000000
int loop_count = 0;
int receive_counts[8];
int callback_counts[8];

void setup() {
  pinMode(13, OUTPUT);
//  while (!Serial && millis() < 4000) ;
//  Serial.begin(115200);
  delay(800);
  Serial4.println("Test all Serials");
  Serial4.printf("Baud rate: %d\n", SPD);
  Serial1.begin(SPD);
  Serial2.begin(SPD);
  Serial3.begin(SPD);
  Serial4.begin(SPD);
  Serial5.begin(SPD);
  Serial6.begin(SPD);
  Serial7.begin(SPD);
}

void loop() {

  for (int i=0; i < 8; i++) {
    receive_counts[i] = 0;
    callback_counts[i] = 0;
  }
  Serial4.printf("Loop: %d\n", ++loop_count);  
  Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
  Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
  Serial1.print("012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789\n");
  delay(1000);
  Serial4.println();
  for (int i=0; i < 7; i++) {
    Serial4.printf("%d: %d %d ", i, callback_counts[i], receive_counts[i]);
  }
  Serial4.println();
}

void serialEvent1() {
  digitalWrite(13, !digitalRead(13));
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial1.available()), Serial4.availableForWrite());
  Serial1.readBytes(buffer, cb);
  Serial4.write(buffer, cb);
  callback_counts[0]++;
  receive_counts[0] += cb;
}

void serialEvent2() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial2.available()), Serial2.availableForWrite());
  Serial2.readBytes(buffer, cb);
  Serial2.write(buffer, cb);
  callback_counts[1]++;
  receive_counts[1] += cb;
}
void serialEvent3() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial3.available()), Serial3.availableForWrite());
  Serial3.readBytes(buffer, cb);
  Serial3.write(buffer, cb);
  callback_counts[2]++;
  receive_counts[2] += cb;
}
#if 0
void serialEvent4() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial4.available()), Serial4.availableForWrite());
  Serial4.readBytes(buffer, cb);
  Serial4.write(buffer, cb);
  callback_counts[3]++;
  receive_counts[3] += cb;

}
#endif

void serialEvent5() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial5.available()), Serial5.availableForWrite());
  Serial5.readBytes(buffer, cb);
  Serial5.write(buffer, cb);
  callback_counts[4]++;
  receive_counts[4] += cb;
}
void serialEvent6() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial6.available()), Serial6.availableForWrite());
  Serial6.readBytes(buffer, cb);
  Serial6.write(buffer, cb);
  callback_counts[5]++;
  receive_counts[5] += cb;
}
void serialEvent7() {
  uint8_t buffer[80];
  uint8_t cb = min (min((int)sizeof(buffer), Serial7.available()), Serial7.availableForWrite());
  Serial7.readBytes(buffer, cb);
  Serial7.write(buffer, cb);
  callback_counts[6]++;
  receive_counts[6] += cb;
}
For testing it, I am using Serial4 as the echo point (normally would have been Serial, but...). I start off jumper TX1->RX2 and then if I jumper TX2->RX1 it shows the string I was outputting.. So then move the RX1 to RX3 and then try TX3 to RX1 and it works... So I get to TX1->RX2, TX2->RX3, TX3->RX5, TX5-> RX1 and it works. Trying to RX6 or RX7 it is not showing it receiving any data.

Wondering if
A) the Pogo pins are working? Actually looking at the Adapter board I don't think there are any pogo pins installed for the bottom pins, except pins 30 and 31?
So makes sense it does they don't work ;)
 
I have a working i2c SSD1306 on T4-2

To get that I pulled Adafruit_GFX and Adafruit_SSD1306 into sketchbook\libraries from prior releases. To the hardware is working - but needs working libraries. The GFX needs some fixes - at least as used by the no longer included SSD1306 lib.
 
I noticed just the two POGO pins on the bottom 'pad array' - I didn't note which - nice to know that is #30 and #31 and others missing.

KurtE - if the Pin Adds for 'SD ARRAY' goes through - like it did on the T_3.6 than Serial8 would be usable on those pins.
 
I have a working i2c SSD1306 on T4-2

To get that I pulled Adafruit_GFX and Adafruit_SSD1306 into sketchbook\libraries from prior releases. To the hardware is working - but needs working libraries. The GFX needs some fixes - at least as used by the no longer included SSD1306 lib.
Becareful with the Adafruit GFX library - I had to update it to the latest from Adafruit - not sure if Paul pulled in the latest with beta11.
 
@mjs, Tim:
I2C:
Weird results with the audio-shield.
with my patched file (attached) I get different results every time i disconnect-and reconnect usb-cable. Output should be all 1s.

what I get is for example:
Code:
chip ID = A011
0
0
1
1
1
1
1
0
.. or it is completely different.
 

Attachments

  • control_sgtl5000.cpp
    35.7 KB · Views: 65
The core_pins.h was from this morning. The beta11 update was from yesterday so you have to manually make the change.
Oh thanks I didn't look at the commit time I thought that Teensy GitHub mirrored the teensyduino installer.
 
Oh thanks I didn't look at the commit time I thought that Teensy GitHub mirrored the teensyduino installer.
Most of the time if its stable. With T4 it can sometimes be a moving target and problems and PRs are incorporated. I feel bad for Paul - there is only so much time in the day for him :) Right now I actually pulled in SPI lib and Core changes from @KurtE for the T4-beta2.
 
@Frank B - @defragster

That is really weird. I have no ideas on this one. I keep wanting to say check pad config for SCL/SDA maybe something changes for 1062. But that is a passing thought.
 
As noted in 2353 - my first/only test so far for i2c works as expected on SDA/SCL labelled breakout pins to the SSD1306 display I see running Adafruit Flakes - only issue is missing/broken libraries.

Mike - can you compare the Adafruit_GFX you have versus the NEW one put into 1.46 late Beta when SSD1306 was pulled.

Is there a new SSD1306 we should get from AdaFruit? but the _GFX has type mismatch on Portset so it won't compile at least for T4

<UPDATE>: github.com/adafruit/Adafruit_SSD1306
This was last updated 5 months ago - and it is working with the "OLD _GFX" - I changed this line in header as needed that says this is deprecatated - perhaps with new _GFX?
#define SSD1306_128_64 ///< DEPRECTAED: old way to specify 128x64 screen

I see this was updated 2 days ago :: github.com/adafruit/Adafruit-GFX-Library

The one included in 1.46 is giving errors - so if one were to be Teensy Fixed for inclusion it should be the latest?

Pulled the Current Adafruit_GFX linked above and similar set of errors as that included in TD1.46:
Code:
"T:\\Ard186t4b2\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=146 -DARDUINO=10809 -DF_CPU=396000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\TEMP\\arduino_build_906278/pch" "-IT:\\Ard186t4b2\\hardware\\teensy\\avr\\cores\\teensy4" "-IT:\\Ard186t4b2\\hardware\\teensy\\avr\\libraries\\Wire" "-It:\\tcode\\libraries\\Adafruit_GFX" "-It:\\tcode\\libraries\\Adafruit_SSD1306" "-IT:\\Ard186t4b2\\hardware\\teensy\\avr\\libraries\\SPI" "t:\\tcode\\libraries\\Adafruit_GFX\\Adafruit_SPITFT.cpp" -o "T:\\TEMP\\arduino_build_906278\\libraries\\Adafruit_GFX\\Adafruit_SPITFT.cpp.o"
In file included from t:\tcode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:35:0:

t:\tcode\libraries\Adafruit_GFX\glcdfont.c:13:0: warning: "PROGMEM" redefined

  #define PROGMEM

 ^

In file included from T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/WProgram.h:41:0,

                 from T:\TEMP\arduino_build_906278/pch/Arduino.h:6,

                 from t:\tcode\libraries\Adafruit_GFX\Adafruit_GFX.h:5,

                 from t:\tcode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:34:

T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/avr/pgmspace.h:28:0: note: this is the location of the previous definition

 #define PROGMEM __attribute__((section(".progmem")))

 ^

t:\tcode\libraries\Adafruit_GFX\Adafruit_SPITFT.cpp: In constructor 'Adafruit_SPITFT::Adafruit_SPITFT(uint16_t, uint16_t, int8_t, int8_t, int8_t, int8_t, int8_t, int8_t)':

t:\tcode\libraries\Adafruit_GFX\Adafruit_SPITFT.cpp:124:24: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'PORTreg_t {aka volatile unsigned char*}' in assignment

     dcPortSet          = portSetRegister(dc);

                        ^

t:\tcode\libraries\Adafruit_GFX\Adafruit_SPITFT.cpp:125:24: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'PORTreg_t {aka volatile unsigned char*}' in assignment

     dcPortClr          = portClearRegister(dc);

                        ^

t:\tcode\libraries\Adafruit_GFX\Adafruit_SPITFT.cpp:126:24: error: cannot convert 'volatile uint32_t* {aka volatile long unsigned int*}' to 'PORTreg_t {aka volatile unsigned char*}' in assignment

     swspi.sckPortSet   = portSetRegister(sck);

// … more
 
Last edited:
OK, S/PDIF works on pin 2 ("output SPDIF2"), not on Pin 6 ("Output SPDIF") I remember there were changed pins.. which post-# was it?
 
I noticed just the two POGO pins on the bottom 'pad array' - I didn't note which - nice to know that is #30 and #31 and others missing.

KurtE - if the Pin Adds for 'SD ARRAY' goes through - like it did on the T_3.6 than Serial8 would be usable on those pins.

I am actually trying to debug the extra pins now... As can not test the other bottom pins yet, as nothing connecting them...

But so far my access to pins 34-39 with my current stuff is faulting:
Right now using Serial4 to test pins...
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 6 loops
analogInit
usb_cdc_line_coding, baud=0
before C++ constructors
after C++ constructors
before setup
Find Pin by blinking
Enter pin number to blink
Now Blinking pin 33

Fault irq 3
 stacked_r0 ::  3D314253
 stacked_r1 ::  00000001
 stacked_r2 ::  52452020
 stacked_r3 ::  200002A4
 stacked_r12 ::  E33CC779
 stacked_lr ::  000000CB
 stacked_pc ::  00000974
 stacked_psr ::  610E0200
 _CFSR ::  00000082
 _HFSR ::  40000000
 _DFSR ::  00000000
 _AFSR ::  00000000
 _BFAR ::  3D314257
 _MMAR ::  3D314257
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
Using my blink any pin:
Code:
int current_pin = 13;
int next_pin_number = 0;
#define DBGSerial Serial4
void setup() {
    // Blink any pin.  Note: I put pin 13 as input to see if we can
  // jumper to it to see if we can find the pin...
  while (!Serial && millis() < 5000);
  DBGSerial.begin(115200);
  delay (250);
  DBGSerial.println("Find Pin by blinking");
  DBGSerial.println("Enter pin number to blink"); 
  pinMode(13, OUTPUT);
}

void loop() {
  // put your main code here, to run repeatedly:
  if (DBGSerial.available()) {
    int ch;
    while ((ch = DBGSerial.read()) != -1) {
      if ((ch >='0') && (ch <= '9')) {
        next_pin_number = next_pin_number * 10 + (ch-'0');
      } else {
        if (next_pin_number != 0) {
          digitalWrite(current_pin, LOW); // turn the previous pin to low...
          current_pin = next_pin_number;
          pinMode(current_pin, OUTPUT);
          if (current_pin != 13)
            pinMode(13, INPUT);
          digitalWrite(current_pin, HIGH);
          next_pin_number = 0;  // setup to enter next pin
          DBGSerial.printf("Now Blinking pin %d\n\r", current_pin);
        }
      }
    }
    
  } else {
    digitalWrite(current_pin, !digitalRead(current_pin));
    delay(250);
  }
  

}
If not pin 13, it sets pin 13 to input so you can just jumper from specified pin to 13 and you should see blinks... Now debugging

EDIT: Fixed :D pins 34-39 blink appropriately. Pushed up changes to my core branch
 
@defragster

Here you go for the coremark

Thanks - that works - move to Serial from Serial4.

Added TempMon and it quickly gets to °C=57.869564 at 600 MHz … now with heat soaking it is °C=59.695652 { 139.4521736 degree Fahrenheit }

Odd the top is no where near that hot to touch. Max IR Thermo read on surface is 43C or 109F. Code now showing 60.3C as room is warming.

Did a quick mod for ~1 sec passes with count of 2500:
Code:
  float myTemp = 0;
  myTemp = tempmonGetTemp();
  Serial.printf( "BEFORE :: \t°C=%f\n" , myTemp );

  while (1) {
    mainCoreMark();
    myTemp = tempmonGetTemp();
    Serial.printf( "AFTER :: \t°C=%f\n" , myTemp );
  }

I put asm "wfi" in prior simple loop and it dropped temps 4-5 degrees C.

Doing this to make sure the new smaller PCB is as tolerant and capable of moving heat at speed.
 
@Paul, @mjs513 ...

Will do a PR with my pin changes soon. But first probably should convert mine to be in same format as Paul's changes. That is I made changes in the middle of the definitions for 1052 and 1062 versus Paul's creating new sections...

So will convert to Paul's and hopefully add new pins.

@defragster - forgot to answer your question:

Assuming PR is taken, the Uart8 pins are also on other IO pins associated with Serial5... So we can add Serial5.setTX and setRX for these pins. Will be a little more complicated then on T3 boards as you both have to change the mode of the IO pin as well as settings for associated MUX register.
 
As noted in 2353 - my first/only test so far for i2c works as expected on SDA/SCL labelled breakout pins to the SSD1306 display I see running Adafruit Flakes - only issue is missing/broken libraries.

Mike - can you compare the Adafruit_GFX you have versus the NEW one put into 1.46 late Beta when SSD1306 was pulled.

,,,,,,

<UPDATE>: github.com/adafruit/Adafruit_SSD1306
This was last updated 5 months ago - and it is working with the "OLD _GFX" - I changed this line in header as needed that says this is deprecatated - perhaps with new _GFX?
#define SSD1306_128_64 ///< DEPRECTAED: old way to specify 128x64 screen

I see this was updated 2 days ago :: github.com/adafruit/Adafruit-GFX-Library

The one included in 1.46 is giving errors - so if one were to be Teensy Fixed for inclusion it should be the latest?

Pulled the Current Adafruit_GFX linked above and similar set of errors as that included in TD1.46:
……..

Tim - looks like Adafruit did a mass rewrite of their spitft function to include DMA, etc. Now it bears no resemblance to what I was using when I tested it and said it was working with the latest version. I have the 1.3.6 version I think that works - unfortunately I deleted the version in my core library folder when I did the install.

EDIT: Ok found the version that worked - 1.3.6.
 
Probably 1.47-beta1 tomorrow. Going to fix some more stuff and merge pull requests. I have a little time now, since the next round of PCB have been ordered.

Nice, Since I'm not messing with Cores I'll wait for gathering of fixes and just poke around as I do. New PCB seems to be okay with MCU at 800 MHz.

@mjs513 - Bummer on the AdaFruit updates to _GFX needing attention to get running.

Merged arm_clock change into CoreMark, left output on Serial4 and just used Serial for the text below. I cut the iterations down to 300 so 100 MHz completed in a second and then just call until 30 seconds passes. And I killed 'error' on short run but put in a Serial.print if Other errors in CoreMark. Temp is rising ( Calibration seems off? as my finger and thermometer see max 110F ) - but no errors in running the CoreMark.
Code:
F_CPU MHz 99	Sec=30  CM#=43 [Max C=54.217392]	AFTER :: 	°C=53.000000
F_CPU MHz 201	Sec=30  CM#=67 [Max C=53.000000]	AFTER :: 	°C=52.391304
F_CPU MHz 300	Sec=30  CM#=94 [Max C=54.217392]	AFTER :: 	°C=53.608696
F_CPU MHz 402	Sec=30  CM#=119 [Max C=54.217392]	AFTER :: 	°C=54.217392
F_CPU MHz 498	Sec=30  CM#=140 [Max C=55.434784]	AFTER :: 	°C=54.826088
F_CPU MHz 600	Sec=30  CM#=160 [Max C=58.478260]	AFTER :: 	°C=57.869564
F_CPU MHz 696	Sec=30  CM#=177 [Max C=60.913044]	AFTER :: 	°C=60.913044
F_CPU MHz 804	Sec=30  CM#=194 [Max C=63.347824]	AFTER :: 	°C=63.347824
F_CPU MHz 99
25 sec Cooling Period ... 	°C=62.739132After Cool :: 	°C=54.217392
CM# is the number of calls to Coremark with 300 iterations - this shows how many complete in each period @MHz
 
Updated my core_pins.h file to use add my changes to Paul's version.

Next up try to run the ILI9488 display on SPI2 :D

@Paul (and others) One thing I noticed with both this Beta 2 board as well as Beta 1 (at least in the adapter boards). If I have the something like a USB to Serial adapter plugged into lets say Serial4 connection (using CP2104 adapter). And then plug in the T4 into USB, the board is not detected by PC... Not sure if it booted or not, but no sounds showing Serial port plugged in... But if the adapter is not connected comes up fine.
My guess is it has to do with the voltage on the RX pin back feeding?
 
@defragster

Temp is rising ( Calibration seems off? as my finger and thermometer see max 110F ) - but no errors in running the CoreMark.
Not sure why it is off - looked at the code several times and didn't see anything - will play around a little more it might be timing between measurements is too short.
 

@Paul (and others) One thing I noticed with both this Beta 2 board as well as Beta 1 (at least in the adapter boards). If I have the something like a USB to Serial adapter plugged into lets say Serial4 connection (using CP2104 adapter). And then plug in the T4 into USB, the board is not detected by PC... Not sure if it booted or not, but no sounds showing Serial port plugged in... But if the adapter is not connected comes up fine.
My guess is it has to do with the voltage on the RX pin back feeding?

in Post #6 :: teensy_ports issues with 3+ boards, #1330, #1398,

That sounds like behavior I was seeing many weeks back? Where I had to have other Teensy's OFFLINE in order for the T4-1 so show up. Those posts suggest it failed to start … @KurtE put a blink to see if it is running to confirm similarity

Seems I attributed that to Current Beta_T4 USB Stack function? Not seen for some time, perhaps it was not using IDE+SerMon+TeensyPorts - but moved to fulltime TyCommander. Since moving to Display off of the Breakout I have not had Serial UART out to other Teensys [ where I use a Teensy not lame USB adapter :) ]

One thing I did as a workaround was a powered USB HUB with 5 ports switch controlled and two Always On - so the T4-1 was Always on and I flipped the switch to disable all others when I saw the trouble.

Speaking of TyCommander - I emailed koromix power up and bootloader messages he shows in his app log - hopefully that will let him ID the T4-2 and get an update shortly.
 
Trying to RX6 or RX7 it is not showing it receiving any data.

Wondering if
A) the Pogo pins are working? Actually looking at the Adapter board I don't think there are any pogo pins installed for the bottom pins, except pins 30 and 31?
So makes sense it does they don't work ;)

Opps, I probably should have made one with all 10 pins for you. They were all done the same and soldering extra pins times 9 boards was time I didn't have. :(

I'll send you a package today with extra pogo pins and another bare PCB. Some assembly required. That's the most I can do at this moment. If you're still needing Serial6 & Serial7 hardware, ping me in a week or so and I'll get another board soldered up for you.
 
Status
Not open for further replies.
Back
Top