K66 Beta Test

Status
Not open for further replies.
In the past day I've had two anomalies uploading to my K66's. Actually both were on the Beta_3 unit and the same code was working or acted differently/recovered on the PROTO_b1 board.

This after the K64 not running display as the K66 has kept me distracted - I put that on hold and then making sure TYQT was working otherwise I ran into these. For now I've taken TYQT out as an IDE loader replacement for TeensyDuino.

ONLY odd factor is I was using TYQT for my uploads. This comes up later.

> I wrote some EEPROM test code to use the various the function interfaces to fill the 4KB. This sketch reads and writes at 120MHz, and can only read over 120 it seems.
Problem was same sketch to both K66's and the PROTO_b1 ran and the Beta_3 would do one part and then 'die in the weeds'. I got as far as putting a print statement in the code and it would complete one portion and then never print the next like the Beta_3 unit did.

Something else "shiny" popped up and I tried to put code in startup_early_hook();. I have yet to get that to work, but in the process the PROTO_b1 withstood my failed attempts, but the Beta3 unit went into a state where I could not get TYQT to put a couple other pieces of different code on it (this was the 'later' piece). Rebooting my machine and seeing it repro, I manually used TeensyDuino to push the same HEX and the Beta_3 K66 came back to working.

This served as a great distraction and in the end TeensyDuino seems to be doing the right thing but I'm not sure if this was an edge condition that caught TYQT but TD can handle, or if TYQT is just not getting something right?

Paul - does this in any way relate to the failure to program over 512MB of flash - or just seem like an issue for Koromix?

Also: My now retired USB HUB was causing some troubles - a new USB 3 hub not showing those issues in any similar way [so not questioning USB on this Win 10 desktop], perhaps those failures got something off in the K66?

Noteworthy SIDE NOTE: It seems that K66 EEPROM reads DO work at 180 MHz?, only writes are inhibited?
 
With a simple "T_3.5" and "T_3.6" stamp at about $10 each, the boards could be clearly marked after passing QC, and an updated stamp should the board ever get a revision.

I found Black Circuit Board Marking Ink - just needs a natural rubber stamp made.

Above link (quoted first below) is black only - this place has black and 3 colors - quoted at bottom.

Surfaces: Metal and plastic parts, printed circuit boards, polyethylene, polypropylene and other hard to mark surfaces.
Drying Time: 10-30 seconds
Characteristics: AERO #432 is designed to resist solvents such as degreasers, freon, alcohol, cleaning fluids, triclorethylene, soap and water. The longer the imprint is allowed to dry, the more resistant the impression becomes.
Adhesion is excellent.
Color: Black
Suggested Application: Natural rubber hand stamp with industrial metal pad

432 Quart of Solvent Resistant Ink - Designed specifically for circuit boards. This medium dry ink is highly resistant to solvents .... It is also non-conducting.

Also known as WILMARK #22

Color System: Pigment
Solvent System: Alcohol

Available Colors: Black, Blue, Red, & White.

Note: this ink contains an aggressive solvent so should not be used with plastic stamp pads or stamping equipment with plastic parts. We have metal and felt pads specifically for this ink.

Medium Dry (10-30 secs), this ink gives excellent adhesion to circuit boards and the longer it is left to dry the more resistant it becomes to solvents such as degreasers, fluorinated/chlorinated hydrocarbons, alcohols, and soap and water.
 
How does Kickstart get your shipping address to PJRC? I don't remember entering it anywhere, and I don't see anywhere to change it. I'm confused how it all works.
 
Others I've done:: KS sends out an end of KS email for reward shipping address so they are current at the time the shipping happens.
 
I can reliably prevent my Teensy 3.6 (round 3) from starting, with the Blink sketch loaded on the board, when I:
- shut down the computer and remove the power cord
- wait a bit for the capacitors to drain, until the plugged in Teensies stop blinking (and then wait a bit more)
- plug it back, and then start the computer

My Teensy LC and my 3.1 start as soon as I plug the power in. My 3.6 (round 3) does not, even after powering the computer. lsusb won't show anything. I checked and there's 5V at Vin / GND. Pressing the bootloader button loads HalfKay, as expected. I tried 180 MHz and 120 MHz, no difference.

I have seen it fail to start at least once when I plugged it in my MacBook, I think, but I cannot reproduce that.
 
I see some of you are using female headers that sticks out so one can use a breadboard also, where do you get the long headers that fits these boards?
 
... My Teensy LC and my 3.1 start as soon as I plug the power in. My 3.6 (round 3) does not, even after powering the computer. lsusb won't show anything. I checked and there's 5V at Vin / GND. Pressing the bootloader button loads HalfKay, as expected. I tried 180 MHz and 120 MHz, no difference.

