Teensy 4.0 First Beta Test

KurtE · Feb 17, 2019

Hi @defragster - With that joystick, hard to say what the mode button does? Maybe it changes the configuration of messages to something specific for some driver or????

As for Mouse - using the USBHOST_PRINT_DEBUG did not show additional information? I assume it showed all of the debug stuff, like Here is some output running with HP mouse...

Code:

Input, total bits=16
  usage = FF000040  sdata = 0
  usage = FF000041  sdata = 0
begin, usage=10000
       type= 6
       min=  -127
       max=  127
       reportcount=1
       usage count=1
Input, total bits=8
  usage = 10038  sdata = -2
begin, usage=10000
       type= 6
       min=  -32767
       max=  32767
       reportcount=2
       usage count=2
Input, total bits=32
  usage = 10030  sdata = 0
  usage = 10031  sdata = 0
,  mouseY = 0,  wheel = -2,  wheelH = 0
HID: 0 - 00 01 00 00 01 00 00 00 
begin, usage=10000
       type= 2
       min=  0
       max=  1
       reportcount=3
       usage count=255
Input, total bits=3
  usage = 90001  data = 0
  usage = 90002  data = 0
  usage = 90003  data = 0
begin, usage=10000
       type= 2
       min=  -127
       max=  127
       reportcount=2
       usage count=1
Input, total bits=16
  usage = FF000040  sdata = 1
  usage = FF000041  sdata = 0
begin, usage=10000
       type= 6
       min=  -127
       max=  127
       reportcount=1
       usage count=1
Input, total bits=8
  usage = 10038  sdata = 0
begin, usage=10000
       type= 6
       min=  -32767
       max=  32767
       reportcount=2
       usage count=2
Input, total bits=32
  usage = 10030  sdata = 1
  usage = 10031  sdata = 0
Mouse: buttons = 0,  mouseX = 1,  mouseY = 0,  wheel = 0,  wheelH = 0
HID: 0 - 00 04 00 00 04 00 00 00 
begin, usage=10000
       type= 2
       min=  0
       max=  1
       reportcount=3
       usage count=255
Input, total bits=3
  usage = 90001  data = 0
  usage = 90002  data = 0
  usage = 90003  data = 0
begin, usage=10000
       type= 2
       min=  -127
       max=  127
       reportcount=2
       usage count=1
Input, total bits=16
  usage = FF000040  sdata = 4
  usage = FF000041  sdata = 0
begin, usage=10000
       type= 6
       min=  -127
       max=  127
       reportcount=1
       usage count=1
Input, total bits=8
  usage = 10038  sdata = 0
begin, usage=10000
       type= 6
       min=  -32767
       max=  32767
       reportcount=2
       usage count=2
Input, total bits=32
  usage = 10030  sdata = 4
  usage = 10031  sdata = 0
Mouse: buttons = 0,  mouseX = 4,  mouseY = 0,  wheel = 0,  wheelH = 0

The Wheel data is sort of strange, it keeps a positive or negative value depending on how far/fast you spin wheel, then when you stop, it will reset back to zero. Also this mouse did not have a horizontal scrolling like some of the others I have. And on this one pressing the wheel down gives you button 3...

Wonder if I need to look/debug another one?

mjs513 · Feb 17, 2019

@defragster/@KurtE
Ok - posting back over here because this may be a T4 only issue. I incorporated Tim's debug code into the Bluetooth.cpp file where the #debug_bt statements are and some strange things. So take a step at a time.

1. With a setup that just specifies debug_tt;

Code:

