Teensy 3.6 diy board

Status
Not open for further replies.
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() {
    .
    .
    .
    .
   [COLOR="#B22222"][COLOR="#FF0000"] //SPI2.setSCK(46);
    //SPI2.setMOSI(44);
    //SPI2.setMISO(45);
    //SPI2.begin();
    //SPI2.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));[/COLOR][/COLOR]
   .
   .
   .

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?
 
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()
 
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:
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...

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.
 
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:
[B][COLOR="#FF0000"]i changed[/COLOR][/B]

#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

[B][COLOR="#FF0000"]i added[/COLOR][/B]

#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

[B][COLOR="#FF0000"]for digitalWrite routine[/COLOR][/B]

else if (pin == 64) {
CORE_PIN64_PORTSET = CORE_PIN64_BITMASK; 
}

[B][COLOR="#FF0000"]for digitalRead routine[/COLOR][/B]

else if (pin == 64) {
return (CORE_PIN64_PINREG & CORE_PIN64_BITMASK) ? 1 : 0;
}

2) pins_tensy.c
Code:
[B][COLOR="#FF0000"]i added[/COLOR][/B]

{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);
}
 
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.
 
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?
 
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.
 
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.
 
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?
 
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
}
 
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;
		    }
	  }
}
 
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.
 
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.
 
Which xtal is which

It depends on the used crystals. With the crystals from reply#22:
16Mhz: 2x20pF
32kHz: none


I want to replace the 16 MHz xtal with a TCXO, Looking at the xtals, I think the 16 MHz is the small one and the larger the RTC.
Is that correct?
 
Teensy 3.6 clone question

Hello,i have found decoupling capacitors 0.1uf 16v and 25v.
Which one is best to put on,16V or 25V??

Thanos and all,

I am new to this forum and started to build a Teensy 3.6 clone. The led and ADC work fine but I have an issue with my sd card. I checked the card with my Teensy 3.6 and it does not have any problem. Any advice on this. Attached is a screenshot of my sdcard connection.

Thanks,
 

Attachments

  • sdcard_issue.jpg
    sdcard_issue.jpg
    334.3 KB · Views: 81
I just wanted to reach out to everyone here who has successfully clone 3.6 if you can provide something that I need to look at on my issue with the sdcard. I tried to check the MK66 document and all the pins were correct (PTE0, ..PTE5). It does have power (3.3V and the ground is connected). I did try to resolder the pins but still the same. Do I need to shorten the distance of the sdcard to MK66?

Thanks again,
 
Status
Not open for further replies.
Back
Top