K66 Beta Test

Status
Not open for further replies.
Utilizing all pins on a custom breakout

MichaelMeissner said:
One method that people use for breakout boards is to use a castellated design, such as this board for Teensy 3.1/2 from FrankB: https://oshpark.com/shared_projects/cYQjHdCu. His newer board is here (but the pictures don't show the castellation): https://pcbs.io/user/FrankB.

You might want to check out this thread from KurtE about a carrier board he is designing: https://forum.pjrc.com/threads/36244-Teensy-3-5-3-6-Breakout-board-to-test-things-with.

Here is a post from Jimmayhaug on a sturdier way to solder pins to the underneath pads: https://forum.pjrc.com/threads/26071-Using-all-Teensy3-x-pins-with-a-socket.

Note, in the 3.5/3.6 all of those pins are on the outside edges, so you might not need to solder to the pads underneath the Teensy.
Click to expand...

So many options... SMDheader underneath was looking good but I saw it may may be prone to lifting or damage if swapping the MCU in and out frequently. Maybe a bit of love from a hot glue gun can make the connections underneath more like a single connection?

Mounting upside down would also have an advantage of being able to add later if needed but has the drawback of covering the reset button and making access to the SD card a bit tricky.

EXPERIMENT : Had a look at double male headers I have (ones that can break off to any size)... it seems the pins bend quite easily so it would be more than possible to join 33->3.3v, 34->47, 35->48 etc. This should solve issues with lining up pins, means the bottom can be facing the bottom and hopefully since each SMD connection will have a through hole to support it... it shouldn't be prone to damage. I'm going to give this a dry run on my Teensy 3.1 that still has no headers.

VERDICT : The bent male double header approach seems good... however as the pins that get bent do not sit flush the entire pin array is mounted up slightly which should not be a problem as there is still enough to solder on the opposite side and once soldered in place some hot glue could easily fill the small gaps if needed. As for the female headers on the breakout... would use the breakable single ones on board as needed as all connections on the breakout will be through hole.

I'm very happy with this project so can prob commit to backing $100ish to secure enough units for testing and eventual use.


The original breakout I had started had provisions for SD card and a RTC... guess they can go for starters.
 
Anyone able to point me to best info on the 3.5/3.6 pin positions for the back?

I can't see what the pins are vertically between 38 & 27 (5 pins).

Also the 5 pins horizontal slightly above pins 1 - 5.

Need a link to a board front and back + latest pinouts.
 
hoek67 said:
Anyone able to point me to best info on the 3.5/3.6 pin positions for the back?

I can't see what the pins are vertically between 38 & 27 (5 pins).

Also the 5 pins horizontal slightly above pins 1 - 5.

Need a link to a board front and back + latest pinouts.
Click to expand...

The 5 horizontal pins that are slightly above pins 1-5 are for the second USB pinout. Starting at pin 1, the pins are 5v, D-, D+, ground, ground. Note, these pins are offset from the standard 0.1" layout, so you would not be able to use a standard 0.1" board to attach these pins directly.

The 5 vertical pins towards the back in front of the micro SD card between pins 27 and 38 are (starting with the pin 27 side): Vbattery for the real time clock, 3.3v, ground, program, reset. The Vbattery, 3.3v, ground, and program pads are in the same position as the back pins on the Teensy 3.2. The DAC pin on the Teensy 3.2 is now the reset pin on the 3.5/3.6.
 
MichaelMeissner said:
The 5 horizontal pins that are slightly above pins 1-5 are for the second USB pinout. Starting at pin 1, the pins are 5v, D-, D+, ground, ground. Note, these pins are offset from the standard 0.1" layout, so you would not be able to use a standard 0.1" board to attach these pins directly.

The 5 vertical pins towards the back in front of the micro SD card between pins 27 and 38 are (starting with the pin 27 side): Vbattery for the real time clock, 3.3v, ground, program, reset. The Vbattery, 3.3v, ground, and program pads are in the same position as the back pins on the Teensy 3.2. The DAC pin on the Teensy 3.2 is now the reset pin on the 3.5/3.6.
Click to expand...

OK ... great info! From what I can see the 2nd USB is offset 0.05" in both directions.

I think I finally have a schematic with pins that can be used. Some sets of pins will just get broken out as is so... in essence it's nice to know what they are but won't break the board. However if I join a VBAT and VCC ... could be a bit nasty.



Given the time before shipping I have a few weeks to get this done and will have time to get the PCB made.
 
hoek67 said:
OK ... great info! From what I can see the 2nd USB is offset 0.05" in both directions.

