Forum Rule: Always post complete source code & details to reproduce any issue!
Page 73 of 175 FirstFirst ... 23 63 71 72 73 74 75 83 123 173 ... LastLast
Results 1,801 to 1,825 of 4361

Thread: Teensy 4.0 First Beta Test

  1. #1801
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,704
    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?

  2. #1802
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,288
    @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: 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.
    Last edited by mjs513; 02-17-2019 at 04:45 PM.

  3. #1803
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,075
    Quote Originally Posted by KurtE View Post
    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.

  4. #1804
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,075
    Quote Originally Posted by mjs513 View Post
    @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.

  5. #1805
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    538
    Eigen (https://github.com/bolderflight/Eigen) seems to work on Teensy4.

  6. #1806
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,288
    Quote Originally Posted by brtaylor View Post
    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

  7. #1807
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    538
    Quote Originally Posted by mjs513 View Post
    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.

  8. #1808
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,288
    Quote Originally Posted by mjs513 View Post
    @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

  9. #1809
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,288
    Quote Originally Posted by brtaylor View Post
    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.

  10. #1810
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    677

    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.

    Click image for larger version. 

Name:	T4B1-FreqMeasure-1PPS.png 
Views:	35 
Size:	110.2 KB 
ID:	15948

    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;
        }
      }
    }

  11. #1811
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,288
    @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.

  12. #1812
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,236
    Quote Originally Posted by mjs513 View Post
    @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?

  13. #1813
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,133
    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/b..._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?

  14. #1814
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,288
    Quote Originally Posted by manitou View Post
    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

  15. #1815
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,133
    Code:
    *(p->pad) &=  ~IOMUXC_PAD_PKE;

  16. #1816
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,288
    Quote Originally Posted by tonton81 View Post
    Code:
    *(p->pad) &=  ~IOMUXC_PAD_PKE;
    Thank you Tony. Have to leave this one in my notes for future reference.

  17. #1817
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,288
    @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;
    }

  18. #1818
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,236
    Quote Originally Posted by mjs513 View Post
    @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.
    Last edited by manitou; 03-23-2019 at 01:19 AM.

  19. #1819
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,288
    Quote Originally Posted by manitou View Post
    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

  20. #1820
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,133
    you could have also statically just set them as 0xB0, if theyre all suppose to be same without differences

    Code:
    *(p->pad) = 0xB0;

  21. #1821
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,361
    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.

  22. #1822
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,075
    Quote Originally Posted by PaulStoffregen View Post
    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.
    Quote Originally Posted by MichaelMeissner View Post
    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;

  23. #1823
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,236
    Quote Originally Posted by MichaelMeissner View Post
    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.

  24. #1824
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,236
    Quote Originally Posted by PaulStoffregen View Post
    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?

  25. #1825
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    978
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •