Teensy 4.0 First Beta Test

Status
Not open for further replies.
random is on the bug list. Compiling speedTest fails because no random(). Just copying cores/teensy3/WMath.cpp to cores/teensy4 fixes the problem, but i'm thinking there must be more to it?? The Teensy 4 TRNG is quite complicated, though the NXP SDK has working code. Was the intent for the "random" bug to try to incorporate T4 TRNG???
 
Frank B said:
This was your post for T3.6 beta test:
https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107134&viewfull=1#post107134
Click to expand...

The T3.6 TRNG is nothing like the T4 TRNG, and to my knowledge the T3.6 TRNG was never incorporated into the Teensy core. We demonstrated that it worked, and you could add it to your sketches that need crypto-strength RNG.

We should develop a working example of T4 TRNG, based on NXP SDK. The reference manual says almost nothing, and the SDK example sets lots of parameters for statistical tests that the crypto engine must use in generating 512 random bits. The SDK integrates TRNG into mbedtls and wolfssl. The T4 TRNG is slow so should just be used as an entropy source for a seed to a PRNG.

EVKB testing

degree of difficulty: the ref manual doesn't describe the registers, here's the SDK registers for T4 TRNG
Code: 
/** TRNG - Register Layout Typedef */
typedef struct {
  __IO uint32_t MCTL;                              /**< Miscellaneous Control Register, offset: 0x0 */
  __IO uint32_t SCMISC;                            /**< Statistical Check Miscellaneous Register, offset: 0x4 */
  __IO uint32_t PKRRNG;                            /**< Poker Range Register, offset: 0x8 */
  union {                                          /* offset: 0xC */
    __IO uint32_t PKRMAX;                            /**< Poker Maximum Limit Register, offset: 0xC */
    __I  uint32_t PKRSQ;                             /**< Poker Square Calculation Result Register, offset: 0xC */
  };
  __IO uint32_t SDCTL;                             /**< Seed Control Register, offset: 0x10 */
  union {                                          /* offset: 0x14 */
    __IO uint32_t SBLIM;                             /**< Sparse Bit Limit Register, offset: 0x14 */
    __I  uint32_t TOTSAM;                            /**< Total Samples Register, offset: 0x14 */
  };
  __IO uint32_t FRQMIN;                            /**< Frequency Count Minimum Limit Register, offset: 0x18 */
  union {                                          /* offset: 0x1C */
    __I  uint32_t FRQCNT;                            /**< Frequency Count Register, offset: 0x1C */
    __IO uint32_t FRQMAX;                            /**< Frequency Count Maximum Limit Register, offset: 0x1C */
  };
  union {                                          /* offset: 0x20 */
    __I  uint32_t SCMC;                              /**< Statistical Check Monobit Count Register, offset: 0x20 */
    __IO uint32_t SCML;                              /**< Statistical Check Monobit Limit Register, offset: 0x20 */
  };
  union {                                          /* offset: 0x24 */
    __I  uint32_t SCR1C;                             /**< Statistical Check Run Length 1 Count Register, offset: 0x24 */
    __IO uint32_t SCR1L;                             /**< Statistical Check Run Length 1 Limit Register, offset: 0x24 */
  };
  union {                                          /* offset: 0x28 */
    __I  uint32_t SCR2C;                             /**< Statistical Check Run Length 2 Count Register, offset: 0x28 */
    __IO uint32_t SCR2L;                             /**< Statistical Check Run Length 2 Limit Register, offset: 0x28 */
  };
  union {                                          /* offset: 0x2C */
    __I  uint32_t SCR3C;                             /**< Statistical Check Run Length 3 Count Register, offset: 0x2C */
    __IO uint32_t SCR3L;                             /**< Statistical Check Run Length 3 Limit Register, offset: 0x2C */
  };
  union {                                          /* offset: 0x30 */
    __I  uint32_t SCR4C;                             /**< Statistical Check Run Length 4 Count Register, offset: 0x30 */
    __IO uint32_t SCR4L;                             /**< Statistical Check Run Length 4 Limit Register, offset: 0x30 */
  };
  union {                                          /* offset: 0x34 */
    __I  uint32_t SCR5C;                             /**< Statistical Check Run Length 5 Count Register, offset: 0x34 */
    __IO uint32_t SCR5L;                             /**< Statistical Check Run Length 5 Limit Register, offset: 0x34 */
  };
  union {                                          /* offset: 0x38 */
    __I  uint32_t SCR6PC;                            /**< Statistical Check Run Length 6+ Count Register, offset: 0x38 */
    __IO uint32_t SCR6PL;                            /**< Statistical Check Run Length 6+ Limit Register, offset: 0x38 */
  };
  __I  uint32_t STATUS;                            /**< Status Register, offset: 0x3C */
  __I  uint32_t ENT[16];                           /**< Entropy Read Register, array offset: 0x40, array step: 0x4 */
  __I  uint32_t PKRCNT10;                          /**< Statistical Check Poker Count 1 and 0 Register, offset: 0x80 */
  __I  uint32_t PKRCNT32;                          /**< Statistical Check Poker Count 3 and 2 Register, offset: 0x84 */
  __I  uint32_t PKRCNT54;                          /**< Statistical Check Poker Count 5 and 4 Register, offset: 0x88 */
  __I  uint32_t PKRCNT76;                          /**< Statistical Check Poker Count 7 and 6 Register, offset: 0x8C */
  __I  uint32_t PKRCNT98;                          /**< Statistical Check Poker Count 9 and 8 Register, offset: 0x90 */
  __I  uint32_t PKRCNTBA;                          /**< Statistical Check Poker Count B and A Register, offset: 0x94 */
  __I  uint32_t PKRCNTDC;                          /**< Statistical Check Poker Count D and C Register, offset: 0x98 */
  __I  uint32_t PKRCNTFE;                          /**< Statistical Check Poker Count F and E Register, offset: 0x9C */
  __IO uint32_t SEC_CFG;                           /**< Security Configuration Register, offset: 0xA0 */
  __IO uint32_t INT_CTRL;                          /**< Interrupt Control Register, offset: 0xA4 */
  __IO uint32_t INT_MASK;                          /**< Mask Register, offset: 0xA8 */
  __I  uint32_t INT_STATUS;                        /**< Interrupt Status Register, offset: 0xAC */
       uint8_t RESERVED_0[64];
  __I  uint32_t VID1;                              /**< Version ID Register (MS), offset: 0xF0 */
  __I  uint32_t VID2;                              /**< Version ID Register (LS), offset: 0xF4 */
} TRNG_Type;

