Teensy 4.0 First Beta Test

Status
Not open for further replies.
Was this noted <as such>? <EDIT> - caused by DEBUG write(13) in USB code.

Setting BUILTIN_LED (13) to output allows HIGH or LOW Write. With digitalWrite(LED_BUILTIN, HIGH)

>> Doing a digitalRead(LED_BUILTIN ) <on the output> turns off a HIGH LED and always returns LOW. In a paired HIGH<>LOW blink with delay(1000) - reading after write turns the HIGH off in a flash.

A T_3.2 can read a HIGH output as HIGH without disturbing it.


>> Also is seems the End ON/OFF pin control is not yet implemented?

Can confirm Serial.read() as noted in Issue list post does not work.
 
Last edited:
My T4 arrived. The red LED is very nice!

Did a very first short test: digitalRead() reads PIN 0 correctly.
@defragster: Hm..I can't confirm that a digitalRead(13 ) turn off the LED.

Edit: digitalRead(0) works even without a pinMode(0, INPUT) before. Is this correct behaviour?

Edit: Tested Pins 0..23 as inputs - work (without pinMode(x, INPUT) before, too)
 
Last edited:
My T4 arrived. The red LED is very nice!

Did a very first short test: digitalRead() reads PIN 0 correctly.
@defragster: Hm..I can't confirm that a digitalRead(13 ) turn off the LED.

Edit: digitalRead(0) works even without a pinMode(0, INPUT) before. Is this correct behaviour?

Do the following:
Code:
      pinMode(LED_BUILTIN, OUTPUT);
      digitalWrite(LED_BUILTIN, HIGH);
      digitalRead(LED_BUILTIN )
      delay( 1000 );

On T_3.2 that works to read the value of LED_BUILTIN as noted without change or error, maybe that goes along with the loss of bitbanding and the hardware is now the schroedinger cat model.

Without pinmode a write won't work on T_3.2 - you'd have to test a read.
 
@defragster:
Code:
void setup() {
  // put your setup code here, to run once:
      pinMode(LED_BUILTIN, OUTPUT);
      digitalWrite(LED_BUILTIN, HIGH);
      digitalRead(LED_BUILTIN );
      delay( 1000 );
}

void loop() {
  // put your main code here, to run repeatedly:
}
- LED stays on.
I've attached my hex file (rename it back to .hex) - do we have different versions?
 

Attachments

  • T4_Pin13.ino.TEENSY40.hex.txt
    30.5 KB · Views: 147
I only typed that in the browser as a subset of the test I did ... it doesn't result in a HEX file :)

Put your code in sketch and it works - with no USB printing! Add in USB printing as follows and the LED fails to properly cycle.

Paul - Please try this if Frank can confirm it.
<edit> : It seems this would be from :: int usb_serial_write(const void *buffer, uint32_t size) the LED goes HIGH then LOW in the core code during the 'status = ' prints
<edit> : confirmed removing the writes(13) and the LED blinks normally.

<EDIT>: Another FUNNY THING : maybe expected with the state of USB? > Closing SerMon while this is running and the LED turns ON, restart SerMon and the LED goes OFF. Or with SerMon closed, enable and disable Serial in TyCommander and the same thing happens - so it isn't unique to SerMon, or changed by TyComm. This may explain why the LED pops on during UPLOAD process - before red light blinky in this case as the USB stack changes.

This is what I was testing {in a smaller sketch} and now I see not even a FLASH of the LED when using Serial.print! If changed to Serial4.print the LED blinks normally!
Code:
#define SOME_SERIAL Serial
//#define SOME_SERIAL Serial4
void setup() {
  // put your setup code here, to run once:
  pinMode(LED_BUILTIN, OUTPUT);
  while ( !Serial && millis() < 600 ) {
    if ( 0 == ARM_DWT_CYCCNT &&  0 == ARM_DWT_CYCCNT ) {
      digitalWrite(LED_BUILTIN, HIGH);
      SOME_SERIAL.println( "   ARM_DEMCR_TRCENA done!" );
      ARM_DEMCR |= ARM_DEMCR_TRCENA;
      // ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter << THIS LINE NOT NEEDED
    }
  }
  SOME_SERIAL.println("\n" __FILE__ " " __DATE__ " " __TIME__);
}

void loop() {
  // put your main code here, to run repeatedly:
  digitalWrite(LED_BUILTIN, HIGH);
  if ( digitalRead(LED_BUILTIN ) ) SOME_SERIAL.print("1+");
  else SOME_SERIAL.print("1-");
  delay( 1000 );
  digitalWrite(LED_BUILTIN, LOW);
  if ( !digitalRead(LED_BUILTIN ) ) SOME_SERIAL.print("0+");
  else SOME_SERIAL.print("0-");
  delay( 1000 );
}


