Teensy 4.0 First Beta Test

defragster · Dec 30, 2018

I'm okay with F_CPU_ACTUAL evolving as needed. #defines versus things the linker may or may not find is painful when trying to compare and contrast T4 and another Teensy on same sketch.

> If anything the T4 needs added will NOP out in the end, getting the Teensy3 tree to compile is why I mentioned it. Like :: set_arm_clock(), F_CPU_ACTUAL. If not then we can #ifdef that in sketches.

Given my play time with CycleCounter I tried that and found it stalls as noted with PULL request, which stops delayMicroseconds() running as noted. I'm not sure if that suggests that usb_pll_start() may affect any other prior work?

Also noted that any USB print before Serial==TRUE halts the Teensy - you made note it was iffy - not sure if that is new info - until then "while ( !Serial && millis() < 4000 ) ;" works to get output as noted.

FYI - using CycleCounter at 600 MHz lasts just over 7.15 seconds before wrapping so I'm not sure if that is a caveat desired for using in elapsedMicros? Same for delayMicroseconds() is probably fine?

Also FYI expected/future note my test sketches seem to be okay at default optimize FASTER, and a change there also seems fail to start after upload in some combination.

tonton81 · Dec 30, 2018

Confirmed, -fno-threadsafe-statics is not needed since Paul has fixed the acquire/release guards for local statics

These still work as well:

AVR non-standard functions: ultoa, ltoa, dtostrf

Code:

    float f_val = 123.67942;
    char outstr[15];
    dtostrf(f_val, 7, 5, outstr);
    Serial4.println(outstr);

    long  a = 10000000;
    char buffer[50];
    ltoa(a, buffer, 16); // here 2 means binary
    Serial4.printf("value = %s\n", buffer);


    char output[40];
    uint32_t tmp = 0x12345678;
    ultoa(tmp, output, 16);
    Serial4.println(output);

T3.2 output:

Code:

123.67942
value = 989680
12345678

EDIT: on post #72: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=193946&viewfull=1#post193946
I commented out the temp fix for Eigen sketch that made it compile on Beta1 teensyduino

Code:

//#include <stdlib.h> // for malloc and free
//void * operator new(size_t size) {
//  return malloc(size);
//}
//void operator delete(void* ptr) {
//  if (ptr) free(ptr);
//}

Eigen now compiles and runs fine on beta2 without it.

PaulStoffregen · Dec 30, 2018

I got the Wire library working. Code is on github, if anyone wants it now. Currently only supports master mode, and only 100 kHz clock, and lacks forced 9-clock recovery from a stuck bus. Will do that stuff later.

Going to work on SPI next. Will make another installer when both Wire & SPI are working, hopefully later today...

mjs513 · Dec 30, 2018

Ok. Just tried running coremark at OPTIMIZE - FASTEST, bricked it: and lost device. Did the 13 second hold and reloaded blink at faster - worked and USB recovered and recognized the T4 again. So just a warning. Anyway tested the 13 second warning and reflash

tonton81 · Dec 30, 2018

you tried a brief program pulse first before reflash or was it really bricked to have to do 13 sec hold?

mjs513 · Dec 30, 2018

Hey Tony - had to do the 13 second hold.

Frank B · Dec 30, 2018

..I hope my T4 arrives tomorrow..

or.. is there anything meaningful I can do without it?

PaulStoffregen · Dec 30, 2018

mjs513 said:
Ok. Just tried running coremark at OPTIMIZE - FASTEST, bricked it: and lost device.

I tried here. Indeed it makes the board unresponsive to auto-reboot. But it reprograms fine when I press the button (just a quick tap, not 13 sec).

Which operating system are you using? It is Arduino 1.8.8? Do you have 1.46-beta1 or 1.46-beta2?

mjs513 · Dec 30, 2018

I tried here. Indeed it makes the board unresponsive to auto-reboot. But it reprograms fine when I press the button (just a quick tap, not 13 sec).