more recent tests: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195000&viewfull=1#post195000
 
Last edited:
Maybe you can make a library for both and Paul can include it to the core, later? The math is over my head when it comes to test that stuff and more complicated things, and I can not help :)
 
tried to understand migration (clock settings etc.) (no T4.0 yet)
So I verified an adhoc program (with i2s and dma)
after adding missing macros it compiled BUT in the end got this error
Code: 
Linking everything together...
"C:\\Users\\Walter\\Documents\\arduino-1.8.8\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O1 -Wl,--gc-sections,--relax "-TC:\\Users\\Walter\\Documents\\arduino-1.8.8\\hardware\\teensy\\avr\\cores\\teensy4/imxrt.ld" -lstdc++ -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -o "C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160/test_T4_I2S.ino.elf" "C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160\\sketch\\test_T4_I2S.ino.cpp.o" "C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160/core\\core.a" "-LC:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160" -larm_cortexM4lf_math -lm
"C:\\Users\\Walter\\Documents\\arduino-1.8.8\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160/test_T4_I2S.ino.elf" "C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160/test_T4_I2S.ino.eep"
"C:\\Users\\Walter\\Documents\\arduino-1.8.8\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -R .eeprom "C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160/test_T4_I2S.ino.elf" "C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160/test_T4_I2S.ino.hex"
"C:\\Users\\Walter\\Documents\\arduino-1.8.8\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160/test_T4_I2S.ino.lst" "C:\\Users\\Walter\\Documents\\arduino-1.8.8\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -d -S -C "C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160/test_T4_I2S.ino.elf"
"C:\\Users\\Walter\\Documents\\arduino-1.8.8\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160/test_T4_I2S.ino.sym" "C:\\Users\\Walter\\Documents\\arduino-1.8.8\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160/test_T4_I2S.ino.elf"
"C:\\Users\\Walter\\Documents\\arduino-1.8.8\\hardware\\teensy/../tools/teensy_post_compile" -file=test_T4_I2S.ino "-path=C:\\Users\\Walter\\AppData\\Local\\Temp\\arduino_build_60160" "-tools=C:\\Users\\Walter\\Documents\\arduino-1.8.8\\hardware\\teensy/../tools/" -board=TEENSY40
Teensy Loader could not find the file test_T4_I2S.ino