Interesting - if the power off problem happens at 120 or below then it isn't anything to do with the FLASH hiding in HSRUN mode.

I don't power cycle mine much - but anything Odd I've seen I couldn't reproduce and had to blame on TYQT as it goes away next trial using TeensyDuino - but then TYQT works fine after that too ...

I'm assuming you see this power up fail on a direct USB plug and not through a hub?

Does your blink setup() have any wait like 'while(!Serial)'? Any LED sign if you do something like this before the while?
Code:
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWriteFast(LED_BUILTIN, 1);
  delay(2000);
  Serial.begin(38400);
  while ( !Serial ) ;


Paul has a delay(400) in startup in pins_teensy.c about line 636 you might set this to 3000 and see if that changes anything in your repro case.
Code:
	delay(400);
	usb_init();

<edit> In pins_teensy.c I just did this to test with and it compiles - but I have to change computers to see it - it may add time for USB to come online and avoid the trouble:
Code:
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWriteFast(LED_BUILTIN, 1);
  delay(1000);
  digitalWriteFast(LED_BUILTIN, 0);
  delay(400);
  digitalWriteFast(LED_BUILTIN, 1);
  delay(1000);
	usb_init();
 
Last edited:
- shut down the computer and remove the power cord

Can you be a little more specific about the type of computer and which operating system it's running.

I'll try to reproduce it here, just as soon as I've send the cards off to be printed (likely late Tuesday or early Wednesday).
 
tried snooze v6 on T3.6 (K66) (IDE 1.6.11 1.30-beta3). sleep example flashes every 10s, and digital pin wakeup ok,though I'm not sure how to get touch to work?? measuring 1.4 ma

(v6 sleep example won't compile on T3.5(K64), no touch pins on K64, and there may be other mods needed for K64?)
Just uploaded an update for Teensy 3.5 that will compile, don't have one yet but it compiles so try it out and let me know. No touch for T3.5.
 
I don't BSOD below has anything to do with what seems to be a HDD issue, but I do suspect something off was messing with my USB hub, though it is old enough to be retired. It is now on a shelf - Paul if you'd like I can send you the hub. On programming Teensy's the hub leaves the system and the blue 'connected' light on the powered hub goes out. Actually IIRC hitting GUI RESET in TYQT with TD active caused it to go into program mode and in the process the FLASH goes blank and the HUB goes away. Repowering the hub or moving Teensy ( I want to say it was always a T_3.6 ) to another direct cable allowed TD to reprogram it back to service. I think this is what I was seeing when WMXZ had his PROTO unit stop taking code. {that was when a hub was still on my laptop - but that would have been a different newer USB2 hub}

BSOD::
I did what I suggested - I got blinks on power up. All was well. Then I just turned on the LED in pins_teensy.c [same delay(400)] and in setup made my while(!Serial) and it sat and waited, rather than timing out after the wait. Two T_3.6's cabled to desktop USB ports, no hub.

I did clean restarts and power off's - but on the reboot it was sitting too long at the BIOS' - "DEL for setup" screen so I hit the RESET and got the following:

Computer had a kmode exception not handled in mv81xx.sys - which is a 2010 Marvell Disk Driver file. That has apparently been causing others trouble since Win 7 in 2010, based on forum posts I found - though never for me.

First two times it BSOD'd before getting to login, having restarted, the two Teensy T_3.6's were waiting in the while(!Serial) with the LED on. I pulled them both off for the restart after there was no help from the boot fixer joke. After that I pulled both T_3.6's off and it restarted to the login prompt. I logged in then - and then I got the same 'kmode exception not handled in mv81xx.sys'.

I did just put a fresh SSD drive and New 3TB drive on this machine before the Win 10 upgrade, but did not touch the 5+ year old RAID pair . . . opps.
 
It's a desktop computer, I plug the Teensy directly in the USB 2.0 port (tried all of them). The computer is quite a few years old, made from spare parts that include a Seasonic BG-500 S12II-520 alimentation and a M5A78L-M LX motherboard (AM3 socket). It runs mainly Arch Linux, but also Windows 7. No difference if I boot either, the device is nowhere to be seen until I press the button or unplug / replug it.

The Blink example sketch is unmodified, I run it in Serial mode at 120 and 180 MHz. I programmed it with Teensyduino 1.30-beta4 (unmodified).

I cannot reproduce it on my MacBook, even if I remove the battery and plug it after. I will try on another computer when I get the chance.
 
Last edited:
I see some of you are using female headers that sticks out so one can use a breadboard also, where do you get the long headers that fits these boards?

Note, if you get the 6/8 pin headers meant for Arduinos, you will need to take a rotary tool like a dremel, to sand down one end to allow you to mount them side by side on the Teensys.

Alternatively, you can buy longer headers, and trim them down. I use a pliers to pull out the pin of the next row, and then use diagonal cutters to cut where I yanked out the pin, and then sand it down. Here are 18, 20, and 40 pin headers:

Sparkfun recently came out a set of headers made specifically for the Teensy 3.2/3.1: https://www.sparkfun.com/products/13925.
 
Here's another draft for both cards. Plan is to commit them for printing within the next 24 hours....
 

Attachments

  • card8a_rev1.pdf
    486.6 KB · Views: 188
  • card8b_rev1.pdf
    582.9 KB · Views: 536
  • card9a_rev1.pdf
    488 KB · Views: 179
  • card9b_rev1.pdf
    707.7 KB · Views: 179
Hi Paul,

Doing quick check, see you have the registered mark, which is great.

One thing I see right off the bat, is I wish the T3.5 front card had picture of a T3.5 on it. Shows MK66 and has the two parts needed for HOST...
Will keep looking

On Back of new T3.5, did you cross out the A21, A22, A25, A26? Does that imply they can take +5v?
 
Last edited:
On the back of the 3.5 card, it says Teensy 3.6 System Requirements. In terms of the requirements, I don't know if you want to list 32-bit Arm linux (Raspberry Pi) or not.

Hmmm, I did not realize that the 3.5 did not have the USB host header (and 2 new analog pins). I thought it just had a slower USB connection (12Mbit vs 480Mbit).
 
Hmmm, I did not realize that the 3.5 did not have the USB host header (and 2 new analog pins). I thought it just had a slower USB connection (12Mbit vs 480Mbit).
Teensy 3.5 only has a single USB controller (can be switched between host/device mode) - same as Teensy 3.2.

Teensy 3.6 has an additional high speed (480Mbit) USB controller that's more sophisticated and based on EHCI (that's the interface Intel USB 2 controllers use) and has a different programming model than the full speed (12Mbit) controller. This is the controller connected to the USB header.
 