Does anyone else ( on windows ) get the feeling the compile is slow to start? In fact doing this test the IDE HUNG until I hit the T4 Button - possible from doing this test - with above code it is now better. I have 6 sketches open and the machine not rebooted for almost 7 days including many dozens of T4 compiles.

BTW: I moved my installed files to Windows SurfaceBook and it and the T4 worked there as it should.

Paul: You said the '15 second Restore' Image on FLASH has USB issues with Windows. Is there a Source Sketch you can provide that repro's the problem? Or is it unique to flash loading?
 
Last edited:
Yes, Serial.print crashes (windows 10, if this is important)). Minimal Sketch:
Code:
void setup() {
 delay(2000);
 Serial4.println("Hello");
 Serial.println("World");
 Serial4.println("World2");
}

void loop() {}
after "Hello" in Serial4 nothing happens.
 
Known behavior AFAIK relates to the outstanding Pull Request I have - and or another issue also in the Post #6 bug list I noted. Add this BOLD code to setup() - Please confirm::

Yes, Serial.print crashes (windows 10, if this is important)). Minimal Sketch:
Code:
void setup() {

[B]  pinMode(LED_BUILTIN, OUTPUT);
  while ( !Serial && millis() < 600 ) {
    if ( 0 == ARM_DWT_CYCCNT &&  0 == ARM_DWT_CYCCNT ) {
      digitalWrite(LED_BUILTIN, HIGH);
      Serial4.println( "   ARM_DEMCR_TRCENA done!" );
      ARM_DEMCR |= ARM_DEMCR_TRCENA;
    }
  }
[/B]
 Serial4.println("Hello");
 Serial.println("World");
 Serial4.println("World2");
}

void loop() {}
after "Hello" in Serial4 nothing happens.

<edit> from p#6:
cycle counter stops, causes other wait code to lock up, #117
Serial.print too soon crashes

You had a delay(2000) - so it should not be the too soon problem.

Also note that !Serial never goes true - it always exits based on the time test it seems - times much less than 600 on Windows and the USB stutters for some time - too low and it fails to start ever.
 
Your modified code prints all correctly for me, USB-Serial, too. But LED is off.

I suppose with LED ON and this printed to debug? : 'ARM_DEMCR_TRCENA done!'

So that is a shorter delay - but somewhere with cycle counter inactive the new delayMicroseconds() was used and it needs counted cycles to exit.

<edit>: will look for result from post #158 ...
 
yes, prints 'ARM_DEMCR_TRCENA done!', led is a short time on.
I guess it gets turned off somewhere in the core-code. Paul mentioned he uses it.

Edit: Yes, Serial.print() turns the LED off.
 
I tested Wire with the MB85RC256 chip. Seems to work fine. On this test, I used 1K pullup resistors. Here's the waveforms I see.

file.png

The code I posted yesterday for the 24LC02B chip requires a slight edit, since this larger chip uses 16 bit address for 32 kbytes of FRAM. The 24LC02B has only 256 bytes, so it uses 1 byte for the internal address field.

Here's the modified code I used with MB85RC256.

Code:
#include <Wire.h>
#include "debug/printf.h"
 
int led = 13;

void doread(int address) {
  printf("doread\n");
  int retry=0;
  while (1) {
    Wire.beginTransmission(0x50); // EEPROM
    Wire.write((address >> 8) & 255);
    Wire.write(address & 255);
    int r = Wire.endTransmission(false);
    if (r == 0) break;
    printf("error, r=%d\n", r);
    if (++retry > 10) return; // fail :(
  }
  printf("req\n");
  Wire.requestFrom(0x50, 4);
  printf("Wire read: %x,", Wire.read());
  printf(" %x,", Wire.read());
  printf(" %x,", Wire.read());
  printf(" %x\n", Wire.read());
}

void dowrite(int address) {
  printf("dowrite\n");
  Wire.beginTransmission(0x50); // EEPROM
  Wire.write((address >> 8) & 255);
  Wire.write(address & 255);
  Wire.write(0x69);
  Wire.write(0x1E);
  Wire.write(0x34);
  Wire.write(0xA5);
  Wire.endTransmission();
}

void setup() {
  pinMode(led, OUTPUT);
  digitalWrite(led, LOW);

  Wire.begin();
  doread(0);
  dowrite(0);
  doread(0);
}

void loop() {
  elapsedMillis t;
  digitalWrite(led, HIGH);
  t = 0;
  while (t < 2000) ; // wait
  //delay(2000);
  digitalWrite(led, LOW);
  delay(2000);
}
 