quitexit status 1
Error compiling for board Teensy 4-Beta1.

thought it should look for hex file and not ino file
There is a ino.hex file in the directory.
OK, I had an old teensy.exe open, after removing this file, TD compiled and started new Teensy loader
 
Last edited:
Looks like I will get my T4 this afternoon sometime - according to USPS its out for delivery.

@manitou - will give updating the toolchain a try later on went back to working on the initial temp monitoring sketch.

The temp monitor is pretty minimalistic. Have to add testing the interrupts to the sketch but want to do one piece at a time. Right now it is just set up for the getting the temperature and setting the alarms. Should go fast once I get the T4 and start debugging.
 
Forgot to mention, on the TRNG, my intention is to add this to the Entropy library. Not sure if the random number hardware in Teensy 3.5 & 3.6 ever got added there, but if not, that's where I want to see it added. I believe there's a copy of Entropy supporting Arduino Due's TRNG.

The main reason I want to do this in the Entropy library is because it facilitates everyone in the Arduino community creating hardware independent code. On boards without TRNG hardware, it slowly produces truly random bits using the skew the crystal and an RC oscillator clock (on AVR, using the watchdog timer).

Long term my hope is to see the Entropy library gain support for the TRNG hardware on all other boards. I probably won't put much time into supporting non-Teensy boards, but I do at least want to promote everyone creating programs that are as hardware independent as reasonably possible.
 
Looks like mine might arrive sometime today as well. Also an Adafruit board to test out issue with USBHost_t36 library, which I probably should do first...

Wondering best way to handle some updates here. I do have my fork of core GitHub project. Assuming we make contributions, I am assuming you will want Pull Requests for the updates.

Also wondering about hacking up a setup for making these types of changes. For example today when I am working on some Robotis setups (OpenCM9.04 or OpenCR), I now have their boards in the system twice. Once using their normal install (They use board manager...), and another one I have installed through the <sketch folder>/hardware... Where the board code actually does not exist, but I instead use symbolic links into my fork of code in GitHub... Then when changes are made, I can simply see them and do PR, and also can sync up my fork to current stuff... Wonder if that would make sense here as well?
 
Re: arm_math.h in bug list

I'm not an expert (and no beta board yet), but I have tested T3.6 with alternate arm_math.h libs, based on mods described at
https://forum.pjrc.com/threads/4059...Defined-Radio)?p=129081&viewfull=1#post129081

I went to https://github.com/ARM-software/CMSIS_5 to get latest arm_math.h and cm7 libs. Version is 1.5.4, but arm_math.h structure is different from my cheat-sheet URL above, so I used 1.5.1 from mbed/SDK libs. Editing arm_math.h for M7 and copying over libarm_cortexM7lfdp_math.a libarm_cortexM7lfsp_math.a and modifying boards.txt
teensy4b.build.flags.libs=-larm_cortexM7lfsp_math -lm

My DSPbenchmark compiled OK (even with corrected fpu setting). Awaiting beta board for execution test...
 
Last edited:
Installed the beta teensyduino addon and ran a compile of one of my test programs (audio, midi and serial). While I was able to copy some existing files from the Teensy 3 core folder to fix errors (probably not the right way to do it, but it sseems to have worked), I ran into one that I'm not sure how to handle.

This is my sample code:

Code: 
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>
#include "pitches.h"

  // GUItool: begin automatically generated code
