K66 Beta Test

Status
Not open for further replies.
Paul you might make a "KS Special Early Developer' announcement thread to provide those getting to see the new Teensy for the first time a starting point to the K66/K64 threads and any other such notes as the one below for initial use of their new items.

Also - if you had a preferred/usable solution to the T_3.6 HSRUN USB serial # issue - I would say that alone would be a good for a 1.31Beta0 placeholder KS release so that folks aren't inclined to hack the core on day 1.

PaulStoffregen said:
The Ethernet shield fits with the PCB covering both 24 pin sockets.

Each side of the shield has 20 pins, not 24. Orient the 20 pins onto right most 40 of 48 pins. That's pins 3-12+3.3V+24-32 on the bottom row and pins 22-13+GND+DAC1+DAC0+39-33 on the top row. When oriented correctly, the PCB should exactly cover the two sockets, not overhanging either end of the sockets. The RJ45 jack should be above the 8 left-most pins (GND+0-2 and VIN+AGND+3.3V+23). The RJ45 jack does NOT overhang the end of the sockets.

There's no connection to the VIN & GND pins on the left side. The shield gets its power from the 3.3V pin that's between pins 11 and 24, and ground from the GND pin between pins 13 and DAC1.
Click to expand...

This post was important to know how to properly orient the Ethernet board on the Teensy! I had it linked on Post 8. I just noticed the shield has the matching new row of through hole pins for an orientation guide as well - though those pins are not required, just present at the base of the SD adapter. Given the precious nature of these hand 'soldered by a goddess' boards - and the still rare Teensy they go with - I thought I'd make note of it,

* I was going to combine my serial# fix with Frank's and place it in startup_early_hook() to allow per sketch inclusion, but it doesn't work to persist that early - wherever it gets cached goes away. Also that area seems to be dangerous to code in. I'm not sure if this is unique to the T_3.6 as I have not done it before - most of the MCU is offline and the user sketch "C" init code has not been done - so you can reference a sketch global variable and set it, then that value is overwritten - even if the global is not initialized. That is explainable - but surprising.
 
crystal specs
For my crystal fetish, someday i'd like to know the specs and/or part number for the MCU crystal and the RTC crystal on the K64/K66
 
I updated the spread sheet to include Prop Shield and Audio Adapter Board pinouts:

Download here:
https://www.dropbox.com/s/23yl6hxqmp0h2u9/T3.6pinoutDiagram.ods?dl=0

Screenshot:
screenshot.png

It's meant to be printed on an A4 sheet in landscape orientation, and it's actually not that easy to cram in even more information without making it look messy... Maybe I should expand to two sheets of A4 in portrait orientation and do the left and right side seperately?
Ben
 
Cool ben. I suspect you can't get the get the other shields on it (octows2811, wiz810io, and Adafruit feather).

I suspect with the ethernet pinouts, we probably won't get too many people using the wiz810io shield.

And the most natural way to mount a Teensy 3.2/LC to the feather shield (having the Teensy on top of the feather shield) won't work because the lipo battery will get in the way (but you could mount the Teensy underneath the shield, but you would need to bring out a reset button to the shield.

The octows2811 might be a possibility. I do wonder if if somebody wants something that has more lights in parallel.
 
Ben said:
I updated the spread sheet to include Prop Shield and Audio Adapter Board pinouts:
Click to expand...
Posted an image and post link on post #8

Read today's KS Update - amazing how details matter like "dirty PCB's"- Awesome effort by PJRC. So cool they have an employee named 'BRAIN"! [ "Erin, Brain and I (yes, "Team PJRC" is 4 people) " ]. Having to work with a somebody named Brain and a soldering goddess explains why Paul has to excel or they would take over the company!

Paul: My recent helpful comments were:
> Make a "KS Early Developer" announcement thread and post that link in an update so those folks can get up to speed on K64 and K66 threads - assuming at least one isn't a regular here. Include any notes you may have and links to the Beta K64 and K66 threads. Or perhaps just give links to K64 and K66 threads in an update.
> Consider a prerelease TD_1.31_Beta0 build that would have some fix like Kurt's or perhaps this simple one to allow the Serial number to be exposed on USB.
 
I may have bricked my Teensy 3.6.
I attempted to test the update to Teensy_Logic_Analyzer.
That program includes a Windows application called OLS that flashes the Teensy directly with a pre-compiled hex program.
There was a preset for 240 MHz Teensy 3.6 Demo that was written to my Teensy 3.6-r3.
After that Windows 10 responded with "USB DEVICE NOT RECOGNIZED"
Since then I have not been able to get 2 different PC to recognize the Teensy 3.6, although both are able to program a Teensy 3.0 Normally.
More details are here: LINK TO THREAD
 