yes, prints 'ARM_DEMCR_TRCENA done!', led is a short time on.
I guess it gets turned off somewhere in the core-code. Paul mentioned he uses it.

Edit: Yes, Serial.print() turns the LED off.

Indeed in int usb_serial_write(const void *buffer, uint32_t size) the LED goes HIGH then LOW in the core code during the 'status = ' prints
 
Code:
    configure_systick();
    usb_pll_start();
[COLOR=#ff0000][B]for (int i=0; i<50000; i++) asm volatile ("nop");
 ARM_DEMCR |= ARM_DEMCR_TRCENA;[/B][/COLOR]
    set_arm_clock(600000000);
Without the loop, it does not work - looks like we need to wait for something?
 
Originally Posted by mjs513
... running blink with Fastest and it hung.
Committed a fix for this.

Put the fix in startup.c and reran blink with fastest. Yep it fixed the problem.
 
I tested Wire with the MB85RC256 chip. Seems to work fine. On this test, I used 1K pullup resistors. Here's the waveforms I see.
Thanks Paul. Before crashing (my sleep) I ran the adafruit lib sketch on using 4.7k with the MB85RC256. Looking at output it looked like it was working writing and reading to the registers. I didn't scope though. Going to test it with 1k and no pullups as well. Then back to the bme280 sensor.

Even with the 4.7k pullups the i2cscanner still did not work - have to check to see what error code is returning. Right now it the scanner tests if 0 is returned.
 
Code:
    configure_systick();
    usb_pll_start();
[COLOR=#ff0000][B]for (int i=0; i<50000; i++) asm volatile ("nop");
 ARM_DEMCR |= ARM_DEMCR_TRCENA;[/B][/COLOR]
    set_arm_clock(600000000);
Without the loop, it does not work - looks like we need to wait for something?

with this code following program
Code:
void setup() {
  // put your setup code here, to run once:
      pinMode(LED_BUILTIN, OUTPUT);
      digitalWrite(LED_BUILTIN, LOW);
      delay(1000);
      digitalWrite(LED_BUILTIN, HIGH);
}

void loop() {
  // put your main code here, to run repeatedly:
  delay(1000);
      digitalWrite(LED_BUILTIN, LOW);
  delay(500);
      digitalWrite(LED_BUILTIN, HIGH);
  Serial.println("loop");
print out "loop" but flashes are very short, as if Serial.println() switches off the led

inserting
delay(100);
before Serial.println(), ensures Led is 100 ms on

this is consistent with led is stationary when serial_monitor offline
 
Yes, Serial.print() turns the LED off - See Posts #163/#165 - It's debug code from Paul.
Paul is working on the ARM_DEMCR issue (Post #168)
 
@Paul: shiftIn/shiftOut : I'd just use a delayMicroseconds(1)
And I remember there were issues with T3.6 because it was too fast - I'd add a delayMicroseconds(1) there, too.
- What do you think?
 
I have a fix for the cycle counter issue. Testing it now. Should have a new installer ready in about an hour.

Is anyone using the Linux ARM version? I'd like to drop it from this beta testing, because messing with builds on the Raspberry Pi really slows me down.
 
Arm Linux - Not me yet... Currently MAC and Windows.

Still debugging some stuff, with hangs and crashes. Have copied down some of your updated sources that appears to help a little...

But still issue with crash of calling through virtual function...

Again test case:
Code:
class TestSerial : public Stream {
  public:
    TestSerial() {state_ = 0;};
    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;
    size_t nonVirtualfunc(uint8_t c);
    uint8_t state_;
};

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(3, HIGH);
  state_ = state_? 0 : 1;
 digitalWrite(13, state_);
 digitalWrite(3, LOW);
 return 0;  
}

size_t TestSerial::nonVirtualfunc(uint8_t c) {
  digitalWrite(3, HIGH);
  state_ = state_? 0 : 1;
 digitalWrite(13, state_);
 delay(100);
 digitalWrite(3, LOW);
 return 0;  
}

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

TestSerial ts;

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

  for (uint8_t i=0; i< 5; i++) {
    digitalWrite(13, HIGH);
    delay(250);
    digitalWrite(13, LOW);
    delay(250);
  }
  
}
uint8_t buf[]={0,1};
void loop() {
  digitalWrite(2, HIGH);
  //ts.write((uint8_t)0x00);  // see if we call through the virtual function
  ts.write(buf, 1);
  //ts.nonVirtualfunc(0);
  digitalWrite(2, LOW);
  delay(500);
}
If I call ts.write(0x00);
The code runs and led blinks at the right rate,
But if I call ts.write(buf, 1), like currently uncommented, it crashes...
 
Status
Not open for further replies.
Back
Top