AudioInputUSB            usb1;           //xy=180,398
AudioInputAnalogStereo   adcs1;          //xy=194,194
AudioMixer4              mixer1;         //xy=627,184
AudioMixer4              mixer3;         //xy=631,401
AudioMixer4              mixer2;         //xy=636,291
AudioMixer4              mixer4;         //xy=642,534
AudioOutputAnalogStereo  dacs1;          //xy=1209,218
AudioOutputUSB           usb2;           //xy=1221,431
AudioConnection          patchCord1(usb1, 0, mixer3, 0);
AudioConnection          patchCord2(usb1, 1, mixer4, 0);
AudioConnection          patchCord3(adcs1, 0, mixer1, 0);
AudioConnection          patchCord4(adcs1, 0, mixer3, 1);
AudioConnection          patchCord5(adcs1, 1, mixer2, 0);
AudioConnection          patchCord6(adcs1, 1, mixer4, 1);
AudioConnection          patchCord7(mixer1, 0, usb2, 0);
AudioConnection          patchCord8(mixer3, 0, dacs1, 0);
AudioConnection          patchCord9(mixer2, 0, usb2, 1);
AudioConnection          patchCord10(mixer4, 0, dacs1, 1);
// GUItool: end automatically generated code 



// Stuff for running keyboard
char keystate[61] = {0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0};

char keystate_prev[61] = {0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0,0,0,0,0,0,
  0};

char pins_rows[6] = {5,4,3,2,1,0};
char pins_cols[11] = {11,14,16,6,7,10,12,15,9};

void init_keys() {
  for (int i = 0; i < 6; i++) {
    pinMode(pins_rows[i], OUTPUT);
    digitalWrite(pins_rows[i], LOW);
  }
  for (int i = 0; i < 9; i++) {
    pinMode(pins_cols[i], OUTPUT);
    digitalWrite(pins_cols[i], HIGH);
  }
}

// read_keys - Implements switch matrix
void read_keys() {
  int k = 0;
  
  // Read bottom C
  digitalWrite(pins_cols[0], LOW);
  pinMode(pins_rows[5], INPUT_PULLUP);
  delayMicroseconds(10);
  if (digitalRead(pins_rows[5])) {
    keystate[k] = 0;
  }
  else {
    keystate[k] = 1;
  }
  pinMode(pins_rows[5], OUTPUT);
  digitalWrite(pins_rows[5], LOW);
  k++;
  digitalWrite(pins_cols[0], HIGH);
  
  // Read remaining keys
  for (int i = 1; i < 11; i++) {
    digitalWrite(pins_cols[i], LOW);
    for (int j = 0; j < 6; j++) {
      pinMode(pins_rows[j], INPUT_PULLUP);
      delayMicroseconds(10);
      if (digitalRead(pins_rows[j])) {
        keystate[k] = 0;
      }
      else {
        keystate[k] = 1;
      }
      pinMode(pins_rows[j], OUTPUT);
      digitalWrite(pins_rows[j], LOW);
      k++;
      delayMicroseconds(500);
    }
    digitalWrite(pins_cols[i], HIGH);
  }
}


void setup() {                
  AudioMemory(20);
 // setup pin 13 LED for when keys pressed
  pinMode(13, OUTPUT);
  mixer3.gain(0, 0.5);
  mixer3.gain(1, 0.5);
  mixer4.gain(0, 0.5);
  mixer4.gain(1, 0.5);
  delay(1000);

  // Initialise all pins ready for cycling through reading
  init_keys();
}

void loop() {

/*
   // read keys
  read_keys();
  
  // Output midi messages
  int played_note = 0;
  for (int i = 0; i < 61; i++) {
    if (keystate[i] == 1) {
      digitalWrite(13, HIGH);
      played_note = 1;
      if (keystate_prev[i] == 0) { // note on
        usbMIDI.sendNoteOn(i+60, 99, 1);  // 60 = C4
      }
    }
    else if (keystate_prev[i] == 1) { // note off
      usbMIDI.sendNoteOff(i+60, 0, 1);  // 60 = C4
    }
  }

  // Update previous states
  for (int i = 0; i < 61; i++) {
    keystate_prev[i] = keystate[i];
  }

  if (played_note == 0) { // light up keyboard
    digitalWrite(13, LOW);
  }
*/
  
  // read the PC's volume setting
  float vol = usb1.volume();

  // scale to a nice range (not too loud)
  // and adjust the audio shield output volume
  if (vol > 0) {
    // scale 0 = 1.0 range to:
    //  0.3 = almost silent
    //  0.8 = really loud
    vol = 0.3 + vol * 0.5;
  }

  delay(100);

  digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(100);               // wait for a second
  digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW
  delay(10000);               // wait for a second

   // uncomment this code to allow Knob A3 to pan between songs
  /*
  int knob = analogRead(A3);  // knob = 0 to 1023
  float gain1 = (float)knob / 1023.0;
  float gain2 = 1.0 - gain1;
  mixer1.gain(0, gain1);
  mixer1.gain(1, gain2);
  mixer2.gain(0, gain1);
  mixer2.gain(1, gain2);
  */
}

