Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 3 FirstFirst 1 2 3
Results 51 to 72 of 72

Thread: Teensy 3.6 diy board

  1. #51
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    In the teensy connected a gyroscope and when i finish measurements of sensor the microcontroller goes into a hibernation state.
    When going a hibernation state consumption has increased,if i delete the commands below in the code

    Code:
    void setup() {
        .
        .
        .
        .
        //SPI2.setSCK(46);
        //SPI2.setMOSI(44);
        //SPI2.setMISO(45);
        //SPI2.begin();
        //SPI2.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));
       .
       .
       .
    and run the program again consumption will be reduced.
    When it goes to a hibernation state the spi communication does not stop??
    What can i do?

  2. #52
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,430
    I don't see the rest of your code here, but if you wish to go into Hibernate state, what happens if you first call: SPI2.end();

    It should put stop the SPI communications, and it puts MISO/MOSI/SCK pins into mode 0 Note: it does not touch the CS pin or other pins like DC....

    Edit: Obviously once you wake up and if you wish to use SPI2 again you would need to go through the INIT stuff that again calls SPI2.begin()

  3. #53
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    Hello,
    i finished my own 3.6 teensy pcb but i have some problems.
    I first loaded the example blink and everything went good,to test that it works i connected a sensor via spi but it did not work,then connected via i2c but it still did not work.
    The sd card,dac0 works fine,spi and i2c they do not works.I tried on spi1,spi2,spi3 and i2c3 none works.
    An example i loaded using i2c3(scl3-sda3) was this:

    Code:
    #include <Wire.h> 
    
    byte lowByte;
    unsigned long timer;
    int adress;
    
    //Setup routine
    void setup(){
    
      Wire2.begin();                  //Start the I2C as master
      Serial.begin(9600);          //Start the serial connetion @ 9600bps
      delay(250);  
                    
    }
    
    //Main program
    void loop(){
    
      if(adress == 0){
        Serial.println("Searching for divice");
        for(adress = 0; adress < 255; adress ++){
          Wire2.beginTransmission(adress);
          Wire2.write(0x0F);
          Wire2.endTransmission();
          Wire2.requestFrom(adress, 1);
          timer = millis() + 100;
          while(Wire2.available() < 1 && timer > millis());
          lowByte = Wire2.read();
          if(lowByte == 211){
            Serial.println("");
            Serial.print("Sensor L3G4200 found @ adress:");
            Serial.println(adress);
            adress = 256;
          }
          else if(lowByte == 215){
            Serial.println("");
            Serial.print("Sensor L3GD20H found @ adress:");
            Serial.println(adress);
            adress = 256;
          }
          else Serial.print(".");
        }
        if(adress == 255){
          Serial.println("");
          Serial.println("divice not found!");
        }
      }
    }
    Can you help me?

    The PCB


    edit
    I also tested it uart3 connect it gps but unfortunately it does not works.
    Last edited by thanos; 07-27-2018 at 09:38 PM.

  4. #54
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,592
    To use I2C3, you need to do at least 2 things.

    First, find this in WireKinetis.h and uncomment the define for WIRE_IMPLEMENT_WIRE3

    Code:
    // Teensy 3.6
    #elif defined(__MK66FX1M0__)
    #define WIRE_IMPLEMENT_WIRE
    #define WIRE_IMPLEMENT_WIRE1
    #define WIRE_IMPLEMENT_WIRE2
    //Wire3 is seldom used on Teensy 3.6
    //#define WIRE_IMPLEMENT_WIRE3
    #define WIRE_HAS_START_INTERRUPT
    #define WIRE_HAS_STOP_INTERRUPT
    Then, make sure you're actually using Wire3 in your program...

    Quote Originally Posted by thanos View Post
    An example i loaded using i2c3(scl3-sda3) was this:
    ...
    Code:
      Wire2.begin();                  //Start the I2C as master
    If you use Wire2, it will try to access the wrong port!

    It's always a good idea to keep the original Teensy 3.6 nearby and run the same program on your custom board and the original Teensy. Then you can compare the 2 results. It's *much* easier than wasting a lot of time trying to troubleshoot your custom hardware only to eventually figure out the code has a problem.

  5. #55
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    All works properly paul,was a problem at hardware.
    Thanks.

  6. #56
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    In my question here (post 44) i have made some mistakes, i will continue on this theme.
    I added additionally the pin PTC16 as pin 64 in the archives "core_pins.h" and "pins_tensy.c" with the following changes and additions.

    1) core_pins.h
    Code:
    i changed
    
    #define CORE_NUM_TOTAL_PINS      64 ---> 65
    
    #define CORE_NUM_DIGITAL         64 ---> 65
    
    #define CORE_NUM_INTERRUPT       64 ---> 65
    
    
    #define CORE_MAX_PIN_PORTC       11 ---> 16
    
    i added
    
    #define CORE_PIN64_BIT		16
    
    #define CORE_PIN64_BITMASK	(1<<(CORE_PIN64_BIT))
    
    #define CORE_PIN64_PORTREG	GPIOC_PDOR
    
    #define CORE_PIN64_PORTSET	GPIOC_PSOR
    
    #define CORE_PIN64_PORTCLEAR	GPIOC_PCOR
    
    #define CORE_PIN64_DDRREG	GPIOC_PDDR
    
    #define CORE_PIN64_PINREG	GPIOC_PDIR
    
    #define CORE_PIN64_CONFIG	PORTC_PCR16
    
    #define CORE_INT64_PIN		64
    
    for digitalWrite routine
    
    else if (pin == 64) {
    CORE_PIN64_PORTSET = CORE_PIN64_BITMASK; 
    }
    
    for digitalRead routine
    
    else if (pin == 64) {
    return (CORE_PIN64_PINREG & CORE_PIN64_BITMASK) ? 1 : 0;
    }
    2) pins_tensy.c
    Code:
    i added
    
    {GPIO_BITBAND_PTR(CORE_PIN64_PORTREG, CORE_PIN64_BIT),
    &CORE_PIN64_CONFIG},
    I tried the new pin with the program below but the led does not flash.
    Should i add anything else?

    Code:
    int led = 64;
    
    void setup() {                
     
      pinMode(led, OUTPUT);  
       
    }
    
    void loop() {
      digitalWrite(led, HIGH);
      delay(2000);               
      digitalWrite(led, LOW);
    }

  7. #57
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    Any help please?

  8. #58
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    Can someone tell me what is wrong?
    Why does not work the new pin?

  9. #59
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,535
    Nobody knows what you are really doing. You are talking about a LED which does not flash, but nobody has seen if and how you connected a LED to that pin. This is a Teensy support forum. And Teensy processors do have their LED on pin 13. Not on an undefined pin.
    If you add pin definitions to the core files for GPIO, did you check if the port registers are correctly configured for GPIO operation? Looking at your code, the pin MUX setting for GPIO for this pin seems to be missing.
    Instead of begging here, you should understand that what you are doing is outside the Teensy horizon and that you are on your own.

  10. #60
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    Quote Originally Posted by Theremingenieur View Post
    did you check if the port registers are correctly configured for GPIO operation?Looking at your code, the pin MUX setting for GPIO for this pin seems to be missing.
    I have set the new pin in core_pins.h and pins_tensy.c, no longer needed the mux setting.

    Code:
    #define CORE_PIN64_BIT		16
    
    #define CORE_PIN64_BITMASK	(1<<(CORE_PIN64_BIT))
    
    #define CORE_PIN64_PORTREG	GPIOC_PDOR
    
    #define CORE_PIN64_PORTSET	GPIOC_PSOR
    
    #define CORE_PIN64_PORTCLEAR	GPIOC_PCOR
    
    #define CORE_PIN64_DDRREG	GPIOC_PDDR
    
    #define CORE_PIN64_PINREG	GPIOC_PDIR
    
    #define CORE_PIN64_CONFIG	PORTC_PCR16
    
    #define CORE_INT64_PIN		64
    
    _____________________________________________
    
    for digitalWrite routine
    
    else if (pin == 64) {
    CORE_PIN64_PORTSET = CORE_PIN64_BITMASK; 
    }
    
    for digitalRead routine
    
    else if (pin == 64) {
    return (CORE_PIN64_PINREG & CORE_PIN64_BITMASK) ? 1 : 0;
    
    ______________________________________________
    
    {GPIO_BITBAND_PTR(CORE_PIN64_PORTREG, CORE_PIN64_BIT),&CORE_PIN64_CONFIG},}
    How do you check this?

  11. #61
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,535
    If you do think the MUX setting is not needed, ok for you.

    I’d check by setting directly the bits of the port registers in test code to drive the pin high and low, in between read the registers to check if everything has well been written, then check with the oscilloscope if the pin follows these commands. If not, you might naturally continue to ignore the MUX...

    I’d setup a test/diagnose structure following the GPIO block diagram and register mapping table in the Reference manual and advance and verify systematically step by step.

  12. #62
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,592
    Maybe try digitalWriteFast vs digitalWrite. They use different code, so if one works you'll know it's a mistake you've made somewhere impacting only the other code.

    If both still fail, try creating pin 64 as a duplicate of pin 13, since 13 has a known-good LED. Then after that works, change it to your intended pin.

  13. #63
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    I tried and with digitalWriteFast but the pin ptc16 is not enabled,i measure with the multimeter 0.5v.
    Paul first of all, the changes i have made are sufficient or i have to do something and in other archives?

    If both still fail, try creating pin 64 as a duplicate of pin 13, since 13 has a known-good LED. Then after that works, change it to your intended pin.
    How can I do that?

  14. #64
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,592
    Quote Originally Posted by thanos View Post
    the changes i have made are sufficient or i have to do something and in other archives?
    I'm not completely sure. It looks good. But it's been quite a while since I've edited that code, about 2 years since Teensy 3.5 & 3.6 were added.

  15. #65
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    Quote Originally Posted by Theremingenieur View Post
    If you do think the MUX setting is not needed, ok for you.

    I’d check by setting directly the bits of the port registers in test code to drive the pin high and low, in between read the registers to check if everything has well been written, then check with the oscilloscope if the pin follows these commands. If not, you might naturally continue to ignore the MUX...

    I’d setup a test/diagnose structure following the GPIO block diagram and register mapping table in the Reference manual and advance and verify systematically step by step.
    The example sketch Blink mux setting is not needed because the pin13=ptc5 is registered, the same i do pin64=ptc16.Why do i have to adjust the mux settings since i have set the new pin.

    Code:
    int led = 13;
    
    // the setup routine runs once when you press reset:
    void setup() {                
      // initialize the digital pin as an output.
      pinMode(led, OUTPUT);     
    }
    
    // the loop routine runs over and over again forever:
    void loop() {
      digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
      delay(1000);               // wait for a second
      digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
      delay(1000);               // wait for a second
    }

  16. #66
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,535
    Look at the code for pinMode(). In order to use the pin as output and thus to drive a LED, all the used config addresses have to be correct: The functions portConfigRegister(pin), portModeRegister(pin), and digitalPinToBitMask(pin) would have to return correct register addresses.

    I'm not sure if it's a problem, but pin64 seems already to be defined in pins_arduino.h as follows: #define PIN_A10 (64)

    Code:
    void pinMode(uint8_t pin, uint8_t mode)
    {
    	  volatile uint32_t *config;
    
    
    	  if (pin >= CORE_NUM_DIGITAL) return;
    	  config = portConfigRegister(pin);
    
    
    	  if (mode == OUTPUT || mode == OUTPUT_OPENDRAIN) {
    #ifdef KINETISK
    		    *portModeRegister(pin) = 1;
    #else
    		    *portModeRegister(pin) |= digitalPinToBitMask(pin); // TODO: atomic
    #endif
    		    *config = PORT_PCR_SRE | PORT_PCR_DSE | PORT_PCR_MUX(1);
    		    if (mode == OUTPUT_OPENDRAIN) {
    		      *config |= PORT_PCR_ODE;
    		    } else {
    		      *config &= ~PORT_PCR_ODE;
        }
    	  } else {
    #ifdef KINETISK
    		    *portModeRegister(pin) = 0;
    #else
    		    *portModeRegister(pin) &= ~digitalPinToBitMask(pin);
    #endif
    		    if (mode == INPUT) {
    			      *config = PORT_PCR_MUX(1);
    		    } else if (mode == INPUT_PULLUP) {
    			      *config = PORT_PCR_MUX(1) | PORT_PCR_PE | PORT_PCR_PS;
    		    } else if (mode == INPUT_PULLDOWN) {
    			      *config = PORT_PCR_MUX(1) | PORT_PCR_PE;
    		    } else { // INPUT_DISABLE
    			      *config = 0;
    		    }
    	  }
    }

  17. #67
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    I changed the pin 63-->PTE5 to 63-->PTC16 without defining a new pin,but the pin PTC16 not activated.
    Can not "see" the pin PTC16.

  18. #68
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    Hello,i have found decoupling capacitors 0.1uf 16v and 25v.
    Which one is best to put on,16V or 25V??

  19. #69
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    does not matter much. more important is they are NP0

  20. #70
    Senior Member
    Join Date
    Aug 2016
    Posts
    149
    Ok thanks frank.

  21. #71
    Junior Member
    Join Date
    Aug 2019
    Posts
    1
    Hi All,
    Made an account just to post this. I've been working with the Teensy for several years. As part of my phd I recently embedded a Teensy 3.6 clone into a device I built. I cobbled together information from Paul and others across various posts as well as disassembling and reverse engineering parts of the Teensy 3.6. If it would be helpful to someone, please reply to this post and I will provide a DigiKey parts list and a schematic and gerbers for a 4-layer 3.6 clone I laid out.

  22. #72
    Senior Member
    Join Date
    Oct 2015
    Location
    Vermont, USA
    Posts
    190
    Our Tympan Rev D is also a Teensy 3.6 embedded as the brains in an audio processing system. Full schematics and design files are here: https://github.com/Tympan/Tympan_Rev_D_Hardware

    Chip

Posting Permissions

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