I think I finally have a schematic with pins that can be used. Some sets of pins will just get broken out as is so... in essence it's nice to know what they are but won't break the board. However if I join a VBAT and VCC ... could be a bit nasty.



Given the time before shipping I have a few weeks to get this done and will have time to get the PCB made.
Click to expand...

Please see #1143
The grid is 0.05" and the dimensions listed are mm, the only one that is off is 3.18mm it should be 3.175mm, eagle rounded it. Meaning the 2nd USB is 0.05" left/right center to center from the pins below it but it is 0.125" above center to center from the pins below.
 
Did I miss anywhere that covered how much curent the T3.6 will pull at 180mhz doing some compute intensive stuff like a tight loop using the fp hardware? Does it get vey hot? I'm also wondering how current much would be left for io and external 3.3 v parts.
 
Finally was able to take a look at the board. I've got a "pluggable" configuration that seems to allow access to all of the inboard pins in a configuration similar to the teensy3.2.

I've tested all of the available digital pins, and everything looks copacetic. Now I'll make an Eagle device and have a test board made. More as things develop.
 
bicycleguy said:
Is anybody working on the dual CAN_bus?
Click to expand...
My Teensy 3.6 has recently arrived (thanks again Paul and Robin) and I did some quick tests with the FlexCAN library.

I've loaded one of my sketches using the FlexCAN library at 1Mbit/s and it worked no problem on CAN0. Then I've modified the FlexCAN library to work with CAN1 and it also seems to be working fine. Next step would be to modify the FlexCAN library to make the dual CAN operations possible.
 
Last edited:
My teensy arrived somewhen in the past 9 days while I was on vacation. It appears to be fine, I'll try it this weekend. Thanks!
 
pawelsky said:
Next step would be to modify the FlexCAN library to make the dual CAN operations possible.
Click to expand...
I've created a fork of the FlexCAN library, where I'm adding my changes.
https://github.com/pawelsky/FlexCAN_Library/
So far you can select which CAN controller to use by providing an extra parameter id during the FlexCAN object construction (either 0 or 1). Did not try two simultaneous instances working together yet, but that will be a next step.
 
This weekend I've been working on the Teensy 3.5 testing. Took longer than expected, got the first board tested just now.

I'm planning to send out beta boards to about 6 people. Going to sent to Frank, KurtE, Manitou... who else (on the beta testers list) wants to play with the K64 chip over the next few weeks? Only 12 of these boards exist, so please only request one if you definitely have time to do useful testing.

As usual I've fallen behind on lots of forum messages over the last few days. I know there's several questions specifically for me. Please be patient... I'll try to get caught up on Monday or Tuesday, after we've shipped these Teensy 3.5 betas.
 
PaulStoffregen said:
This weekend I've been working on the Teensy 3.5 testing. Took longer than expected, got the first board tested just now.

I'm planning to send out beta boards to about 6 people. Going to sent to Frank, KurtE, Manitou... who else (on the beta testers list) wants to play with the K64 chip over the next few weeks? Only 12 of these boards exist, so please only request one if you definitely have time to do useful testing.

As usual I've fallen behind on lots of forum messages over the last few days. I know there's several questions specifically for me. Please be patient... I'll try to get caught up on Monday or Tuesday, after we've shipped these Teensy 3.5 betas.
Click to expand...

Great. I look forward to test it !
 
Tested my T3.6 with teensyduino 3.6 beta 3 and it seems to work fine. The board is a bit longer than I imagined it would be (I thought it would be like a Teensy 3.2 plus a micro SD card socket). Now doing DMASPI stuff.
 
Sorry if this question has been answered (somewhere in this really hard to search mass). Wondering about the number of independent timer blocks and which pins will be assigned to which timer, etc? Looking for information similar too:
Teensy 3.1 & 3.2 FTM0 5, 6, 9, 10, 20, 21, 22, 23 488.28 Hz
FTM1 3, 4 488.28 Hz
FTM2 25, 32 488.28 Hz
Click to expand...
 
Frank, KurtE, Manitou - good choices - nice to see what works with OC and timing.
If I got a T_3.5 I'd have time to do my random experimentation and test barrage - and as usual follow up on whatever somebody else finds/does given the resources I have - if that constitutes useful testing sign me up.

Soldered my round 3 T_3.6 on the road to work - now home again. Going to update my desktop to IDE 1.6.11 and latest TeensyDuino. Everything I've done on T_3.6 should translate to work now that I can get back to it after 6 tough weeks.
 