This is the error that stumps me on how to deal with it:

Code: 
Arduino: 1.8.8 (Windows 10), TD: 1.46-beta1, Board: "Teensy 4-Beta1, Serial + MIDI + Audio, Faster, US English"

In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio\input_adc.cpp:29:0:


C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio\utility/pdb.h:30:21: fatal error: kinetis.h: No such file or directory

 
compilation terminated.

 
Error compiling for board Teensy 4-Beta1.


Paul, since that header file is part of the Audio Library, what's the best way to handle this? I'm currently thinking using a #define Teensy4 if compiling for the newer Teensy model and an #ifdef / #else to select the proper #include header. Is that the correct approach?
 
daywalker03 said:
what's the best way to handle this?
Click to expand...

Depends on what you mean by "best".

The easiest answer is to wait a few weeks until the Audio library is ported. It's on my list...

The hardest answer is to dive into the libraries and hardware and try to port it yourself. But since we don't have a PDB timer in the new chip, converting that over to the special ADC trigger stuff in the new hardware is far from a simple & easy task.
 
PaulStoffregen said:
Depends on what you mean by "best".

The easiest answer is to wait a few weeks until the Audio library is ported. It's on my list...

The hardest answer is to dive into the libraries and hardware and try to port it yourself. But since we don't have a PDB timer in the new chip, converting that over to the special ADC trigger stuff in the new hardware is far from a simple & easy task.
Click to expand...

I'll likely wait for the library port. It's not like I need the code to work right now, since I don't yet have a Teensy4.
 
Got T4 Beta Unit #2. Powered up blinking. Uploaded blink with T_3.2 RX Pin#0 watching pin #17 at 115200 - interesting spew looks good.

More than a few uploads - no issues!

Stock TD 1.46B1 except :: My HACK to the mem segment and One prior change to boards.txt build.flags added : -fno-threadsafe-statics

Modified Blink to show ARM_DWT_CYCCNT cycle counter between loops, I thought it would already be running from call to configure_systick() - but I found I had to start it again in sketch setup() ????

Pull Request Done

Just poking in T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\startup.c
Executing usb_pll_start(); stops the Cycle Counter, so it needs to be restarted after that ??? I added this and it is working - so the counter needs a restart:
Code: 
	usb_pll_start();
  ARM_DEMCR |= ARM_DEMCR_TRCENA;
  ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter

All working well with sketch below. It shows use of 'F_CPU_ACTUAL'. With above edit to startup.c restarting the Cycle Counter can stay commented out.

Works to compile FASTER - won't run FASTER+LTO - and both show a few warnings.

Added prints out Serial after the Serial4 and both are working. Adding Serial prints pops out some 'status' on debug.

Code: 
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  //ARM_DEMCR |= ARM_DEMCR_TRCENA;
  //ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter
  while ( !Serial && millis() < 4000 ) ;
  Serial4.print( "   F_CPU_ACTUAL=" );
  Serial4.println( F_CPU_ACTUAL );
}

void loop() {
  static uint32_t oCCnt = ARM_DWT_CYCCNT;
  static uint32_t oMicros = micros();
  uint32_t nCCnt = ARM_DWT_CYCCNT;
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
  Serial4.print( (nCCnt - oCCnt) / (F_CPU_ACTUAL / 1000000) );
  Serial4.print( "   Micros=" );
  Serial4.println( micros() - oMicros );
  Serial.print( (nCCnt - oCCnt) / (F_CPU_ACTUAL / 1000000) );
  Serial.print( "   Micros=" );
  Serial.println( micros() - oMicros );
  oCCnt = nCCnt;
  oMicros = micros();
}
 