Ouch :( Scanned the other thread .... did either machine have the release TD 1.30?

Did you do the part about plugging in another Teensy? Of course using a second machine sort of discounts my reason for that. But having never seen a Teeny it wouldn't have known drivers in place which is part of the reasoning.

I've had some brick'ish moments with my T_3.6 using TYQT (may have been my HUB issue). They went away when I used TD itself for programming the first time. Not sure if it was related to Ser# failure or internal stuff Teensy.exe may do on new versions.

With released TD 1.30 installed. I'd open a simple blink sketch (with Serial) - do an IDE Ctrl+K and back to the IDE do Ctrl+Alt+S on the simple blink. [ you might do this once for a T_3.2 rename the HEX then repeat for T_3.6 at 180 MHz ]

Then close IDE and TYQT and open "?:\???\hardware\tools\teensy.exe" [with no attached Teensy] and point to the folder from the Ctrl+K where you should see that Hex. Then, Button pressed, plug the Teensy - wait a couple secs - release and ask Teensy.exe to upload that Sketch file. [ If you saved a HEX for T_3.2 do that one first then unplug and repeat for the T_3.6 ]

If there is a problem the Teensy.exe log should show it if the device ever shows up. I wouldn't think even the bad bit on the 3.6_MCU would stop the program_MCU from presenting as HID - but I don't know the mechanics there.

If that doesn't fix it then the LA upload somehow did the impossible or the undesirable.

<edit>
[The serial number is etched write once, but unless a CORES change was made it will never show a Ser# from a 240MHz T_3.6]

Just read follow up post on LA thread - assume you have a T_3.2 if not of course try the above with the T_3.0.
 
Last edited:
defragster said:
Ouch :( Scanned the other thread .... did either machine have the release TD 1.30?
Click to expand...

defragster,

I tried a new installation of Arduino 1.6.11 with Teensyduino 1.30 final, but there was no change.
I'm able to compile blink_with_serial and generate a Hex file there's no way to upload the Hex file using either TyQT or Teensy.exe as neither ever recognizes that there is a COM port or a Teensy 3.6.
There are no error messages in the logs or verbose Teensy output.
Everything else works as normal with both a Teensy 3.0 and a 3.2

It looks like I'm gonna wait until the K.S rewards ship to continue my Teensy 3.6 saga.
Maybe it was just time for it to give up the ghost.

By the way, Bounce, Bounce2 and XPT2046_Touchscreen, Encoder library and Hardware based QuadDecode are all working on T3.6.
Has anyone tried FreqCount, FreqMeasure, or FreqMeasureMulti on the T3.6... I was just starting with that and was getting compile errors.
 
Last edited:
So sad . . . if it won't come up as HID device for programing then it is messed up.

I don't suppose there is any chance your dog chewed on it - or you had a wiring issue that shorted/burnt anything?
 
The procedure which has always worked for me (maybe because the Teensy wasn't truly bricked) is to plug in the Teensy and fire up the Arduino IDE.
- open the Blink sketch.
- hold down the reset button
- compile and upload the code.
- if TeensyDuino isn't running, give it time to start
- release the button.
If it works you will of course see the LED blinking and if you check in the IDE Tools menu you should be able to see the COM port under the Port menu.

If it doesn't work the first time, try it once more from the second step (hold down the button).
If that fails, you may indeed have a brick.

Pete
 
defragster said:
So sad . . .
I don't suppose there is any chance your dog chewed on it - or you had a wiring issue that shorted/burnt anything?
Click to expand...

No my dog did not eat it, but she did once eat the remote for a new TV. She also ate our "How to Train you Puppy" the day after we rescued her from the pound.
At the time it died (the Teensy 3.6, not the dog), I only had a 3.3V passive encoder (Teensy supplied 3.3V) hooked up, which had been running perfectly all weekend.
I thought I'd take a break on that when I saw the updated logic analyzer.
 
Wozzy said:
I may have bricked my Teensy 3.6.
I attempted to test the update to Teensy_Logic_Analyzer.
That program includes a Windows application called OLS that flashes the Teensy directly with a pre-compiled hex program.
There was a preset for 240 MHz Teensy 3.6 Demo that was written to my Teensy 3.6-r3.
After that Windows 10 responded with "USB DEVICE NOT RECOGNIZED"
Since then I have not been able to get 2 different PC to recognize the Teensy 3.6, although both are able to program a Teensy 3.0 Normally.
More details are here: LINK TO THREAD
Click to expand...

As mentioned earlier in this thread, I got also a T3.6 beta2 into a 'infinite programming loop' (now back to PJRC and in Paul's hand and diagnose confirmed)
To see what is going on you could connect an LA to the SWD pins and sample and decode protocol for a couple of seconds (triggered by reset pin going high again)
In my case I could see the typical SWD communication followed by a repetitive sequence of commands.

As Paul has now a frozen T3.6, lets hope he has time to figure out what is going on before the rewards are shipped.
If you have a situation to similar mine, I guess Paul is interested to get the T3.6 back for testing.
I have the strong feeling that the bootloader program needs a careful overhaul to keep robustness also for the new and, as it seems, different MK6x chips.

Otherwise, it's time to get a SWD programmer/debugger
(Anyone who can give a hint on which hardware /software combo is suitable for T3.6, or does any SWD debugger work?)
 
I've already started to update FreqMeasureMulti, not only for use with the new Teensys, but also to use (if wanted) all FTMs and not only FTM0. But things are going on slow for now, my day job is eating me up.
 
el_supremo said:
The procedure which has always worked for me ... If that fails, you may indeed have a brick.
Click to expand...

el_supremo,
I tried your reprogram sequence, but my T3.6 is still not recognized by Windows 10.

WMXZ said:
As mentioned earlier in this thread, I got also a T3.6 beta2 into a 'infinite programming loop' (now back to PJRC and in Paul's hand and diagnose confirmed)
To see what is going on you could connect an LA to the SWD pins and sample and decode protocol for a couple of seconds (triggered by reset pin going high again)
Click to expand...

WMXZ,
I'll hook up my logic analyzer tonight to see if there is any digital activity going on or if it's electrically dead.
I do get 3.28V at the 3.3V pin, and the Reset pin pulls low and then goes high again when program button is pressed and released.
At this point, I'm assuming that my T3.6 is unrecoverable.
I'm back to my T3.2 until PJRC ships my T3.6 Kickstarter rewards.

If it is stuck in an infinite loop, I wonder if there's a way to jump start it from a working T3.6?
The jumper cables in my truck are probably too large :)

Thanks for the help,
--Bob
 
Last edited:
Paul must be swamped - I'm sure he'd want Wozzy's T_3.6 back ASAP.

Paul recently documented a way to set the T_3.2 lock bit in EEPROM that then requires a full erase get access to the stored code. I wonder if this has been checked to work on the T_3.6 and T_3.5? Actually reading that post it wasn't the one where the actual CORES bit was created and explained . . . I saved that in the WiKi but not the thread where the named byte was changed - does anyone recall that post/thread?
Here is the commit change details: github.com/PaulStoffregen/cores/commit
And the Thread Post: Setting-flash-security-byte?

Also if anyone wants to see what I've done with letting the T_3.6 over 120 MHz write to EEPROM I've been updating that thread. I have what seems solid to:: stop processing - drop the speed (anything 144-240) as needed to have access to write the full EEPROM and then RESET to normal operation where the code then has those updated values from EEPROM. I got it working without reset, only tested at 180 MHz, but when I cycled that about 4 times with USB working the next write without reset - at least on my Windows machine - didn't have usable bi-directional USB - received by the Teensy, but nothing came back out to the PC, and this was good with TYQT but SerMon (and IDE) FROZE/HUNG until I unplugged the Teensy. So it isn't possible - or I didn't do some essential step in the USB setup as it gets lost when the clocks go Fast>Slow>Fast. I have not tried any other BUS families (Serial,SPI,I2C,...) - but it was good to get the USB online to be able to debug, while it lasted. Perhaps there is a fix for the limited USB resetting? I could try it with Serial1 debugging I suppose and start testing other devices.
 
Last edited:
PaulStoffregen said:
Yes and yes.
Robin's contacting Wozzy now.
Click to expand...

I already heard from Robin.
I'll send it back later today.
Thanks

Edit: Update - It was picked up at 7:20 last night and is scheduled for delivery by 10:30am today. (Wed 9/14/2016)
**Wow!**
 
Last edited:
I'm working on bootloader fixes and improvements.

I have code that detects and recovers from the locked condition of WMXZ's board. My hope is to test it on Wozzy's board later today, before releasing the update.

The 512K flash bug is fixed, the serial number is now reported properly, and a minor bug where bootloader mode is improperly ended (doesn't always reboot to your program) if the program button is tapped while the bootloader runs is also fixed.

One new feature will be added. If you hold the program button for 15 seconds (actually, between 13 to 17 seconds) the chip is fully erased, including eeprom data.

If testing goes well with Wozzy's board, I hope to have an update to you later today.
 
Status
Not open for further replies.
Back
Top