Forum Rule: Always post complete source code & details to reproduce any issue!
Page 7 of 149 FirstFirst ... 5 6 7 8 9 17 57 107 ... LastLast
Results 151 to 175 of 3703

Thread: Teensy 4.0 First Beta Test

  1. #151
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,166
    Which FRAM are you using?

    I have a small number of MB85RC256 chips here. Looks like it has the same pinout as the 24LC02B.

  2. #152
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,443
    Yep - I am using the MB85RC256 from adafruit - https://learn.adafruit.com/adafruit-...kout/downloads. It also has the same i2c address. EDIT: Yes I am using 3.3v with the chip.

    Going to be a little more methodical with this tomorrow.

  3. #153
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,770
    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 by defragster; 12-31-2018 at 11:40 AM.

  4. #154
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,631
    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 by Frank B; 12-31-2018 at 10:37 AM.

  5. #155
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,770
    Quote Originally Posted by Frank B View Post
    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.

  6. #156
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,631
    @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?
    Attached Files Attached Files

  7. #157
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,631
    pinMode(17, INPUT) crashes
    edit..lol..my fault .. ok..it's Serial4 - no crash
    Last edited by Frank B; 12-31-2018 at 10:37 AM.

  8. #158
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,770
    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 by defragster; 12-31-2018 at 11:39 AM.

  9. #159
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,631
    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.

  10. #160
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,770
    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::

    Quote Originally Posted by Frank B View Post
    Yes, Serial.print crashes (windows 10, if this is important)). Minimal Sketch:
    Code:
    void setup() {
    
      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;
        }
      }
    
     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.

  11. #161
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,631
    Your modified code prints all correctly for me, USB-Serial, too. But LED is off.

  12. #162
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,770
    Quote Originally Posted by Frank B View Post
    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 ...

  13. #163
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,631
    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.

  14. #164
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,166
    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.

    Click image for larger version. 

Name:	file.png 
Views:	12 
Size:	37.3 KB 
ID:	15461

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

  15. #165
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,770
    Quote Originally Posted by Frank B View Post
    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

  16. #166
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,631
    Code:
        configure_systick();
        usb_pll_start();
    for (int i=0; i<50000; i++) asm volatile ("nop");
     ARM_DEMCR |= ARM_DEMCR_TRCENA;
        set_arm_clock(600000000);
    Without the loop, it does not work - looks like we need to wait for something?

  17. #167
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,166
    Quote Originally Posted by mjs513 View Post
    ... running blink with Fastest and it hung.
    Committed a fix for this.

    https://github.com/PaulStoffregen/co...92e3f027bbf8cd

    Turns out the compiler was noticing the code in startup.c copies memory and was replacing it with a call to memcpy(). Trouble is, this startup copy puts the memcpy() code into ITCM.

  18. #168
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,166
    Quote Originally Posted by Frank B View Post
    looks like we need to wait for something?
    Working on this now. Current theory is it's likely a bootloader bug.

  19. #169
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,443
    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.

  20. #170
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,443
    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.

  21. #171
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,220
    Quote Originally Posted by Frank B View Post
    Code:
        configure_systick();
        usb_pll_start();
    for (int i=0; i<50000; i++) asm volatile ("nop");
     ARM_DEMCR |= ARM_DEMCR_TRCENA;
        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

  22. #172
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,631
    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)

  23. #173
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,631
    @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?

  24. #174
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,166
    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.

  25. #175
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,848
    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...

Posting Permissions

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