Last edited:
I've uploaded new software on msg #2 with fixes for the missing syscall functions and memory allocation stuff.

Please do not use the hack from msg #66. Yes, I know it gets the code to compile. But this can cause anything using malloc() to conflict with global & static variables. The new installers have a (hopefully) proper fix.

If you want to try different clock speeds, the simplest way is to edit this line in startup.c in the core library.

Code: 
        set_arm_clock(600000000);

For anyone wanting to run a quick, not-so-official coremark benchmark, here's the code I've been using. It uses the debug printing to Serial4 for the output.
 

Attachments

  • teensy4_coremark.zip
    23.3 KB · Views: 159
Got my T4 today and ran the coremark sketch which duplicated the results tonton81 had. Also ran a CBA sketch which had no issues. Working on the temp monitor program most of the day but am having a issue I have to work through. Ran bolderflight's UBLOX sketch to read a GPS but didn't test since there are a couple of things to do for hardwareserial, i.e., flush, available, end etc. Did test __IMRT1050__ define with no issues. Still couldn't get Eigentest sketch to compile, tried lspec = nosys.specs which worked once before as a workaround and nano.specs but both returned a not found message.

@defragster-tried your sketch above-didn't seem to work for me. Compiled and loaded fine but no blinking and no micro prints just status=10080 messages. I put the
Code: 
  ARM_DEMCR |= ARM_DEMCR_TRCENA;
  ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter
between usb_pll_start(); and set_arm_clock(600000000).

EDIT: JUST LOADED Beta2 of the Teensyduino and Eigen now runs with any errors or warnings.

Coremark also compiles with out any issue - no sbrk errors. Also looks like you may not need -fno-threadsafe-statics as well. The three sketchs I ran - coremark, CBA and Eigen all ran no issues. Tony you may want to check yours.
 
Last edited:
Installed TD 1.46b2 - above blink won't compile?:
Blink:7: error: 'F_CPU_ACTUAL' was not declared in this scope
Serial4.println( F_CPU_ACTUAL );
Click to expand...

<EDIT> opps - Teensy 3.2 was opened in IDE not T4

Mike: Put this in setup - it seems Serial.print too soon isn't good:
Code: 
  while ( !Serial && millis() < 4000 ) ;

<edit> Running now with the setup lines uncommented to start the CycCnt
 
Decided this was a good time to play with set_arm_clock and coremarks. Here are some results:
Code: 
Clock (Mhz)     Coremarkish
528            2022
600            2298
732            2805
768            2942
798            ERROR! Must execute for at least 10 secs for a valid result! (ran 9.8 secs), 3034 on exit
 
Hi Tim.
Reloaded your sketch and its working now. Looks like it was probably my error - forgot to change some serial's to serial4's. After that it worked with one caveat. This is what I am getting as output:
Code: 
   F_CPU_ACTUAL=600000000
after setup
0   Micros=2000780
0   Micros=2002510
2003291   Micros=2001300
2003291   Micros=2003550
2004331   Micros=2001300
2004331   Micros=2003560
2004331   Micros=2001300
2004331   Micros=2003560
2004339   Micros=2001300
2004339   Micros=2003560
2004340   Micros=2001300
2004340   Micros=2003560
2004339   Micros=2001300
2004339   Micros=2003560
2004340   Micros=2001300
2004340   Micros=2003560
2004339   Micros=2001300
2004339   Micros=2003560
2004340   Micros=2001300
2004340   Micros=2003560
That cycle of 4339 and 4340 just keeps repeating. Is that what suppose to happen. Think it is just want to be sure.
 
After 1.46b2 Install to get CycCnt blink to work - either init in setup() or it would turn on LED and then stop before turning it off.

Applying this patch [pull request ] makes it work right again without the setup() equivalent:
Code: 
T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\startup.c:
   72  	configure_systick();
   73: 	usb_pll_start();
   74    ARM_DEMCR |= ARM_DEMCR_TRCENA;
   75    ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter
{ Pull request has moved above to before return in usb_pll_start() in case it ever gets called again }