Hmm. Did the quick tap when it hung (I think to be honest don't remember) but no luck had to do the 13sec hold and then it would reprogram fine and got the usb back.

I was running IDE1.8.8 with 1.46-beta2 on a windows 10 x64 desktop.

EDIT: Just repeated running blink with Fastest and it hung. Recompiled blink at faster and just did a single tap to reload and it resolved the issued. So must have forgot to do single tap or do a recompile.

KurtE · Dec 30, 2018

Note I have started playing with some serial port stuff. Trying first to get outputs using ISR

mjs513 · Dec 30, 2018

Been working on the temp monitor code using a .h/.cpp from within the sketch to change register settings and reading them back. Also was testing reading the clock frequencies AHB and IPG in another sketch. Again reading the registers from within the sketch. While both compile, load and kind of run can't seem to change or read the register settings.

For the temp monitor sketch I am assuming the RTC clock is enabled and the PLL clock is enabled and settled by the time the sketch runs. But both sketches seem to exhibit the same problem. Is there a trick to changing register values and reading them? Don't know - never really worked at this level before. The funny thing is I can read the OCOTP.ana1 no problem.

Sketches are located on my GITHUB WIP page: https://github.com/mjs513/WIP.

manitou · Dec 30, 2018

strange you can't read registers. i don't have board yet, can you try running my sysinfo
https://github.com/manitou48/teensy4/blob/master/sysinfo.ino

i've run equivalent sketch on EVKB eval board -- but i've only checked that it compiles on Teensy 4

defragster · Dec 30, 2018

manitou said:
strange you can't read registers. i don't have board yet, can you try running my sysinfo
https://github.com/manitou48/teensy4/blob/master/sysinfo.ino

i've run equivalent sketch on EVKB eval board -- but i've only checked that it compiles on Teensy 4

Very Odd - I sent this all out Serial4 - had to go upload another before came back and this worked ...

396000000 10:07:34 Dec 30 2018
CCM_ANALOG_PLL_ARM 0x80002064
CCM_ANALOG_PLL_USB1 0x80003040
CCM_ANALOG_PLL_USB2 0x12000
CCM_ANALOG_PLL_SYS 0x80002001
CCM_ANALOG_PFD_480 0xF1A2318
CCM_ANALOG_PFD_528 0x18131818
CCM_CBCDR 0x180A8300
CCM_CBCMR 0x35AE8304
CCM_CCGR1 0xFCFFC000
CCM_CCGR2 0xC3FF033
CCM_CCGR3 0xF00FF300
CCM_CCGR4 0xFFFFFF
CCM_CCGR5 0xF0033C33
CCM_CCGR6 0xFCFF3FC3
CCM_CSCMR1 0x66930040
CCM_CSCDR1 0x6490B40
SCB_CPACR 0xF00000
SYST_CSR 0x10003
SYST_RVR 0x63
after setup

And Yes - it runs to loop doing a nice flash.

<edit>: Working out USB Serial now -

mjs513 · Dec 30, 2018

Ok. Just an update - clock registers seem to working fine now - have a different issue with that one. TempMonitor still an issue though. Will work that next - maybe I have the register mapping wrong. Have to check.

KurtE · Dec 30, 2018

Trying to debug my Serial output code now...

The board is faulting and getting into the fast led flash...

I have sprinkled digitalWrite statements to see where...

Code:

uint16_t loop_counter = 0;
void loop() {
  delay(250);
  digitalWrite(2, HIGH);
  Serial1.print("Loop ");
  Serial.println(++loop_counter, DEC);
  digitalWrite(2, LOW);
}

Pin 2 goes high...

This calls through to:

Code:

size_t Print::write(const uint8_t *buffer, size_t size)
{
	digitalWrite(4, HIGH);
	size_t count = 0;
	while (size--) count += write(*buffer++);
	digitalWrite(4, LOW);
	return count;
}

Again Pin 4 goes high...
Which should go through virtual write function:

Code:

size_t HardwareSerial::write(uint8_t c)
{
	uint32_t head, n;
	digitalWrite(3, HIGH);
//	if (transmit_pin_) transmit_assert();
	head = tx_buffer_head_;
	if (++head >= tx_buffer_total_size_) head = 0;

And Pin 3 does NOT go high...

Wonder if virtual functions are working here? Wonder if I need to do a more simple test...

Edit should mention, the test program does initialize these IO pins.

Code:

void setup() {
  pinMode(13, OUTPUT);
  pinMode(2, OUTPUT);
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  digitalWrite(2, LOW);
  digitalWrite(3, LOW);
  digitalWrite(4, LOW);
  for (uint8_t i = 0; i < 5; i++) {
    digitalWrite(13, HIGH);
    delay(250);
    digitalWrite(13, LOW);
    delay(250);
  }
  digitalWrite(2, HIGH);
  Serial1.begin(115200);
  digitalWrite(2, LOW);
}

uint16_t loop_counter = 0;
void loop() {
  delay(250);
  digitalWrite(2, HIGH);
  Serial1.print("Loop ");
  Serial.println(++loop_counter, DEC);
  digitalWrite(2, LOW);
}

Current Hardware serial changes up at: https://github.com/KurtE/cores/tree/Teensy4_HardwareSerial
Minus the digitalWrites

PaulStoffregen · Dec 30, 2018

EDIT: 1.46-beta3 now available on msg #2.

I put a very minimal SPI library in, and it's able to read the ID bytes from a serial flash chip with this code. Much work still needed to implement all the usual SPI library features!

Code:

#include <SPI.h>
#include "debug/printf.h"

void setup() {
  printf("begin\n");
  digitalWrite(9, HIGH);
  pinMode(9, OUTPUT);
  digitalWrite(9, HIGH);
  SPI.begin();
  SPI.beginTransaction(SPISettings(8000000, 0, 0));
  digitalWriteFast(9, LOW);
  SPI.transfer(0x9F);
  uint8_t b1 = SPI.transfer(0);
  uint8_t b2 = SPI.transfer(0);
  uint8_t b3 = SPI.transfer(0);
  digitalWriteFast(9, HIGH);
  SPI.endTransaction();
  printf("%02X,%02X,%02X\n", b1, b2, b3);
}

void loop() {
}

Going to package up beta3 so everyone has (minimal) Wire & SPI... then take a break for the rest of the day (& get some sleep...), maybe late tonight look into the USB serial problems.

defragster · Dec 30, 2018

TD 1.46b3 installs and works.
Paul to look into why CycleCounter disabled.

Until then putting this early in setup() will keep delayMicroseconds() from getting stuck by enabling the CycleCounter without core file edit - it also seems to be the minimum time ( on Windows ) for USB to activate ONLINE without retry/wait status prints:

Code:

  while ( !Serial && millis() < 600 ) {
    if ( 0 == ARM_DWT_CYCCNT &&  0 == ARM_DWT_CYCCNT ) {
      pinMode(LED_BUILTIN, OUTPUT);
      digitalWrite(LED_BUILTIN, HIGH);
      Serial4.println( "   ARM_DEMCR_TRCENA done!" );
      ARM_DEMCR |= ARM_DEMCR_TRCENA;
      ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter
    }
  }
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__); // Serial safely online now

I triggered my first isr FAULT break - running COREMARK with 50K iterations - works fine at 1K or 10K

RE MSG #6 :: I didn't test enough - but pushing the # iterations toward 10 seconds worth … 24K seemed to trigger this. Until then is says ERROR not enough for 10 secs. It may just be the math for that test.

<edit>: It is in calc of final results on no errors - run over 10 secs … HACK fix here Post #651 - doesn't get printable numbers, but stops faulty math

mjs513 · Dec 30, 2018

Hi Tim - been running my coremarks at 20k just for info.

By the way just looked in startup.c and your change is not there:

Code:

	usb_pll_start();      
ARM_DEMCR |= ARM_DEMCR_TRCENA;
ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter

For some reason not getting anything to print using Serial.println? Going back to do some more checking.
EDIT: Doing something wrong, my fault.

I put the code back into the startup.c and seems to working fine, your sketch

PaulStoffregen · Dec 30, 2018

Explained in github earlier... I want to spend some time looking into what's really going wrong with the cycle counter. Even if this fix always works, before I merge it I really want to try to understand *why* this strange behavior is happening. That's why it's not in beta3. Please be patient on this. I'll get to it soon... but getting minimally working Wire & SPI was a higher priority. So is working USB Serial printing....

defragster · Dec 30, 2018

Yes, I noted above it was to be looked at - just offered the work around.

Also that saves from USB halting T4 when used too early because delayMicroseconds() goes infinite while loop. So when in USB [or any code] and that delayMicroseconds() may be called - make sure cycle counter running.
Comments on github were updated with code showing the line that halts the cycle counter - and point source recovery - as best I can test.

Frank B · Dec 30, 2018

Tabsize

What's the tabsize for imrth.h? 8?
As long I'm waiting, I can add some missing definitions..

manitou · Dec 30, 2018

There are two GPT timers GPT1 and GPT2, imxrt.h only defines one, CCM_CCGR1_GPT (see pg 682 ref manual). GPT1 enabled on CCGR1 and GPT2 on CCGR0

NEVER MIND I see the CCM_CCGR0_GPT2_SERIAL, i guess i expected CCM_CCGR1_GPT to be CCM_CCGR1_GPT1

mjs513 · Dec 30, 2018

Just want to confirm that Serial1 is on pins 0/1 and SCL/SDA is 18/19 for testing.

Just as a side note - have a working sketch to get clock any and all clock frequencies - haven't tested them all but looks good. There's way too much junk in the .h and .cpp files to be anything but maybe a debugging tool.

KurtE · Dec 30, 2018

Looks like I confirmed there may be an issue with some virtual functions?

Here is a quick and dirty sketch, that simple subclass of Stream...

Code:

class TestSerial : public Stream {
  public:
    virtual int available(void);
    virtual int peek(void);
    virtual void flush(void);
    virtual size_t write(uint8_t c);
    virtual int read(void);
    using Print::write;
};

int TestSerial::available(void) {return 0;}
int TestSerial::peek(void){return 0;}
void TestSerial::flush(void) {return;}

size_t TestSerial::write(uint8_t c) {
 digitalWrite(13, !digitalRead(13));
 return 0;  
}

int TestSerial::read(void){return 0;}

TestSerial ts;

void setup() {
  // put your setup code here, to run once:
  pinMode(13, OUTPUT);
  
}

void loop() {
  ts.print(0);  // see if we call through the virtual function
  delay(500);
}

Simply has some of the same subclasses as the Hardware Serial and the only thing that the write method does is to update the led every half second.
Runs on Teensy 3.6 on the beta board the LED turns on and stays on... Doesn't go to the fault LED flashing like my hardware Serial test was.

Does anyone see anything I am missing here? Note: I am using default options for compile. Compiling for debug shows a dim LED. Compiling Fast shows debug messages...

tonton81 · Dec 30, 2018

Paul, I ran your SPI test above and added a while(1); at end of setup

Code:

void setup() {
  digitalWrite(9, HIGH);
  pinMode(9, OUTPUT);
  digitalWrite(9, HIGH);
  SPI.begin();
  SPI.beginTransaction(SPISettings(8000000, 0, 0));
  digitalWriteFast(9, LOW);
  SPI.transfer(0x9F);
  uint8_t b1 = SPI.transfer(0);
  uint8_t b2 = SPI.transfer(0);
  uint8_t b3 = SPI.transfer(0);
  digitalWriteFast(9, HIGH);
  SPI.endTransaction();
  printf("%02X,%02X,%02X\n", b1, b2, b3);
 [COLOR="#FF0000"]while(1);[/COLOR]

T3.2 output shows

Code:

and Teensy4 led goes into a led flashing spree

Also the program button needs to be hit at that point else the IDE can't continue next flash

Teensy 4.0 First Beta Test

Senior Member+

Well-known member

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member

Senior Member+

Senior Member+

Senior Member+

Well-known member