void setup()
{
  Serial4.begin( 1843200 );
  debBegin_tt( &Serial4, LED_BUILTIN, 12);
  //debTraceShow_tt( -1, "", "", "" );
  //Serial4.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  //Serial4.println("\n********\n T4 connected Serial1 *******\n");
  //Serial4.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  //Serial4.println("\n********\n T4 connected Serial4 *******\n");

Serial.begin(115200);

  while (Serial && millis() < 5000) ; // wait for Arduino Serial Monitor
  //debTraceShow_tt( -2, "", "", "" );
  //Serial4.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  
  Serial.println("\n\nUSB Host Testing");
  Serial.println(sizeof(USBHub), DEC);
  myusb.begin();

The T4 hangs (at times it just keeps resetting itself) and gives me gibberish:

Code:

@@@fa` ! n B`e@A@ P@@ d%@  ra`ed$!dHdp DRe`dAD LOGb adaba `Ep1 
@@@fa` ! n B`e@A@ P@@ d%@  ra`ed$!dHdp DRe`dAD LOGb adaba `Ep1 
@@@fa` ! n B`e@A@ P@@ d%@  ra`ed$!dHdp DRe`dAD LOGb adaba `Ep1 
@@@fa` ! n B`e@A@ P@@ d%@  ra`ed$!dHdp DRe`dAD LOGb adaba `Ep1 
@@@fa` ! n B`e@A@ P@@ d%@  ra`ed$!dHdp DRe`dAD LOGb adaba `Ep1 
@@@fa` ! n B`e@A@ P@@ d%@  ra`ed$!dHdp DRe`dAD LOGb adaba `Ep1

Here is the whole log file from tycommander: View attachment TyCommander-5336850-Teensy-1.txt

2. Now, if I add in some extra lines to setup for debug purposes:

Code:

void setup()
{
  Serial4.begin( 1843200 );
  debBegin_tt( &Serial4, LED_BUILTIN, 12);
  debTraceShow_tt( -1, "", "", "" );
  Serial4.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  Serial4.println("\n********\n T4 connected Serial1 *******\n");
  Serial4.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  Serial4.println("\n********\n T4 connected Serial4 *******\n");

Serial.begin(115200);

  while (Serial && millis() < 5000) ; // wait for Arduino Serial Monitor
  debTraceShow_tt( -2, "", "", "" );
  Serial4.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  
  Serial.println("\n\nUSB Host Testing");
  Serial.println(sizeof(USBHub), DEC);
  myusb.begin();

There is no hanging of the T4 and verbose prints work without issue.

Now I am really confused on whats going on.

EDIT: Here is another strange data point. I just put the sketch back to the condition it was in when it was causing the fault with debug statements turned and now its not hanging again but I can't get it to connect properly. It connects and then disconnects.

EDIT2: ok lost the usb again by simply uncommenting a couple of serial.prints in joystick.cpp.

defragster · Feb 17, 2019

KurtE said:
Hi @defragster - With that joystick, hard to say what the mode button does? Maybe it changes the configuration of messages to something specific for some driver or????

As for Mouse - using the USBHOST_PRINT_DEBUG did not show additional information? I assume it showed all of the debug stuff, like Here is some output running with HP mouse...

//… The Wheel data is sort of strange, it keeps a positive or negative value depending on how far/fast you spin wheel, then when you stop, it will reset back to zero. Also this mouse did not have a horizontal scrolling like some of the others I have. And on this one pressing the wheel down gives you button 3...

Wonder if I need to look/debug another one?

Joystick: Mode button probably some archaic 'act another way mode' - started to remove that line. One thing - probably device issue failing switches - it often keeps streaming updates when untouched.

Logitech Mouse: The Wheel has FAILED sensor. Plugged into Windows and mouse wheel no effect - sometimes pushing it down and rolling registers [Windows and Teensy]. The wheel has Left and Right action buttons and those work.

I'm seeing the T_3.6 USBHost work same and as well on that as T4 - since we 3 have both - not filling this thread and testing on T_3.6 to get initial function - with verbose new hardware reports - should leave a good record without polluting T4_Beta thread as was suggested.

defragster · Feb 17, 2019

mjs513 said:
@defragster/@KurtE
Ok - posting back over here because this may be a T4 only issue. I incorporated Tim's debug code into the Bluetooth.cpp file where the #debug_bt statements are and some strange things. So take a step at a time.

1. With a setup that just specifies debug_tt;
...
2. Now, if I add in some extra lines to setup for debug purposes:
…
There is no hanging of the T4 and verbose prints work without issue.

Now I am really confused on whats going on.

EDIT: Here is another strange data point. I just put the sketch back to the condition it was in when it was causing the fault with debug statements turned and now its not hanging again but I can't get it to connect properly. It connects and then disconnects.

EDIT2: ok lost the usb again by simply uncommenting a couple of serial.prints in joystick.cpp.

I've have seen at times where it re-enters setup() repeatedly. I pulled the log.txt and will see to it shortly. One thing to note it that with PJRC using Serial4 for cores debug spew ( with its direct writes ) - the d_tt code does I/O through Serial4 class code in the sample above. In my testing I have Serial1 independent for debug_tt. The string text shown [@@@fa` ! n B`e@A@ P@@ d%@ ra`ed$!dHdp DRe`dAD LOGb adaba `Ep1] is really messed up. Not sure if that is cores or debut_tt output? So something isn't coded/running right.

I may have some WIP problem - or it may be my setup was unique and working by luck

It is related to T4 use of the code - it has evolved and grown with T4 - I need to see if I can make it work on T_3.6 - maybe that will find the error.

brtaylor · Feb 17, 2019

Eigen (https://github.com/bolderflight/Eigen) seems to work on Teensy4.

mjs513 · Feb 17, 2019

brtaylor said:
Eigen (https://github.com/bolderflight/Eigen) seems to work on Teensy4.

Hi Brian, Welcome to Beta testing. Just to catch you up, Eigen does work I tested it as well. I also tested your UBLOX library and MPU9250 along with one of the Kalman filters. The only piece that's not working yet is EEPROM - that is still on the todo list.

Regards
Mike

brtaylor · Feb 17, 2019

mjs513 said:
Hi Brian, Welcome to Beta testing. Just to catch you up, Eigen does work I tested it as well. I also tested your UBLOX library and MPU9250 along with one of the Kalman filters. The only piece that's not working yet is EEPROM - that is still on the todo list.

Regards
Mike

Thanks Mike,
For the MPU9250 library, did you try both SPI and I2C? I just tried it with I2C and I'm not getting communication with Wire (I2C1, pins 18/19) and Wire3 (pins 16/17) is undefined.

EDIT: nevermind, pins 18 and 19 works...going to have to dig deeper into Wire3.

mjs513 · Feb 17, 2019

mjs513 said:
@JBeale,
Not sure the best way to handle this. There are a couple of options, maybe put it into the initialization function for ADC, but not sure what that would impact. Don't think it would.
@Paul/@JBeale
Anyone reading this - thoughts?

Was doing some thinking about how to do this and maybe is to create another option for pinMode. This is just a thought on naming:

Code:

#define INPUT_ADC		6

and then in pinMode add a additional test:

Code:

else if (mode == INPUT_ADC) {
     *(p->pad) = 0xb0;
}

Wouldn't leave its as b0 but I cant remember off the top of my head the right settings

mjs513 · Feb 17, 2019

brtaylor said:
Thanks Mike,
For the MPU9250 library, did you try both SPI and I2C? I just tried it with I2C and I'm not getting communication with Wire (I2C1, pins 18/19) and Wire3 (pins 16/17) is undefined.

EDIT: nevermind, pins 18 and 19 works...going to have to dig deeper into Wire3.

Well there is no Wire3.
SDA/SCL
Wire: 18/19
Wire1: 17/16
Wire2: 25/24

3 i2c ports you might say.

JBeale · Feb 17, 2019

frequency offset vs. CPU temperature

@mjs513 I don't know the best way to implement turning off the keeper. I think the default should be no keeper when a pin is used as analog input. I suppose there might be cases where you might want it on even when using the ADC but it would be the exception.

For what it's worth, my sample of the T4-beta1 running FreqMeasure on a GPS 1-PPS signal reads around 1.000024 Hz near room temperature, and the indicated frequency goes up with reported CPU temperature. I presume that means the crystal on this particular board is 24 ppm slow, and also it becomes slower with rising temperature.

This plot shows a day's worth of data as I slowly change the temperature of the board. It's nice that we can print out the internal CPU temp. Each point is the average of 60 frequency readings (eg one point per minute). There is a bit of a hysteresis loop; the lower points are going up in temperature and higher points are coming down. This was a very casual test, not in a precisely controlled oven. I had the board in a box, starting at room temperature, then put it on a warm brick. At intervals I switched in a warmer brick. Then I let it cool back down.

Code:

/* FreqMeasure  http://www.pjrc.com/teensy/td_libs_FreqMeasure.html */
#include <FreqMeasure.h>

const int LED1 = 13;         // output LED connected on Arduino digital pin 13

void setup() {
  Serial.begin(115200);       // baud rate is ignored with Teensy USB i/o
  digitalWrite(LED1,HIGH);   
  delay(1000);                // LED on for 1 second
  digitalWrite(LED1,LOW);   
  Serial.println("FreqMeasure starting...");
  FreqMeasure.begin();
}

double sum=0;
int count=0;

void loop() {
  if (FreqMeasure.available()) {
    sum = sum + FreqMeasure.read();
    count = count + 1;
    if (count >= 60) {
      float frequency = FreqMeasure.countToFrequency(sum / count);
      Serial.print(frequency,8);
      Serial.print(", ");
      Serial.print(tempmonGetTemp(),1);
      Serial.println();
      sum = 0;
      count = 0;
    }
  }
}

mjs513 · Feb 18, 2019

@JBeale and others
Guess the easiest thing to do is to add this to adc.c to set the analog pins:

Code:

const struct digital_pin_bitband_and_config_table_struct *p;
for(uint8_t i = 14; i < 24; i++){
  p = digital_pin_to_info_PGM + i;
  *(p->pad) |=  IOMUXC_PAD_PKE;
}

I did check Wire, audio and possibly flexcan will redefine the pad configs if you call them so maybe that's the best way to implement it.

manitou · Feb 18, 2019

mjs513 said:
@JBeale and others
Guess the easiest thing to do is to add this to adc.c to set the analog pins:

Code:

const struct digital_pin_bitband_and_config_table_struct *p; for(uint8_t i = 14; i < 24; i++){ p = digital_pin_to_info_PGM + i; *(p->pad) |= IOMUXC_PAD_PKE; }

I did check Wire, audio and possibly flexcan will redefine the pad configs if you call them so maybe that's the best way to implement it.

Don't you want to disable and not enable/set PKE?

tonton81 · Feb 18, 2019

I noticed on several sites, regarding setting up the clocks, I see many fsl_clock_config files like so:
https://github.com/ARMmbed/mbed-os/...MIMXRT1050/TARGET_EVK/fsl_clock_config.c#L171

/* Setting the VDD_SOC to 1.5V. It is necessary to config AHB to 600Mhz. */
DCDC->REG3 = (DCDC->REG3 & (~DCDC_REG3_TRG_MASK)) | DCDC_REG3_TRG(0x12);

I noticed the teensy core does not do this, and the ordering of the clocks is not same, any insight in this?

mjs513 · Feb 18, 2019

manitou said:
Don't you want to disable and not enable/set PKE?

Yes I do - want it to be 0xb0. So I guess its ~= not very good with this stuff

tonton81 · Feb 18, 2019

Code:

*(p->pad) [B]&=  ~[/B]IOMUXC_PAD_PKE;

mjs513 · Feb 18, 2019

tonton81 said:
Code:

*(p->pad) [B]&= ~[/B]IOMUXC_PAD_PKE;

Thank you Tony. Have to leave this one in my notes for future reference.

mjs513 · Feb 19, 2019

@tonton81, @manitou and @JBeale
Just ran a quick test and on pad config and will create a PR to incorporate into the Core. Now just have to see what state my version of the core is in.

Here's the final change:

Code:

for(uint8_t i = 14; i < 24; i++){
  p = digital_pin_to_info_PGM + i;
  *(p->pad) &=  ~IOMUXC_PAD_PKE;
}

manitou · Feb 19, 2019

mjs513 said:
@tonton81, @manitou and @JBeale
Just ran a quick test and on pad config and will create a PR to incorporate into the Core. Now just have to see what state my version of the core is in.

Just for the record, in the NXP EVKB SDK, the ADC pins are configured as 0xB0 -- PKE (keeper) not enabled.

mjs513 · Feb 19, 2019

manitou said:
Just for the record, in the NXP EVKB SDK, the ADC pins are configured as 0xB0 -- PKE not enabled.

Cool, didn't even check the SDK. PR#357 in the core changes it from 0x10B0 to 0xB0

tonton81 · Feb 19, 2019

you could have also statically just set them as 0xB0, if theyre all suppose to be same without differences

Code:

*(p->pad) = 0xB0;

MichaelMeissner · Feb 19, 2019

I just got my beta board, I tend to print various information at the start of my Serial USB output, including the serial # and ethernet address that FrankB's teensyMac returned. Unfortunately, it looks like the various HAS_KINETIS_FLASH_* macros aren't defined for Teensy 4 beta. Now, I can imagine these are pretty low on the totem pole for things to port, but is there a replacement for teensyMac that will work with T4? At the moment, I just have teensySerial and teensyMac return 0.

I went to: https://github.com/FrankBoesing/TeensyMAC.git and I saw that it had been archived, and the last change was in 2017.

defragster · Feb 19, 2019

PaulStoffregen said:
Yes, confirmed, HW_OCOTP_MAC1 & HW_OCOTP_MAC0 are the ethernet mac address. In this chip it's conveniently memory mapped.

FWIW, those registers are also writable. Writing to the registers is safe. You won't change the non-volatile fuses unless you do a special process with other registers. Anything you write to those register will be lost when the chip resets. At reset the hardware loads all those registers from the non-volatile fuses.

MichaelMeissner said:
I just got my beta board, I tend to print various information at the start of my Serial USB output, including the serial # and ethernet address that FrankB's teensyMac returned. Unfortunately, it looks like the various HAS_KINETIS_FLASH_* macros aren't defined for Teensy 4 beta. Now, I can imagine these are pretty low on the totem pole for things to port, but is there a replacement for teensyMac that will work with T4? At the moment, I just have teensySerial and teensyMac return 0.

I went to: https://github.com/FrankBoesing/TeensyMAC.git and I saw that it had been archived, and the last change was in 2017.

Good to hear MichaelM - I knew I saw something about MAC from Paul - post #731 above and #730 before that from manitou

And this is the current from \hardware\teensy\avr\cores\teensy4\usb_desc.c:

Code:

void usb_init_serialnumber(void)
{
#if 1
	char buf[11];
	uint32_t i, num;

	num = HW_OCOTP_MAC0 & 0xFFFFFF;

manitou · Feb 20, 2019

MichaelMeissner said:
I just got my beta board, I tend to print various information at the start of my Serial USB output, including the serial # and ethernet address that FrankB's teensyMac returned. Unfortunately, it looks like the various HAS_KINETIS_FLASH_* macros aren't defined for Teensy 4 beta. Now, I can imagine these are pretty low on the totem pole for things to port, but is there a replacement for teensyMac that will work with T4? At the moment, I just have teensySerial and teensyMac return 0.

I went to: https://github.com/FrankBoesing/TeensyMAC.git and I saw that it had been archived, and the last change was in 2017.

yep, post #730 shows how to retrieve the T4 ether MAC address. Of course, T4 doesn't break out the Ethernet pins like the T3.5/T3.6 do. I did test Ethernet on NXP EVKB eval board.

manitou · Feb 20, 2019

PaulStoffregen said:
I've asked Robin to send you a replacement. You should hear from her tomorrow. After you've got a new one, I want to get the board back here so I can look into what went wrong.

I just tested the replacement board here. It definitely auto-reboots on Ubuntu 18.04 64-bit.

Re: my misbehavin' first beta unit

Paul,
Just curious. Have you had a chance to look at my first beta unit that required hitting the program button for every reload?

duff · Feb 20, 2019

Just got my T4 and expansion board yesterday, just been poking around for now. Going to work on the low power stuff soon but it looks like I will have to mess with the cpu speeds, voltages and multiple PLLS + Doze bits to get this thing into the real low power modes.

One thing I saw is that ludicrous speed locked it up with a constant dull led, does that work? I edited startup.c for that.

Another is a sketch that I can post if need be gave a cryptic error about RAM overflow I think using a 2048 FFT. error: section `.bss' is not within region `DTCM'

Another is it looks like libarm_cortexM7lfsp_math.a dropped __SMLSD intrinsic, I was able to roll my own but my optimized FFT code doesn't work still but works great with T3's.

Seems like I got a lot of work a head of me

Teensy 4.0 First Beta Test

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Well-known member