Mike: With the above patch this is working - as long as the while(!Serial) code is in place - other wise it 'stalls' with LED on::
Code: 
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  //ARM_DEMCR |= ARM_DEMCR_TRCENA;
  //ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter
  while ( !Serial && millis() < 4000 ) ;
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  Serial4.print( "   F_CPU_ACTUAL=" );
  Serial4.println( F_CPU_ACTUAL );
  Serial.print( "   F_CPU_ACTUAL=" );
  Serial.println( F_CPU_ACTUAL );
  Serial.print( "   micros=" );
  Serial.println( micros() );
}

void loop() {
  static uint32_t oCCnt = ARM_DWT_CYCCNT;
  static uint32_t oMicros = micros();
  uint32_t nCCnt = ARM_DWT_CYCCNT;
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
  Serial4.print( (nCCnt - oCCnt) / (F_CPU_ACTUAL / 1000000) );
  Serial4.print( "   Micros=" );
  Serial4.println( micros() - oMicros );
  Serial.print( (nCCnt - oCCnt) / (F_CPU_ACTUAL / 1000000) );
  Serial.print( "   Micros=" );
  Serial.println( micros() - oMicros );
  oCCnt = nCCnt;
  oMicros = micros();
}

<edit :: crosspost>
My output looks like this - it is counting 2 seconds of delay(1000) per loop - so it should cycle around 2 seconds (CycCnt based on left and micros on right) with some variability in loop timing/measure:
T:\tCode\T4\Blink\Blink.ino Dec 29 2018 21:07:23
F_CPU_ACTUAL=600000000
micros=4005490
0 Micros=2001570
2004876 Micros=2002100
2005397 Micros=2002100
2005392 Micros=2002110
2005392 Micros=2002100
2005398 Micros=2002110
2005387 Micros=2002100
2003755 Micros=2002110
2005383 Micros=2002100
2005385 Micros=2002110
2005407 Micros=2002100
2005406 Micros=2002090
Click to expand...
 
Last edited:
Thanks Tim. Reran it and checked both Serial and Serial4 and looks like very similar numbers. heres just a snippet:
Code: 
2005405   Micros=2002100
2005396   Micros=2002110
2005393   Micros=2002110
2005391   Micros=2002090
2005398   Micros=2002090
2005387   Micros=2002110
2005395   Micros=2002110
 
RE: post #92:: Any reason that F_CPU_ACTUAL should not exist and return F_CPU_ACTUAL==F_CPU on non T4 boards?

This should just work without care if it will work for T4::
Serial.println( F_CPU_ACTUAL );

This is a bit awkward moving a simple sketch across Teensy Boards:
Code: 
#ifndef __IMXRT1052__
#define F_CPU_ACTUAL F_CPU
#endif
 
Last edited:
Last edited:
hm... I don't like F_CPU_ACTUAL
..looks like a #define but isn't.. why not a function?...
or #define F_CPU_ACTUAL getCpuFreq()
:) ..or whatever name the function will have.
 
Frank B said:
why not a function?....
Click to expand...

Because like so much of the core lib code, it was done, and redone, and changed again, all in haste to get this beta test started sooner. I had to make many trade-offs & compromise decisions - how much to do before opening the beta up. As you can see, I put most of that work into the hardware and bootloader... not so much into libraries. In this particular case, I had originally make for F_CPU to be a variable. But I'm not perfect at planning everything from the beginning. I neglected to think of the many places where #if checks are done assuming F_CPU is a preprocessor symbol.... so I quickly changed the name, but didn't do anything more with it (yet) because I wanted to get the beta test started.

Right now, my main focus is the huge list (msg #6) of stuff that doesn't work or hasn't even been tested.

Public APIs are also very important. I do want to get to a fairly stable API in a few weeks, hopefully before we have the 1062 chips. So this is an important conversation. Just please understand at this moment I'm more focused on missing features. Over the next few weeks, I will want to talk more about this... and then I won't... there will be a fairly short period of time, maybe a few weeks, where we really focus on finalizing the APIs for new stuff like clock scaling.
 
Status
Not open for further replies.
Back
Top