It would be real nice to have a legend for the ports, I know there's not much room but if only on the back and only for the 3 serial port types (as the others are pretty obvious) it might help newcomers.
 
I'm sure new users will start asking about the "Debug" Pins, maybe add a short note like "enables debugging for advanced users"?
 
How does Kickstart get your shipping address to PJRC? I don't remember entering it anywhere, and I don't see anywhere to change it. I'm confused how it all works.

Shortly after the campaign closes we will send out a survey through Kickstarter to collect shipping address for the backers.
 
Thanks. I also got an answer from Paul to a private message on Kickstarter that said same thing. Sorry for duplicate questions. I read more into the article about invoices being printed than I should have. It even said they were all identical per reward level. Anyway another case of great customer service from PJRC. That's kind of rare these days from other most places.
 
The T_3.1 card says this too ON THE BACK SIDE :: "Additional pins and features available on the back side"

It is worded better on the LC :: "Additional pins, features, and specifications"

Looks good - I see these already noted: wrong image for the T_3.5, and T_3.5 card showing 'Teensy 3.6 System Requirements'
 
Last edited:
One thing I see right off the bat, is I wish the T3.5 front card had picture of a T3.5 on it.

D'oh!! That's an embarrassing mistake.

In terms of the requirements, I don't know if you want to list 32-bit Arm linux (Raspberry Pi) or not.

I think for now I'm going to leave the card to emphasize traditional computer requirements. I'm a bit conflicted about whether to really recommend such underpowered computing as a serious way to develop projects.


It would be real nice to have a legend for the ports, I know there's not much room but if only on the back and only for the 3 serial port types (as the others are pretty obvious) it might help newcomers.

Yeah, I wanted to keep the legend from the Teensy 3.2 card. But there just isn't room. :(

Really, trying to add this even on the back side results in things getting really cramped on a card that's already bulging with tons of details. Maybe someone who's an actual graphic designer could do better than me. Might try that route after the first couple batches, but for getting these printed in time to ship the Kickstarter rewards, I'm afraid this is one of many small compromises that needs to be made.

Looks good - I see these already noted: wrong image for the T_3.5, and T_3.5 card showing 'Teensy 3.6 System Requirements'

Oh, another big opps. I must have gotten pretty tried by the end of last night's editing....
 
Status
Not open for further replies.
Back
Top