On my Windows 10 computer I noticed that the USB COM port changes dependent on the T3.6 CPU Speed.
On my particular PC, It is COM6 when CPU <= 120 MHz and COM3 when CPU > 120 MHz.
I presume this is because the SN cannot be accessed when the Kinetis K66 is set above 120 MHz.
This may present a problem if trying to communicate with Multiple Teensy 3.6s set at high CPU Speed.

I'm running a Teensy 3.6r3 with Arduino 1.6.11 and Teensyduino 1.30b3 under Windows 10
 
Last edited:
Wozzy said:
On my Windows 10 computer I noticed that the USB COM port changes dependent on the T3.6 CPU Speed.
On my particular PC, It is COM6 when CPU <= 120 MHz and COM3 when CPU > 120 MHz.
I presume this is because the SN cannot be accessed when the Kinetis K66 is set above 120 MHz.
This may present a problem if trying to communicate with Multiple Teensy 3.6s set at high CPU Speed.

I'm running a Teensy 3.6r3 with Arduino 1.6.11 and Teensyduino 1.30b3 under Windows 10
Click to expand...
Yep this is the issue. My probably not eloquent fix is to check before we go into high speed mode and call of to get the USB serial #, which is working for me.
You can see the changes up on my fork with new branch: https://github.com/KurtE/cores/tree/Read-USB-Serial-before-HSRUN
which has the pull request: https://github.com/PaulStoffregen/cores/pull/166
 
PaulStoffregen said:
I'm planning to send out beta boards to about 6 people. Going to sent to Frank, KurtE, Manitou... who else (on the beta testers list) wants to play with the K64 chip over the next few weeks? Only 12 of these boards exist, so please only request one if you definitely have time to do useful testing.
Click to expand...

I'm ready for K64 tests.

:confused:
Paul, I tried to breadboard/jumper the ethernet shield to a beta3 board, but no luck. I jumpered middle gnd/3.3v and pins: 3,4,24,25,26,27,28 19,18,17,16,39 based on pin ALT tables posted in this thread. Are there other pins that are necessary (lacking a schematic, i be guessin')? Could be my soldering of beta3 pins, or jumper length, or ?

I get no LEDs on shield and etherraw test is not reading the PHY regs ....
(shield still works on K66 proto test board)
 
manitou said:
I'm ready for K64 tests.

:confused:
Paul, I tried to breadboard/jumper the ethernet shield to a beta3 board, but no luck. I jumpered middle gnd/3.3v and pins: 3,4,24,25,26,27,28 19,18,17,16,39 based on pin ALT tables posted in this thread. Are there other pins that are necessary (lacking a schematic, i be guessin')? Could be my soldering of beta3 pins, or jumper length, or ?

I get no LEDs on shield and etherraw test is not reading the PHY regs ....
(shield still works on K66 proto test board)
Click to expand...

Manitou - FWIW I can confirm when I put female headers (to match the PROTO) on my beta3 board that my Ethernet shield did work the same on both with your etherraw sketches as I used them. I'd suspect the solder/jumpers or some missing connect not getting good signal/power.

Paul: Have you made any preliminary versions of the "T_3.6 card" you can publish yet for proofreading/use?
 
manitou said:
I jumpered middle gnd/3.3v and pins: 3,4,24,25,26,27,28 19,18,17,16,39 based on pin ALT tables posted in this thread.
Click to expand...

That's all of them. Actually, 16,17,18,19 aren't needed.

Perhaps it doesn't work if the wires are too long? RMII is 50 MHz.


defragster said:
Paul: Have you made any preliminary versions of the "T_3.6 card" you can publish yet for proofreading/use?
Click to expand...

Nope, but that's next on my list after shipping some K64 beta boards. The cards take 1-2 weeks to print, so this is about the cut-off to have time for 1 redo if there's any problems.
 
I use the internal temperature sensor when creating the seed value for random numbers (along with some other stuff). A page that came out when the Teensy 3.0 was new mentioned this sensor: http://dangerousprototypes.com/forum/viewtopic.php?t=4606.

In case others also use it, I dug into the library (avr/cores/teensy3/analog.c), and noticed for 3.5/3.6, the sensor is now on pseudo pin 44 instead of 38.

Similarly, for Teensy 3.0, 3.1, 3.2, analogRead (39) gave AREF (the comments indicate LC gives the bandgap sensor). On the Teensy 3.5/3.6, it looks like this got moved to pseudo pin 45.
 
Status
Not open for further replies.
Back
Top